Does Switching Jobs Make You a Worse Programmer? (forrestbrazeal.com)

Slashdot reader theodp shares some thoughts from Virginia-based cloud architect Forrest Brazeal, who believes that switching jobs or teams makes you -- at least temporarily -- a worse programmer: "When you do take a new job," Brazeal writes, "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."

He concludes, "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."
This seems counter-intuitive to me -- but what do Slashdot's readers think? Does switching jobs make you a worse programmer?

Comments

Struggle is growth

[SuperKendall]

The view he gives is nuanced, and it's not a bad idea to stick with jobs for a least a few years before switching...

But he also lays out the part where you don't know as much as the people in the company even though you have experience, and labels that as slowing down or a switchback.

I think those are some of the most valuable times for true growth. You are learning how other companies work. You are learning how other people approach code. Maybe you agree with some of that, maybe you do not, but in any case that kind of temporary struggle is tremendously valuable over time as the more experience you gain with different environments means in the future a new place or system may look something like what you have seen before, or you may be able to draw on what several companies did in a combination that leads to a new and better approach than any one of the companies...

So while you may not want to switch jobs too often, keep in mind the flip side of that advice - don't get stuck in just one company too long, especially early in a career!

Re:Struggle is growth

[Hognoxious]

I've heard it said that 10 years in one company is more like two years of experience repeated five times over. It's similar to diminishing returns.

And what one place does well another is utterly shite at, and vice versa.

Finally, what the fucking hell is a cloud architect when it's at home, which I suspect it usually is?

Re: Struggle is growth

[Anonymous Coward]

Believe it or not, some people actually enjoy repetition and monotony, doing the same thing over and over again, and find the novel makes them anxious.

A person is not their job. Stop promoting that.

[Anonymous Coward]

A person is not their job. Stop promoting that.

Betteridge is actually appropriate here

[93 Escort Wagon]

Does switching jobs make you a worse programmer? No.

It’s true there are things existing team members know but you don’t, at least at first. But you are indeed adding experience and knowledge the other team doesn’t currently possess, regardless of this person’s premise. The author claims “that’s not really happening”, but provides no evidence to support his claim. I, on the other hand, have seen this infusion of new knowledge and ideas occur, first-hand, when we’ve added a new team member.

Re:Betteridge is actually appropriate here

[rtb61]

Switching jobs, really insufficient information given ie switching projects, switching teams, switching employment, switching languages, switching programming styles and switching programming structures. So it depends upon how much is changing, the more change the more loss of productivity but it depends on the new working environment compared to the old one, how much change and how productive the old environment was and new project or existing project.

The real question is whether a stable development team is more productive than a continually ad hoc team ie whether you keep staff together over the longer term with period of non-project productivity, they can do total quality management https://en.wikipedia.org/wiki/... projects during that time (redoing programming structures, variable choices, code library maintenance and refinement, basically internal projects to improve coding outcomes) versus hiring and firing staff straight in line with project demands.

This being the balance between higher productivity expected from a well oiled machined versus lower productivity from ad hoc team (constantly being dismantled and rebuilt dependent upon project demands) and how you balance between the two. For developing, maintaining and refining the coding library is very productive but somewhat intermittent upon demand and works well with retaining staff with low project load, as is reviewing coding structures, variable use, documentation, basically maintaining the coding environment.

80% of your new job is domain knowledge

[quietwalker]

Domain knowledge is knowledge that you would only have by working at that job or at that company. You can't train for it, you can't 'know it', you can only gain it over time.

Now, you might be able to trace code a bit faster (except that bit where they muck with the class loader and the config is in a database) or fix a build (except they're using a homebrew system), or maybe even optimize a SQL request (except they require that you go through sprocs and have an actual DBA sign off on it), but you're going to be going slow at first, even if you could technically do everyone else's job at the same time.

That's just how it is. That's also why you should pretty much apply for anything: there's a good chance you could do it - and what's on your resume or their job request is really only 20% of what the job really is.

The most important thing to do at a new job

[NotSoHeavyD3]

Is find what the "in" group is and make sure you're part of it. If in your first 6 months you realize you're not part of the in group for any reason you might as well leave because it's actually easier to get into the in group as an outside hire than as a member of the company who is currently in the out group.(You're now typecast.) For those that do know the in group gets listened to, gets the good things to work on, and if they ask for something they'll actually get it.

Re:The most important thing to do at a new job

[phantomfive]

For those that do know the in group gets listened to,

I try to avoid companies like this. I prefer it when people get listened to based on the quality of their arguments. And don't tell me that doesn't happen because I know it does.

Long-term programmers can make for worse software.

[Average]

On the flip side, a stable of long-term plodding programmers can sure make for stale code. I can think of several examples still today. Software that is the standard thing in some low-revenue boring niche field. Developed and sold by some little five-person family-run shop in some suburb. Software that is just patch upon patch upon patch on some 1996-era Turbo Pascal or MFC C++. With some client-server bit bodged in here. With some 'export to HTML' kludge over here as a "web publishing platform". Software that desperately calls out for getting replaced by something newer, but the install base, data lock-in, and niche market combine to keep things just getting more and more outdated.

You could be a software developer with twenty years in one of those shops. With twenty years of writing 1996 code. And you'd be basically dogshiat on the job market.

Re:A senseless question.

[Anonymous Coward]

I want to see a cite, preferably more than one, for "Productivity is higher in areas with more job churn".

If you applied to work at my program, but your resume shows you leave every 3 years, I simply will not hire you. Nothing is going to be worth paying you to learn my company's style and process, to understand our software and customers, only to have you leave once you finally start to be useful.

The experts - the ones that have been on program for 20 years, who know not only what the systems do but why they do it - are the valued workers. They're the ones that get the big bucks.
The newbies - the one like you that have only been around a year or two, whose knowledge of the systems is limited to what they happened to have been assigned to work on - are the ones that get the scut jobs, the bug fixes, and the O&M work. Once they have experience, they'll be allowed to develop new features.

Re: A senseless question.

[Zero__Kelvin]

If it takes 3 years for your employees to become valuable and knowledgeable then you are hiring incompetents, your documentation and process is horrible, or both.