What is this Website?
This site is a cross between a resume, a blog, and a notepad. I use it to document projects, write up experiments, and share what I’m learning.
What I Do
I build and maintain software systems, with a focus on solving ambiguous problems end-to-end. My work spans backend services, data platforms, ML pipelines, and custom UIs - whatever the problem calls for. I care about solving business problems with technology, shipping reliable software, and making complex systems easier to reason about, and using every tool available — especially AI — to multiply what a small team or solo dev can deliver.
Once you know the fundamentals, most languages and frameworks are just syntax. This section is about the stuff that actually transfers.
Honestly, I’m still figuring out what this section should be. For the actual track record — companies, roles, and what I have worked on — see employment history.
The bullets below are things I’ve learned working on software, but they don’t really have to be about software… They’re about how to figure out what’s actually going on, how to turn a vague ask into something you can act on, how to plan for things going wrong, and how to change something important without breaking it. The same lessons would carry over to a lot of other kinds of work.
Problem Decomposition & Debugging
- Take something ambiguous or broken and work it down to a clear root cause — not just a fix, but an understanding of why
- Build a mental model of how data and state actually move through a system, so when something goes wrong, I know where to look
- Write down what I find or add better logs. Half of debugging is making sure nobody has to debug the same thing twice
Translating Between Business & Systems
- Most requirements start vague. I turn “we need this to work differently” into something concrete enough to build, test, and ship
- Start from first principles — learn the domain, talk to the people closest to the problem — because the right technical solution usually comes from understanding what they actually need, not just what they asked for
- Optimize for business impact, not technical novelty
Building for Reliability
- Assume the data will be wrong, the upstream service will lie, and the edge case will happen in production on a Friday
- Bake in visibility from the start — structured logs, metrics, health checks — so problems surface before users report them
- Testing and validation aren’t cleanup. They’re part of the work
Iterating Without Breaking Things
- Improve systems while they’re running. Refactor incrementally, extract patterns when they earn it, don’t rewrite what you can evolve
- When changing critical behavior, run the old and new paths side by side until you trust the new one
- Every architecture decision is a tradeoff between shipping now and living with it later. I try to be honest about which one I’m choosing
Open to interesting problems. LinkedIn.