With many decades of collective experience navigating the shifting tectonic plates of software engineering, our team at Saropa views the industry through a strictly empirical lens. We have lived through the foundational philosophies, analyzed the catastrophic security post-mortems, and written the countless boilerplate that keep systems running. From this vantage point, the terrain has fundamentally shifted.
We are building massive, distributed, and incredibly complex systems — now aided by machine intelligence — using philosophies forged in an era that pre-dates the browser.
Chief among these foundations is Rob Pike’s legendary list, often abbreviated as “Pike’s Rules,” which shaped decades of software engineering. Codified during his time at Bell Labs, they championed empirical proof over intuition and a profound respect for simple, verifiable logic. They were designed to stop programmers from writing brittle code in a desperate search for minor efficiency gains.
Saropa's 5 Rules of Programming
- - - - - - - - - - - - - - -
**Rule 1. Simplicity does not excuse slow architecture.** Trust your domain experience to avoid systemic bottlenecks, but always prove your micro-optimizations with data.
**Rule 2. Measure the micro, design the macro.** You can use a profiler to fix a bad function, but you cannot profile your way out of a fundamentally flawed system.
**Rule 3. Outsource the logic, own the spec and the architecture.** Let AI write your algorithms, but recognize that in 2026, writing the spec is writing the software.
**Rule 4. Write for the next maintainer, human or machine.** Clever abstractions are a security risk and an automation nightmare. Simple code is verifiable.
**Rule 5. Data dominates.** Choose the right data structures and encode your invariants, and the algorithms will be self-evident.But for the modern developer looking to build secure, performant software today, we must bridge the gap between that foundational wisdom and the reality of cloud-native development. The industry’s rigid adherence to “avoiding premature optimization” has too often become a philosophical shield used to justify grossly inefficient, heavily abstracted software.
Here is that bridge — a synthesis of Pike’s core truths, community critiques, modern variances, and the reality of modern development.
“A good programmer is someone who always looks both ways before crossing a one-way street.” — Doug Linder
The Rules of Programming in 2026
Rule 1: Simplicity does not excuse slow architecture.
Original rule: You can’t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don’t try to second guess and put in a speed hack until you’ve proven that’s where the bottleneck is.
We must stop using “premature optimization is evil” to justify unacceptably slow software. In 1989, you couldn’t tell where a program spent its time, so micro-tuning was a waste. Today, we build systems within established domain contexts. A senior backend engineer working in 2026 must know intuitively that hitting an external API synchronously inside a user request loop is not a “simple” design; it is a broken design.
Today, performance problems rarely stem from a clever loop; they stem from distributing operations across microservices and causing N+1 query problems at a enormous scale. Performant distributed design is a feature, not an afterthought.
- Synchronous cross-service calls inside iteration loops.
- Unbounded database queries triggered by lazy loading in ORMs.
- Excessive payload serialization/deserialization across network boundaries.
- Unmanaged connection pools leading to resource exhaustion under load.
Rule 2: Measure the micro, design the macro.
Original rule: Measure. Don’t tune for speed until you’ve measured, and even then don’t unless one part of the code overwhelms the rest.
Pike was right: you must measure performance. But the definition of measuring has changed. In his era, you profiled local CPU cycles. In 2026, software rarely bottlenecks on CPU cycles; it bottlenecks on distributed systems problems like network latency between services, database connection pooling, cold-start times, and cloud memory transfers.
[ CPU ] <---> [ Local Memory ]
(Bottleneck: Cycles)
[2026: Distributed Architecture]
[ Service A ] ---> (Network) --->[ API B ] ---> (Network) ---> [ DB C ]
(Bottleneck: Latency, N+1 Queries, Cold Starts)Measuring these system-level issues is exponentially harder than running a local profiler. You must still profile your local code, but you cannot afford to wait to measure your macro system until implementation is done. You must proactively design for macro-scale performance.
Rule 3: Outsource the logic, own the spec and the architecture.
Original rule: Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don’t get fancy. (Even if n does get big, use Rule 2 first.)
The classic struggle of manually implementing fancy algorithms is largely over. Modern tooling and AI assistants can generate optimized implementations of a B-tree or a specific data transform instantly.
[ Human Intent ]
|
(High Value)
|
v
[ Domain Spec & Types ]
|
(Critical Boundary)
|
v[ AI Assistant / Tooling ]
|
(Commodity)
|
v[ Boilerplate / Logic ]
|
(Low Value)However, these tools cannot yet solve for your unique high-level business context. They tend to suggest naive structures and defaults because they maximize for the “literal mean” rather than context-specific excellence.
Let the tools do the tedious typing of the logic, but the modern human engineer must take total ownership of the domain specification and architectural boundaries. In 2026, writing the spec is writing the software.
- Strict API contracts (e.g., OpenAPI/gRPC definitions).
- Documented data invariants and state transition boundaries.
- Explicit non-functional requirements (latency budgets, concurrency limits).
- Defined security perimeters and trust boundaries.
Rule 4: Write for the next maintainer, human or machine.
Original rule: Fancy algorithms are buggier than simple ones, and they’re much harder to implement. Use simple algorithms as well as simple data structures.
Simple remains better, but the reasoning rests on two modern pillars: security and automation. In a world where the software ecosystem is under constant attack, clever code is a major vulnerability risk because it is harder to verify.
As cryptography engineer David Wong has noted, the most efficient code often trades off the clarity required for verification.
- Auditability: Metaprogramming obscures execution paths during security reviews.
- Refactoring: AI agents struggle to accurately refactor highly abstracted or implicit logic.
- Onboarding: Human maintainers waste cognitive load decoding “magic” syntax rather than understanding business logic.
Furthermore, your code will inevitably be ingested, analyzed, and automated by AI models. Clever metaprogramming or deep inheritance trees confuse both humans securing the system and tooling trying to automate a refactor. Simple, verifiable code is the only sustainable path.
Rule 5: Data (and types) dominate.
Original rule: Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
This is the king. While Pike’s core truth remains untouched, the 2026 revision explicitly adds ‘types’ to reflect how modern systems enforce this rule at scale. Data dominance is no longer just a structural philosophy; it is a mechanical constraint.
Visualizing the top-down hierarchy of modern system design and why Rule 5 holds true…
[ Strongly Typed Data Structures ]
|
(Constrains)
|
v[ Application State ]
|
(Dictates)
|
v
[ Control Flow ]“One man’s crappy software is another man’s full time job.” — Jessica Gaston
Looking Ahead
Echoing legends like Fred Brooks, data remains the fundamental foundation of computation. Whether you are in 1989 writing C, or in 2026 architecting a multi-agent autonomous system, the truth remains: if your data structures and domain relationships are correct, and your invariants are strictly encoded into strong types, the control flow of the entire application will almost always be self-evident.
Designing the data remains the single, critical, uniquely human task in software engineering.
Everything else is just typing.
“I don’t care if it works on your machine! We are not shipping your machine!” — Vidiu Platon
BONUS: The Modern 5 Rules: AI System Prompt
# CORE BEHAVIOR AND RULES OF ENGAGEMENT
1. ARCHITECTURE OVER MICRO-OPTIMIZATION (Rule 1 & 2)
- Never hide I/O operations, network requests, or database queries inside loops.
- Flag potential macro-bottlenecks (N+1 queries, high memory transfers, cold starts) before writing the implementation.
- Do not micro-optimize local CPU cycles (like loop unrolling) at the expense of readability unless explicitly instructed.
2. SPEC-DRIVEN IMPLEMENTATION (Rule 3)
- Act as an implementer, not an architect.
- Do not invent new architectural boundaries, change the stack, or introduce new design patterns without explicit permission.
- Strictly adhere to the provided specification. If the spec is missing or ambiguous, STOP and ask for clarification before writing logic.
3. WRITE "BORING" CODE (Rule 4)
- Prioritize extreme readability and verifiability.
- Avoid clever metaprogramming, deep inheritance trees, magic methods, and obscure language features.
- Write code that a stressed human can debug at 2 AM and another AI can easily parse for future refactoring. Security through clarity is mandatory.
4. DATA AND TYPES FIRST (Rule 5)
- Always establish and validate data structures, types, interfaces, and schemas BEFORE writing any control flow or algorithms.
- Encode business invariants strictly into the type system wherever the language allows.
- If the requested logic does not elegantly fit the existing data structures, flag the data structure as the problem rather than writing a messy workaround.Sources and Further Reading
- Rob Pike/UNC.edu, Rob Pike’s 5 Rules of Programming — https://www.cs.unc.edu/~stotts/COMP590-059-f24/robsrules.html
- Rob Pike/Yale University, Notes on Programming in C — https://zoo.cs.yale.edu/classes/cs323/doc/Pike.pdf
- Donald Knuth/ACM, Structured Programming with go to Statements — https://dl.acm.org/doi/10.1145/356635.356640
- Alan J. Perlis/Yale University, Epigrams on Programming — https://www.cs.yale.edu/homes/perlis-alan/quotes.html
- David Wong/Cryptologie.net, David Wong’s 7 rules of programming — https://www.cryptologie.net/posts/david-wongs-7-rules-of-programming/
- Linus Torvalds/LWN.net, Quote of the week — https://lwn.net/Articles/193244/
- Addy Osmani/AddyOsmani.com, How to write a good spec for AI agents — https://addyosmani.com/blog/good-spec/
- Hacker News/Y Combinator, Rob Pike’s 5 Rules of Programming (Discussion) — https://news.ycombinator.com/item?id=47423647
- Fred Brooks/Wikipedia, The Mythical Man-Month — https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Final Word 🪅
