Prescriptions, Proscriptions, and Prognostications Software Engineers are like Cyclists by Matthew Wilson April 16, 2005
Summary
A light-hearted look at the similarities between the characteristics of Software Engineer and Cyclists
Advertisement
Being as how cycling is the most beautiful of all sports, being a fascinating mix of pain, physical
prowess, ability to suffer, profound (but often subtle/hidden) strategy, bluff, courage, and joy, I
always tend to see it as a metaphor for pretty much anything worthwhile in life. On my morning 90
mins of torture, around June last year, just after Bill had kindly agreed to bring me into the Artima Blog
fold, I spent the time thinking about the correlations between cycling and software engineering. (Since I
was then - and still am now! - pretty mentally spent after the writing of
Imperfect C++, I tended to focus on the
arduous characteristics. Hopefully you can apply a veneer - (see chapter 21 ) - of optimism over my
perspective and still find some useful aspects of the metaphor.
So, in point form, an unordered list of the convincing (and the tenuous) correlations between these two valiant pursuits:
Getting the miles in. Cycling is a very long-term investment sport, where you need to literally spend years
stimulating the appropriate parts of your physiology to make the necessary adaptations. No matter how fit you are
as a swimmer/runner/decathlete/skier, you're going to drag behind the pack for some time. Software engineering is
much the same. Just like those first few years after you come into the sport, it doesn't matter how good you were at
chess/mathematics/video-games/whatever, you're still going to find yourself vexingly outpaced by crusty looking old
dogs whose best years are so obviously behind them. There's no option; you've just got to get those miles in.
Muscle memory. The long-term nature of cycling fitness is both good and bad, since it means that you can be
off the bike for 6 months and still have some appreciable level of form, but also that if you take 5 days off you're
off your peak and will have to spend some longer time getting it back. Same deal with programming. Take any
time off, and you're immediately a ways behind all the latest Agile / Extreme / Imperfect / TMP methodologies and
techniques, but you can be away for some extended period of time and much of the long-learned skills are still
there and accessible.
Endorphins. There's little doubt among serious sports-people that the best high is granted by the body
as reward for giving it a dose of repair+strengthen stimulation. Lord knows it's not the hours and hours spent on
that razor sharp saddle. In just the same way, software engineering is mainly drudgery - fighting IDDEs / source
control systems, documenting, debugging someone else's code - punctuated with moments of sublime joy when one has
cracked a hard algorithm, invented a new technique, brought a project in before time, taught a co-worker something
that you know's going to change their programming life for the better. I'm not sure if it's endorphins that are
cursing through your veins at such times, but it feels pretty similar.
After a good bike ride, I know that no matter what happens for the rest of the day, that day is a success. Same for
a good day at the keyboard. Conversely, a day without exercise is poorer for it; a day without any reaching any
milestone in software development is one that feels pretty flat.
Research. A cyclist who doesn't research the course, his opponents, even the practices of the crowd, is one
who's made his life twice as hard as he needed. Same goes in programming. If you don't take the time to think about
what you're doing, you'll spend many long hours at the keyboard and come away with the feeling that you've achieved
nothing. (Note: for any budding authors out there, expect literally months of this mud-wading feeling after your first
book <g>.)
Save it for tomorrow. Not every day can be a day of winning in the saddle. Sometimes a long slow Level 1 ride
is the best thing. Same with your head. You can't be inspired every day, and when you're feeling uncreative the best
thing to do is go for a walk, or knock off early and go home and read your kids some stories. That break in the
(stuck) mental flow is really effective.
Feeling the road. Preparation is great, but it can't tell you everything about the course. You have to be
prepared for surprise attacks, punctures, bonking, dehydration, on-the-fly collaborations against you. Same for
programming: network problems, co-worker having an emotional day, office politics, unexpected bugs. The surprises
can come in all guises. Know that your work's always going to surprise. (It is, after all, the most complex activity
humanity has ever been involved in, so you musn't feel bad if it kicks you in the head every now and then.)
Turning into the wind. Similar, but more predictable, than the last point: most races aren't run in a straight
line with a tail wind the whole journey. You're far more likely to be switching directions and hitting that head
wind several times until you get home. Same with programming. You can be flying, feeling like a superstar reifying an
elegant design into beautiful code, and then you hit the next part of the course and Bam! it's a headwind (usually
the Win32 API ;/ )
Hitting the hills. Hills, curse 'em. The best feeling on two wheels is when you're climbing on the rivet,
that point of perfection where you're operating at your aerobic limit for minutes, even hours, at a time. And the
worst feeling is when you're fighting the bike up an uneven climb and you just can't get a rhythm. Out of the saddle costs you an
extra 10bpm and hurts your back; in the saddle tortures your quads and hurts your back. But the hill's there, there's
no TDF-style crowd to buoy you up and give you hidden pushes, and you've just got to grind away on the little ring.
Some days at the office are just like this. Your going is slow, and not because you've hit a headwind, or are tired,
or didn't do your research. No, some things are simply damned hard, and you've got to grind away. Remember, a cyclist
never gets off on a hill, and a programmer never quits on a slog.
Beware car drivers and other menaces. This'll have differing impact depending where you live in the world. If
you're fortunate to live in the south of France you simply won't relate, because the drivers there treat you with
such respect and forebearance it actually makes you wonder whether there might indeed be a hope for humanity. However
if you live in England, you'll be used to being abused for occupying narrow roads to the cost of 10s out of the
time that a car driver was hoping to spend impatiently idling in neutral at the next set of traffic lights. And if you live in
Australia you'll be almost used to being the deliberate target of utter nerfals who simply want to kill you. (I've
never ridden in the USA, but I've heard it's somewhere between those two lamentable points for the most part;
Lance Armstrong, six-time TDF champion and arguably the fittest man on earth for the last decade, has written that
truckies in his native Texas have made all kinds of non-too-subtle attempts to bring his record-breaking career to a
premature end.)
So, what does this have to do with computing? Well, nothing really, I just wanted to have a whinge about car
drivers. As an occasional car driver myself - when I can prize my prize away from my wife - I would have to say
that I just don't get what the rush is. There's always another set of traffic lights to slow down for. Put a De La Soul
album on and take it easy!
If there is a programming analogy to be made, I'd say that it's to slow down, and try and leave the panic out of your
life. As PJP mentions in the editorial for this month's CUJ, you can only keep up a frenetic speed up for so long, and
then your body has its revenge.
Teamwork and individualism. Cycling is a very curious mix of individual talent and teamwork. Apart from the
legendary Greg LeMond in the 1989 Tour, the number of successes absent a decent team can be counted on one hand. If
you don't have teammates to bring you food and water, control the pack, chase down breaks, shield you from the wind,
push you along while nature calls, give you an extra jersey when itis cold, then your individual brilliance is going
to account for precisely nothing. Most software engineering activity is much the same. You need people with
individual talents, but you also have to work as a cohesive team. Otherwise, you just end up with a lot of brilliant
partially implemented ideas, and nothing to show for it.
Don't flick the pack. This one's simple. You will quickly get to hear about it if your bike handling skills are
such that you cause waves in the pack, or you don't warn your teammates and competitors alike about potholes, oil on
the road, and other dangers that can impact you all. Same goes in programming. Members of the same team should share
knowledge; harbouring it buys you nothing. And organisations need to share information at a higher level,
and not go off into deliberate dialecticism of common standards for short-term reasons.
Don't spit into the pack. Another simple one. When you need to free up your passages from your body's reaction
to intense and sustained airflow, you'd better make sure it doesn't hit anyone. Same goes in programming. It's sometimes
a high intensity thing that we do, and people may be deeply invested emotionally in their points of view, so try your
best not to make unnecessary enemies. Of course, it can be hard to do, especially via electronic media which allow
you to communicate with people from all countries absent the usually highly necessary non-verbal communications. That's
why, however much you may experience cultural-cringe in doing so, those little emoticons can be so useful. <g> ;)
Take it from one who's a citizen of two of the most sarcastic countries on earth: Making ironic cracks with your
correspondents without using emoticons can get you in all kinds of trouble.
Get off the beaten path: Tarmac, Trail and Track are all good for you. Many top cyclists on the road have
come from the track, or from mountain biking, and vice versa. And many also cross train on the other disciplines at
different times of the cycling year. My good friend Gary Penningyon (see below) gave me some great advice many
years ago: a good programmer needs to be expert in one compiled language and one scripting language, and should
have a smattering of experience in a number of others. I couldn't agree more, although I'm yet to be anything like
expert in my favourite scripting languages, Python and Ruby. But I can aver that having experience of multiple
languages helps out with use of any/all.
Hard work is the watchword - you gotta love it. Cyclists are among the hardest working of all sportsmen, some racing up to ~250
days a year. And programming, by its addictive nature, also tends to find us sitting on our backsides for as many
hours during the year. Of course, the difference is that one group's honing their motor skills and their aerobic and
anearobic systems, and the other's not. But despite that, software engineering is something that involves a lot of
commitment, for which you have to love it. And we do, don't we?
Endnote
I was surprised when I first had the idea to write this blog, quite some months ago (mid 2004), to see
that the blog of one of my friend Gary Pennington had had the same idea. I've not yet read it, as I
wanted to put my ideas out without any cross-pollination, but am going to do so right now. It's
at http://blogs.sun.com/roller/page/garypen. Let
me know what you think of either/both.
Talk Back!
Have an opinion?
Readers have already posted
6
comments
about this weblog entry. Why not
add yours?
RSS Feed
If you'd like to be notified whenever Matthew Wilson adds a new entry to his weblog, subscribe to his RSS feed.
Digg
del.icio.us
Reddit