DEV Community

Cover image for Perfect Code Makes Everyone Lose
Misha
Misha

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.

Why?

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 (6)

Collapse
 
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): dev.to/mcsee/the-one-and-only-soft...

Collapse
 
jmfayard profile image
Jean-Michel 🕵🏻‍♂️ Fayard

Speaking Truth to Power
Burn Clean Code

Collapse
 
serjobas profile image
Sergey Bunas

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

Collapse
 
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.

Collapse
 
nrjshka profile image
Max Korolev

Top!

Collapse
 
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🤙🏻