Taming perfectionism with the programmer mindset

Until last year, if you’d asked me to describe myself in one word, I’d have said I was a perfectionist. Almost twenty years earlier, I lived out my perfectionism in university. During the first year of my studies, I had a lot of time on my hands. I spent most of it studying—to practice and perfect my newly acquired skills. My thorough work paid off. I was well-prepared for advanced courses and effortlessly landed a job as a teaching assistant. Besides, being known for getting excellent grades wasn’t bad either. After graduating with honors, I applied for a position as a PhD student.

During my PhD, I had a lot of time for research. I spent it working meticulously and striving for the most accurate results. This approach matched the field of mathematics I was involved in. The more precise my work, the more interesting my results. Again, perfectionism paid off. In fact, I believed academia was encouraging a perfectionist way of working. In response to the peer review process, I revised manuscripts until I was entirely satisfied. Only then would I submit them to a journal, hoping the reviewers would have at most a few minor revision comments.

Software engineers call this method the waterfall model. First, build until done. Then, publish in one big bang. It’s a true all-or-nothing approach. Even though I wasn’t familiar with this model at the time, this is how I treated my dissertation even more than my articles. I saw it as a single-shot publication that had to be absolutely perfect. I described my research and its foundations in excruciating detail. I traced every loose end to resolve or document it. I tuned my thesis layout to millimeter precision. Eventually, I was very satisfied with the result, but what had been the cost? I couldn’t have told you, because I couldn’t yet see how dysfunctional my perfectionism had become.

Nonetheless, transitioning to a job in industry was a relief. Before, I was used to working independently on open-ended research projects for years on end. Then, I joined a team of software engineers. We worked in three-week cycles called sprints, which each had a clear goal: adding business value. The contrast with my academic work could hardly have been bigger. One aspect of our agile way of working didn’t strike me until later, though. We didn’t strive to create perfect software. Instead, we focused on incrementally improving our applications as best as we could in the allotted time.

Looking back, I think that’s a brilliant approach. For one, we continually expanded our knowledge, gathered new insights, and became familiar with new tools. Consequently, our ideas about which solutions worked best steadily evolved. Additionally, our customers’ needs frequently changed, resulting in new or altered product requirements. Besides, the software we relied on received regular updates. So, we’d inevitably revisit our applications after releasing them. In other words, the perfect product satisfying all customer requirements didn’t exist.

Did perfection exist at all? Based on my background, I had certain standards. Through their experiences, my colleagues developed theirs. Sometimes, our views overlapped. In other cases, they differed. I began to see that my perspective wasn’t the only possible one, and decisions weren’t nearly as indisputable as I liked to believe. As a result, my requirements became less black and white, and my perfectionism softened. It further subsided when I considered my team’s collective output. What if a colleague created a new product feature that didn’t fulfill my standards? I couldn’t have built it while working on other tasks. So, it was better than having nothing at all.

I’m not advocating abandoning all standards. Neither am I saying perfectionism is inherently bad. After all, it took me a long way. But in terms of delivering practical results in a reasonable time frame, I’ve found pragmatism wins out over perfectionism almost every time. At the same time, pragmatism doesn’t rule out carefulness and scrutiny. I’ve found critical security issues and curious pieces of code that my colleagues never noticed or didn’t care to correct before our software product crashed. In every situation, a balance needs to be found between efficiency and quality.

Obviously, the approach of the agile programmer can also be a trap. If indefinite changes are possible after publishing some work, perfectionism can still run amok. In my personal projects, it sometimes still does. I keep editing the same piece of code, or I endlessly revise a passage of text. In such cases, I try to focus on what works. I first implement the minimal functionality I want my software to have instead of considering all possible use cases. Or I complete a rough draft of a paragraph before editing the lines I already wrote. Often, I also put out intermediate results. I push unfinished code to a public repository or publish a draft of a blog post. With these tactics, I don’t fall prey to perfectionism as much anymore.

Of course, digital media is much more malleable than print. A published article or thesis can’t be changed as easily as a piece of software or a blog post. But did I have to be so perfectionistic about my academic work? Many fellow scientists weren’t. They were satisfied with their results before I was with mine. They didn’t linger over their manuscripts as long as I did. Collaborative research may have made them more pragmatic. They may not have had my uncompromising attitude toward studying. In any case, academia didn’t demand my all-or-nothing approach.

But I needed that approach. I needed an environment to take my perfectionism to the extreme. I needed to experience that perfectionism cost me years and put an enormous pressure on my relationships. Otherwise, I wouldn’t have seen how dysfunctional it had become. I had to live out perfectionism before I could begin outliving it. Then, I could slowly start unraveling it and learn to appreciate pragmatism. After all these years, I’m still in the process of overcoming perfectionism. But I wouldn’t call myself a perfectionist anymore.