Balancing - Code, Choices and Sanity
Tags: cleancode, balanc
Published: 2024-02-21 21:40:05

As time passes, I hear more and more often people say the phrase "balance is the solution", although I'm not entirely sure they understand the meaning of these words. I am starting to believe that balance is indeed the solution. And not just in one aspect of my life, but in nearly all of them. Just like the well-known phrase "work-life balance", where it's necessary to create a balance between professional and personal life, there is also a need to make the balance between physical and mental development, a balance between time for oneself and time for others...

When I say something is in balance, it doesn't mean I've spent the same amount of energy on two or more things I'm balancing. On the contrary, balance means that at the moment of balancing, I'm satisfied with the balanced ratio between the sides, which doesn't have to be equal. It could be 60/40, 70/30, or even 90/10. I deliberately said "at the moment of balancing" because balancing is an ongoing process; otherwise, I would call it measuring.

Just as the human body balances many systems daily, including blood pressure and heart rate per minute, I believe that balancing is a natural concept. On the other hand, society tends to construct ideologies and tries to find a single solution that can be applied in as many places as possible.


> _"Ideologies are substitutes for true knowledge, and ideologues are always dangerous when they come to power, because a simple-minded I-know-it-all approach is no match for the complexity of existence."_
> _— Jordan B. Peterson, 12 Rules for Life: An Antidote to Chaos_

I'm not immune to this behaviour either. I've been learning a lot about programming lately, so I'll find examples there most easily to explain what I mean.

I remember when I entered the world of design patterns how I saw a pattern as a solution to all problems. This happened to me the most with the Strategy Pattern. The Strategy Pattern is very convenient and can be applied in many more places than necessary, thus increasing code complexity. Fortunately, I did this on a smaller project that wasn't in production, so I quickly and easily corrected this mistake. In this example, I learned from my mistakes, which is very useful. The only better scenario would have been if I had learned the same thing from someone else's mistake.


> _"Don't fall into the Design Patterns trap_
> _It would be best to be warned that you will probably fall into the Design Patterns trap when you first learn design patterns. This means you will try to squeeze a pattern in every solution, and your codebase will become over-engineering and unusable very soon."_
> _— Interesting quote from Dr Milan Milanović in the article: [How to select a Design Pattern?](https://newsletter.techworld-with-milan.com/p/how-to-select-a-design-pattern)_

| ![How much you learn](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vfes630x0j49iw6042y6.png)   | ![How much you learn updated](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2x6kwild8ma9d1f1aae4.jpg)  |
|:---:|:---:|
| Recently I saw this image but it looked like something is missing 🤔 | And I'm glad I found that someone shares my thoughts 😂, and I didn't need to go through making the same image again 🤣 |

Lately, I've heard from various sources that the [SOLID](https://en.wikipedia.org/wiki/SOLID) principle is no longer popular and good. When I'm programming, I use SOLID principles, but I don't apply them 100% of the time. As I mentioned at the beginning of this article, balance is important. I believe that one solution cannot solve every problem. If I try to solve all problems in the same way, I'm not actually solving them but rather transforming them into a new problem.

I believe dissatisfaction with the SOLID principle stems from lack of understanding. If I take, for example, the [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) principle, which states, "**D**on't **R**epeat **Y**ourself," and if I try to apply it in 100% of cases, I'm no longer solving business problems. Instead, I focus on a single principle, attempting to encapsulate every instance of code repetition, thereby creating more complex code that is not as readable and, therefore, not as flexible.

In order to write flexible, sustainable, and functional code, it's not enough to just balance SOLID principles; I need to incorporate other principles like [KISS](https://en.wikipedia.org/wiki/KISS_principle) (**K**eep **I**t **S**imple, **S**tupid). Of course, I don't want to overdo it with the KISS principle either, because I can't always solve a complex problem in a simple way.

I firmly believe it's first necessary to identify the problem before I can proceed to solve it. Recognising the importance of balancing things and understanding that this balance can change as time goes on and I learn new things has helped me not only in my professional life but also in my personal life. It's also crucial to expand our knowledge and broaden our perspectives to balance things even better.

It's true that the more I learn new things, the harder it becomes to balance because I have more things to balance. On the other hand, having more things to balance can lead to a better balance. Because if I don't have enough things to balance, it's possible to end up trying to balance things that are impossible to balance.

If you're struggling with achieving balance, consider broadening your knowledge and expanding your horizons. Even though it may seem harder to balance more things, I would consider it a challenge; therefore, achieving balance will have greater value and satisfaction because more effort has been invested.