Don’t build systems. Build subsystems.

Always consider your design a subsystem. Jabe Bloom When we build software, we aren’t building it in nowhere. We aren’t building a closed system that doesn’t interact with its environment. We aren’t building it for our own computer (unless we are; personal automation is fun). We are building it for a purpose. Chances are, we … Read moreDon’t build systems. Build subsystems.

Hyperproductive development

TL;DR: the most productive development happens when one person knows the system intimately because they wrote it; this is in conflict with growing a system beyond what one person maintains. Let’s talk about why some developers, in some situations, are ten times more productive than others. hint: it isn’t the developers, so much as the … Read moreHyperproductive development

Code and Coders: components of the sociotechnical system

TL;DR: Study all the interactions between people, code, and our mental models; gather data and we can make real improvements instead of guessing in our retros. Software is hard to change. Even when it’s clean, well-factored, and everyone working on it is sharp and nice. Why? Consider a software team and its software. It’s a … Read moreCode and Coders: components of the sociotechnical system

Reuse

Developers have a love-hate relationship with code re-use. As in, we used to love it. We love our code and we want it to run everywhere and help everyone. We want to get faster with time by harnessing the work of our former selves.And yet, we come to hate it. Reuse means dependencies. It means … Read moreReuse

Provenance and causality in distributed systems

Can you take a piece of data in your system and say what version of code put it in there, based on what messages from other systems? and what information a human viewed before triggering an action? Me neither. Why is this acceptable? (because we’re used to it.)We could make this possible. We could trace … Read moreProvenance and causality in distributed systems