Engineering · 6 min
I taught bulk uploads to behave (mostly)
Bulk uploads sound simple until you're the one holding the pager when someone imports a spreadsheet with 40,000 rows, half of which have trailing whitespace in the employee ID column.
The brief was straightforward: let HR operators add, deduct, and adjust entries for entire employee cohorts in one go, and do it in under ten minutes. The reality was a queue of small, boring failure modes — duplicate rows, partial batches, someone re-uploading the same file twice because the first "processing" spinner didn't feel confident enough.
What actually mattered
Most of the engineering effort didn't go into the upload pipeline itself. It went into making failure legible: which rows succeeded, which didn't, and why, in language a non-engineer could act on without pinging us on Slack.
A few things that helped:
- Validating client-side before the file ever left the browser, so obviously bad files never entered the queue.
- Chunking large batches so a single bad row didn't take down the whole import.
- A results screen that read like a diff, not a stack trace.
It's not glamorous work, but it's the difference between a feature people trust and one they route around.