Clean Coder Notes

During the weekend, I decided it was a good time to re-read Uncle Bob’s classic work on what it means to be a profressional software engineer. The book has so many amazing stories and nuggets of wisdom that would look great hanging above a desk; immortalized in needlepoint. Being that I’m unable to sew, I present my notes with the hope that they will be useful to others just beginning Clean Coder for the first time, or perhaps re-reading for the Nth.

——– BEGIN NOTES ——–

What it means to be Professional

Being a professional means taking repsonsibility for ones work.

If you don’t know the problem domain, get a book and learn about the domain. Don’t just code from a spec. Without domain knowledge it’s impossible to build a mental model of the problem domain.

Professionals know their limits and take care of their bodies and minds. Development is a marathon, not a sprint.

A professional knows when to ask for help. A fresh perspective on a problem is invaluable when stuck.

US vs Them

There is no “us” and “them”. Professionals identify with their employer and understand their problems. Identifying with other developers instead of with the greater company causes a wall to be built between yourself and people whose problems need solving.

Confidence and Failure

A professional is confident in their abilities and not falsely humble. There are times when professionals will fail and they accept failure for what it is, laugh it off, and live to code another day. Programming is an act of creation. It requires supreme skill, concentration, and also a little luck. Despite our best efforts, things can and will fail. Prepare for it. Don’t be an asshole because your day may be next!

Saying NO

It is impossible for a slave to say ‘no’. Professionals are expected to say ‘no’. Saying ‘no’ is the only way to really get things done. A professional defends their objectives just as a manager demanding ‘the moon’ by Friday defends theirs. By each of you defending your objectives, the best outcome is reached.

“I’ll try” is lying

Avoiding confrontation by caving into unreasonable demands with ‘I’ll try’ is unprofessional. It leaves both parties happy, but this false happiness will be shattered when expectations are not met.

“Trying” implies you were not putting forth all your effort before, and will now tap a secret reserve to get it over the finish line. “Trying” is now a commitment to succeed. But you are really setting yourself up for failure.

Commitment

Commitment involves three parts :

• Say - you say specifically what you will do
• Mean - say it with confidence
• Do - most importantly, do wtf you just said!

Words like need/should , hope/wish, let’s instead of ‘I’ are BS words that don’t imply any commitment. They are wasteful and do not lead to action.

Someone else …

If the end goal depends on someone else (as they usually do) commit to specific actions that bring you closer to that goal.

Red flag!

Circumstances arise where we may not be able to make good on the commitment. If things look bad, let stakeholders know early so the situation can be assessed and new commitments made.

The key to mastery is confidence and error-sense. Be confident in your choice and know howto quickly recognize a wrong choice.

Estimation

Estimates are a guess; not a solid commitment that the work will be done in a specified amount of time; starting from now. (starts stopwatch)

Estimates are in essence, a probability distribution. Having a very large task done tomorrow has a chance of < 1% of success. In 5 days, the chance of completion is 95% , in 10 days 99%.

While commitments are about certainty, estimates quantify uncertainty through probability.

Beware of implied commitments in estimation. Communicate the uncertainty of the estimate clearly so an estimate is not mistaken for a rock solid commitment of X hours.

If you are in no position to give a firm commitment based on the probability distribution of your estimate; make it clear! Do not be fooled into tacitly commiting by agreeing to “try to get it done in one day.” Uncertainty is a part of development, and by commiting to an estimate with a large degree of uncertainty, you’re setting yourself up for failure and exposing the project to undue risk! A true professional does not wrecklessly endanger a project.

Professionals do not cave into the pressure of ‘just try to get it done in 1 day?’ Missed objectives create business uncertainty which create uncertain development objectives.. It’s a sad cycle of affairs!

Keeping it clean

Professionals know ‘quick and dirty’ is an oxymoron. The only way to go ‘quick’ is to keep the code organized, well structed, documented and tested.

Choose methods that you feel comfortable doing during a crisis. Then do them all the time! Sticking to your diciplines is the best way to stay out of a crisis.

• Do you pair during a crisis? Pair more during non-crisis!

• Do you forgo TDD during a crises? Then you don’t find tests useful!

• Do you lose your head and smash your computer? Maybe developer isn’t the right job after all …

DONT PANIC

Rushing , fretting, and sleepless nights will only drive you deeper into a hole. Relax, and look at the problem(s) calm and rationally.

Communicate during a crisis

No one likes bad news. People like late bad news even less. This tends to multiply pressure X10.