I didn't go to a bootcamp. I didn't study CS in college. My path into development started in a call center, where I built VBA macros to scrape data off an IBM mainframe using Rocket Software's BlueZone API. It wasn't glamorous. But it solved a real problem — people needed data that was trapped in green screens, and I figured out how to get it out.
That's been the throughline of my entire career. Someone has a problem. The problem involves data, or a process, or both. I figure out how to build something that makes it better. The tools have changed — VBA became C#, Access became SQL Server, jQuery became React — but the pattern is the same.
The Access-to-Web era taught me more than any framework. I spent years as a lead developer maintaining a massive Microsoft Access footprint. When we started rewriting those databases as web applications, I learned things you don't get from tutorials: how to migrate data without breaking running processes, how to get buy-in from users who've been doing things the same way for a decade, and how to scope a rewrite so it doesn't become a death march.
One of the projects I'm proudest of from that era was the Life Event Tool. Financial services has these complicated processes — someone dies, gets divorced, becomes incapacitated — and the paperwork requirements are different every time depending on a dozen variables. I built an application that walked branch and home office users through the decision tree and told them exactly what documents they needed. It sounds simple, but getting the logic right required weeks of sitting with compliance and operations people, mapping out every edge case. That's the work that actually matters. The code is the easy part.
The solo developer years were the biggest growth period. I was the only developer for a multimillion-dollar SaaS product. That meant I owned everything — the .NET/C# codebase, the SQL Server databases, the server environments, the deployments, the billing integration, the client-facing reports. When something broke at 2 AM, it was my problem. That kind of ownership teaches you to build things that don't break. Or at least, to build monitoring so you know when they do.
Now I'm in the AI/ML chapter. I'm building risk scoring models, training classifiers on compliance data, and learning how to bridge the gap between what data science can do and what regulated industries actually need. It's the same pattern — someone has a problem, I figure out how to build something — but the tools are more powerful than anything I've had before.
The thing I'd tell someone starting out: don't worry about having a linear path. My resume looks like a random walk through technology — mainframes, Access, .NET, SharePoint, Qlik, React, SageMaker. But every step taught me something that made the next step easier. The VBA macros taught me to think about data. The Access rewrites taught me to think about users. The solo developer years taught me to think about systems. And all of it prepared me for what I'm building now.
Seventeen years in, I still get the same feeling I got when that first BlueZone macro pulled data off the mainframe and dropped it into a spreadsheet. The tools change. The feeling doesn't.