About
Most engineers start with "Hello World." Mine starts with a $2 million pricing problem.
I am a software engineer. Most of my work lives in distributed and event-driven systems, the infrastructure and developer tooling underneath them, technical leadership on teams building that kind of thing, and lately the AI-native side of engineering — how software actually gets written now. I arrived by way of finance, sales, and field operations, so I tend to ask what a system is for before I ask how to build it.
Origin
Four Excel files, Raptor, and a 30-day delay.
In 2019, I was working in finance and pricing at Ford. Interest rate spreads moved through four Excel files (one for each market area), brand approvals, and then a legacy system called Raptor. Brand managers negotiated spreads, someone keyed the changes in manually, and everybody waited.
That was annoying on a quiet week. During the end of ZIRP, with Fed meetings moving rates, it got expensive. A 30-day lag between decision and system update could cost roughly $2 million a year.
I proposed an automated fix. The answer was: "We don't have the technical resources or skills to do that." Fair enough. So I built what I could with the skills I had, then spent nights and weekends filling in the rest: Java, Python, React, Terraform, cloud systems, design patterns. The first version cut the delay down to about a week.
That was the point where software stopped feeling like another department and started feeling like another tool I needed to be useful.
The through line
I have been the field rep and the engineer with the ticket.
I spent the first half of my career in sales and business development, moving through 7 states and 13 territories for Ford. I have been the person asking engineering for help, and now I have been the person receiving the Jira ticket. That ruins you in a useful way.
People rarely hand you the real problem neatly packaged. They hand you the workaround. A dashboard request might be a broken handoff. An AI request might be a team without a shared way of writing things down. A "simple automation" might be covering for a system nobody trusts.
So I ask annoying questions early. Who touches this? What breaks silently? Where does the money leak? What happens after version one ships? That's the operator part of me. The engineer part still has to make the APIs, queues, schemas, tests, and logs behave.
Working standards
Business math first
Before the architecture diagram, I want the boring numbers. Where is the money leaking? Where is the time going? What breaks if the system is slow, wrong, or quietly stuck?
Production tells the truth
A green job with an empty database isn't success. Ask me how I learned that one. The work has to tell you what happened, not just that something ran.
Context has to live somewhere
If the important part only exists in Slack, a console click, or someone's memory, it's already drifting. Write down the traps before they become folklore.
A little more human
The page behind the writing.
I have lived in Dallas, Atlanta, Denver, Boston, Detroit, Little Rock, Nashville, and Tampa. Moving that much makes you adaptable and quick to read people. After that, almost anyone is easy to work with.
Outside work: gym 3-5 times a week for years, nutrition tracking, the outdoors, sports, country music, and 2000s rock. Yes, I still listen to Creed and Nickelback.