| Why 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. |