Order fixes by blast radius

When several defects turn up at once, the order I fix them in is by blast radius: whatever breaks visibly first, whatever corrupts data silently second, and the performance change last, because a speed-up measured on top of unresolved bugs is a number about the wrong thing.

Earned on EaseMySemester v1

Once real students were on v1 I ran a hardening pass of eight fixes, one commit each so any of them could be backed out alone, ordered by what actually breaks rather than by the order I found them.

The first three produced something a student could see: an unhandled database pool error taking the whole process down, a raw exception screen where a page should be, an import screen going white when a session expired. The other five quietly corrupted the question bank, which is worse because nobody reports it. Cleanup deletes were sweeping the whole database, so publishing Anatomy was quietly garbage-collecting Biochemistry.

The speed fix went last on purpose, because it rewrites the same loops the earlier fixes touch and doing it first would have undone them. It took a 2,000-question publish from about 6,000 separate database round trips, which blew past every serverless timeout, to about 1.7 seconds. Both figures are v1's, from the write-up of that pass.

Reused on Semantic Search

Five concurrency defects were fixed in blast-radius order too. The deadlock went first: clicking Start twice took the whole server down and it did not come back on its own. Then correctness and typing, before requests were allowed to run at the same time, because making something faster before making it right only produces the same bugs at higher speed. The change anyone would notice, moving the blocking work off the event loop, went last, since on its own it would have shown no speed-up at all while everything still queued behind the same lock, and it would have looked like a failed optimisation. The project's first 16 tests shipped with that work. See the concurrency audit sequencing decision.

Why the order matters

Two things go wrong otherwise. A measured improvement sitting on a measured bug flatters whichever number is checked first, and the fast change that runs over the same code as the correctness fixes can undo them. Ordering the work is part of making the measurement honest, not a tidiness preference.