Six months into my first real job at Cybersoft in Addis Ababa, I got assigned to the HR module of a government ERP system. I had a CS diploma, a fresh B.Sc., and zero idea how payroll actually worked.
The spec was straightforward on paper: calculate monthly salary, deductions, pension contributions, and generate payslips for a few hundred civil servants. I figured two weeks, maybe three.
It took four months.
Payroll is not math
The first thing you learn about payroll is that it's not a math problem — it's a policy problem. Every edge case is a human story. This employee is on unpaid leave for two weeks but gets housing allowance for the full month. That one transferred between departments mid-cycle and each department has a different overtime rate. Someone else retired on the 14th and their pension calculation uses a different formula than the standard deduction.
None of this was in the spec. The spec said "calculate salary." The actual rules lived in binders on a shelf in the finance office, and half of them contradicted each other.
SQL Server and stored procedures everywhere
This was 2009. The architecture was classic n-tier: Windows Forms front end, a thick business logic layer, and SQL Server doing the heavy lifting. We wrote a lot of stored procedures. Not "some" — a lot. Complex payroll calculations lived in T-SQL because that's where the data was and because the senior devs said so.
I hated debugging stored procedures. I still do. But I learned something important from that experience: the database isn't just storage. Understanding what happens at the data layer — joins, transactions, isolation levels — matters more than any framework you'll ever learn.
What stuck
Three things from that first module shaped how I think about software:
First, talk to the people who actually use the system. The finance team knew things the project manager didn't. They had workarounds, informal rules, and institutional knowledge that no document captured. I started sitting with them during payroll runs, watching where they got stuck, and that changed everything.
Second, edge cases aren't edge cases. If your payroll system can't handle a mid-month transfer, it can't handle payroll. The "80% case" is the easy part. The remaining 20% is the actual job.
Third, shipping something imperfect is better than perfecting something unshipped. We released with known limitations and fixed them over the next two cycles. The finance team got their payslips on time. That mattered more than elegant code.
I went on to build 20+ applications at Cybersoft over the next five years. But that HR module was the one that made me an engineer.