Oh look, a thread about my current company. I'm actually in a bug fixing team right now separate from the main product development team. It's an extremely difficult position because as someone else mentioned, you need an incredibly deep understanding of the system to truly resolve these bugs. Unfortunately I work on a 20+ year old legacy codebase with minimal documentation and poorly written code, and our dev team is unwilling to spend any time helping to resolve these issues. They're too occupied with churning our new features, while the bug team is abandoned to clean up the mess from all this new code without any sort of help whatsoever. Another perspective that many people don't discuss is that only doing bug fixing is soul crushing. With things constantly breaking, it can be very mentally draining having to fix them. That being, the attrition rate on the team is quite high because there's very little career growth or satisfaction in being a bug fixer. This experience could be exclusive to my company, and I can't say whether it's effective for the business to run things this way since I'm still really early in my career.
Ask HN: A separate team for fixing bugs?
11–12 of 12 posts
Re: Ask HN: A separate team for fixing bugs?
#12Why would one want to do that? That looks like an open loop system. Fixing bugs is a feedback loop that allows the system to correct.
I try to involve juniors as new as a couple of weeks in all the project so they learn how software gets made and how the business is run (cc'd in mails with clients so they get the initial back and forth, ideation, clarification and elicitation, how specifications come to be, tradeoffs in engineering and business, courtesy) and I ask them to interact with the client.
Then they write the code knowing the rationale behind why they're writing it this way and why one feature is higher priority than the other.
They then can be more independent because they see a bigger picture than adding a new endpoint.
Then when there's a bug, they know about it first hand and they witness how it's handled with the client and they go on to fix it learning and documenting the assumptions that lead to the bug.
Alignment is high, as is accountability and the desire to make it right. Learning is accelerated in terms of engineering and code, communication, and business savvy.
In my opinion, one misses so much separating concerns that way. Even the humility would go down as the one who wrote the code doesn't get the feedback from the mistake.