The hard part of joining a team isn't the code. It's that you don't know where anything is, and every question you have is one somebody else could answer in about four seconds.

So you either interrupt them, or you spend forty minutes finding it yourself. Both feel bad. The first one feels worse, so most people pick the forty minutes.

The ramp is longer than anyone admits

The published numbers vary a lot, which itself tells you something.

Time to a first commit is often measured in days, and that number gets quoted proudly. It's also close to meaningless, because a first commit is usually a typo fix designed to test that your access works.

The number that matters is time to independent work, and that's 8 to 12 weeks with good onboarding and three to six months without. One breakdown puts juniors at four to six months to reach 90% velocity, against six to ten weeks for seniors.

What's interesting is that the gap isn't really about coding ability. A staff engineer can ship code in week two and still need three months to land anything architectural. They can write fine code immediately. What they lack is the same thing I lacked: knowing where things are and what talks to what.

That's not a skill you can hire for. It's information, and it's currently stored in people.

The interruption is the actual cost

Here's the thing that took me a while to see.

When I ask a senior engineer where something lives, it costs them a lot more than the four seconds of answering. They lose their thread. Then they context switch back. Multiply that by a new person having ten of those questions a day for a month.

Sourcegraph's writeup on this puts it well: the fastest-ramping teams have made their codebase self-serve, so a new hire's question gets answered by a search rather than an interruption. That framing helped me. The goal isn't to have fewer questions. It's to route them somewhere that isn't a person.

And the questions a new person has are genuinely repetitive. Where does a request enter. Which service owns this. What deploys this. Where's the config for that. Any senior engineer has answered each of those a hundred times and would rather not do it again.

The four questions I kept having

Looking back at my own first weeks, almost everything reduced to four things.

Where is this defined? I have a function name from a stack trace or a code review and no idea which repo it's in.

Who calls it? I'm about to change something and I want to know what depends on it.

What is this service, actually? Not the README. What runs it, what it talks to, what monitors it, what deploys it.

How does this whole flow work? The genuinely hard one, because the answer is never in one file.

The first three are lookups. The fourth is the one that used to eat entire afternoons.

What changed for me

I use Vörr for all four now, and the fourth is where it earns its keep.

For the lookups it's straightforward. Ask where a symbol is defined and get the repository, path and line. Ask who references it and get every call site across every repo, not just the one I'm in. That last part matters more for a new person than an established one, because I don't yet know which repo to guess at.

The fourth question is different. Instead of opening six files in sequence and trying to hold them all in my head, I can ask for a context pack on a whole feature or flow and get the relevant pieces assembled together. A behaviour is never in one file. It's spread across a handler, a service, a client and a config value, and reading them one at a time is how you lose the thread halfway through.

Then there's the part that isn't code at all. I can ask what a service actually is and get what it runs on, what it depends on, what monitors it, what deployed it last. That's the thing a new person genuinely cannot get from a repository, and it's usually the thing they need.

Coming from electronics, this maps onto something familiar. You never understand a board by reading one component's datasheet. You need the schematic. Reading files one by one is datasheets. What I actually wanted was the schematic.

Where you still need people

Worth being clear about the limits, because I don't want to overclaim on something I'm still living through.

Code tells you what happens, never why. A retry limit set to three because of an outage in 2023 that nobody wrote down is not recoverable from source. That reasoning lives in a pull request comment or somebody's memory, and you have to ask.

You also can't learn conventions this way. What this team considers a good PR, when to escalate, which parts of the codebase are fragile and treated carefully. None of that is written anywhere.

So the questions don't disappear. What changes is which questions you spend a senior engineer's attention on. Mine are better now, mostly because I've already answered the boring half myself.

If you're onboarding someone

Two things I'd have wanted.

Give them a way to answer their own lookup questions from day one, before you give them a task. The task is easier than the orientation and everyone gets that ordering backwards.

And measure time to independent work rather than time to first commit. First commit measures whether your access provisioning works. It tells you nothing about whether the person can actually operate on their own, which is the thing you were hiring for.

Author note

Manjunaathaa, Associate DevOps Development Engineer at Frigga Cloud Labs.

I'm close enough to this to still remember it properly, which I think is the only reason I have anything useful to say about it. Give it three years and I'll have forgotten what was confusing, the same way everyone does.

The thing I'd tell someone starting now is that the confusion isn't a signal about you. It's a signal about how much of your team's knowledge has never been written down, which is a property of the team and not of you.

If you're onboarding onto something large right now, I'd be interested to hear what worked. LinkedIn.

Nobody Tells You That Month One Is Mostly Asking Where Things Are