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 fully 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 more advanced courses and it was easy to get 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 the results I found. Again, perfectionism paid off. In fact, I believed academia was encouraging a perfectionist way of working. In response to its system of peer review, I rewrote manuscripts for articles 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, that’s 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 either 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 individually 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 struck me until later, though. We didn’t strive to create perfect software at all. Instead, we focused on incrementally improving our applications as best as we could in the alotted 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 of which solutions worked best constantly developed. Additionally, our customers’ needs regularly changed, resulting in new—or altered—product requirements. And, otherwise, the software we relied on received updates. So, we’d inevitably have to 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. Throughout their experiences, my colleagues had 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 absolute 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 that 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 crashed entirely. In every situation, a balance needs to be found between quality and efficiency.

Obviously, the approach of the agile programmer can also be a trap. If indefinite changes are possible after publishing some work, perfectionism could still run amok. In my personal projects, it sometimes still does. I keep editing the same piece of—already working—code, or I endlessly revise the same text passage. 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 it. Often, I also put out intermediate results. I push unfinished code to a public repository, or I publish a blog post draft. Both approaches prevent me from slipping back into perfectionism.

…