(Photo by Markus Winkler on Unsplash)

This is a two-part series.

This first part is about how I became able to review across multiple stacks, even ones I don’t familiar with.

The second part will be about why reviewing becomes a superpower in the age of AI.

Seems like I reviewed too much last year

Recently I became curious about how many PRs I actually review in a typical period.

So I asked an AI agent to build a little tool to fetch PR data from GitHub/GitLab APIs... and it turned out I reviewed 110+ PRs in just 4 months!

Too much? Maybe, or maybe not?

Here’s the interesting part. I’m a frontend-focused software engineer, yet the PRs I reviewed were across frontend, backend, mobile, GraphQL and legacy.

I actually had never thought about this before. Most people review PRs only in the parts of the codebase they’re comfortable with. Backend engineers review backend code, frontend engineers review frontend code, and so on.

But somehow I didn’t do that.

I kept reviewing code in stacks I wasn’t an expert in. So I started asking myself: why am I able to review stacks I don’t fully know?

After thinking about it for a while, I realised the answer is: Because my career started not from zero... but from minus.

My "started from minus" origin story

To explain why I can now review almost anything, I need to explain how I started.

I’m self-taught. Before joining my current company, I only built marketing websites in a small team with only me and another engineer. I didn’t know Agile. I don’t know how to write good unit tests.

During my interview, I could only write very simple tests and I didn’t know test pyramids. (which is ironic because now everyone knows me as the engineer who always writes tests)

When I joined, I was:

• the only junior software engineer in the team
• new to the UK
• struggling with English
• unfamiliar with CI/CD pipelines
• confused about Agile (What is retro/refinement? What do we do there?)
• only comfortable with React/Next.js

So even though I had some working experience, I still say I started from minus. I felt behind everyone and desperately wanted to catch up! (like... WHAT is retro?)

The secret weapon that changed everything

One day, my manager encouraged me to review more PRs after I joined the company for a few months. He said just left comments, we’d love to see your thoughts there.

So I opened the PRs.

They were written by senior engineers, I am just a junior. Everything looked... good. I didn’t even know what to comment on. Zero. Absolutely nothing.

But my manager said I should comment and I really didn’t want him to ask why I hadn’t. So I forced myself to ask any question.

At first, the only comments I could make were:

• What does this mean?
• I’m not familiar with X, what does this do?

Then, after I accidentally broke production once, I discovered the magic question:

• How do we handle errors here?
• What happens if this fails?
• Do we have an error state?

I realised many engineers naturally focus on the happy path first. Once you ask about error handling, you immediately reveal missing validation and missing tests.

The magical thing is these questions don’t depend on syntax. They work in any language, any stack, any repository.

Even in stacks I don’t know, like legacy systems, I can still ask useful questions.

My secret list of questions for reviewing ANY stack

These questions helped me survive reviewing PRs I didn’t understand:

• How do we handle errors/edge cases here?
• Do we have error states?
• Do we have tests for this behaviour?
• Why do we need this? (And if the answer is complex) Could you add a comment explaining this so we don’t forget why?
• Why is it written this way? (e.g. deeply nested ifs) Can we simplify it?
• How does this flow actually work?
• Does this function do too many things?
• This variable is used everywhere, should it be split or named differently?

Notice something? None of these questions have anything to do with which language this is in. They’re to do with logic, behaviour, readability and testability.

You don’t have to know Python, Go, Ruby, Kotlin, or some kind of legacy stack.

When you ask "What happens if this fails?", you force the code to reveal assumptions that were never written down, or uncover hidden behaviour that even the original author didn’t notice.

That’s why this technique works across frontend, backend and even legacy code. Failure is universal. Once you learn to look at the unhappy path, you can see it in a higher-level.

Results: six years later...

Without noticing it, forcing myself to leave comments, even when embarrassed, even when clueless, reshaped my entire engineering career.

After six years of doing this, I reviewed hundreds of PRs. I can review repos I’ve never seen. I can context-switch extremely fast!

I can spot good/bad patterns quickly. I can ask useful questions even in languages I don’t write. I could review backend, mobile, legacy, GraphQL, data pipeline, anything.

Reviewing became the fastest way I grew as an engineer. It helped me far more than writing code alone ever could.

I learnt from dozens of people, dozens of styles, dozens of systems. In the age of AI, this ability becomes even more important.

I’ll talk about AI in part 2. See you there!