The David Foster Wallace of Software Development

I was trying to describe to somebody what it is that I do in relatively specific terms—a task that proved to be immeasurably more difficult than it should be—and I was casting about trying to find some way to convey what it is that I actually accomplish. I know what I do, I’m there for pretty much all of it, why would it be so difficult to summarize in any meaningful way (or, more to the point I guess, in a way that is meaningful to people that don’t do the same thing). After a series of increasingly embarrassing false starts and fumbled trail-offs, I staggered into a description that I feel is pretty close.

I am a story teller.

When I teach, I teach through metaphor and anecdote. Facts are fun—I love them and they are necessary—but facts don’t teach, they inform. Building a connection to facts, that is how we learn. That is how everyone has always learned (give or take a few). So rather than spew a list of concepts, methods, or algorithms at my class, I teach by using stories to build those connections. I tell stories about how I used this function wrong and it yielded a comical result. I talk about how mis-application of some idea ended in tragedy. We, as a class, explore examples of certain algorithms in our daily lives. We weave stories in order to build context for the facts in our minds and so that we can retain them.

I’m no less a story teller when I develop software.

When developing software, I have to be a master storyteller if I want to do a great job. I can’t tell the story, I have to help the customer—the end user—tell their story. I have to elicit from them how they think they do work; then I have to dig deeper and get them to convey how they actually do work. Through anecdote and informal chatter, I draw out context for otherwise disjointed facts like “I want it to be busier” or “the old way was just too clustery.”

Once I’ve helped the user build their story, I build my complementary story. I take what they have taught me and spin it into my own tale using code and graphics and requirements documents. I deal it back to them like a serial novel—pieces at a time in a way that allows me to gauge their reaction and keep their interest engaged. By the time they have seen the story in total, there should be precious few surprises (and among those precious few, only good ones) but a great deal of satisfaction with the denouement.

This is why it pains me to see the artless, engineering way to do requirements analysis. I cannot do my best work as I slog through a checklist of context-less questions and categorized facts. I need connection, and so does the client. In my experience, we are all infinitely better off sitting down together and listening to one another’s story with a checklist as a backstop to ensure that all bases have been covered than to rigidly adhere to a few hours of discovery done in a conference room.

So I’m not a software developer. I’m not an educator, a father, a manager, or a leader. I’m a story teller; I suspect that your software developers are yearning to be one too. Do yourself a favor and help them get there.

A Dewdrop Full of Struggle

A world of dew,
and within every dewdrop
a world of struggle
—Issa

This month marks 11 continuous years without drugs or alcohol. For the vast majority of you, this probably doesn’t seem to be an exceptionally huge feat—most people can take or leave drinking, and I’d wager that a sizable percentage of adults in this country have gone years and years without partaking in drug use. For me, however, this 11 years constitutes the longest period of sustained change I have ever managed. At this point, the length of time during which I haven’t been pissing-all-over-myself drunk or hitting-on-the-mother-of-my-date high is rapidly approaching as long as the length of time during which such events were regular occurrences. It’s a pretty heady feeling, this knowing that I am profoundly unlikely to wake up in a puddle of my own vomit next to someone I don’t especially know in a state of undress that inadequately conveys the full extent of the previous day’s adventures.

For obvious reasons, each year the approach of my anniversary comes with ponderous thoughts about the merits, features, and nature of change. Among drug addicts I first heard the phrase “nothing changes until the pain of staying the same is greater than the pain of changing” and never in my life has something sounded so ludicrous and so obvious at the same time. Of course we wait to change until staying the same is worse…but why would we be so short-sighted and stupid so much of the time?! Madness. Drug addicts are not known for their ability to plan for the future.

As it turns out, the same is true in most organizations—in fact, I could probably write a fairly lengthy article wherein I compare organizational behavior to that of a multi-year junkie (note to self, that sounds like a fun article)—most organizations act just as irrationally when faced with the formidable task of instituting change. Allow me to paint you a picture from my own life experience:

I was young—early twenties roughly—and had recently moved to a new town with my wife and young children. I immediately found the people who party and started spending my evenings at bars and house parties around town rather than with my newly displaced family.

Needless to say, that didn’t last long before my beleaguered wife, who undoubtedly hoped that this change in venue would result in a change in my behavior, finally had to put her foot down and threaten Very Bad Things if my behavior were to continue.

To my credit, I immediately put an utter and complete halt to my misbehavior. I quit drinking, I stopped hanging out with people after work, and I spent my nights and weekends with my family at home.

For about two weeks.

I quickly found my new life boring, and over the course of the third week, I had backslid almost completely. In fact, in many ways it was worse, because I had convinced myself that I had to lie and sneak time with friends and I would often drink a great deal at work and then drive home very, very drunk so that I could hang out with my family without hearing about my drinking.

This sort of whiplash-inducing overcorrection is something I’ve observed myriad times in countless organizations. A Thing That We Do™ is just not working—and a grand, sweeping plan is devised and put into place. It seems to largely alleviate some of the problems (in the best case scenario) or doesn’t seem to be having sufficient impact (in the more common scenarios), but in either case the strain of maintaining persistent change of such enormity—of such utter completeness—for any length of time proves too great and the members of the organization collapse back into old behaviors and patterns.

Why is this? Are they lazy? Stupid? Lacking in ambition?

Change—that is to say lasting, significant change—is methodical and slow. It’s glacially paced. It is the turtle winning the race slowly and steadily while the rabbit wears itself out with too much too fast. I’ve achieved over a decade free from actively pursuing addiction because I didn’t try to change everything at once. I triaged my life and changed the most pressing thing, and I have continued to do so iteratively for nearly 11 years now.

I do the same when helping an organization to change. Often the first thing I have to do is devote time and energy to reigning in the change enthusiasts who find themselves in a cycle of changing everything, then changing everything differently until everyone is so confused and disheartened that even modest change sounds horrifying and impossible. Only once that destructive cycle is quelled can the job of triaging and planning begin.

When you feel like change is failing you, stop for a moment and look around you. If you cannot list on one hand the individual changes that are being enacted and fingers left over, your glacier has run away and needs to be halted and adjusted.

Remember, several inches of snowfall can cover my town overnight and it is a thing of beauty; that same quantity of snow in one fell swoop would be a natural disaster. Stop making natural disasters.