---

Hello! In this post, I want to share my thoughts on how my approach to creating software has changed, and continues to change. I’ll talk about how I used to dislike any solution that wasn’t “perfectly” made, and how I always wanted to use the newest and, in my opinion, most suitable code for every task.

When I started my career as a programmer at a company, my goal was to write the best possible code: the fastest, most optimized, cleanest, and fully compliant with all the rules and principles I’d learned. I wanted no duplicates and avoided them (DRY). I wrote small, simple methods with a single responsibility (SRP). I still remember when my boss suggested using a Command in Command while using CQRS. I really didn’t like it because, after all, the rules said otherwise and it “shouldn’t be done.” I admit, I used to over-engineering, optimize my code, and use the latest language features, design patterns, or just make my code more complicated than it needed to be. I also didn’t really like YAGNI (You Aren’t Gonna Need It), sometimes writing extra helpers or extensions, thinking someone would surely use them and it would make their life easier.

How do I look at all this today? And how has it changed with more years of experience? Humility and working with other programmers played a big part here, I’m not the only one building the whole project.

Regarding code duplicates, I’ve learned that not all similar-looking classes or methods need to be removed or have their common parts extracted. Code changes over time, and these methods don’t always refer to the same thing. Often, trying too hard to reduce duplication leads to a monster made half of “if” statements.

For small and simple methods with one responsibility, well, it’s a good approach, but as with everything in programming, “it depends.” Today, I wouldn’t say that many small methods are always more readable than one larger one. If we don’t have to, I personally wouldn’t split things up just for the sake of it. It’s a bit of a preference, but I find it easier to read and debug when I have the whole context in front of me instead of jumping between several parts.

As for the “Command in Command” solution from my boss, well, it’s true it’s not the recommended approach. But again, as it often happens in programming, “it depends”. No one will punish us for it later, except the code itself. We need to weigh everything.
If we’re able to accept the future problems of a decision in exchange for clear benefits right now, sometimes it’s worth making that trade. In the example I described, implementing a solution that avoided the “Command in Command” approach would have been very costly and not at all easier to maintain. I knew then that it was an
anti-pattern that broke the rules of separate responsibilities, but in the end, it was a conscious compromise decision, with the understanding that we could handle its costs.

I’ve moved away from the “ideal” solution approach and now do many things that simply satisfy me and are “good enough”. If the situation doesn’t require it, I use the simplest methods and commonly known language features, so no one has to wonder why something was used or how to handle it. I didn’t think this approach would bring such flexibility to my code. Especially since our project is changing a lot, this approach helps me extend my code in many directions without having to rewrite the whole solution, just adapting it to new needs.

I once made a bunch of helper methods for our OpenSearch solution to make it easier to manage indexes and test everything. And what happened to them? I deleted them. Bigger changes came that forced me to modify them, time was tight, and I’d have to keep eyes on them. Sounds like they were badly designed? They were! When I made them, I thought there’d be a free time when we could focus on improving overall quality, but as life shows, I was wrong. That’s why I’ll never again create methods that “MIGHT” be useful.

To sum up, I’ve shared some of my experiences and thoughts on software development, which will surely continue to change with more years of work. This post isn’t meant to be advice, everyone develops their own approach, and you might agree or disagree with some of my points. However, I believe a good conclusion is to always approach the principles we learn more consciously.