# The Clean Coder

Posted on March 18, 2012 by Tommy McGuire
Labels: software development, books

He said something like, "Bad news. Legal doesn't have the enrollment forms ready, so we can't go live yet.

[...]

Joe: "Matt, these are professionals. We can't just stare them down and insist they sacrifice their personal lives for our little project."

Matt: (pause) "...Joe...what do you think we've been doing to the engineering team for the past four months?"

Joe: "Yes, but these are professionals."

[...]

Somehow, another group had convinced Joe that they did not need a babysitter, that they were not playing games, and that they needed to be treated as peers who were respected.

Then I learned that being a professional means never getting called out.

That lesson is courtesy of Matthew Heusser in the Forward of The Clean Coder: A Code of Conduct for Professional Programmers, by Robert C. "Uncle Bob" Martin.

## Professional programming

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. I mean, whole task-forces have been dedicated to such, and come away bedraggled and bearing only a limp and battered list of noble but abstract platitudes.

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:

When you estimate a task, you provide three numbers....

• O: Optimistic Estimate. This number is wildly optimistic. You could only get the task done this quickly if absolutely everything went right. Indeed, in order for the math to work this number should have much less than a 1% chance of occurrence....
• N: Nominal Estimate. This is the estimate with the greatest chance of success. If you were to draw a [probability distribution], it would be the highest bar....
• P: Pessimistic Estimate: Once again, this is wildly pessimistic. It should include everything except hurricanes, nuclear war, stray black holes, and other catastrophes. Again, the math only works if this number has much less than a 1% chance of [occurrence].

Given these three estimates, we can describe the probability distribution as follows:

$$\mu = \frac{O + 4N + P}{6}$$

$$\mu$$ is the expected duration of the task.... For most tasks, this will be a somewhat pessimistic number because the right-hand tail of the distribution is longer than the left-hand tail.

$$\sigma = \frac{P-O}{6}$$

$$\sigma$$ is the standard deviation of the probability distribution for the task. It is a measure of how uncertain the the task is. When this number is large, the uncertainty is large, too.

One nice property of these estimates is that, besides producing what seems to be pretty reasonable numbers, they can also be combined meaningfully (more or less) to produce a higher-lever estimate.

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.

But...

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.

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, cannot accept it as a code of conduct.

Two thoughts:

1. I couldn’t disagree more with Uncle Bob's thoughts about "flow". When I'm in this state I feel as though I write my best code (in addition to writing it quickly - relatively).

2. I think TDD (or unit testing in general) is too many times sold as a silver bullet for ensuring code correctness. I do think it can help in that regard but an equal (and many times greater) benefit for me is that it forces me to write modular code with clean interfaces. Having some other system other than the "framework" be able to execute your code is a good indicator that you haven't just written a big, stinking pile of spaghetti.
cbass

Clean Coders is a fabulous book, it has proven beneficial to me in different ways. The sections on interacting with stress and utilizing irrational managers did keep out somewhat and also the sections on evaluation and calculating how long something will take has some very exciting ideas.

Lumen Fox
'2012-04-03T01:41:14.097-05:00'

Sure, it's got some good ideas. But "fabulous"?

I still prefer The Psychology of Computer Programming by Gerald Weinberg as far as many of those kinds of topics go.

Tommy McGuire
'2012-04-03T10:20:17.806-05:00'

An interesting discussion is worth comment. I believe that you should write extra on this topic, it might not be a taboo subject however generally individuals are not enough to speak on such topics.

Web development Company
'2013-06-05T04:47:25.731-05:00'
Site proudly generated by Hakyll.