Perfectionism. I first heard this word from my piano teacher when I was young. As I would struggle to play through a piece of music, starting and stopping every few seconds to make sure every note was correct, she’d chide me, “Kendra, you’re too much of a perfectionist. Just keep going — it doesn’t have to be perfect.” This confused me. Shouldn’t I be trying to play the piece perfectly? As the saying goes, “Practice makes perfect.” So, what was all this piano practice for, if not to play perfectly?
This tendency toward perfectionism has followed me into my adult life. (If you’re into astrology, you would not be surprised to find out I’m a Virgo.) At times, my perfectionism has been my friend. It has been a driving force in my life, motivating me to switch careers, maintain a high GPA, improve my fitness routine, and be a reliable friend.
Unfortunately, perfectionism also has a dark side. I often struggle to meet my own high standards, leaving me feeling overwhelmed and anxious when things don’t measure up. Relationships and work projects — even simple tasks — all become battlegrounds for my perfectionist tendencies.
Lately, I’ve been thinking about perfectionism in software development. We want our code to be readable, efficient, maintainable, robust… the list goes on and on. Of course, having high standards is a good thing, but when juggling so many objectives, perfection is not attainable. If not properly handled, perfectionism can lead to slow-downs in development.
While the desire to achieve perfection will always be there, these strategies have helped me harness this power for good rather than evil.
1) Communication is key.
It can be difficult as a perfectionist to share something before I feel that it’s complete. This can manifest in different ways. Sometimes when I pick up a new story to work on, I experience a period of analysis paralysis when I am trying to figure out the absolute “best” way to implement a feature or fix a bug. Or I want to spend extra time on a story to make sure it’s totally “complete” before anyone has a chance to critique my work.
When practicing agile software development, this can be highly dangerous. Spending too much time on a story can create bottlenecks or skew team priorities. Communicating concerns or issues as soon as possible allows the rest of the team to aid in decision-making and unblocking. Although it feels hard at first, I almost always feel 100X better when I involve my teammates right away, rather than letting my anxiety get the best of me. That’s what a team is for, after all.
2) Don’t let perfectionism hold you back from making a decision.
As previously mentioned, I suffer from analysis paralysis. It can feel like I’m stuck at a buffet, endlessly weighing the pros and cons of each dish until I’m too overwhelmed to even pick up a fork. This poses a risk in software development. When building software, we are constantly faced with decisions and trade-offs. Letting analysis paralysis get the best of me can lead to bogging down in all the options, unable to move forward, and getting nothing done. It feels like my brain’s stuck in a loop, endlessly analyzing and second-guessing, while time keeps ticking away. It’s frustrating, exhausting, and it hinders productivity.
If it’s not the right moment to bring the team in to the decision-making process, I’ve found that time-boxing can be extremely helpful in these circumstances. Instead of getting stuck in the decision stage, I pick one of the top options and just go with it. I then set a time limit (anywhere from 15 minutes to an hour, depending on the amount of effort estimated for my current story). Once my time is up, I evaluate how things are going. If I feel like I’m making progress, I feel secure moving forward. If not, it doesn’t feel like it’s too late to go back or that I’ve wasted too much time.
3) Let users decide when it’s “good enough.”
Another thing that helps me is to remember that software is never really “done.” I have been re-reading The Pragmatic Programmer by Andrew Thomas and David Hunt. I was struck by their description of software that’s good enough as “good enough for your users, for future maintainers, for your own peace of mind.” This means users must be involved in determining when software is good enough and determining what trade-offs might be made.
It’s important not to let perfectionism keep us from shipping software. Getting the user’s perspective on what is good enough is more important than relying on my own definition of “done” or “perfect”. With practice, we can become better at knowing when to stop and let our code stand on its own for a while. In doing this, we may find that it is good enough as-is.
I’ve come to realize that perfectionism isn’t necessarily good or bad. It’s a trait that is useful when harnessed properly and detrimental if not. Working against my own perfectionism has helped me speed up my processes, communicate better with my team and find joy in “good enough” rather than in the pursuit of some unattainable ideal. It has pushed me to grow, both personally and as a software craftsperson. If you also find yourself struggling with perfectionism, I hope these tips can help you too!