Aviolinx

Aviolinx operated in a highly specialized domain, where the software had to represent complex aviation regulations and operational rules correctly, not just plausibly.

My work wasn't simply implementing conventional business features. I spent much of my time inside the rule engine underpinning the system, modifying it and adding capabilities as the product evolved. The real engineering challenge was understanding domain rules well enough to express them correctly in code.

Coming straight from university, I had to become productive fast in a domain with a lot of specialized knowledge and very little room for a rule to be almost right.

Early on I was given responsibility for a substantial payroll feature largely on my own, using the existing calculation infrastructure to work out personnel payroll and expose it through the application's workflows. As a junior developer, I was trusted with a meaningful piece of functionality and got it done with little supervision.

Over the following three years I worked extensively on the underlying rule engine, extending and modifying it as new requirements came in. That was where I got real experience with software where correctness depends on accurately representing complicated real-world rules, not just following straightforward application logic.

I went from a newly graduated junior developer to someone working independently on the core rule engine — the first place I got comfortable becoming productive in an unfamiliar, complex domain.

I was also considered for a team-lead move after about a year, but the company promoted someone else without telling me that had been the decision; I found out after the fact. It was an early, blunt lesson that being technically capable and being formally given authority are two different things.