On the long game.
A principal engineer and architect who never stopped writing code.
I'm a principal-level software engineer and architect — an individual contributor by deliberate choice, more than thirty years in. I've designed and delivered enterprise software for federal, healthcare, financial-services, utilities, telecommunications, transportation, education-assessment, and commercial environments — the kind that runs quietly in the background of consequential work and has to keep running long after launch. I came to it through engineering before computer science, which is probably why I still think about software the way I think about machines: as a real thing with constraints, failure modes, and a tendency to surprise you if you stop paying attention.
What I've actually learned, over and over, is that the technology is rarely the hard part. The hard part is fitting the work to the people, the constraints, and the timeline — and not pretending the surprises won't come. So I've made it my job to be the steady hand on a build: clear about the architecture, honest about the tradeoffs, and the person a team can look to when the problem is hard and the stakes are real. That trust is the thing I'm proudest of, and it was earned one delivery at a time.
In recent years my work has moved into applied AI. I build production-grade language-model systems — retrieval pipelines, agentic workflows, the evaluation and observability that keep them honest. The principles didn't change; the material did. Most of the difficulty still isn't the model. It's the engineering around it: making the thing legible, measurable, and trustworthy enough to put in front of people who are counting on it. And the line I hold is simple: AI where reasoning or language genuinely helps; deterministic, testable code wherever money moves, access is granted, or a number has to be right.
The way I produce work has changed too, deliberately. For most of my career the craft itself was the point — knowing the language cold, typing every line, taking pride in the how. The era we're in rewards a different posture: real clarity about what is worth building, and the discipline to get there with AI coding agents doing more of the typing. I decide what to build and how it should hold together; the agents help me move. The standard underneath is the same one I've always held — build it so it works, prove it with tests, and leave it clean for the next person.
None of this is the whole of me. I'm a family man and a man of faith, and that's the quiet center the rest turns around — it keeps me patient, grateful, and clear about what actually matters. I still write code most days. I expect I always will. When I can, I'm outdoors, where the patience and the gratitude get topped back up.
Most of the work is unglamorous. That's what makes it worth doing well.
Areas of practice
- Enterprise architecture
- Designing systems with clear boundaries that stay sane as they grow. Decades of building platforms that have to keep running — and modernizing the ones that already do, without taking the business down for the weekend.
- Systems in Java, Go & Python
- Three languages I've shipped production systems in for years — services, concurrency, data, and the front ends to match. I pick the right tool for the constraint and live with the choice rather than chase the trend.
- Cloud-native delivery
- Containers, pipelines, and infrastructure that ship and stay up. Distributed systems, concurrency, and the unglamorous operational details that decide whether a launch goes well.
- Applied AI
- Retrieval pipelines, language-model integration, and agentic systems — built with judgment rather than hype, and with attention to evaluation, observability, and the cost nobody likes to talk about.
- Agentic engineering
- Working daily with AI coding agents: deciding what to build, setting the contracts and the tests, and using the tools to move fast on the rest. More software, built more carefully, with an architect's hand on every decision that matters.
- Delivery discipline
- Tests, reviews, and production thinking from the first commit. A short feedback loop and calm under pressure usually outperform heroics — I've been around long enough to be sure of it.
Practice
- 01
Architecture, in service of the work
Aligning systems design with the actual goals of the people doing the work. I tend to ask what is essential, what is incidental, and what can be quietly removed without anyone missing it.
- 02
Modernizing without breaking
Most of my career has been spent moving older systems into newer ones — mainframes to services, monoliths to microservices, batch to streaming, on-prem to cloud-native — without taking the business down for the weekend.
- 03
Generative AI, applied carefully
Building retrieval pipelines, agentic systems, and LLM-driven workflows for places where the answer matters. Most of the difficulty isn't the model — it's the surrounding scaffolding: evaluation, observability, prompt discipline, cost.
- 04
Working with engineers
I prefer small teams that read each other's code, argue well, and ship. I mentor when I can, and I've found that the best engineers tend to grow themselves once they're given problems they care about.
- 05
Calm under pressure
Some projects show up urgent — pandemic response, large migrations, regulatory deadlines. I've been around long enough to know that calm, clear thinking and a short feedback loop usually outperform heroics.
Education
Graduate study in computer science, on an engineering foundation.
Recent certifications
-
Talk to Your Documents with LangChain and Python
08/2025 -
MCP Servers Made Easy with Python and OpenAI Agents
07/2025 -
AWS Certified Cloud Practitioner
08/2024
Continuing education tends to happen in public — see the blog.