Suppose you are interviewing for a software engineering job. The interviewer does that annoying thing where they ask you programming trivia questions, like how to write a ternary statement in some language you haven’t used in awhile.

“I don’t remember off the top off my head,” you say, quite reasonably. “If I needed to do that at work, I would just Google it real quick.”

“Ah,” says the interviewer, “we don’t use Google here. No StackOverflow allowed. We only write code from scratch.”

You’d walk away from that job opportunity immediately. Why? Because Google and StackOverflow are essential tools that help you do your job. Without them, you wouldn’t just have a harder time achieving the same goals; you’d probably be a categorically worse developer. You would lose access to the great hive mind of programmers on the internet that allows you to level up your own talent. Nobody in their right mind would make that tradeoff.

The learning curve fallacy

And yet, when you do take a new job, one that lets you go hog-wild on StackOverflow, you’ll probably still need at least a few weeks to get up to speed. Everybody else will know things you don’t know. You’ll expend an enormous amount of time and mental energy just trying to keep up.

This is usually called “the learning curve”. The unstated assumption is that you must add new knowledge on top of the existing base of knowledge you brought from your previous job in order to succeed in the new environment.

But that’s not really what’s happening. After all, some of your new coworkers have never worked at any other company. You have way more experience than they do. Why are they more effective than you right now?

Because, for the moment, your old experience doesn’t matter. You don’t just need to add knowledge; you need to replace a wide body of experiences that became irrelevant when you turned in your notice at the old job.

To put it another way: if you visualize your entire career arc as one giant learning curve, the places where you change jobs are marked by switchbacks.

From senior to junior in one easy step

You don’t know who on the new team can help debug Linux networking issues. You don’t know who has already built the library you spent half a day kludging together. The time you spent becoming a rockstar at a technology nobody uses anymore, while it may be generally helpful for analogy’s sake, does not automatically make you a rockstar at whatever technology the new company uses instead.

Consider what we might call the “shadow codebase”. When you’re roughing out a new piece of code, you’ll often pull boilerplate or helper functions from other, similar projects your team has done in the past. Assuming you’re not working on open source stuff, you’ll lose access to a lot of that when you leave your job. Practically speaking, it’s much like losing a very specific version of StackOverflow that was custom-built to solve your problems. You become a worse programmer until you can build that shadow codebase back up.

Your title may say “senior”, but effectively, at least for now, you’re getting help from the junior devs.

I’ll say it again: switching jobs or teams makes you, at least temporarily, a worse programmer. A software development team is greater than the sum of its parts, and our value as engineers is more context-dependent than we realize. Hiring managers know this phenomenon quite well: turnover of even one key person can dramatically depress effectiveness across an entire team. But I think individual engineers are less aware of the effect turnover has on our own careers.

New job, new you

Obviously, I’m not saying you shouldn’t switch jobs. Just remember that you can’t expect to be the same person in the new cubicle.

Your value is only partly based on your own knowledge and ingenuity. It’s also wrapped up in the connections you’ve made inside your team: your ability to help others, their shared understanding of your strengths and weaknesses, and who knows what else.

You will have to figure out new paths of communication in the new organization, build new backlogs of code references pertaining to your new projects, and find new mentors who can help you continue to grow.

You will have to become a different programmer. There is no guarantee you will be a better one.