How I work

What you're actually getting
01

I start with the problem, not the stack

Before choosing a technology, I want to understand what's actually broken. The right tool depends on the constraint - team size, data volume, delivery timeline. I ask uncomfortable questions early so they don't become expensive surprises later.

02

I design for the next engineer, not just today

Code I write gets read in production incidents at 2am. I write for clarity over cleverness: explicit over implicit, boring patterns over clever abstractions, comments that explain *why* not *what*. I have debugged enough "brilliant" code to know the cost.

03

I own things end-to-end

I don't stop at "it works on my machine." I care about how it deploys, what it costs to run, how it fails, and how we would know if something went wrong. Full ownership means the database, the deployment, and the on-call.

04

I communicate decisions, not just results

Every significant technical choice has a tradeoff. I document those explicitly - what we chose, what we gave up, and what would need to change if requirements shift. This is not over-engineering; it's Insurance against future you having to reverse-engineer past you.