Robert Heaton

Software Engineer /
One-track lover / Down a two-way lane

Coding with gumption

11 Mar 2013

The first and only mention of Gumption Theory in modern writing is found towards the end of Robert Pirsig’s Zen and the Art of Motorcycle Maintenance. The author sets out a plain and uncomplicated approach to attaining and maintaining the state of mind required to repair a motorcycle. It takes about 20 pages. And the first time I read it, I knew that this was what my engineering practise was missing.

In motorcycle maintenance, gumption is what allows you to take apart and reassemble the motorcycle in front of you in a better state than when you started.

In software, gumption is what allows you to assemble tokens in files so as to improve the lives of your users.

A person filled with gumption doesn’t sit around dissipating and stewing about things. He’s at the front of the train of his own awareness, watching to see what’s up the track and meeting it when it comes. That’s gumption.

Gumption is having heart. It is having enthusiasm, quiet confidence and commitment to your work and projects. It is being in tune with whatever you choose to have in front of you, regardless of the distractions around and within you. That’s gumption.

To create code you will require expertise; this is readily available on StackOverflow. But without gumption, there can be no code or product. At least not of any merit or worth. There are no manuals on how to preserve and expand your gumption. You will need to work this out out for yourself, cultivating equally both technical knowledge and the temperament to consistently apply it.

You will need to be well-versed in Gumptionology. This is the discovery and classification of gumption traps. Things that sap gumption. As a Gumptionologist you should have a working knowledge of the two forms that they come in - setbacks and hangups. Setbacks are external hindrances. Hangups are internal conflicts. They can both do you a serious mischief.

The most common type of motorcycle maintenance setback, and for now the only one that I would like to discuss, is the out-of-order reassembly. This trap occurs when a mechanic reassembles the parts of a machine in the wrong order, realising his mistake only when he finds a stray connecting rod-bearing liner lying on his workshop floor. It afflicts the engineer who realises that his nomenclature is off, or that he has used the wrong library for the task, or that his fundamental architecture is slightly faulty. The gumption drains from his cheeks and stomach as he realises the magnitude of the re-reassembly that must follow. There is nothing for it but to undo everything he has been working on and do it again, only this time with slightly more care and wisdom.

There is no inoculation against the out-of-order assembly. The best you can do is to be careful and try and discover it early. Check and double check before you make any decisions of significant gravity. Don’t go too far off the beaten track or the track that you initially set out on. Go slowly and deliberately. But, however delicate and considered your touch, something will always go wrong. And when it does, watch yourself for gumption desperation. This is when you try to artificially boost your gumption levels by hurrying the reassembly process to make up for lost time. This necessarily involves ignoring all of the known guidelines for avoiding gumption traps in the first place, and it is a rare occasion on which this works.

Instead, when you realise than a painful dismantling of your recent work is going to be necessary, it is time for a long break. You should use this time to take solace that you have learned something. Or, if you haven’t learned anything, that the reassembly will at least be quicker the second time around.

Motorcycle maintenance is fraught with hundreds more gumption traps, and engineering is no safer. To be an engineer you need artistries and skills, but you must also build and maintain the heart to use them. Gumption reduces short-term productivity hacks down to the core of what it is to intrinsically care about your craft. If you can study and know yourself and your own state of mind, even and especially when you are hurting and reeling, and if you can use this study to nurture and preserve constantly embering enthusiasm in the face of setbacks and hang ups, then you cannot fail to create great and serene things as a matter of course.

You aren’t just after a fixed machine, you are after peace of mind.


All of the above is directly inspired by Pirsig, some parts more directly than others.

Discussion on Hacker News ➜
Subscribe to my new work on programming, security, and a few other topics. Published a few times a month.
Follow me on Twitter ➜ RSS ➜