Software engineering is drowning in false signals. We optimise for the wrong metrics, test the wrong skills, and chase the wrong goals.

When Answers Are Cheap, Questions Become Expensive

Stack Overflow can solve almost any technical problem in seconds. Yet we still test answers in interviews, not the ability to ask the right questions.

LLMs have made information retrieval almost free, but our interview processes haven’t adapted. The hard parts of engineering aren’t about having answers memorised — they’re about problem identification, context understanding, question formation, and solution evaluation.

The best engineers aren’t human compilers — they’re human debuggers, finding the right questions when systems behave unexpectedly.

Solve Your Own Problems, Not FAANG Problems

Google built Kubernetes to manage thousands of services across millions of servers. Netflix created chaos engineering for massive distributed systems. Facebook invented React for complex UI state at scale.

But you are not Google. You are not Netflix. You are not Facebook.

Their problems are not your problems. Their solutions may be overkill or actively harmful for your context.

Start with the simplest thing that could work. Optimise for maintainability. Add complexity only when forced by real constraints.

The Hype-Driven Development Trap

Hype makes your resume look cool. But it does nothing good for your project.

Hype-driven: “We need Kubernetes to scale” (for your 3-user MVP) Question-driven: “What problem are we actually trying to solve?”

Choose Boring Technology

Boring technology is boring for a reason — it works. PostgreSQL, Linux, HTTP. Battle-tested, reliable, foundation of nearly every successful system.

New technology solves new problems, but most of us don’t have new problems.

A Better Way Forward

Ask better questions. Solve your own problems. Choose boring technology when it works.

That’s how you build things that actually work.