DEV Community

Cover image for Perfect Code Makes Everyone Lose

Posted on

Perfect Code Makes Everyone Lose

Perfect code may seem like the ideal goal, but aiming for it can actually lead to loss for everyone involved.


It sucks up time and resources like a black hole.

Longer hours of work? Check. Higher costs? Double check.

Image description

It's a quick ticket to burnout and a slow ticket to progress.

While you're busy polishing every bit of your code, important tasks get left in the dust. Does it make you a coding superstar? Nope, just a worker ant stuck in the endless cycle of 'improvements'.

Your team? Stuck trying to decode your masterpiece instead of pushing the project forward. And all for what? A shiny, 'perfect' code that took twice the time and money it should've?

Here's a hint: aim for 'good enough'. It's fast, it's cheap, and it does the job. No hassle, no waste. Just effective problem-solving.

But what is ‘good enough’ anyway?

I've got a simple checklist:

  1. Does the code meet the spec? Write code, make sure it meets the requirements and move on.
  2. Does the code follow your codebase rules? Keeping things consistent is a must for easy reading and maintaining. Use linters and formatters to automate code convention checks.
  3. Does the code pass the tests? Well, that's if you've got tests to begin with. If not, trying to introduce them outside of the task's initial scope isn't a wise move.
  4. Does the code smell... not too much? This is going to be specific to your particular case, trust your gut feeling.

As long as you stick to these simple checks, you should be fine. Just don't over-engineer.

But what is over-engineering?

Over-engineering is like building a spaceship when all you needed was a bike. It's when you take a simple task and inflate it with complexity that isn't necessary.

Maybe you find yourself continuously refactoring the code you've just written, or messing with parts of the code that weren't part of the original problem. Or, adding unnecessary features for a future that may never come. These are flashing red lights on the road from 'good enough' to over-engineering.

Remember, it's about solving the problem at hand, not crafting a masterpiece for the ages.

If you have something to add, please leave a comment.

Follow me on Twitter and connect on LinkedIn.

Top comments (7)

jarrodhroberson profile image
Jarrod Roberson • Edited

this is called "Gold Plating", it is easy to spot a "Gold Plating" programmer, they can never submit a pull request or apply one because their "local is always broken".

These people are a complete waste of time, they are there to just satisfy themselves and their need to feel like they are being productive, when they are actually the opposite.

They are the people that constantly harp about some language that is completely impractical to use in practice but has some magical ability to save you from doing something "bad" that can not be defined in an actual real life scenario that would cost a company real money.

They are constantly putting sad attempts at shoehorning whatever pet language feature of the month into code they wrote months ago to "fix" some imagined academic design flaw that does not actually exist.

Or some dogmatic implementation of some CFDDD (Consultant Fever Dream Driven Design) philosophy that meets the same criteria; academic in nature, overly complex, solve a non-existent problem or one that is easily avoided with minor educational effort, or is just a clone CFDDD with a slightly different name and one new thing added because people have soured on the previous one and are not hiring consultants or buying the courses for that one and are looking for the next not magical silver bullet to all their issues that exist only in their heads.

These people also tend to be the darlings of management, because they always demo some "awesome new thing they learned" at the end of a sprint, and management sees it and they get kudos for learning and staying up to date and constantly complain about everyone else writing crappy code that "they have to fix" (and the pull requests are never accepted because it probably breaks existing code that has worked for over a year ).

A year later they same management refuse to accept, even with a print out of every git commit and user id, that this person has not committed a single line of code to what is actually in production when you are in a meeting about your performance and not delivering some useless feature that was never needed to begin with back in April of the previous year. It is the "teams fault" and we just "need to figure out how to work with" this person.

Yes, this has happened IRL; multiple times at different companies.

jankapunkt profile image
Jan Küster • Edited

Agree and I can only suggest this article "The one and only software design principle (not by me):

jmfayard profile image
Jean-Michel (agent double)

Speaking Truth to Power
Burn Clean Code

serjobas profile image
Sergey Bunas

Speaking straight facts man! I've always been hating the perfect code :)

boudewijndanser profile image
Boudewijn Danser

Great tips.
I try to make it work according to spec first.
If it's working, tested and there is time left within the estimation there can be a bit of polishing done.

nrjshka profile image
Max Korolev


artem_suslov_f0ef4379820f profile image
Artem Suslov

I like the idea and your brave to tell about this! I think sometimes new devs try to polish their code and dive deep into it when it’s not necessary. Keep going🤙🏻