The best engineers know when not to code

The request was simple. Every time a customer placed an order, the warehouse team wanted a message in their group chat and a new row in a shared spreadsheet.

One of our engineers picked it up and lit up. Finally, a chance to build something proper.

First came a webhook receiver. Then a queue, so no order would ever get lost. Then retries with backoff. Then a websocket feed, so a live dashboard could show orders as they landed. Then monitoring for all of it. Clean code, good tests, a beautiful architecture diagram.

Three weeks later, it shipped. It worked perfectly.

A few days after that, someone from operations showed me the same thing, rebuilt in n8n during a lunch break. One trigger, two steps, done. It even retried when something failed.

Nobody was wrong to care about quality. But we had brought world-class engineering to a lunch-break problem, and paid for it with three weeks we would never get back.

The best X is no X

I keep running into the same pattern:

• The best screen is no screen. That was the order that should just show up.
• The best support is no support. That was the fix nobody should need twice.
• The best communication is no communication. When a problem never happens, nobody has to message back and forth, reproduce it, explain it, and confirm it is fixed.
• And the best custom build is often the one you didn't need.

Every line of code you write is a line someone has to read, run, fix, and keep alive for years. A tool that costs $10 a month comes with a whole team doing all of that for you.

Why the trap is bigger now

Engineers are builders. When we see a problem, our hands reach for the keyboard first. That instinct is what makes us good, and it's also what wastes our time.

AI makes it worse. Code is cheap and fast now. You can generate a whole webhook service in an afternoon, and it feels free. It isn't. You still own it forever.

Look around before you build

Before writing anything, spend thirty minutes asking:

• Has someone already built this? Tools like n8n or Zapier handle a huge amount of everyday automation.
• Can we pay a few dollars a month instead of spending a few weeks?
• If we build it, who looks after it two years from now?

If the answer is still "build it", build it with pride. Sometimes custom really is the right call.

But the best engineers I know are not the ones who write the most impressive code. They're the ones who know when not to write any.