The Engineer
Background, approach, stack, and work history. How I think and what I've built with.
I started writing code because I wanted to understand how things worked — not to build products, but to see behind the curtain. That curiosity eventually turned into a career. I started on the web, spent years getting deep into the .NET ecosystem, and picked up React when I realized the frontend was where most real complexity lived for the teams I was on.
Over time I’ve worked across domains — internal tools, SaaS platforms, data-heavy dashboards — and the through-line has always been the same: I care more about whether the system makes sense in six months than whether it ships five minutes faster today.
I’ve learned most of what I know by being wrong about something, then being forced to understand why.
I read the problem twice before touching a keyboard. Most bugs I’ve seen — and written — came from solving the wrong thing quickly. I try to find the simplest modelthat explains what’s actually happening, then work from there.
I care about codebases you can read without explanation. Not clever code — clear code. A function should do one thing and say what it is. I’d rather delete an abstraction than defend one I can’t explain.
Code review is one of the highest-leverage activities a team has. The best reviews I’ve been part of weren’t about catching bugs — they were about shared understanding. I ask “what happens when X?” more than I say “this is wrong.”
No experience data available.