But yak shaving is fun

Park Sangbeom’s essay, “But yak shaving is fun,” begins with a small publishing problem and ends inside one of software’s oldest temptations: the urge to build the tool before building the thing.

Park wanted a blog. Static site generators such as Jekyll, Hugo, and Gatsby constrained his design choices, so he wrote posts in HTML. HTML made writing painful, so he created a JSON-based post system. JSON made long essays awkward, so he built a Markdown-to-HTML service. He then added a compiler and deploy tool. A blog project produced a static site generator.

Engineers know the pattern. You start with a goal, hit a tool gap, fix the tool gap, then discover the tool needs its own tool. Park names that pattern yak shaving.

MIT AI Lab researcher Carlin Vieri coined the phrase after watching “Yak Shaving Day,” an episode of The Ren & Stimpy Show. Park traces the term through later programmer folklore: a dull axe leads to a sharpening stone, the stone sits in another village, the trip requires a yak, and the yak needs a shave before the trip can begin.

That story sounds absurd because it captures a familiar workday. You meant to ship a feature. You spent the afternoon fixing build scripts.

Park’s argument has two parts. First, teams burn time when engineers build from scratch without checking whether existing tools satisfy the core need. Second, those detours attract good engineers because building tools gives them the pleasures Frederick P. Brooks Jr. described in The Mythical Man-Month: making useful things, solving puzzles, and learning through a medium that changes under the hand.

Donald Knuth gives Park his strongest example. Knuth wanted to prepare a new edition of The Art of Computer Programming. Dissatisfied with available typesetting, he created TeX, then WEB, literate programming, the Knuth-Plass line-breaking algorithm, Computer Modern, METAFONT, and DVI. A book project turned into a publishing system that mathematicians, scientists, and engineers still use.

Knuth’s case also sets the trap. His detour changed technical publishing, but most project detours consume the schedule and leave the original goal unfinished. A manager sees missed dates. An engineer sees a half-built tool that deserves one more week.

Park treats that tension with care. He warns teams to cut scope, choose adequate tools, and protect the original goal. He also admits the private truth that makes the warning hard to follow: yak shaving feels good because it rewards curiosity with visible progress.

The essay works because Park refuses to flatten the issue into a productivity sermon. A team that ships software needs restraint. A person who wants to understand computers needs detours. Building a small compiler, renderer, deploy tool, or operating system clone can waste a product sprint and serve as excellent education.

That distinction matters for modern software work. Product teams often borrow language from craft while measuring only delivery. Engineers often borrow language from learning while avoiding a decision. Park gives both sides a cleaner test: name the goal, name the constraint, and decide whether the detour serves the user or serves your curiosity.

A company should stop the shave when the customer waits for the product. A learner should keep shaving when the detour exposes the machine under the abstraction. Park’s blog generator sits between those poles: impractical as a default choice, defensible as a way to learn the web stack by building it.

The counterargument deserves space. Off-the-shelf tools carry their own costs. Frameworks impose mental models, plugins break, and defaults shape the site more than the author expects. A builder who cares about control may spend less effort over time by owning the system. The hard part lies in telling control from preference before the project consumes its own purpose.

Park closes with a defense of the detour as education. The Elements of Computing Systems makes the same promise through coursework: build from logic gates toward an operating system, and you understand the stack because your hands touched each layer.

Yak shaving becomes dangerous when a team mistakes motion for delivery. It becomes useful when you choose the detour as the lesson. Park’s essay lives in that uncomfortable middle, where engineers know they should stop and also know why they want to continue.