Stochastic Geometry

March 31, 2008

The case against passion

Filed under: General — Mark Dennehy @ 22:01

Something’s been bugging me lately. I’ve seen it said in otherwise intelligent blogs. I’ve seen it crop up more and more in resumes and job ads, to the point where it becomes something you have to say if you even want to be looked at, a piece of mindless dross taking up space on the paper or screen. I’ve seen it from managers who thought that it was an excuse to offer subaverage pay and conditions and demand unreasonable things from employees. I’ve seen it from people who should know better talking about how to educate and train engineers and programmers. I’ve been meaning to post about it for a while, but this post in It’s Common Sense, Stupid was the bit that finally got me to blog about it. It’s rather a dirty thing to say, in fact in some circles it could be positively career-damaging, but I don’t think much of those circles anyway and I think it needs saying, so here goes.

Programming is not all about passion.

Passion is the antithesis of good programming.

More on this after the break…

Before I have to don my asbestos suit, don’t get me totally wrong – if you had no interest at all in programming or computing, you wouldn’t be working with computers. The jobs we do, whether we’re teaching in university courses, working in startups, or buried away in the bowels of a large company in a perpetually underappreciated sysadmin role, are not jobs that sane people take on without some interest in computing. At some level, we have an intellectual itch that these little boxes scratch. We’d go postal otherwise.

But interest isn’t passion – and to claim that passion is the defining attribute of a good programmer is patently wrong. To claim (or even worse, to imply) that good programmers are the ones who are so taken up in their code that they pay no attention to piddly little real world things like pay, stock options, pensions, health insurance, morgages, taxes, politics, love lives, children, family or worst of all, hobbies that have nothing to do with programming, is utter nonsense. Programmers, especially good ones, are intelligent people, the main focus of whose intelligence is problem-solving. Yes, they focus more deeply on problems than some others, but not by continually excluding the rest of the world. Several have literally changed their world – we all know the famous examples of people like Tim Berners-Lee, Marc Andresson, Larry Page, Sergey Brin, Steve Wozniak and even Bill Gates (I said “changed their world”, not “changed their world for the better”). Pick up a can of beans and read the URL on the side, or ask who the world’s richest man was a few years ago, or ask any random office worker what a spreadsheet or a mouse is and you’ll see what I mean. Thing is, they all (except Wozniak and Berners-Lee, who actively chose academia over business) were or are highly successful businessmen as well. So is it that you can only be a good programmer if you are so passionate that you do nothing but programming, but Sergey Brin made a mistake one day and started Google without meaning to? Yeah, right.

That’s not to say that you have to launch a startup to be a good programmer either, by the way – I think there’s been enough of people getting kicks into Paul Graham recently to conclude that you might not have been meant to have a boss, but most of us weren’t meant to wear clothing or use money either and we’re getting along so well with those that we tend to expend lots of time and effort on acquiring both. The point is that these people were intelligent and intelligent people have a habit of being polymaths, often with an interest (and a lot of competence) in a lot of fields.

What does it take to be a good programmer? There’s natural ability in areas that are useful for programmers. The ability to think about abstract concepts productively is an obvious one, as would be the ability to focus deeply on problems being considered. Whether these are down to genetics or environment is an ongoing debate, but pragmatically the how isn’t important to us, just whether you have them or not. But I don’t think we quite need to start a eugenics problem just yet, because frankly, having those abilities is not sufficient to make you a good programmer. Useful tools for a good programmer, yes, but not a sufficient precondition to be a good programmer.

There’s training – but formal training has been shown by example to not be essential to programming, and I think that’s mainly because the field is far too young to know how to teach it formally in the first place (compare civil engineering with computer engineering and you notice things like the way courses in the latter change annually while in the former you can use course notes from ten years ago with ease in most cases). Established fields have had hundreds of generations of engineers to train, and have as a result learnt how to do so – computer engineering has had about seven and software engineering about four (I’m taking a decade as an estimate of the time between engineering generations here but there’s a solid argument for shrinking that significantly for software engineering – however, not enough to get software engineering onto a par with its brethern branches of the profession).

The critical thing, however, isn’t going to be natural ability or training. Or at least I don’t think it is. Soon Hui used the example of Tiger Woods in his blog post, and I think there’s an interesting point in that analogy, so I’ll use it – but Soon Hui was wrong about why Woods is a great golfer. Yes, he started playing at a young age, and yes he’s put in enormous amounts of effort into the game – but that’s not why he’s the champion that he is. He’s the champion because he works at it. And it’s not just the simple act of working at it either, every golfer does that, and some for longer than Woods does or has; it’s that Woods works at it in a structured, focussed, committed and self-critical way. Not critical in the sense of being negative, but critical in it’s original meaning – a dispassionate and objective analysis. He examines his performance, notes the weaknesses and works on them specifically.

