Agile and DevOps have pushed faster and more frequent releases. Techniques like integration test, feature flags, canary tests, and monitors evolved to maintain service reliability without slowing that pace. But some code paths are so critical that they cannot fail even once. This is where Scientist comes in.

This post is mostly a self-reminder to think more on a few logging ideas I encountered. I figured others might benefit from them too.

I previously wrote on statistical and mutation testing for UIs. After additional thought, I don’t think UI mutation testing is feasible, at least in the traditional sense. Structure-based generative testing still could be. Lack of Deterministic Errors for Mutation Mutation testing is a tool to measure completeness. It tells us how well our other tests detect possible errors in our code. Mutation testing frameworks measure test suite completeness by crawling the code and injecting breaking changes.

A friend has been struggling with under-documented projects (*cough* zoo software). This raised the question, what makes good documentation? And what is a good documentation system? Here’s my opinion backed with some sources.

Small teaching is an engaging and practical condensation of learning research into an accessible read. The book is oriented toward teachers, but is meaningful for anyone who wants to learn more effectively or understand how to share ideas.

Choosing the right amount of process is an art. Too much process is smothering and too little is a mess. However, I think incremental, stable, and additive processes naturally start simple and mature progressively with our demands.

“No ideal process, or set of processes, exists” “Software processes must be selected, adapted, and applied as appropriate for each project and each organizational context.” (SWEBOK Ch 1.1 intro). No one likes to hear “that’s just how we do it”. Process without understanding leads to frustrating lack of results. Understanding factors of good process is critical for effective work across projects and for continued improvement. My working hypothesis is that effective processes are incremental, stable, and additive.

Code is not the goal of programming. Programming is about understanding and representing problems. While this belief is expressed by many experts, the repercussions are many and nuanced. This is my latest attempt to communicate the idea clearly.

This is my attempt to communicate what I consider when looking at a pull request.

Working on System.CommandLine.PropertyMapBinder has led me to believe C# is missing a powerful feature: static class extensions. This post explains my usecase, and balances some of the tradeoffs.