#2-2019-Aug-“Clean coder”

I read this book many years ago, but now it was as valuable or even more valuable.

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

Notes on the clean coder (aug 2019)

  1. Commitment != estimate

    1. A commitment is when you say you will do something by a specific date. Professionals only make commitments they can keep.

    2. The estimate comes in a range. The book proposes the following formula (PERT):

    3. distribution

      1. Optimistic estimate (<1%) = O

      2. Nominal estimate = N

      3. Pessmisitc estimate (<1%) = P

      4. expected duration = (O + 4N + P) / 6

      5. Example: O=1d, N=3d, P=12d, expected duration = (1+12+12)/6 = 4.2d

      6. standard deviation = P-O / 6

      7. ../_images/13_clean_coder_estimate_sequence.pngMultiple tasks expected duration

      8. ../_images/13_clean_coder_estimate_sequence_variation.pngMultiple tasks standard deviation

  2. There is no other way than working 60 hours to become a professional

    1. 40 hours for your employer

    2. 20 hours for you (reading, learning, practicing, and otherwise enhancing your career)

  3. Passive-aggressive is when you simply do something because someone told you to do so even though you know it is wrong.

    1. A professional does what is right for the business.

  4. Clean code

    1. Tests: Unit tests, component tests, integration tests, system tests, and manually exploratory tests.

      1. System tests run against the entire system.

    2. Never compromise on unit tests, TDD forever. Unit tests are meant for developers to document the code

    3. Acceptance tests should be readable by business people and are meant for business people but not necessarily written by business people.

  5. Saying No is expected by the professional. If immediate superior doesn’t understand, you need to make it explicit that you will go above them.

  6. The coding dojo, performing Katas, contributing to open source, all ways of practicing.

  7. He emphasizes pairing throughout the book, but it is something I have not been successful in implementing it. I would like to know more about how to pair correctly.

  8. He does not recommend the flow zone

    1. The zone gives you speed, but you loose the big picture.

  9. Divides an engineer into: Master, Journeyman, and Apprentice. Each level should teach the level below.

  10. Definition of done

    1. Feature implemented and acceptance tests passing on build.

  11. Preparedness

    1. The code must work

    2. Solve customers problem

    3. Fit into the existing system

    4. Readable by other programmers –> reveal the intent