A lot of developer slang points at how you work, not at code. These four do — getting lured down side-quests, repeating an action safely, using your own thing before you ship it, and stopping safely when you stop. Worth knowing whether you collaborate or work alone.
TL;DR
- Yak shaving: starting your real task, then drowning in a chain of side-tasks far from the point
- Idempotency: running the same action many times gives the same result as running it once (safe to retry)
- Dogfooding: using your own product as a user before handing it to anyone else
- Dead man’s switch: when you stop sending the “I’m alive” signal, the system stops itself, safely
- What they share: they look like code terms, but they’re really attitudes — focus, safety, honesty, failsafe
| Term | One line | At work |
|---|---|---|
| Yak shaving | side-quests bury the goal | focus |
| Idempotency | many times = same as once | safe repetition |
| Dogfooding | use it yourself first | honest verification |
| Dead Man’s Switch | you stop → system stops safely | failsafe |
1. Yak Shaving
You want to wax the car, but the hose is missing. To buy one you need your store card, which expired; to renew it you have to return the neighbor’s book… and somehow you end up at the zoo, shaving a yak. The car is still dirty.
Yak shaving is exactly this — a side-task started for a real goal spawns another, then another, until you spend all your time somewhere that looks unrelated to the original work. The term is said to have come out of MIT.
It’s common in dev: “just fix one bug” → “need to update a library” → “need to swap the build tool” → half a day in config. Daily life too — sitting down to write one post and ending up redesigning the blog theme.
Getting out: ask once, “is this actually needed for what I set out to do?” If not, leave a note about the side-task and return to the main one.
2. Idempotency
Press the elevator button ten times and it still arrives the same as one press. That’s idempotency — doing the same action several times yields the same result as doing it once.
It’s originally a math term (f(f(x)) = f(x)), but in dev it matters most for safe retries. You send a payment request, get no response, and send it again. If it isn’t idempotent, you get charged twice. If it is, the same request is processed once — distinguished by an “idempotency key.”
Telling them apart is easy. “Delete” is idempotent (deleting an already-deleted thing leaves it deleted). “Add 1” is not (each press increments).
Why it helps: anywhere retries and automation live (payments, notifications, sync), it’s the lens for “if this runs twice, does something break?”
3. Dogfooding
“Eat your own dog food.” It’s said to come from a dog-food company proving quality by feeding it to its own dogs, and Microsoft spread it in 1988 to mean “let’s use our own software first.”
The idea is simple — use it yourself, as a user, before selling or shipping it to anyone. You only catch the bugs and feel the friction by actually using it.
The core is honesty. It’s hard to recommend a tool you don’t use yourself. Conversely, a tool you use daily gets better fast — because you’re the first to hurt when it’s clunky.
One more step — dogfooding goes as far as “I used it.” The next step is a stranger using it, and the real test starts there.
4. Dead Man’s Switch
What happens if a train driver collapses at the controls? Old trains had a pedal. The train runs only while the driver keeps the pedal pressed; lift your foot (collapse) and the train stops itself. That device is the dead man’s switch.
The name is grim, but the idea is simple — when you stop, the system stops itself, safely. Normally you keep sending an “I’m alive” signal; when that signal drops, it assumes the worst and fails toward safety.
Dev and automation use it the same way. If a trading bot stops responding, it closes positions automatically (otherwise a market swing catches you defenseless). If a server misses its periodic “heartbeat,” another server takes over.
Why it helps: for anything that runs unattended (bots, cron jobs, automation), it’s the habit of planting “if this dies, how does it stop safely?” in advance. Designing for how it dies is real safety, more than turning it on.
In One Line
The four point at attitude, not code.
- Yak shaving → don’t get lured by side-quests; focus on the point
- Idempotency → design so repeats and retries are safe
- Dogfooding → use it yourself before shipping
- Dead Man’s Switch → design for how it dies, not just how it runs
Name them and you can point at where work leaks — in conversations with developers, and when you work alone.