I've been building for the web since 2008. Started with Rails and jQuery, learned what actually works through shipping real products, and these days I'm focused on TypeScript. I like working with product and design teams to figure out what to build and ship it quickly.
Currently working on healthcare software at CHG, improving type safety and developer experience in a legacy codebase. Before that, startups in mortgage tech and auto repair. I'm always looking for ways to reduce cognitive load for teams and let automation handle what it should.
The landscape shifts quickly, so if it's useful or an existing codebase uses it, I've probably explored it.
Tools like Prettier and ESLint catch issues before code review happens. They give you immediate feedback in your IDE instead of waiting for someone to point out a problem. That's time freed up to focus on what actually matters.
TypeScript and GraphQL codegen catch bugs at build time instead of runtime. You find out immediately when something breaks instead of discovering it in production. That confidence lets you refactor and move faster.
I pick tools based on actual needs, not trends. React solved jQuery's complexity problem. Utility CSS handled styling cognitive load. Boring is fine—stay aware of what's emerging but don't chase the next thing for its own sake. Use what solves your problems.
First real programming job was in state government while still in college. ColdFusion mostly. No version control. Deployments required writing a Word document listing every file you'd changed, getting sign-offs in actual ink from multiple levels of management, handing it off to someone else who'd FTP the files to the correct server, and once they verified everything they'd stamp the document and file it away in a binder. It was bureaucratic and slow, but I was grateful for the opportunity. I knew it wasn't where I wanted to stay long-term, but I was eager to learn.
Built a ColdFusion application around that time. It's still out there in production, pretty much unchanged since 2010. Not glamorous, but it's proof that you can build something that just works and keeps working.
Meanwhile, I was working through my senior capstone project. We were supposed to build a volunteer management system in ASP.NET MVC. The class had these specific time tracking requirements we needed to report on for the project specification. I decided to build a Rails application to handle all that instead. Took me a fraction of the time and ended up way more useful than the actual capstone project. I was reading Rework around the same time—DHH's vision of how software could be built—and something just clicked. You could ship something real quick, actually use it, iterate on it. No endless specification documents, no waterfall cycles. Rails showed me there was a fundamentally different way to think about building software.
Built a lot of Rails apps during this stretch. Low usage products that kept me stuck in backend work. The frontend code was a complete mess—jQuery mixed with Backbone, Underscore templates scattered everywhere. It worked, but I wasn't seeing the kind of impact I wanted. I liked the product side of things, but nothing was really taking off.
Then Foundation launched as a mobile-first responsive framework and I got pulled into leading the JavaScript work. Built the plugin system, the documentation site, the build customizer tool. Spoke at meetups, ran online trainings. It was the first time I really owned something that thousands of people were actually using. That impact was addictive. Suddenly I got passionate about frontend work. I realized I wanted to build things that had reach, that mattered to a lot of people.
But open source has a way of wearing you down. After a while you're drowning in feature requests, trying to make everyone happy, and the complexity just keeps climbing. I started to resent it. I wanted to set a direction again, to own the decisions. That's what pulled me into Screenbeacon. I saw a gap—deployment tools checked your endpoints but had no idea if your UI was actually broken. It seemed novel, and I thought as an engineer I could see the product clearly. Spoiler alert: I couldn't. I didn't understand product-market fit at all. Eventually I did some consulting to pay the bills while I kept iterating on the idea. It didn't work out.
But here's the thing—even though Screenbeacon failed, I came away loving the process. The building, the quick iteration, the ability to try something and move fast. That stuck with me.
After Screenbeacon, I was burned out on startups. Needed stability and variety without the pressure to build the next big thing. Consulting was perfect for that. Worked on advertising for Walmart Labs and some internal products for other clients. Managed overseas development teams building Flash animations and advertising work. It wasn't cutting-edge technical work, but that was intentional. I was stepping back from that intensity.
This was my first real exposure to managing teams. I learned how to break down work, communicate with clients, figure out what actually mattered to them. The consulting setup gave me time to travel, which was great. I could physically and mentally disconnect more. I wasn't chasing the bleeding edge anymore, but I was keeping tabs on what was happening without the pressure to adopt everything immediately.
Got back into the startup world. At RepairPal, I got my first real exposure to React by building their first React application. It was mostly greenfield. The frontend landscape had drastically improved. The tooling was genuinely great and made it possible to build more ambitious applications. But there was a tradeoff. The configuration and initial setup had become significantly more complex. Suddenly it made sense why there was this split between backend and frontend engineers. The setup alone was enough to push people into specialization.
I also started working more closely with design. I was all in on the frontend side of things. I felt like there was way more potential for impact there. Most people seemed to hate frontend work, which I still don't understand. Make a button bigger or change a color and people get excited. Spend months optimizing a SQL query and nobody cares, which is kind of sad. A few people do, but it's not the same. The frontend is where you see immediate feedback. That visibility, that impact is why I leaned hard into it. I still did backend work, just less of it, because honestly nobody wanted to do it.
One more thing—Webpack and Babel. Incredible tools, but confusing and difficult to configure. The learning curve was steep.
React has staying power. I've used it across every startup I've worked with and had time to get really comfortable with it. The biggest shift was moving away from Rails and building standalone applications. At Snapdocs, a lot of my work was code-splitting to let frontend and backend teams move independently. That's when I started getting really passionate about how the frontend communicates with APIs.
I've yet to work with a RESTful API I really liked for anything of reasonable complexity. For personal projects or simple stuff, they're fine. Don't waste your time with GraphQL initially. But at Willow they were already using it, so I had to learn it. I'd been avoiding it for a while because it seemed complex and I didn't think the complexity was worth it. Then I discovered the tooling around GraphQL. Type generation that provides real type safety across the entire communication layer. That changed my mind. That's the selling point for me. You modify your backend and your frontend applications know exactly what's available. It's worth the complexity.
Funny that full-circle, frameworks like Remix are going to let applications talk directly to databases and skip the API layer altogether. We'll see how that plays out. At my current job I had to switch to Angular. It's been a paradigm shift, but frontend development continues to feel pretty stable. Excited to see what comes next.
Healthcare provider credentialing software. Working with Angular and TypeScript on a legacy codebase to increase type safety and improve developer experience.
Key learning: Tools like ESLint and Prettier act as a helpful code reviewer always available through IDE hints. They catch issues early and raise the quality bar incrementally across the team without manual effort.
Built a React-based application for mortgage servicing used by both lenders and borrowers. First real GraphQL experience here.
Key learning: Monorepos made coordinating frontend and backend changes easier. Grouping related changes that needed to ship together reduced friction and deployment complexity.
Managed a React dashboard for home closing workflows across lenders, settlement agents, and borrowers as the company experienced explosive pandemic growth from a couple engineers to over a hundred. Separated backend and frontend teams, built test automation with Cypress, and led an accessibility audit focusing on color contrast standardization. Later worked on an internal tool for digital promissory notes in TypeScript, applying learnings from earlier projects to design things better from the ground up.
Key learning: Automate what can be automated. Prettier eliminated debate about formatting in code reviews, freeing us to focus on product. Later, TypeScript became another form of automation—developers get immediate feedback when writing invalid code, catching bugs before they ship. Both remove friction from the development process.
Managed the Rails monolith and built SEO-friendly pages helping car owners find trustworthy repair shops and understand repair costs. Built the company's first React application for scheduling appointments and generating transparent price estimates, making it easier to connect owners with shops.
Key learning: Frontend was becoming increasingly complex. React provided structure for handling difficult interactions that jQuery couldn't manage cleanly. Utility CSS minimized cognitive load by eliminating excessively nested custom styles. Both made the codebase more maintainable as complexity grew.
I'm originally from Northern California. Moved to Colorado, then eventually to Maine where I am now. I like the New England vibe way more than California's endless summer.
Outside of work I have 2 dogs, 2 cats, and a little scooter for beach trips. Slowly working on fixing up my house. It's taking forever. I get sucked into programming problems too easily. "Just 10 more minutes" turns into hours, which probably explains the house situation. Trying to get better about disconnecting and spending time in the real world.
I don't do social media, except GitHub. Check out my GitHub or LinkedIn if you want to know more.