Reading “Thinking in Systems”

“Purposes are deduced from behavior, not from rhetoric or stated goals”

We often get stuck on what is said and forget to look at results. If the results never match what is said then you need to realize maybe what is said is meant to mislead. It could also be lack of skills but that is not much better.

In my experience, most engineering misalignment comes down to interpretation of requirements. Someone says, “We should support Y.” That can mean different things depending on context.

The easy move is to make a reasonable assumption and start building, because asking clarifying questions feels slower, especially in async teams where you might be waiting for a reply. But I’ve found that taking the time to align first is usually cheaper than the rework that follows a wrong assumption.

I wrote about why this keeps happening and why senior engineers modeling clarification publicly makes more difference than we think: https://sleepingpotato.com/asking-questions-takes-less-time-than-doing-the-wrong-thing/

#software

*Tim Cook comes back to the stage*

It wouldn’t be an Apple event without… one more thing. In deep partnership with Sega — today on 9/9 — we’ll be announcing… the 26th anniversary Dreamcast.