Nothing wrong with being perfect, am I right?
Except of course, I was wrong. My perfectionism drove me to to waste so much of my most precious resource: time. The hours I poured into making that thing just a little bit better - the mix, the code, the design, word choices - every last second of it took something I could never get back. The one thing I could have improved upon, was knowing when to call it complete; my definition of done.
Time for a little disclaimer
Before we go any further, I should clarify that I’m not talking about a lack of care for a project. That will surely end badly for both you and your future self, (“Why, oh why, didn’t I spend just five more minutes fixing that?”). I’m not advocating being the fastest in the West either (“Eh, can you say rushed?”). I am suggesting that perhaps we creatives tend to agnonise over things that ultimately take more away from us, than they give to us.
Why are we like this?
Wanting to make something good is not bad. Wanting something to be as good as it can be, is also nothing terrible. I do however think that wanting to make something perfect, is probably one of the worst ambitions for any project. Wanting to create something that is perceived as good, especially by ourselves is an important drive. If we don’t care about a project, we are unlikely to finish it.
Sometimes that care isn’t to produce a product that we enjoy though. Sometimes, we want to make something good to satisfy a client. That’s a good motivation too. We want to impress them, we want them to return. But is perfectionism the right approach?
None of us are alone in this
I’ve seen many an article or interview with a famous or successful composer where they too, have agonised over a track, or indeed felt like a track didn’t turn out as they wanted it to; despite its critically acclaimed success. It’s all too easy to look up to someone else and to believe that they are immune to these same struggles. Yet, they are not immune. They often suffer just as we do in this regard.
Sometimes, we need to reset our expectations on a project. Or maybe, that project will not become what we originally set it out to be. Sometimes, requirements change and others still, we’re just not feeling it.
Can we change?
Yes, of course we can have an impact on this. We can definitely try to change how we approach our projects. The biggest suggestion I would make after the main hump of a project is over, is to ask yourself some basic questions.
- Would someone notice if I made this change or not? (Not, would I notice?)
- Has the change improved the project in any meaningful way?
- Does the project already satisfy the given requirements? Not perhaps the ones we have modified in our mind.
- How long have I spent on this already? Is the return on investment a good one?
- If possible, what is the feedback from others I respect on this project?
Once we measure the project against this extra set of criteria, we can often sit back a little in the knowledge that it is done. It is actually complete and complies with all the original requirements and we are simply polishing it more and more to our tastes.
Definition of done
Coming from the software world, one aspect we talk about frequently is the definition of done. Having a clear “definition of done” is crucial not only for software projects but for any kind of project. It sets a clear boundary for what needs to be accomplished and helps us avoid the trap of endless perfectionism. Once we have defined what constitutes as done, we can focus our efforts on meeting those criteria and not getting lost in the details.
Additionally, having a clear definition of done allows us to track progress and celebrate accomplishments. When we reach a milestone or meet a requirement, we know that we are making progress towards our goal. This can be motivating and encouraging, especially when we are feeling stuck or overwhelmed.
It’s slightly different for personal projects where we often have more flexability with time, but I still like to approach my personal projects through the same lens of definition of done. Without that framework I could end up spending excessive amounts of time tweaking and polishing, which could otherwise be spent learning or starting a new project.
I’ve written this post in a generic way because I believe the key concept applies to almost any project. The idea isn’t not to care, it’s to not obsess. To have the courage to say, I am done and to move on, especially when perfectionism can be so tempting.
Photo by Brett Jordan on Unsplash