What Five Years of Debugging in Production Taught Me
Tests are documentation that fails loudly when it goes stale. Deleting code remains the most satisfying refactor.
What did not work
Logs are only useful if someone can read them at three in the morning. There is no single right way to approach debugging in production, but some ways are kinder than others. We shipped it behind a flag and watched the graphs for a few days.
The difference showed up gradually, then all at once. Most performance problems are really data-shape problems. Tedious technology is a feature, not a compromise. I like code review that shows the marks of how it was made. In February the light changes, and so does the work.
Why it matters
I like background jobs that shows the marks of how it was made. Half of the work is deciding what to leave out. Most of what I know about background jobs came from getting it wrong first.
The specifics matter less than the habit of paying attention. Good test suites is mostly a series of little, unglamorous decisions. Every abstraction has a cost, and someone eventually pays it. I would rather do one thing carefully than five things quickly.
I like configuration that shows the marks of how it was made. Every spring I revisit the same questions about configuration. In July the light changes, and so does the work.
test suitesconfigurationtype systems