At the end of a long day immersed in the world of software and systems (sometimes in the middle if working from home), I sometimes relax by cooking myself a meal.

I am but a lowly home cook, but I feel that I've learned something over the years. When visiting certain friends, I am sometimes amazed by the number of kitchen gadgets in their possession, one for every conceivable task, bread makers, egg slicers, omelette makers etc..., but when handed a kitchen knife, I can only look on while holding my breath as they grip it like a baseball bat, brow furrowed in concentration and push it down slowly on some poor, unfortunate vegetable.

It got me thinking ...

Look at a professional chef's kit. It fits in a roll bag. A good knife, a few pans, a chopping board, a handful of essentials. The chef isn't under-equipped. They've learned, through years of daily practice, that technique with a good knife covers 95% of what they'll ever need.

The difference isn't budget or awareness. The chef knows the gadgets exist. They've probably tried most of them. The difference is that the chef has cooked enough meals to know what actually matters versus what just looks like it should help.

Software Has a Gadget Drawer Too

The software industry has its own version of this kitchen drawer: Kafka, Kubernetes, microservices, event sourcing, CQRS, service mesh. Each one is a real tool that solves a real problem. None of them are wrong.

But they get adopted the same way the spiraliser, or apple corer does. A conference talk made it look transformative. A blog post made it look easy. The team at the last company used it, so it must be the right call. Everyone seems to have one.

The cost is higher than a plastic gadget, though. Months of integration work. Operational complexity that never goes away. Cognitive overhead that compounds across the team. And unlike the egg slicer, you can't just leave it in the drawer when it turns out you didn't need it; by the time you realise, it's an egg slicer that requires building control and a structural surveyor to approve if you even think of looking at it.

The Knife

So what is the equivalent of the 95% tool for a software developer?

It's not a product. It's not something you can install. The knife is data structures and algorithms. Not in the LeetCode sense; not inverting binary trees on a whiteboard to impress an interviewer. In the real sense: knowing how to model a problem. Knowing when a list is enough and when you need a set. Knowing that a queue is the right abstraction before reaching for a queue product. Understanding how data flows through a system, how to normalise it, how to think about access patterns before writing a single line of SQL.

This is the skill that transfers across every language, framework, and database you'll ever touch. Frameworks change. Languages fall in and out of fashion. The engineer who understands how to structure data and reason about algorithms will outlast every hype cycle, because the knife never goes out of date. Engineers who reason at this level understand that a database is, at its heart, a bunch of interlinked trees and hash maps. A queue is a double-ended array. A distributed compute cluster is a map-reduce engine.

These underlying structures are everywhere. Like things you can cut in a kitchen, that people might want to eat.

A chef doesn't buy a new knife every year. They sharpen the one they have.

The Chopping Board

A knife needs a surface to work on. Nobody shows off their chopping board. It's not exciting. You'll never see a conference talk about the merits of a good chopping board. But try doing prep without one.

Postgres is a chopping board. A monolith is a chopping board. A test suite is a chopping board.

Not because they're simple. A good chopping board is a precision surface: stable, durable, forgiving on the blade. These tools are the same: powerful, versatile, and deep enough to reward years of increasing skill. Postgres has been refined for decades. A well-structured monolith with a clean data layer is the most productive architecture most teams will ever need.

A competent engineer with strong fundamentals, Postgres, and a well-structured monolith can build systems that serve millions of users. Schema design, access patterns, state management, domain modelling: these are knife skills applied to a reliable surface. They compound in ways that tool-specific knowledge never does.

The amateur reaches for a new gadget when something feels hard. The chef reaches for better technique with the tools already on the bench.

Earning Your Specialist Tools

A chef does own specialist tools. A mandoline for cuts that a knife genuinely cannot match. A thermometer for precision that human senses cannot provide. A stand mixer for tasks where muscle and time aren't enough. But each one earned its place through repeated, specific need; not through aspiration.

In software, the equivalent is a service for ML inference that is genuinely novel and tricky. An OLAP data analytics system when you genuinely need high-level, flexible analysis of vast reams of data. A search index when your query patterns outgrow what SQL can express.

The test isn't "does this tool exist" or "could it theoretically help". It's "have I hit the limit of what the knife can do for this specific task, and can I articulate exactly what that limit is". If you can't name the constraint, you haven't earned the gadget yet. You're buying the travel waffle-iron.

Becoming a Chef

The progression from amateur cook to professional chef isn't about acquiring more tools. It's about needing fewer. It's the confidence that comes from depth with fundamentals rather than breadth of toolkit.

That's what this series is about. Not a tour of the gadget catalogue, but the knife techniques: state machines for modelling how work moves through your system. Data layers that keep your options open. Architecture patterns that start simple and earn complexity. Queue strategies that use what you already have.

Technique with a good knife. It's enough to build something serious.