Taco Bell Programming (2010)

2026-08-26

Link: https://widgetsandshit.com/teddziuba/2010/10/taco-bell-programming.html

HN Discussion: 1 points, 0 comments

Ted Dziuba's "Taco Bell Programming" is one of those rare essays from the late-2000s blogosphere that has quietly shaped how a generation of pragmatic engineers think about tooling. The premise borrows from the fast-food chain's famous business model: Taco Bell sells a dozen products, but they're really just seven ingredients rearranged. Dziuba argues that great engineering works the same way — most problems don't need a bespoke framework, a new database, or a distributed system. They need xargs, find, awk, and a willingness to think.

The canonical example in the piece: someone wants to build a distributed job queue to process a few million URLs. Dziuba's counter is that xargs -P on a single beefy machine will chew through the workload in an afternoon, with zero infrastructure, zero failure modes you didn't already understand, and zero on-call pages at 3am. The "boring" Unix toolbox often beats the shiny distributed system — not because distributed systems are bad, but because you rarely actually need one, and the ones you build yourself are almost always worse than the ones you didn't.

Why does this deserve attention in 2026? Because the trap has only gotten worse. Fifteen years after Dziuba wrote this, the industry has piled on Kubernetes, service meshes, event buses, vector databases, and now an entire ecosystem of "agentic" orchestration frameworks — all layered on top of problems that a shell one-liner and a cron job would have solved cleanly. Every senior engineer eventually rediscovers Taco Bell Programming under a different name: "worse is better," "boring technology," "just use Postgres," "the majestic monolith." Dziuba got there first, and did it with more humor.

The essay is also a useful lens for evaluating LLM-generated code. Models love to produce elaborate abstractions, custom classes, and heavy dependencies for problems that want a five-line script. Reading (or re-reading) this piece is a good calibration exercise: the question isn't "what's the most sophisticated solution?" but "what's the fewest moving parts that actually solves it?"

It's short, it's funny, it's from a defunct-feeling blog that miraculously still resolves, and it will genuinely make you a better engineer. That it's sitting at 1 point with zero comments is a small tragedy.

Why it deserves more upvotes: A foundational essay on engineering pragmatism that's more relevant now, in the age of over-engineered AI stacks, than when it was written in 2010.

All newsletters