The Clean Coder: A Code of Conduct for Professional Programmers

Here are a few excerpts from the book that really stood out to me, and my own personal take on them. The book was an entertaining mix of anecdotes and advice geared towards the software developer who wants to take a professional approach to their career. To Robert C. Martin, programming isn’t just about the code, it’s about the attitude as well. Code you are passionate about and take your time on (as much as you can within the restraints of the real world!) will always trump code you threw together the night before a major deadline in a rush.

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!

This particular paragraph struck me because it really shows the difference between someone who takes responsibility and accountability for the code they write, and someone who just writes code to specifications and forgets about it. It’s easy to think that your employer will protect you from your mistakes, and to a certain extent they will. But to a professional, a mistake should be a learning experience and something that she is fully responsible for.

When you release your software you should expect QA to find no problems. It is unprofessional in the extreme to purposely send code that you know to be faulty to QA. And what code do you know to be faulty? Any code you aren’t certain about!

This one is important. A good programmer will test their code and be completely sure it works before they send it off to QA. Who knows how to test code better than the person who wrote it? QA can be good for catching things you may not have thought of, but they are not going to be aware of all the possible edge cases or situations that are necessary to test your code. Your goal should always be to make sure they find nothing.

Blind alleys are a fact of life for all software craftsmen. Sometimes you will make a decision and wander down a technical pathway that leads to nowhere. The more vested you are in your decision, the longer you will wander in the wilderness. If you’ve staked your professional reputation, you’ll wander forever.

Prudence and experience will help you avoid certain blind alleys, but you’ll never avoid them all. So the real skill you need is to quickly realize when you are in one, and have the courage to back out. This is sometimes called The Rule of Holes: When you are in one, stop digging.

Professionals avoid getting so vested in an idea that they can’t abandon it and turn around. They keep an open mind about other ideas so that when they hit a dead end they still have other options.

I can’t tell you how many times I used to tell my Project Manager that I had a solution, and dove in confidently only to find out a few hours later that what I originally thought to be a good solution would not actually work. The best thing to do is to communicate your concerns! If you think something is going to take longer, or that you need to scrap what you have entirely, you should communicate this effectively. Finding out that someone has made a promise you know you cannot keep is a horrible feeling, and one I actively try to avoid.

You create a solution to a simple problem, being careful to keep the code simple and clean. As the problem grows in scope and complexity you extend that code base, keeping it as clean as you can. At some point you realize that you made a wrong design choice when you started, and that your code doesn’t scale well in the direction that the requirements are moving.

This is the inflection point! You can still go back and fix the design. But you can also continue to go forward. Going back looks expensive because you’ll have to rework the existing code, but going back will never be easier than it is now. If you go forward you will drive the system into a swamp from which it may never escape.

This one ties in with the previous quote, but it also highlights the importance of not allowing yourself to get into technical debt. That nagging feeling that you really should restructure that module is something you should always listen to. Spend five or ten hours now, save yourself countless hours of agonizing over your now-incorrect design decision.

The problem is that we view estimates in different ways. Business likes to view estimates as commitments. Developers like to view estimates as guesses. The difference is profound.

This is something that took me a very long time to realize. I would throw estimates out there without realizing that most of the time, that is when something was actually promised to someone. Then, I would realize I needed more time, or that it was the due date but I had not spent enough time testing it. How horrible does it feel to launch code you know isn’t ready? Unfortunately, sometimes that is the reality when you make hasty commitments and the client, or your manager, is unwilling to budge. You should always make it clear what your estimate covers and does not cover, and communicate until you reach a number both parties can agree on. A reasonable one!

The way to go fast, and to keep the deadlines at bay, is to stay clean. Professionals do not succumb to the temptation to create a mess in order to move quickly. Professionals realize that “quick and dirty” is an oxymoron. Dirty always means slow!

