
Coding with gumption - robheaton
http://robertheaton.com/2013/03/11/coding-with-gumption/
======
agentultra
_"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.

~~~
1123581321
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.

~~~
agentultra
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.

------
erikj54
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.

------
scotch_drinker
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.

------
bwsewell
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.

~~~
cypherpunks01
That sounds like the worst possible book to read in a classroom! I can barely
imagine how furious Pirsig would be if he were pondering that happening.

I loved the book, for the record.

------
jamesk14022
"To create code you will require expertise; this is readily available on
StackOverflow. But without gumption, there can be no code or product."
Perfect.

~~~
jeffdavis
I'm beginning to wonder: is it possible to write inspirational, motivational
prose without making ridiculously false and insulting statements?

The author has clearly not found a way.

------
antoko
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. :)

~~~
shiven
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". :-)

------
endlessvoid94
There's a ton from that book that applies to coding. Highly recommended.

------
Swizec
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.

But I did once sew on a button. I was very proud.

~~~
antoko
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"

I highly recommend them both.

[http://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_M...](http://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_Maintenance)

<http://en.wikipedia.org/wiki/Lila:_An_Inquiry_into_Morals>

~~~
waterlesscloud
I wonder if people still read it or if it's mostly something for people who
were alive in the 70s?

~~~
falcolas
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.

But that's just my opinion.

------
mooreds
What a great great post. Sorry, no witty comments to add.

------
nu2ycombinator
This is a good self help programmer article.

------
moron4hire
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".

