All Articles

The Downside of Grit

Much has been written about the merits of “grit,” that intangible characteristic of personality which can drive a person through any challenge.

It’s been studied academically, with a 2014 paper by the National Institutes of Health soundly praising its connection to success in all endeavors:

Grittier soldiers were more likely to complete an Army Special Operations Forces (ARSOF) selection course, grittier sales employees were more likely to keep their jobs, grittier students were more likely to graduate from high school, and grittier men were more likely to stay married.

It took a tiny amount of grit to finish this article and publish this blog, and if you’re reading this, that means it paid off. What you’re not reading or using are development projects I poured more effort into over the span of years.

It took me a year to truly appreciate the difference. Before 2018, I had never found occasion in my life to believe that more effort dedicated to an endeavor would not result in a better outcome. That’s not to say I could do anything; often I felt that the amount of effort required wouldn’t be worth what I could expect in return, or that some goal would require much more effort from me than from someone else. However, no matter the task: more push == more success. Easy enough.

In 2018, I left the Army and all of its schedule-filling make-work and was able to throw myself at my interests full-time, in development work for a tech company and at home. I had been coding on the side for years, but finally I could justify it with a paycheck and not just as a hobby. At 28, I felt like I had lost some prime years to the Army, and was driven to catch up via a non-stop fury of learning and hands-on practice.

So, 8 hours a night after work, and 14-16 hours a day on the weekends - with some breaks for sanity and a healthy relationship - I dedicated myself to a number of intertwined projects. A good example was an application I dubbed Clarity. It would automate pretty much every routine aspect of life at home, like Google Calendar and Epicurious and Runkeeper and Accuweather and (name your app here) rolled into one web application. It’s harder to find a domain you know better than your own daily life, and what better to optimize?

It took a couple weeks to lay out the foundation for the application, which was expected enough, especially as I learned the frameworks I was working within. Long after, I still had nothing to show for time spent. Work day after work day, I came home, bent on delivering at least one feature to my only customer — myself — only to stay up past midnight wrangling some bug in Ruby or Javascript. This continued throughout the summer, putting me in bed later and later and leaving me more and more disappointed.

I took a break in late summer, then scrapped and rebuilt the backend in Node, which happened to support my use case better and had less of Ruby/Rails ✨magic✨ going on. Better yet, TypeScript brought type safety and top-notch IDE support, and a graph database (Neo4J) significantly reduced the representational gap I had felt using Postgres and Mongo. Modeling my use cases became much more straightforward, and a healthier share of my time went into actually chopping down the tree rather than sharpening the axe.

Still, my girlfriend would laugh at me when I would tell her “It’s almost there, it just needs a little more work!”, because she had heard it so many times before. I had a 1-inch stack of notecards underneath the monitor, with a feature or milestone on each. After a little more time, I put the project on ice in favor of more exciting adventures: a 4-month trip overseas and Citizen Dispatch. I rued the weekends and evenings that I had sacrificed to this quixotic application!

The non-stop challenges of that South American trip taught me, more than anything else, that some problems have a top speed to a solution. Like sprinting through water, pushing harder may not get you there any quicker, but it will be a lot more exhausting to try. That effort is better spent figuring out how to drain the water or get around it.

All the while, Clarity stayed in the back of my mind, where I worked out solutions to some of the architectural challenges I had been dealing with while on sunrise hikes in the mountains of Patagonia or waiting for a mechanic to fix our van. Other, smaller-scope projects in the meantime improved my techniques and toolkit.

I opened up the project last weekend out of curiosity. I was happy to discover that the code was neat and decently documented, with a good suite of working tests. In only a few hours, I reworked whole sections, passing milestones I had worked on for weeks last year, but with far less effort and code.

Looking back, grit was the enemy. If, instead of compelling myself to sit and work through a devious bug for hours or days on end, I had spent a small amount of time adding tooling to make those bugs more obvious, I would have claimed back all that time, with more to show for it.

On the micro scale of this project, I learned:

  1. The irreplaceable value of a well-tuned development environment, to include a pre-configured debugger.
  2. Debug test-first. Never guess at the problem, and especially not in REPL.
  3. When progress feels slow, value the delivery of a small feature over the groundwork for a large one.
  4. Use a break timer application, which seems tacky - I know when I need a break, right? - yet is so effective. I’m too naturally stubborn to do it on my own - just five more minutes!!

On a macro scale, I learned that there’s a feeling about the difficulty of a problem that shouldn’t be ignored. If it’s something that you’ve pinned down exactly, and that can be worked through in an hour or two, then some elbow grease and a good Pandora playlist might do the trick. If it breaks out of that scope, or you find yourself getting frustrated, stop. Don’t let grit win. Step back and think:

  1. Do you have all the information you need to solve the problem, or are you guessing at what the problem is? → Get more, or better, information
  2. Do you know what problem you’re solving, exactly? Can you imagine the whole solution in your head? → Break it down into smaller problems. Have sanity checks to test your intermediate solutions.
  3. Are you burning out? → Step away. If you’re bent on being productive, find another thing to produce that uses different skills, or go on a run. One hour of focused work pays off more than a day of forced labor.

Of course, this is old knowledge for many. As Jonah Lehrer wrote for NPR in 2012:

If you’re an engineer working on a problem and you’re stumped by your technical problem, chugging caffeine at your desk and chaining yourself to your computer, you’re going to be really frustrated. You’re going to waste lots of time. You may look productive, but you’re actually wasting time. Instead, at that moment, you should go for a walk. You should play some ping-pong. You should find a way to relax.

I wrote this in one sitting. Instead of reading it over, I think I’ll go for a run.