I’ve been trying to identify a minimal set of factors that guide how I write self-documenting code. It seems these may be sufficient: naming, proximity, consistency, and scope.

Checklist Manifesto paints an facinating journey of a surgeon who discovered checklists. The book explores checklists across industries and applications, but one lesson pervades them all: use checklists to distribute power.

My duck docs continue to evolve as my process changes. Here are changes I’ve noticed lately.

This is my attempt at short actionable checklists to guide key moments in software process.

I read that stuckness is not a bad thing. It is avoiding our stuckness that is the problem. I think living with stuckness is part of why duck docs are so good.

I’ve started some reading lists to help people connect to good software literature.

A friend asked me to summarize what I believe about software in five points or less. I previously described those points. Here is where each of those beliefs originates from.

A friend asked me to summarize what I believe about software in five points or less. These are those five points.

I read a lot. I’ve noticed that some of the most effective books I read share a clear focus. Every point is quickly and explicitly tied back to a concise core message. What core message would I reiterate if I wrote a book on software?

Software development is notoriously short on research-based practices. Google’s DevOps Research and Assessment (DORA) project is helping fill that gap.