I have made a discovery. You might think it’s obvious, but it was new to me. It was this: that programmers come in different shapes and sizes.
Lest you think I have been shut away, keyboard-bashing in darkened rooms for so long that I’d forgotten what my fellow-man looks like, let me reassure you that I’m not talking here about physical appearance or geometrical dimensions; I know that different people have differing physicalities. No; what I’ve discovered is that programmers have different shapes as programmers.
I noticed it when I was talking to a colleague at a conference recently. We were discussing why it is so hard to convey architectural designs to otherwise competent developers. Suddenly, there it was: programmers are shaped differently to architects. And they’re shaped differently to each other.
Broadly-speaking, I’ve identified two different dimensions of shape: focus, and depth.
Let’s talk about focus first. Every programmer, at the beginning of their career, is taught a programming language. Few beginners have much choice in the matter of which language it is – if they’re at university, it’s Java (because it’s free and relatively simple), and if they’re in a job, it’s C# (because it’s just like Java, except it’s Microsoft). Gradually, over time, our neophyte discovers the existence of other languages – either modern variations on the traditional OO theme like Ruby or php, or else increasingly rarefied exotica, like Clojure, Scheme, Erlang, Haskell … “can you still hear me, over there?”
But then, archetypally, one of two things happens: Either the programmer selects one language as home turf, explores every nook and cranny with increasingly microscopic precision, and develops his skill and knowledge to the point of gurudom. That’s narrow. Or else he revels in the whole gamut of programming languages and technologies, and tries to learn them all. That’s broad.
Narrow programmers make good language lawyers. They’re the people who know their way around humongous class libraries, and are no longer surprised by their interactions. Until recently, it was only narrow programmers who could get any sense out of C++. Narrow programmers are the specialists. They know how to use the facilities of a language to solve a problem, even when they have to make the language turn somersaults to do so.
But broad programmers are the generalists. It takes a broad programmer to spot when a language is unsuited to a problem, and change course. Broad programmers are the people who write reusable class libraries (even for specific projects). It’s the broad programmers who can simplify problems until they become easy, precisely because they have a greater arsenal of tools at their disposal.
You can spot the difference when broad and narrow programmers communicate (and even more so when they miscommunicate!) Two programmers having a turf battle over two almost-identical languages are thinking narrowly. Programmers arguing over how well some language implements a particular design pattern: that’s narrow thinking too. But the programmer who objects to the whole concept of design patterns, because they should be in the syntax of the language itself: that’s broad thinking. The programmer who claims that every language is a pale imitation of LISP (precisely because LISP can be made to express everything in every language invented, or yet to be) is showing characteristic broad thinking. The programmer who won’t argue about which is the best OO language because the whole idea of objects is a pervasive imperialist plot to crush the creativity of the downtrodden… Well, you get the idea.
So that’s focus: narrow or broad.
But there’s another dimension: depth. Depth is about how a programmer uses the tools at his disposal to solve the problem he’s faced with. It’s probably best introduced by example.
We have all seen them: the programmers who have taken to heart everything they’ve been told about how to write maintainable, re-usable code. They’ve factored and refactored their stuff, and they have a nice, clean, object-oriented architecture which perfectly (even cleverly) implements the problem they’ve been given. Everybody gets it. But then, the specification changes, and somebody has to implement the change, and this beautiful, well-designed, well-factored code just can’t adapt. It’s all got to have to come out! You’ve been there, haven’t you? You know who I’m talking about.
What’s going wrong, here, is that the programmer isn’t focussing on the problem at all. He’s focussing on the solution, and on the tools he’s using to make it. But the problem, in all it’s complexity and flux, is out of range even of his peripheral vision. Basically, he’s looking at the surface of his program, rather than looking through his program to the problem beyond it. This is shallow thinking,
Shallow programmers abound. Some, like the example above, have learned a simulacrum of object-oriented design, and produce code which looks great, but turns out sticky. Others don’t even bother: they just run at the problem head-on, writing fast, simple, hackky code. If the specification changes: so what? That’s what overtime is for!
But deep programmers see right through the tool to the problem behind. Every time they design a class, or a module, or a system interface, they’re thinking not in terms of the whatever-it-is; they’re thinking in terms of the problem-space concept which inspired it. They’re aware not of what they’ve been asked to do, but of all the things they’ve not been asked for but could have been. Deep programmers hardly ever get blind-sided by a change request. They hardly ever deliver anything at all!
Broad through to narrow; deep to shallow: here is the landscape on which each of us has our natural home. These are the shapes of programmers, mapped out and displayed each in their rightful place. Where do you belong? How about your colleagues?
But now: the sixty-four thousand dollar question: Where are the best programmers to be found?Which is the most fertile ground? Where would you rather be?
Let me answer the last of those first. There is no “where would you rather be?”, because you are who you are:
- Broad thinkers are broad not because they plan for themselves a well-rounded education, but because they’re driven to explore new landscapes by their insatiable, irresistible curiosity.
- Narrow thinkers are narrow not because they notice the world needs another guru, but because no amount of expertise is enough – they can spend two weeks at a lecture about the weather systems on Mars, and come out saying “They only just scratched the surface!”.
- Deep thinkers don’t make any conscious effort to see through their screen. They just see, and having seen, can’t un-see.
- Shallow thinkers don’t have to make any effort to avoid gold-plating everything – when they’re not advancing toward their goal, getting the thing working: they just get bored .
Your programmer-shape is part of your personality, and like your height or your handwriting, you’re more-or-less stuck with it.
So, which is the best? Well, it depends. What are you trying to accomplish?
- These days, Agile development is very much in fashion. For that, you need shallow thinkers, and you need narrow specialists. The whole point about Agile is that you’re proceeding in rapid sprints (so you really need to know your tools), and you’re being driven, all the time, by what your stakeholders perceive as value (and that’s about as shallow as you can get).
- Agile exhorts that you “refactor early, refactor often”, but without any depth, how can you know how or in what direction to refactor? For that, you need, somewhere on the team, an architect. Architects deal not with present requirements, but with the possible. Architects need to second-guess every specification, predicting changes that may take place over the entire lifetime of a project. For that, you need deep thinkers, but you also need broad ones: architecture involves selecting technologies and stacks, it involves giving meaning to the ideas which are going to form the language in which stakeholder value will be expressed.
- Agile delivers rapid development. But the very fastest development of all is done by the broad, shallow thinkers. Here are the people who can fling together a mashup even before the focus group has finished ashing for it. Here are the people who turn up to hackathons with a tricked-out laptop, and leave, 48 hours later, with half a startup. They need breadth, because their success is predicated on the correct selection of a multiplicity of different tools. They need shallowness, because they need to get from here to there by the shortest possible route. Who cares about the quality of the code, when you can make another, just like it but better, in a long weekend?
- And that leaves the narrow, deep programmers. The specialists, who know their tools with almost indecent intimacy, and yet who never solve a clearly-defined problem of their own. You don’t meet them very often, but I assure you, your life would be much less pleasant without them. They are the people who write your class libraries, and your compilers, and who have solved most of your problems for you before even you knew what they were. These are the toolsmiths.
If you’re going to build a team, who should be on it? Again, it depends. If you’re an Agile shop, then you need a lot of shallow, narrow programmers with interchangeable skills (Agile makes no sense without co-operative working). If you’re writing anything configurable, you’ll need more depth than shallowness. In the early stages of a project, when you’re laying down the foundations which generations of subsequent programmers are going to build on, then some deep, broad thinkers will come in very handy.
But, all that said, I think a well-balanced team has as extensive a range of people that you can possibly cultivate, while still maintaining good communication. Even the best-planned project has occasional emergencies which need a solution hacked in short order, and even the most customer-focussed Agile team needs an architect in it somewhere.
So: broad or narrow; deep or shallow. What shape programmer are you? What shape are your colleagues?
1 How far we’ve come! That OO is now traditional!
2 “Ruby is better than Python! Any fool can see that! Whoever heard of ‘Python on Rails’?”
3 Who’d have thunk it?
4 “A man that looks on glass, on it may stay his eye; or if he pleaseth, through it pass, and there the heav’ns espy. ” George Herbert, 1593-1633
5 And the neophytes who began this story: Where do they belong? Actually, they don’t lie on this map at all. They have neither narrowness nor breadth, because they’re still struggling to tame an unfamiliar language into some semblance of compliance. They’re shallower even than shallow, because they’re not even focussing on the problem they need to solve, they’re compromising the problem just to get any result at all.
6 The trouble with Agile: Coming soon!