Chapter 8 - Pragmatic Projects
Season 2 - Episode 14 - Chapter 8 Part 2
John: Welcome to Iteration: A weekly podcast about programming, development, and
design through the lens of amazing books, chapter-by-chapter.
JP: This is part 2 of Chapter 8 - THE FINAL CHAPTER!
65 - Test state coverage, not code coverage
Identify and test significant program states. Just testing lines of code isn't enough
JP: Even if you test every single line of code - that's not what matters. What matters is how many different permutations of your app's state you have covered. drops mic
John: Coverage tools are nice - but they only give you a window into the state passed into it. If you can extract state out into separate objects or methods to be able to test them decoupled from time.
66 - Find bugs once
Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.
JP: We don't have time to find a bug more than once... "We have to spend our time writing new code - and new bugs"
John: Step one of debugging - write a test that's failing. I broke this pattern this weekend. :(
67 - English is just a programming language
Write docs as you would write code: honor the DRY principle, use metadata, MVC, auto-generation and so on
JP: don't dread writing docs. it's part of your application. I think this tip is phrased in such a way to appeal to engineers. think of documentation writing as writing code, not writing literature
John: I like this in theory - I'm having trouble getting tooling in place for this that makes sense. I really want to dynamically generate, external API docs, internal docs and user guides totally automatically. Super struggling to get anything moving in rails.
68 - Build documentation in, don't bolt it on
Documentation created separately from code is less likely to be correct and up to date
JP: sometimes you need documentation. obviously, name your variables well, but sometimes explain what a function does or why it does it. at OL we'll sometimes write include the GitHub issue number for a weird quirk or to explain why a test is testing for certain functionality. treat docs like code. part of the code, not separate from it
John: I feel like this is a bit outdated. If written well modern languages really can be self-documenting. Basecamp really doesn't "do" code comments or internal docs - Per DHH - If there is a comment explaining a method or model I break it up further until it doesn't need explaining. I worship in the church of Henninger-Hansen.
69 - Gently exceed your users' expectations
Come to understand your users' expectations, then deliver just that little bit more.
JP: "Never lose sight of the business problems your application is intended to solve".
John: One of my favorite parts of the job is delivering features users get super jazzed about.
7- - Sign your work
Craftspeople of an earlier age were proud to sign their work. You should be, too
"Anonymity, especially on large projects, can provide a breeding ground for sloppiness, mistakes, sloth, and bad code. [...] We want to see a pride of ownership. Your signature should come to be recognized as an indicator of quality. A really professional job. Written by a real programmer. A Pragmatic Programmer"
JP: lol, git blame
John: Take pride in what you do.
Picks
JP: https://github.com/sindresorhus/refined-github
John: LG 22MD4KA-B UltraFine 4K Display 21.5" UHD 4096x2304 4xUSB-C
Next week: Pragmatic Programmer in Practice - Book recap in the context of our real-life development work.