Hacker News new | ask | show | jobs
by beachy 757 days ago
When I started at Oracle yonks ago, there was a bizarre bug management system.

When a bug was found, it was assigned to the next available developer in the team. It didn't matter who wrote the code and created the bug - there was no feedback to them unless they happened to be the one who picked up the bug report.

The bug reports were printed out and stood in a tall pile on a manager's desk.

Quality was, as one might imagine, terrible. Junior developers had no idea what a bad job they were doing - senior developers spent their days fixing stupid bugs they would never have caused themselves.

The solution, blindingly obvious, was to start assigning bugs to the developer who caused them. The improvement was instant, because most people actually want to do a good job, and to be seen doing a good job. The pile of bug reports literally shrank before people's eyes.

The current industry seems to have moved back to these bad old days but on a longer timescale.

Resume-driven development abounds. Developers move on to the next gig before the impact of their decisions becomes obvious and quality plummets accordingly.

1 comments

It doesn't help that most of the career advice out there now is to move to a new role every 2 years if you want to get underpaid. Developers don't have the opportunities (or don't give it to themselves) to see how well what they build stands against the test of time.
was just having a chat about this in a recent 1:1

I've been at my current role for almost 7 years. Many of the best lessons I've learned have come from the pain of maintaining and fixing my own mistakes.

Sometimes it can take 2 years just to tell if a decision you made was good or not.

"move to a new role every 2 years if you want to get underpaid"

missing "don't"