When was the last time you read through someone else’s code, not because you were looking for a snippet to pinch or because you’ve been saddled with debugging it; but for the sheer joy of reading someone else’s elegant, witty, creative code?
On the basis that you’ve just answered either “Huh?” or “Never” (pretty much the only answers I ever get to this question, other than wise-cracks), does it strike you how odd that is? We programmers like to regard ourselves as creative craftsmen, who aspire to a pride in our work even in the face of rapacious and ignorant managers who generally make that kind of diligence impossible in real life. And yet, we never read each other’s code.
Can you imagine any other diligent professional behaving like this? Can you imagine a writer who says “I know all I need to know about writing. Why would I want to read other peoples’ stuff?” Or a musician who says “Why would I want to listen to music? I have my instrument right here – I can play whatever I want.” Or a sportsman who says “I play the game every weekend. I train every day. Why would I watch other people playing? When am I supposed to have a day off?” Or an architect who says “I put them up. I don’t gape up at them!”
Attitudes like these are inconceivable: people become accomplished and proud writers, musicians, sportsmen, and architects firstly because they actually like words, or music, sports, or buildings. But they also are continually measuring themselves against the best of their colleagues, constantly learning how their art is changing, constantly pushing their own boundaries.
It’s not even world-class creatives and athletes who do this. People who like to tinker with cars get together, look under each others’ hoods, and exchange tips. Even the least creative jobs you can think of – firefighter, production-line manager, bricklayer – all are constantly developing their skills, in no small extent by checking-out each others’ results.
But the overwhelming majority of programmers don’t do that. Many just show up to work, pound out code, and then go home again. A few make the effort to keep up with developments: seeking out and playing with new skills; running perennial evening-and-weekend projects which have no hope of ever becoming real products just in order to keep their hands in. But I have never yet met a programmer who seeks out great code just because it’s satisfying to read and understand, and I’ve certainly never heard of programmers recommending great code to each other just for the joy of reading it. It just doesn’t happen! So, can I ask you another question: Why not?
It seems to me there are only a few answers to this question, none of them very satisfying:
- Code isn’t the point of what we do. Code is how we do what’s really interesting. If we want to make apps, or robots, then coding is just something we have to endure. But I don’t really believe that. If that was the case, we’d get together and appreciate each others’ applications, or Arduino mashups, or phone apps, (like the car fanatics get together and admire each others’ cars) and we don’t seem to do that either. Besides, more projects are left unfinished because the code needs more polishing than because the bodywork does.
- Code is the point of what we do, but we don’t like doing it. But that simply isn’t true, and it particularly isn’t true of evening-and-weekend programmers. Most people who program for a living (and everybody who programs outwith their job) actually love what they do – in fact, it’s almost impossible to make a decent fist of even a trivial program if you don’t love doing it.
- Programmers just do what they do alone. Despite best efforts to promulgate programmer-apprenticeships, pair-programming, and code reviews, programming always was and remains a solitary activity. Like going to the toilet or …  We don’t look at each others’ code because we don’t care what anyone else is doing. It’s just you and me against the laws of mathematics, physics, and Moore; and I don’t know about you.
If you have any other answers, I’d love to hear from you – because this really puzzles me.
But what doesn’t puzzle me at all is the corrosive influence this phenomenon has on our profession and our industry. Software is a byword for blown budgets, failed projects, and amateurish working practices – and non-programmers see us in an even less flattering light! Frequently, we claim that programming is a young industry, and we’re still suffering from growing pains. But that excuse, too, is bogus: we’ve been writing programs longer than we’ve been flying helicopters or splicing genes, yet our kind of success and professionalism would have killed the helicopter business stone dead, and biotech wouldn’t even have been allowed out of the lab.
By the standards of the 21st century, our business actually has a reasonably long history, but our memories are disproportionately short. Because we don’t routinely and instinctively share our skills and knowledge (only soundbites and snippets), we have no shared sense of craftsmanship or excellence. We don’t even have much idea of what programming excellence would look like (the way we know what great musicianship or a great sports or great architecture looks like) other than an absence of ‘smell’. We are left with no way of passing best-practice and acquired skill from one generation to the next, and every developer is condemned to solitarily rediscovering and reinventing the solutions of his predecessors. Against a backdrop of constantly-churning tools and technology, there’s a sense in which we’re not actually progressing as an industry at all. And that matters.
1 To any firefighter, production-line manager, bricklayer, or other ‘uncreative’ professional reading this: I apologise. I know that your job only looks dull from the outside. I know that, from where you stand, your job is engaging, interesting, and highly creative. To you, it’s programming that’s dull!
2 Use your imagination!
3 And surely, there has to be more to programming excellence than just a lack of ‘smell’