Slashdot Mirror
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?
"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?
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!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
A person is not their job. Stop promoting that.
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.
#DeleteChrome
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.
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.
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
Well, no. All the person seems to be describing is the ramping up process, which anyone who has switched jobs or had new coworkers will recognize. It does not say anything about how good or bad of a programmer they are, only that you can expect them to take time to get up to speed as they learn the new system/team/norms/whatever.
Any team or position that you can hit the ground running and immediately be up to your full capacity is probably a job to be avoided since the needs of it are probably quite modest and mind numbing.
And this doesn't just apply to programming. Pretty much any skilled work, esp work with an existing body of knowledge specific to the institution is going to have this, down from the lowliest intern or janitor to the c suite executives.
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.
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Comment removed based on user account deletion
Coming from a complex environment where it takes a year or more to just begin to understand the product (service with massive amounts of customizations for many high-profile customers), this definitely makes you less employable. It definitely feels to me like we're going to start seeing a backlash soon against all of the millenials who flip jobs every year. As more products get more complex it takes longer for a new employee to truly become competent at their job. Turnover is extremely disruptive. And this is in an environment with good wages and benefits.
Personally if I had two equally experienced candidates, one with ten positions in ten years, and one with two in ten years I'd take the latter. I want someone who will stick around long enough to become effective and pay off all of the time it took to reach that point.
(And finding a support person? That's even harder. We need 2-3 years minimum to get a support person to competency, and that's if we poach someone from an employer who already knows our products some from a user perspective.)
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.
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.
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.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
Yes, anyone would!
But as I said, you cannot. Over time, performance starts to degrade. Maybe you can have a great team for four, five years. But somewhere in there the greatness fades and you just have an average team eventually. You said you want to fix it, but the fundamental thing you cannot fix is that people are people.
I have been in great teams before, that worked so well I stayed on for many years... I said my preference was for three years, but that was found by staying with two companies for around 8-9 years each beforehand.
Note that you do not necessarily have to leave a company to gain the benefits I stated, at one place I transitioned to different teams at around three years and that worked quite well for all. But basically my statement of three years being a good term comes from decades of experience as employee and contractor at multiple companies of all different sizes.
What you see as sad, I see as a magnificent combination - a company and individual figuring out how to really work, both receiving huge benefits for a time.
The recognition that all good things come to an end, is something that everyone must come to grips with. Once you do, and embrace it, life itself is so much easier and enjoyable, as you learn to move with life instead of fighting to stay still and have chaos overwhelm you eventually.
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.
Like I said, I have been in many different companies of different sizes. I am pretty sure that it how things are and there's nothing fundamental you can do to mitigate the issue of productivity drop-off eventually.
You do point out role(s) as plural which is like I said a way you can kind of delay the inevitable by shifting to a different task and team, but a big problem is that you are still fundamentally in the same domain, and I think that's the core of why people start to decline and why moving on can be so helpful to the individual. Also no matter where you go in a company (small or large) you are immersed in the same political environment, another factor that can really drag you down, and does not change over time as much as anyone would like it to.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
In my 30, or so, years working as a programmer, I have changed jobs several times. And when I say changed jobs, I mean different employers in different industries using a different tech stack, so really changed. Switching jobs makes you worse in the sense that your corporate knowledge - local source code, local program design, local tools, contacts, etc - is now worthless and you need to replace it. That takes time to learn, and learning it will slow down your productivity. Switching jobs makes you better in that you learn a new tech stack, new techniques, new concepts (design, how to work with clients, how to think about problems), etc. Whether you switch jobs is somewhat irrelevant. In our industry, you need to be learning new stuff. If you cannot sit down at the end of a year and list a couple of significant things you learned over the past year, you've got problems. The industry is ALWAYS changing. You cannot keep up with everything, but if you don't grow, you will become obsolete. the good news is that it's never been easier to learn new stuff.
linquendum tondere
I want to see a cite, preferably more than one, for "Productivity is higher in areas with more job churn".
Here you go:
1. Labor market flexibility boosts productivity
2. Go for the Churn
The area with the highest job hopping rate, due to California's ban on non-compete contracts, is Silicon Valley. No where are else are developers more productive or better paid.
Churn is good. Good for workers. Good for companies. Good for national economies.
And if they leave as soon as they become useful he's probably treating them badly, underpaying them, or both.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Was all this before you were a Navy Seal and a test pilot, or after?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."