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
of Dev Empathy Bookclub 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 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
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, thought/feelings on this? What is up next on your reading list?
Top comments (0)