Obviously, stop before you hit the point of diminishing returns. The problem is many operators stop way before this point--and leave proverbial money on the table.
In my experience, people are very influenced but how much they enjoy a task, which screws the perception.
So an engineer who enjoys working on a feature will underestimate the time it will take to reach to the next level, and overestimate the benefit it brings ('it will help us scale in 5 years').
And when writing an important Slack message or email, they will overestimate the time it takes to make it great ('Why would I ask for feedback on a message? I just hit enter, it saves so much time'), and underestimate the value of a clear message. Especially if other people are supposed to act on it (like support engineers, or your PM), those 10 additional minutes can sometimes saves the company HOURS of going in the wrong direction.
In my opinion, the best way to battle 'perfectionism' (for software engineers at least) is to think 'What will be the benefit of the next level RIGHT NOW, in the upcoming days?'. If you are improving something for a far away future, you may have reached the point. If it will make the life of your customers or teammates easier - you still have a way to go.
Insightful post. I've experienced those cases where "good enough" wasn't actually good enough. If we're seeking excellence, we must go further, but without being trapped into perfectionism.
"Stop catastrophizing." Ha. Can't wait to use that one, as it gets right to the heart of the matter. Just wish it was less than 5 syllables as I could see myself bungling the pronunciation in the moment.
That being said, maybe saying it slowly is part of the impact I'm seeking.
Spot on.
In my experience, people are very influenced but how much they enjoy a task, which screws the perception.
So an engineer who enjoys working on a feature will underestimate the time it will take to reach to the next level, and overestimate the benefit it brings ('it will help us scale in 5 years').
And when writing an important Slack message or email, they will overestimate the time it takes to make it great ('Why would I ask for feedback on a message? I just hit enter, it saves so much time'), and underestimate the value of a clear message. Especially if other people are supposed to act on it (like support engineers, or your PM), those 10 additional minutes can sometimes saves the company HOURS of going in the wrong direction.
In my opinion, the best way to battle 'perfectionism' (for software engineers at least) is to think 'What will be the benefit of the next level RIGHT NOW, in the upcoming days?'. If you are improving something for a far away future, you may have reached the point. If it will make the life of your customers or teammates easier - you still have a way to go.
I've always had an issue with good enough or get it to 80% done and out there. Those are arbitrary and my 80% is not he same as someone else's.
Insightful post. I've experienced those cases where "good enough" wasn't actually good enough. If we're seeking excellence, we must go further, but without being trapped into perfectionism.
"Stop catastrophizing." Ha. Can't wait to use that one, as it gets right to the heart of the matter. Just wish it was less than 5 syllables as I could see myself bungling the pronunciation in the moment.
That being said, maybe saying it slowly is part of the impact I'm seeking.
👏🏼👏🏼👏🏼
Great advice. +1 on finding the highest leveraged items to optimize.