How I work
with people.

Give me a problem and get out of the way. I do my best work when I own the outcome — not just the task.

I don't need to pair on everything. But I'm fully engaged when we're working through hard problems together.

A daily standup keeps me aligned. Beyond that, I'd rather ship. Heavy meeting cultures eat into the time that actually matters.

I can deliver under pressure and have. But I'd rather plan well than manufacture urgency as a substitute for good process.

Growth first, fair pay second, good people third. I'm not chasing perks — I'm chasing craft and forward momentum.

I don't need to be saving the world, but I need to believe in what I'm building. Work that feels pointless burns me out fast.

I've worked in both tight process and total chaos. I prefer teams that move fast with intention — not just fast.

I'm self-directed. A thoughtful quarterly review is more valuable to me than weekly check-ins that say nothing.

Async is where I'm most effective. My messages are hyperlinked, context-rich, and written to be read later.

I write long messages so I don't have to have long meetings. If I send you a wall of text, it's because I've already thought it through.

I'd rather surface tension early than let it fester. I don't avoid conflict — I just keep it productive and depersonalised.

Good code should speak for itself. But decisions and context belong in writing. I document the why, not just the what.

I like the option to go in. Full remote works fine but occasional face-to-face matters for building real relationships.

I work well within normal hours. Grinding nights and weekends isn't dedication — it's a planning failure.

Small teams move faster, have less politics, and every contribution is visible. I've worked in large orgs but I do my best in tight, trusted groups.

On-call as a substitute for reliability engineering is not a team I want to join.

Occasional team offsites or key meetings are a plus. Constant travel is not for me.

Not gatekeeping — knowledge sharing. A good PR review is one of the highest-leverage activities a team can invest in.

Writing tests first is a design tool. It forces you to define the interface before the implementation. The test suite is what lets a team ship fast without breaking things.

I don't chase perfection at the cost of shipping. But I don't let debt compound silently either. Make it visible. Schedule it like real work.

My first instinct is the primary source — the RFC, the spec, the official docs. Tutorials are fine for a first look but I need the ground truth before trusting something in production.

If a human is doing it more than twice, a machine should be doing it. CI/CD is table stakes. I've built pipelines that let teams ship with confidence at scale.