Look, let me give you a better example. I’ll stay with sport because there are obvious parallels, as Juon Illas noted. Take olympic target shooting (to confess, I’m using this example because I know more about it than I do about golf, but it’s closer to programming than you think – both require patience, concentration and enormouse attention to detail). Look at the results from the ISSF World Cups, the World Championships and the Olympic Games for the past decade or three, and you’ll notice a trend – the same people’s names keep coming up, but with the exception of Ralf Schumann in rapid-fire pistol, the medals get won almost at random amongst those names (Ralf’s in a bit of a niche really). The reason is perhaps simpler than it appears – the difference in skill levels between the top thirty shooters in each event is usually negligible. Shooters do go through good and bad times in their competitive career, but on average, the difference between the top shooters on the line is miniscule. In fact in some events, the difference between the gold and silver medallists’ performances could arguably be down to brownian motion of the air molecules between rifle and target (0.1 points out of a possible 109.0 points in a finals boils down to a bullet hitting about 0.8 millimeters closer to the centre on one shot out of 10. That’s a difference of 0.000167%, roughly). So how do you get a medal in shooting if there’s that much of an element of random chance?

You train until you’re good enough to get into the finals consistently, and you keep competing and getting into finals, and sooner or later, you’re bringing home a medal. Simple, isn’t it?

Well, no, obviously.  It requires that you consistently examine your technique, your performance – both physical and mental, your equipment and your training itself, and that you not only continue to train but also that you continue to improve that training process (see why I thought it was a good analogy to use?).

Passion? Has no place in the process at all. Yes, you can use it as a motivation – but it’s worse than useless if you want to actually succeed. Passion is fleeting, transient, momentary on the timescales that achievement requires.  For motivation, you need something deeper and more permanent – and more, you need something that lets you be dispassionate at the same time as remaining motivated. Passionate shooters get into the sport, spend a few years trying, maybe they don’t get good at it but more usually they make it to some self-described goal like winning a nationals or hitting a certain score in competition, and then they lose interest and drop out. I’ve seen this happen dozens of times, and anyone in target shooting could list off names at you if you asked for examples of this. The people who stay in, who win medals, passion is not their motivation. They have a deep love for the sport, yes, but it’s the kind of love you get with three kids and a morgage and thirty years of listening to someone snoring at night. It’s about as new age and airy-fairy as death and taxes. And it’s also about as long-lasting.

So what’s the lesson to take from this analogy? It’s that passion isn’t the thing you need to be a good programmer – what’s needed, what’s vital, what’s fundamentally required to be a good programmer is the process. It’s the process of continually examining what you do in as dispassionate a way as possible, and improving how you do it.

Another lesson from the analogy would be that in this process you do not compare yourself to others, because there’s no point (target shooting isn’t a contact sport, you can’t effect other people’s performance so you just focus on your own and improve yourself). So you’re left with a continual process of dispassionate self-improvement for the sake of self-improvement, consistently carried out throughout your career.

There’s a word that has come to be used to describe that kind of behaviour. It’s professionalism. You want to know what a good programmer is? He or she is a professional. They get a job, they do it to the best of their ability, and they continually, dispassionately and deliberately improve how good that best is. They’re balanced people, with families and homes and jobs that they leave behind when they stop working, they include rest as part of their daily life, they take holidays and read widely and generally you find they’re more productive as a result. They take a task and they do it well and they do that consistently, instead of trying to do that one quick thing that will give them instant fame and ego-stroking. And maybe they’ll never have fanboys cheering them on when they put up slides in a conference that say “fuck you” to other developers; but when you get prostate cancer and the oncologist puts you into the IMRT machine to zap an area close to your gonads with a dozen different beams of radiation, you’ll probably find yourself hopeful that a professional wrote the controller’s software rather than someone who was always chasing the next hot thing in computing (and maybe never worrying about stupid dull things like documentation, specifications, tests, code reviews, quality control or that sort of old-fogie stuff).

And I know what your thinking – but you’re wrong (the eighties can come get their old tv catchphrases, thank you very much). Sure, a professional is a positive thing to be, but it’s dull and boring, isn’t it? Thing is, engineering’s a funny field sometimes (in the funny-strange sense). One of the lesser-remembered comments about the US space program – something that most people think of as desperately exciting and cutting edge – was that the astronauts often thought things felt unoriginal. The first american in space, Alan Shepard, commented that the view from the mercury capsule periscope looked unreal and the entire flight felt like one of the hundreds of simulated flights he’d done before.

Engineering can be simultaenously groundbreakingly original and mind-numbingly boring. It’s a dichotomy that may not be intuitive, but which lets you have a 500 horsepower sports car with airbags and anti-lock brakes. And that’s an analogy that’s somewhat relevant here, because a lot of this cult of the rockstar programmer feels like a mechanical engineer who builds the 500 horsepower car is trying to get a chunk of the adrenaline that goes with driving the car on the racetrack. But in reality, any engineer trying that would be suffering from a very small and myopic worldview; because the greater glory is in the long-term changes that the lessons learnt in building the car bring about – the car’s driver gets a fleeting buzz but the car’s designer changes the world, whilst also getting the regular salary, the pension, the health insurance, the wife and kids and home and eight hours sleep a night.

