Gumptionology for developers

Having just finished "Zen and the Art of Motorcycle Maintenance" I find that the word "Gumption" has been rattling around my brain for the past week, sneaking it's way into my mindset as I go about my daily tasks.

"Zen and the Art of Motorcycle Maintenance," (ZAMM)  subtitled "An enquiry into values" was recommended to me as a great "Programmer book" - not a "Programming book", but rather one of the those more intangibly beneficial books that effect pause and reflection in the normally full-speed-ahead world of software development. A book that couldn't be further from the world of development yet somehow come across referenced in a bibliography or quoted in a presentation every couple of months. 

So I took the bait and jumped in, and really had no idea what hit me. I found myself sneaking in reading to get through the book - before work in the mornings - waiting in line - with an enthusiasm normally saved for Neal Stephenson and Douglas Adams.

The central focus of the book is the concept of "Quality" as a unifying principle for the world. Heady stuff. I'll leave the discussion on "Quality" in software development to more intelligent people than I, but there was one distinctly concrete idea that Pirsig dropped into near the end of ZAMM: The concept of Gumption and Gumption traps.

Of Gumption, Pirsig says:

 "I like it because it describes exactly what happens to someone who connects with Quality. He gets filled with gumption. The greeks called it enthousiasmos, the root of "enthusiasm," which means literally "filled with Theos," or God, or Quality. See how that fits? ( Loc. 4928 )

The programmer with an ample supply of gumption is easy to spot - he's the one for whom no problem is a boring problem, because we as developers can create our own gumption by solving boring problems in novel ways. Yes, tying together a rube-goldberg machine of Unix pipes is probably not the best way to solve a 10-minute data entry problem, but if it takes 9 minutes and let's me learn more about AWK, it should get counted in the win column. (You can take this way too far, but good dev's skirt the line between making boring problems interesting and making problems out of non-problems.)

But Gumption is easy to lose. When the job becomes rote and there's not a creative spark left in the daily grind, work suffers. Life suffers. And developers will either die a little inside or spend that creative spark on side projects and leave nothing for the 9-5.

So in the same way Pirsig described the Gumption traps that hinder Motorcycle Maintenance, here are the Programmer Gumptions Traps I've come across (imagine a PHB saying the following to get in the spirit)

"This is the way we do it" - There's nothing quite as dehabilitating as being told, when proposing a novel solution to a problem that "this is the way we do it, this is the way we've always done it, this is the way you're going to do it" It literally can deflate the life out of a developer in two seconds flat. That doesn't mean every programming-language or framework-related whim should be catered to, but it does mean that people making the technical decisions in a company should have the technical knowledge to make them and be able to make them on solid technical grounds. Nothing kills creativity quite like being told that whatever flawed methodology that last guy in your position came up with during a caffeine induced epiphany is one of the 10 commandments of company methodology. Not allowing any discussion on the methodologies a company uses is a sign that the company isn't doing things for the most technically sound reasons.

"Implement this UML" - As I've written about before Implementation matters - it's not just a matter of taking some designs a software architect wrote up and just writing the simple code that makes it actually run. Real software doesn't work like that, and code implemented to fullfill the requirements of waterfall design usually jump through a number of hoops to account for design flaws that could have been weeded out with a few feedback loop driven iterations.  

 "This is the best hardware we can afford" - Programmers are expensive, and giving them sub-standard hardware (or less than 2 monitors) makes absolutely no sense from both a financial and a gumption perspective. If your developers are sitting around waiting for tests to run or libraries to compile, they aren't working. There's a certain length of time that sites as the cut-off time for the "flow" that transcendent state where the developer and machine becomes one. If you're machine response time is less than that magic number, you'll be able to keep razor focused on that task at hand. If it's above that line, your hand will subconsciously hit Ctrl-t, bring up a new tab and type in slashdot or reddit.com.

 Keeping your Gumption, being allowed to bring something of Quality into the world is one of the greatest feeling in the entire world. If you're working for yourself of managing developers, make the world a little bit of a better place by paying attention to the Gumption traps that you're laying for yourself and your developers.