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

[SuperKendall]

I've heard it said that 10 years in one company is more like two years of experience repeated five times over.

That is a great way to put it.

My preferred length of time is three years - two years of learning to really understanding the domain and the related systems, then a year of great productivity as you really hum because you are no longer dealing with much internal overhead in getting work done.

Much longer than that and you start to grow tired of repetition, or the little things that were always problems start to annoy you more and more. For whatever reason, productivity drops again...

That's probably the thing to really look out for, be self aware of how you feel you are doing in your job. That can be the signal as to when you might want to start looking for something new, if you notice that your own performance starting to decline for any reason.

Re:Struggle is growth

[vux984]

And to me this is just sad.

" two years of learning to really understanding the domain and the related systems, then a year of great productivity as you really hum because you are no longer dealing with much internal overhead in getting work done."

So as the employer, that's a pretty shitty deal. I'd really like to hang onto a team who are really humming for longer than that. Who know how things work, who know where everything in the code is and how its organized, who've mastered processes, who actually understand the knowledge domain we're developing software to solve so the friction between requirements and implementation is much lower...

"Much longer than that and you start to grow tired of repetition, or the little things that were always problems start to annoy you more and more."

I think this is where we diverge. You want out to get away from this... I want to know why we can't fix this.

FWIW I've never worked anywhere really big; i prefer smaller companies; because I like them more. They aren't as rigid, the work is really varied, everyone is wearing 2 or 3 hats.

"That's probably the thing to really look out for, be self aware of how you feel you are doing in your job. That can be the signal as to when you might want to start looking for something new, if you notice that your own performance starting to decline for any reason."

I agree with you here, but looking at it from the other side, as the employer -- they should be looking to figure out how to resolve these 'problems'. Because losing good people after a few years in an industry where it takes a couple years to hit their stride is a huge waste.

"I've heard it said that 10 years in one company is more like two years of experience repeated five times over."

I think it can be. I don't think it has to be. It'll depend on the company and your role(s) in it.

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.

Re:A senseless question.

[ShanghaiBill]

Most developers don't switch jobs because their employer is going out of business. They switch because their job sucks, or they want to make more money.

Companies will pay more to lure away talent from other companies than they will to keep their current employees. You should switch employers every 3 to 5 years to maximize your income.

Productivity is higher in areas with more churn. Job hopping means new ideas and better techniques spread quickly between companies.

No

[Greyfox]

It does impact your productivity as you learn your way around a new code base, but it doesn't make you a worse programmer. Your employer expects there to be a ramp-up period, so that's not a problem. If you switch positions because you think there's some cool stuff to learn in the new position, it'll generally make you a better programmer over time. Plus, it's really the only way to get a decent raise in the industry.

Comment removed

[account_deleted]

Comment removed based on user account deletion

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.