Chapter 8 - Pragmatic Projects

Season 2 - Episode 13 - Chapter 8 Part 1

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 1 of Chapter 8

John: This chapter is all about "Pragmatic Projects" - Teams, Automation, Testing, Documentation Code quality and more.

60 - Organize teams around functionality

Don't separate designers from coders, testers from data modelers. Build teams the way you would build code.

JP: It's a mistake to think that the activities of a project - analysis, design, coding, and testing - can happen in isolation. i.e. Offers V2 at OL. Leaders of a team: needs at least 1 technical and 1 administrative personnel. Always think of the business goals

John: It's nice to have lots of full stack devs - They can focus more on a "Module" than a specific tech or "side" of the project.

61 - Don't use manual procedures

At the dawn of the age of automobiles, the instructions for starting a Model-T Ford were more than two pages long. With modern cars, you just turn the key—the starting procedure is automatic and foolproof.

John: We are developers! Why would we do ANY tedious work? Example: Github's API pulls in PR's and notes.

A shell script or batch file will execute the same instructions, in the same order, time after time

JP: "We may have to build the starter and fuel injector from scratch, but once it's done, we can just turn the key from then on" i.e. deploys

Let the computer do the repetitious, the mundane—it will do a better job of it than we would.

62 - Test early. Test often. Test automatically

Tests that run with every build are much more effective than test plans that sit on the shelf.

JP: In the Smalltalk world, they say, "Code a little, test a little" -> Get those small wins and make incremental changes

John: Write tests to help guide design.

63 - Coding ain't done till all the tests run

'Nuff said

JP: Keeping your feature branch green!

John: ALL the tests - unit, integration, performance, staging, usability, QA

64 - Use saboteurs to test your testing

Introduce bugs on purpose in a separate copy of the source to verify that testing will catch them.

JP: After you have written a test to find a particular bug, cause the bug on purpose to make sure the test complains
John: Code coverage analysis tools are very helpful

Picks

JP: Husky on NPM
John: Hound - It's a service