RSS FeedI enjoyed reading the recent article Why Can't Programmers..Program?. This leads to the question, if 199 out of 200 programmers can't write code at all, how are we going to find enough decent programmers around to do all the work?
Personally I think the 99.5% useless rate is a bit exaggerated. People can write code for years and only learn a small set of coding skills, just enough to get by in whatever environment they are in. If this is sufficient to stay employed and nothing much changes, and though they have little motivation in expanding their skills for the future, how can they be considered useless? From a management perspective they are good enough to not be fired (or at least adept at avoiding anyone finding out).
Now take these same people out of their comfy environment in an interview, give them something new to do, and watch them fail horribly. Suddenly they are no longer considered programmers and are unemployable. Funny how a change in location creates a broken programmer instance. You go from being a somewhat useful programmer to being lost among the 199.
If 1 out of 200 programmers can actually program, and an even smaller percentage can be considered great, how do any projects ever succeed? The answer is probably "most fail". Even that might require explanation, as their are many modes of failure. The software might work but be slow, unusable, inaccurate, hard to maintain, buggy, unstable, ugly or not meet the needs of the customer, yet still be considered a success. Among the reasons for the lame nature of the success could be that the programmers really didn't have a clue but there are many others such as poor leadership, impossible schedules, bad architecture, terrible technology choices and a host of other ills. It's possible that the programmers actually did a heroic effort in the face of all these obstacles to even get a lame success. Yet sit these same folks down to solve a new problem and they look stupid.
Yes of course they could all actually be stupid, but the inability to excel outside their comfort area might not only be their fault. I've known people who worked for a long time in one company who excel in the environment, know everything that is going on, can solve a host of problems, yet rarely have time to write any code much less learn new things. Yet take them out of the company and they might fail one interview after another. Their value to their current employer simply fails to translate easily to a new one. 199? It's not always that simple.
I am very comfortable with new technologies, environments, challenges, whatever. After 25 professional years writing code (and being a programmer) and another 6 as an amateur) I find it's all the same just different rules. Yet I can't simply switch gears from one major language to another at the drop of a hat. I volunteer to work on the Mac client of an online game WWIIOnline which is written in C, Objective-C and C++. Now I did spend a few years writing in each of those languages, yet jumping into a unfamiliar codebase, in languages I have mostly ignored for years (Java dude since 1998) is a hard switch. Yes I could write FizzBizz but something more meaningful would take more time. I wrote the sound code for the Mac client in C++ (calling openal) but it took much longer than I would have liked as I had to remember all the C++ features and patterns my brain refused to recall.
On the other hand, most programmers are not very good, and that's where telling them apart in a short interview is so hard sometimes. How can you determine if someone would be a good contributor to your team by some simple coding tests? I have interviewed a lot of people, and sometimes they don't have the coding experiences you are using in your company but you can tell they have the passion, curiosity and interest to adapt and learn. Then again you can hire someone instead with a deep resume, who could write FizzBizz in 12 languages, knows every JSR spec by heart, and then delivered nothing in 18 months (I worked with such a guy). I would argue he was 199 despite the other evidence.
So how do we get enough people to deliver successful projects (assuming you can define successful)? For one thing you need a balance of great programmers who are willing mentors and teachers, eager programmers who want to excel, and a slew of programmers who can at least follow directions and recipes. Some people like pair programmers, tying people together with different abilities together. Personally I find even basic mentoring on a regular basis (where the less experienced programmer asks lots of questions) works well. Of course lots of people won't listen, don't care and just keep screwing up. Those are the folks I don't want to see on my project. Everyone can learn from other's experiences, mistakes, blog reading and even code reviews. It's how every great programmer got started.
I am not a big fan of classes and reading books as ways to improve a programming team, especially if they don't immediately translate into using whatever was learned. You learn coding by coding. You learn great coding by working with great coders. You learn to be stupid by working with stupid people (if you are smart, leave these kinds of environments!).
Nothing in this industry is black and white, great programmers might be useless and poor programmers might be useful in the right environment. No one interview technique is infallible in discerning who might add value to your team. Passion, curiosity and interest in learning might in the end be the best sign of a prospective great programmer.
We were all bad programmers to start with.
