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?
... EditorDavid an editor? Fuck no.
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.
I think this is true and a huge opportunity to get a lot better fast. It is all about people. If you work with great people (may I brag a little that I do) it is very rewarding not just in the intangibles of working with great people but also in how much smarter, more knowledgeable, and skilled you become. Usually a new job has aspects you cannot even imagine but if you keep listening and keep trying you will be much better off
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
Switching jobs actually makes you a better programmer. You'll work with different tech (or at least a different approach). Yes, you'll be learning things but it's not about being the best-of-the-best at your new company day 1. If you're new job has a good culture, they'll facilitate you committing to code very early on. Institutional knowledge isn't the same as industry knowledge. It may feel like you don't know squat but trust me, you'll be better off for it. The trick is to know when to leave... If you join a company where your coworkers have never worked elsewhere, this is an opportunity to teach. When working on a codebase or a large project, those that have been there a while will always know more than you do. This doesn't take away from your own skill sets at all but rather it proves that there are institutional knowledge that you haven't learned yet. Worse, it proves that they didn't follow standards which would allow someone with little knowledge of the codebase to contribute because of industry knowledge of the standards. You are expected to not know how things are done when switching jobs. That's why your "new". But that doesn't take away from your own skill sets. If anything, you have the opportunity to leverage what you already know to make the new job better (or at least try to).
Yes and this argument is the exact same excuse HR everywhere uses to rationalize never hiring anyone. Programmers lose all of their skills as soon as they leave school or switch jobs. Every new hire will add zero value which is too risky. The only safe option is not to hire.
I'm not sure if I'm subjectively a 'better' programmer after changing jobs but I'm objectively a 'much better paid' programmer !!!
But worse programmers tend to switch jobs quite a bit.
No
;)
When you decide to change jobs it is on you to ramp up and be of value to your new employer. Over all it should make you better at what you do. If you are the type that handles change well and to your advantage.
My son-in-law (in IT like me) changed jobs every 1-2 years after graduation. Then he found the right spot and has stayed there. BTW I stayed out of his choices.
Just my 2 cents
No, Thank You! This is arguably the worst excuse for being in one Company, because some opinionated nobody says so.
People leave even great companies because the management is bad, or because the job is bad or because they are getting stifled by everyone else around them. It may not reflect on one's ability to co-operate as much as it reflects on the entire company itself.
People leave Amazon all the time even though they are some of the brightest engineers. Also, the churn in other reputed companies such as Uber, Facebook and Microsoft is pretty high. Does that make them bad programmers? Heck, no. They may be great engineers but they can suffocate under terrible management. This is exactly why people leave companies.
A good programmer != a programmer who puts up with shit.
Let others change jobs instead. Theyâ(TM)ll be making swooping 20% gains in their base salaries and advancing their lives while you stagnate for some loser manager/team who are leveraging your comfortability and timidness to jump ship.
People who are keeping their résumés up to date and shopping themselves around are going to have more experience(s) than you and will likely get hired in above you and end up being your boss if you just stick the script year over year.
Switch jobs. Every 2-3 years. Eff your comfort.
you probably weren't a good programmer to begin with.
I have people skills. I am good at dealing with people. Why can't you understand that. What the hell is wrong with you people.
No. That is completely idiotic. It doesn't even require you to switch jobs, just trying to solve new things makes you a better programmer. Probably what he means is that he learned some framework X and the new team uses framework Y. That is why you shouldn't spend much time learning frameworks (or corporate controlled languages like C#, Go, Rust, etc). Once you "learn" them, it doesn't transfer. Stick with C++ and what you learn will transfer to a new position or a new problem.
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.
We must determine people's path in life as soon as possible and fix that with an eternal permanence that cannot be changed ever.
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.
sometimes teams and organizations get stale. The new individual if they are sharp and the environment is open can reinvigorate and re focus a team. Or everyone can hate on the new individual and torpedo things. I that case the smart will jump ship.
APK, is that you?
Just got a new job at the dairy mart. So I tried to program a neural network to see if I'm any good and, sure enough, I couldn't make the damn thing stop seeing sheep everywhere. It must be true. New jobs make you suck at programming.
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.
Studies show it's the same for every profession. If you are a stellar fund manager, software developer, whatever, studies show that you, on average, will not fare as well if you switch companies or universities.
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?
After an expected ramp-up period of a week or two (which he seems to be treating as some sort of super big deal crisis), you will be a better programmer by virtue of knowing all the good things from your last jobs and the good things from your new job. I've stepped up my game with ever job change I've had, usually because I have to learn a bunch of completely new skills and concepts.
Unless you're plain incompetent or you've accepted a job someplace that's completely broken or an enterprisey graveyard you can't help but get better.
And conversely if you hang around on a single project for too long (I'm thinking over 5 years, but that's handwavey) you're likely to stagnate. I've sure seen a hell a lot of that.
They make me program good..
Of course whenever you go into something new there will be a learning curve. While the "worse programmer" aspect makes for a nice click-bait headline, that is only a small part of the learning curve. TFA borders upon absurdity.
Sure you have to learn a new system but your experience will be highly useful - you were hired based on that, right? For many moving on to a new position means opportunities to learn new stuff and that makes you better. For others, they just want to get out of a crappy situation. The only issue I have is if an applicant has switched jobs every two years for their entire career. While that's not disqualifying, it is something I'll ask about in a job interview.
Some of us would prefer get closer to a 50-50 ratio.
I would say it's more like:
Year 1) Not quite pulling your weight.
Year 2) Pulling your own weight but still learning.
Year 3) Pulling 5x your weight because you can fly through things.
So over all the company is still way ahead. It's when you leave after just a year or so the company is kind of losing out.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.)
Please seek medical advice immediately.
Forrest Brazeal is a lazy, misguided, idiot millennial. This is just proof.
Unless this dickhead is using some kind of automated process to make these posts, they must be very unwell indeed. This has become a real obsession for somebody, to the extent that you have to wonder how they can perform any normal life functions.
I have had about 14 C/C++ jobs over the last 30 years...I find for the first 2 months I do not know too much so I am a little less productive. Then at about 18 months people figure out I know what I am doing and *everyone* wants my help. At about 2 years in they want to make me team lead or manager or something. At that point I leave the job, cause I just like writing code, dealing with people is just too frigging annoying.
If the software developers in the new job are working like they're on a production line, then there's probably some truth to those claims. However, such jobs are easily sent overseas where labour is cheaper. There's real tangible value to new team members who have experience from elsewhere, i.e. different strategies, perspectives, & knowledge, that can get whole teams to be more productive in both the shorter & longer term. Citation? Yeah, way back from 1973: Granovetter, M. S. (1973). The Strength of Weak Ties. American Journal of Sociology, 78(6), 1360–1380.
Debate is a form of harassment. Do not question my truth.
The more experiences you gain, the better programmer you are for most people.
The best way I know to see what other companies do well and learn what your prior company did well is to change jobs.
I've worked at some famously high-performance places - known for almost zero bugs and I've worked at some seat-of your pants places with full teams of super hero devs.
Over the years, I've held 7 jobs at different development companies. None came close in quality to the first job and non came close in productivity to the 2nd. Real companies just don't attract people like that - not even google or apple.
Seeing the good things that another company does is helpful.
At one company, we had programming standards that were created by all the teams using each specific language. There were fights, but eventually, after a few months, everyone started to love that the code was written in a way to force errors to be found at compile-time, not run-time. Learned those techniques at my first job and was able to convince the rest of the team that it would be helpful. Coding standards became a training tool for new people joining the team because we explained WHY a specific standard existed.
Most importantly, we had a method for everyone to get any standard change considered. Some of the new guys would bring in great ideas that we adopted. Everyone coded a little better all the time. Over a few years, the problems were reduced, fewer bugs found by QA, and clients were always getting better quality code.
You know, the opposite of what MSFT does since Win8.1 was released.
Employers hate when good employees leave, it’s not only expensive brining on new employees, they know that they lost an employee that knew the ropes, and are getting another new hire.
And this is not just about programers, it’s all professions, and all fields of employment.
The Boss’s have all types of tricks to keep you working for them, bonus, profit sharing, office perks, and at times promoting views of thought that might make us feel like we are losing skills or productivity if we switch jobs.
I developed what became EFI
You utter utter bastard! ;)
Nazi faggot Ken Doll blathering his INCEL nazi faggot's propaganda on slashdot again..
"Productivity is higher in areas with more churn. Job hopping means new ideas and better techniques spread quickly between companies." - You love to pull shit out of your ass and call it Gospel, but it's not. It's unsubstantiated bullshit, Bill.
These comments are being posted by Alexander Peter Kowalski. I've encouraged him to seek mental health treatment before, which he angrily resists. Let's hope he gets the help he needs this time, because he's been doing this for over two weeks now.
Polymath maxim: anyone who calls themselves a polymath isn't.
Typical polymaths are shysters and frauds that know enough to fool anyone not as knowledgeable as they are.
Just one example, "and in 1998 I developed what became EFI." The Intel Boot Initiative program, which develped EFI, started in 1998 as a working group. No one person can legitimately make the claim that "I developed what became EFI." The group that actually did so, was formed and started working in 1998. EFI was not developed sufficiently to actually boot a machine in 1998. The claim is a lie which can plausibly be passed off as truth if you don't know the details.
Many of the claims can be correlated to show that no one person exists which worked on all of them. No evidence, no name, some vague statements, lots of bluster. Typical "polymath."
Lots of contractors switch jobs all the time. I've been doing it for 20 years. I've never had anyone say I wasn't good. In fact every place I've done work has said I'm better than anyone they have ever seen.
So if switching jobs makes me worse yet I'm still better than 99%, then if I stuck with a job I would be Master of the Universe!
Just one example, "and in 1998 I developed what became EFI." The Intel Boot Initiative program, which develped EFI, started in 1998 as a working group. No one person can legitimately make the claim that "I developed what became EFI." The group that actually did so, was formed and started working in 1998. EFI was not developed sufficiently to actually boot a machine in 1998. The claim is a lie which can plausibly be passed off as truth if you don't know the details.
I don't disagree with all of what you say, but I have a counterpoint here. I work in the auto industry. Committees on top of committees. Sometimes it feels like a 60 person committee grinds through creating a spec that basically aligns with a working proof of concept developed by 5-10 people. If you're one of those 5-10 people, it's easy to roll your eyes when the committee says they developed the tech.
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.
... I think this can be generalized to say that you'll be a worse <fill-in-the-blank> for a time when you switch jobs, for the same reasons described in the intro.
CUR ALLOC 20195.....5804M
This has been a long-running debate among developers. The consensus seems to average about 3 to 4 years. Too short and you get a reputation as a jumper, so you get skipped over by HR. Staying too long reduces the number of different ideas and organizations you get experience with.
If it's a great org, maybe stay longer than 3 years, and if it's a crap-farm, shorter.
Table-ized A.I.
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
Your salary will go up with each change
You will meet new people and expand your professional network
You will see new ways of doing things
You will see a lot of broken stuff too
You will take on new challenges
You will learn new technologies
Or stay put and become an underpaid fossil in no time, afraid to change jobs for fear of looking incompetent or of having your incompetence discovered.
And then when your company goes under you or lays you off will have no network to reach out to and no experience at interviewing.
Every time I changed jobs, did I have a better job, or a worse job?
Every decade, the standards of excellence and professionalism in the IT industry in the USA has gone down hill, because corporations and governments have been willing to invest less and less intellectual capital at home in the USA. We now live in the gig economy, and Joe Liemandt is the exemplar of that economy. We ship our intellectual capital overseas, and as a result, the quality of software coming from major corporations, like Microsoft and Apple, suffers as a result.
The biggest innovation in software in the past 5 years has been in neural networks. But the leaders in that area were trained in Canada, and they made their break throughs in the United Kingdom. The USA has not lead the way in that effort.
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.
Switching jobs means that some domain knowledge becomes obsolete but you do not change the type of programmer that you are. I've worked in many places and in 6-7 different domains, most of those in non-business logic roles. In each role I've worked with customers, functional developers, architecture developers, QA, and documentation. What I have found in switching jobs/roles is that things generally do not change, new job -> same crap. I remember one job, it sure seemed like it was going to be fun. Next thing I know I'm learning about factories, not a bad thing, until you realize that somebody decided that if one factory was good then if everything had a factory it must be better. :) Each job comes with a pile of code/architecture/infrastructure that started out as somebody's "Great New Idea" that more or less turned into the same pile as the last pile.
As you move along the programming spectrum eventually you reach a point where you realize that learning each new thing in detail is not necessary since all new languages are variations of older languages(*), all frameworks are variations of older frameworks, and remember that no one takes responsibility for what they write (except perhaps djb). The thing to remember is that the stuff we work with was written by humans, humans tend to think along similar lines, human code piles tend to smell the same.
(*) Except prolog, I think that was written by aliens.
you need to replace a wide body of experiences that became irrelevant when you turned in your notice at the old job
You're doing it wrong. One of the characteristics of Abstract Reasoning is the ability to transfer experience from one domain to another. Because... you know... you learn abstractly instead of concretely? There's a reason intellectual domains have a 4 magnitude difference in time to master.
and in 1998 I developed what became EFI (BIOS replacement)
That was your sign to step back a bit :)
... often think like this. They don't know the domain well enough to do something new, so they burrow into an existing application, then wilfully confuse "skill" and "specific knowledge of the application oddities and convoluted build", allowing them to churn out the most crap solution possible for any given requirement because "deadlines".
You may be temporarily less productive than you might have been at your last job, but no more so than anyone else would be that is starting a new job in a new place with different people.
But that doesn't make you a worse programmer, it makes you better. You certainly don't become any *less* competent at what you can do, but even being great at your last job doesn't automatically mean you will instantly know everything there is to know about someplace completely new. Learning new things takes time, and absolutely any remotely decent employer is going to know that and expect that your productivity may be below that of others in the company who have been there a while for the first few weeks.
File under 'M' for 'Manic ranting'
Most developers don't switch jobs because their employer is going out of business
Isn't that the definition of a startup? Not all of them succeed, but the failure is hardly on any single individual. At worst, any engineer's worst fault is idealism -- it's management that tends to be deceptive. On the other end of the spectrum, you find a bunch of people using VB to pull SQL queries into Excel spreadsheets that have been there for decades -- but they pay well because no one in their right mind would ever tolerate such a system.
If you have any tips on finding a Goldilocks zone please share:)
-- Political fascism requires a Fuhrer.
To get really good at something, you need 10.000 hours practice.
Getting too comfortable in a role is probably worse. It means you become afraid of leaving and having to ramp up knowledge. You loose the ability and desire to take on new things. So in an ideal world you need a balance. In practice when you move depends more on how scarce jobs are and what the consequences to you personally of moving will be.
You interface with the outside world. That interface conveys many things, but unless you suffer brain damage, it cannot convey negative ability.
If what is meant is lower efficacy, that's different. Efficacy is always reduced with context switches.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
The same Silicon Valley where worker's real income has fallen by around 14% over the last 20 years ?
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."
I doubt he is even works in the field actually. One thing is for sure ... He thought he was being a clever troll. For example saying to Shanghai Bill, of whom I am no fan by any means, "for newbies like you." Combine that with the phrase "if you applied to my program" and I would say he is an ESL high school or college student who sucks at trolling.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Jobs switched programmers all the time.
Should work the other way around too.
Its a job market, if you're not swapping jobs, you aren't using the market and you're getting underpaid.
It's not about productivity, it not about scratching the itch its about maximising your return.
I like to solve problems and build things. There are lots of organisations which value my skills and that keeps me happy. While I've found that I enjoy working in research organisations more than accounting firms they've both paid me well in the time that I was there.
Your bosses will try to pay you as little as possible to do the job because that's their job, so do yourself a favour and make sure that your pay reflects your value.
isn't this about true for any type of job switching?
there is always some work-in time required before you're performing at maximum capacity.
On a long enough timeline, the survival rate for everyone drops to zero.
Switching jobs made me tired, and made me uninterested in programming on machine. Now I program only on paper. It made me a better human, which is the goal I fixed to me.
... that you learn something new.
I am in a constant state of having to learn something new in my current job. Chef, docker, new versions of Java, Angular ... constant change. Or new tools are constantly added by people who 'we used this over at my last company and it solved all of our problems. Even our farts smelled like licorice'. Even our own staff are constantly creating new 'standards' because some tool we use doesn't make their farts smell like licorice and they are too lazy or not creative enough to figure out how to do it. So they force everyone else to have to learn something new even if the old tool actually could do what they needed. The 'bright and shiny toy' affects far too many lazy and uncreative people in senior tech positions.
I've worked for over 13 companies in my career that spans 40 years. Every time I left, I left for a reason and found a company that didn't have that limit. In doing so, I learned new languages, new techniques, and new skills. I started out as a desk clerk but applied for a computer operator job when it opened. From there, I've held programming jobs in assembler, COBOL, C++, C# and now work mostly in Java and Javascript. My ability to learn new languages far surpasses most of my peers because now, it's just syntax. So learning Ruby for Chef was no big deal. My company still has COBOL, C++, and C# applications that I can contribute to when needed. My past jobs have given me opportunities to be a DBA and learn Oracle, Sybase, Informix, and SQL Server. I've also worked as Sun and HP sysadmin. There was even some telephony and network administration tossed in, as well as moving a data center.
My boss comes to me when there are difficult tasks that others can't resolve. With my full-stack knowledge, I can work on problems that might otherwise require a team of 3-4 people. My solutions look at all aspects of a system instead of just the one I know. I'm not afraid to pick up legacy code in any language and work through issues or convert it if needed.
And none of this required me to spend a dollar for college. Companies have this wonderful thing called 'tuition reimbursement'.
So, if you are a smart, capable person, NEVER be afraid to change jobs, always be willing to learn something new, and take advantage of every educational opportunities your employer provides.
The staff member that can wear more than one hat is the one kept during layoffs.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
You are a MORON. You should stay with your mommy and daddy. Changing your environment has proven to be too much for you and as we have been tortured by your stupidity it is clear that you can not learn anything. The basement is your life and video games are your best friend. Don't change a thing for your entire life and you will be just as happy as your are now.
That bitch-whore Karen couldn't code her way out of a wet paper bag. The only way she can keep a job for as long as 18 months is to sleep with her bosses or sexually extort them with threats of sexual harassment allegations and gender discrimination.
There. I said. We all know it's true.
Many other comments make the case that more diverse experience will make you better. And they are damn right.
However, what will really make you better a better programmer is having to fix your own code 15 years after you made it while having to keep it backwards compatible. The best programmers have that experience and write code knowing that they probably will be held responsible for it years in the future.
That's in sharp contrast with what some others here say; they have obtained a lot of experience by switching jobs often. People that do that may very well be the best programmer ever, but knowing they can just go work somewhere else next month will make them behave much less responsible w.r.t. the futureproofness of the code. They may know better, but acting accordingly is a different matter entirely.
0x or or snor perron?!
I started in a small Software/IT group of a non-software company, and I can clearly identify my own weaknesses that have resulted; I've learned a lot of bad habits from a team that has traditionally stayed pretty isolated from outside influence, with very few people coming and going over the years. I fully recognize that I should have started out doing contract work to get a good broad picture of how people do things. So yes if I found another job just like my current job, it would be a bad move, but if I had that broad knowledge of best practices gained by exposure to lots of different teams, I think that would benefit me anywhere I went.
I strongly disagree. I've switched jobs, and I've hired hundreds of developers, and the article missed the distinction between being a good programmer and being effective in the job. When a good developer switches jobs, they'll be temporarily less effective for a while as they learn how to work with the new team, tools, and code base. But that doesn't mean they're a 'worse programmer' - they are just as good as they were before - and as they learn how to work with the team, learn the new tools, and learn the new code base, they'll be just as good as they were. And because they've got a broader experience, they'll often make the team better, because they'll add new skills and techniques to the team. So, of course, there's a tradeoff that bringing in a new developer costs you time/effort/money in the short term that is a long-term benefit, but that's hardly a new observation. The Mythical Man Month https://en.wikipedia.org/wiki/... published in 1075 covered this thoroughly. I'm not sure the blog post added much to the discussion.
Enable 3D printed prosthetics!
Double edged sword. I've been in software development for over 3 decades. I stay current with latest technologies and trends, I tend to change jobs simply because someone I've worked for previously calls me up and says "hey, would you be interested in ...". I've been in management for quite some time but it is always in very hands-on roles.
I've worked at large and small companies. Turn over in small companies is often a result of either a) company doesn't make it or gets acquired b) bad managers c) lack of new things to do. Bad managers are bad manages, shutdowns or acquisitions are something the developers can't control, but for small focused companies often times there is a lack of opportunity to do something new and grow skills. These startup types that deliver are generally singularly focused.
Large companies have the problem with the 20 year experts. Too often they know nothing except "what we've always done". They are fat and happy working with tech that no one else uses, and they are the only ones that know it. Had a situation recently where I am, a 20+ veteran who is not in management was in an office, our building was running out of space as we are expanding and the office was needed. He said "take my office and I quit". The company hadn't bothered to spend resources on upgrading the tech he knew or training others, they just let "Bob" do his thing. They found him another "office" to keep him. I'm working to get the platforms migrated and the senior leadership is worried that might make him mad too. That is the problem with a company relying on 20 year veterans and not hiring new blood to learn from us grey hairs.
The kids (I use the word lovingly) are still looking for that niche that really excites them so they expect to be able to work on different things. The "Agile" culture so many companies try to embrace means short quick cycles, changing on the fly as needed, adopting the latest tech and "chasing the shiny objects". There is nothing wrong with that so penalizing them for moving every few years is a mistake on your part. But you also need stability in your organization so instead of letting your younger team members bail on the company offer them an opportunity to do something else instead. And don't let the grey hairs shoot down every suggestion the junior folks make. Ensure there is a mentorship program in place. Your grey hairs are looking at retirement now and you don't want to be caught without a bullpen when they go.
Learning new things doesn't make you a worse programmer. If they relate to programming, it makes you a better programmer.
If after a job switch, it becomes necessary to learn new things, because your new employer does things differently, then you may be less effective for a while, but you're not a worse programmer. You're in the process of getting even better.
It might be true when we are talking about programming.
But code doesn't exist in a vacuum. A web store front sells products, an ECU runs an engine, a video game entertains, a search engine is there for people to find what they need. And you won't be a good programmer unless you know about the job your code is going to accomplish. The store front requires knowledge about the products being sold, and the marketing behind it. The ECU requires some understanding of mechanical engineering, the video game requires understanding of game design and the search engine may involve linguistics.
And it takes time to get into something you might know nothing about. And chances are that your next job will be in a completely different field, so while you can capitalize on what you learned when it comes to programming, you are back to square one when it comes to understanding the context.
Programming is a whole life encompassing art. Not a cog in the machine productivity defined labor.
"Knowing everything doesn't help..."
Oh to work in a company that rewards long-term employees like this!
I currently work in the IT department of a UK university. Employees are classified into pay grades, and once a person reaches the top pay of any particular grade, there they stay until they either change jobs inside the university, or leave entirely. Around here, the peak grade for IT workers as opposed to managers is generally Grade 7; this has the unpleasant effect that as soon as people start hitting top of grade and becoming superstar workers, they depart for pastures greener to get more money. Those that stay either fossilise into a role, or switch to management. Ace techies rarely make good managers.
I switch programming jobs 3 times. The only thing it did was bring a huge increase in programming skill and ingenuity to my new company. Production problems were cured. There was never anything negative to me or my new company. This article is nothing more than intellectual BS, as far as I am concerned .
This crap about connections and mentors is bull.
The real reason is you need to learn a new code base and learn to work with it.
Learning code bases is 80% of the early work when introduced to a new project.
Essentially, in order to improve the machine, you need to learn how it currently works. This is not a trivial task.
That *is* the learning curve. Domain specifics, company processes, and standards, etc. If you thought learning to program was part of the learning curve when changing companies then you don't know what a learning curve is, and we are talking about *development*, not programming.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Stupid, shallow question.
Also means dragging along bad ideas and techniques.
In a sense. The first year or two at a new gig is mostly learning how things work at THIS company/role/department/etc. It's learning how the last set of people did it. This isn't just for programmers, it is for all tech jobs and likely all jobs. Yeah, it's a learning curve alright, how to fill out your timecard, who to talk to in order to get a vm, crap that in absolutely no way makes you better at anything other than being able to function.
Given the way companies think right now you don't really have much choice but don't delude yourself into thinking job hopping on the whole actually makes you better. A flexible and challenging work environment at the same job can give you a constant learning curve of actual useful growth and information. The enemy is not the job, the enemy is you and your innate desire to find and live in a comfort zone. We live on the internet, you don't need to switch jobs to find out how things work somewhere else anymore.
dude, don't provke him. he has over 300 kills and is trained in gorilla warfare.
Find the biggest, meanest Mofo and make them your bitch. If you're not an Alpha then you're just gonna get pushed around your whole life. Shiv the old top dog and establish your dominance on day numero uno or just be a beta like 95% of the weak willed people on this thread.
Define "sucks." This job hopping because thier job sucks routine is really symptom of one's misguided view of how most places view thier services. If you are pragmatic about the truth of the relationship you won't be so apt to become discouraged. As a side effect of that you will choose better employers if you clearly identify what you want and what they expect.
I object to power without constructive purpose. --Spock
I've no version 3.0++, I'd never post on hosts offtopic + gweihir KNEW u IMPERSONATE me https://it.slashdot.org/commen... c6gunner proves it https://linux.slashdot.org/com... & forgot to SUBMIT AC & used his registered 'lusrname' (he tried to mock me both BEFORE & after I FAIRLY challenged him to show he's done better work - he had ZERO).
I'd never "cry victim" to ne'er-do-wells (TROLLS, not all /.ers) either.
U EVEN HELPED ME https://science.slashdot.org/c... (& then realizing it you quit trying to make me look bad via what you thought were lies on hosts as "ME" IN YOUR IMPERSONATIONS of me e.g. https://tech.slashdot.org/comm... on speculative execution attack: Hosts PREVENT 'EM, joke's on you)
APK
P.S.=> 2nd to last link's KILLING U THAT U HELPED ME & got me to see if hosts stop portsmash/meltdown/spectre & yes - hosts WORK on 'em - U LOSE + FAIL a PORTFILTER TEST https://yro.slashdot.org/comme...
But climbed 20% over the last 15 years.
Hint: That story was cherry picked data.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
12 bosses in 15 years.
I was very reluctant to read TFA, in part because it was written by a "cloud architect", but also because the headline is such obvious clickbait. No, I do not lose my decades of experience coding when I switch jobs. My changing jobs every so often has actually improved my programming over the long-term because I've been exposed to a much wider array of tools, techniques, and programming styles... what I've learned best is the *practice* of programming, whatever language or tools are at hand. In fact, if changing jobs doesn't make you a better programmer, nothing will.
I do not have a signature
Perfect example: AME Accounting Software
I object to power without constructive purpose. --Spock
If all you have is a scalar hierarchy, rebasing tends to look like a short-term plunge.
It's true, we do tend to rank people by salary, as if expertise were a scalar commodity. I will agree at the job-change boundary, the scalar projection sucks more than ever before.
But it sucks all the time, if you're a deep thinker, so this isn't conceding much.
"I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the TannhÃuser Gate. All those moments will be lost in time, like tears in rain. Time to die. "
https://en.wikipedia.org/wiki/...
Comment removed based on user account deletion
APK
GO the fuck AWAY!
(Everybody sing along!)
APK
GO the fuck AWAY!
APK
GO the fuck AWAY!
APK
GO the fuck AWAY!
APK
GO the fuck AWAY!
Do you drink Dos Equis beer?
I worked for 100000+ companies and saw the same thing happen all the time. We were often actively forbidden to change anything not absolutely necessary (i.e. loud customer complaint). Long-term programmers was not the problem. I worked with many young programmers (nowadays, it's all of them), with people who just started, they make the same mistakes, create the same bad code. The worst is the eager know-it-all, with the newest buzzword. Drop everything and use X. And they do not even understand, what cost and benefit is. No knowledge of any theory behind. No real understanding. The long-term programmers at least have a chance to see, how the new technology fits in. If they have a saying in the cacophony of all those eager youngsters and newcomers. And if they are not too burnt-out to bother.