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.
- No production code without first a failing test.
- No unnecessary unit tests.
- 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.
- happy path situations are usually testsed
- testing more components,
- 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):
- What I did.
- What I am going to do.
- 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.
- 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.
last modified: 2023-09-23