One of the best ways to progress as a developer is to man the bug queue. There's nothing quite like a stream of edge and corner cases to exercise your grasp of technology at large and your codebase in particular. Cheerful problem solving builds goodwill within your project team and helps you build bridges in the broader technological community. There's really nothing else that pays such dividends so fast and so well.
Sadly, over time a complacency can set in, and worse: a "not my problem" attitude. Developers reach a certain level of comfort and begin feeling their time is better spent on more visible feature work. It creeps in innocently enough under the heading of "I can't work on this without a reproduction scenario" but often it becomes nearly confrontational: bugs assigned to this team member are either closed under shady circumstances, swapped over to languish as a "feature request," pushed back to the reporter for more details, or tossed over the fence to either more junior or more senior team members who "have more time."
To the developer who has fallen into this habit, it's a way to protect their time to work on what they consider important. But being a reliable contributor who is willing to solve problems is valuable, and a project culture where bug reports are a battleground is toxic.
What can projects do to keep defect queues from becoming a low-reward backwater? What can senior team members do to foster a problem-solving culture? Let me know in the comments.
Top comments (4)
In my experience, this rarely happens because of developers being over-comfortable. It happens only under high levels of discomfort. Developers don't like leaving code in a bad state, but they tend to leave it if 1) the code is really messy and fixing it would be a huge effort, 2) the code-base is really fragile and fixing this bug has a high risk introducing new ones, or 3) the developers are put under a lot of pressure from management which results in them cutting corners to get stuff off their plates. Usually all three are true simultaneously.
This is only counteracted by making code quality the highest priority, and the hardest part of achieving this is having management understand it's importance. It needs to be turned into a company culture which can be assisted by numerous tools and techniques such as code reviews, automated Testing (at small, medium and large scales), automated code quality assurance (SonarQube, PMD, etc) and enforcing these rules with commit-hooks.
My experience is mostly from lower-level programming languages though, but I think these are general themes across the board.
I agree with this, most of the times I have ever said that it is not my problem is because I am restricted in time or the system is too fragile to deal with what needs to be done (often restricted by time).
If you are hitting that kinda road block a lot it is worth bring it up to more senior people to discuss what can be done around stablising the system or adding time in for bug fixes.
Good point. In some communities, certain bug work is shared between senior staff and more junior collaborators as a way to "show the codebase" to the new team members and also to foster the bug solving culture.
I have a "not my layer" attitude, bugs that belong to lower layers should not be covered on upper ones.