Architecture
Making the right tradeoffs
Finding a design that solves the real problem without creating three new ones.
Software engineer · Systems architecture · Reliability
Hi, I'm Scott.
I've spent a good part of my career building software, figuring out how systems fit together, and occasionally managing the people who do both.
These days, I'm especially interested in the problems that don't have an obvious answer, and in making sure the solution actually works once it's out in the world.
A little background
I've worn a few hats.
I've been a developer, an architect, and an engineering manager. I've worked on payment systems, web applications, SaaS products, and the machinery behind them.
I eventually found that I enjoy being close to the actual problem: understanding it, making decisions, and being responsible for the outcome. I still like writing code. I just don't think writing code is always the hardest part.
And yes, I've been in enough meetings to appreciate a good afternoon of uninterrupted work.
The everyday work
Big systems. Small fixes. Both matter.
I enjoy architecture and the complicated problems that come with connecting systems. But I'm just as comfortable opening an established codebase, tracking down a JavaScript bug, or fixing something small that has been irritating people for months.
There's a lot of good software that's been around for years. I don't see age as a reason to replace it. Sometimes the right answer is a new design. Sometimes it's a careful three-line change.
And sometimes it's a typo. I'm happy to fix that, too.
Something I believe
The tools change. The responsibility for making things work doesn't.
After enough years in software, you stop expecting to have seen every problem before. What matters is being able to sort through the unknowns, make sensible choices, and follow through.
More about how I approach engineering →What keeps my attention
It's usually the space between systems.
Integration
Getting things to cooperate
APIs, data, services, old systems, new systems. They don't always agree with each other.
Reliability
Knowing it actually worked
“The server is up” is useful information. “The customer can finish the transaction” is better.
A recent project
That last question became a product.
I kept coming back to a simple gap in traditional monitoring: a healthy server doesn't guarantee a healthy business process.
So I built a Business Reliability System (BRS) through W3Patterns. It runs checks against actual business capabilities and makes the results visible. It's an independent working project, with a live demonstration, not a claim that I've deployed it across hundreds of companies.
It also gave me a chance to put AI-assisted engineering to work on something substantial, while keeping the design decisions and verification where they belong: with the engineer.
The formal stuff
Looking for my work history?
I've kept the job titles, dates, and technical details in a proper résumé. This site is more about what I work on and how I think.