Hello.
I'm a Fullstack Software Developer that loves the outdoors almost as much as
technology! I like to untangle old systems, and try to leave the codebase easier to
work in than I found it. I like practical tools, clear tradeoffs, and software that
holds up outside the happy path.
Happiest building things that are boring in the best way: clear, useful, vanilla, and
dependable. I’m drawn to the practical side of engineering: making real systems easier
to use, maintain, and trust. Good software should feel obvious to use and reasonable
to change. That’s usually the bar I’m aiming for.
My Story
After finishing a political science degree, I started out in international trade and
slowly realized the best part of the job was not the formal side of the work. It was
building small scripts and cleaner reports that made the day easier for the people
around me. That pushed me back toward school for programming. I kept taking classes
online while driving 18-wheelers and later a tour bus for a semi-pro hockey team. When
COVID hit with one semester left at Liberty, I shifted into Flatiron School’s software
engineering bootcamp for the focused career support and hands-on work. Not long after
finishing, I landed my first software developer role. I’ve been building web
applications across modern and legacy stacks since, and I still like the same part of
the work: untangling practical problems and turning them into tools people can
actually use. Today, I’m a full-stack software engineer with 5+ years of experience
building enterprise web applications across modern and legacy stacks. Most recently at
AVIXA, I worked on member dashboards, Salesforce integrations, Sitefinity CMS
features, a Next.js/Storyblok migration, Mapbox-powered search tools, and .NET 8
authentication services.
How I Work
I like to understand a system before changing it, but I know real production work
sometimes needs quick decisions. I’m comfortable balancing speed with care: finding
the important context, making the right tradeoffs, and shipping changes that fit the
system. I’m strongest in messy real-world systems that don’t always line up with what
the docs say. When I’m picking up a new language, framework, repo, or product surface,
I like to start with a quick orientation: a teammate walkthrough, vendor demo,
conference talk, or focused video that gives me the shape of the thing before I’m deep
in details. From there, I want to see it running and read the docs with a real use
case in mind, especially when the docs include runnable examples, sandboxes, or API
explorers. Then I build something with it, using the mix that makes sense for the
problem: documentation, existing code, AI assistance, videos, or a structured course
when the topic deserves it.
