Doing Hard Things is Simple, Unfortunately

This site recently went through a redesign, and when planning out how I wanted it to look, I intended to have two sections: about me and a blog. The focus was a place where I could publish my writing with only a little bit of flair. I deliberately kept it simple, detesting GSAP animations, frameworks, or anything else that regularly shows up on Awwwards. With $2 in OpenRouter credits and a cleared morning schedule, I should have been ready to start writing that afternoon.

Early Optimization

Of course, when you try to start writing, you end up with a remarkably clean kitchen, and I spent the next few weeks cleaning my digital kitchen. I started optimizing the website, running Google Lighthouse against any updates that I pushed, learning about SEO and Google's Core Web Vitals, and running GitHub Actions to automatically publish an updated sitemap. I implemented Umami and Vercel Analytics to track how users were interacting with the site and where they were lingering. I redesigned for mobile users, tried to steal UI features from Arc, and made sure my OpenGraph links were eye-catching. Of course, I couldn't be bothered to write in Word, and I shelled out $40 for iA Writer, but not before trying Ulysses, Scrivener, and Cordelia.

Keep in mind that all this work was for a website that had fewer than fifty words, two links, a photo, and no blog posts. I was acting like the site needed to be ready for 100,000 users visiting at once or for the Economist's editor-in-chief to stumble across my writing and beg me to write an opinion piece. Hell, I wasn't even designing for 100 users: as of writing this, a total of six people have visited the page, all of whom I had sent a direct link to.

A Recurring Pattern

This isn't the first time this has happened to me, and I'm not the only person this has happened to. One time, my team spent several days discussing the merits of Google's Python style guide versus generic PEP 8 to avoid starting a looming project; this pressing issue had to be settled before any code could be written. When a new semester started at university, I would spend the first week setting up Linear to manage my homework. I was using the same service that OpenAI and Vercel use to manage projects used by billions of people to manage my introductory economics class's homework. It's like using an atomic bomb to eradicate a housefly. More bizarrely, I knew that level of planning was pointless. A simple notebook and calendar would have done the trick and taken 1/1000th of the time.

Your Brain on Planning

Knowing this meant nothing because of a condition I call the "Productivity Trap." The same idea has been called many things: overthinking, analysis paralysis, decision fatigue. I like my name for it because rarely does someone fall into such a situation because they don't know what to do; they fall into the trap because they don't want to do it.

Planning feels really good for two reasons, both psychological. Our brains are prediction machines, and any open "loops" create a low level of unease. Creating a plan is a signal to ourselves that the loop is closed and we can forget about the task until it's time to start. The second reason comes from the dopamine that is released from anticipation. When planning out a project or task, the brain simulates the required effort and the reward upon completion, making it feel like you've completed the task.

I've had innumerable life goals and career aspirations mapped out to a weekly plan, ready to take the next step to "change myself forever." After all that strategizing, when my head hit the pillow, it felt like I had accomplished something that day. Obviously, since I'm not a CFA, a software engineer at Apple, or the next great industrial designer, these plans either fell through or never even started. That's not a fault of mine or yours if you're empathizing with this -- it's human physiology to get excited about a future state. After all, it's what got us from smearing dandelions on cave walls to planting flags on the Moon.

Just Get Started

In his 1974 paper about the merits of the go-to statement, Structured Programming with go to Statements, Donald Knuth wrote, "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." While software engineers are familiar with the quote, it applies everywhere. The brain is wired to fence-ride and wait for the perfect moment to start. What I've learned after reflecting on the productivity trap is to just dive in. Ditch the project's equivalent of Linear and Umami, and start with the notebook and calendar; only when the project has proven itself to be in that 3% of time should you take your eyes off the primary purpose.