Top 5 Lessons From The Book Clean Coder
Want to read Clean Coder but don't have the time? Check out my 5 most essential tips from this book.
Technical books are essential for developing your career as a software developer. Many concepts resist time and are common across all stacks, whether you are an iOS Developer or a Backend Developer.
The Clean Trilogy
The word "clean" when referring to software has been around for a long time. It was first introduced in the 2007 book Clean Code: A Handbook of Agile Software Craftsmanship.
To better understand what clean means, let's read Leonardo Giordani's definition in the book Clean Architectures in Python.
(clean) describes one of the fundamental aspects of both the software structure and the development approach of this architecture. It is clean, that is, it is easy to understand what happens.
With the interest generated by the first book, the author, Robert C. Martin, wrote two additional books on this topic: The Clean Coder: A Code of Conduct for Professional Programmers (2011) and Clean Architecture (2017). This article will focus on the first.
Now, let's dive in on my top 10 teachings from the book The Clean Coder.
5: Take Responsability
One of the first lessons Robert Martin discusses in his book is that a professional holds himself accountable. This is very important because when something doesn't work out, you often attribute the fault to something external to yourself.
Robert Martin exemplifies a case that might've happened to you. He shipped a new feature without extensively testing it and ensuring no bugs. Since he wanted to ship software on time and the testing process took hours, he felt safe enough to ship it without testing.
Here's a passage from the book:
The reason I neglected the test was so I could say I had shipped on time. It was about me saving face. (...)
I had only been concerned about my own reputation
How many times has this happened to you? That's why taking responsibility and being transparent about shipping software with quality to the customer is so important.
4: Learn How To Say No
As a software developer, you will work with many people across different stacks; some will be managers and product owners who don't know/care how the software works as long as it works. It's up to you, the engineer, to know that.
So, when you're involved in the delivery process, you must learn to be realistic and know how to say no. According to the author:
If you know full well that getting the login page done by tomorrow is impossible, then you are not doing your job if you say “OK, I’ll try.” The only way to do your job, at that point, is to say “No, that’s impossible.”
It's paramount to establish clear communication and know how to say no.
I highly recommend you check out the conversation examples in Chapter 2: Saying No about this topic.
3: Clients Don't Care About The Product As Much As You Do
Bear with me now when I say client; I mean the person hiring you to build an application.
The author's story in chapter 3 best represents this lesson. When he was hired to build an app for a big company, he worked very hard on it because the client wanted it for Black Friday of that year (which was two weeks away).
He built the product after working tirelessly on it (pulling all-nighters and 74+ hour work weeks).
The only thing needed to finish the app was an app description. The clients didn't even care to respond to his e-mails.
After all was said and done, the company decided not to release the app due to organizational changes.
I’d sacrificed my family for a two-week super sprint, and no one at Gorilla Mart could be bothered to create an app description given a week of time.
And the most important lesson here:
Professionals become heroes when they get a job done well, on time, and on budget.
By trying to become the man of the hour, the savior of the day, John was not acting like a professional.
2: Know When To Walk Away
How often have you stayed late doing something at work because you felt close to finding the solution?
How many times did your colleagues at college brag about pulling an all-nighter?
We often sacrifice our comfort and well-being to deliver something, but we forget that the more tired we are, the more bugs we introduce in the app. You're lying to yourself if you think that working tirelessly without breaks makes you more productive.
You should know when to stop and when to disengage from a problem.
1: Know How To Accept Help
As software engineers, we often feel pressured to exceed expectations and avoid showing any signs of weakness. Asking for help can be particularly challenging because it might imply a lack of knowledge.
As the author points out, "(...) programmers tend to be arrogant, self-absorbed introverts", which can make accepting assistance even more difficult.
However, it's crucial to recognize the importance of allowing yourself to be helped. When someone offers assistance, embrace it and remember not to be overly protective of your territory.
Collaboration and support are essential for growth and success in our field.
This includes pair programming, which, according to Robert Martin:
I find this odd since most programmers will pair in emergencies. Why? Because it is clearly the most efficient way to solve the problem.
To truly excel as a professional in your field, it's essential not to isolate yourself. Instead, actively seek to learn as much as possible from your colleagues.
Embrace collaboration and be open to the knowledge and insights others can offer.
Conclusion
Clean Coder is an exceptional book, whether you're just beginning your career as an engineer—or in any field—or you already have years of experience. Its advice has stood the test of time, making it a staple reference in the software world.
I hope you enjoyed this article. Thank you for reading. 💖
References
