The Pareto Principle: How To Deal with Imposter Syndrome
When French philosopher Voltaire penned the phrase “The best is the mortal enemy of the good”, I wholly doubt he anticipated for resurgence in its relevancy near 300 years after his death. I am one of the many developers out there who is prone to the occasional imposter syndrome, and the best way for me to combat this is to invest further into the work that I am responsible for delivering. My rational being that if it is not at its best, it may reflect poorly on my own skills. In my early professional days as a budding developer I would spend many a personal hours applying more and more polish to a project to justify my skillset to any observers. Though my approach to development is far more healthy now, I can only agree with Voltaire, who I assume would have slammed my laptop lid shut as soon as 5:00pm hit and proclaimed “c’est fini”, as the state of my branch was probably good enough already!
This moment of reflection came to me whilst side-eying reddit, where a pro tip caught my attention:
“Embrace 'Progress Over Perfection': Focus on making consistent progress rather than striving for flawlessness. Recognize that completing tasks to a satisfactory level is often more valuable than endlessly pursuing perfection.”1
There is no miracle cure to imposter syndrome, but with advocacy for best mental health practices being stronger than ever this might be the much needed mantra for healthy development practices. It is easy to mistake this approach as a way of inviting carelessness into your work. However, you are able to break your one large task into individual pieces then you be able to measure progress, and have the clear milestones for where you might have unknowingly reached the point you needed to be where the work you are perfecting hit the point of being ready to be used or deployed.
Luckily, there are tools and practices available to help with this, one approach is known as the 80/20 rule. More professionally known in management as the “Pareto principle” This is a generalised phenomenon that states roughly 80% of consequences comes from 20% of the causes. This is a useful Six Sigma tool that helps to prioritise the top tasks (20% or thereabouts) to take within a day to account for the maximum, 80% worth of positive impact. This has been used in economics, data analytics, quality control, and has Microsoft’s backing as an approach to managing improvements in computer science. Steve Ballmer, Microsoft CEO is quoted as saying “[a]bout 20 percent of the bugs causes 80 percent of all errors”. It also does not just apply to bug fixes, in my experience, 80% of a piece of software can be written in 20% of the total allocated time, interestingly, this works both ways with the hardest 20% of the code taking 80% of the time. For further reading or research on the topic YouTube has an abundance of information, as well as the books of Richard Koch, namely the “80/20 Principle: The Secret to Achieving More with Less” and “The 80/20 Manager” the Secret to Working Less and Achieving More”. It also helps to be able to break the 100%, large tasks into minuscule tasks of less in order for you to know how far you have come and how far you have left to go.
This is a fundamental principle of Agile methodologies which emphases iterative and incremental development. Visual management Kanban boards help massively in this regard in order to manage your workloads, to stay organised, and to allow for transparency, collaboration and continuous improvement; each of these are massively important to understand how far you have come in your development cycle. This also plays into the core fundamental unit of continuous delivery, where as each small task of the 100% is broken up into smaller units it undergoes testing, review and integration into the final product. This allows for regular feedback and helps facilitate discussions where your team can see the work which you have done and help you address whether it is good enough for the requirements, and if the hours you would have put in adding polish would be wholly necessary or not.
Though it is important to have high standards, perfect in so many instances is the enemy of good. Hopefully through an awareness of the Pareto principle, and clear agile methodologies to back it up you will be able to acknowledge the cases where “good enough” has already been reached. Trust in your scrum masters, organise your workloads, and realise you are already 80% there on the road you are traveling on.
https://www.reddit.com/r/LifeProTips/comments/14w4pow/lpt_embrace_progress_over_perfection_focus_on/
