How I got here.

I'm a full-stack developer in Calgary. I spent five years at TransAlta, most of it as one of two developers on a Next.js data visualization platform that the wind, hydro, solar, and gas teams use to monitor how their plants are running. I wrote the majority of the code and had a lot of latitude in how it was architected, working from requirements set by a senior engineer and our manager.

Before software, I was a school teacher, teaching everything from early education to high school English. A Bachelor of Education is an unusual way into this work, but it's where I learned to explain things plainly, notice when someone is lost, and design for the person who wasn't in the room when a decision was made. That shows up in how I design user interfaces, write documentation, and handle error states.

Outside work I build for the communities that I'm part of: a storefront for a local skateboard brand, a map for skaters to document and share skate spots, and a training app for TypeScript developers (like me). The storefront and the map are live, with real users and no team behind them, so most of the engineering went into making them dependable without relying on my constant oversight. The training app is a work in progress, with every lesson written and the runtime built.

Correct by design

Stock reserved before a payment session exists, orders that appear only once the webhook confirms, review state a contributor cannot overwrite. If it only works when someone is there to manage it, it doesn't work properly.

Sized to the problem

A one-city map gets a client-side distance filter, not a geospatial service. The right amount of infrastructure is the least that keeps the product dependable.

Clear for the next person

Comments explain why, docs explain how to run it, and the interface explains what to do next. The next reader is usually me in six months.

1. Clarify the user flow and success criteria before building.
2. Build the smallest useful version, then tighten edge cases and interaction quality.
3. Test at real boundaries: a real database for concurrency, a real browser for checkout, a verified config before release.
4. Ship small, reviewable changes, with CI running the whole suite on every pull request.

I've skated Calgary's streets and parks for most of my life, and I still get out most weeks. The rest of my time is spent with my wife and two young children, who continue to inspire me in everything I do.