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
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).
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.
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.
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.
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.
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?
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.
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.)
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.
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.
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.
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 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.
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)
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
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.
... 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.
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 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!
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.
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.
And who, exactly, are you to tell someone they should shut up?
Amusing counterpoint to the number of experienced commenters here boasting about changing jobs "quite a bit".
Cite some, AC. Cite some.
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
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'
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
And if you had just kept up your shoddy practices and allowed more bugs your company would have been more profitable.
I object to power without constructive purpose. --Spock
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
Do you drink Dos Equis beer?