Why I Stopped Reading "Best Practices"

I used to read everything. Every blog post about "microservices best practices." Every Medium article on "how to scale to 10 million users." Every white paper from AWS on "architecting for reliability."

And for a while, it worked. You absorb the conventional wisdom, apply it, and you look competent. Your architecture diagrams get nods in meetings. Your code reviews cite industry patterns.

But here's what nobody tells you: best practices are just the average opinion of the last five years.

They're not wrong, exactly. They're just… average. And if you want to build something world-class—something that doesn't just meet the bar but raises it—you have to stop reading the crowd and start thinking from first principles.

The Problem With "Best Practices"

Best practices emerge from consensus. A bunch of smart people try different approaches, a few patterns work better than others, and eventually those patterns get codified into blog posts, conference talks, and consultancy frameworks.

This process has value. It prevents you from making the most obvious mistakes. It gives you a starting point when you're working in unfamiliar territory.

But it also has a dark side:

• They lag reality by years. By the time something becomes a "best practice," the conditions that made it optimal have often changed. The tooling has evolved. The scale has shifted. The constraints are different.
• They optimize for the average case. Best practices are designed to work reasonably well for most organizations. But your organization isn't average. Your constraints, your team, your performance envelope—they're unique.
• They kill innovation. When you follow the playbook, you get playbook results. Incremental improvements, sure. But breakthroughs? Those come from people who ignored the manual.

The First Principles Alternative

When Link11 was scaling our DDoS mitigation infrastructure, every "best practice" told us to use Kubernetes. Cloud-native, horizontally scalable, industry standard. The safe choice.

But when we broke it down to first principles—what are we actually trying to achieve?—the answer was clear:

• We needed to route and filter massive volumes of traffic with sub-millisecond latency.
• We needed deterministic performance under extreme load.
• We needed to minimize operational complexity during incidents.

Kubernetes gave us none of that. It gave us YAML sprawl, sidecar latency, and a control plane that became a liability under stress.

So we didn't use it. We went back to boring VMs, custom routing logic, and eBPF for packet filtering. Our deploy times dropped 90%. Our incident response became surgical instead of chaotic. Our latency became predictable.

Was it "best practice"? No. Did it work better for our problem? Absolutely.

How to Think Without the Playbook

Here's my framework for ignoring best practices without falling into chaos:

1. Understand the constraint you're optimizing for

Every architecture is a trade-off. Best practices optimize for generality—they work okay in most situations. But if you know your constraint (latency, cost, developer velocity, compliance), you can design for that instead.

2. Study the history of the pattern

Most "best practices" were invented to solve a specific problem in a specific context. If you understand why microservices became popular (monoliths couldn't scale teams at Google), you can decide whether that reason applies to your 12-person startup.

3. Measure, don't assume

Best practices are assumptions packaged as advice. Test them. Benchmark them. Compare them to alternatives. The data will tell you if the conventional wisdom applies—or if you're better off ignoring it.

4. Be willing to look stupid (for a while)

When you deviate from the playbook, people will question you. Your peers will cite blog posts. Vendors will tell you you're doing it wrong. You have to be okay with that—and you have to be right often enough that the results speak for themselves.

When to Follow Best Practices Anyway

I'm not saying you should reinvent everything. There are times when the conventional wisdom is genuinely optimal:

• When you're in unfamiliar territory. If you don't understand the domain, follow the playbook until you do. Learn the rules before you break them.
• When the stakes are low. If the decision doesn't matter much, just pick the standard and move on. Save your contrarian energy for the things that actually move the needle.
• When you're optimizing for hiring. If you use obscure tech, you'll struggle to hire. Sometimes "boring and popular" is the right trade-off.

But for the decisions that define your competitive edge? The ones that determine whether you're fast or slow, resilient or brittle, scalable or stuck?

Ignore the blog posts. Understand the physics. Build from first principles.

The Best Practice Is Not Having One

The most successful companies I've studied—Link11 included—don't follow a playbook. They write one. They figure out what works for their constraints, codify it, and then iterate as those constraints evolve.

That's what separates good engineering from great engineering. Good engineering is competent execution of known patterns. Great engineering is figuring out when the patterns don't apply—and having the confidence to build something better.

So the next time you see a headline like "10 Best Practices for [Insert Buzzword]," ask yourself: Best for whom? Under what constraints? For what goal?

If the answers don't match your reality, close the tab. You've got better things to build.