Dispatchers made me a better engineer.

I work on a transportation management system — the software a national trucking operation runs dispatch, tracking, and brokerage on. My users are people with a phone in one hand and a grid of loads on two monitors, and they notice a slow screen faster than any metric will tell me.

That shaped how I build. I care about giving people interfaces that look good, hold up under real load, and — more than either of those — work the way they already expect them to. Data density done well, realtime state that survives a reconnect, integrations that fail loudly instead of quietly dropping a customer's update.

A lot of the work I am proudest of is invisible: realtime state that stays consistent across every server and instance, a migration that moves in scheduled batches instead of one long run, a job that quietly flags stored templates whose schema has drifted too far to trust. My favorite is a service worker that holds a new build until the user navigates and then swaps it in silently — a slightly longer page load instead of an afternoon of data entry lost to a deploy — with a force-update switch in the pipeline for the hotfixes that cannot wait.

Day to day that means Angular on current standards over a .NET Core platform — Material and Kendo on the front, RabbitMQ, Coravel, SQL Server, and Redis behind it, all multi-tenant, all shipped through pipelines I help maintain.

On a team I end up as the last set of eyes: final review on the pull requests, the build and the release, and the first one watching errors afterward with a hotfix ready. I am also the one hunting edge cases — what happens on retry, what happens when someone skips the front end entirely and posts straight to the API — and writing the migration plan nobody asked for.

Past that, I guide the architecture, plan what we build next and how it gets built, and keep asking whether a screen could not only look better but scale better and feel more obvious to the person using it.