Everything I know about software started in a pharmacy lab
Precision, procedure, verification, and respect for failure modes: the lab is a systems engineering course in a white coat.
By Nzubechukwu Cyprian · Pharmacy student at UNN, full-stack developer
People hear "pharmacy student who codes" and imagine two separate lives. They're more similar than you'd think. The lab taught me things about software that I've seen whole engineering teams learn the hard way.
The transfers
Procedure is not bureaucracy — it's memory. A dispensing protocol exists because someone, somewhere, made a specific error. Standard operating procedures are institutional scar tissue. Deployment checklists and code review are the same species.
Verification is separate from doing. In the lab, you check the calculation twice, and the second check is a different activity, not a repeat of the first. In software: write the code, then read it as a reviewer — different modes, different eyes.
Failure modes are the design. Pharmacists think in terms of what happens if this goes wrong: wrong dose, wrong patient, wrong route. Building software with that lens — what if this fails, times out, gets double-clicked, loses network — produces systems that survive contact with reality.
Small errors compound. A 1% error in one step isn't 1% at the end of ten steps. Testing isn't perfectionism; it's the acknowledgment that errors multiply.
The synthesis
The lab made me comfortable with the idea that being careful is a skill, not a temperament. Software rewards exactly that.
One email when a post lands
No schedule, no spam. Just the posts worth reading — new writing on software, AI, products, and the Pharmacy × Tech life.
Prefer a feed reader? Grab the RSS feed.
Keep reading
Software engineeringNaming things is the whole job, sometimes
Most codebases don't have a naming problem — they have a thinking problem that shows up in their identifiers.
Software engineeringYour README is your first interview
Before anyone judges your code, they judge your README. What a good one actually contains, from someone who reads a lot of them.
Software engineeringThe bug that taught me to read error messages properly
A three-line error sat in my logs for a week. It told me exactly what was wrong. I just never read past the first line.