Helpers Hell

A few days ago, while working on a React + NestJS project, I noticed a recurring pattern: in the last two projects I participated in, helpers proliferated in the code. The curious thing is that this is not an isolated observation; during code reviews, I have witnessed discussions about whether certain functions qualified as helpers or not. This frankly frustrating experience led me to investigate whether this phenomenon is common in other projects or simply a coincidence.

What I found was interesting. After about 20 minutes of searching, I found an answer on Reddit that pointed out a key idea:

Many times, the names we give to functions, variables, classes, files, and folders reflect our own mental models. And while there’s nothing inherently wrong with this, it can limit us.

I agree. Too often, discussions about how to name a function or class steer us away from what truly matters: business logic. This is the essence of software, as it ensures that requirements are correctly implemented in the code. The focus should not be on whether a name is perfect or intuitive, but on whether the implementation adequately reflects the expected behavior and facilitates maintenance.

The problem with helpers in the code

In this industry, it’s easy to fall into the perception that work becomes monotonous, but the reality is different: there are always interesting problems to solve. What holds us back, in many cases, are mental blocks that amplify when working in teams, becoming unnecessary obstacles. Sometimes, these trivial discussions steer us away from the essential.

Let’s stop calling helpers to functions that are, simply, functions. While it’s common to use the term helper to describe a set of reusable functions, doing so adds an unnecessary layer of abstraction that benefits no one and no process (code review, maintenance, deployment, etc.). Instead, let’s focus on the purpose of each function. If a function performs a specific and clear task, call it by what it does, not by a generic term.

Simplification: The right path

Many authors and software development experts, like Robert C. Martin in Clean Code and Clean Architecture, emphasize that the key is to keep things simple. I remember a database professor mentioning to us the KISS rule (Keep It Simple, Stupid). Even in her experience working with databases, she observed how the natural tendency is to complicate solutions when, in reality, the optimal approach is to simplify. If I mention her here, it’s because her advice remains relevant.

Programming doesn’t have to be an exercise in unnecessary complexity. We don’t need to create additional layers of abstraction if they don’t add value. Software development should focus on solving problems efficiently, not on debating minor details.

Maturing as professionals

The real challenge is not only how we name things but how we overcome self-imposed limitations as developers. How much longer are we going to remain passive in our work? When will we take responsibility for managing our time and resources effectively?

It’s time to reflect. During code reviews and meetings, ask yourself: Are we discussing something that truly impacts code quality, or are we just trapped in Parkinson’s Law of Triviality, spending time on the insignificant?

Conclusion: Less is more

My recommendation is simple:

Let’s simplify.

Let’s leave behind irrelevant discussions about naming and focus on what really matters: business logic. Functions should be aligned with that purpose, not with an abstract and vague concept of helper. Let’s remember that, as developers, our job is to turn ambiguous requirements into clear, stable, and predictable systems.

Programming is an exercise in clarity, efficiency, and purpose. If we simplify our decisions, we will not only improve code quality but also enhance collaboration within our teams.

The next time you face a trivial discussion during a meeting, ask yourself: Is this really relevant, or are we wasting time in a conversation that leads us nowhere?

Coming soon...