Self-reinforcing quality / adopting verification pattern

After implementing the small-change pattern, Imprint Engineering’s next focus in improving our development loop has been implementing a verification loop for our software development. This is an increasingly common pattern, particularly popularized by poteto’s pstack, but you’ll find similar ideas emerging in other places as well, e.g. Niko Matsakis’ post on the correctness ratchet, among others. This captures some of the confusion I’ve seen in our initial rollout, and the particulars of how we are implementing the approach. What verification pattern is, and what it isn’t The verification pattern suffers from confusing naming: when you tell a team that you’re planning to roll it out, they’ll often ask you what mechanism you’re using to verify the codebase, don’t we already have tests, linters and so on? However, the verification pattern itself is more similar to the chain-of-thought pattern, which aims to steer the harness towards your desired outcome in a clear way. For example, we…