Reading Notes from 'Simplicity' and 'Kill it with Fire'

After a long stretch of only reading articles and documentation, I've been getting back into software engineering books.

I wanted something grounded that wouldn't be obsolete in 3–30 days (cough cough half the LLM and "agentic AI" content out there), so I picked "Simplicity" by Dave Thomas and "Kill It with Fire" by Marianne Bellotti, which had been sitting in my to-read list for a while.

One of Thomas's suggestions is to keep a day book — a Moleskine, a Hobonichi, or some similar — and write down everything you learn as you learn it.

So: the following are notes that I took reading both of these books that I found educational and/or insightful, and that I can see being helpful to me in the months and years to come.

Simplicity

Learning without the panic of being overwhelmed by the new

Thomas encouraged the keeping of two lists: one that covers "should learn" topics that are related to your day job, and the other that's focused on "fun" topics - ones that you're curious, interested, or excited to learn about, but may not be directly relevant to your job (at least in that moment).

He argues that alternating back and forth between the lists can help in career development while minimizing the risk of burnout that can come if you were to only take time to learn "work things" that don't necessarily spark excitement and curiosity.

And, following the point about the "day book" mentioned above - keep notes on things learned from both lists, not just the topics in the "should learn" list.

Automation = Reliability

While I'm familiar with and aware of the value of automating developer environment setup for individual projects, I hadn't considered automating my entire developer environment.

Thomas encourages the automation of everything as a regular practice. As he put it, automation equals reliability - and a lot less stress when the automated setup is needed!

Since reading this, I've started writing more setup scripts and files (and putting them under version control) so that if I ever need them, it's much easier to hit the ground running.

Kill it with Fire

Technology progresses in a cyclical way, not linearly

Essentially - "what is old is made new again".

An example that I’ve seen in my own career is the push, in web application/full-stack development, from server-side processing and rendering towards client-side processing. Now, over the past few years, we’re moving back towards server-side processing.

Bellotti cautions that, due to this cyclical nature, what is new is not always "better" or "more advanced". In her words:

Adopting new practices doesn't necessarily make technology better, but doing so almost always makes technology more complicated, and more complicated technology is hard to maintain and ultimately more prone to failure.

...

Changing technology should be about real value and trade-offs, not faulty assumptions that newer is by default more advanced.

Postmortems for success are as important as postmortems for failure

We run postmortems in the event of a "failure" to understand all the contributing factors that led to the event in order to determine the role of decision-making and the quality of decisions, and what was luck and beyond anyone's control.

Bellotti argues that it's as important to do in cases of success in order to make success replicable. To not do so can lead people into what's called "resulting" - judging the quality of a decision with the quality of an outcome.

Obviously luck and the quality of decision-making both play a role in success and failure, so I think the idea of having postmortems for success shouldn't be as novel as they seem to be today in software development.

As an aside - I read Annie Duke's "Thinking in Bets" earlier this year, which devotes a decent amount of pages to "resulting" in a poker context. If you've been thinking about reading this book, it's great for the coverage on this topic alone.