03.14.10
Levels of Developers
Jeff Atwood asks why programmers can’t, well, program.
I wrote that article in 2007, and I am stunned, but not entirely surprised, to hear that three years later “the vast majority” of so-called programmers who apply for a programming job interview are unable to write the smallest of programs.
To some extent, I think he’s being unfair, although I actually agree with him completely. One thing I’ve noticed recently is that there seems to be a bit of a step function in developer ability. Below this demarcation, developers seem to think of the value of their code entirely in terms of what they can get some library or another to do. Their programming is almost entirely manipulating objects written by others. Above this line, developers start thinking of the value of their code primarily being in what they write – and the code written by others that they have to deal with is, at best, an annoyance.
It’s not even entirely based on programmer ability. There can be very good developers capable of doing a lot of things by that kind of manipulation. There can also be developers that focus on their own code that are very much in the learning stages. It almost seems to be more about scope, or level of abstraction, than it seems to be about effectiveness or experience.
Taking it a bit further, there seems to be at least 4 of these developmental “jumps” that I’ve recognized. There’s probably more – and the fact that I can’t see them probably means that I haven’t achieved them myself, yet.
- Manipulation of code created by others. Typified by “call this library, put the results into this other library.”
- Algorithmic ability – primarily defines programs by the data transformations done. Library manipulation is assumed.
- Structural ability – primarily defines work done by the internal structure of the program developed. Algorithmic ability assumed.
- Systems design – primarily defines value by the overall design of the system, spanning multiple programs. Structural ability assumed.
So the problem with things like the FizzBuzz test, and the number of developers that can’t hack it, is that FizzBuzz is a “level 2 developer” problem. Developers at the first level, why they might be great at a huge number of tasks, simply don’t have the tools to solve it, and don’t usually think it’s worth solving. They also tend to think that problems like “find the least common multiple” are obscure math problems, and don’t get that it’s a test of algorithmic thinking.
A similar problem exists with design patterns. These operate at the third level or higher. A developer at the first or second level really has no use for them, or even really the capability to understand them. Telling a developer at one of those levels that design patterns are “good” is just asking for trouble – without the required understanding, they’ll try to apply patterns to the wrong problems.
Again, this is not really a value judgement. There’s alot of value in experienced devs who are at that first level – since they value libraries written by others, they’ll tend to know the ins and outs of them very well, will know which ones are useful, and will be able to pull things together to make something blindingly fast. If you want someone to develop a pretty typical CRUD app, that’s probably what you need. Guys at the “higher” levels probably aren’t what you want – since they don’t care as much about other peoples code, they won’t be as up on the intricacies or latest libraries. But, once you get off into areas that aren’t well-tread, that’s where you’ll start to need them.
So are things like FizzBuzz good tests for developers? Depends. If you really need a guy to tie some libraries together in a useful way, well, probably not. You’re applying a second-level test when you need a first-level developer – you’re testing the wrong thing. But at least it explains how so many programmers “can’t program.”