The Clean Coder: A Code of Conduct for Professional Programmers
Robert C. Martin
| Publisher | Prentice Hall |
|---|---|
| Published | 2011-05-23 |
| ISBN | 9780132542883 |
| Format | Ebook |
| Print pages | 210 |
| Genre | Computer Science |
Being a programmer is not just about writing code. Efficient teamwork depends on many other skills. After his classic “Clean Code” book, Robert C. Martin continues his mission of setting standards and creating good practices. This time you will not find a single line of code in his book. The author focuses on the developer himself.
Who is this book for?
The book is primarily targeted at programmers working in organised teams.
Even if you are a freelancer and are your own director, project manager and tester, you are not isolated from the world and need to contact the client, other people or organisations. If you want to act and be seen as a professional, this book is for you too.
But, if for some reason none of these situations affects you (eg. you are a hobbyist programmer) you probably will not be able to use most of the knowledge from this book. In this case reading the previous book, “Clean Code” will be a better investment of your time. You can always read this one later.
What can you learn?
Most of the chapters start with author’s memories of the old times and situations that taught him something. Sometimes it was a careless delivery of a non-tested system to a client, sometimes a lack of adaptability to the work environment, leading to being fired. These experiences are the basis for conveying knowledge to the reader so that they can avoid these problems.
Here’s a stripped down version of my notes.
Chapter 1 – Professionalism. Defines the behaviour of a professional programmer and the extent of the necessary knowledge.
Chapter 2 – Saying No. Often a programmer undertakes to perform unrealistic tasks in exchange for an imaginary prize of being considered a hero. The professional in such situations does not say “OK, I will try”, but refuses.
Chapter 3 – Saying Yes. Saying “yes” is easy, but you have to be responsible for every promise to do something within a certain time frame. “Talk is cheap, show me the code”.
Chapter 4 – Coding. It is important not to work in stress. Entering the Flow state gives you nothing. Overtime programming, in the long run, does not work too. You need to learn by reading and helping others.
Chapter 5 – Test Driven Development. If you have a set of tests, you can have the courage to make changes. But TDD is not the ultimate solution to all problems. You can still write ugly code, even with tests. Use this method when it is easy to work and it does not cause problems.
Chapter 6 – Practicing. All professionals practice; doctors, musicians, military men. Developers should practice between large tasks too. You can write Hello World in different programming languages. The author discusses the methods of exercises such as The Bowling Game, Kata, Wasa, Randori.
Chapter 7 – Acceptance Testing. As soon as possible business people want to know what they will get and programmers what to provide. The task of professional programmers and managers is to remove all the inaccuracies from the requirements. The best tool to use for this is acceptance tests. They are meant to determine when a customer and the programmer will agree that the requested requirement is met.
Chapter 8 – Testing Strategies. The pyramid of test automation consists of 5% of research, 10% of a system (GUI), 20% of integration (API), 50% of components (API), 100% of unit tests (XUnit). The author discusses all levels.
Chapter 9 – Time Management. The nightmare of unproductive and long meetings. Each meeting should have a plan and goals. If the organizer is unable to identify them, refuse to participate. Remember to regenerate, e.g. by walking, talking, meditating, listening to music. The author mentions the Pomodoro technique.
Chapter 10 – Estimation. Managers treat estimates as obligations and programmers as suppositions. The professional meets the obligations. Therefore, if you are not sure, do not take it. The author discusses techniques such as PERT, Wideband Delphi and Planning poker.
Chapter 11 – Pressure. Just like an operating surgeon, a professional programmer follows the learned procedure and stays calm. Avoid pressure, do not commit to terms that are unrealistic. The author describes methods to bypass the pressure.
Chapter 12 – Collaboration. Most programmers are introverts and they prefer to focus on the code alone. But the program should be owned by the team, not individual members. Everyone should be able to change any part.
Chapter 13 – Teams and Projects. It takes a time to clarify the team. Members practice collaboration, learn their strengths and weaknesses. Usually, a good team consists of about 12 people. Everyone should have a specific role in the team.
Chapter 14 – Mentoring, Apprenticeship, and Craftsmanship. Usually, students are not sent to work with the expectation of excellent results. However, many companies employ inexperienced people, build teams, and expect them to work on complex systems. The author discusses essential stages of development.
Appendix A – Tooling. Author’s favourite tools for version control, IDE, bug tracking, continuous compilation, unit tests, component tests and integration tests.
Summary
Phew! Quite a good deal of advice from an experienced programmer! If I had to summarise this book in two words they would be “professionalism” and “responsibility”. Definitely worth reading.
Now, there are no perfect books, so I have to add a few words of criticism. First: some readers may be bored with author’s memories of systems and computers from the 70s or 80s of the previous century. Technologies have changed, the management methods are different too. Second: example conversations between employees are too idealistic. Situations like “You have to code this by Friday, I promised this to the client.” – “Sorry, I have different tasks to do, deal with it.” – “OK!” are rather rare. BTW: that’s not a quote from the book, but you get the idea. And the last one: promotion of author’s program for testing. Come on, we get it, “FitNesse” is the best, no need to repeat that.
The book’s length is ca. 60 000 words. If you can spare 5 hours and 3 minutes (plus some time for making notes) for reading it, you will make a clear step towards becoming a professional programmer, a true Master Craftsman.
Thanks for the review. It sounds like a great book with a broad spectrum of topics covered. I just added it to my to-be-read pile.
I have to say that your stack is growing really fast (or you have used some kind of insertAt() method :)
Example conversation happened to me quite often, but without that “OK!” at the end :(
I think that you’re not the only one! It’s a pity that this book doesn’t discuss alternative endings of such conversations.
Thank you Mariusz for your notes on this book. These definitely tell me that I won’t waste my time reading it. This author seems to not understand that most software/firmware developers spend their careers at private companies where “refusing” and “saying no” are not options unless one wants to be removed (fired).
What we need is a book (and some new processes to replace all the agile spin-offs) that helps engineers find the best way to balance our professional desire to do it correctly vs. the business environment that we work in where we can either do what we’re told to do or leave. I am an embedded developer with over 30 years experience. Randall Ft. Lauderdale Florida USA.