The Knife in My Hand

May 01, 2026 · 7 min read

My kitchen knives are not beautiful. Blue plastic handles, no rivets, nothing decorative. They look like what they are: tools for working in a kitchen, not display pieces.

They are, however, extremely good. Heavy, precisely ground, tough enough that I haven’t chipped one in years of real use, sharp enough to cut a tomato under the weight of the blade alone. Sized correctly for my hands. I maintain them. I know them.

They live in a knife roll in a kitchen drawer – canvas keeps the edges separated, a drawer keeps them away from small prying hands not yet ready to handle a very sharp knife. Six in the roll: a steel, a chef’s knife, a fish knife, a Santoku, a butcher’s dagger, and a paring knife.

This post is about what I’ve learned through those knives. Most of it turns out to apply to software.

A dull knife is more dangerous than a sharp one

The first thing any cook learns, and the last thing home cooks seem to believe, is that a dull knife is more dangerous than a sharp one.

A sharp knife bites into what you’re cutting where you put it. A dull knife slides. It requires more force to do the same work, and force that isn’t going into the cut has to go somewhere – usually into the hand of the person holding the knife, on the day they’re tired and the tomato is firmer than they expected. Dull-knife injuries are the ones that need stitches.

The analogue in engineering is almost embarrassingly direct. A broken test suite is more dangerous than no test suite. A stale monitoring dashboard is more dangerous than no dashboard. A CI pipeline that’s “mostly green” is more dangerous than one that’s explicitly red. The thing you want is a tool that gives you a clean, honest signal and that you trust enough to act on. A tool you mistrust, that slides off the tomato, that you have to lean on to get through – that tool is the injury waiting to happen.

Sharpen your knives. Fix your tests. Don’t tolerate dullness. Dull, blunt, less likely to cut – these things aren’t safer, no matter how they look.

Pick the right tool. Then practise with it.

The chef’s knife rocks through dense vegetables. The Santoku slices straight down through soft fruit. The paring knife works in tight space against your thumb. The fish knife flexes to follow a spine. None of them is a “better knife” in the abstract – each one exists because it fits a different job. Trying to bone a fish with a chef’s knife is awkward no matter how skilled you are. The first move in any cut is choosing the right knife for it.

The second move is having practised with it. When I’m cooking I reach for the chef’s knife without looking. I know its weight, how it rocks, how much pressure it takes through a carrot or a butternut squash. I know the Santoku picked up a spot of rust a few weeks ago – left in the sink too long after a distracted Sunday – and how it felt under the cloth when I worked it out. The muscle memory this develops doesn’t replace choosing the correct knife; it means I’m faster, safer, and more comfortable using the most accurate tool.

Picking up a new knife costs you. Hand me a hand-forged Japanese knife tomorrow and I’d be slower with it for a week. The handle the wrong shape, the balance different. I’d be thinking about the knife instead of the food. That dip is real – and it’s the price of upgrading, not a reason to skip the upgrade. The tool that promises to make you 20% faster once you’ve learned it will make you 40% slower for the three months you’re learning it, and then 10% faster forever. Nothing ever meets the hype, but the right tool can get close enough. Pay the dip once for the right tool and you recoup it the rest of your career.

Some tools never fit. A knife with the wrong handle for your hand causes fatigue every cut – no amount of practice fixes that. The learning dip is recoupable; an ill-fitting tool is friction forever. Selection comes before practice, and you can’t practise your way out of a bad selection. Software architecture is the same kind of choice – the framework, the database, the language. Get those right and practice compounds; get them wrong and practice runs into walls.

The trap isn’t deliberate upgrades. It’s churning – picking up a new knife, or a new editor, or a new build tool, every month, never quite getting past the dip, never quite cashing in the upside. Pick deliberately. Then put in the practice.

Practice is the cut, not the recipe

The way you get good with a knife is that you cut. A lot. You cut deliberately slowly to pay attention to grip and rhythm, and you cut at speed when you’re in a hurry and discover the edges of your technique.

The technique is the floor, not the ceiling. You learn it in a weekend. Then you spend ten years making it automatic – so automatic that you stop thinking about the knife and start thinking about the food. The difference between a good home cook and a professional is almost never knowledge; it’s repetition. Professionals have cut ten thousand onions. You have cut one hundred. They’re not smarter; they’re smoother.

You don’t “know” SQL after reading a book. You know SQL after a thousand queries and several slow joins you had to rewrite. The book is the technique; the queries are the practice.

Speed comes from practice, not pressure. Every time I’ve seen an engineer try to move faster by concentrating harder, they’ve moved slower. Every time I’ve seen one move faster by doing something they’d done a hundred times before without thinking about it, they’ve been right.

Care as part of the craft

Every time I pull the knife out of the roll, I run it a few strokes down the honing steel. Ten seconds. I do it so automatically I’d feel wrong starting to cut without it.

When I’m done, I wash the knife by hand – dishwashers are hostile to good knives – dry it on a tea towel, and slide it back into its slot. Thirty seconds, every time, for so long that it isn’t a chore, it’s just what happens at the end of cooking.

Every few months I take the knives to a professional sharpener. I hone them every day because that’s use and maintenance in the same motion. But when they need actually sharpening – a proper regrind – I hand them to someone whose whole craft is sharpening knives. There is no prize for doing everything yourself.

The care is not separate from the cutting. It’s the same practice. A knife used a lot and cared for consistently gets better over time. A knife used a lot and cared for occasionally gets worse, because damage accumulates faster than attention.

The single biggest thing separating engineers who get better from engineers who plateau is whether they care for their tools alongside using them. Whether their editor config quietly improves. Whether they know the keyboard shortcut for the thing they do fifty times a day. None of it is glamorous. None shows up on a CV.

Six knives

Six knives in a roll, a board, a professional sharpener every few months. I can make almost any dinner in the world from those objects plus a pan and some heat.

I’ve been tempted to buy more. The internet is very good at trying to sell me more – beautifully photographed knives with long waiting lists and three-figure price tags, the kind that live on magnetic strips in other people’s kitchens. My knives cut something every day. They don’t look like anything special. They work.

The craft is not in the accumulation of tools, and certainly not in the appearance of them. The craft is in picking the right tools and putting in the work to know them. The tools that get photographed are rarely the tools that get used.

I look at my terminal and see the same thing. A few commands and shortcuts I’ve used so many times they feel like extensions of my hand. The rest is decoration.

Pick your tools. Keep them sharp. Use them every day. Practise. Replace one deliberately, when you can name the thing it doesn’t do that you now know you need.

The practice is the point.

These posts are LLM-aided. Backbone, original writing, and structure by Craig. Research and editing by Craig + LLM. Proof-reading by Craig.