The Pragmatic Programmer – Chapter 8 Notes and Questions
Tags: engineering, bookclub, learning
Published: 2019-05-24 16:41:10

---
title: The Pragmatic Programmer – Chapter 8 Notes and Questions
published: true
tags: engineering,bookclub,learning
canonical_url: https://christine-seeman.com/2019/05/engineering-bookclub-pragmatic-programmer-chapter-8-notes-and-questions/?utm_source=rss&utm_medium=rss&utm_campaign=engineering-bookclub-pragmatic-programmer-chapter-8-notes-and-questions
cover_image: https://ak4.picdn.net/shutterstock/videos/16003714/thumb/2.jpg
---

So sorry this took a while to post, but let’s dive into the last chapter for The Pragmatic Programmer! As always, thank you to {% user amcaplan %} of [Dev Empathy Bookclub](https://devempathybook.club/) for letting me use questions from the book club. If you are looking for an awesome group of people to discuss books that can help you become a better person and better developer check them out! Right now they are taking on [Say What You Mean: A Mindful Approach to Nonviolent Communication](https://www.amazon.com/Say-What-You-Mean-Communication/dp/161180583X) by Oren Jay Sofer.

Notes on Chapter 8, Pragmatic Projects

- Quality of code is a team issue
- Teams should not tolerate broken windows, team must have accountability 
- Communication within a project team is important, as is the project team communicating with the rest of the company
- Don’t duplicate work between members of a team
- Divide teams up by function, into small groups that are self-organizing
- Automate what you can, don’t rely on manual processes (ex. scheduling backups, compiling project, generating code, regression tests, making a build…)
- “Finding bugs is somewhat like fishing with a net. We use fine, small nets (unit tests) to catch the minnows, and big, coarse nets (integration tests) to catch the killer sharks.”
- Earlier a bug is found, the cheaper it is to fix it
- Be aware of end-user use patterns and how they are different from test data/patterns
- If a bug slips through the net of existing tests, you need to add a new test to trap it next time.
- All documentation is a mirror of the code, if there is a discrepancy, the code is what matters
- Code comments should discuss the why something is done, purpose and goal (the code is the how)
- Documentation of any form is just a snapshot in time of the code
- Communicate expectations, work with users so they understand what you will be delivering
- Have pride in ownership of your finished code, don’t jealously defend it, bu show that it is is solid, well written, tested and documented code.
  - Before Git blame! So now your name is in their no matter what now! 😜
  - Have strong opinions, but loosely held

Tips

- Organize Around Functionality, Not Job Functions
- Don’t Use Manual Procedures
- Test Early. Test Often. Test Automatically.
- Coding Ain’t Done ’Til All the Tests Run
- Use Saboteurs to Test Your Testing
- Test State Coverage, Not Code Coverage
- Find Bugs Once
- Treat English as Just Another Programming Language
- Build Documentation In, Don’t Bolt It On
- Gently Exceed Your Users’ Expectations
- Sign Your Work

Questions on Chapter 8

- Is a separate tool builder tool still necessary? Or does each programmer also have to build their own tools?
- “Our goal is to maintain an automatic, unattended, content-driven workflow” is this something we have been able to achieve as developers now that we have 20 more years of tools and utilities?
- What tests are you missing in your project/application? For ex. Think about how many unit/integration tests may exist but what about validation and verification

Testing? The book goes through several major types:

- 1. Unit testing
- Integration testing 
- Validation and verification
- Resource exhaustion, errors, and recovery (Stress tests)
- Performance testing
- Usability testing

- In Tip 60 in the book urges: Organize Around Functionality, Not Job Functions
  - Have you worked on a cross-functional team before? How did that experience compare with working on a function-based (backend-only, frontend-only, DB-only, etc.) team?
- While advocating for usability testing (chapter 43, Ruthless Testing), the book claims: Failure to meet usability criteria is just as big a bug as dividing by zero. Has that been the attitude of teams where you’ve worked? Do you believe this is true?

Further reading

[https://en.wikipedia.org/wiki/Chief\_programmer\_team](https://en.wikipedia.org/wiki/Chief_programmer_team)

In an article in the April 1999 CACM, Robert Glass summarizes research that seems to indicate that, while code inspection is effective, conducting reviews in meetings is not [Gla99a].

And with that we are done!! Next up for my engineering book club we are looking at tackling How [We Got to Now: Six Innovations That Made the Modern World](https://www.amazon.com/How-We-Got-Now-Innovations/dp/1594633932), thought/feelings on this? What is up next on your reading list?