C-Level developers

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.

1. 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.
2. B developers will generally follow standards but are not able to pin point software issues which give them an uneasy feeling
3. 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... ;-)