You Don’t Have to Write Perfect Code. It’s Okay to Be Good Enough | by Guy Erez | Jun, 2022

Perfection comes at a cost

Photo by Ryland Dean on Unsplash

Perfectionism. Nowadays it’s often displayed as a badge of honor.
So much so, that it’s considered a “good” negative quality to mention during interviews, as it tends to be associated with diligence and hard work.
Perfection, however, comes at a cost.

You might be scratching your head right now. motherhood? Code?
Don’t worry, it’ll all make perfect (pun intended) sense in just a moment.

The “Good Enough Mother,” was a term coined by the renowned pediatrician and psychoanalyst Donald W. Winnicott. Its main idea is that aiming to be a perfect parent tends to introduce unintended harmful behaviors. Thus the quest to be a perfect parent backfires, causing more harm than good to both the parent and their child.

When you think of it, it makes perfect sense. But if you happen to be a parent of a newborn child, it might be hard to accept. After all, it’s the most important thing you’re going to do in life — raising an actual human being that is 100% dependent on you. But you know what it’s like. When the pressure mounts up, we began to be more irritable, stop thinking things through, and all of these emotions are communicated back to your child.

That’s definitely a fascinating topic, but I’m not here to talk about parenting.
The goal of this quick psychology lesson was to illustrate how perfectionism, even when applied to the most important things in life, like parenting, is the wrong way to go.

So, what does it mean to be a “good enough” developer?

What does it mean to write “good enough” code?

Let’s begin with first principles, and ask ourselves — What is the goal of writing code?

Photo by Markus Winkler on Unsplash

Some treat code as a form of art. They strive to write elegant, beautiful code that inspires others. I’m all for elegant code, but that’s not its ultimate goal.
The true goal of writing code is to solve problems.

Even so, we don’t just want to solve problems, we want to solve them well.
We don’t just want to build a product that works, we want it to be a quality product. However, at some point, spending more time making the code a little more perfect, produces no tangible results.

Moreover, if we’re spending so much time perfecting our code, the lack of tangible results is the least of our problems. Perfection, laudable as it may be, comes with a steep price tag.

Photo by Elisa Ventur on Unsplash

There’s one problem with perfection, and it’s a big one — perfection is subjective. Most people can agree when it comes to truly awful code. But when it comes to writing perfect code? Everybody’s got an opinion.

“You should extract these lines into a function”

“You have too many functions”

“This should belong in a separate class”

“That doesn’t justify a separate class”

“Add explicit parameter names when instantiating objects”

“The code is too verbose, remove explicit parameter names”

“You have to add comments in key areas”

“You should never add comments”

“You should rarely throw exceptions — return a response object with status: failed”

“If something doesn’t work — always throw an Exception”

“The code isn’t OOP enough”

“This doesn’t justify OOP’s coupling — use a more functional approach”

The list goes on and on. It becomes even more difficult if the comments above all came in one PR from different teammates. In the face of so many conflicting opinions, is it even possible to make the code perfect? Probably not.

Since there is no clear standard for perfection, engineers might spend hours, even days, contemplating minutiae. That can easily lead to overthinking and eventually even burnout.

So what is the price of perfection you ask?

Burned-out engineers who are not making progress on their tasks.
Shooting for perfection means missing our target — Being effective at solving problems.

Photo by Felicia Buitenwerf on Unsplash

In order to solve problems effectively, we need to strike a balance between code quality and actually getting things done. In order to do so, we need to find the point of diminishing returns. The place where spending more time optimizing code quality, will not produce a better outcome, and might even make us less effective overall. We need to construct our own definition of “Good Enough” code.

The definition of “Good Enough” code must be determined according to your unique needs. Some businesses might prioritize moving fast, so the standard might not be as high. Other businesses might require a robust infrastructure where every small mistake could spell disaster.

Once we’re clear on our business’s unique priorities, we need to determine our coding guidelines. It’s best done at the level of the entire R&D department, in order to promote more effective collaboration. But at the very least, it needs to be determined at the level of your team.

  • What is the definition of “done”?
  • How do we format our code? — line spacing, when to break lines, do we add function parameter names (where applicable)
  • Do we favor performance or readability?
  • What is our testing philosophy? Do we favor component tests over integration tests?
  • Class/Package/Function naming conventions
  • Logic layers — does it always make sense to separate DTOs and models?
  • When writing APIs, do we favor throwing Exceptions over Response objects?

The list goes on of course. The main goal is to set a clear standard for writing good quality code. That way, we can reduce cognitive load and reduce time spent endlessly debating PRs, thereby giving our team a significant performance boost.

Perfection comes at a cost. Psychology teaches us that we don’t need to be perfect parents to raise healthy children. That’s also true for your code. You don’t have to write perfect code to be an effective developer. Striving to write perfect code will most likely lead to frustration and burnout, because perfection is subjective.

The goal of writing code is to solve problems.

So, get clear on what constitutes “Good Enough” code for your business, set clear guidelines, and experience a significant boost in productivity and developer wellbeing.

Leave a Comment