Programming is a loser's game
I recently read this essay which discusses changes in investment strategy in the 1970’s. In it, Charles Ellis talks about the difference between a winner’s game and a loser’s game1.
Expert tennis is what I call a Winner’s Game because the ultimate outcome is determined by the actions of the winner. Victory is due to winning more points than the opponent wins – not, as we shall see in a moment, simply to getting a higher score than the opponent, but getting that higher score by winning points.
Amateur tennis, Ramo found, is almost entirely different. Brilliant shots, long and exciting rallies and seemingly miraculous recoveries are few and far between. On the other hand, the ball is fairly often hit into the net or out of bounds, and double faults at service are not uncommon. The amateur duffer seldom beats his opponent, but he beats himself all the time. The victor in this game of tennis gets a higher score than the opponent, but he gets that higher score because his opponent is losing even more points.
…
In other words, professional tennis is a Winner’s Game – the final outcome is determined by the activities of the winner – and amateur tennis is a Loser’s Game – the final outcome is determined by the activities of the loser.
What does it mean to talk about winning or losing in programming? What does success look like? I think that is a hard question, which could probably fill several blog posts, but I think a good working definition for us is “producing high quality code2, either by oneself or as part of a team, that helps to solve some problem for an end user”. Based on this definition, it seems to me that professional programming is somewhat of a losers game, at least for most of us.
I will concede that perhaps in fast moving startups, or for those involved in bleeding-edge research, there is an element of succeeding by “winning points”. Developing a faster algorithm, or determining some incredibly innovative way to implement a feature may help you succeed. However, I believe for a lot of professional programmers, succeeding comes from focusing on not “losing points” - causing bugs or producing unfathomable code, for example3.
When we consider programming with this in mind, it highlights the importance of some of the less glamorous elements of our field as a viable strategy for success. As you approach your next project, ask yourself, how can you avoid losing?
-
Which itself was taken from the work of Simon Ramo in his book Extraordinary Tennis for the Ordinary Tennis Player. ↩︎
-
By “high quality code” I mean code that is clean, understandable and that produces few bugs in normal operation. ↩︎
-
There has been some discussion on this piece on lobste.rs and it has highlighted a point that I need to clarify. I am not trying to claim that programming is a game, but rather it represents a scenario where we are working towards a goal, and perhaps one of the best strategies for achieving that goal is to avoid actions that frustrate your attempts to reach it. In tennis, that goal would be to win the match and a strategy you can pursue is to avoid hitting the net, rather than focussing on trying to outsmart your opponent with a clever backhand. For programmers, that goal may be to produce high quality software, and a strategy to pursue is to be extra careful to avoid bugs, rather than implement some very complex algorithm. ↩︎