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.