People run liquid through computers to tell you how much drugs is in your drugs. That’s how I explain a QC lab to people outside tech, and it covers about as much of the job as a stranger wants.
I started there, pipetting samples. Dissolutions, assays, residual solvents, IR. The same tests come over and over. Between them you clean the flasks, make mobile phase, wash the columns, and check that everything on the bench is fresh and not expired. You follow all the rules and make sure every analysis is above board, because the result is going into drugs. It’s a good place to start. It is also robotic and predictable, and those two facts are the same fact.
The regulation is why. 21 CFR 211.165(e) says the accuracy, sensitivity, specificity, and reproducibility of a test method “shall be established and documented.” 211.194 wants the method stated in the record, its suitability verified under actual conditions of use, a complete record of all data, and a second person’s initials saying they reviewed it. By the time a new analyst picks up a flask, the question (how much of the active is in this tablet), the procedure that answers it, and the shape of a valid answer have all been written down and approved by someone else. What’s left is execution.
Tedium is what a finished specification feels like from the inside.
Data is different. It takes a lot to understand your data, what it means, and which feature or customer need it’s supposed to serve. The question arrives first and the definitions get worked out behind it, usually in a meeting, usually again next quarter.
Two things keep data work from getting boring, and they deserve opposite treatment.
The first is that the words aren’t written down. What counts as a sample, which rows are available, whose copy wins when two systems disagree. That’s a method that could exist and doesn’t. I’ve spent a few posts on who should write it. Once it’s written, every question that depends on it gets dull, and dull is the goal. A count that needs a meeting is an assay without a method.
The second is that the question moves. The lab asks one question per method, forever. A data platform gets a new question with every feature and every customer, and no steward can write that one down in advance, because it hasn’t been asked yet. That part is the job. It should never get boring.
Most shops treat both as the second kind. Every question is a fresh investigation, so the definitions never get written, so the next question is a fresh investigation too. A lab run that way would be validating the method per tablet.
Take the last data question at work that needed a meeting. Was the meeting about what the words mean, or about what the asker wanted? If it was about the words, the meeting was the lab discovering it had no method, and the fix is to write one, not to hold a better meeting next time.
The lab gave me the boring part as proof that someone had done the thinking before I got there. I’d take a data team where counting samples is as dull as making mobile phase.