Strong, Not Perfect
Confession: Like Chidi from The Good Place, I am a person who often suffers from decision paralysis. As Chidi failed in life to make ethically-perfect decisions, I often find myself hampered by perfectionism.
According to the StrengthsFinder inventory (I’ve had to do this thing many times for different jobs), “Input,” as defined below, is one of my top strengths:
People exceptionally talented in the Input theme have a need to collect and archive. They may accumulate information, ideas, artifacts or even relationships.
My need to gather lots of information to make the best decision certainly helps me make informed decisions; and of course, it fuels my desire to constantly learn (which ultimately led me to this career). At other times, it hinders more than helps me and causes an endless cycle of information-gathering in pursuit of a perfect answer or option, until I feel like this:
Case in point: a few years ago, I spent weeks evaluating and comparing two different half marathon training apps, comparing their features and reading countless reviews of them online, before ultimately settling on one. In hindsight, it’s ridiculous that I spent so much time on a decision of such relatively small significance.
Decision paralysis creeps up on me in my work in tech, too. It took me several months to redo my personal site, partly because I was very busy moving across the country and settling into my first full-time engineering job, but also because I went back and forth on tiny design details like fonts and link colors and waffled between a .dev and a .codes domain. Late last year, I posted this on Twitter:
When I finally deployed my personal site in early April of 2020, it was with the knowledge that it was almost where I wanted it to be. There’s a long list of things I want to improve: I could have formatted the blog post listing more creatively, I could have tried more combinations of fonts, I could have implemented a more visually-appealing list of skills and tools on the work page, I could have done more research into CSS transitions for toggling light/dark mode, I could have spent more time understanding GraphQL deeply, I could have built things from scratch instead of using Gatsby plugins . . . you get the idea.
I’m still not super satisfied with all of the things on that list. So how did I overcome the indecision caused by the pursuit of perfection? Here are some things I’ve been trying to keep in mind.
Focus on Strong, Not Perfect
One of my colleagues in the education non-profit world often used the phrase “strong, not perfect” to describe the desired outcome of a project, knowing that we could never write a single curriculum that met the needs of every one of our over 10,000 students. We did, however, design something really good that we believed, based on research, would resonate with as many students as possible.
I’ve worked hard to apply this mantra to my work in tech. I used to worry about covering every edge case and fretted that I wasn’t optimizing code as much as possible in every PR. While there is, of course, value in doing one’s due diligence, I don’t think it’s worth it to allow perfectionism to hold up good work. Now, I focus on doing my research, opening a PR with well-functioning and tested code, and knowing that I’ll likely get helpful feedback to make it even better.
Similarly, I could have outlined solutions to the long list of things I want to improve in my site, then started working on all of them before deploying. That would have meant a significant delay in having a live site, though. So instead of obsessing over relatively minor decisions (i.e., things the site could function without), I decided to go ahead and deploy something good and focus on the nice-to-have details later.
Define “Good Enough”
Another thing that has helped me is setting clear expectations for what I hope to accomplish with a feature. What does completion look like? When does my work on one thing end, and another begin? What is “good enough”?
The answers to those questions come in the form of acceptance criteria in every ticket I work on at my job, and I’m lucky to have great product managers on my team who I can go to for clarification on the exact scope of a ticket if needed.
But what about personal projects? For this site, I wrote mini “tickets” for myself with bare minimum acceptance criteria to achieve to ensure I was making steady progress. Completing these empowered me to move on with things in a good-enough state, even if they weren’t exactly as I envisioned.
Improve in Iterations
That last point leads me here: the importance of iterating to make incremental, yet steady, change. Accepting that I can do multiple rounds of improvements on a thing helped me just get started instead of being paralyzed by the desire for perfection.
At work, we build large features iteratively, laying the groundwork for a feature in one ticket and improving it with subsequent work to eventually achieve the vision for the project. With my site, I used my definition of “good enough” to get it live, and have been making small tweaks to it when I have time.
These three ideas have allowed me to make more progress on personal projects lately than I have in a long, long time. Some of the ideas came from my career as an educator, and others are lessons learned as an engineer.
Don’t get me wrong - I am not advocating for submitting half-finished code at work or not putting in time and effort. But things don’t need to be utterly perfect for them to be good, and something good can be improved. It can be scary to let go of the desire to churn out perfect projects or perfectly optimized code, but in a way it is also liberating to let go of unrealistic expectations.
