Field notes — the blog

Notes from inside the system.

Specific write-ups on decisions that moved the needle: architecture trade-offs, delivery pipelines, and leading engineers who are better than you at their part of it.

              {{ totalPosts }} notes
              {{ totalMinutes }} min total
              Monthly
            

/

                Latest
                {{ featured.date }}
                {{ featured.cat }}
                {{ featured.read }}
              

{{ featured.title }}

{{ featured.excerpt }}

Read the note →

// before → after
{{ row.text }}

{{ listHeading }}

{{ resultCount }}

                {{ post.cat }}
                {{ post.date }}
              

{{ post.title }}

{{ post.excerpt }}

{{ post.read }}

Nothing matches that.

Try a different term, or clear the filters.

The architect's dispatch

One note a month. Nothing else.

A single deep write-up on a system I worked on: the trade-off, the numbers, what I'd do differently.

            {{ article.cat }}
            {{ article.date }}
            {{ article.read }}
          

{{ article.title }}

{{ article.excerpt }}

{{ part.text }}{{ part.text }}{{ part.text }}

{{ b.alt }} — {{ b.caption }}

{{ b.label }}

{{ h.text }}

{{ cell.text }}

{{ b.label }}

{{ link.label }} {{ link.note }} {{ link.host }}

{{ b.caption }}

{{ b.text }}

{{ b.text }}

{{ b.label }}

{{ line.text }}

{{ item.no }}

{{ part.text }}

{{ part.text }}

{{ part.text }}

Takeaways

▖ {{ t }}

Tags

{{ tag }}

← Newer

{{ prevPost.title }}

Older →

{{ nextPost.title }}

Related notes

{{ post.cat }}

{{ post.title }}

{{ post.read }}

Reading code as a manager without taking the keyboard

Leadership · Mar 2026 · 5 min read

Staying technical as an engineering manager is not about writing the tricky patch. It is about reading enough to ask the question that saves a sprint.

The failure mode I see most in new engineering managers is not losing technical depth. It is spending that depth in the wrong place — reviewing style on CRUD endpoints while an architectural decision goes through unexamined in a different pull request.

Read the decisions, delegate the diffs

I read every pull request that changes a boundary, a schema, or a dependency, and almost none of the ones that add a field to a form. Formatting belongs to the linter. Naming belongs to the two engineers who will maintain it. Failure modes belong to me.

What happens when this call times out?
What is the rollback, and has anyone run it?
Who gets paged when this breaks, and will the page tell them anything useful?

Those three questions have caught more production incidents for me than any amount of line-by-line reading. They are also teachable: after a few months, engineers start answering them in the description before I ask.

Every patch you write for someone is a lesson they did not get, and a piece of the system only you understand.

The trap

The temptation is to fix it yourself. You can see the problem, you know the fix, it is twenty minutes. It is faster once and slower forever: the engineer learns nothing, and you have quietly made yourself the bottleneck on the one part of the system nobody else has had to reason about.

The exception I allow myself is pairing. Not taking the keyboard, but sitting alongside while they type — same information transfer, and the code ends up in the head of the person who will be on call for it.

Takeaways

Review boundaries, schemas, and dependencies; let the linter own style.
Ask about timeouts, rollback, and paging on every non-trivial change.
Pair instead of patching — the fix should land in the head of whoever will be on call.

All notes · Shehzad Aslam