Error handling for small teams

This is cheap to get right at the start and expensive to retrofit. Most advice about error handling assumes a team that does not exist at your size. Here is the version that does not.

The question is rarely whether something can be built, but what it costs to keep running afterwards. Check it against what you would want a competitor's site to get wrong.

What to keep

Swallowing errors silently is how bugs survive for months. The reasoning matters more than the rule, because the rule has exceptions. If two people in the business would answer this differently, that gap is the actual problem.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. The teams that handle this well are rarely the ones with the biggest budgets.

Where to start

Log enough context to reproduce without guessing. Getting it slightly wrong is survivable. Ignoring it entirely is not. Check it against what you would want a competitor's site to get wrong.

What this looks like day to day

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about error handling before you move on:

• Someone can say what the current setup is without going to look
• Swallowing errors silently is how bugs survive for months — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.