Does Switching Jobs Make You a Worse Programmer? (forrestbrazeal.com) 227
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?
Struggle is growth (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:5, Interesting)
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 (Score:3, Insightful)
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.
Re: (Score:2)
Those people make just decent admins, terrible coders. Tend to 'retire in place'.
Re:Struggle is growth (Score:5, Interesting)
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.
Re: (Score:2)
Well, it varies based on if you're talking about some web blah with a narrow niche where they're only ever going to have one job for you to do, except for the one person who gets promoted to boss.
Like in the song "The New Media Caste System" from the soundtrack to the book NetSlaves.
But not all companies are like that.
Not sad - great! (Score:3)
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
Re: (Score:2)
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...
The good news is that you as the employer absolutely can do that.
You need to figure out why people leave jobs, or more specifically, why those people you want to keep would leave their current job, and make sure those needs are satisfied. Look at the common reasons:
Re: Struggle is growth (Score:3)
I've worked in a lot of big places. Politics and god complexes have been the two biggest problems, stagnation third.
The underlying problem is the Peter Principle, followed by the notion of the MBA, followed by the messy psychology of geeks.
Re: (Score:2)
It depends on the culture. My current employer is fairly large and successful, but very much has a startup mentality in that they keep resources lean and focused on delivering value to customers. And they've got a very low turnover rate - lots of 10-15 year employees in the mix, so there's strong institutional knowledge.
I've certainly been other places that weren't that way, of course, so I don't disagree with your generalization about big companies. But it doesn't always have to be that way. Some companies
Re: (Score:2)
So as the employer, that's a pretty shitty deal.
I agree, 3 years may be the best from the employee standpoint, but a bad deal from the employer. I'd be reluctant to hire someone who I see is changing jobs every 3 years. And I think about how it looks on my resume if I am changing jobs too often - that won't keep me in a really shitty job, but it does affect my actions in other circumstances. 5 years is a better average. Employers can keep me for even longer, especially if I am still learning a lot on the job and/or the money is great and the work environ
Re: Struggle is growth (Score:2)
Re: Struggle is growth (Score:2)
If code is designed correctly, there would be no learning curve at all. A given module would be covered by a specification and a comprehensive test system.
But it isn't. The learning curve exists because you have to dig for answers.
Re: Struggle is growth (Score:2)
Re: (Score:2)
Depends on the domain. We develop SDKs based on hundreds of specs for thousands of customers in almost as many different domains, and we have to be compatible with third party implementations that aren't spec compliant. I'm still learning stuff every day after six years. There's so much I've forgotten even from the decade preceeding that at other companies in related fields, and then had to relearn to teach the current developers who never had any exposure to specific issues. Sometimes I toy with the id
Still above average in balance (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Hmm... 2/3rds of the time you're not pulling your weight, or not pulling all of you weight. Some of us would prefer get closer to a 50-50 ratio.
Maybe in the third year they'd have taught you about low-pass filtering, and you'd have turned out to have been pulling your weight the whole time. Too bad for you, Mr Fiftypercent.
Re: (Score:2)
I suppose you were born knowing:
a) all the systems, languages etc the employer uses
b) the subject matter or domain
c) the company's internal structure, politics etc.
You must be Indian!
Re: (Score:2)
Finally, what the fucking hell is a cloud architect when it's at home, which I suspect it usually is?
A fisherman. Sometimes I even wear a floppy fishing hat while I type the client's name and project into the code generator.
Re: (Score:2)
My first thought was that it was some hipster fuckwad who's read ( or at least flipped through) Docker for Dummies.
Your idea has merit, though.
Re: (Score:2)
Re: (Score:2)
Does Switching Jobs Make You a Worse Programmer?
No . . . it makes y'all better programmers!
Your title: Struggle is growth . . . alt title:
“What doesn't kill you makes y'all stronger” -- Friedrich Nietzsche
Getting fresh blood and ideas in a project . . . or being the fresh blood . . . enables everyone to share, um, err, steal . . . ideas that work.
Hey, programmers are the poster children of evolution . . . we'll gladly adopt and accept anything that makes our lives easier.
Think of it like plantation slaves in the Old South of the USA . .
Re: Struggle is growth (Score:2)
What doesn't kill you has as much chance of making you weaker. Sun Tzu.
Re: (Score:2)
Re: (Score:2)
A person is not their job. Stop promoting that. (Score:5, Insightful)
A person is not their job. Stop promoting that.
Betteridge is actually appropriate here (Score:5, Insightful)
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: (Score:2)
I was that new team member once.
The knowledge I added was "subroutines" and a concept that I don't know the name of but it's along the lines of "if you have five programs that are 99% the same try having one with an IF/CASE statement in it somewhere".
Re: (Score:2)
Those both sound like specific instances of DRY [wikipedia.org]?
Re: (Score:2)
Reminds of the time when I had to introduce the concept of 'iteration' instead of 5 pages of X1=0; X2=0; X3=0...
Re: (Score:2)
Re: (Score:2)
Re:Betteridge is actually appropriate here (Score:5, Insightful)
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/... [wikipedia.org] 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.
Re: (Score:3)
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.
In my experience, it really depends on the individual. I've seen a lot of contractors over the years who are simply "coders for hire" and seem to have no interest in broadening their skill sets to become well-rounded developers. They are happy to collect a decent daily rate for a few months and move on when (or before) their limitations become apparent.
On the other hand I've known guys who have chosen various different jobs specifically to grow their skills in different areas, and become better professional
Re: (Score:2)
Re: (Score:2)
It seems counterintuitive only if you misunderstood the idea. It makes you temporarily worse on the basis of speed. By any other metric, you get better.
I'm registering my disdain for ignorant horseshit like this. We should not be reading headlines that are not supported by the article content, and we should not be reading garbage that misrepresents reality.
horsesh*t (Score:2)
Short answer (Score:2)
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
80% of your new job is domain knowledge (Score:5, Insightful)
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.
Re: (Score:3)
or maybe even optimize a SQL request (except they require that you go through sprocs and have an actual DBA sign off on it)
Actually that highlights one of the areas where I've found being new at a company improves productivity. Ignorance of the productivity-killing procedures like this can make you shine in front of your boss, until they are alerted about the procedure bypasses and send you for corrective training on internal procedures.
Re: (Score:2)
The problem with bypassing procedures like that is that you also have a higher risk of your change causing an issue, a disruption, or an outright problem. And if you work in a safety critical environment (say a power plant) or an environment subject to severe regulatory requirements (like a pharma plant) that would be bad.
I've worked in the space industry on ground station equipment, I've worked for a nuclear fuel processing plant, and currently work in a pharma plant. Other places were much looser, as you
Re: (Score:2)
You're not describing the domain knowledge I'm talking about.
I'm talking about things specific to a company. The gas account number for replacing tanks on the forklifts. Who sets up direct deposit for payroll. Things like "which customer needs to be coached to come up with good requirements," or "this is how we lay out our database tables so that our home-brew replication system works properly," are company domain knowledge. Hell, just getting credentials to check out and check in projects in source con
The most important thing to do at a new job (Score:5, Insightful)
Re:The most important thing to do at a new job (Score:5, Insightful)
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: (Score:2)
Unfortunately, office politics often overpowers this. One example among many:
Me: "We don't need microservices for the vast majority of our applications because the command structure of this organization is very hierarchical and don't prefer sharing services across groups over the longer term. If you tie them to another group, they'll get angry over dependencies that otherwise wouldn't be there. [Examples given relevant to the o
Re: The most important thing to do at a new job (Score:3)
Re: The most important thing to do at a new job (Score:2)
Re: (Score:2)
I say sometimes it can help the new team (Score:2)
Wrong Question? (Score:3)
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.
No (Score:5, Interesting)
Not at all - it makes you better (Score:2)
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 c
Congratulations for stating the obvious.. (Score:2)
Comment removed (Score:5, Interesting)
Re:Just the opposite for me (Score:4, Funny)
Was all this before you were a Navy Seal and a test pilot, or after?
No, just less desireable (Score:3)
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.)
Wrong way to think about it... (Score:2)
Long-term programmers can make for worse software. (Score:4, Insightful)
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'd say it's true but ... (Score:2)
... 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.
Yes and no (Score:3)
Re: (Score:2)
I think you're over estimating it the amount of change that really happens. Sure, if you're working with an emerging language (e.g. javascript today, ruby 10-years ago) then there is a lot of flux in libraries and tools, however if you're working with a mature language (Java, C++, etc) then the world is pretty stable.
Re: (Score:2)
Switch jobs early and often (Score:2)
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 intervie
Re: (Score:2)
NEVER stay just because you are loyal to a company/team.
also if you changed jobs and still feel like a nubie after 1 year because the project is shit or undocumented or a complicated mess of historically made errors, consider leaving.
Absolutely not. (Score:2)
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
For once Betteridge is wrong (Score:2)
To get really good at something, you need 10.000 hours practice.
No (Score:2)
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.
Income - Swapping Jobs Maximises you Income (Score:2)
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
programmers? (Score:2)
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.
Yes .. heaven forbid ... (Score:2)
... 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
It depends (Score:2)
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 sw
Bizarre logic (Score:2)
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.
Does switching bands make you a worse musician? (Score:2)
Programming is a whole life encompassing art. Not a cog in the machine productivity defined labor.
No (Score:2)
Of course it is true (Score:2)
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
Re:A senseless question. (Score:5, Interesting)
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.
Re: (Score:3, Insightful)
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 t
Re: A senseless question. (Score:5, Insightful)
Re: (Score:3)
And if they leave as soon as they become useful he's probably treating them badly, underpaying them, or both.
Re: A senseless question. (Score:2)
Re: (Score:2)
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 require
Re: A senseless question. (Score:2)
Re:A senseless question. (Score:4, Informative)
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 [ilo.org]
2. Go for the Churn [economist.com]
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.
Re: (Score:2)
But climbed 20% over the last 15 years.
Hint: That story was cherry picked data.
Re: (Score:2)
Re: (Score:2)
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 wo
Re: (Score:2)
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 tole
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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 th
Re: (Score:2)
Re: Companies are Bad - Jobs are Bad (Score:2)
I have worked for ex AMZ employees in other companies that left due to a lack of advancement opportunities. I have interviewed multiple AMZ employees lokking for jobs that offer more money, different experience from their pigeon holed responsibilities, and have hired a few w
During a directorship. The idea that AMZ is a good place to work is always touted by overpaid middle management or green job seekerswho never left. Theres a very large number of working programmers, terrified of having to reprove themsel
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)