I recently heard of a situation where a team needs to hire someone since they’re understaffed.
The reaction from one of the developers was simply:
“I don’t want to maintain their code.”
I understand this mentality. The worst code is always other people’s code. For most developers, this is simply fact.
What is also fact is that very little software of significance gets built by the lone wolf.
Building software is a difficult endeavour. It is also a time consuming one. At some point, more developers have to be added in order to get more stuff done. That’s not to say adding new developers to a team is easy. It isn’t.
Yet most of the difficulties of adding a new developer can be mitigated. The fear of maintaining another developer’s code is only justified when a developer with the wrong skill set is hired. This is not to say that hiring is an easy exercise, but putting effort into it can help a great deal.
The largest difficulty with new developers is actually the ramp up. Every software system has different patterns and naming conventions. These all have to be explained to a new developer. Even when they are explained, the sheer quantity of stuff to know will result in it taking weeks or months before a new developer is at 100%.
This can be mitigated with good software architecture. Good software architecture makes things clearer and more apparent. Instead of a new developer fumbling around, things can make sense just by looking at the code.
Unfortunately, “good” software architecture is extremely subjective. I’ve had multiple devs join a team where some really liked the decisions I made and some really hated those decisions. What “makes sense” depends on how a person thinks and different people think… differently.
Therein lies one of the biggest problems with adding a new developer: the ego of the existing developer. New developers also mean new opinions. New opinions challenge the decisions we have made. At this point, the fear of maintaining another developer’s code is not based on that code being bad. It is based on that code being different from how we would write that code.
In many ways, new opinions are a good thing. New perspectives can help us refine our thinking and make everyone on a team, both existing and new members, much stronger than they were.
That only happens if the ego of the existing members can take it.
Top comments (2)
Good read. However, I feel this is very subjective to the kind of code that you've been asked to maintain. In my experience, more often than not we learn something new from someone else's code. Either it's style of coding or clarity of approach. It becomes difficult when you're asked to maintain patchy and obscure code regardless of who wrote it. Taking accountability of maintaining such code puts jobs at risk. Better to call it what it is being objective rather than emotional.
Leaving aside the subjective topics (ego, oppinions ...) I can touch a few other spicy problems.
The company (managers, sales etc) will not value the new guy's work, most probably. The work he is doing most of the cases will not directly affect an important product KPI. Even if the work improves the product is not a visible (for non tech ppl) impact, I was actually reading this article earlier Why I Quit Google.
The old devs must explain the new guy the entire history of the project and most important the context. Understanding WHY those decisions were taken is more important (business vs tech decisions, like stupid example: we had a voucher of 10000$ on Azure and we didn't went to AWS, or we wrote that class because the management told us it will only stay in production for 2 days, which ofc they always lie).
Personally I got over this "fear" of legacy code only after I read the "Refactoring by Martin Fowler" book, I discovered a new world of challenges and opportunities, and understand how a code can and should evolve over time.
Related to this, a lot of oppiniated devs don't like, agree or know about the YAGNI principle, and when you are new to a project, and see the current problems is easy to say .."the todays issue could be solved by design last year when they wrote this system, but now I have to waste time and do their work...".