When I start up a new project, one that’s going to be worth writing up later on, I find it’s useful to get myself into the right mindset. I’m not a big planner like some people are — sometimes I like to let the project find its own way. But there’s also the real risk of getting lost in the details unless I rein myself in a little bit. I’m not alone in this tendency, of course. In the geek world, this is known as “yak shaving“.
The phrase comes obliquely from a Ren and Stimpy episode, and refers to common phenomenon where to get one thing done you have to first solve another problem. The second problem, of course, involves solving a third, and so on. So through this (potentially long) chain of dependencies, what looks like shaving a yak is obliquely working on cracking some actually relevant problem.
Yak shaving has been interpreted by many folks as being always a distraction from the main task — necessarily a bad thing — and something to be avoided at all costs. Others have interpreted yak shaving as an annoyance that must be nevertheless be dealt with. But yak shaving can also be an enjoyable diversion that contributes to the end goal, or it can also be like the way that spending a year learning to string a bow was reported to work in Zen and the Art of Archery — as a meditation on the finest details that results in transcendent mastery of the whole. At least for me, yak shaving has been all of these things, which makes it tricky to know when to put down the razor and try to refocus on the main problem.
One thing that helps me to navigate these treacherous waters is to classify a project into one of a couple modalities before starting: is it a Hacker-mode project, or a Maker-mode project, or somewhere in between? Hacker and Maker projects require different tools, different degrees of certainty in planning the outcome, different working methods, and different approaches to yak shaving. Sorting this all out beforehand is at least worth the few minutes it takes to think it all through.
Some projects are started purely to get the project done. That sounds simple enough, and of course there are many steps along the way from idea to finished work, but the prototypical Maker-mode project can be planned out in detail from the start, accomplished with “normal” tools using skills that you’ve already got, and not a place for yak shaving. For these projects, the biggest obstacle to success is just doing it.
This is where tools like pre-canned software libraries and off-the-shelf parts or modules are great. The point of a Maker project is to get the thing made, and there’s no sense in reinventing (or even refining) the wheel. Maker mode projects are great to ship out to PCB houses as well. Plans can be made, parts ordered, and the relatively slow turnaround in external board fabrication just adds a delay rather than lengthening the amount of time it takes to get the project done. You might as well get started on the next project while waiting for delivery, because the board will “just work”.
The extreme Maker stance on yak shaving is that it’s always a waste of time. Spending too much time on tiny or inconsequential parts of the project risks delaying the whole. When you nonetheless find yourself down a yak-shaving dead-end, it’s a good time to think if that part of the project is essential, or if it can be approximated, allowing one to move on. Make everything as smooth as possible. Get it finished.
(Contrary to the “Cult of Done” folks’ assertions) Maker mode is not an excuse to be sloppy or avoid detail work. Indeed, because issues can be foreseen, it makes sense to plan things out and avoid uncertainty and mistakes upfront. In building an SD-card-based audio recorder, for instance, you know the frequency response you need, can figure out the data rates, and can select the right hardware and firmware from these data. Wire them up in the easiest way possible, and get it done.
Hacker-mode projects are a lot fuzzier from the start. A hacker mode project often starts out with a new piece of gear, and a vague idea that it can be made to do something interesting. Maybe the SD-card audio recorder example above is actually a bat-call recorder, and the microphone is only spec’ed up to 20 kHz but it could probably be run a lot higher. Or maybe the project is looking into an IoT device to see what makes it tick, and if the firmware can be broken into. Only one way to find out!
The planning phase is often more about assembling a list of possibilities than making a list of sequential steps; hacking is dealing with uncertainties. Where planning a Maker-mode project answers “how do I make this?”, planning a hacker-mode project runs more along the lines of “I wonder if I can make it do this?”.
The tools needed for a Hacker project are lower-level. A scope, a logic analyser, and other gear that can be programmed to inject signals into the system under study are all handy. In Hacker mode, it’s good to have a well-stuffed toolbox, because you don’t know what you’re going to need, and what you’re not. Still, you don’t always have all the tools on hand that you’re going to need, and some of them will need to be custom-built. In the context of a Maker project, tool-building exercises are often undesirable yak shaving. In a Hacker project, the right (low-level) tool or insight can often be the key to success.
Hacker mode projects are also a lot less conducive to waiting time between steps. If you know that you’re going to have to repeat a step over and over again, it makes sense to spend some time optimizing that step. If it’s re-running a test a million times, you’re going to be happier if it’s scripted than if it involves pull-down menus. If it’s a PCB design that’s going to need to be respun five times over, a two-week waiting time to order the cheapest fabrication is repeated five times — it’s worth doing it yourself or paying for a faster service. Knowing where a Hacker-mode project is uncertain helps to manage the uncertainty.
The Real World
Any real project is going to share aspects of these two extremes, of course. Some “purely” Maker projects will involve jig-making and tool-building to get the job done efficiently or beautifully. Those are yaks that need to be shaved. Conversely, unless you need very specific timings for some esoteric timing attack, there’s very little to be gained by writing your own bit-banged JTAG library; almost any Hacker-mode project can get by using an off-the-shelf tool.
The Hacker/Maker distinction is further blurred when you’re building a concrete project, but your actual goal is learning a new programming language or SDK or chip family. Learning projects are basically Maker projects, but the goal is picking up some new skills rather than a physical artifact. In learning projects, there’s little uncertainty — you can probably learn anything — but diving deep into the tools may be part of the goal rather than a step along the way. When your goal is to deepen your knowledge, what would seem to be negative yak shaving is actually the work you need to do. Indeed, once you’ve learned what you came to learn, it might be time to abandon the physical thing even if it’s not done, which is anathema to a Maker project.
The point here is to be explicit about the goal upfront, because it should influence the amount of planning, choice of tools, and even what constitutes positive or negative yak shaving along the way. If you find yourself caught up in infinite regress on an Maker project, write it up as a Hacker project to figure out later, and sidestep the issue for now if possible. Conversely, don’t feel that you should never be allowed to fully investigate some arcane aspect of a problem, because that’s where good Hacker insights come from. Some yaks just need shaving!