I do “pathing” when I project my work into the future: laying out a sequence of work steps, where each step ends with the code in a shippable state. More than design, and more than planning, pathing is a kind of work-style, and it brings me several benefits. When we're pathing, we're really just decomposing a problem, breaking it into several smaller problems. What makes me call it pathing -- instead of design or planning -- are two requirements we want each sub-problem to meet before we're satisfied with it: size and shippability. I use the pathing workstyle most frequently in two related but different tasks: in close-up coding at the keyboard, and in near-term feature layout around the meeting room. These are different scales, with different sizes that will satisfy, but shippability is the same in both.

You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata.