Some time ago I found very interesting InformIT page with eBook Deal of the Day, where you can buy IT ebook for only 9,99$. Every 24h (or sometimes a bit longer) they change a title you can get for this amazing price so it is worth to check it from time to time or follow them on Twitter. And one day I noticed that they were selling last Robert C. Martin’s book titled “The Clean Coder”. It was so cheap and I was already impressed by “The Clean Code” so without the slightest hesitation I ordered one electronic copy and started reading.
My opinion
This title joins my set of books which should be read by every developer aspiring to become better and better. It shows how we, as developers, can behave as a professionals and as a result be perceived and treated like professionals. Robert C. Martin basing on his experience (did you know that he is a programmer for 42 years!?) shows us how to improve or change our habits, our communication and collaboration skills to become more valuable part of our team, our company and finally our client. Below I present some main thoughts from some chapters of this great book.
Chapter 1: Professionalism
In first chapter we can learn that being a professional has some drawback too. We should take responsibility for our actions and we can not take our potential mistakes lightly. Every mistake we made has some more serious implications, for example: client can loose his patience or trust to our company or software might crash and cause large finance loss. So as a professional we should concentrate not only on adding new features but also or even mainly how not to harm existing system.
You must be able to make changes without exorbitant costs
Our code and your architecture must be flexible to allow future changes to be as painless as possible.
Chapters 2 and 3: Saying “No” and “Yes”
Next two chapters are about saying “No” and “Yes”. We should not be afraid to tell that adding a feature is impossible in a given time so team or project manager could react properly. And the earlier we say “No” the better. Although we should always try to find a solution to say “Yes” by, for instance, removing some less important elements from feature or postponing another feature for later iteration so this more important one could be finished on time.
Slaves are not allowed to say no. Professionals are expected to say No
There is no trying
The worst thing developer could say when someone is pushing him to complete a task faster that he knows it is possible is “I will try” because it means that you could put some extra effort (so before that you weren’t working at full speed?) and by applying this additional effort goal will be achieved. So without saying “Yes, I will do that” you unintentionally have just made a commitment that this task will be done. So “there is no trying” when estimates shows that we have less time than needed.
Don’t try to be a hero
Temptation to take a short cut and omit writing tests, refactoring, using design patterns just to finish on time and become a team/company hero can be strong, but this lack of good practices will hit you later and it will hit you badly causing more delays and frustration than constantly sticking to your good habits and practices.
Chapter 4: Coding
In this part Uncle Bob is saying that the famous state of mind called “Flow” or “Zone” is not as good as most people think. Of course it allows developer to stay focused on a single task but what is a big disadvantage, it prevents him from seeing a big picture, a context of what he is currently doing. It might lead to bugs, code duplication and misunderstandings how current code fragment should talk with other parts of the system. The best way to avoid entering Zone is Pair Programming, when you need to often switch from Driver to Navigator.
Creative output depends on creative input
We are creating something. We have to be creative. And one of the ways to increase our creativity is to feed our mind with creative ideas by reading various books. For Uncle Bob it is science-fiction, but for someone else it could be a good thriller or even poetry.
Chapter 12: Collaboration
In this chapter author concentrates on communication process between developers, developers and client and developers and boss/project manager/etc. Currently most projects are not developed by lone person but by a team consisting of different people and different personalities, so soft skills and communication skills are as important important as our programming skills.
It’s good to be passionate about what we do. But it’s also good to keep your eye on the goals of the people who pay you.
You might work better alone but your team definitely won’t when you work alone.
Programming is all about working with people: you must please client, you must understand BA
The clue of this chapter is that we should be able to cooperate effectively with other people to be a professional. We need to improve out communication skills, we need to think not only about ourselves but also about our company and our client. Because at the end thanks to them we can pay our bills.
Some valuable ideas and quotes from other chapters
Hope is a project killer
If your estimation shows that you need at least two weeks to finish this task and demo is in five days you can not hope to finish it on time. Instead of saying that you hope to be ready for a demo you should inform everyone interested in deadlines that this feature won’t be ready and something needs to be done about it.
An estimate is a guess. Not a commitment
As @jaimeohm wrote on Twitter some time ago:
Coders are special. “We are expected to know how to do things we’ve never done before and estimate how long they will take.”
We just estimate. Of course we try to be as accurate as possible but our estimations are not 100% correct. We should educate our project managers that the estimation can not be treated as a commitment or a hard number.
Teams should be feeded with projects not project feeded with developers.Teams are harder to build than projects.
Team of developers should not be created just for a single project, then disbanded and when another project appears, formed again but with different people which were available at that moment. Team needs some time to consolidate, to create relationships between metrue, mbers. Team which was given enough time to do so is more productive and works in a more constant and predictable velocity. So instead of creating teams for a project, the more emphasis should be put on finding projects for gelled team of developers who know each other well.
Summary
These quotes presented above are my favorite but if you read this book (and I strongly recommend it) you will probably find different set of wise sentences and thoughts inside. And then, after rethinking them, you will be a few steps closer to become a better developer. And from who should we learn if not from Uncle Bob and his 42 years of experience?
