Professional Programming: Reflections on The Clean Coder

Over the past week, I had the pleasure of reading Robert C. Martin’s The Clean Coder: A Code of Conduct for Professional Programmers. The text is an insightful and thought provoking meditation on what it means to be a software professional, one that aggresively challenges many habits and practices that developers might otherwise passively accept if not actively condone.

Among Martin’s targets: working in “the Zone”, agreeing to “try” to meet a rushed deadline, and foregoing time-consuming procedures to put together a “quick and dirty” solution. Though we could surely envision downsides to all of these practices, I’d wager that most of us are guilty of having partaken in each of them at one point are another.

Still, the author’s wealth of professional experience and his keen sense for the big picture yields such a compelling case that I’d like to reflect upon it here. Though there are a plethora of other valuable tidbits that probably merit equal consideration, for the sake of space I’ll be sticking with the points listed above in this post.

Speed Kills: Stay Out of “The Zone”

Most of us are familiar with “the Zone”, the sense of flow that comes from completely immersing yourself in a problem. I think it’s one of the things that first drew me to programming; I knew I was hooked when I found myself losing track of time coding into the night.

But Martin is explicit in his opposition to this form of coding. He urges us explicitly, “Avoid the Zone” (62). His case: your sense of infallibility in the zone is hubris, it’s accompanied by reduced mental faculties for careful consideration, and it yields technical debt that costs significantly more time later to clean up.

I’ll admit, I was a little skeptical of his case at first. If my goal as a professional is to produce working software for my clients and I do so more quickly when I’m in the zone, then shouldn’t that be something I strive for?

What pulled me over to his side was when he brought up pair programming. I know that some of my favorite code has come from pairing - having two minds working on the same problem somehow yields better solutions than either partner would have written on their own. And Martin points out, “it is virtually impossible for a pair to enther the Zone” (62).

Upon consideration, that’s true. Pairing forces you to constantly communicate what you’re doing, to be deliberate about each decision you make. You can’t immerse yourself fully in the code, because you have to pay attention to the person you’re pairing with.

If pair programming yields the best code because it’s more considered and deliberate than code produced in the zone, then it stands to reason that carefully put together code is better than code produced in the zone. Professionals should clearly strive to produce the best output that they can, so perhaps our collective affinity for the zone ought to be rethought.

Saying Yes Or Saying No: There Is No Try

One of the more striking passages in Clean Coder comes when Martin is instructing software professionals to never say “try”. In juxtaposition with the more colloquial understanding of the term which sees it as a commitment to a good faith effort, Martin sees “try” as a commitment to results. He writes, “by promising to try you are committing to succeed” (33).

At first, I found myself fighting against this passage. That not what I mean when I say “try”!

But then I found myself thinking, what do I mean when I say “try”? Generally, I mean I’m unsure - I don’t have a good enough sense of my own abilities and priorities to make a commitment.

Professionals need to know what they can do. They need to be able to communicate their abilities to those who depend on them. A professional who waffles and agrees to “try” is not acting professionally - they’re expressing a poor understanding of their own abilities.

My takeaways are twofold. First, anytime I might think of saying “try”, I need to find a way to convert that to a clean “yes” or “no”. If I’m not sure, that’s a “no”. Second, I need to be vigilant about improving my ability to say “yes”. If I frequently have to say “no” because I lack ability, then I need to do a better job of holding myself up to the standards of my profession.

Avoiding “try” isn’t just eliminating a word from your vocabulary. It’s bringing yourself in line with the practices of a professional.

When The Going Gets Tough: Staying Disciplined

A common motif in Clean Coder is discipline. A professional exhibits discipline by following through on commitments, exhibiting a strong work ethic, and sticking to best practices. Though a discussion of discipline is not surprising in a text on professionalism, I was intrigued by Martin’s emphasis on avoiding “quick and dirty” solutions.

We’ve all been in situations where we believe we can accomplish a task more quickly by circumventing some of the more time-consuming procedures that we use to produce good work. Whether it be in spiking out a problem rather than following the incremental progression of test-driven development, shipping in code that “works” even if we know it should be cleaner, or working late into the night even though we can sense that our mental capacity is diminished, sometimes it just feels right to compromise on best practices in the interests of shipping code.

Martin puts up a big stop sign in front of that line of thinking. In fact, he inverts the very underpinning that gives rise to such sentiments: disciplines are not something that carry us through the good times but can be put aside when the going gets tough; rather, “the reason you have disciplines is to give you guidance through times of high pressure” (154).

This was one of those points that felt so obvious I couldn’t really conceptualize how I had ever thought otherwise. If a patient is rushed into an emergency room with an urgent issue, that doesn’t mean the doctor isn’t going to wash their hands. If an airline is running behind schedule and needs to move more quickly, that doesn’t mean a pilot is going to skip procedures like checking that the plane’s carrying enough fuel.

A software professional only takes up those disciplines which they believe will improve the quality of their work, so such disciplines cannot be sacrificed in the interest of professional output. The only output a professional will produce is output produced in adherence with professional standards.

Conclusion

If there’s one thing that ties together all of the points I’ve mentioned here, it’s that professional software developers need to think of themselves as professionals. Perhaps we don’t think of ourselves in the same way that we think of surgeons, pilots, attorneys, and the like, but maybe we should. And even if we don’t attribute to ourselves the same prestige or dress codes, that’s no excuse for compromising on professional standards.

A professional works through processes that generate high quality output, is clear in communicating what they can do and on what timeline, and does not compromise on their professional standards. Clean Coder was an excellent reminder of all of these propositions.