What I learned from reading other people’s code
Tests are documentation that fails loudly when it goes stale. Boring technology is a feature, not a compromise. Half of the work is deciding what to leave out.
Small things
The result is not perfect, but it is candid. Little, repeatable steps beat big plans nearly every time. I am still not sure I have it right, but it is closer.
The fix was three lines; finding it took most of a week. You can get unexpectedly far with a local database and some patience. There is a version of this that is much more complicated. This is not that version.
Deleting code remains the most satisfying refactor. Most of what I know about build pipelines came from getting it wrong first. I changed my mind about background jobs twice while writing this. I attempted the reliable version first. It did not last. Every abstraction has a cost, and someone eventually pays it.
Getting started
There is no single right way to approach deleting code, but some ways are kinder than others. Good database migrations is chiefly a series of little, unglamorous decisions. None of this is new, and that is partly why it works. This is less a primer and more a record of what worked for me.
Below are a few jottings, roughly in the order I picked up them. If you only take one thing from this, make it the part about test suites. The trick, if there is one, is to leave sufficient room for slip-ups. Here is what changed, and what stayed exactly the same. Most problems with error handling turn out to be problems with time.
If something here is unclear, that is on me, not you.
error handling