These are my notes about the book Code That Fits In Your Head by Robert Seemann.
Chapter 1: Art or Science? Seemann talks about how software development is compared with building a house, then describes how this comparison is mostly unjust. Is software development art or engineering? He says “Software development is principally a design activity.” It is not yet an engineering activity in his view, but it may one day be. He says the book describes heuristics that he’s found useful in software development (in contrast, imagine building a house based on heuristics…).
Chapter 2: Checklists The idea behind checklists is to “improve the outcome with no increase in skill.” There are two types of checklist. With the read-do checklist, you do each item as you read through it. With the do-confirm checklist, you do each item on the list and confirm you’ve done it. He gives an example checklist that includes using Git and automating the build, including deploying to some production environment.
He suggests initializing a Git repo and then deploying using CD (Continuous Delivery) as soon as possible. This suggests he’s a “breadth-first” kind of person. It’s like framing a house or sketching out a drawing before filling in the details. That’s my tendency as well. It can lead to waste. For example, there’s probably no real production environment to start with, so you’ll need to set up a temporary one that will be replaced with the real one later. The benefit is in having that framework in place. Hopefully, this means you will not get blind-sided by a missing, complicated and important detail later down the road.
Do not turn off error messages, and turn warning into errors if possible. This makes you more likely to fix them.
Turn on static analysis.
Treat compiler warnings as errors. Treat linter and static code analysis warnings as errors.
For existing code bases, he recommends turning on warnings one at a time, fixing the issue, and then turning the warning into an error [p 29].
He also suggests that turning warnings into errors will force fixes since the code will not compile in that scenario, meaning you can tell management that the code will not work until it is fixed [p 30]. Oy.
Chapter 3: Tackling Complexity Code has to be sustainable if it is going to be used long-term.
To do so, he recommends optimizing code for readability, because we spend much more time reading code than writing it.
Chapter 4: Vertical Slice This chapter is mostly a run-through of creating a “vertical slice” - a thin piece of software that exercises all the expected working parts of the system from start to finish.