I joined N Squared in August 2022, after two Zoom calls. That isn’t much information to make a decision on, and I made it on something fairly unquantifiable: I came away from both calls thinking this was a person who told me the truth about things, including the inconvenient parts.
Four years later that remains the most accurate read I’ve made about anyone professionally, and most of what follows is downstream of it.
The GitHub label
In my first weeks I needed something tracked, so I created a label to track it. Sensible, and exactly the kind of small unilateral action I’d been praised for at a previous job.
Nathan’s response was immediate and mild: you don’t need to do that, we have a process for that.
My instinct was that this was bureaucracy. It wasn’t, and understanding why took me longer than it should have. The process existed because a small team supporting a large customer base can’t afford divergence. Every ad-hoc convention someone introduces is a thing the next person has to discover, and discovery costs get paid forever while the shortcut gets paid once.
The broader lesson, which I’ve since applied everywhere: when you arrive somewhere and the process looks unnecessary, the correct assumption is that you haven’t yet seen the failure it prevents.
Sometimes there genuinely is no failure and the process is vestigial, but that is a conclusion you haven’t earned in week three. This is also the strongest argument for writing down what went wrong before, not just what the rule is: a rule with no visible reason gets correctly identified as arbitrary and routed around by the next person who arrives.
Here’s the distinction I’d actually missed. Doing something without waiting for approval is usually right. Doing something differently from how the team does it, without asking, is a different act entirely. I’d collapsed the two into one idea called “initiative” and they aren’t the same.
Two ways to find a bug
My debugging method was linear and mechanical. Xdebug, step through, eliminate possibilities one at a time, refuse to guess. It’s slow and it always terminates. I trusted it because guessing had burned me and elimination never had.
Nathan works from the other end. He starts at the top, with what the customer is experiencing and which part of the system could produce it, and narrows downward. It looks like intuition. It is a model of the whole system built over years, applied as a filter.
For a long time I couldn’t use his method, and I was slightly defensive about that. Then at some point I had enough of the system in my head that starting from the big picture began to work, and I understood the actual relationship: his method is faster when you have the model, mine works when you don’t.
They’re the same search entered from opposite ends, and which one is available to you depends entirely on how much context you’ve earned.
I use both now, and the switch is a single question: can I form a hypothesis I’d bet on?
If yes, start at the top and go down. If I’m guessing (and there’s a specific feeling to guessing, once you learn to notice it), go linear and eliminate. The failure mode is doing top-down without the model, which is a sequence of hunches with a debugger open.
Taking the bugs
Shortly after joining I took on investigation and resolution of the bug reports. All of them.
This wasn’t heroic, and at the time I thought of it mainly as a way to learn the system quickly, which it was. Nothing teaches you a codebase like being responsible for everything wrong with it. What I didn’t anticipate was the effect on someone else’s time.
Nathan had been the person absorbing that queue. When it moved, his week changed shape, and he could work on the direction of the product rather than its daily failures.
That reframed what I think a contribution is. Most of the individual fixes were small. The value was that a specific person got freed from a specific recurring drag, and that person’s freed time was worth more than mine.
The highest-leverage work is often not the most technically interesting. It’s whatever is currently consuming the most valuable person’s attention. That’s a question worth asking explicitly, out loud, and almost nobody asks it. It’s also uncomfortable to ask, because the honest answer is frequently “something boring, and it should be me.”
It’s the same question as asking which finished thing makes the next thing cheaper, applied to people rather than to tasks. A ranked backlog will never surface it, because the item doesn’t appear on the backlog at all.
Paranoia, correctly aimed
The clearest thing I absorbed: be paranoid about mistakes, specifically the ones customers can see.
Internal breakage is recoverable and cheap. A customer encountering a broken thing costs trust, and trust doesn’t restore on the same timescale it’s lost on. So the paranoia is directional, heavy on anything a user touches, deliberately relaxed everywhere else.
That directionality is the useful part. Undirected caution makes everything slow and is always the first thing abandoned under pressure, usually in the week you most needed it. Aimed caution survives, because it’s cheap enough to keep.
Three practices came out of it and I use all of them.
Revisit with fresh eyes. The same code, the next morning, is a different piece of code. I’ve found things at 9am that were genuinely invisible at 6pm, reliably enough that I now schedule around it rather than pushing through. Shipping something customer-facing late in a long day is a decision.
When you can’t reproduce it, guard against it. The instinct is to keep hunting until you can. Sometimes you can’t: the report is thin, the state is gone. The next best action is defensive code that makes the failure impossible or harmless without knowing the trigger. You lose the satisfaction of understanding it. You keep the customer.
When you can’t guard, ship a safe probe. This one changed how I handle the genuinely mysterious class of bug, so it’s worth spelling out.
A safe probe is a deliberate release whose purpose is information rather than repair. It can’t make anything worse, and it returns more than you had before at a cost low enough that you’d do it again next week if it comes back empty. In practice that means structured logging around the suspected path that captures the state you wished you’d had in the original report, or a narrow guard that records what it caught before handling it.
You’re not required to choose between certainty and inaction. Certainty is expensive and sometimes unavailable. You can spend a release on learning, and it’s a much better trade than either guessing at a fix or leaving it open.
The last line of defence
Nathan’s operating principle was that nobody should be a bottleneck, with himself as the standing exception, because he considered himself the final check before anything reached a customer.
I’ve thought about that a lot. It’s a real cost, and he knew it was. It’s also a coherent position: if you’re the person who cares most about the customer’s experience, being the last check is the job.
What I took from it is that someone must own the outcome rather than the task, and that this ownership is the thing keeping quality from degrading by small acceptable increments. Every individual compromise is defensible. The aggregate isn’t, and only someone looking at the aggregate ever catches it.