Teaching juniors when the agent knows more

A couple of weeks ago the junior who joined us in May last year asked her mentor why a migration had locked a table in staging for eleven seconds. He gave her a decent answer about ALTER TABLE taking a heavy lock. Then, because she’s thorough, she pasted the migration into an agent and asked again. The agent’s answer was better. It named the lock mode, pointed out that the new column had a volatile default, which makes Postgres rewrite the whole table, and suggested the two-step version: add the column with no default, backfill in batches, then set the default. Her mentor read it over her shoulder and said something like “yes, that’s right, I’d forgotten that part”. He told me about it the next day, half laughing and a bit rattled.

When I wrote about why I’m still hiring juniors last year, my worry was that agents take away the friction juniors used to learn from. I didn’t spend much time on the more awkward problem, which is that for most of the technical questions a junior asks in their first two years, the agent is a better explainer than the senior engineer sitting next to them. It’s more patient than any of us, and it’s awake at eleven at night when the question comes up. If mentoring was mostly answering questions, it’s done.

It never was mostly that, though answering questions is the visible part. What the agent can’t tell her is why our system looks the way it does. It doesn’t know that the odd retry wrapper around the webhook sender exists because of a bad weekend years ago, or which customers will email the CEO if an export changes format, or that one “temporary” table has been temporary since 2017 and everyone is scared of it.

It also has no taste about our code in particular. “This is correct and I still wouldn’t merge it” is a call juniors need to watch someone make, out loud, many times before they can make it.

So we’ve changed what the mentor sessions are for. The weekly one-on-one now starts with “what did you ask the agent this week, and what did you do with the answer?” It’s a much better conversation than “any questions?”, because the questions already have answers. What’s left is whether she checked the answer, and whether she’d asked the right question. Twice in the last month the answer was fine and the question was wrong, like asking how to make a slow query faster when the real issue was that the page shouldn’t run it at all.

We also told the mentors it’s fine to say “I don’t know, ask it, then come back and tell me whether you believe it”. Two of them found that hard. Being the person who knows things is a big part of why people like being senior, and I didn’t appreciate how much until I watched a good engineer lose a bit of it in front of someone who’d been doing the job for just over a year.

The PR walkthroughs stay. The one-notch-left rule from last year ended after each of them had a few months in, as planned, and I haven’t wanted it back.

The social side is the part the agent can’t replace. When I was junior, asking a senior engineer a question was how I got to know them, and a few of them shaped my whole career. Our juniors ask fewer questions of people now, because they don’t need to. I’ve started putting them in design reviews earlier than I would have, partly for the learning and partly just so they’re in a room with the people.