Today’s post is in reply to the invitation post, Josephine Bush asks the question: “How do you get to good enough and not burn yourself out with perfect?”
As an editor, I read this question and I love it, but I am reminded of the Seinfeld episode called Mom and Pop store. There was a discussion about whether Jerry was invited to a party, and Elaine said the host asked, “Why would Jerry bring anything?”
Jerry asked, “okay, but did he say, ‘Why would Jerry bring anything?’ or ‘Why would Jerry bring anything?’
The reply was, “I think he emphasized would.”
Context is everything
This title of this month’s T-SQL Tuesday post is in that particular sort of vein. Whether you emphasize good enough of perfect changes the meaning. About 25 years ago now, I was working on a project rebuilding a company’s base customer system. This was supposed to be an agile project, but in reality, it was a death march, deadline driven process. The person driving the project LOVED the phrase “better is the enemy of good enough”. So over time I learned to hate the term “good enough.”
Over the years, I came to reconcile this hatred with the realization that it isn’t “good enough” I hated, it was the definer of the term.
Before you can use a term like “good enough” or “perfect,” it is essential to recognize what these terms mean. In the invitation post, Josephine does a great job defining what trying to be perfect, or perhaps rather what trying to be perfect does to her.
My definition of Good Enough
The problem with trying to be perfect is that it is not reasonable. You can never be perfect. But you can be good enough without settling, but you have to do a few things:
- Define what good enough is in reasonable terms
- Ideally, you define why good enough is actually good enough
- You need to reconcile the value of working to that good enough goal
The one of these that needs maybe a bit more clarity is understanding the why. I have always had the mentality that I was going to stay at a job for as long as I was happy. I had worked at my prior company for 5 years, left, and had come back not too long after this large project had been completed.
I was assigned to help build the business intelligence parts of the system. What I was seeing was not making me happy for many reasons. The databases being built were not well normalized, and if you understand database theory at all, this is not just some kind of academic process. It is completely practical and meant to create your databases to handle your customers’ requirements.
If you don’t match your database to the needs of the customer, problems will ensue.
I stayed there for 15 more years after this project, and literally every day I felt the decisions made during those years. So, getting it right enough, and defining “right enough” is essential.
The advice
To Josephine’s final question: “How do you get to good enough and not burn yourself out with perfect?”
It all comes down to understanding the value. As much as I am a perfectionist in some things, I am kind of a slob in others. When it matters (like building a database that will anchor my organization for 20 years and affect my life for as long as I am there), striving for perfection and going some level of extra mile makes sense. When the work will pay off, it is usually worth it. Usually as a team, you can all feel it too. This means something, so let’s do it well for the next person, that might be me.
And doing this within the bounds of the advice Josephine provided in the invitation to not burn yourself out.
Load comments