At the top of my blog is a fact quoted from Robert Glass’ excellent book, Facts and Fallacies of Software Engineering. It says that the best programmers are 28 times more effective than the worst.
Before discussing this fully, we should concentrate on the word ‘worst’ for a moment. Clearly, Glass was referring to people who are actually productive on a project, otherwise the difference between the two would be infinite, so he’s not saying that the best programmers are 28 times better than the worst people you’ve ever worked with, which would be easy, he’s comparing the best to the worst ‘productive’ programmers. Those people who can and will write code professionally, who try to contribute but due to a lack of skill continually introduce broken code to the system. There are worse people than this on some projects — people who refuse to contribute anything at all, people who refuse to collaborate with others, people who just don’t know what they’re doing or what they’re meant to do — Glass isn’t talking about them.
Now, 28 times better seems fairly specific, but Glass is a solid researcher and he offers up his figures and method of approaching this measurement, and having read what he did I have to agree with his conclusions. Of course, we’ve always said that the best are 10 times better than average, but that’s always been an adage rather than a fact. Glass provides us with facts, against which we can model and compare our own practices. As an engineer I believe that facts are very important. I also think learning is important, so if you’re reading this blog but you haven’t read his book then shame on you – go read it first (he has much more interesting things to say than I do).
Glass does go on to mention that given the pay isn’t commensurate with this fact, the best programmers are a bargain. This is what I really want to discuss. I’ve always been rather well paid, but never what I’m worth to a company. Partially this is due to competition — I can’t charge $10k a day while there are others out there willing to do the job for a lot less. Of course, I know that there aren’t that many engineers at my level still practicing in this way (a lot of my peers have been lucky enough to get rich), and that almost everyone else has less experience and can’t provide the same level of benefits as me, but how is the client to know that. How is the client meant to distinguish between my credentials and those of other, less expensive engineers?
The way I used to do it was to charge exorbitant rates. That set me apart, made people pay attention and start asking why I was charging a lot more than my peers. Basically, it was a form of marketing – I got the most interesting jobs this way, and I got paid more (which is nice). This doesn’t work any more, the market has leveled out over the last decade and now I’m only charging a small premium, and usually that means that I have to take on extra responsibility, such as client principal.
Now I’m getting older, and my day-rate is no longer sufficient to keep me interested in consulting. When I eventually give it up the industry will loose an effective coach. I will start my own software house and develop android business applications, and my knowledge will benefit only me, rather than the wider industry. My clients will take on less experienced advisers and they will suffer for it.
The thing is, I don’t want to give up consulting – I actually love being an international consultant (I think it’s the second best job in the world – the best is, obviously, male porn star). I enjoy learning new business domains (I enjoy it a lot) and I love learning from the teams I interact with. I love traveling to new cities and staying in top hotels and beautiful apartments and going to hot restaurants. I am a good consultant too – and I enjoy it. Above all, I like helping people. But, I’ll be force to give all this up because my day-rate is no longer tied to my experience and skills, it’s tied instead to a market that considers humans as commodities. In order to raise my day-rate to a level where I’m interested in consulting again I’m going to have to change the whole industry.
Okay, it has taken a while, but finally I’m getting to the point, and this is a point I’m going to harp on and on about in this blog. We need to change how we recognise, recruit, and reward, talent. I’ve been banging on to my clients for years about their hiring processes, and how they’re totally dysfunctional. I rarely meet a team without at least a few dead-weights dragging down productivity. I often meet teams who succeed through the heroic effort of one or two people who end up doing all the work anyway. I think we should take those people and raise their salaries to compensate, and fire the people who can’t do their job right.
There, I said it – we should fire people who can’t do their job right. These are the people who aren’t engaged in their own personal development, who don’t really contribute anything positive to the team, who constantly have to have their code rewritten, who are responsible for ‘code review’ process-patterns being introduced in the first place. We’ll be better off without them. We would all be more productive and less frustrated if we got these people out tomorrow. If you’re a chickenshit liberal (like me), then perhaps you can get them trained in test automation, or release management, or dog-walking, but you need to get them off the development team asap, and pay the heroes for the work they’re actually doing, the work of the entire team.
But, how do we recognise talent? How do we hire good people? How do we recognise people who are just cruising and not improving and distinguish them from people who perhaps simply have not had the right training or the right experience? Well, that’s partially what this blog is sort of about. Over the next few weeks
I’ll write more about hiring processes and how to filter out non-starters in an efficient way.
Hugs and Kisses,