You know when you're programming, writing code after code, loop inside loop, if-else after if-else, and at some point you look at your code, it looks back at you, and you think: "this could be shorter!"? Well... That might be a good idea, or not.

Refactoring is an important stage of the project. At least for me, I rarely write the final version of the code right away. It's always necessary to reread, check if it's clear, readable, intuitive, etc. Whatever is redundant, too verbose, or unnecessary, it's always good to make it simpler.

However, everything that's excessive becomes problematic, and here it couldn't be different. It's very common to go overboard when refactoring code. And this code looks beautiful at first: seeing a function that had 15 lines become just 5 is something wonderful. Until you need to do the first maintenance.

We need to keep one thing in mind from the start: we don't write our code just for the computer to understand, but for humans to understand, whether it's you or your coworkers (assuming you're all human). How many times have you picked up code that you yourself wrote some time ago (it doesn't even need to be that long ago, just a week) and couldn't remember exactly how it worked? This is the most normal thing in the world.

Code needs to be read and interpreted, like a poem. But when we shorten code too much, its interpretation becomes much more difficult.

Now, think about how it must be for another programmer, one who didn't participate in the development, to do some maintenance or implement a new feature, something normal in the daily life of a software company. Imagine how much time they'll need to study and test your code to understand the logic you thought of. Code that would take them minutes to understand (if it were well written) ends up taking hours, and that's not even an exaggeration.

To give you an idea: recently, my team and I needed to do maintenance on a React application. Despite being a simple adjustment, the code was so optimized to avoid any unnecessary line of code that it took us more than a day to, first, understand the code and, second, understand how it rendered a form. Something that should have been totally simple.

Conclusion

Understanding that code will be read and worked on by other programmers and having the empathy to write more readable code will make you a much better programmer to work in a team (and trust me, this will happen most of the time).

Code needs to be descriptive, intuitive, and self-explanatory. Any developer who glances at it should, with little effort, understand what it does. Don't save on lines of code and give clear names to variables. Moreover, another very important detail: not all duplicated code is bad. How many times, in my early jobs, I would make a clever solution to avoid code duplication and an even bigger hack to, later on, use the same piece for different purposes, but without duplicating anything. It's nonsense.

And what do you think about this subject? Have you ever had any experience with code that was difficult to understand? Write in the comments.