There are an estimated 200,000 people in the UK who build software. Like all demographic groups, coders are a mixed bunch. There are the true stars of software development, who are highly productive, producing software of a good quality at affordable costs – well, affordable by software standards. At the other end of the scale, there are coders who, if a register of professional programmers existed, would be struck off it.
There’s no doubting that the standard among freelancers is higher, largely because many of us have to prove ourselves over and over again, starting from scratch to rebuild our reputation with every new client. But you will have no doubt come across many contractors who are “faking it”. Just because you know the rules of chess, that doesn’t make you a chess player. And just because you know how to write Java code that compiles, that doesn’t make you a programmer.
Having worked with hundreds of freelance programmers, I’ve been privileged to see some of the best, and unlucky enough to have crossed paths with some of the worst. What’s striking is that quite often the worst programmers have more confidence in their abilities than the better ones, who constantly question and challenge themselves, which is one of the reasons they’re better in the first place. An “unconscious incompetent” is someone who doesn’t know enough to know that they’re rubbish. The auditions for The X Factor are crammed with people who seem quite oblivious to the fact that they can’t sing. Dotted around IT departments across the country, there are people who are equally oblivious to the fact that they can’t write code.
Part of the cause of this lack of self-awareness is the secrecy that surrounds many projects. According to the accepted statistics, most projects either fail or are severely compromised in terms of time, scope, quality and cost. But organisations, understandably, don’t shout about their failures from the rooftops. Indeed, many programmers never really find out that the project they just worked on failed. It appears that nobody has the heart to tell them.
I suspect that if we were more open about our performance, the average standard would start to rise as we feel the pressure from competing teams who are just that much better than us. Benchmarking is a great way to find out where you stand in the grand scheme of things. How much working software can you deliver in a month? What does it cost to deliver it? How good is the software that gets delivered? Surprisingly, these things aren’t too hard to measure, and yet the vast majority of teams never do. Maybe, like me, they’re too afraid to step on the scales…
A Contractor from London