The boring parts of a project are where the real bugs hide

Rebuilding EWOS's inventory onto a proper SKU convention and category taxonomy this week surfaced a genuine correctness bug: Unit Price had been calculated as price-per-pack rather than price-per-piece, wrong for roughly 60 multi-pack rows. Nobody flagged it because nothing crashed — the numbers just quietly didn't mean what the column header said they meant.

Same shape of problem, different tool: an Excel Table's TOTAL formulas stop covering new rows the moment you append past the table's original boundary, with no warning that they've stopped. The fix is mechanical once you know to look for it. Knowing to look for it is the actual skill.

The pattern repeated moving the data into InvenTree. The bulk import wizard silently stalls when you select-all across many pages — no error, it just stops working, so the fix was paging through 25 rows at a time and confirming each page rather than trusting ‘select all’ to mean what it says. Bulk stock quantities have no CSV import path in the UI at all — that one needed the REST API directly, called from an authenticated browser session, rather than 175 manual entries.

None of these were hard problems once found. All of them were silent — no crash, no error, no obvious signal that something was wrong. The lesson isn't ‘check your work’, it's more specific than that: the parts of a project that feel too boring or mechanical to double-check are exactly the parts most likely to be quietly wrong, because nobody's watching them closely enough to notice when they are.