Rob Pike's Rules: What Startup Teams Get Wrong

A 35-year-old document about writing C programs just hit the top of Hacker News — and the reason it resonates so hard right now tells you everything about what's broken in modern startup engineering. Rob Pike's Rules of Programming, written in 1989, scored 901 points this week amid a raging debate about developer productivity, AI-generated code, and whether modern teams are actually shipping better software. They're not. And Pike's rules explain why.

This article is for founders and engineering leaders who feel like their team is always busy but never quite done — where deadlines slip, complexity compounds, and the codebase becomes a black box nobody fully understands. You'll walk away with a concrete lens for auditing your team's habits and a checklist you can use before your next sprint planning.

Why a 1989 Document Is Trending in 2025

The timing isn't accidental. We're in a moment of peak tooling complexity: AI code generation, microservices by default, infrastructure-as-code sprawl, and a new framework every quarter. Teams are adding capability faster than they're adding understanding. The result is software that works until it doesn't — and nobody knows why.

Pike wrote these rules when computing resources were scarce and every line of code had to earn its place. That constraint produced clarity. Today's abundance — of compute, of libraries, of AI-generated boilerplate — has produced the opposite: systems that are large, opaque, and fragile.

The HN resurgence is engineers recognizing that the fundamentals haven't changed, even if the tools have.

What Pike Actually Said

The rules are deceptively simple. Here they are, with the startup translation:

Rule 1: You can't tell where a program is going to spend its time.

Pike's point: don't guess at performance bottlenecks. Measure. The startup translation is broader — don't guess at where your engineering time is going either. We're seeing teams spend 40–60% of sprint capacity on unplanned work, rework, and coordination overhead. You won't know your number until you measure it.

Rule 2: Measure. Don't tune for speed until you've measured.

This is the most violated rule in startup engineering. Teams optimize their deployment pipeline, adopt Kubernetes, or rewrite services in a faster language — before they've established what's actually slow. The failure mode: months of infrastructure work that doesn't move the product forward.

Rule 3: Fancy algorithms are slow when n is small, and n is usually small.

For startups, read this as: don't build for scale you don't have. The team that spends Q1 building a distributed event-sourcing architecture for 200 users is the team that misses the market window. Simple solutions that work now beat elegant solutions that work at 10x scale — because you may never reach 10x scale if you don't ship.

Rule 4: Fancy algorithms are buggier than simple ones, and they're much harder to implement.

Complexity is where deadlines go to die. Every abstraction layer, every clever pattern, every "we might need this later" decision adds surface area for bugs and slows down every future engineer who touches that code. The founder who wonders why a "simple feature" takes three weeks is usually looking at accumulated complexity debt.

Rule 5: Data structures, not algorithms.

Pike's insight: get your data model right and the logic becomes obvious. Get it wrong and you're fighting the code forever. In startup terms: the teams that ship predictably have clear, stable data models. The teams that slip have data models that evolved organically and now require tribal knowledge to navigate.

The Startup Audit: Mapping Pike's Rules to Your Delivery Pain

Here's a practical scorecard. Run this against your current engineering state before your next planning cycle.

Pike's Rule	Startup Symptom When Violated	Diagnostic Question
Measure first	Sprints feel slow but you don't know why	Do you track where engineering time actually goes?
Don't optimize prematurely	Infrastructure work crowds out features	What % of last quarter was platform vs. product?
Keep n small	Over-engineered MVP	Could a junior dev explain your architecture in 10 min?
Avoid fancy algorithms	Bugs in "simple" features	How long does onboarding a new dev take?
Data structures first	Schema migrations every sprint	When did you last refactor your core data model?

If you answered "no," "don't know," or "too long" to more than two of these, your team has a complexity problem masquerading as a velocity problem.

Simplicity Is a Leadership Decision, Not a Technical One

Here's what most engineering articles miss: Pike's rules aren't primarily about code. They're about decision-making authority and culture.

Simplicity doesn't happen because engineers prefer it. It happens because someone with authority consistently says "no" to unnecessary complexity — and that someone is usually not in the room at most startups. Founders are managing product. Engineers are managing each other. Nobody is managing the accumulation of technical decisions.

This is the engineering black box problem in its purest form. Every week, dozens of small technical choices get made without a forcing function toward simplicity. A new library here, a new abstraction there. Each one defensible in isolation. Collectively, they become the reason your team can't ship a two-point ticket in under a week.

The fix isn't a new process. It's technical authority — someone who reviews architectural decisions with Pike's rules as the standard, and who has the standing to push back. This is exactly the kind of structural gap that 10ex's fractional CTO engagement model is designed to close.

What Predictable Delivery Looks Like in Practice

Consider a team that applies these rules deliberately. Before any new service gets added, they ask: can this be a function in an existing service? Before any new dependency gets introduced, they ask: what's the cost of owning this? Before any performance optimization, they ask: do we have data showing this is the bottleneck?

The result isn't a boring codebase. It's a codebase where a new engineer can be productive in days, not weeks. Where a bug in production has a small blast radius. Where a feature estimate is actually reliable because the team understands what they're working with.

This is what predictable delivery looks like at the engineering level. The Iron Triangle tradeoffs that plague most startup teams don't disappear — but they become manageable when the underlying system is legible.

Applying Pike's Rules in the AI Era

Pike's rules are more relevant now, not less. AI code generation makes it trivially easy to produce large amounts of code quickly. It does not make that code simple, well-structured, or maintainable. Teams that use AI tools without a simplicity discipline will accumulate complexity faster than ever before.

The question to ask before merging AI-generated code isn't "does it work?" It's "does it fit?" Does it fit the existing data model? Does it fit the complexity budget? Does it fit the mental model a future engineer will need to maintain it? For a deeper look at why this matters, see why LLMs write bad code and how to fix it.

Measure. Keep it simple. Get the data structures right. These aren't vintage constraints — they're the only way to stay in control of what you're building.

Where to Start This Sprint

Pick one Pike rule and apply it to your next sprint retrospective. Not all five — one. Ask your team: where did we add complexity we didn't need? Where did we optimize before we measured? Where did we build for a scale we don't have?

The answers will tell you more about your delivery problems than any velocity metric.

If the pattern you find is systemic — if complexity is accumulating faster than you can address it, or if you don't have the technical authority in the room to enforce simplicity — that's the problem 10ex works on directly. Not by adding process, but by embedding the judgment that keeps engineering legible and delivery predictable.