A README for collaborating with me. What to expect, how I work, and what brings out my best.
These are some baseline preferences that shape how I show up at work. They're not rigid rules — context matters. But if we're going to work together, knowing this upfront saves a lot of friction.
I prefer written communication over calls for anything that isn't truly real-time. A well-written message I can respond to thoughtfully beats a rushed 30-minute sync.
I'll tell you if I think a decision is wrong. I expect the same in return. No passive agreement — I'd rather have a productive disagreement than silent misalignment.
When reporting a problem, I include what I tried and what I observed. I appreciate the same — not just 'it's broken' but 'here's what's happening and what I've ruled out.'
I prefer async communication. I check messages in the morning and afternoon, not continuously.
I work best in uninterrupted 2–3 hour blocks. I batch meetings to specific days when possible. Interruptions during deep work sessions have a real cost — I'll always read messages, just not instantly.
Before I write code, I write the problem. Before I open a PR, I write why. Good documentation prevents 80% of follow-up questions and makes async collaboration much smoother.
I prefer many small, reviewable PRs over one large one. It's easier to review, easier to revert, and keeps everyone in the loop. I'll ask the same of others.
I write tests because I've been burned enough times without them. I don't aim for 100% coverage — I aim for confidence at the boundaries that matter.
I thrive when there's a genuine technical challenge — latency requirements, scale, correctness guarantees. Give me a problem that has no obvious answer and I'll go deep on it.
I do my best work when I own the problem end-to-end — design, implementation, observability, incident response. I don't need to be told how, just what outcome we're aiming for.
I genuinely enjoy sharing what I'm learning. Writing about a problem forces clarity. I'd work well in a team that values writing, documentation, and internal knowledge sharing.
I care about how things connect. Not just 'does this feature work' but 'how does this interact with everything else, and what breaks in 6 months if we do it this way.'
A meeting that could have been a document is a genuine productivity tax. I'll always participate fully in necessary meetings, but unnecessary ones are painful. I'll often suggest async alternatives.
I can work with ambiguity if I have the autonomy to resolve it. What doesn't work is ambiguity plus layers of approval to act on anything. Pick one: structure or freedom.
'Ship it and see' without logging, alerts, or rollback plans makes me uncomfortable. Speed matters — but so does knowing what happened when something goes wrong.
Doing something because 'that's how we've always done it' without being able to explain why. I'll always ask why, and I expect a real answer.
I care about code quality — not perfection, but craft. The difference between 'it works' and 'it works and the next engineer will understand it' is worth the extra hour.
I want to work where it's safe to say 'I don't know', 'I made a mistake', or 'I disagree'. Teams that create this safety outperform those that don't.
I've learned most of what I know from open source. I believe in giving back — sharing internal tools, writing about solutions, contributing upstream when we use OSS.
Short-term shortcuts accumulate into long-term debt. I'll always flag when I think we're trading future pain for present speed — even if we decide to do it anyway.
If a decision goes against my recommendation and I've made my case clearly, I'll commit to it fully. No passive sabotage, no 'I told you so' later. But I'll document my concerns first.
I'll measure before optimizing, test before assuming, and validate before scaling. But I also recognize that data doesn't always exist and sometimes you have to bet on judgment.
I default to reversible decisions at low cost, and slow down on irreversible ones. The database schema you picked in week 1 matters more than the library choice.
Make it correct, then make it fast. Premature optimization has a real cost. I'll profile before I optimize and measure after.
I prefer code that's explicit about what it's doing over 'magic'. A little more verbosity that makes behavior clear beats clever tricks that need deep context to understand.
Strong types reduce the documentation burden, prevent a class of bugs, and make refactoring safer. I take types seriously — not as overhead but as investment.
The best engineers I've worked with ask 'what does the user actually need?' not just 'what did the spec say?' Technical excellence in service of real outcomes.
Have a point of view, defend it, but update when presented with better evidence. The alternative — endless consensus without conviction — produces mediocre outcomes.
I work best with teams that treat remote as the default — not as a fallback. That means good async norms, written culture, and meetings as exceptions not defaults.
The best way to know if we'd work well together is to talk. Book a 30-minute intro call — no pressure, no agenda beyond getting to know each other.