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