Growing up, I was a perfectionist by nature. Every single answer I wrote on a test and every single line of an essay I wrote had to be perfect. I was really meticulous about the minor details - making sure each “t” was crossed and each “i” was dotted.
Software engineering, though, is a completely different ballgame. I had to learn that the hard way. Early into my career, I spent a lot of time making sure every line - no, every character of my code was perfectly written.
Then, I got one of the best pieces of advice I was given as a junior engineer from my mentor.
Be comfortable with your code being good enough - not perfect - then iterate.
While it was fine in school and university to take my time with projects because the scope wasn’t too large and the deadlines were quite relaxed, it was absolutely not fine as a professional. This is because you always want to get feedback as early as possible.
Imagine spending months releasing a feature only to find out that this isn’t quite what the customers wanted. The main game of software engineering is to release quickly and keep improving. This is why your delivery manager is always talking about breaking things down to the Minimum Viable Product (MVP).
🚩 Spotting the Perfectionist Red Flags
Recognising the red flags may not be as straightforward. The perfectionist in us manages to convince us that what we are doing is just not good enough… not “perfect” enough.
We start nitpicking every single detail in our code just to make sure it goes through review without any hiccups, passes every single possible test and provides the most value to the customer.
By then, a competitor would have released their own feature that wasn’t “perfect”, and they already delivered value and received valuable feedback to incorporate in their next iteration.
So, how do we start delivering value as soon as possible?
Before we start talking about the solutions, let’s identify the flavours of perfectionism:
Endless refactoring: coding can be a lot like writing. We usually come up with a solution to satisfy the requirements, and then refine by making the code more readable and more efficient. Then, this process repeats and before we know it, a few days have already gone by, and your code is still not out for review.
Feature creep: as software engineers, we’re geared to solving problems, so sometimes, we start solving problems outside the scope of the ticket. We either start looking ahead, or looking at other files and start fixing things that could have been written better.
Fear of failure: we dread what comes back from the code review. We dread what comes back from the QA testing the code. We dread being judged by the customer.
Unfortunately, some of these flavours can mask some deeper insecurities like imposter syndrome, and the perfectionist in us is just convincing us that striving for perfection is the only way to silence the doubts and prove ourselves.
We need to recognise, though, that this is just the internal monologue. This happened to me even in my most recent 1:1. My imposter syndrome took over and I started questioning my progress. Luckily my manager was quick to recognise that and remind me that I have achieved a lot in such a short amount of time despite not having experience with those particular technologies.
We need to remember that progress, not perfection, is the true mark of becoming a successful engineer.
💡Strategies for Managing Perfectionism
So we’ve identified the red flags of perfectionism - let’s start shifting the focus to fighting back. How can we stop the negative internal monologue? Here’s some of the techniques we can add to our arsenal:
Mindset: We can use the advice my mentor gave me and be satisfied with our code being “good enough” instead of striving for perfection. We focus on delivering value and solving problems rather than achieving an ideal. That way, each time we ship, we can celebrate milestones and not just the final product.
Goal-setting: We can use timeboxing to prevent our work from being stuck in the endless perfectionist loop. We can develop a strict “definition of done” for each task and stick to them.
Seek feedback: Seek feedback as early and as often as possible. Accept constructive criticism and participate actively in code reviews. Most importantly, trust your teammates and learn from them.
Managing perfectionism is definitely a marathon, not a sprint. We won’t change away from perfectionism overnight.
It took me a few years to get away from my habits and mindset to get to where I am. Along the way, I made sure to celebrate all the small victories and keep my eye on the ball of progress.
🔑 Key takeaways
Progress > Perfection. If your code is 80% good enough, then ship it and get some feedback.
Recognise the red flags. Watch out for endless refactoring, feature creep and fear of failure which can mask deeper insecurities.
Focus on delivering value. Spending too much time fine-tuning details can delay releases and miss opportunities to provide value to the customer.
Embrace feedback. Seek feedback early by timeboxing yourself, and understand feedback is a learning opportunity.
Managing perfectionism is a journey. Be patient, celebrate small wins and focus on continuous improvement.
Thank you for reading this article!
If you enjoyed this article, please give it a ❤️. It is very much appreciated!
If you think someone else would gain value from this, then feel free to share this post. 🔁