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