Notes from the book by R.C. Martin

Summary of thoughts

This book is more conversational than others by the same author. It had some good insights, but was a bit more of a reinforcer. If these concepts are new to you, i’m not sure that this book is the best way to first read about them. The main thrust here is this book engourages you to look at yourself and your acreer and motivate you to improve. It is different from the architecture books in that respect. There is some crazy 70 hour work weeks that he encourages. Not smart IMO. Real personal growth and improvement is sustainable. just IMO tho. 😃

1. Professionalism

delivering function at teh expense of structure is a fool’s errand

every time you look at a module, you make small lightweight changes to it to improve its structure

merciless refactoring

4. Coding

pairing can be very helpful as a way to deal with interruptions

TDD is another big help. If you have a failing test, that holds the context of where you are.

Writer’s Block

the solution: Find a pair partner

Debugging Time

nowadays i spend much less time debugging … a factor of ten … adopting the practise of TDD

5. Test Driven Development

when you see bad code, you simply clean it on the spot

7. Acceptance Testing

acceptance tests should always be automated

acceptance tests should be written as late as possible, typically a few days before the feature is implemented

it is very important to keep the CI tests running at all times

8. Testing Strategies

the test automation pyramid

  • 5% exploratory, manual
  • 10% system tests, gui
  • 20% integration tests, api
  • 50% component tests, api
  • 100% unit tests, XUnit

Somehow this doesn’t add to 100% ??

  • Unit Tests way to specify what they are about to write
  • Component Tests some of the acceptance tests
  • Integration Tests they do not test business rules. it is at this level that we might see performance and throughput tests. they are typically not executed as part of the continuous integration suite, instead nightly, weekly, etc
  • System Tests their intent is … to ensure … correct system construction
  • Manual Exploratory Tests these tests are not automated

9. Time Management

  1. Meetings are necessary
  2. Meetings are huge time wasters

Time Boxing and Tomatoes

pomodoro technique

time outside of tomatoes is either distractions, meetings, breaks, or other time that is not spent working on your tasks

a good day you might get 12 or even 14

Blind Alleys

holes: when you are in one, stop digging

10. Estimation

What is an Estimate?

  • business … view estimates as commitments
  • developers … view estimates as guesses

estimates are fraught with error

11. Pressure

avoid the situations that cause pressure

avoid commiting to deadlines

12. Collaboration

Teams are most effective when the team members collaborate professionally. it is unprofessional to be a loner or recluse

professionals pair … it is the best ay to share knowledge with each other

if we really want to spend our days programming, we are going to have to learn to talk to–people

Appendix A. Tooling

Unit Testing Tools

  • quick and easy
  • clear visual pass/fail indication
  • clear visual indication of progress
  • discourage individual test cases from communicating with each other

Component Testing Tools

given/when/then style

Integration Testing Tools

some tests that must go thru the UI … a few end-to-end tests