Working Effectively with Legacy Code by Michael Feathers, Refactoring by Kent Beck and Martin Fowler, The Mythical Man-Month by Fred Brooks, and countless others.
You know them, you probably agree with all if not mostly because they give situations, scenarios, and guidelines of what to do. Sometimes you know and agree without even having read them.
Then you have Clean Code by Robert “Uncle Bob” Martin. Love or hate it, it’s easier to find someone who has read and has an opinion about it than the others you just “agree with”. Why is that?
The power of “creating rules”
I was listening to a podcast where the hosts and guests were discussing programming books and of course, the Clean Code was mentioned. Some liked it, others didn’t and no other book had generated that kind of discussion.
The thing that Clean Code does that other books don’t is that it’s not a “discussion”, it doesn’t “depend”, it just “is”. There are “rules”, there is a “right” and a “wrong”, and you should follow them, period.
This makes people either love it or hate it. People who don’t know it better probably love it because you don’t need “to think”, you just need to follow the rules. Others that know better, know that it “depends” and for situation ABC it would be better XYZ.
This is also the internet today
If Clean Code were a “normal” book presenting multiple scenarios and best practices that “depends” and everything other books do… it would be “just another book”.
People would read, agree, learn something, close it and that would be it. But by making it about “this is right” and “this is wrong” it became unique.
Junior or Senior? Well… it DEPENDS!
Some time ago, I learned that one thing that makes someone junior or senior is the “depends”.
A junior doesn't know better, so there’s no “depends”. It’s a person with a hammer trying to make everything a nail to be hammered.
The internet loves to joke that you’re a senior when everything can be answered with “depends”. But that’s just the first step into seniority.
Transcending senior means that, yes, while everything “depends”, you know how to narrow the options down… to the one to follow and tell everyone else “why”.
Junior needs rules.
So, since a junior doesn’t know better than the hammer in their hand, this means they need clear rules of what to do and what not to do.
Even if the rules are not the best for that situation, I can say that it doesn’t matter and that’s where a book like Clean Code shines! Right or wrong, it tells people one way of doing things, no thinking needed.
With time they will probably find multiple situations where the rules don’t apply and it will feel weird to try to apply the rules handed down to them… so they won’t.
With time, their repertoire of “depends” will grow until…
Senior needs guidelines.
Everything will be a “depends”.
You learned multiple tools, you passed through multiple situations. So you know there are multiple approaches and that’s just what you know you can pull off because there would be a lot more that you know are a possibility but never actually tried.
You don't need rules, because you know they won’t fit all problems. However… guidelines? That you can welcome.
With guidelines you can trim multiple “depends” right off the bat and make steps to transcending “senior” because you will be able to trim and narrow the decisions more effectively.
So, the “normal” books come with the solutions here. Probably not on a silver plate. But it will be there and will help with multiple problems to come.
I’m totally right about it, trust me. ;)
Jokes aside, I have a quote that fits here and sums up the “why” I write stuff:
"The purpose of a storyteller is not to tell you how to think but to give you questions to think upon." - Brandon Sanderson
Although for me it’s the other way around. Something comes up that makes me think about it, then I write because it’s what I thought about it.
Top comments (7)
Rules and guidelines are only needed in an employee employer relationship.
When coding there are no rules. You are free to write your code as you see fit. There are no coding police that will come and arrest you if you do not follow SOLID principles.
clean code != performant code
When I'm being charged by the milisecond, performance matters. I could care less as to how many rules or guidelines I break in my quest to get the fastest code possible.
For developers who are a one person team (such as myself), I would suggest not getting mired in the fine details and prop up a MVP of there idea ASAP just to see if the idea will even work. As you explore different technologies that may assist you in your project, then work in any rules/guidelines/coding style that makes sense to you. After all it is your project so have fun with it :)
Happy Coding
I get your point, but you also have to account for developer time.
Those miliseconds you can shave, how much developer time later on does it generate in technical debt?
There is a point where developer time would be less than whatever the gains are in performance, but that isn't a reality for most people, in most cases and in most applications.
Saving dolars in performance when you waste hours and hours of developers making 6 figures isn't a good trade off.
Time and time again, a cleaner code is shown to be better in the long run as far as developer time spent is considered. And as you said: the important thing is to put out value.
Finally, a MVP should be disposable, so it doesn't really matter because it's something for a sprint and not for a marathon.
There is not a single person on my one person team that makes six figures :) But I get your point and agree that any team manager who didn't consider such things would be considered negligent.
My point is that for people such as myself who develop alone, you are the team, you get to decide what rules/policies/guidelines/coding style you want (or not) to enforce.
Being a lone wolf developer, I have realized that no one looks at my code but me, no one gives a crap about my code but me, so why am I following all these rules when I don't have to and instead write my code, my way, the way that makes sense to me.
And yes, all this rampant rule breaking has made coding fun for me again :)
Follow the rules, Don't follow the rules, it's a choice not a requirement.
Happy Coding
You do you =D
And for toy projects, no one really cares.
But for projects that are "marathons", even working alone, there are things you can help your future self with: dev.to/noriller/im-stoopid-so-i-co...
At least it's what I do.
Hey @noriller ! 👋,
I completely resonate with your thoughts on the power of rules and guidelines in software development. It's interesting how certain books, like "Clean Code" by Robert Martin, generate strong opinions and discussions among developers. I believe it's because "Clean Code" presents a set of rules that are presented as definitive and non-negotiable. This black-and-white approach appeals to some people who prefer clear-cut guidelines to follow without much ambiguity.
However, as you rightly pointed out, the reality of software development is often more nuanced. Situations can vary, and what works in one context may not work in another. This is where the concept of "depends" comes into play. As developers gain experience and knowledge, they understand that there are multiple valid approaches to solving problems. The ability to navigate these possibilities and make informed decisions is a crucial aspect of seniority in the field.
For junior developers, having clear rules can be helpful as they are still building their knowledge and expertise. It provides them with a starting point and a framework to follow. Over time, as they encounter different scenarios, they begin to see situations where the rules don't apply or might need adaptation. This expanded understanding leads to the development of a broader repertoire of "depends" and a deeper appreciation for the nuances of software development.
As developers progress and become more experienced, they transition from relying on rigid rules to embracing guidelines. Guidelines provide a flexible framework that helps narrow down the available options without being overly prescriptive. They offer insights, best practices, and considerations that can guide decision-making. With guidelines, senior developers can effectively navigate complex problems and make informed choices based on their experiences and expertise.
I couldn't agree more with your quote by Brandon Sanderson. As developers, our goal should be to provoke thought and provide different perspectives rather than dictate how others should think or code. Writing about our thoughts and experiences allows us to share our insights and inspire others to explore and question the norms.
In the end, the software development journey is a continuous learning process. We evolve from following rules to understanding guidelines, constantly expanding our knowledge and refining our problem-solving abilities. So keep exploring, thinking, and sharing your ideas—it's through this collective growth that we advance as software freestyle engineers (like me 😎).
Wishing you all the best on your ongoing journey of discovery and learning!
Cheers!
Hi, thanks for the response, but I feel like this is just the post paraphrased back... so I have to ask: did you use somethingGPT to do that?
Thank you for asking, somehow when I reply or respond to every post anywhere, I am always considered ChatGPT. Is it possible for AI to be so addictive that something that could be made by humans is then considered AI and vice versa? If I answer "no it's not ChatGPT" what might happen? and if I answer "yes it is AI", doesn't Google Translate also include AI?
Sorry, I'm confused about how to answer.