I’ve heard, and I think it’s true, that the best ‘A’
developers hire other A level developers. Whereas the next best B
developers hire C level developers. Whether this is because of pride, fear of
being challenged, belief that the C levels best fit the needs of the company
I’m not sure, but it is a real problem that can result in entire teams
containing no A level devs and very few Bs (I’ve inherited a team like this
before and it’s a real challenge).
Part of the problem is that most C and B levels believe
they are As, in fact self-awareness of what a developer does not know is a
good sign that they’re advancing. So what’s the definition of the levels? In
basic terms it boils down to how they affect the software on the spectrum of
code quality. C developers will tend to leave code in a worst state than they
found it, whereas A developers will always improve it.
- C developers will forget to comment, will add unnecessary coupling, not develop all the tests they need, avoid refactoring, will adopt cut and paste coding, add more bugs, not test their own work. Essentially they will produce huge technical debt whilst patting themselves on the back when they deliver a piece of functionality on time.
- B developers will generally follow standards but are not able to pin point software issues which give them an uneasy feeling
- A developers will identify problems left by C developers and will take the time to fix them.
Over time, with enough C level developers working on the
software, the technical debt burden becomes so high that adding features is
prohibitively expensive and the software has moved into a legacy state. At which point a new project is started (hopefully using
some A developers). What is the solution to this issue? Only hire As and Bs – better to not hire at all than to hire Cs. Or if you are hiring Cs make sure they have some recognition of their limitations and ensure they understand that they won't be praised for speed at the expense of quality.
What if you don’t have the
technical skills to hire the As? They are not actually that hard to spot –
they will talk more about their craft than about what the software that they
wrote in past jobs actually did. They will want to tell you about the
architecture of the distributed message queuing system they implemented rather
than the fact that $4gazzillion of transactions were processed daily. They
will want to tell you about the automated build processes they introduced to
the team rather than the order processing screens they put together. They will
be able discuss technical debt and continuous integration rather than giving
you blank stares.
Btw, looking (a long way) back to my development days I can
recognise the traits of the C level developer in myself – ‘the quick solution is
best!’, ‘the client was really happy that I got that functionality out on
time’, ‘never mind that was a copy paste of another screen with a few changes’,
‘this change is simple, I’ll just make it in production and fix up source
control later’. Which is obviously why I became a manager... ;-)