You should not allow yourself to buckle under pressure and write sloppy code. You will only regret it later, and you will spend far more time wading through the muck you’ve created as a result. I believe given the choice, most people would rather have software with less features that really works well, than software loaded with features that is buggy and unpredictable.

You should plan on working 60 hours per week. The first 40 are for your employer. The remaining 20 are for you. During this remaining 20 hours you should be reading, practicing, learning, and otherwise enhancing your career.

Perhaps you think this is a recipe for burnout. On the contrary, it is a recipe to avoid burnout. Presumably you became a software developer because you are passionate about software and your desire to be a professional is motivated by that passion. During that 20 hours you should be doing those things that reinforce that passion. Those 20 hours should be fun!

This one definitely took me a while to learn. I used to tell myself that there was no way I’d go home and continue to code, or read about code, after already working a full day. When I got more disciplined and actually allocated that time, I realized that coding outside of work helped keep that passion alive that got me coding in the first place. I’ve also found that passion transferring back to the work place. It’s easy to care about the quality of something when you really are passionate about your work.

The frenetic rate of change in our industry means that software developers must continue to learn copious quantities just to keep up. Woe to the architects who stop coding–they will rapidly find themselves irrelevant. Woe to the programmers who stop learning new languages–they will watch as the industry passes them by. Woe to the developers who fail to learn new disciplines and techniques–their peers will excel as they decline.

This definitely ties in to the 20 hours above. Not only should you keep your passion alive, you should be engaging in new techniques and technologies regularly! In ten years, who knows what kind of platforms and languages will be the norm? Learning new things will also keep your perspective fresh–you might learn new ways of solving problems that you would have never thought of without it.

The promise to try is an admission that you’ve been holding back, that you have a reservoir of extra effort that you can apply. The promise to try is an admission that the goal is attainable through the application of this extra effort; moreover, it is a commitment to apply that extra effort to achieve the goal. Therefore, by promising to try you are committing to succeed.

How many times have you told someone, “I’ll try”? You might see it as an open-ended statement of “It might be finished, it might not.” Unfortunately for us, the person hearing that statement might see it as a “Great! They’re going to put in the extra time and effort to get this through on time. What a great guy!” I know I don’t write my best code when I’ve been stretching myself too thin. You should never commit to not doing your best.

Don’t write code when you are tired. Dedication and professionalism are more about discipline than hours. Make sure that your sleep, health, and lifestyle are tuned so that you can put in eight good hours per day.

You owe it to yourself to always write code with a fresh mind. Take a walk if you’re having a mental block. Get your blood flowing. Get a glass of water. Sometimes, just taking a short break, or a long one, means you can come back and really devote yourself to the task at hand. How many times have you struggled with a problem, only to go to sleep and solve it in ten minutes the next morning?

Professionals draw a clear distinction between estimates and commitments. They do not commit unless they know for certain they will succeed. They are careful not to make any implied commitments. They communicate the probability distribution of their estimates as clearly as possible, so that managers can make appropriate plans.

You might think you’re being a good team player by saying you’ll try to do something in a certain amount of time, but if you push code out that hasn’t been fully tested or is missing features, you’re only doing a disservice to yourself and your reputation. It is so important to make it clear what you mean when you commit to something, or when you are estimating how long something will take. Estimating things is hard, but not as hard as having to apologize for not having something ready when you said you would (or quite possibly the worst thing of all, sending code off you know is not ready and running into bugs in production–ouch.)

The first responsibility of the professional programmer is to meet the needs of his or her employer. That means collaborating with your managers, business analysts, testers, and other team members to deeply understand the business goals. This doesn’t mean you have to become a business wonk. It does mean that you need to understand why you are writing the code you are writing, and how the business that employs you will benefit from it.

This is so important. Without fully understanding why you are writing the code and business logic you are writing, how do you know your code works? It’s easy to test if code is functional, but what happens when you present the final product to your client and it’s not at all what they wanted, or you realize you’ve completely misunderstood their request? Not a fun time for anyone!