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.

---

Send in a voice message: https://podcasters.spotify.com/pod/show/geepawhill/message

Twitter Mentions