The perfect solution

Striving for the perfect solution is what our inner technical heart truly desires. This is what we love and what the education system usually values.

Because of that, we tend to look for all the corner cases and fix them immediately - one by one. And analyze any counter-examples that - if discovered - may invalidate the whole solution. And of course, we can indefinitely polish the code, including its formatting (tabs vs spaces anyone?).

I think the above-mentioned approach might not be the optimal approach you can take as a Software Engineer - neither at the company you work for nor when you're trying to make your own ideas fly. Why?

Perfect... might not exist

It's important to realize that (what you perceive as) the perfect solution might not exist. Some things you just cannot do - if you're trying to sort a list of n elements in O(n) - you are out of luck.

Moreover, what you think is perfect, might not be perfect for somebody else.

And even if we can assume that a perfect, optimal, best solution exists... it can be extremely hard to achieve it. And in business, it's often not worth to invest an abundant amount of time to solve a rare, improbable corner case that can - if occurred - be sorted out with a single email.

A Pragmatic Solution™

Often more desirable approach is to aim for a pragmatic solution. It's what business people may recognize as an MVP (Minimum Viable Product) but the pragmatic approach doesn't need to be applied on a product level. Pragmatism is an attitude you can use at many levels of your professional (and non-professional) life.

And it's remarkably simple. All you need to do is to ask yourself one question and answer it honestly and sincerely. And the question is:

Is it worth to use the time, energy, and resources to do X to achieve Y?

Or to make it more concrete:

Is it worth refactoring a piece of code implemented 10 years ago that has proven to be working correctly since then, that no one needs to touch ever since except for you now who is faced with a task to change the wording in an error message in line 3214?

More often than not, it's not worth it. Because business is not about solving all the issues that might ever happen but about solving the right issues in a reasonable way.

80/20

You've probably heard about a Pareto Principle. In short, Pareto Principle states that 80% of something is related to 20% of something else. That's very generic and the numbers may of course not be exact but the idea is you can solve 80% of a problem using 20% of the time. Or if you apply it twice, you can solve 64% of a problem in 4% of the time... Now we're talking!

Pragmatism != Sloppiness

Sometimes, a pragmatic approach is to indeed refactor a piece of code to make it cleaner. Or take your time to understand the problem and solve it really well. Or even to bump the framework version you're using from 3.0 to 5.1.

Pragmatism is about using your valuable and scarce resources (time, money, energy, skills) in the best possible way. A way that takes into account not only your perspective but also all the other perspectives (the team, stakeholders, clients, etc.).

Silver bullets

The Pragmatic Solution™ approach is by no means a silver bullet. There are areas in which you absolutely need to aim for a true, 100% solution, with all the corner cases covered (think medical equipment software). Or maybe, you want to break the world record, set new boundaries in the field, make new discoveries, or move the world forward in one way or another. In this case, absolutely go for it!

But if you're implementing the next feature for an internal project with tight deadlines and a backlog piled with the next tasks, maybe you should be more of a pragmatist, and not a perfectionist??