Clean Coder, The: A Code of Conduct for Professional Programmers (Robert C. Martin Series)

by Robert C. Martin

It is the structure of your code that allows it to be flexible. If you compromise the structure, you compromise the future.

You must be able to make changes without exorbitant costs.

I call it “the Boy Scout rule”: Always check in a module cleaner than when you checked it out. Always make some random act of kindness to the code whenever you see it.

Your career is your responsibility.

Woe to the software developer who entrusts his career to his employer.

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.

Here is a minimal list of the things that every software professional should be conversant with:

• Artifacts: You should know how to use: UML, DFDs, Structure Charts, Petri Nets, State Transition Diagrams and Tables, flow charts, and decision tables.

Doing your daily job is performance, not practice. Practice is when you specifically exercise your skills outside of the performance of your job for the sole purpose of refining and enhancing those skills.

The best way to learn is to teach. Nothing will drive facts and values into your head faster and harder than having to communicate them to people you are responsible for.

It is the responsibility of every software professional to understand the domain of the solutions they are programming.

It is the worst kind of unprofessional behavior to simply code from a spec without understanding why that spec makes sense to the business. Rather, you should know enough about the domain to be able to recognize and challenge specification errors.

Professionals speak truth to power. Professionals have the courage to say no to their managers.

The real truth is that you, personally, ALWAYS have something that’s under your control, so there is always something you can fully commit to doing.

You can only commit to things that you have full control of.

Avoid the Zone. This state of consciousness is not really hyper-productive and is certainly not infallible. It’s really just a mild meditative state in which certain rational faculties are diminished in favor of a sense of speed.

In the end, of course, there will be interruptions that distract you and cause you to lose time. When they happen, remember that next time you may be the one who needs to interrupt someone else. So the professional attitude is a polite willingness to be helpful.

When you are stuck, when you are tired, disengage for awhile. Give your creative subconscious a crack at the problem. You will get more done in less time and with less effort if you are careful to husband your resources.

regularly measure your progress against your goal, and come up with three4 fact-based end dates: best case, nominal case, and worst case.

Do not incorporate hope into your estimates! Present all three numbers to your team and stakeholders. Update these numbers daily.

Hope is the project killer. Hope destroys schedules and ruins reputations. Hope will get you into deep trouble.

You are not likely to get 20% more work done by working 20% more hours. What’s more, overtime will certainly fail if it goes on for more than two or three weeks.

you should not agree to work overtime unless (1) you can personally afford it, (2) it is short term, two weeks or less, and (3) your boss has a fall-back plan in case the overtime effort fails.

It is unprofessional to remain stuck when help is easily accessible.

We didn’t get into this business because we like people.

Therefore, since for many of us collaboration is not an instinct, we require disciplines that drive us to collaborate.

The Three Laws of TDD You are not allowed to write any production code until you have first written a failing unit test. You are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing. You are not allowed to write more production code that is sufficient to pass the currently failing unit test.

But the tests you write after the fact are defense. The tests you write first are offense.

Professional programmers practice on their own time. It is not your employer’s job to help you keep your skills sharp for you. It is not your employer’s job to help you keep your resume tuned.

I, on the other hand, learned a powerful lesson about how customers actually discover what they need. I learned that their vision of the features does not often survive actual contact with the computer.

In the end, the more precise you make your requirements, the less relevant they become as the system is implemented.

It is the responsibility of professional developers (and stakeholders) to make sure that all ambiguity is removed from the requirements.

Integration tests are choreography tests. They do not test business rules. Rather, they test how well the assembly of components dances together. They are plumbing tests that make sure that the components are properly connected and can clearly communicate with each other.

System Tests These are automated tests that execute against the entire integrated system. They are the ultimate integration tests. They do not test business rules directly. Rather, they test that the system has been wired together correctly and its parts interoperate according to plan.

There are two truths about meeting. Meetings are necessary. Meetings are huge time wasters.

be very careful about which meetings you attend and which you politely refuse. The person inviting you to a meeting is not responsible for managing your time.

One of the most important duties of your manager is to keep you out of meetings.

I’ve developed a simple rule: When the meeting gets boring, leave.

If you find yourself stuck in a meeting that is not a good use of your time, you need to find a way to politely exit that meeting.

“Any argument that can’t be settled in five minutes can’t be settled by arguing.”

force of will doesn’t settle disagreements for long. Data does.

Programming is an intellectual exercise that requires extended periods of concentration and focus. Focus is a scarce resource, rather like manna.

Focus-manna is also a decaying resource. If you don’t use it when it’s there, you are likely to lose it.

Worry and distractions also consume focus-manna.

I have found that once the manna is gone, you can’t force the focus. You can still write code, but you’ll almost certainly have to rewrite it the next day, or live with a rotting mass for weeks or months. So it’s better to take thirty, or even sixty minutes to de-focus.

muscle focus helps to recharge mental focus.

there is something about activities that focus on muscles that enhances the ability to work with your mind.

The Rule of Holes: When you are in one, stop digging.

Business likes to view estimates as commitments. Developers like to view estimates as guesses. The difference is profound.

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!