"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."
I'm not sure I understand what this means. It sounds to me like gumption is a lack of foresight and planning. As I get older this sort of state is ever more difficult to achieve. And for the most part I avoid it.
I used to tackle problems by opening up my editor and getting some code in there as soon as possible. Before I had even fully considered the problem and its base cases I was throwing code at my compiler/interpreter and working out mistakes as I went. I could spend hours like this without being interrupted or missing a beat. I've come to believe that some people call this, "flow." I call it, "shotgun programming."
These days I find myself spending more time writing notes and thinking about the problem before I put my hands on a keyboard. I know the base cases before I begin to think about how to implement the solution and I write tests for them before anything else. In the end I write far less code than I used to and fix fewer bugs. But I never really feel like I am in the flow or programming with gumption.
How else can one avoid, "gumption traps?" I guess I've left one too many assembly rods on the shop floor over the years to be bothered to rush into it.
Isn't your method of working exactly what he described in the entire essay? By being in front, he means getting into the careful, thoughtful work instead of the fake-thoughtful work of obsessing over which library to start using, staring at code without actually thinking about it, etc.
I thought perhaps it might be but the traps he discusses near the end don't seem to agree.
Careful planning and consideration would have avoided the mistake of forgetting the rod in the first place. The engine analogy is weak but in software you'd write the checks and balances into your process so that you couldn't forget the rod (good design principles, automated software testing).
Perhaps it was also the wording in the opening paragraphs which threw me off the most. I often find myself drifting off into space while I whittle away the problem in my head. Then I get down to the base cases, tests, and once I am satisfied I will begin writing code. The doesn't sound to me like like being at the front of anything.
I think I get the gist of it but I just wasn't clear one way or the other which way the author was leaning.
I think I agree with the other poster. You might have misunderstood. Namely, "... watching to see what's up the track and meeting it when it comes. That's gumption." seems to be at odds with your interpretation that "gumption is a lack of foresight and planning."
I definitely don't think the OP was advocating shotgun programming (although I don't think the OP was explicitly advocating against it either).
I read "The Art of Motorcycle Maintenance" and Gumption was the thing that stuck with me the most as well. I'm glad you picked up on the same point I did. I think Gumption is just the act of applied inspiration. Much the same how 37 Signals says "Inspiration is perishable", for me; Gumption is the day to day. It is taking the inspiration and the clarity and acting on it.
Gumption seems related to the idea of flow from the book of the same name. Being aware of your state of mind and staying totally focused on the task at hand enables you to truly enjoy your work. I think it's time to read Zen.
I had to read Zen for a operations research course in college. I hated that book, but I do remember the professor beating over our heads this idea of gumption.
"To create code you will require expertise; this is readily available on StackOverflow. But without gumption, there can be no code or product." Perfect.
I think I've read ZatAoMM 3 times, admittedly the last time was >8 years ago. I didn't even remember "Gumption", it certainly did not seem to be a major theme of the book. It is very interesting to see other people's insights into a book especially when they're so divergent from your own. I guess I should read ZatAoMM and Lila again. :)
Gumption is what I remember the most about ZMM. The way I read it, the concept of Gumption felt like the backbone on which the rest of the book is built.
That and "Kulturbearer". :-)
Great post! Guess I'll have to include a section on Gumption in my book. Thanks for the idea.
Anyway, I have now heard about the zen of motorcycle maintenance so often, I'm starting to think I should read it even though I have no motorcycle, no workshop and as much practical skills as Clarkson.
It isn't really about motorcycle maintenance. Pirsig uses that as a common example in various places throughout the book. Its actually a philosophical novel, the subtitle is "An Inquiry into Values"
His later work Lila - is similarly subtitled "An Inquiry into Morals"
Great Post!I must absolutely read this Zen and the Art ...
Also, I have never played tennis but I read the book 'The inner game of Tennis' (W. Timothy Gallwey) and it was a very enlightening experience for me.
It seems some of these books somehow use the subject matter purely as a parable or metaphor that is so powerful, and they shine a light on a very core aspect of being.
I recommend the 'inner game of tennis' to anyone , even if you never hit a single ball in your life ...
I've read it several times, the first time being in highschool and the most recent being a few months ago. As I get older I've read it with a bit more skepticism about the novelty of his overarching ideas and the rigor of some of his reasoning but I always find the book full of valuable ideas and interesting food for thought.
Did the people from the 70s forget how to read now its 2013? ;)
I was born in '79 so although I was alive in 70s I wasn't really part of the whole free love movement or anything :)
I'm not sure its even that popular of a book for that cohort... I mean its a philosophical novel, what's the size of that market ever been?
There are certainly some things addressed in the book that aren't as applicable in a modern setting but the main thrust of the book investigates the intrinsic value or quality of things - That should always be applicable to future generations.
I read it first when I was in my early 20s. I seem to re-read it about every 5 years. Though some of the language is dated, I find the philosophical musing important enough to take the time to refresh in my mind. Finally, the "me" that I bring to the book is different every time I pick it up for the next re-reading...which is to say, I find that I relate to the text differently over time.
I just tried to read it, and had to quit when it started spouting all the pseudo religious advice as fact, and as a replacement for scientific inquiry.
When I read it, I was a young teenager in the 2000s. It was engrossing and mind-expanding, though perhaps I was more interested in 70s ideas than most.
Call it bravery, or confidence, but it is absolutely essential to making progress in anything. You can see its antithesis in bad code. Bad programmers leave old code commented out instead of deleting it, lacking confidence that they understand the task well enough to know that their new code performs sufficiently. Bad programmers copy pasta instead of abstracting and reusing, lacking the bravery to change code that works and potentially breaking it, lacking confidence to know that they can fix it.
I tell all my intern intends to "code forth bravely".
I'm not sure I understand what this means. It sounds to me like gumption is a lack of foresight and planning. As I get older this sort of state is ever more difficult to achieve. And for the most part I avoid it.
I used to tackle problems by opening up my editor and getting some code in there as soon as possible. Before I had even fully considered the problem and its base cases I was throwing code at my compiler/interpreter and working out mistakes as I went. I could spend hours like this without being interrupted or missing a beat. I've come to believe that some people call this, "flow." I call it, "shotgun programming."
These days I find myself spending more time writing notes and thinking about the problem before I put my hands on a keyboard. I know the base cases before I begin to think about how to implement the solution and I write tests for them before anything else. In the end I write far less code than I used to and fix fewer bugs. But I never really feel like I am in the flow or programming with gumption.
How else can one avoid, "gumption traps?" I guess I've left one too many assembly rods on the shop floor over the years to be bothered to rush into it.