Addiction

I am an addict.

Chances are, if you’re reading this, so are you. My addiction is not to any chemical substance, but I believe the symptoms are very much the same. When I satisfy my addiction I find myself only wanting more. It makes me feel good, in control, powerful. Anything that blocks or interrupts it makes me irritable. In the throes of my addiction I lose track of time. And, ultimately, it hurts the people around me. Worst of all, there is no end of people who are ready, willing, and able to take advantage of my addiction.

My addiction, is to “flow,” the mental state that the software industry has elevated to such a degree that it’s almost seen as a unique attribute of exceptional software developers. Which isn’t true, of course; to a large extent it’s a marketing ploy that, like the source of many addictions, is promoted largely by its devotees.

Whoa. Back up second. Isn’t “flow” the ultimate goal of every software developer? A mental state of such concentration that the “flow-”er can solve problems and write code that is beyond the reach of mere mortals? To some extent, yes, and that’s a big part of what makes it so compelling. But, that’s not the whole story.

“Flow” boils down to a simple idea: the ability to hold many, many aspects of a complex system in your mind at once. Software is complex, and writing software requires understanding and managing that complexity, but software isn’t unique as a process that requires this sort of mental discipline. Skilled chess players keep a mental picture of pieces on the board, as well as a series of potential future states of those pieces. The more talented the player, the more future states they can process and consider at once. It should come as no surprise that people enjoy playing chess, similar to how software developers enjoy working with complex systems.

But, writing software is not a game, and differs from chess in one far more important aspect: chess players work alone, while software developers work as part of a team. Working on a software project is like having ten chess games going simultaneously, with ten separate players, and with the goal of winning every match while also having a specific combined number of pawns remaining at the end of all games, across all ten boards. No Grand Master who has ever lived, or will live, can guarantee the end-result of another player’s game. At least, not without a lot of interaction.

On software project we have to consider the work of our peers. “Flow” isolates us from others, when we need to be focused on interaction. “Flow” helps us focus on our own work, to the exclusion of helping others learn or grow. “Flow” encourages hoarding of knowledge that our teammates may need in order to make decisions. “Flow” hurts the overall goal, while making me feel good about my own work.

Now, you may think this is tongue-in-cheek, that I’m using addiction as a metaphor, or a hook to make a tangentially related point. I am not. I don’t want for a second to diminish addiction in any form by some spurious comparison. I have never been addicted to alcohol, or heroin, or anything similar, but I feel a pull that seems like what I imagine people afflicted with chemical addiction feel. I’ve been a devotee of pair programming for many years; I’ve had the extreme fortune of working for companies that support pairing for over a decade. I feel — I know — in my bones, the value. Yet, given an opportunity to work alone, unvexed by questions about my thought process or my conclusions, I feel an intense draw to retreat into my own thoughts and work unencumbered. I know, through experience, that I will write inferior code without a collaborator, without someone questioning my ideas — without a pair. Yet, I want it. I yearn for it. Like a drug.

So, if you write software, please, I ask you, take a moment to consider your motivations. Do you work the way you do because it truly provides the most benefit to your team? Your customers? Your company? The software industry as a whole? Or, are you satisfying a personal need — one you may not even consciously consider — at the expense — even a little — of the people you work with?

If you’re honest, I think the answer might surprise you.