The Clean Coder

A Code of Conduct for Professional Programmers

Robert C. Martin

Summary: how to be a better programmer (or a more senior one)

Score: 75 / 100

The book contains several good mentoring stories. It is probably so popular since it was one of the first books in this realm.

Chapter 1: Professionalism

Professionalism comes with responsibility and accountability.

Rule: Do no harm. Test, do quality assurance, know to apologize.

Every single line of code should be tested.

Design code to be easily tested.

Make code to be flexible. If a change is hard, change code so it is easy the next time.

There are two opposing rules: always improve/refactor code (Martin) vs. never do refactor as a part of a bug fix.

Martin says these are fundamentals:

• design patterns
• design principles: SOLID, component principles
• methods: XP, scrum, lean, kanban, waterfall, structured analysis, structured design
• disciplines: TDD, OOP, structured programming, CI, pair programming
• artifacts: UML, DFD, structure chart, Petr nets, state transition diagrams, flow chart, decision tables
• continuous learning

Chapter 2: Saying no

Professionals have the courage to say no to their managers.

Good code should be extendable, maintainable, lend itself to modification and read like a prose.

Chapter 3: Saying yes

Commitment: do not use should, need, say I will … by ….

Professionals know their limits: how much overtime they can effectively apply.

Chapter 4: Coding

Do not write code at 3 AM.

Professionalism is more about discipline than hours.

The key to master is confidence and error-sense.

Estimates: best case, nominal case and worst case.

Do not incorporate hope into your estimates.

Define DONE for a project, task.

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

Chapter 5: Test-driven development

Compile and run often.

1. No production code without first a failing test.
2. No unnecessary unit tests.
3. No code above fixint the failing code.

If you break it, it becomes yours.

With a suite of tests you trust you lose all fear of making changes.

TDD ensures very high test coverage.

TDD drives a decoupled system.

Chapter 6: Practising

Bowling game, kata, coding dojo.

Chapter 7: Acceptance testing

Fight ambiguity in requirements with acceptance criteria.

In Agile, tests are written after features have been selected for the next iteration/sprint.

Acceptance tests are by business for business. Unit tests are by programmers for programmers.

Chapter 8: Testing strategies

QA should find nothing.

Unit tests > component tests > integration tests > system tests > exploratory tests.

Component testing:

• mocking
• happy path situations are usually testsed

Integration tests:

• testing more components,
• performance,
• throughput tests

System tests seems to me as the same as integration tests.

Chapter 9: Time management

Meetings are necessary AND are time wasters.

Professionals are aware of high cost of meetings.

It is unprofessional to go to too many meetings.

The person inviting you is not responsible for your time management.

Of of the duties of your manager is to keep you out of meetings.

You can leave a meeting as remaining at a meeting which is a waste of your time is unprofessional.

Meetings should have an agenda. It the agenda is not followed, you might leave.

Stand-up (in Agile canon):

1. What I did.
2. What I am going to do.
3. What is in my way.

20 sec each item, one minute one person’s update. No discussion!

Iteration/sprint planning: tasks from backlog into next iteration/sprint. This might take more.

Discussions: data should resolve disagreements.

If you agree, you must engage!

Author’s focus-manna is something like cognitive load.

Do hard work when you have manna, do other work it it’s depleted.

Muscle focus may restore the mind focus.

Pomodoro/tomatoes technique: 25 minut no distraction, deep work, 5 minut rest. After 4 blocks, 30 minut rest.

Priority inversion: raising priority of other task at the expense of the real high-priority task. A.k.a. procrastination.

It might actually be a defense to protect us from the judgement of others.

Rule of holes

if you are in one, stop digging.

Chapter 19: Estimation

Business likes to view estimates as commitments; developers like to view estimates as guesses.

So multiplying by pi constant is converting a guess into commitment.

Estimate isn’t a number, it’s a distribution.

Trivariate analysis

• O: optimistic estimate (ideal, fast, ~1%
• N: nominal estimate (top of the curve)
• P: pessimistic estimate (~1%, worst case scenario)

µ = (O + 4N + P)/6 = expected duration sigma = (P-O)/6

wideband delphi

discuss and agree on estimation in a group

flying fingers

raise fingers simultaneously

planning poker

equivalent to fingers, with cards with Fibonacci numbers, or 0, 1, 2, 3, 5, 10.

affinity estimation

sorting tasks; then grouping to buckets (labelled with Fibonacci numbers)

Chapter 11: Pressure

Choose disciplines (pair programming, clean code, TDD, …) then follow them all the time (in crisis or in non-crisis).

Do not rush!

In crisis, communicate.

Chapter 12: Collaboration

The first responsibility of the professional programmer is to meet need of his or her employer.

The team should own the code, not individuals.

Pair programming is good for breaking knowledge silos.

No system should consist of code that hasn’t been reviewed by other programmers.

A special case of communication/collaboration is serendipitous communication. There must be a space for that in a company.

Chapter 13: Team and projects

It’s better to keep a gelled team together and feed it projects than to re-create the teams for each project.

Teams are harder to build than projects.

Chapter 14: Mentorship

This chapter was just a rant.