What happens when you are given a system you have never seen?

I read the output before the source, because the output is what is true and the source is what somebody intended. Then I reproduce the problem, write down what I expect to happen, change one thing, and check whether reality agreed with me. Most debugging failures are a wrong shared assumption that nobody thought to test.

How do you work when you do not know the language or framework?

The loop does not change. Establish what is true, form one hypothesis, test it, write down the result. The syntax is the smallest part of the problem and the fastest part to learn. What transfers is knowing what to be suspicious of.

Is any of this different on a team?

It gets easier. Everything above exists because I have mostly worked without a reviewer, so the process had to do the job a colleague would do. On a team the same habits mean my work can be picked up without a meeting.

How do you decide what not to build?

Frequency multiplied by the cost of not having it, and a bias against building the interesting problem when the important one is duller. The pull toward the interesting problem is the most common failure of an engineer working without product pressure, including mine.

The method

How I work when nobody is checking

Most engineers describe this as a personality trait. It is a process, it is written down, and it is the reason an unfamiliar system is not a risk.

I have mostly worked without a reviewer. That is not a boast, it is the constraint that shaped everything below: when there is nobody to catch the mistake, the process has to do the job a colleague would have done.

A six step loop: read the output not the source, reproduce it before theorising, write the plan down, change one thing, prove it end to end, hand it over in writing, then repeat on the next unfamiliar system — Six steps, in order. The order matters more than any individual step, because most of the failures below come from doing the right thing at the wrong point. Tap to open full size.

Verify, never guess

I do not assume a field, a behaviour or a number exists. I check first. Every claim I make about a system is one I have run, and when I am uncertain I say so rather than rounding it into confidence.

A guess that happens to be right is indistinguishable from knowledge until the day it is wrong, and by then it is load bearing.

The plan is the truth

Work starts as a written plan, and the plan gets edited as reality lands rather than left as a record of what I originally hoped. Anyone can open it and see where the work actually is.

Plans that are never updated are fiction. A plan that tracks reality is the only artefact that answers where things stand without interrupting somebody.

Proven, not compiled

Done means it was exercised end to end, the data reconciles, and I read the evidence rather than trusting that it passed. Compiling is not shipping and a green test suite is not proof.

Most of what breaks in production was tested. It was tested at the wrong level, against fixtures that were kinder than reality.

Measured, not felt

Explain the slow path, record the median and the tail separately, and test at the scale it will actually meet rather than the scale that fits on my machine.

A good average with a bad tail is a system that is quietly late for a small number of people every day, forever, and nobody reports it.

Handed over in writing

Every piece of work ends with a handoff somebody could resume from cold. Not documentation of the code. A record of the decisions, the things that surprised me, and the traps.

This is the habit that makes me safe to put on a team, not just safe to leave alone. It is also what I read six months later when I have forgotten everything.

Same mistake, never twice

Decisions and their reasons get recorded. When a rule is learned the hard way it becomes a written rule rather than a memory that fades.

Experience that is not written down decays into instinct, and instinct cannot be handed to anybody else.

Worked example

The loop, on a bug that had already beaten three people

A site was ranking as though every page were the same page. Three separate commits had already added the correct per page tag. Each engineer had verified their own change. Each was right about it. Nothing improved.

Verify, never guess. I stopped reading the source and read what the server actually sent. That is the entire trick and it is the step everybody skips, because the source is what we believe and the output is what is true.

Every page was serving two of the tag. One was inherited from a shared layout, one was correct, the framework merged both, and the inherited one won on document order. Nobody had looked at the merged result because everybody was looking at their own change.

Prove it, then measure it. The fix was one deleted line. I then added a check that reads the built output and fails the build if it ever happens again, because a fix that relies on nobody repeating the mistake is not a fix.

Write it down. The reason it took three attempts is that the failure mode was reasoning from the input when the truth was in the output. That is now something I look for first, and it is written down, which is why I still do.

The full write up

Working with AI

I use it daily, and the loop above matters more because of it

AI is in my routine most days. It has not changed the process on this page. It has made every step of it more necessary, which is the opposite of how it is usually sold.

The reason is simple. These tools raise two things at once: how much output you can produce, and how plausible that output looks when it is wrong. Volume and plausibility are exactly the two conditions under which unverified work does damage. So the answer is not less rigour because the machine is good, it is the same rigour applied to more material, faster.

Where I let it work

Reading an unfamiliar codebase quickly, to find where to look rather than to be told the answer.
First drafts of the boring half: scaffolding, migrations, test fixtures, the parser I have written thirty times.
Arguing with a design before I commit to it, which is the closest thing to a colleague I have working alone.
The test I was going to skip because it was tedious. This one is a genuine quality gain.
Turning a plan into a written handoff without losing an hour to prose.

Where I do not

Anything touching money, permissions or tenant isolation goes through the same verification as if I had typed it, because it did not know it was guessing.
A claim about how a system behaves. That gets checked against the output, always.
A number. It will produce one, confidently, and it will be wrong in a way that reads as right.
A decision. It is very good at arguing either side, which makes it useless as the thing that decides.

The rule I hold to

I do not ship anything I could not have written myself and cannot explain line by line. Not as a principle about purity, but because I am the one who gets called at two in the morning, and you cannot debug code you never understood.

The distinction worth drawing: the discipline predates the tool. Verify before acting, prove it end to end, measure the tail, write it down. Every one of those habits was built because I had no reviewer, and every one of them turns out to be exactly what these tools require to be used well rather than used fast.

Questions people actually ask

What happens when you are given a system you have never seen?: I read the output before the source, because the output is what is true and the source is what somebody intended. Then I reproduce the problem, write down what I expect to happen, change one thing, and check whether reality agreed with me. Most debugging failures are a wrong shared assumption that nobody thought to test.
How do you work when you do not know the language or framework?: The loop does not change. Establish what is true, form one hypothesis, test it, write down the result. The syntax is the smallest part of the problem and the fastest part to learn. What transfers is knowing what to be suspicious of.
Is any of this different on a team?: It gets easier. Everything above exists because I have mostly worked without a reviewer, so the process had to do the job a colleague would do. On a team the same habits mean my work can be picked up without a meeting.
How do you decide what not to build?: Frequency multiplied by the cost of not having it, and a bias against building the interesting problem when the important one is duller. The pull toward the interesting problem is the most common failure of an engineer working without product pressure, including mine.
Do you use AI to write code?: Daily, and it has not changed the process, it has made it more necessary. These tools raise how much output you can produce and how plausible it looks when it is wrong, which are exactly the two conditions under which unverified work does damage. So the same verification applies to more material. I do not ship anything I could not have written myself and cannot explain line by line, because I am the one on call for it.

This is the part that transfers

If your stack is one I have never touched, the loop above is what you are actually hiring. It works the same in any language.

Get in touch See it applied