Reviewed in the United States on March 18, 2012
I've been interested in the notion of a professional programmer for a very long time, at least since my first reading of Gerald M. Weinberg's The Psychology of Computer Programming made me see the difference between amateur and professional programming. Heck, I like to think that I am a professional programmer. Then, along comes Bob Martin's The Clean Coder, containing "a lot of pragmatic advice in an attempt to answer questions such as":
* What is a software professional?
* How does a professional behave?
* How does a professional deal with conflict, tight schedules, and unreasonable managers?
* When, and how, should a professional say, "no"?
* How does a professional deal with pressure?
The subtitle, A Code of Conduct for Professional Programmers puts some significant weight on this book. And The Clean Coder is a pretty darn good book. For example, the first chapter is "Professionalism", and the first section is "Be Careful What You Ask For" with the following question:
"What would happen if you allowed a bug to slip through a module, and it cost your company $10,000? The nonprofessional would shrug his shoulders, say 'stuff happens', and start writing the next module. The professional would write the company a check for $10,000!"
Martin's comments on taking responsibility, and on saying "no" (and also on saying "yes" and meaning it) are spot on. His chapter on estimation is very good as well, emphasizing the distinction between an estimate and a commitment and introducing PERT estimates, which I seem to have managed to miss before.
The list of good things about The Clean Coder goes on and on, including handling pressure, teams, and the development of a professional programmer from an apprenticeship. Further, the whole mass is leavened by Martin's war stories, dating back into the dim mists of antiquity and dealing with both his successes and failures.
The book, which is not that big and a quick read, covers a wealth of advice at a high-level, with pointers to learn more. Many of those topics, as I have tried to point out above, are all over professionalism for the programmer. Things like responsibility, handling pressure, and mentoring. But there is other advice in the book which does not have the same pedigree. Some of it would appear to be a "nice-to-have" rather than a requirement. Then there are things that seem to be Martin's personal opinions. And then, there is stuff that is just bizarre.
I don't want to get into the case for test-driven-development here. It works, well. (But then, so do code inspections, seemingly even better, and I have plenty of evidence for that. Yet it doesn't get the same press. And no, pair programming is not the same thing.) But the vast majority of working code in the wild was not produced by TDD. I can lay hands on more than a few very professional programmers who think unit tests are not worth their opportunity costs, to put it mildly. I will go as far as saying that unit testing is a good idea, and that TDD, in a lot of cases, gives me more confidence in my code. But I cannot go along with making it a requirement for professional programming.
Appendix A, Tooling, has a nice list of useful development tools. "Tomato" time management is interesting. "When the heat is on, find an associate who is willing to pair program with you." Ok. I personally think "craftsmanship" is a good way to describe good programming. Most of the time, anyway. On the other hand, with all respect to Uncle Bob, if I tried, I could also track down a fair number of embedded and safety-critical software developers who regard the whole "agile" thing with a mixture of disbelief and horror.
But what about this:
"Much has been written about the hyper-productive state known as "flow." Some programmers call it "the Zone." Whatever it is called, you are probably familiar with it. It is the highly focused, tunnel-vision state of consciousness that programmers can get into while they write code....
"Here's a little hint from someone who's been there and back: Avoid the Zone.... Code written in the Zone may come out faster, but you'll be back to visit it more....
"One of the big benefits of pair programming is that it is virtually impossible for a pair to enter the Zone...."
Let me just say that I don't have my copy of Mihály Csíkszentmihályi's books handy. But I do seem to recall that a reduced error rate is one of the definitive benefits of flow. Further, Martin's description of the Zone as "tunnel-vision" and "uncommunicative" directly contradict Csíkszentmihályi's description of flow in team sports. On the other hand, Martin's comments also contradict both the common description of pair programming's feel, and Martin's own comments about "focus-manna".
And then there's the "Coding Dojo". Now look, I am a big fan of toy problems. They're fun, they're relaxing, working on one is roughly the equivalent of a situation comedy: everything gets wrapped up in 22 minutes. Better, they're good ways to try out something new, to explore a problem, or to isolate some issue so that you can examine it without getting lost in the surrounding weeds. But when Martin writes,
"In 2005 I attended the XP2005 Conference in Sheffield, England. I attended a session with the name Coding Dojo led by Laurent Bossavit and Emmanuel Gaillot. They had everyone open their laptops and code along with them as they used TDD to write Conway's Game of Life....
"A programming kata is a precise set of choreographed keystrokes and mouse movements that simulates the solving of some programming problem. You aren't actually solving the problem because you already know the solution. Rather, you are practicing the movements and decisions involved in solving the problem."
Well, after that, I've got nothin'. Sorry.
In the end, Clean Coder has a lot of very good advice, a lot of good philosophy about programming professionalism. It also has many entertaining stories. But I, as a (possibly delusional) professional programmer, just don't see it as a grand manifesto.