The Junior Perspective
As a junior developer, I dreamt of becoming highly proficient in Object Oriented Programming (OOP) and abstraction. Back then, I already knew how to write decent OOP code, but it was not considered senior enough according to what senior developers valued at the time. I began mastering OOP patterns and incorporating high levels of abstraction into my code, trying to produce "perfect clean code."
The Pursuit of Perfect Code
"What is the perfect clean code?" For me, at that time, it meant achieving a level of generics and abstraction that eliminated boilerplate code. I spent eight years rigorously pursuing that mythical clean and perfect code.
And?
It didn’t work as I had hoped.
My best-crafted code might have been flawless in design, but it created issues I didn’t even realize I was making. At that time, I didn’t see the problem, and I suspect my peers didn’t notice either. We all knew about SOLID principles, KISS principles, and the Clean Code book, but understanding how to use them effectively to become better developers was the real challenge.
The Turning Point
In software craftsmanship, as you may know already, we write code once but read it thousands of times. Colleagues with a similar abstract mindset had no issues enhancing "my perfect clean code". However, every time a junior or mid-level developer made a small change due to new requirements, we lost hours in code reviews.
The problem wasn’t the modified code itself. It broke the meaning of a carefully crafted abstract class by adding a minor conditional statement. The code was difficult to change because its purpose wasn’t immediately clear to those unfamiliar with the topic. This could inadvertently break the business logic. For instance, a misplaced conditional check once denied access to a product for an authorized user, breaking critical business logic.
At my first job in the banking industry, I had a heated discussion about Clean Code thanks to Java’s infamous "null reference" known as the "billion-dollar mistake". My friends didn't like that I was using null as a real value in an if statement and asked me to switch to using Optional type instead. That day I decided to buy Clean Code by Uncle Bob. Through the book, I began transforming my generic, abstract masterpiece into SOLID and KISS-compliant code.
When I finally understood the book, I realized that what other senior developers often seek as perfect clean code through higher levels of abstraction and generics is, at best, over-complicating solutions and, at worst, a recipe for increased maintenance costs.
Lessons Learned
When I transitioned from using a few huge, carefully crafted classes to many small, single-responsibility classes, everything started to click. Breaking a monolithic class into smaller, single-task components made debugging more modular and efficient, reducing errors downstream. This transition not only improved code quality but also made it easier for new team members to onboard quickly and contribute effectively, without hours spent in code review. The code became easier for anyone to read, changes occurred only where needed, and testing a single small class was much simpler.
Conclusion
If I could recommend a path to my younger self, without question I would suggest following SOLID and KISS principles instead of diving into abstraction hell and overusing OOP. Reflecting on my journey, the most important lesson I’ve learned is that simplicity is a guiding principle for tackling complex problems across any domain.
"Do one thing and do it well" - Unix philosophy
That’s all for now, thank you for reading!
Top comments (0)