Helpers Hell

A few days ago, working on something at React, I realized that there are already two projects going on that I see that there are helpers everywhere, and sometimes they even get to the stage of code review, with discussions about whether a method, class or file should be called helper or not.

Looking a little bit on the Internet to see if this was something that had only touched me, I found that, apparently, it’s more of a convenience to avoid falling into the other rabbit hole: not knowing how to name things when it comes to programming.

Of the twenty minutes I spent searching a little bit, I found a post on Reddit that mentions that the possible problem is that we directly express our own thought patterns in the names we give to functions.

I agree with that argument. There are times when discussions revolve solely around how to name something. I’m not saying that naming things is a bad thing; what limits us is that these little blocks take us away from what really matters in the code we program:

business logic

The business logic is what allows us to differentiate whether the requirements are well expressed in lines of code, not the names we give to the variables.The good names, the clear expressiveness in the code, the application of design patterns and, in general, the experience we already have whether working or even on a trip to the park with family, friends, at a well-organized party, etc. are the elements that really bring value.

What makes us monotonous about work today is not the work itself: there are entertaining and diverse problems, there is no day like the previous one. What does create mental obstacles, both in the work teams and in ourselves, are these subtle limitations.

So, here I leave you with a list of good practices that we can apply, starting with letting go of the term “helpers” to something that is actually functions.

People before us, through books like Clean Code, Clean Architecture and others, have already expressed it: you have to do the simple things. I remember a rule that a database teacher taught us at UTT: “KISS” Keep It Simple, Stu****. It was fun in its time, but it reflects how, even in years of work or experimentation with databases, people tended to complicate things, probably because of other limitations.

How long are we going to be passive about our work? How long do we have to wait to mature and take control of our ability to manage our time and resources?

I invite you today to put those differences aside and start asking yourself: is what’s being discussed in this code review or meeting something that, from the root, is a limitation, or are we just falling into the Parkinson's law of triviality?