The article's way of using "ageism" in the lede, and their title, both seem odd, and seem to confuse the real issue of what I think what most people mean by "ageism".
There seems to be a substantial tech industry aversion to hiring developers in 40s (sometimes 30s) or older.
But if you suggest that developers in their 40s expect salary to keep growing without limit, that fuels hairtrigger resentment arguments about how those people are just greedy and unrealistic, and that that's the cause of any "ageism" they perceive.
That would be a diversion from legitimate issues of people getting their resumes illegally screened for age, interview tests targeted at people with CS101 fresh in mind, rejecting candidates for "culture fit" (not just over-20s, but women, certain ethnicities/racial backgrounds, unapproved sex/gender identification), etc.
I'm happy this is a thing in the US and wish Europe would copy this since in some Western European countries like Austria, having your birthday and photograph on your resume is mandatory making discrimination a piece of cake.
The idea of having to include a headshot with a job application is insane to me. Unless you are in a public-facing role, your appearances are virtually irrelevant, and the information can only be used to discriminate against you for nefarious reasons.
This seems especially bad in places like France where the government explicitly does not collect demographic information on things like race and ethnicity. It allows employers to screen people based on race, but the government cannot prove it.
Photos are another one in the US, with our wealth of diversity, yet ongoing history of biases and marginalizing.
I used to hear in the US that some companies' HR had policies of discarding all resumes with photos or certain other details, to reduce risk of the company appearing to discriminate on basis of ethnicity or family status, for example. Perhaps apocryphal, but I always heard not to include a photo.
And we heard of studies in which resumes with nothing changed but the name, to a "black" one or a female one, were treated differently.
But then the most popular US resume Web sites introduced photos, to appear alongside your resume and your messages.
People expect their salary to go up for a number of reasons, but the major factors are inflation and cost-of-living. If your salary is not going up by at least a certain percent a year, you are likely stagnating or losing income.
Another reason people expect their salary to go up is because it is a basic expectation that has existed for decades, and one upon which the supposed fairness of the current market is predicated. The idea is that you start young, earn little, work your way up, and earn more. Life is _much_ more expensive the older you get.
> If your salary is not going up by at least a certain percent a year, you are likely stagnating or losing income.
That explains why income for the same person at differing times is correlated with age. It does not explain why income at the same time for different people is also correlated with age.
> Life is _much_ more expensive the older you get.
It's much more complicated than that. Cost of living goes down when you've paid off your student loans, down when you've paid off your mortgage. It goes up when you have children, up more when they enter college, sharply down again when they leave. About the only cost that consistently increases is health care, but insurance and other factors make that complicated too.
Also, we don't live in a world where people are paid according to their need, or where many people believe they should be. We live in a world where people are paid according to supply and demand (distorted somewhat by lingering neo-feudalism but close enough). People have to justify their salary based on what they produce, not what they require. Nobody expects their salary to go up based on the latter.
You're papering over all of the policy arguments that have been made over the past 30-50 years to convince people to give up pensions, unions, contracts, severance, etc., most of which boiled down to "not only will this new system be better for you, but it will be more efficient and cost less." Ignoring the consensus that is required in order for their to be any stability will lead you to conclusions like the ones you've just made.
With monopsony and other anti-competitive distortions being the name of the game in the labor market, using the "labor market" as a good indication of anything is also pretty useless. There is no labor market, for the most part, at least not in the sense that anybody means by "market."
By the way, the median first-time homebuyer in 2019 is 32 years old. With 30-year terms being the most popular, that means that they can expect to pay back their mortgage at about the same time they are paying a great deal more for medical insurance, life insurance, prescription drugs, medical treatments, etc. And if you think you stop paying for children when yours grow up, allow me to introduce you to the concept of "grandchildren."
> You're papering over all of the policy arguments
Calling them "policy arguments" is way too charitable, and I'm not papering over anything. The excuses are irrelevant. The fact is that student loans exist. Mortgages often get paid off way before 30 years (less than 10 in my case). Not everyone even gets a mortgage. Children grow up. Some don't even rely on their parents to support grandchildren, and we'll be coming back to that. Some people remain healthy later into life. Cost of living does not uniformly get "much more expensive" as people age. Your claim, so you prove it.
> monopsony and other anti-competitive distortions
Those are very serious problems and I even alluded to them before, but to claim they're so bad that the laws of supply and demand have become inoperative is inane. Not even worth engaging on.
> With 30-year terms being the most popular
When you talk about 30-year terms, you're papering over (a) people who rent instead of buying, (b), the 20% of home purchases without any mortgage, (c) mortgages for shorter terms, and (d) people who pay off early. Cherry-pick much? Then you ignore mortgage-interest deductions, make a ton of assumptions about older people's health, and treat insurance and medical costs as strictly additive without substitution effects. To top it all off, you assume substantial support for grandchildren. That's actually damn rare. Most of us manage to raise our kids to be self-sufficient and support their own kids. I'm sorry if you didn't, but that doesn't change the statistical reality.
The fact remains that salary based on need is not a thing for purposes of this discussion. There's no rational expectation that employers will, out of the goodness of their hearts, pay older workers more because they need it. The same employer who you claim have completely rigged the game and advanced bogus arguments to cheat workers out of pensions? Your argument isn't even consistent, let alone credible.
It's honestly hard to cut through the randomness of your data points and the bitchiness of your tone and judgments in order to discover an underlying argument.
No this is not ageism. After a certain point, if you are an individual contributor, your value is not worth more than someone with less experience.
A developer with 10 years of varied experience can usually do just as well as someone with 20 years of experience. I also believe that the idea of the 10x developer while not a myth, is so rare it’s not worth trying to find for most companies.
I speak as someone in my mid 40s who has been at this professionally for 20+ years [1].
I’m debating whether I want to take the next step of consulting or just stay in development. I see my salary hitting a ceiling in the next two or three years and I think I am okay with that.
[1] well for all intents and purposes maybe 12 years. I stagnated for a few years and became an “expert beginner”.
> your value is not worth more than someone with less experience.
I don't think such a general statement (even its direct inverse) can be true or even particularly useful. At a certain point you're playing the odds. We're dealing with X, what's the chance that someone has seen X before or can see a connection to something else? In those situations, 20 years of varied experience can be a lot more valuable than 10 years of varied experience, especially if the 20 includes areas or approaches that have been forgotten/ignored for most of the last 10. (You'd be surprised how often the ebb and flow of tech fashion produces such results.) Note that I said can. Whether that actually happens depends on the exact technology, what experts you already have, team size/cohesion, etc. "Is not" without qualification expresses a more absolute and certain opinion than is warranted.
Let's not forget the essence of why we get paid: you are paid because someone likes you. They like your work output, your social skills, or your status.
I'm not as hungry as a intern but I present well, and at the end of the day, thats why I get paid.
"In order to be successful, one must project an image of success at all times."
– Buddy Kane, American Beauty
I doubt many people know this explicitly, but I think the necessary behavior is intuitive to lots of people. I suspect people "on (or near) the spectrum", which is far more common in tech circles, get their ass handed to them career wise many times because of this, because they are in some sense looking at a different version of reality than other people.
Don't confuse the current shitshow that is VC flippable social software garbage with actual competence.
I worked with people at IBM and DEC at the point probably just at the peak of their heyday when the average experience was about 15 years.
Oh ... my ... God.
I have never had that kind of interaction again. Being able to just call up and talk to the folks who designed FPU algorithms, x86 emulators that smoked (I think the FX!32 guys knew more about x86 than AMD), BDD analyzers that actually matched circuitry to descriptions (NP-hard problems--solved every day), debugged CPU failures by having 3 old guys light up cigars, put their feet up and think real hard ... I can go on and on.
Yes, those big, sclerotic companies had lots of deadwood. But, there was a 25% that was amazing.
About once every couple of years now I bump into someone genuinely as good. It's really rare now.
> A developer with 10 years of varied experience can usually do just as well as someone with 20 years of experience
As a developer with 20 years experience ... I'm a lot better at what I do than I was ten years ago. Better at seeing how it relates to the business I'm working with, more productive in ways that are not just LoC.
I'd be OK if I can sustain my current income... but I'd still like to take the step to being more of a consultant. I'm dancing on the edges of it now, between contractor and consultant.
How much better? What are you doing now that you weren't doing 10 years ago that is a real game changer in terms of value?
As an architect/tech lead I'm much better than I was 5 years ago. I know how to manage engineering practices and when/how to apply them, better how to design a systems, and how to better manage relationships/politics so that I can leverage my experience into actual implementation and design.
But as an individual contributor I don't think I'm a whole lot more valuable unless it's in a domain I have deep experience in like real-time.
> What are you doing now that you weren't doing 10 years ago that is a real game changer in terms of value?
Technical leadership on teams of developers. Mentoring and enabling younger team members. Having more cogent ideas about tooling and delivery, having more well formed ideas about delivering the product my client needs, not prioritising doing things in technically interesting ways. Managing upwards/sideways when I encounter problems in product ownership and similar posts. Teasing out requirements where these are incomplete. A lot of things.
I'm also more confident in tackling larger problems, and understand more about the big picture, from kernel to front end.
Much of this is incremental, of course.
> But as an individual contributor I don't think I'm a whole lot more valuable unless it's in a domain I have deep experience in like real-time.
Are those things you mentioned not part of your individual contribution? They don't translate directly to LoC, but they likely to contribute directly to faster, simpler delivery of what the client needs.
Yeah most of the things you've mentioned you've gotten better are the things I've noticed too. On smaller team that I run or am in a sr. position it seems to make a big difference. But on larger teams(100+) where I'm just plugged in as staff augmentation it makes a smaller difference.
Sometimes your job is just transforming fairly well articulated requirements into code and on these I notice I haven't gotten a lot better than I was 4-5 years ago.
And that’s another line of reasoning I don’t believe.
I have a coworker who is probably 10 years younger than I am but has been working for the company for 7 years to my one, how could I better understand the business of the company than he does?
I worked for one company when I was 35 dealing with the complicated rules of the railroad industry. My manager was 28, but he was the founder of the company before it got acquired, built it from scratch and had 90% penetration in the particular market segment, how could I be more experience at how my code relates to the business - one he studied since he graduated from college?
You can always find examples that counter the generalization but don't necessarily make the generalization false. In general, a 40 year old is going to be better than a 25 year old in understanding how software is applicable to business simply because they have more experience. They have been in more business meetings and seen how their software applies. Does that mean a 25 year old can't be better than a 40 year old at that? Of course not.
It's not just one random counterexample. Knowing how code relates to a business has a lot more to do with how long you have been in that particular business or vertical than your general experience.
That 25 year old who was at the company since they started 3 years ago is going to know a lot more than that 40 year old who just came in yesterday.
Besides that, I did say 10+ years. The whole point is diminishing returns from experience.
There's more to this than understanding the business.
With 20 years of experience, I didn't write the bugs I did 10 years earlier. I produced better architectures. I produced more readable code. I could tackle more complex problems. I could help my coworkers more.
> I have a coworker who is probably 10 years younger than I am but has been working for the company for 7 years to my one, how could I better understand the business of the company than he does?
You probably don't understand the specific business domain better. That's not the claim. But you may better/faster understand the clients you have and how to meet their needs, how to interpret their requirements, spot the gaps in what they're asking for, etc
One explanation could be that having more experience in a wide variety of fields brings perspective that someone steeped deeply in the business, but with very little external breadth, has.
Not that I necessarily think that's true. Personally, I have yet to be convinced that it's possible to systematically measure developer productivity, making all of these comparisons pretty worthless except as "dorm room at 2am" type conversations.
"I also believe that the idea of the 10x developer while not a myth, is so rare it’s not worth trying to find for most companies"
The problem with the 10x myth is that it assumes a single dimension of productivity, and that no-one is ever negative so there's some sort of sensible, positive "minimum" to talk about.
Senior developer leads a team of three other medium-experience developer, and completes the project in six months. Junior developer leads a team of 5 other even more junior developers, after six months they've got nearly nothing, so we pull in another 4 semi-skilled developers and 2 contractors who are drowned under the mess and don't know what to do, and six months later, the project is cancelled entirely.
How many times better is the senior developer?
There's nothing even remotely skewed about those numbers, either. Both are totally realistic. And yes, senior engineer can fail, and junior engineer could succeed. (Although the range of projects where a junior can succeed and a senior can fail assuming adequate initial knowledgebase for both is fairly narrow; generally if you find one, you've probably got a strawmanned "senior" engineer who isn't actually senior but just a collection of stereotypes in your head.)
If you're still offended:
A generally senior software engineer who knows nothing about the domain and his team of three develop furiously for a year and eventually deliver the first iteration of what was asked for, with another year to go on the project to finish it. A generally software junior engineer who is deeply familiar with the problem domain listens to the customer's problem and after a day's thought realizes what they really need is a very different, but also much simpler, solution, which they deliver in two weeks by themselves. How many more times valuable is the latter?
(I've actually advised someone like that in the construction industry. They were switching into a programming career in their 40s. I said, look, there's no realistic chance you're going to outprogram me in a really academic, isolated sense of the term. But you've got contacts, the ability to pass the shit test with other people in your industry which I and/or generic software engineer have no chance of, and a deep understanding of the problem domain. Don't worry about trying to outprogram a 20-years-experienced software engineer, take advantage of the facts that you know what your customers really need, and... you're there! and I (standing in for generic software engineers) am not! Life's about playing what you're dealt, but people are generally dealt more cards than they realize, I think. Not necessarily better cards, but they have more cards than they think.)
I tend to agree there isn't a such thing as an engineer who is 10x more productive than another, in the sense that they will do the same thing as that other engineer, just 10 times faster. The key comes from doing things differently, most of the time.
There's other differences as well, such as being aware of the pitfalls. I recently got myself put in charge of a billing system, and as a senior engineer, I at least have the good sense to be suitably terrified, for instance. "Move fast and break things" has its place, but "careful, paranoid engineering" does too. Almost by definition, your really junior employees don't really know how to do the latter. (They'll often be able to cargo cult it, which can be a start, but they won't really understand it.)
My statement was referring specifically to an "individual contributor" and I said as much in the original post. If you are a team lead, by definition you aren't just an "individual contributor" and you're also not the "10x developer". Your increased effectiveness is because you have a team under you and you are a "force multiplier".
but "careful, paranoid engineering" does too. Almost by definition, your really junior employees don't really know how to do the latter. (They'll often be able to cargo cult it, which can be a start, but they won't really understand it.)
I also specifically said the difference between someone with 10 years of experience and someone with 20 years experience. If you have 10 years of experience -- you hopefully aren't a "really junior employee".
I've worked with a 10x developer. He wasn't a team lead because he wasn't interested in being a team lead and also probably wouldn't have been nearly as good at it as the person who was.
But man, was he ever transformative. Not only in terms of handling the most technically challenging tasks and solving the black-magic challenges that nobody else wanted to touch, knowing the C standard like the back of his hand, and getting things done quickly to a high standard of quality. He also was a force multiplier, because he would help others debug their problems when they got stuck and get them back on their feet and productive again, give advice for how to best handle various edge cases, and designed and maintained our tooling. He was a mentor to junior members of the team, and the team lead would ask his input and advice for how long things might take, what risks he could see causing delays, etc.
You can't plan around having someone like that but they make a world of difference if you're lucky enough to work alongside one.
I suppose I so deeply agreed with you I went total mental blindspot on the idea that someone could be a 20 years skilled software engineer and not be (technically, if not necessarily managerially) leading at least a small technical team. I'm not going to delete my post because I think it still has interesting stuff in it, but I do apologize for my tone of disagreement.
On that basis I’d consider the junior to actually be more senior, as understanding the need of the user and building that is vital to the role. A senior engineer who churns out code without taking that step to understand the domain and build the right thing is not, in my estimation, senior at all.
Bashing at something until it finally works is, to me, something we do as beginners when we’re still in the mindset of solving every problem with code.
You'd be very surprised then at how fast some people at companies bang out code with very little understanding of the problem, get it done fast, and look like heroes because it works. They then build up an expectation of getting things done fast because "time is money" and end up with a garbled mess of spaghetti code that functions.
Most senior developers that I know are so good at the above that very little communication is required about even the problem. So in reality, they end up sacrificing the team and becoming one man armies.
This goes on until retirement, and then a junior replaces them because they're cheaper and they're stuck with trying to learn a huge ball of code on their own, because teams became obsolete and documentation was an after-thought, that could have been done with a bit more effort on the senior developer to get out of their box and actually impart knowledge.
However, there is the opposite end of the spectrum where they write great code and could do everything themselves while still knowing crap about the problem domain. At that point though, does the PD really matter? Most people , including customers, just accept code results on their face anyways.
You'd be very surprised then at how fast some people at companies bang out code with very little understanding of the problem, get it done fast, and look like heroes because it works. They then build up an expectation of getting things done fast because "time is money" and end up with a garbled mess of spaghetti code that functions.
And honestly, experience tells you when that's okay. If you work for a venture backed company where the owners and founders only goal is to get something up and running to convince investors to give them money or to survive long enough to go public (statistically unlikely) or to get acquired, the goal isn't to make good code that can be maintained long term. They don't care if the whole business is built on a house of cards that will fall as soon as they get acquired.
Too many employees drink the kool-aid and think the owners are interested in anything else except for an exit strategy.
"Great code" rarely gets someone promoted or recognized.
In my experience in industry, the developers are seldom if ever allowed access to what the client actually wants. That's what the po or product manager/ba are for. This is the reason I have come to loathe software development.
> The problem with the 10x myth is that it assumes a single dimension of productivity...
There's another problem with "10x": people evolve.
No one starts their career as a 10x-er, juniors are not juniors forever and people take time to find their knowledge, preferences, the right context, employer, coworkers, etc, before they can even discover their "super-powers".
And anyway, all the people I've ever met who could be called "10x" would immediately reject that label and/or buffer it with generous praise of the team in which they work. They would also tell a LONG story of how they got to where they are-- hint: it never starts with being at the top of their game. Instead, it always starts with or involves a lucky-break or a hard situation made better by someone who believed in them.
I think the number of years in your post is off a bit. In San Francisco, you become a senior engineer within 2 years, and after 5 years you're either expected to go into management, or retire to southeast Asia with your IPO money.
Your summary is a bit outdated, I believe. While there is definitely a ceiling as the above poster added, the last decade has had a LOT of effort in improving options for non-management IC development. The big companies are realizing there is value in keeping strong technical people in technical roles.
You still have to improve your so-called "soft" skills, improving communication up and down the chain, and it does involve a reduction in actual coding time, but you end up more of a code manager than a person manager.
None of which says there isn't a struggle, but the world is very different than when I had a manager told me I could never expect a decent job if I stayed in coding.
Honest question: is this actually ageism or is it business cost-benefit analysis in action? You could argue that the benefit to the company of experience for a tech worker is only worth a maximum of X dollars. After that point, the company is better off hiring younger, cheaper employees with lower expectations than it is continuing to give raises, benefits, etc. to older workers.
I would expect a salary plateau to be a natural result of the above + supply and demand in the market. Maybe that’s what the term ageism has come to mean (not its original definition)?
That's not an unreasonable view, but there's a big problem with how people measure the value of experience. The value of a younger programmer's work is relatively easy to measure. Not quite lines of code, but something reasonably close to it. As one's focus shifts - e.g. organizing, mentoring others, guiding technology choices, flagging code that works now but will break next year - those results become harder to measure. Just because it's harder to measure doesn't mean it's less, but that's a common kind of error. Under-valuing the contributions typical of older workers vs. those typical of younger workers is still ageism, but of a less conscious sort. As with most kinds of discrimination, people don't usually discriminate in a direct way. They do it with their assumptions, priorities, and assignment of value which just happen to produce disparate (but "rational") outcomes.
Note: I'm not saying that older workers (I'm 54) deserve everything they get. There definitely are and have always been some older laurel-sitters whose friends pay them more than they should, and I was acutely aware of that when I myself was younger. I'm just saying "but they don't give proportional value" is often less true than people think.
I agree with you about the difference in the type of value older workers can bring to the table. Their roles can have a more cross-functional and broader impact. I don't think anyone would discount its value. (I'm in my 40s)
But another way to view this is through the lens of supply and demand. If there are over-supply of the roles that can only be filled by older workforce, then the pay will reflect that.
> If there are over-supply of the roles that can only be filled by older workforce
That's a pretty crucial question. Certainly at my age there really are fewer people. How true is that at 40? How unique is that "experience premium"? It seems impossible to evaluate the reality or prevalence of ageism without concrete answers (which I don't know either).
In almost all industries you start out doing low level technical stuff and then over time transition to working with people. An analyst at a management consultancy, a bank or a hedge fund spends his time looking at balance sheets or excel, whereas partners go to meetings and dinners with clients.
In a word, you make more money by transitioning from hard skills to soft, and since most developers are unwilling or unable to do this their salaries will plateau.
But compared to the financial industry, and probably law, developers can count themselves lucky. Those industries work on an “up or out” principle, sticking around for 20 years as an analyst simply isn’t an option, no matter how good you are.
Think you nailed it here. For example, in the consulting world you can pretty easily calculate the dollar value of employees at different levels based on the rates you can charge for them, the hours they bill, the new revenue they bring, and their compensation. That calculation tends to put a pretty hard limit on salaries for people not willing/able to make the transition to highly billable SME or partner-type business development/practice management.
In more traditional corporate roles, the compensation path is tied pretty heavily to growth in managerial skills and subject matter expertise in ways that don't always have parallels with software development. Even there, though, I've started seeing similar "ageism" as the article points out come into effect. Clients I've worked at have started coming to the realization that younger and more tech-savvy workers can often get to, say, 75% of the value of a 20-year employee for half the price in compensation.
I would argue the same thing does happen in other positions - salespeople usually cap out at some point or go into management (Though it can be a little odd since they have a commission portion usually. If you're really good, there's not really a cap, but functionally...). Surgeons and lawyers generally cap out unless they end up especially prestigious, but it's high enough that it mostly doesn't matter.
It's a bit different, since there actually is a fall-off with age in sports. A 45 year old basketball player is almost definitely more injured and less capable than a 20-year old. In most sports, you get better for the first 5-10 years being a pro and then it's all downhill from there.
Though, like tech, your trajectory at that point is usually management, analysis, or teaching.
The bigger issue for us Olds is that we have serious financial and family responsibilities that make us highly undesirable employees in today's modern "I've got mine! Fuck you!" society.
Imagine that you have a close family member with Stage 4 cancer. Who wants to have you on their team? Nobody, that's who. And you better be living in a jurisdiction with solid legal protections, or they will fire you in a hot second.
That is a far greater concern than salary stagnation.
Companies in general love people with obligations (kids, high mortgage etc.) because they're much more afraid of being fired, and thus are more obedient.
That hasn't been my experience, in particular when interviewing with managers and team leads younger than myself.
The last one slipped, and as much as admitted that he was concerned that I wouldn't be able to work as hard: he had presumed that I had children to take care of.
It used to piss me off, but now it's just discouraging.
Based on the findings I think it is premature to say this is ageism.
There are multiple other factors going on here:
1) As senior developers become more skilled there is a diminishing return in terms of compensation. This happens regardless of age. A developer with 40 years of experience is not really worth that much more than a developer with 30 years of experience.
2) As developers get nearer towards retirement there is less incentive for them to stay at the top of their field.
3) As developers get older they tend to want to find a place they enjoy working at rather than playing the salary game every 2 years.
1. There are diminishing returns to experience within software development, as you get more experience there are fewer and fewer companies that have any use for those extra years of experience.
2. The perceived value of that extra experience is even lower. How many recruiters or even engineering managers can honestly claim to be able to leverage the last 5 years of experience from someone with 20+ years?
3. In most industries your salary stagnates much earlier than that unless you transition to a management role, and I think it is safe to say that developers are much less keen on taking that step than say bankers.
I would amend this to say that time spent in a career represents a commodity that one can invest in oneself, and different folks invest that commodity in different ways and to different extents.
Some folks coast and fall into the category of "1 year of experience, 10 times in a row." Someone else gets more out of 2 years of working than the coasters get out of 10. In the worst case, you have a coaster who thinks they're actually in the second category.
A simple number for years of experience is very hard to interpret as a result. Take someone in the second category and give them 10 years of experience and you get someone amazing at their craft. But you have to be able to reliably discern this in the interviewing process.
And even if they are, transition into management is much harder. In my experience in the UK, in London at small to medium companies, I've never seen a promotion to management and only once seen promotion to senior developer. Developers are not seen as management material - and breaking out of the that perception is incredibly difficult.
I work with a lot of folks over 40, the two things I've seen that make me doubt ageism studies -- especially in tech, is that older engineers on average seem less likely to consider new technologies, and older engineers are more concerned about day to day stability and are less risk averse to consider another job which may pay higher because they have kids in school, mortgage, etc.
I have to disagree with this assertion. While my information is anecdotal I can attest to its veracity (I am 45 years old).
Over the last two months I have been arguing in a professional manner for my company to move towards .Net Core and React (away from older Framework code and Angular 1.x) Arguably neither of these technologies is super new, but they seem to be new enough that I've been getting push back over various concerns (often over learning something new). I have to say, on the whole most of the push back is from younger developers, many of whom are in their mid-thirties.
My point being that I don't believe that age is necessarily the deciding factor. In my experience most developers tend to lose some of their interest in the field at some point in their career and other do not. Everyone seems to hit that point at a different age, some of them quite young and others quite old.
I'm definitely risk averse but not averse to new technologies. ;-)
Ageism is the consequence of high birth rates. If many young people are available at low prices, why would you pay more for an older worker ? You can't have everything, have three children and then asking for a high salary. There are choices to be made in life.
I think generally current startup hiring discriminates in hiring for post vs pre internet age programmers and that could possibly account for the statistical differences in salary for developers that didn’t spend their entire careers under the current paradigm.
This is why you should always try and save at least 30% from every paycheck. Assuming you start working at 21, you should then have enough invested to live off the passive income by the time you reach 49.
> In Hired’s findings, tech pros were never offered more than $149,000 annually.
I don't know where they are getting their data but that's a lot lower than good developers of all ages make. You can see on https://levels.fyi that large tech companies will pay senior developers 200-400k routinely.
I don't necessarily doubt the analysis but the data is very incomplete if they didn't see a single offer over $150k.
Alternative reading: folks in Silicon Valley who've gotten used to FANG-level compensation have inadvertently developed a very skewed view of what average salaries in their industry are, because FANG compensation has climbed dramatically in the last decade. Anecdotally, $120 –130K was a reasonable mid-level engineering salary in the valley in 2009 (I had more than a few friends at that level, which I admittedly hadn't reached myself); if that wage had increased more in line with inflation, we'd expect it to be $145-160K in 2019 -- and that $120K would have been hard to match for tech talent in most other parts of the country a decade ago. (Not impossible, just not easy.) The soaring valuations of tech companies, especially in the Bay Area, led to a loop of equally soaring costs of living and frenzied talent competition which just hasn't been reflected in most other places in the country.
It does seem strange that they wouldn't see a single offer over $150K, but I wouldn't at all be surprised if the median level was considerably lower.
Keep in mind that cost of living is very high in the places where many of these jobs are located. For example, $120K in SF would be equivalent to $56K where I used to live in the Midwest.
(the data in the actual link you're responding to, with actual level information)
$120k/year is what I'd expect someone with 2-3 years experience to be making at Google as a base, with anywhere from $35k-$80k additional in signing bonus and stock offerings. "Senior Software Engineer" means different things at different companies, but to me it indicates someone who is expected to lead IC for a team, who has at least 5-7 years of experience building software.
source: work at FANG company, have had exactly that offer with that experience level
Seattle area also. And I've seen increasing numbers of remote offers that are close ($170k base was the most recent I saw), you could live in a cornfield for all they care.
It's not a difference of FANG vs. non-FANG, and not even necessarily of location, it's a difference of tech company (or trying-to-act-like a tech company, "tech-like") and not. A lot of words could be spent trying to define exactly what I mean by "tech company" and certainly some non-tech-companies might have tech sub-departments that are given enough autonomy to be sufficiently "tech-like". But mostly it's just a mindset. Tech companies are full of people who understand it's the tech workers who are responsible for the lion's share of the company's success, and so they're often run by technical people too. They understand it so well that some of them had to be sued in order for salaries to rise proportional to contribution again (even if still too low) since the socially low rung of individual contributors even at tech companies often fail to see it well enough to complain, which puts the sibling comment about 2009's "reasonable salary" in another light. (See https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_L...)
I can tell you that a lot of older companies in Seattle have not yet caught up with that change of conditions. Plenty of places are still 20% below that, and they aren't looking for junior people.
To get an offer at that level you would need to be quite good. For example you might have a couple decades of experience working on boot loaders, compilers, hypervisors, OS kernels, and similar things. You'd be comfortable working with assembly language.
There seems to be a substantial tech industry aversion to hiring developers in 40s (sometimes 30s) or older.
But if you suggest that developers in their 40s expect salary to keep growing without limit, that fuels hairtrigger resentment arguments about how those people are just greedy and unrealistic, and that that's the cause of any "ageism" they perceive.
That would be a diversion from legitimate issues of people getting their resumes illegally screened for age, interview tests targeted at people with CS101 fresh in mind, rejecting candidates for "culture fit" (not just over-20s, but women, certain ethnicities/racial backgrounds, unapproved sex/gender identification), etc.