For the sake of your code’s quality, you need to put learning aside for a while
It is a truth universally acknowledged that most developers want to be good and to become even better.
If there has ever been a profession centered around learning, self-improvement and being the best at one’s work, it’s software programming.
And to become better at programming, you need to write better code. And to write better code, it is known, you need to know the rules.
The road to great code is paved with bricks labeled DRY, TDD, YAGNI, KISS, SRP, DIP, XP, …
So whenever a developer wants to become better, they naturally reach for those rules. Maybe the next pattern you read about is the one that’s going to turn your code alchemy-like into greatness. Maybe knowing that one supplementary framework, or learning more about data structures will allow you to find that one elegant solution next time you have to solve something.
Spoiler alert: it probably won’t.
What even is code quality?
There’s nothing worse than working on a poor-quality codebase. And we all know instinctively what the term entails.
The code is all over the place! Every other object is basically a God Class! There’s a bit of metaprograming that generates XML which is then read by a homemade parser to build some kind of templating engine… I guess?
But let’s go the other way and ask ourselves, what does good code quality mean? What do we expect to find in a good codebase?
We expect to find code that is easy to understand.
That’s the crux of it isn’t it? After all, the more easily we can understand what’s going on, the more easily we can alter it to solve the current problem.
So that’s what all of those rules are for: making easy-to-understand code. Let’s drop the too abstract “good” adjective for now.
And now the secret.
Truth is: You can keep learning forever without growing at all.
When you focus on rules, they become a crutch, you cling to them for structure instead of trying to reach a specific goal under your specific constraints.
You end up weighing each new idea against the ones you already hold and discarding the one you deem to have “less value”. You think you’re growing, but you actually just keep yourself busy learning.
Focusing on the rules without keeping in mind what the end goal is will get you nowhere.
You end up writing an n-th blog post on why that new programming language is better than the one it seeks to replace or why that forgotten framework was more elegant than the one in vogue.
But if instead you focus on the end-goal — writing easy-to-understand, clear code — everything else follows.
How do you think the rules were designed in the first place? Some people strove towards clarity and they found guidelines that helped them to get there. But they weren’t applying them blindly, since they still had in mind the actual objective: writing clean code.
That’s why pretty much every rule in software development has a “know when to break the rule” clause.
It’s also why you’ll see great developers use antipatterns or practices that are Considered Harmful™ and still churn out incredibly readable and easy to grasp code.
So what does it mean for your daily life?
If you want to keep learning about patterns and programming philosophies, please do so, but keeping it through the lens of “how can this make my code easier to read”.
But more importantly, whenever you write code, or review code, ask yourself: “Will that change make it easier to understand?” — and be brutally honest with yourself on that answer! — and soon you’ll see your code improve. You’ll feel uneasy putting in that small hack, you’ll refrain from building that unneeded abstraction, it will all fall into place.
And you’ll start growing again.