How I work

1. 01

   Precise words

   If two people mean different things by “sync” or “done”, that is the bug. I will pause a meeting to pin a term down.

2. 02

   Bad news early

   A blocker raised on day 1 costs an hour. On day 5 it costs the week. Tell me the moment you know.

3. 03

   Ownership past the merge

   Shipped means running, observed, and operable by someone who is not me.

4. 04

   Disagree, then commit

   Argue once, with evidence. Decide. Then we move together, and the experiment tells us who was right.

1. 01

   Start at the riskiest unknown

   Before the architecture doc, one real record goes end to end through every system. Unknowns surface in a day, not a sprint.

2. 02

   Write one page first

   The problem, what done looks like, what we are not doing, and how we roll back. Four headings, one page.

3. 03

   Review at 20% and 60%

   A draft PR at 20% shows structure, logging and tests. At 60% it shows the edge cases. Nobody meets a 2,000-line PR cold.

4. 04

   Idempotent and observable before fast

   Every job safe to retry, every record traceable. Speed comes after, and it comes easier.

   Idempotency keys are not enough →
5. 05

   Cut over with a way back

   Dual writes, a reconciliation report, a rollback rehearsed end to end. That is how a CRM cutover ran with zero downtime.

   Outages are loud. Data corruption is quiet. →
6. 06

   Hand off, then step back

   A runbook, a dashboard, a 30-minute walkthrough. The work is done when nobody needs to page me for it.

Outages are loud. Data corruption is quiet. I plan for the quiet one.

Based

Gurugram, India. IST, UTC+5:30.

Default

Async and written. A clear message beats a 30-minute call.

Chat

A reply the same working day.

Email

A reply within 24 hours.

Calls

Booked with an agenda. No agenda, I will ask for one.

• +What you are trying to do, and why.
• +The exact steps you took.
• +What you expected, and what happened instead.
• +IDs, timestamps, log lines. Screenshots of text are hard to search.
• +What you already tried.

A message like that gets a fix in one reply. “It’s broken” gets a question back.

1. 01

   Labelled comments

   Every review comment says what it is: blocking, suggestion, question or nit. You always know what has to change before merge.

2. 02

   Code, not critique

   When I ask for a change, I write the change. A suggestion block costs me 2 minutes and saves you a round trip.

3. 03

   One working day

   Reviews land within a working day. If a PR needs longer, I say so and give a time.

4. 04

   PRs that review themselves

   My descriptions carry four things: what changed, why, how to test it, and the part I am least sure of.

5. 05

   Feedback for me

   Direct, written, and the same day. I would rather fix it this week than hear about it in a retro.

1. 01

   Agents draft, people decide

   I use agents for first drafts of code, tests and migrations. The design calls and the merge button stay human.

2. 02

   Evals before prompts

   No prompt change ships without an eval set it has to pass. Public benchmarks are saturated. Your own 50 cases are not.

   Your eval dashboard is measuring nothing →
3. 03

   The model is a component that fails

   Timeouts, retries, structured outputs and a fallback path, the same as any other dependency.

   Six multi-agent patterns nobody tells you about →

• דWorks on my machine” as a status update.
• ×Postmortems that stop at “human error”.
• ×Retries without idempotency.
• ×A meeting that could have been a 5-line message.

1. 01

   I go deep and go quiet

   An interesting problem can swallow an afternoon. Ping me, I would rather surface. The patch: a one-line status before I log off, every day.

2. 02

   I push hard on naming

   In review I will argue over a function name. If it is slowing the PR, say “naming later” and I will file it instead.

If something on this page is wrong about me, tell me. I will ship the fix.