README

Engineers write READMEs for the things they build. This is one for working with me.

I am a backend and platform engineer based in Sacramento. Curiosity is the engine: I would rather explore how something works than be told. Software is as much a hobby as a job, so there is usually something half-built at home.

How I work

The best code is no code. I want to understand what actually needs doing, and have a fair sense of the final vision, before I commit to building. I do my clearest thinking on planning, design, and problem-solving, and that is where I add the most. I prefer to write code alone or pair in short bursts, and I love jumping on a call to think through a hard problem together.

I hold a lot of threads at once, and I care about how backend and platform work ladders up to customer value. I do not want to build in a vacuum. I want to know what it is for.

Working together

Short-notice meetings are fine when they carry context. Not "can we chat in an hour," but "can we chat about the ABC migration in an hour." The context is what lets me show up useful.

I flex my schedule around being a parent, often catching up in the evenings. A message outside your hours is never a demand on your time, and one from me carries no expectation of a reply until you are back. That flexibility runs both ways.

Feedback

Critical feedback privately, positive feedback in public. Direct is fine; I would rather hear it plainly than not hear it. And promptly, while it still connects to the thing it is about, so I can act on it.

A living document and a statement of intent: transparent communication, and collaboration that works for everyone. Ask me anything it does not cover.