Gumption is the willingness to tackle a problem, backed by enough initiative and resourcefulness to believe you can work it out. Developers depend on it. We start with something that doesn’t work—or doesn’t exist—and we keep at it until it does.
But that willingness to continue needs care to survive. An interesting problem can become a frustrating afternoon, and a few frustrating afternoons can change how we approach the work. When we continue to struggle, we might hesitate before touching a particular module. We might put off an upgrade. We could stop following an idea simply because finding out whether it works feels too expensive.
In Zen and the Art of Motorcycle Maintenance, Robert Pirsig describes gumption as the energy that makes a difficult repair possible:
“Gumption is the psychic gasoline that keeps the whole thing going.”
The mechanic needs more than knowledge of the motorcycle. They need enough curiosity, patience, and confidence to keep working when the repair becomes difficult. Pirsig calls the things that drain that energy gumption traps.
I find this a useful way to think about the environments we create for software development. We spend time discussing developer productivity, but less time discussing what makes someone willing to take on the next problem. The condition of the codebase matters here. So do the tools and the time it takes to find out whether a change worked. If continued success and progress is a flywheel that spins with momentum, then running out of gumption is surely the opposite of that.
Confidence to make a change
Working in a codebase without reliable tests means carrying uncertainty through every change. Did I fix the problem? What else depends on this behavior? How much of the application do I need to check by hand?
That uncertainty can make even a small improvement feel risky. Eventually, leaving the code alone starts to seem like the sensible choice.
Useful tests give us a way to move forward. They help establish what the code does and tell us when we’ve disturbed something we intended to preserve. Unit, integration, and end-to-end tests can each contribute, but the value comes from whether we trust them to catch meaningful mistakes.
A test suite that fails unpredictably or leaves us guessing about the cause can become another gumption trap.
Code we can find our way through
Before changing code, we have to understand enough of it to make a decision. Clear names, visible dependencies, and a coherent organization make that possible.
When the structure is confusing, we spend our attention reconstructing the system. We follow a value through several layers, discover an exception to the apparent pattern, and lose track of the change we came to make.
Some problems are inherently complicated. But every unnecessary complication takes attention away from the problem itself. Making code easier to navigate preserves some of that attention for the work we wanted to do.
Feedback while the idea is still fresh
There’s a satisfying rhythm to making a change, checking it, and adjusting. Short feedback cycles let us keep the question and its answer in our heads at the same time.
Slow builds, awkward local setup, and long waits for CI interrupt that rhythm. We switch to something else, then have to reconstruct our reasoning when the result arrives. Each attempt costs more than the time on the clock.
Fast feedback makes another experiment feel affordable. That matters when the first approach doesn’t work, or when we’re unsure enough that we need to try something before we can explain it.
Protecting the willingness to try
I think protecting gumption belongs in our decisions about engineering maintenance. A clearer module, a reliable test, or a faster build can improve the experience of every developer who comes through afterward.
When a team keeps avoiding an area of the codebase, it’s worth asking what happens when someone tries to work there. Where do they lose confidence? What makes a small change feel like a commitment? How long before they can tell whether they’re making progress?
Those are useful places to spend maintenance effort. They’re where someone’s willingness to try is getting used up.