Of course, for those who feel they really need that cheap buzz, remember that the pragmatic engineers always get better actors playing them in the movies: Jimmy Stewart, Alec Guinness, Hardy Kruger, Ed Harris, Morgan Freeman and Jodie Foster on our side versus Tom Cruise for the racing drivers. No contest really 😀



  1. Post on DZone, then notice the very next submitted post is this one, agreeing with me. Nice to know I’m not the only one 😀

    Comment by Mark Dennehy — March 31, 2008 @ 23:50 | Reply

  2. Mark,
    Well said. Thank you for this thoughtful post.

    Comment by bill — April 1, 2008 @ 01:47 | Reply

  3. Hi, I have written a post on this.

    Comment by Ngu Soon Hui — April 2, 2008 @ 02:09 | Reply

  4. Yes, I know, it’s mentioned three times in the post above…

    Comment by Mark Dennehy — April 2, 2008 @ 10:14 | Reply

  5. Worth checking that link; the linked post is a response to yours 😉

    Comment by Shadowfiend — April 2, 2008 @ 14:25 | Reply

  6. Gah! That’s what happens if you do too many things at once!

    Comment by Mark Dennehy — April 2, 2008 @ 14:47 | Reply

  7. […] Passion is the antithesis of good programming. — I think there is a lot of misunderstanding around the notion. Good programmers need some passion, but great programmers need lots of it. For some reason everyone wants great programmers, argely because they’ve been promoted as having 10x the productivity of a usual programmer. The trick is that a great programmer will likely not be motivated to deal with the usual problems (exactly because of his passion) and likely will even underperform in such a role. My thesis is that passion is just as much important as the software you’re building is creative. Not everyone needs greatness and there’s surely not enough of it to go around. Give it up, people […]

    Pingback by » Blog Archive » The Case Against The Case Against Passion — April 2, 2008 @ 15:39 | Reply

  8. I would actually argue the opposite .. professionalism will get you through the times when you lack passion .. passion is what keeps you thriving in your career ..why stay in your field without passion ? Do something you’re passionate about and your creative mind is free to produce greatness. I can be a “professional” for a short period of time .. but if I don’t have a passion for what I’m doing .. sorry, I have better things to do.

    Comment by Jason — April 2, 2008 @ 18:08 | Reply

  9. That’s precisely why passion is the antithesis of good programming. Any and Every programmer out there has days when they wake up and all they want to do is program, because they have an idea in their head and want to go code it up. The problem is that the next day, maybe all you want to do is go off and play computer games or go for a picnic or veg out in front of the idiot box. The good programmers are professional enough to get through that and push their projects forward even when they’re not in the mood to do so. And if you think that the really great programming success stories were only done on days when their creators felt in the mood, you’re incorrect.

    The point wasn’t about those wonderful high days that we all get, when going to work is a joy and everything’s great – it’s about all the days, good and bad. The good programmers, the mythical 20%, work through all those days. They’re not dependant on waking up in a good mood to get good work done.

    Comment by Mark Dennehy — April 2, 2008 @ 22:21 | Reply

  10. IMO, this post can be viewed as either (a) the logical fallacy of false alternative or (b) a semantic splitting of hairs with muddy terms.

    Regarding (a), of course there is a middle ground where passion and professionalism meet. To suggest that a professional athlete doesn’t have passion is absurd.

    Regarding (b), can’t one’s passion fuel the drive to be dispassionate about analysis? I just don’t buy that dispassionate professionalism gets pro athletes out of bed in the morning. However, this descends us into definitions and semantics. I can’t argue against the post per se because the only definition of passion is that it is “fleeting and transient”. That is, the rhetorical deck is stacked from the start. (To be fair, the pro-passion posts don’t really define it well either).

    I do like the opening paragraph, though, and agree that the term is over-used.

    Comment by Michael Easter — April 3, 2008 @ 00:37 | Reply

  11. […] Dennehy blogs about passion in the context of programming in The case against passion. Took me a while to figure out what he wanted to get at but I think he’s completely mixed up […]

    Pingback by /var/log/mind » Blog Archive » In defense of passionate programming — April 3, 2008 @ 20:36 | Reply

  12. Passion will improve your best performance, self-criticism and practice will improve your worst. In the long term, the latter is probably more important from the point of view of your usefulness to an employer – unless you hit a golden fortnight in which you create a product that makes a zillion dollars. Which is possible, but not terribly likely

    Comment by Cormac — May 1, 2008 @ 09:46 | Reply

  13. The target shooting analogy is useful again here – when we start training people for target shooting, we don’t train them to hit the center of the target; we train them instead to not have “fliers”, to be consistent. So they start off and they shoot a 60 shot match and they have some 9’s and 10’s, lots of 7’s and 8’s and a fair few 6’s, 5’s, 4’s and worse. So we just work on basics. They don’t get any more 9’s and 10’s, but they get less 4’s, 5’s and 6’s. In other words, we work on consistency, on tightening up the pattern of their shots from the outside in – by bringing up the bottom of the histogram, not the top of it.

    Focus on improving the bottom of the histogram and you pass out anyone focussing on the top in very short order. They may have a few 10’s more, but you don’t have 3’s and 4’s. Same thing in programming. Forget passion – focus on the process.

    Comment by Mark Dennehy — May 1, 2008 @ 10:20 | Reply

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Blog at

%d bloggers like this: