Thursday, December 15, 2011

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... ;-)

7 comments:

Justicle said...

Also known more colorfully as the "Bozo explosion".

Justicle said...

Also known more colorfully as the "Bozo explosion".

Graham Pearson said...

Yes bozo is probably a less 'PC' version of c-level. Though, we shouldn't flip the bit on them. Most can be trained and mentored. There's probably a d-level too - ones which do not even produce any functional code. They're easier to spot and remove so in the long run they don't do as much damage. C levels deliver functionality whilst slowly undermining code quality - insidious devils!

Justicle said...

Yeah I think another idea is just not to hire level C unless you feel like spending time and money on them. If they create negative work then you should be paying negative salary :-D

Craig Dunn said...

Secrets for building a successful team
http://gigaom.com/2012/04/28/6-secrets-for-building-a-super-team/
seems to back Joel's theory of "no means no". Doesn't help with the 'B hires C' problem, but I guess it's kinda advocating 'As shouldn't be tempted into hiring Bs if they can help it...'

Graham Pearson said...

A related question is - can you have too many 'A's in the team? Do you need a few 'less able' developers? Agile advocates/promises self-organising teams which presumably means you can have more 'A's working together since none of them is the definitive 'leader', and most developers (all people for that matter) want to be part of a winning team.

Justicle said...

Graham, this may help answer your question. Valve, the software developer behind Half-Life and Portal, released their "Employee Handbook". They pretty much have a team of 300 A employees, and seem to make it work with *no* formal hierarchy.

http://kotaku.com/5903955/read-valves-employee-company-handbook-its-amazing

It's must read.