Lab 1: Perspective Switching
This lab opens the series with the hardest habit to build and the easiest to skip under deadline pressure: before arguing about a fix, work out which question is actually being asked. A failed system doesn't announceโฆ
Five two-hour lab sessions applying frame analysis, feedback mapping, wicked-problem framing, emergence, and an AI-proof skills audit to real software failures.
This lab opens the series with the hardest habit to build and the easiest to skip under deadline pressure: before arguing about a fix, work out which question is actually being asked. A failed system doesn't announceโฆ
A deployed system doesn't sit still once it's live โ it sits inside loops, feeding its own output back in as input, some of them stabilising and some of them amplifying. This lab asks you to find those loops in aโฆ
Some problems have a test that proves when they're solved. Others don't, and treating the second kind as the first is how a requirements process quietly builds the wrong thing with total internal confidence. This labโฆ
Three rules, applied to every cell on a grid, every step, with no cell aware of the pattern it's part of โ and gliders, oscillators, and self-replicating structures appear, unplanned. This lab starts from the cleanestโฆ
This closing lab turns the series back on its own participants. Having spent four sessions on frames, feedback, wicked problems, and emergence, the question now is personal rather than abstract: which of your ownโฆ