Silicon Valley’s Dark Secret: It’s All About Age (2010)(techcrunch.com)
techcrunch.com
Silicon Valley’s Dark Secret: It’s All About Age (2010)
http://techcrunch.com/2010/08/28/silicon-valley%E2%80%99s-dark-secret-it%E2%80%99s-all-about-age/
120 comments
Yikes. This needs to called out.
They also offer bonuses tied to product releases. Seems like that will create some perverse incentives.
They also offer bonuses tied to product releases. Seems like that will create some perverse incentives.
For what it's worth, I'm 31 and read that as "the team hasn't been around very long", not "the team is composed of 20-somethings".
While that's a fair reading, click on "Company" and you'll see they've been around for 15 years. And most people who would work for them (primarily Java developers) are aware of this.
Why would that be worth advertising? "Come join us, we have no idea what we're doing here, but we run a legacy product?"
Again, my own filters in play - but I prefer to be a part of a young team because it means I have a much greater ability to impact the growth and direction of the product. It also means that the team's culture isn't as concrete, and I'm more likely to be able to fit in to it socially.
Insane. This issue is unfortunately what gets me so down about the diversity efforts happening today. We seek to empower a new group of people, more broadly representative of humanity's rich spectrum, to be unhireable at 45.
Maybe this is just my bias as an anarcho-capitalist, but I don't think it's an issue.
If we come to a place where there are scads of older-than-are-hireable-in-Silicon-Valley developers out there, then companies will hire them because they will be willing to work for less than their younger colleagues due to the glut in supply. Those companies will then be able to produce their products more cheaply, and the "young" companies won't be able to compete. Obviously this is an oversimplification, but the premise holds.
According to TFA, the salaries for college grads tend to slow their growth over time, eventually contracting as workers near retirement age. That fits very well with my experience - in my 20s I was focused on developing skills and getting paid more. My family was growing and I had a never-ending supply of energy and a deep well of enthusiasm and motviation to keep me going. I'm now in th early 30s, and feel like I'm established in my career. I've made one cross-country move and have proven myself in a startup environment.
I see a big difference between myself (at 31, married, with two children) and my colleagues (generally early- or mid-20s, single, no children) - I'm nowhere near as tolerant of long days and crunch times. I'm more than willing to work hard and make it happen when the situation warrants it, but I'm not willing to put in 60+ hour weeks indefinitely, and around the third release cycle that results in 12-hour days on the weekend to meet the deadline I lose patience with it.
I don't see myself as valuable because of my ability to stay late, or even to crank out code at a rapid pace. I see myself as valuable because I'm at the point in my career where I am beginning to be able to predict when a "crunch time" is going to happen a couple of weeks in advance. I can use that foresight to organize a late-night hack session or maybe a mid-day sprint before the crunch happens - so that when many of our other developers are highly stressed and trying to make last-minute changes to meet deadlines, I tend to either have my things done or I have gone back to the people who make the decisions and gotten approval for a revised release timeline or feature set.
If we come to a place where there are scads of older-than-are-hireable-in-Silicon-Valley developers out there, then companies will hire them because they will be willing to work for less than their younger colleagues due to the glut in supply. Those companies will then be able to produce their products more cheaply, and the "young" companies won't be able to compete. Obviously this is an oversimplification, but the premise holds.
According to TFA, the salaries for college grads tend to slow their growth over time, eventually contracting as workers near retirement age. That fits very well with my experience - in my 20s I was focused on developing skills and getting paid more. My family was growing and I had a never-ending supply of energy and a deep well of enthusiasm and motviation to keep me going. I'm now in th early 30s, and feel like I'm established in my career. I've made one cross-country move and have proven myself in a startup environment.
I see a big difference between myself (at 31, married, with two children) and my colleagues (generally early- or mid-20s, single, no children) - I'm nowhere near as tolerant of long days and crunch times. I'm more than willing to work hard and make it happen when the situation warrants it, but I'm not willing to put in 60+ hour weeks indefinitely, and around the third release cycle that results in 12-hour days on the weekend to meet the deadline I lose patience with it.
I don't see myself as valuable because of my ability to stay late, or even to crank out code at a rapid pace. I see myself as valuable because I'm at the point in my career where I am beginning to be able to predict when a "crunch time" is going to happen a couple of weeks in advance. I can use that foresight to organize a late-night hack session or maybe a mid-day sprint before the crunch happens - so that when many of our other developers are highly stressed and trying to make last-minute changes to meet deadlines, I tend to either have my things done or I have gone back to the people who make the decisions and gotten approval for a revised release timeline or feature set.
TBH, given the fact that age has no impact on decisions when people join (and quite apparent given the range of ages we have at JetBrains) I'm not even sure why this is on there. I'll inquire into it.
I contacted them about this and it looks like they changed it.
Last year I went to a talk by VC Mark Suster.[1] He addressed age discrimination and how he doesn't participate in it and is actively against it. Why do other VC's do this?
It’s their goal: a billion dollar company. That takes 8-11 years to build, going at a full startup pace. A lot of life changes can happen in that time. You sure aren’t getting more energetic as the years go by. Your personal and financial responsibility is probably increasing over time. While he isn’t an ageist, he does say that the earlier you can do this, the better.
That explains VC's and startups active age discrimination. For non-startups, it seems more centered around a salary cap that is unattractive to experienced engineers. (Not to say that ageism doesn't exist there, and for the record, I am "plus-aged" myself.)
1. http://philip.yurchuk.com/career/mark-suster-talks-startups-...
It’s their goal: a billion dollar company. That takes 8-11 years to build, going at a full startup pace. A lot of life changes can happen in that time. You sure aren’t getting more energetic as the years go by. Your personal and financial responsibility is probably increasing over time. While he isn’t an ageist, he does say that the earlier you can do this, the better.
That explains VC's and startups active age discrimination. For non-startups, it seems more centered around a salary cap that is unattractive to experienced engineers. (Not to say that ageism doesn't exist there, and for the record, I am "plus-aged" myself.)
1. http://philip.yurchuk.com/career/mark-suster-talks-startups-...
silicon valley is plenty of dark or plain bad stuff
https://michaelochurch.wordpress.com/2014/11/05/the-back-cha...
I am an outsider, but this is true for pretty much anything in life. There is a always a "dark side" to things. Finger pointing SV as being the mother of all evils is a bit naive.
"The grass is always greener..." :)
"The grass is always greener..." :)
This topic keeps coming up. I think someone should start a community for older coders. A place to brainstorm and help each other out.
Edit: SilverFox (and Foxess)
Edit: SilverFox (and Foxess)
Is it really because they're old? Or because they've established they are one trick ponies?
I've met young programmers who I wouldn't hire (were it up to me) for the exact same reasons most people wouldn't hire the stereotypical old programmer. 'Legacy' dudes from a time who seemed to understand bad code as a way to always retain a job because who else would understand the shit they do?
And then I've also met (and worked with) older programmers who taught me about the almost repetitive cycle of trendy functional languages, the types where I can literally have a two hour long philosophical conversation about design, extremely smart people I would hire.
I get the sense this is not entirely about ageism, but rather, the field itself has two different directions for growth.
I've met young programmers who I wouldn't hire (were it up to me) for the exact same reasons most people wouldn't hire the stereotypical old programmer. 'Legacy' dudes from a time who seemed to understand bad code as a way to always retain a job because who else would understand the shit they do?
And then I've also met (and worked with) older programmers who taught me about the almost repetitive cycle of trendy functional languages, the types where I can literally have a two hour long philosophical conversation about design, extremely smart people I would hire.
I get the sense this is not entirely about ageism, but rather, the field itself has two different directions for growth.
>almost repetitive cycle of trendy functional languages
This is interesting, please tell me more.
This is interesting, please tell me more.
I don't think this is much of a secret.
I wonder if there's a difference between the SF Bay Area and the rest of the country, as far as ageism is concerned in tech.
It's the reverse in a lot of places. It's common in the Baltimore / Washington area to base salaries on years of experience, education level, and industry certifications. I've applied for jobs where the first question HR asks is do you have at least 10 years of experience. These jobs pay as good or better in absolute $ terms than any salary range I've ever seen for engineers in the valley and if you look at it from a cost of living adjusted value the valley pays a lot less.
My two cents is that preferring young employees has a lot to do with the fact that they will work for a lot less money and put up with housing situations that more mature people wouldn't tolerate.
My two cents is that preferring young employees has a lot to do with the fact that they will work for a lot less money and put up with housing situations that more mature people wouldn't tolerate.
There was a recent article in the Chicago Tribune about bringing dogs to work with the following quote:
"What we're trying to create here, it's lofty, open, we bring in lunch, we hire younger people. Part of creating the vibe is not just the space but the amenities. Bring in your dog."
http://www.chicagotribune.com/lifestyles/pets/ct-pets-office...
No idea if that counts as ageism. Is it any worse than mentioning "recent graduate" or "0 - 2 years experience" in your job advertisement?
"What we're trying to create here, it's lofty, open, we bring in lunch, we hire younger people. Part of creating the vibe is not just the space but the amenities. Bring in your dog."
http://www.chicagotribune.com/lifestyles/pets/ct-pets-office...
No idea if that counts as ageism. Is it any worse than mentioning "recent graduate" or "0 - 2 years experience" in your job advertisement?
If so, the solution is quite simple: when the time comes, move the hell out of California.
How about 'the rest of the world'?
The "rest of the world" is probably happy to ride the hype the SF crowd are cooking. I know a bunch of companies here, who use python not because its a good choice, but its "hip" and they can appear cool and sophisticated.
Huge difference. CA companies and investors (e.g. YC) specifically require your age to the interviewers. Using YC as an example, many interviewers are happy to publicly boast about using age as primary factor - I can link to to some comments written here on HN.
In some other places, e.g. NYC, this is all generally believed to be highly legally-risky and no respectable employer would ever consider doing it.
Shame on you CA.
In some other places, e.g. NYC, this is all generally believed to be highly legally-risky and no respectable employer would ever consider doing it.
Shame on you CA.
I have never been asked my age for a job in the valley, and when I interview others any direction I get regarding age is always to not ask.
*source: 13 years of valley employment and performed dozens of interviews
*source: 13 years of valley employment and performed dozens of interviews
Can you provide some links (other than chatboard comments) to substantiate this claim that "CA companies and investors require your age"?
https://oag.ca.gov/publications/CRhandbook/ch2
https://oag.ca.gov/publications/CRhandbook/ch2
Are you implying that YC doesn't require your age in the interview process? Have you ever even filled out the application form? Let's start with that.
From https://www.themuse.com/advice/the-muses-successful-applicat...
For each founder, please list: YC username; name; age; year of graduation....
Wow, I wouldn't have expected them to be so blatant. Not illegal, since YC is not hiring people, but, wow.
For each founder, please list: YC username; name; age; year of graduation....
Wow, I wouldn't have expected them to be so blatant. Not illegal, since YC is not hiring people, but, wow.
Investors use age as a primary factor. Companies can't, for the reasons you described.
Don't worry, I'm sure the union has your back. What's that? No union in the tech industry?
Why do we need unions when it's so easy to start a company? There is no monopoly on means of production when it comes to software.
The fun part about unions: when you see your company has $200 billion cash in the bank, the union gets together and says "we made that. everyone deserves a raise."
If you're a programmer working at Apple or Google making less than ~$3 million per year (or any other large-scale, profitable firm), you're being taken advantage of.
If you're a programmer working at Apple or Google making less than ~$3 million per year (or any other large-scale, profitable firm), you're being taken advantage of.
I laugh heartily when management types say they want someone to be "more of a team player".
A team player-- that is, a unionist-- is the last thing that Silicon Valley investors and executives want.
A team player-- that is, a unionist-- is the last thing that Silicon Valley investors and executives want.
Sure would be nice to own my company's patent portfolio and to be able to rent it out to them.
I guess it is the same old fallacy that crept into some big software companies long time ago.
The fallacy is called "speed":
Some companies are just looking for young, smart people who can solve problems fast.
This fallacy has some correct side: Software development is most of the time about solving problems and when you can solve them faster, you will have the software faster.
The fallacy part is, that fast is the only quality you need.
With many, smart and young developers right of the college, you can create a huge pile of software in short time ... but you can also create a huge pile of problems in a short time. That is the reason, there are so many quality problems and security troubles around. Those young, smart people just lack the experience to make good design decisions ... and those decisions do not end, when the rough design is done.
Those people make fast decisions, but they just lack the experience to oversee the consequences of those decisions.
Without also having experienced developers around, which can share their experiences and guide other people, many companies are doomed to have bad quality software also in the future.
The fallacy is called "speed":
Some companies are just looking for young, smart people who can solve problems fast.
This fallacy has some correct side: Software development is most of the time about solving problems and when you can solve them faster, you will have the software faster.
The fallacy part is, that fast is the only quality you need.
With many, smart and young developers right of the college, you can create a huge pile of software in short time ... but you can also create a huge pile of problems in a short time. That is the reason, there are so many quality problems and security troubles around. Those young, smart people just lack the experience to make good design decisions ... and those decisions do not end, when the rough design is done.
Those people make fast decisions, but they just lack the experience to oversee the consequences of those decisions.
Without also having experienced developers around, which can share their experiences and guide other people, many companies are doomed to have bad quality software also in the future.
Some companies are just looking for young, smart people who can solve problems fast.
When your company only exists for 6-18 months before being acquired at $2 million per developer, it's worth getting the build-big-who-cares-about-correctness drones in your hand.
People with no experience have fewer reservations about being "led" a certain way or actually doing the wrong thing (because they may not have the real-world experience to say "nope, bad idea.") As a bonus, the uninitiated will probably believe well-spoken, optimistic lies about becoming a billion dollar company within a year, everybody gets a Tesla as a bonus next year, etc, to make them work harder for no tangible reward.
When your company only exists for 6-18 months before being acquired at $2 million per developer, it's worth getting the build-big-who-cares-about-correctness drones in your hand.
People with no experience have fewer reservations about being "led" a certain way or actually doing the wrong thing (because they may not have the real-world experience to say "nope, bad idea.") As a bonus, the uninitiated will probably believe well-spoken, optimistic lies about becoming a billion dollar company within a year, everybody gets a Tesla as a bonus next year, etc, to make them work harder for no tangible reward.
Let's see - you can get these experienced engineers, who will build a proper platform, a robust architecture, a decent code base, and given the fact they have delivered before, a solution that will provide what the customers want.
Or
You can have these wet behind the ears fuckers straight from college who will just download a metric shit ton of code via gem install and npm, and then rebuild several wheels in JS, whilst spending all their time on the company engineering blog wanking about how great they are?
And the vcs choose youth over experience every time.
Youth also doesn't ask complicated questions, like why is the VC getting 10% and I'm getting 0.05% when I'm doing 10% of the work and the VC 0.05%.
How is that complicated? Their game, their rules. You can start your own company and keep 100% of the profits -- your game, your rules.
Or move to a different company that values their engineers more and listen to the others bitch and moan about the "lack of talent".
In my mind, fair ownership is proportional to investment risk. Each owner invests some combination of time and capital.
I assume you are an employee, so how much risk are you taking on?
If you aren't already wealthy, and its a startup - which means you pretty much selling you life to the thing - than everything you have.
A VC might invest a million in ten different companies, but they often still have another 10 in traditional stocks to fall back on if all their ventures fail and they can continue to sit pretty. Their investment in the company is mathematically significantly larger than an employee, but that isn't how it feels when the business goes belly up. The VC writes off another failure, made another million somewhere else, and meanwhile the dev is distraught with blaming himself for basically his lifes work failing.
Yes, there can be role reversal there, it is not absolute, but it is the average. Just because some have and some have not does not mean someone can not put in a lot more of themself into a project. There are enough VCs that got rich off of being the developer that they probably recognize the difference.
And yes, that should hold weight when you only want to give the guy that makes the dream the reality .05% while a guy surfing waves after doing a VC round on a yacht providing the money to make it happen can expect incredible returns if the dream succeeds.
A VC might invest a million in ten different companies, but they often still have another 10 in traditional stocks to fall back on if all their ventures fail and they can continue to sit pretty. Their investment in the company is mathematically significantly larger than an employee, but that isn't how it feels when the business goes belly up. The VC writes off another failure, made another million somewhere else, and meanwhile the dev is distraught with blaming himself for basically his lifes work failing.
Yes, there can be role reversal there, it is not absolute, but it is the average. Just because some have and some have not does not mean someone can not put in a lot more of themself into a project. There are enough VCs that got rich off of being the developer that they probably recognize the difference.
And yes, that should hold weight when you only want to give the guy that makes the dream the reality .05% while a guy surfing waves after doing a VC round on a yacht providing the money to make it happen can expect incredible returns if the dream succeeds.
Those with the resources will always have more to lose than those without. This doesn't justify greater protections for them, especially when the reasons that have more are directly tied to the kinds of protections they have.
That's circular reasoning.
What you have to show is that those who are investing more money are making better decisions. Because we want to protect those who make the best decisions, not simply those who have the most invested.
That's circular reasoning.
What you have to show is that those who are investing more money are making better decisions. Because we want to protect those who make the best decisions, not simply those who have the most invested.
I think thats the point though. You have a couple of "leads" and "platform engineers" who make the structure of what needs to be, and then you hire a bunch of "coders" to actually turn that structure into a reality, and its great for the company, since they won't question the stack. Whereas, a more experience engineer, will have intelligent discussions about languages, frameworks and tradeoffs.
In other words, companies want stooges so that they can still keep running without addressing the ridiculous technical debt that they have accrued.
In other words, companies want stooges so that they can still keep running without addressing the ridiculous technical debt that they have accrued.
>And the vcs choose youth over experience every time.
With predictable results:
"A compelling report out from the Ewing Marion Kauffman Foundation describes how most institutional investors, including larger state pension funds, endowments and foundations, may be shortchanged by their investments in venture capital funds. "
"Over the past decade, public stock markets have outperformed the average venture capital fund and for 15 years, VC funds have failed to return to investors the significant amounts of cash invested, despite high-profile successes, including Google, Groupon and LinkedIn."
http://www.kauffman.org/what-we-do/research/2012/05/we-have-...
With predictable results:
"A compelling report out from the Ewing Marion Kauffman Foundation describes how most institutional investors, including larger state pension funds, endowments and foundations, may be shortchanged by their investments in venture capital funds. "
"Over the past decade, public stock markets have outperformed the average venture capital fund and for 15 years, VC funds have failed to return to investors the significant amounts of cash invested, despite high-profile successes, including Google, Groupon and LinkedIn."
http://www.kauffman.org/what-we-do/research/2012/05/we-have-...
Yeah, because all experienced engineers are perfect and all "wet behind the ears fuckers straight from college" are idiots... Well, Watts Humphrey, creator of CMM, PSP and TSP, had a nice saying along the lines of "Most developers who think they have 20 years of experience actually have 1 year of experience 20 times."
VCs choose youth because, as a previous poster said, single people in their 20s have a much greater tolerance for risk, can work very long hours without family commitments, and are much more likely to not have preconceived ways of thinking how things "are supposed" to be done. For example, Paul Graham has said a bunch of times how much he hated the idea for AirBnB originally, and how lots of smart people (mostly smart, older, rich people) thought it was a horrible idea. However, at the time, Couch Surfing was already well known and popular, so I don't think it's much of a stretch to see how this could be made safer/more convenient and turned into a marketplace. Younger people were more comfortable with the idea of a shared space, while most older folks just thought "Who's going to want to sleep in some stranger's house?"
VCs choose youth because, as a previous poster said, single people in their 20s have a much greater tolerance for risk, can work very long hours without family commitments, and are much more likely to not have preconceived ways of thinking how things "are supposed" to be done. For example, Paul Graham has said a bunch of times how much he hated the idea for AirBnB originally, and how lots of smart people (mostly smart, older, rich people) thought it was a horrible idea. However, at the time, Couch Surfing was already well known and popular, so I don't think it's much of a stretch to see how this could be made safer/more convenient and turned into a marketplace. Younger people were more comfortable with the idea of a shared space, while most older folks just thought "Who's going to want to sleep in some stranger's house?"
How is this a dark secret? This is true for almost all industries is it not? Most business want young hires because the work more (in quantity, not talking about quality here), and can be trained to fit the organization's needs.
No, in many industries experience is (or was) valued.
People businesses are generally worse though, look at law firms where the idea is to exploit the young, overwork them, and if they survive that offer them a tiny chance of the huge profits that senior partners share. Apparently this is supposed to be motivational.
People businesses are generally worse though, look at law firms where the idea is to exploit the young, overwork them, and if they survive that offer them a tiny chance of the huge profits that senior partners share. Apparently this is supposed to be motivational.
And engineering is an “up or out” profession: you either move up the ladder or face unemployment
Had to stop reading at this. Completely wrong. It's a move up or stay a programmer for 40 years career. You decide which appeals more to you. People forget that hiring and accessing talent is mostly done quite poorly. There are not many unemployed programmers and the reasons why they are unemployed could be many things.
Had to stop reading at this. Completely wrong. It's a move up or stay a programmer for 40 years career. You decide which appeals more to you. People forget that hiring and accessing talent is mostly done quite poorly. There are not many unemployed programmers and the reasons why they are unemployed could be many things.
The issue is really more practical: Young engineers can afford to take more risk, particularly if they are not married.
VCs want people who can go all in on an idea that looks like an obvious fail, because often enough, the young engineers who don't know better actually pull it off. These companies become high profile and their founders become famous for being young and wealthy. When VCs profile the successful investments, young, smart and driven all correlate.
Experienced engineers with families can seldom afford take those risks.
VCs want people who can go all in on an idea that looks like an obvious fail, because often enough, the young engineers who don't know better actually pull it off. These companies become high profile and their founders become famous for being young and wealthy. When VCs profile the successful investments, young, smart and driven all correlate.
Experienced engineers with families can seldom afford take those risks.
> When VCs profile the successful investments, young, smart and driven all correlate.
I would be very surprised if investments with old, smart, and driven people were correlated with failure. Considering the bias against age is so strong, I believe more than one person would have reveled in pointing that out already if the data remotely allowed for that conclusion.
> Experienced engineers with families can seldom afford take those risks.
There's a difference between what they say the reasons for discrimination are and what they actually are. There are plenty of young developers with families and plenty of old ones without (including myself) - it's not clear at all that having a family makes you less likely to get hired.
I think the primary reason why founders only hire young people is also the reason why employees are more likely to be white and male, and it's got nothing to do with malice per se. The reasons you hear against the hiring of people belonging to a certain group always sound similar, and that's because they're made up after the decision was already formed on an emotional level. The simple truth is that most people like to surround themselves with other people who are just like them. For an entrepreneur more often than not this means hiring the young.
I would be very surprised if investments with old, smart, and driven people were correlated with failure. Considering the bias against age is so strong, I believe more than one person would have reveled in pointing that out already if the data remotely allowed for that conclusion.
> Experienced engineers with families can seldom afford take those risks.
There's a difference between what they say the reasons for discrimination are and what they actually are. There are plenty of young developers with families and plenty of old ones without (including myself) - it's not clear at all that having a family makes you less likely to get hired.
I think the primary reason why founders only hire young people is also the reason why employees are more likely to be white and male, and it's got nothing to do with malice per se. The reasons you hear against the hiring of people belonging to a certain group always sound similar, and that's because they're made up after the decision was already formed on an emotional level. The simple truth is that most people like to surround themselves with other people who are just like them. For an entrepreneur more often than not this means hiring the young.
The simple truth is that most people like to surround themselves with other people who are just like them.
That fits with the frequent discussion/advice about how important it is to hire to fit the "culture" of a company, particularly a startup.
Reminds me of a funny moment at a previous job in a field office providing technical support for pre and post sales (us old timers have lots of stories, don't ya know). There were half a dozen field offices sprinkled around the country. Ours was by far the most diverse - two Iranians, two Chinese, an Indian, a Finn, a Latino, and about six white guys and girls. We were also the highest performing by a large margin. At an annual meeting of all the offices the manager of the Bay area office (consistently lower performing which baffled everyone since they were in the heart of Silicon Valley) talked about how they were working on performance improvement by recruiting candidates that would fit in well with their group (all young white guys). When our offices's turn came one of the technical leads, an Iranian guy, stated "our diversity is our strength". The whole Bay area team appeared totally deflated.
That fits with the frequent discussion/advice about how important it is to hire to fit the "culture" of a company, particularly a startup.
Reminds me of a funny moment at a previous job in a field office providing technical support for pre and post sales (us old timers have lots of stories, don't ya know). There were half a dozen field offices sprinkled around the country. Ours was by far the most diverse - two Iranians, two Chinese, an Indian, a Finn, a Latino, and about six white guys and girls. We were also the highest performing by a large margin. At an annual meeting of all the offices the manager of the Bay area office (consistently lower performing which baffled everyone since they were in the heart of Silicon Valley) talked about how they were working on performance improvement by recruiting candidates that would fit in well with their group (all young white guys). When our offices's turn came one of the technical leads, an Iranian guy, stated "our diversity is our strength". The whole Bay area team appeared totally deflated.
I think the single people can take more risk thing is a ridiculous trope that assumes marriage situations that are rare today (single income couple). A dual income married couple can tolerate more risk than a single person, for obvious reasons.
As someone in a 14 year DINK relationship, I totally disagree with this. When you are in a relationship, decisions need to be collaborative - you can't just chase any opportunity that comes along without thinking about how it will affect your partner. Also, when I was single, I could spend the vast majority of my time working. In a relationship, not only CAN'T I do that (my partner would kill me), but I don't want to; I'd rather spend more time on what is truly important - my personal relationships.
Even single people should be thinking through high risk decisions, so I don't really see your point there. A dual income couple has inherently more ability to make higher-risk decisions that have larger expected returns.
As for time spent working, I'm a bit skeptical of that. It's not like single people don't have socialization needs that need to be met. My single friends spend a lot of time and effort on dating and trying to arrange opportunities to see friends.
As for time spent working, I'm a bit skeptical of that. It's not like single people don't have socialization needs that need to be met. My single friends spend a lot of time and effort on dating and trying to arrange opportunities to see friends.
I think the point is that the decisions aren't as high-risk when you are single and don't have other people to support (especially children). The consequences of failure aren't as high.
Instead of being able to share a place with a few people (maybe even sharing a room) and sharing utilities, internet, cable and so on, you are paying significantly more for housing, food, utilities, transportation (bigger car), clothes and insurance/medical costs. Those costs could easily be 3-4 times as much as a single person.
If you are a dual income family, you may also be paying for child care and have the extra responsibilities of getting your children to and from child care and/or school (let alone actually spending some quality time with them). Working late has a much higher cost and being out of a job has much greater consequences.
Instead of being able to share a place with a few people (maybe even sharing a room) and sharing utilities, internet, cable and so on, you are paying significantly more for housing, food, utilities, transportation (bigger car), clothes and insurance/medical costs. Those costs could easily be 3-4 times as much as a single person.
If you are a dual income family, you may also be paying for child care and have the extra responsibilities of getting your children to and from child care and/or school (let alone actually spending some quality time with them). Working late has a much higher cost and being out of a job has much greater consequences.
My point is that these days, especially accounting for assortive mating, a married person is better seen as having someone to support him or her, not as needing to support someone else.
Your roommate isn't going to pay for your food and rent. Your spouse will. Moreover, old married people are much more likely to have assets to draw on if someone is unemployed than single people. And while they may have higher expenses, a lot of those (like child care) disappear when one person is unemployed.
Just looking at my friends, very few of my single friends could tolerate loosing their jobs as well as my married friends. That includes older couples I know with kids.
Your roommate isn't going to pay for your food and rent. Your spouse will. Moreover, old married people are much more likely to have assets to draw on if someone is unemployed than single people. And while they may have higher expenses, a lot of those (like child care) disappear when one person is unemployed.
Just looking at my friends, very few of my single friends could tolerate loosing their jobs as well as my married friends. That includes older couples I know with kids.
A dual income couple can tolerate more risk, but in my experience they are unwilling. After marriage, a couple's risk tolerance skews a lot closer to a woman's risk tolerance than to a man's.
> A dual income couple can tolerate more risk, but in my experience they are unwilling. After marriage, a couple's risk tolerance skews a lot closer to a woman's risk tolerance than to a man's.
How is someone's gender in any way relevant to their financial risk tolerance?
How is someone's gender in any way relevant to their financial risk tolerance?
The mechanisms are minimally known (it's believed to be linked to testosterone), but lower female risk tolerance is fairly well established. See this report and the sources it cites:
http://www.pnas.org/content/106/36/15268.full
And interestingly, this study was just posted here today, showing that testosterone levels fall in married men: http://www.ncbi.nlm.nih.gov/pubmed/13129483
http://www.pnas.org/content/106/36/15268.full
And interestingly, this study was just posted here today, showing that testosterone levels fall in married men: http://www.ncbi.nlm.nih.gov/pubmed/13129483
I think caution is advised at applying these studies broadly, as you are doing. Not only are they done on WEIRD populations, but a limited subset of that grouping.
We are discussing the career habits of WEIRD populations, right?
The same pattern holds anecdotally in many other cultures I'm familiar with (Indian, southern African). Do you have any anecdotes or other evidence suggesting women are equally or more risk averse than men?
The same pattern holds anecdotally in many other cultures I'm familiar with (Indian, southern African). Do you have any anecdotes or other evidence suggesting women are equally or more risk averse than men?
Anecdotes? Sure. My wife loves to trade options. I generally avoid them, except for buy-writes. Across investments, she enjoys taking higher risk positions than I.
I can't say that gender doesn't play a role, and it would make sense if gender were a factor, but I don't see how it could be anything close to a dominant factor.
I can't say that gender doesn't play a role, and it would make sense if gender were a factor, but I don't see how it could be anything close to a dominant factor.
By "anecdote", I meant "a culture or subgroup where women are reputed to be more risk taking than men", not "an individual example". No one disputes that individual examples can probably be found in any culture, and their existence doesn't contradict my claim.
...I don't see how it could be anything close to a dominant factor.
Suppose it were a dominant factor. How would the world be drastically different than it is today?
...I don't see how it could be anything close to a dominant factor.
Suppose it were a dominant factor. How would the world be drastically different than it is today?
Add dependents and things get more complicated.
I see a contradiction in this article:
"After 50, the mean salary of engineers was lower—by 17% for those with bachelors degrees, and by 14% for those with masters degrees and PhDs—than the salary of those younger than 50."
If 50 year old programmers are cheaper, why are they being discriminated against?
see here: https://news.ycombinator.com/item?id=9689232
"After 50, the mean salary of engineers was lower—by 17% for those with bachelors degrees, and by 14% for those with masters degrees and PhDs—than the salary of those younger than 50."
If 50 year old programmers are cheaper, why are they being discriminated against?
see here: https://news.ycombinator.com/item?id=9689232
"If 50 year old programmers are cheaper, why are they being discriminated against?"
There are lots of other ways to interpret this data. Looking at the graph, note that salaries are actually lower for 20 and 30 somethings that 50+. It's possible that a majority of really good software developers get out of programming by the time they are 50, meaning the overall quality (and salaries) for the oldest developers is lower than average.
There are lots of other ways to interpret this data. Looking at the graph, note that salaries are actually lower for 20 and 30 somethings that 50+. It's possible that a majority of really good software developers get out of programming by the time they are 50, meaning the overall quality (and salaries) for the oldest developers is lower than average.
Thats what this whole article is about. Older people usually have less ability to take a higher risk, due to family concerns, or other reasons. It is classic supply and demand. Younger programmers are more sought after, therefore demand higher pay.
I'm not "young" anymore and not "old" yet, but I'm quite saddened by this point of view: 'The young understand new technologies better than the old do, and are like a clean slate: they will rapidly learn the latest coding methods and techniques, and they don’t carry any “technology baggage”'. Software business seems mostly about exploitation of the naivety of the youngsters and less about software and programming.
I'm definitely old - going on 40 this year - and I don't recognize myself in that argument either. I think the reason why these points sound like they're made up is because they are, in fact, made up to justify something that's already been decided based on feeling.
31. The fact that 39 is "definitely old" is fucked up.
Age discrimination isn't about competence (programmers peak much later than 40) but control. It exists because the VC man-child oligarchy (oddly enough, software inherits the age-discrimination culture from business-culture colonists who'd be "too old" to write code) thinks that people will work harder if this shitty, artificial time pressure is put on them. And, of course, much of the ageism and sexism is unintentional but still exclusionary. See: open-plan offices and the aggressive micromanagement of Scrum. I don't think Scrum and open-plan were devised with ageism in mind, but they contribute massively to the attrition. As people get older, they have less tolerance for macho-subordinate bullshit.
This macho-subordinate culture that is imposed on software engineers needs to die. It drives out an incredible amount of talent, makes us an HR nightmare as far as diversity goes, and it has nothing to do with programming; in fact, it detracts from the quality of what is produced. We have to kill it at any cost and professionalize our industry because we can't trust our financial backers.
Age discrimination isn't about competence (programmers peak much later than 40) but control. It exists because the VC man-child oligarchy (oddly enough, software inherits the age-discrimination culture from business-culture colonists who'd be "too old" to write code) thinks that people will work harder if this shitty, artificial time pressure is put on them. And, of course, much of the ageism and sexism is unintentional but still exclusionary. See: open-plan offices and the aggressive micromanagement of Scrum. I don't think Scrum and open-plan were devised with ageism in mind, but they contribute massively to the attrition. As people get older, they have less tolerance for macho-subordinate bullshit.
This macho-subordinate culture that is imposed on software engineers needs to die. It drives out an incredible amount of talent, makes us an HR nightmare as far as diversity goes, and it has nothing to do with programming; in fact, it detracts from the quality of what is produced. We have to kill it at any cost and professionalize our industry because we can't trust our financial backers.
Don't know why you're being downvoted, because this is exactly true. Younger naive fresh graduates are much easier to exploit (or just force to stay in the office longer) than older, experienced people. That is why younger people are preferred.
I agree, I'm also 39. Force isn't obvious and actions are aimed at compliance which demonstrates perceived value. I've never seen myself as being on a "career path", everything in my life is a moving target. Engaged in a company's problems isn't why I woke up this morning.
I feel my age puts me in a unique place because I was lucky enough to grow up with computers as they matured. I have knowledge of the world before and after software ate it. What you call "technological baggage", I call wisdom.
yes, that part is unalloyed nonsense, a just-so story told by the nontechnical to justify ageism.
I've got 30 years of experience at this point, and as a result, I grasp new technology faster than most; and the baggage of my years of hard lessons learned is of great worth to my team, employees and employers. As one might expect with any thinking profession.
I've got 30 years of experience at this point, and as a result, I grasp new technology faster than most; and the baggage of my years of hard lessons learned is of great worth to my team, employees and employers. As one might expect with any thinking profession.
Yesterday: Finance ran the world and bankers still do.
Today: Software runs the world but developers do not.
Get the picture?
Get the picture?
>Software business seems mostly about exploitation of the naivety of the youngsters and less about software and programming.
That's not just the software business.
That's not just the software business.
To start a "modern" project today, you have to know programming languages, infrastructure, and packaging systems that didn't even exist five years ago.
That's the surface-level "technology" they (VCs) mean. VCs don't care about your deep algorithm knowledge or domain experience unless it can accelerate user-facing interfaces to the moon.
If you hire people with 30 years experience, do they know what a Gruntfile is? Do they know the difference between Gruntfile.js, component.json, and package.json? Do they know the relation between Docker and Vagrant and Kubernetes and CoreOS and rkt and etcd? Maybe they still love XML a little too much. Now they have to re-learn the same things they already knew, but with new fads and new syntax and new bugs built-in, all while trying to keep "old ways" vs "new ways" straight in their cluttered heads.
Even look a hyper-accelerated areas: Ember? Angular? React? React forks? Become an expert in any single one and you're irrelevant within 3 years unless you want to support "legacy" apps forever.
Saying "old" is confusing too. Is "old" 30 years COBOL experience at one company where they wrote everything themselves and can't think any other way? Is "old" 30 years of always chasing the latest fads, master of none?
If you have a long work history, and if you are good at something, there's a good chance soon the thing you're good at will be replaced by something you're not good at. Congratulations, now you are "old" and out of touch. Younger people created something new and now your experience isn't relevant. In a way, "experience" is a fool's game. Experience requires a fixed point of deep understanding, but while you're getting experience, the world is moving out from under you.
You're almost better starting off as a 15 year old who learns everything new with no historical baggage. Nobody wants to hear old stories about stacks of punchcards and time sharing woes when we've got to deploy and monitor 1,000 instances to AWS in the next 15 minutes. But, you can't go back and become a blank-slate 15 year old every 5 years when the fads change out from under you. Ergo, you're old and out of touch and worthless and go live on a programmer retirement farm in iowa because you're not a culture fit with the 22 year old CEOs anymore. yolo, and you wasted it by not becoming a billionaire by 28.
That's the surface-level "technology" they (VCs) mean. VCs don't care about your deep algorithm knowledge or domain experience unless it can accelerate user-facing interfaces to the moon.
If you hire people with 30 years experience, do they know what a Gruntfile is? Do they know the difference between Gruntfile.js, component.json, and package.json? Do they know the relation between Docker and Vagrant and Kubernetes and CoreOS and rkt and etcd? Maybe they still love XML a little too much. Now they have to re-learn the same things they already knew, but with new fads and new syntax and new bugs built-in, all while trying to keep "old ways" vs "new ways" straight in their cluttered heads.
Even look a hyper-accelerated areas: Ember? Angular? React? React forks? Become an expert in any single one and you're irrelevant within 3 years unless you want to support "legacy" apps forever.
Saying "old" is confusing too. Is "old" 30 years COBOL experience at one company where they wrote everything themselves and can't think any other way? Is "old" 30 years of always chasing the latest fads, master of none?
If you have a long work history, and if you are good at something, there's a good chance soon the thing you're good at will be replaced by something you're not good at. Congratulations, now you are "old" and out of touch. Younger people created something new and now your experience isn't relevant. In a way, "experience" is a fool's game. Experience requires a fixed point of deep understanding, but while you're getting experience, the world is moving out from under you.
You're almost better starting off as a 15 year old who learns everything new with no historical baggage. Nobody wants to hear old stories about stacks of punchcards and time sharing woes when we've got to deploy and monitor 1,000 instances to AWS in the next 15 minutes. But, you can't go back and become a blank-slate 15 year old every 5 years when the fads change out from under you. Ergo, you're old and out of touch and worthless and go live on a programmer retirement farm in iowa because you're not a culture fit with the 22 year old CEOs anymore. yolo, and you wasted it by not becoming a billionaire by 28.
I think this is a symptom of the fact that most SV startups aren't actually doing anything that's truly technically challenging. (Most startups read like social/marketing experiments that happen to need a web page). So they don't need to hire people with actual experience, and since the tech is largely disposable, fashion tends to rule.
That doesn't mean all programming is like that though. For instance, you know what I was using for graphics programming 15 years ago? C++ and OpenGL. You know I'm still using 15 years later? C++ and OpenGL. They've evolved a lot for sure, but that knowledge hasn't become irrelevant.
That doesn't mean all programming is like that though. For instance, you know what I was using for graphics programming 15 years ago? C++ and OpenGL. You know I'm still using 15 years later? C++ and OpenGL. They've evolved a lot for sure, but that knowledge hasn't become irrelevant.
OpenGL is a neat example because it's an abstracted physical interface, and the physical interface isn't drastically changing. It's like being the world's best assembly programmer — you're always going to be the best because the platform isn't going through 50 generations of evolution underneath you ever 3 years.
Carmack is a great example of experience+useful. So is notch. But, they are both very tied to hardware, algorithms, and physical implementations of things so they have stationary expert-level targets.
Carmack is a great example of experience+useful. So is notch. But, they are both very tied to hardware, algorithms, and physical implementations of things so they have stationary expert-level targets.
I get where you're coming from, but this should really be qualified by acknowledging that the overwhelming majority of software work is not "modern" by that definition and has nothing to do with any of those newer technologies. Most software products will never have to be deployed on 1,000 AWS instances. For example, I've never used a DevOps stack, a JS module loader or build manager, or an AWS instance in a professional setting. And if I didn't feel like researching those technologies on my own it would be totally fine as long as I didn't try to get hired as a DevOps guru or whatever.
I am using React/Flux a lot lately, but that is just one straightforward JS platform, and since in my opinion they absolutely nailed the "pit of success" it's no problem to learn it by making real applications.
I am using React/Flux a lot lately, but that is just one straightforward JS platform, and since in my opinion they absolutely nailed the "pit of success" it's no problem to learn it by making real applications.
Rampant proliferation of "new" also breaks the hiring process. Companies (i.e. "in-demand startups") want new stacks, and they want to hire people who are experts in everything that didn't exist 2-3 years ago (literally, 5 years experience with a 2 year old platform).
When that's the case, you're either a high school or college kid who can spend all their time learning new things, or you are old and learn new things a few hours a week, maybe nights and weekends.
You can't compete with someone learning (and iterating!) 40-60 hours a week when you yourself can't throw away all your 40-50 hour per week obligations and responsibilities just to keep up with them.
When that's the case, you're either a high school or college kid who can spend all their time learning new things, or you are old and learn new things a few hours a week, maybe nights and weekends.
You can't compete with someone learning (and iterating!) 40-60 hours a week when you yourself can't throw away all your 40-50 hour per week obligations and responsibilities just to keep up with them.
I'm going to go out on a limb and say the bigger problem with 40-50 hour per week obligations is that it doesn't leave you free to work 80 hour weeks.
A lot of startups really aren't doing anything that technically exceptional, but if you want someone to spend their evenings fixing bugs in your bog-standard Rails app, it's much easier to persuade the guy that spends them fixing bugs in bleeding edge javascript frameworks than the guy that spends them with his wife and kids.
A lot of startups really aren't doing anything that technically exceptional, but if you want someone to spend their evenings fixing bugs in your bog-standard Rails app, it's much easier to persuade the guy that spends them fixing bugs in bleeding edge javascript frameworks than the guy that spends them with his wife and kids.
What are you talking about? I'm 33 and I've thrown everything out and started over with new platforms, tools, libraries, and languages several times in my career so far. I haven't slowed down at all after getting married and having kids either... I've just gotten much better at recognizing dead ends early and not wasting time on stuff that doesn't matter.
This age trope seems to be from some early days when technology did move slower and people expected to spend their entire career working on the same technology. I've never had that expectation.
Anyone who thinks experience is worthless is an utter fool. My work hacking on an F# JavaScript compiler directly translated to doing massive CoW in-memory snapshots using immutable data structures in C#. My early work with SQL and transactions informed my approach to using atomic CMPEXCH to do optimistic in-memory commits, giving the entire app database-like MVCC transactional semantics.
All of that has been invaluable now that I do iOS development full time. Swift's approach to value types and mutability are natural fits to a wide range of things (like undo stacks and concurrent background processing while publishing consistent changes to the UI). Different platform, language, tools, etc but the experience was far from wasted. Hell, having done manual memory management back when iOS was an after-hours hobby project gives me the tools to find memory corruption bugs and diagnose crashes in an hour that some struggle with for days. Even within iOS there has been massive change and upheaval. There again, experience with generics in C# pays off.
Doing full stack development, writing JS libraries, wrangling with CSS... It's all been valuable experience.
This age trope seems to be from some early days when technology did move slower and people expected to spend their entire career working on the same technology. I've never had that expectation.
Anyone who thinks experience is worthless is an utter fool. My work hacking on an F# JavaScript compiler directly translated to doing massive CoW in-memory snapshots using immutable data structures in C#. My early work with SQL and transactions informed my approach to using atomic CMPEXCH to do optimistic in-memory commits, giving the entire app database-like MVCC transactional semantics.
All of that has been invaluable now that I do iOS development full time. Swift's approach to value types and mutability are natural fits to a wide range of things (like undo stacks and concurrent background processing while publishing consistent changes to the UI). Different platform, language, tools, etc but the experience was far from wasted. Hell, having done manual memory management back when iOS was an after-hours hobby project gives me the tools to find memory corruption bugs and diagnose crashes in an hour that some struggle with for days. Even within iOS there has been massive change and upheaval. There again, experience with generics in C# pays off.
Doing full stack development, writing JS libraries, wrangling with CSS... It's all been valuable experience.
Of course, this is mostly specific to web development.
On the other hand, being old means you can quickly spot how trendy magpie technical stacks map to old patterns that the industry has been consistently reinventing over time.
It's also debatable just how many startups actually have much of the contemporary DevOps and data center infrastructure as part of their standard workflow, as opposed to all the volume of buzz that goes into discussing it.
On the other hand, being old means you can quickly spot how trendy magpie technical stacks map to old patterns that the industry has been consistently reinventing over time.
It's also debatable just how many startups actually have much of the contemporary DevOps and data center infrastructure as part of their standard workflow, as opposed to all the volume of buzz that goes into discussing it.
spot how trendy magpie technical stacks map to old patterns that the industry has been consistently reinventing over time.
oh, gosh. That too. The other big problem we have with so many "new" programmers is you can get a critical mass of a few million users before a platform even makes sense. Go shouldn't exist (Erlang did it first). MongoDB shouldn't exist (no explanation needed). But, they scooped the kids early then everybody starts "thinking" that way and before you know it, the world is stuck in a broken mindset.
Now, with an army of 5 million unknowing people committed to your platform, the people with experience don't matter anymore. You have strength in numbers, not in correctness or long-term viability.
It's also debatable just how many startups actually have much of the contemporary DevOps and data center infrastructure
Startups, yes. Actual companies, no. Most "real" companies (older than 8 years) have legacy infrastructure, physical data centers, and are only now realizing what 'cloud' (or OS-level VMs!) could mean to them (continuous deployment, automated testing, application isolation, reproducible infrastructure, etc).
oh, gosh. That too. The other big problem we have with so many "new" programmers is you can get a critical mass of a few million users before a platform even makes sense. Go shouldn't exist (Erlang did it first). MongoDB shouldn't exist (no explanation needed). But, they scooped the kids early then everybody starts "thinking" that way and before you know it, the world is stuck in a broken mindset.
Now, with an army of 5 million unknowing people committed to your platform, the people with experience don't matter anymore. You have strength in numbers, not in correctness or long-term viability.
It's also debatable just how many startups actually have much of the contemporary DevOps and data center infrastructure
Startups, yes. Actual companies, no. Most "real" companies (older than 8 years) have legacy infrastructure, physical data centers, and are only now realizing what 'cloud' (or OS-level VMs!) could mean to them (continuous deployment, automated testing, application isolation, reproducible infrastructure, etc).
Actually as an Erlang programmer myself (one who actually uses it as, among other things, a web dev language, no less...), I have no problem with Go existing, as I've always been a fan of Rob Pike's work and the Plan 9/Inferno vibe can definitely be sensed in it. It's the finalization of the small ALGOL-like + CSP concurrency model that Bell Labs researchers have been exploring throughout the years.
Moreover, it's one of the few languages so far that have a near complete POSIX/Unix-like kernel(s) API so that one can do straightforward system programming tasks without C, without even using libc, much less meddling with FFIs, lousy wrappers and whatnot.
Also, I'm pretty sure OS-level virtualization has been popular for a while now. Hosting companies have sworn by OpenVZ and even Linux-VServer for ages. However, those aren't as straightforward to configure, nor do they have the marketing angle that Rocket/rkt and Docker do. They're also more system-oriented as opposed to app-oriented.
Moreover, it's one of the few languages so far that have a near complete POSIX/Unix-like kernel(s) API so that one can do straightforward system programming tasks without C, without even using libc, much less meddling with FFIs, lousy wrappers and whatnot.
Also, I'm pretty sure OS-level virtualization has been popular for a while now. Hosting companies have sworn by OpenVZ and even Linux-VServer for ages. However, those aren't as straightforward to configure, nor do they have the marketing angle that Rocket/rkt and Docker do. They're also more system-oriented as opposed to app-oriented.
There are only two categories of skills/abilities. First, things that older people are better at, and are legitimate business concerns. Second, things that older people are worse at, and are not legitimate business concerns. There are some things that some people put it one category, and others put in another. E.g. tolerating technical debt, knowing the latest JS frameworks or accepting longer working hours or higher risk.
Total agreement is not needed on which skill goes in which category. What is very important is that you don't try to assert that there is a third category of things older people are worse at and are legitimate business concerns. That would be ageist and invite downvotes.
Total agreement is not needed on which skill goes in which category. What is very important is that you don't try to assert that there is a third category of things older people are worse at and are legitimate business concerns. That would be ageist and invite downvotes.
Great points.
The proper flow seems to be: have experienced people who are better at strategy mentor inexperienced people who may know more modern tools and are better at immediate tactics (regardless of age), then over time the inexperienced people grow to become mentors to the new batch of inexperienced people.
But, in our current climate of ego-driven "22 year old amazing CEO knows everything with zero management training or management research," we end up with perpetuation of subjective confirmation-bias fueled "only 22 year olds can do everything" lies.
The proper flow seems to be: have experienced people who are better at strategy mentor inexperienced people who may know more modern tools and are better at immediate tactics (regardless of age), then over time the inexperienced people grow to become mentors to the new batch of inexperienced people.
But, in our current climate of ego-driven "22 year old amazing CEO knows everything with zero management training or management research," we end up with perpetuation of subjective confirmation-bias fueled "only 22 year olds can do everything" lies.
Maybe I've been lucky, but this doesn't mesh with my experience at all. The oldest guys at my company are the ones teaching the classes about Haskell or Scalaz. They're the ones trying out Elixir. They're the ones building frameworks for everyone else to build on top of.
The youngest people are banging out feature #4,501 for the website.
As you get older you should be spending more time experimenting, teaching, mentoring, reviewing and building foundation.
The senior guys are senior not because they've pumped out more features this year, but because they're making all the engineers around them better.
The youngest people are banging out feature #4,501 for the website.
As you get older you should be spending more time experimenting, teaching, mentoring, reviewing and building foundation.
The senior guys are senior not because they've pumped out more features this year, but because they're making all the engineers around them better.
Or, if you're experienced and "old", you realize that all the technologies you mention can be picked up in about a week or two (for all not per technology) and are essentially just rehashing old ideas that you already have years of experience with.
You realize how with little effort you can pick up new things and recognize the stupidity of youth who write posts like this.
And you write way better code than most young people because you understand what matters and it's not knowing some specific framework or tool.
I'd add the caveat that learning new paradigms can take longer than a week, e.g. "client-server" in all its guises, OO or functional programming, databases.
But once you learn a paradigm, variations on a theme tend to take "about a week or two", and almost all this new stuff is variations on existing paradigms.
But once you learn a paradigm, variations on a theme tend to take "about a week or two", and almost all this new stuff is variations on existing paradigms.
>If you have a long work history, and if you are good at something, there's a good chance soon the thing you're good at will be replaced by something you're not good at.
We know that doesn't happen for everything, but the problem is that it isn't somewhat predictable. We're pretty much in a lottery until the industry becomes insensitive to new tools which could take decades or more and we all have our own opinions on the safe bets and the risky bets. Maintaining legacy code sucks but it will at least get better because in two decades, the legacy code then will still have decent tools supporting it. I look forward to maintaining .Net 4.5 code in particular with visual studio 2013/15, despite that visual studio 2030 would be available. The IDE for my current legacy code responsibilities has a blazing white (#FFF) background with small font, non-monospaced black (#000) text. Kill me.
It's to the point now that if you gamble on investing time in new languages/tech, you have to plan to be out of a job while you retrain if something happens to your corner of the industry. Don't get me wrong though, churn like this is good because it's evolutionary. A new language isn't exciting any more because there's so many of them, but when one does make everyone excited, it's easier to see if it's worth the time. Eventually we'll get to the point where the idea of making a new programming language just isn't worth it because our normal set of tools are just so damn good.
We know that doesn't happen for everything, but the problem is that it isn't somewhat predictable. We're pretty much in a lottery until the industry becomes insensitive to new tools which could take decades or more and we all have our own opinions on the safe bets and the risky bets. Maintaining legacy code sucks but it will at least get better because in two decades, the legacy code then will still have decent tools supporting it. I look forward to maintaining .Net 4.5 code in particular with visual studio 2013/15, despite that visual studio 2030 would be available. The IDE for my current legacy code responsibilities has a blazing white (#FFF) background with small font, non-monospaced black (#000) text. Kill me.
It's to the point now that if you gamble on investing time in new languages/tech, you have to plan to be out of a job while you retrain if something happens to your corner of the industry. Don't get me wrong though, churn like this is good because it's evolutionary. A new language isn't exciting any more because there's so many of them, but when one does make everyone excited, it's easier to see if it's worth the time. Eventually we'll get to the point where the idea of making a new programming language just isn't worth it because our normal set of tools are just so damn good.
You're getting downvoted for speaking painful truths.
There is a lot in software that takes more than 3 years to learn: machine learning (real ML, not tweaking off-the-shelf algorithms) and compilers and the like. The problem is that the man-child oligarchy that has taken over Silicon Valley (and, because of SV's influence, the industry as a whole, at least culturally) doesn't value fundamental or technical work (as opposed to doing "make the thingy work with the other thingy" Scrum tickets for a PM barely old enough to drink) so there are so few people doing it, and the competition for positions in real programming is quite high (and the salaries, sadly, aren't as good).
It's easier to get a real programming job at 30 than at 22, but fake programming jobs outnumber real ones by such a large margin. And when you're older and have a family to feed, being too old for the well-paid but fake programming jobs at the Hoolis becomes somewhat of a problem, because real programming jobs are so rare that it sometimes involves a cross-country move to get one.
Ergo, you're old and out of touch and worthless and go live on a programmer retirement farm in iowa because you're not a culture fit with the 22 year old CEOs anymore. yolo, and you wasted it by not becoming a billionaire by 28.
I think that attracting the "old" programmers to a specific city (possibly in the Midwest, say Chicago or Minneapolis, but possibly one overseas like Budapest) is the first step step in taking over the world. I'm not sure what the second is, but an industry that tosses people out just as they're beginning to get good at their jobs is (fuck this term in general, but here it applies) ripe for disruption.
There is a lot in software that takes more than 3 years to learn: machine learning (real ML, not tweaking off-the-shelf algorithms) and compilers and the like. The problem is that the man-child oligarchy that has taken over Silicon Valley (and, because of SV's influence, the industry as a whole, at least culturally) doesn't value fundamental or technical work (as opposed to doing "make the thingy work with the other thingy" Scrum tickets for a PM barely old enough to drink) so there are so few people doing it, and the competition for positions in real programming is quite high (and the salaries, sadly, aren't as good).
It's easier to get a real programming job at 30 than at 22, but fake programming jobs outnumber real ones by such a large margin. And when you're older and have a family to feed, being too old for the well-paid but fake programming jobs at the Hoolis becomes somewhat of a problem, because real programming jobs are so rare that it sometimes involves a cross-country move to get one.
Ergo, you're old and out of touch and worthless and go live on a programmer retirement farm in iowa because you're not a culture fit with the 22 year old CEOs anymore. yolo, and you wasted it by not becoming a billionaire by 28.
I think that attracting the "old" programmers to a specific city (possibly in the Midwest, say Chicago or Minneapolis, but possibly one overseas like Budapest) is the first step step in taking over the world. I'm not sure what the second is, but an industry that tosses people out just as they're beginning to get good at their jobs is (fuck this term in general, but here it applies) ripe for disruption.
There is something I frankly don't understand.
Why would anyone discriminate against older, more experienced engineers? Tech companies are spending millions of dollars on their offices and employee-perks to attract and retain talent and yet they discriminate against the category of people who has the most experience?
It just boggles my mind.
I have a very limited perspective, but come from a country where the ageism is reversed. It is really hard to find work as a new grad. I am now living in Waterloo where the situation seems to be more balanced. But seriously, I would kill for a job where I have the chance to work alongside experienced engineers that can see the "bigger picture" and know a thousand tricks!
Could anyone explain where this obsession with youth is coming from? Is that a US or a SV thing?
Why would anyone discriminate against older, more experienced engineers? Tech companies are spending millions of dollars on their offices and employee-perks to attract and retain talent and yet they discriminate against the category of people who has the most experience?
It just boggles my mind.
I have a very limited perspective, but come from a country where the ageism is reversed. It is really hard to find work as a new grad. I am now living in Waterloo where the situation seems to be more balanced. But seriously, I would kill for a job where I have the chance to work alongside experienced engineers that can see the "bigger picture" and know a thousand tricks!
Could anyone explain where this obsession with youth is coming from? Is that a US or a SV thing?
Could anyone explain where this obsession with youth is coming from?
Many people in control want more attention for themselves. One great way is to say "I made that" but refer to people. So, you see investors and industry "mentors" sweep up young people, hope they succeed, then run around saying "I knew this kid was great when he was only 18! Look at me! I'm so smart! I'm Mr. Look At Me!"
A 45 year old investor can't invest in a 45 year old CEO with the same perverse sense of pride around "making it."
Many people in control want more attention for themselves. One great way is to say "I made that" but refer to people. So, you see investors and industry "mentors" sweep up young people, hope they succeed, then run around saying "I knew this kid was great when he was only 18! Look at me! I'm so smart! I'm Mr. Look At Me!"
A 45 year old investor can't invest in a 45 year old CEO with the same perverse sense of pride around "making it."
It's quite simple: a young and single engineer will cost less and work more. An older and married (or with kids) engineer will cost more and work less.
It's quite simple: a young and single engineer will cost less and work more. An older and married (or with kids) engineer will cost more and work less.
However, that older engineer will achieve more in an 8-hour day than the CommodityScrumDrone achieves in three 70-hour weeks.
Unless, you know, you orient the entire organization around replaceable, low-skill, "Scrum" compliant engineers and never invest in your people. Then you're striving for mediocrity and deserve to fail miserably.
However, that older engineer will achieve more in an 8-hour day than the CommodityScrumDrone achieves in three 70-hour weeks.
Unless, you know, you orient the entire organization around replaceable, low-skill, "Scrum" compliant engineers and never invest in your people. Then you're striving for mediocrity and deserve to fail miserably.
Could you elaborate on the "Scrum" compliant part?
I am not super well versed in software development methodologies but the company I am interning at is using Scrum and I have come to appreciate the fact that it helps me "focus" on something and provide fast iteration for the product. Why is do you think it's bad and what are some alternatives?
I am not super well versed in software development methodologies but the company I am interning at is using Scrum and I have come to appreciate the fact that it helps me "focus" on something and provide fast iteration for the product. Why is do you think it's bad and what are some alternatives?
Scrum isn't so bad for juniors, but when you get older and want to tackle more ambitious projects, you won't want to be justifying mere weeks or days (sometimes even hours) of your own working time.
These methods take management strategies typically reserved for juniors and the underperforming and try to apply them to everyone. It's awful.
However, "Agile" and "Scrum" seem to mean different things everywhere. Some companies say they "do Scrum" but just mean that they have a 15-minute status meeting (which isn't that big of a deal; it's a minor annoyance but it actually can defuse politics and suspicion). Others haul out the whole shebang, with nightmarish "ceremonies" that take hours and involve beasts like "product backlogs" and "business user stories" meant to spread disease.
By "Scrum compliant", I meant the sort of mediocre (or junior) engineer who will accept being managed down to the day.
That said, I don't think that Agile or Scrum is the right thing, even for juniors. Junior engineers should be getting daily feedback, but it should be in the form of genuine doing-the-right-thing mentoring, not continual progress tracking.
These methods take management strategies typically reserved for juniors and the underperforming and try to apply them to everyone. It's awful.
However, "Agile" and "Scrum" seem to mean different things everywhere. Some companies say they "do Scrum" but just mean that they have a 15-minute status meeting (which isn't that big of a deal; it's a minor annoyance but it actually can defuse politics and suspicion). Others haul out the whole shebang, with nightmarish "ceremonies" that take hours and involve beasts like "product backlogs" and "business user stories" meant to spread disease.
By "Scrum compliant", I meant the sort of mediocre (or junior) engineer who will accept being managed down to the day.
That said, I don't think that Agile or Scrum is the right thing, even for juniors. Junior engineers should be getting daily feedback, but it should be in the form of genuine doing-the-right-thing mentoring, not continual progress tracking.
As a newcomer in my 30's I can only hope that this won't be true in Europe.
It is true in Europe. However, the effect is strongly dampened given all of the social and job protection legislation in most European countries.
This means the extend to which an employer can profit from preferring younger employees is very much limited.
Also, young people in Europe are generally less sensitive to promises of future riches because of both cultural differences and the fact that it's simply extremely rare that a European startup strikes gold.
The agism is the same, but it's easier to overcome since there's less profit in it.
There is a downside though: youth unemployment.
This means the extend to which an employer can profit from preferring younger employees is very much limited.
Also, young people in Europe are generally less sensitive to promises of future riches because of both cultural differences and the fact that it's simply extremely rare that a European startup strikes gold.
The agism is the same, but it's easier to overcome since there's less profit in it.
There is a downside though: youth unemployment.
The denialist culture in tech and especially Silicon Valley is so absurd. Even in this thread people are scrambling to come up with excuses.
There are many industries around the world where agism is rampant, and there is only ever one excuse: money and control. Young people are cheaper and more gullible.
It's not a secret, far from it, it's one of the few things for which the cliche "everybody knows" actually applies.
Sure, many industries try to cover up this fact a bit, but only tech makes up such elaborate stories to pretend it isn't all about cold hard cash.
Obviously, there is a reason for this beyond creating a flattering self-image: Most other industries that exploit the young and naive have plenty of supply.
Good engineers however are rare at any age, so market forces aren't sufficient to maintain this exploitative relationship, it needs to be artificially enforced.
Resulting for instance in the insane situation that many older engineers are unemployed whilst the industry is importing cheap young and easily abused engineers from abroad.
(Full disclosure: I too used to believe the main cause for that was that these older engineers had outdated knowledge and no longer making the effort to learn anything new, until I became a hiring manager. And although I have nothing but anecdotal evidence (so has the other side btw), I will be so bold as to state that that is a big fat lie.)
There are many industries around the world where agism is rampant, and there is only ever one excuse: money and control. Young people are cheaper and more gullible.
It's not a secret, far from it, it's one of the few things for which the cliche "everybody knows" actually applies.
Sure, many industries try to cover up this fact a bit, but only tech makes up such elaborate stories to pretend it isn't all about cold hard cash.
Obviously, there is a reason for this beyond creating a flattering self-image: Most other industries that exploit the young and naive have plenty of supply.
Good engineers however are rare at any age, so market forces aren't sufficient to maintain this exploitative relationship, it needs to be artificially enforced.
Resulting for instance in the insane situation that many older engineers are unemployed whilst the industry is importing cheap young and easily abused engineers from abroad.
(Full disclosure: I too used to believe the main cause for that was that these older engineers had outdated knowledge and no longer making the effort to learn anything new, until I became a hiring manager. And although I have nothing but anecdotal evidence (so has the other side btw), I will be so bold as to state that that is a big fat lie.)
Speaking as someone in the middle (mid thirties, have my masters, led several teams as a technical lead/architect, been up and down the hiring process), I agree completely. I've met several older developers/engineers that I have the utmost respect for, and so much of this field seems to move in circles.
Does anyone outside of SV/startups actually find this ageism nonsense to be anything but a convenient story? I can personally think of two excellent engineers that are 60+, and are some of the most amazingly detailed, experienced and all-around intelligent men I've ever met; age has not dulled them in the slightest.
Does anyone outside of SV/startups actually find this ageism nonsense to be anything but a convenient story? I can personally think of two excellent engineers that are 60+, and are some of the most amazingly detailed, experienced and all-around intelligent men I've ever met; age has not dulled them in the slightest.
First, Keep in mind this was written by Vivek Wadhwa, who has a history of attention-seeking articles and statements on social issues in tech.
Second, while the startup scene may follow this trend, the larger employers of the SF Bay Area are not staffed with 20-somethings, they're staffed by all age groups.
Second, while the startup scene may follow this trend, the larger employers of the SF Bay Area are not staffed with 20-somethings, they're staffed by all age groups.
Also, in the startup scene, since new upcoming startups are mostly headed by young newcomers, I guess they would prefer working with the same age people to avoid criticism from an experienced professional. An experienced guy would probably be not as easygoing as them. However, I think, in the end its their loss, one can always learn from others experience.
I don't think experienced guys would find learning a new technologies hard, in the contrary it might be easier for them.
The only point where the young people could be a better choice for a startup is the working hours. Assuming experienced professionals are married and settled, working at a startup might be difficult for them.
I don't think experienced guys would find learning a new technologies hard, in the contrary it might be easier for them.
The only point where the young people could be a better choice for a startup is the working hours. Assuming experienced professionals are married and settled, working at a startup might be difficult for them.
> Talk to those working at any Silicon Valley company, and they will tell you how hard it is to find qualified talent. But listen to the heart-wrenching stories of unemployed engineers, and you will realize that there are tens of thousands who can’t get jobs. What gives?
Pretty clearly, there are tens of thousands of unqualified engineers.
This is less about age, and more about whether you adapt with the times and changing technology. If you're a developer who grew up writing, say, COBOL, and you got REALLY GOOD at COBOL...I mean, just completely amazing at COBOL, so that you're in the top 1% of COBOL programmers in the world...where do you work in 2015? At one of the dozen or so banks that still uses COBOL.
But what about the people in the top 10%? The people who still devoted their time to learning COBOL like no one's business? Where do they work in 2015? Wal-Mart.
I hate to quote Seth Godin, but if you're going to devote yourself to being great at something, you need to absolutely be the best at it, or you're going to find yourself out of work whenever that thing isn't in vogue - and even then, it's a gamble.
Pretty clearly, there are tens of thousands of unqualified engineers.
This is less about age, and more about whether you adapt with the times and changing technology. If you're a developer who grew up writing, say, COBOL, and you got REALLY GOOD at COBOL...I mean, just completely amazing at COBOL, so that you're in the top 1% of COBOL programmers in the world...where do you work in 2015? At one of the dozen or so banks that still uses COBOL.
But what about the people in the top 10%? The people who still devoted their time to learning COBOL like no one's business? Where do they work in 2015? Wal-Mart.
I hate to quote Seth Godin, but if you're going to devote yourself to being great at something, you need to absolutely be the best at it, or you're going to find yourself out of work whenever that thing isn't in vogue - and even then, it's a gamble.
> The young understand new technologies better than the old do, and are like a clean slate: they will rapidly learn the latest coding methods and techniques, and they don’t carry any “technology baggage”. As well, the older worker likely has a family and needs to leave by 6 pm, whereas the young can pull all-nighters.
Underpaid AND you have to pull all-nighters? No wonder software engineers are hard to come by. What are my other options?
Is building forms in Rails really that difficult for older people? EDIT: Keeping in mind this article was from 2010.
Underpaid AND you have to pull all-nighters? No wonder software engineers are hard to come by. What are my other options?
Is building forms in Rails really that difficult for older people? EDIT: Keeping in mind this article was from 2010.
In my line of work (digital marketing), I actually prefer slightly older people because they usually have a body of experience and data to rely on to make better decisions.
Yes, young people know social media better, but that's a role I can easily get a couple of fresh college graduates for. For deep analysis and understanding of customer personas, messaging, etc. I feel older people do better.
Yes, young people know social media better, but that's a role I can easily get a couple of fresh college graduates for. For deep analysis and understanding of customer personas, messaging, etc. I feel older people do better.
Just a reminder that the following are inconsistent (and both views go basically unchallenged on HN)
- Tech is exploitative, underpaying and overworking naive employees.
- Tech is dominated by privileged White/Asian males who exclude women and minorities from what would otherwise be a great opportunity.
(If you take a Marxist view that attaches a ridiculously high value to what an employee is worth, then these views can be consistent, in the sense that you can label almost any employment arrangement as exploitation. But I would guess most people on HN subscribe to the (correct) market oriented view which defines exploitation much more narrowly as getting a person to accept something worse than their outside options by the emotional appeal of the job. If startups were really duping White males into working for them instead of a better paid and lower stress banking job or whatever, someone who really cares about women and minorities would presumably tell them to steer clear of this exploitation).
- Tech is exploitative, underpaying and overworking naive employees.
- Tech is dominated by privileged White/Asian males who exclude women and minorities from what would otherwise be a great opportunity.
(If you take a Marxist view that attaches a ridiculously high value to what an employee is worth, then these views can be consistent, in the sense that you can label almost any employment arrangement as exploitation. But I would guess most people on HN subscribe to the (correct) market oriented view which defines exploitation much more narrowly as getting a person to accept something worse than their outside options by the emotional appeal of the job. If startups were really duping White males into working for them instead of a better paid and lower stress banking job or whatever, someone who really cares about women and minorities would presumably tell them to steer clear of this exploitation).
On the flip side Netflix only hires "fully formed adults". No interns and no fresh college grads.
Netflix doesn't care all that much about the costs of their IT, because it's overwhelmed by the costs of licensing, and now I assume, creating content.
Or so we're told in reference to their moving to AWS, they could be an exception that proves the rule.
Or so we're told in reference to their moving to AWS, they could be an exception that proves the rule.
Younger workers cost less, and work more.
Ridiculous. Imagine the baking industry taking this approach - tell your three year old kid to go into the kitchen and bake a cake. Or how about toddlers running marathons - because they have to do a lot more running to get to the end.
Ridiculous. Imagine the baking industry taking this approach - tell your three year old kid to go into the kitchen and bake a cake. Or how about toddlers running marathons - because they have to do a lot more running to get to the end.
I just turned 27 and this perspective frightens me beyond I prefer to admit. I live in Toronto area, but want to work in Silicon Valley one day. One of my fears is that by the time I turn 29 or 30, I may be "too old" to attract employers enough to relocate me.
Well, just the more motivation to work on my github account...
Well, just the more motivation to work on my github account...
I am an experiences software developer and I won't break my back and work nights/weekends/12 hour days for any employer. I foolishly did this enough in my youth on many occasions and it's just not worth it because you are doing all of the work, your personal life is suffering, and in the end, the investors and owners get rich while you need to find another job when it goes under or is acquired (in rare cases, do you get to keep your job because usually the company acquiring you already has their own people).
When I own > 50% of the company, it's a different story.
At one of my last jobs (> 3 years ago), the boss would call us on holidays, weekends, and whenever else things were on fire and expected us to work. One guy even had to cancel his entire vacation because of a release which had the entire team working on New year's eve into New year's day.
I just refused and wouldn't pick up my phone on the weekends or change my vacation schedule. I think the main issue with me was that the boss's poor management skills caused the delays and issues. Mainly, someone kept corrupting the git repo because they didn't know how to check-in code properly and it would re-introduce bugs we recently fixed and new bugs almost every week. It took her and the project manager 3 months to figure out who it was...and they weren't fired.
I was let go after a little over a year working there and replaced with a remote developer from Mexico. In fact, everyone on the US team was replaced with remote workers because they could work on our holidays and had no problems working every day.
The best part was that the owner gave me shares in the company, for every hour that I worked. I never actually received my share total on paper (besides a generic agreement when I was first employed) because the owner kept giving me a different excuse. About 6 weeks after I left, the owner dissolved the corporation and created a new one so he wouldn't have to pay anyone shares that were promised.
This sort of behavior is common in the valley (re-incorporating to push undesirable people out) and playing semantic and number games on paper to liquidate employees shares.
It's this sort of behavior that forces me to be unemployable as an experienced engineer.
When I own > 50% of the company, it's a different story.
At one of my last jobs (> 3 years ago), the boss would call us on holidays, weekends, and whenever else things were on fire and expected us to work. One guy even had to cancel his entire vacation because of a release which had the entire team working on New year's eve into New year's day.
I just refused and wouldn't pick up my phone on the weekends or change my vacation schedule. I think the main issue with me was that the boss's poor management skills caused the delays and issues. Mainly, someone kept corrupting the git repo because they didn't know how to check-in code properly and it would re-introduce bugs we recently fixed and new bugs almost every week. It took her and the project manager 3 months to figure out who it was...and they weren't fired.
I was let go after a little over a year working there and replaced with a remote developer from Mexico. In fact, everyone on the US team was replaced with remote workers because they could work on our holidays and had no problems working every day.
The best part was that the owner gave me shares in the company, for every hour that I worked. I never actually received my share total on paper (besides a generic agreement when I was first employed) because the owner kept giving me a different excuse. About 6 weeks after I left, the owner dissolved the corporation and created a new one so he wouldn't have to pay anyone shares that were promised.
This sort of behavior is common in the valley (re-incorporating to push undesirable people out) and playing semantic and number games on paper to liquidate employees shares.
It's this sort of behavior that forces me to be unemployable as an experienced engineer.
I am thinking of ditching anti-discrimination laws and instead allow EEOC, anti-trust, or other regulatory agencies to impose anti-discrimination conditions on companies as necessary, which hopefully will be a last resort.
=== Summary
It seems to me that the article:
(A) is a reasonably correct description of some dysfunctional aspects of the Silicon Valley culture but
(B) omits considerations much more important for the main goal of the Silicon Valley culture or any such activity at all -- business success.
Here I concentrate on this last, business success, i.e., making money with computing, software, and the Internet.
=== New Technologies
In the sense of (A) above, it appears that the article wants to concentrate on "new technologies" by which it likely means, say, Python, Django, Ruby, Rails, Objective-C, JavaScript, jQuery, Node.js, mobile devices, etc.
Two problems:
(a) For a startup seeking the goal of business success, those technologies are mostly just redundant alternative tools from which a given startup need pick only a few.
Sure, a person with more skills with more such tools can be useful quickly in a larger collection of startups by others. So, by concentrating on acquiring skills with so many tools, the person is concentrating on being an employee and at least partly neglecting picking a good project and startup for the real goal of business success.
(b) The "new technologies", when and if really needed for the goal of business success, are not just routine software, and the OP did not explain "new technologies" that are needed or how to acquire them.
=== An Example
For my startup, two weeks a go or so, I got all the production software I planned running.
In writing that software, I decided that my user interface (UI) would be just a simple Web site, not an app, and, for the foundation for the software, selected Windows, the .NET Framework, ASP.NET for developing the Web pages, ADO.NET for interacting with SQL Server, and Visual Basic .NET (VB) for the programming language.
My Web pages are so simple (i) I don't need to write or even read any JavaScript and (ii) even for just my first all English language version, 2+ billion people around the world, eight years old or older, whether they know English or not, should find the site easy to use right away or, in the case of an eight year old without English, soon. So it's all just the simplest HTTP, HTML, and CSS with just some one line text boxes and some links with no pop-ups, pull-downs, or roll-overs. We're talking simple as in "Keep it simple, stupid" (KISS).
My mobile strategy is to have my Web pages quite usable even on nearly any mobile device. E.g., each Web page is just 800 pixels wide with large fonts and high contrast, and a window only 300 pixels wide should be wide enough.
Sure, Python has a lot of software libraries: So, if some such library has some functionality I need that is not in .NET, that I can't find in open source in C# or VB, and that I shouldn't just program myself, then maybe I'll use some Python. Okay. So far, nope.
So far I don't need more of the OP's technologies -- Ruby, Rails, Python, Django, JavaScript, Objective-C, etc. or whatever else the OP had in mind.
So, the OP's view of the role of technologies is not good.
=== New Technology
The OP emphasized "new technology":
Okay, continuing my example, in my startup there is some new technology -- I created it. It's implemented in software, but just as software it is just routine. The most advanced code in the software I wrote is a use of the classic heap data structure as a priority queue.
What's special is what came before the software. And that's not computer science, either.
Instead, my new technology is some applied math I derived, yes, complete with theorems and proofs, based on some advanced prerequisites -- I especially thank A. Kolmogorov and J. von Neumann. Maybe these two guys are "new" to Silicon Valley -- otherwise they go back nearly a century.
The Silicon Valley culture the OP is describing will have a tough time duplicating or equaling my new technology.
So, for new technology, I'm far ahead, not behind.
For the new technology I created, the OP's "The young understand new technologies better than the old do" is exactly backwards.
Net, it appears that the OP believes that the keys to business success are new technologies such as Python. Nope!
Instead, Python is just yet another applications programming language that permits writing routine code and is nothing like a step toward the new technologies important for the goal of business success. Similarly for Ruby, JavaScript, Objective-C, C#, VB, etc.
=== Denouement
Why am I picking on Python?
From what I've read, Python, CPython, IronPython, etc. are fine, and some of the libraries are terrific. Okay, so, there is yet another applications programming language: It will likely have a good variety of elementary data types, classes, allocate-free, If-Then-Else, Do-While, Call-Return, call by value, call by reference (likely won't have call by name), file and console reading and writing, access to TCP/IP, some means of exceptional condition handling, e.g., Try-Catch, some facilities for multiple threads and locks, etc. It might be compiled, interpretive, or run on a JVM. Okay.
Once I talked with some of the best technical support people at Andreessen-Horowitz (A16Z). They wanted me to be using Python.
I told them that for my startup I had selected Visual Basic .NET (VB).
The A16Z people thought that VB was a toy (they were thinking about the old version of Visual Basic), and I had to explain that (A) for serious production computing on Windows what is crucial is the .NET Framework; (B) essentially the most important language for such work is C#; (C) the .NET version of Visual Basic is different from C# essentially only in a different flavor of syntactic sugar; and (D) for several reasons I prefer the VB flavor.
The A16Z people missed another crucial point: I started with VB only with my present project. Well, right away, less than a minute, I was able to read and write VB. Then with the syntax lessons from just a few, simple code samples, I could write VB right away -- no delay at all. The language was very much not the challenge.
There was a challenge -- the .NET Framework with however many classes and thousands of Web pages of documentation; for serious production software on Windows, .NET is just crucial. The A16Z people didn't understand that.
C#? The syntax looks a lot like that of C so is familiar enough. Of course, I don't like the C syntax -- never did. Used it? Yes. Liked it? No.
Lesson: Even among the best technical support staff at A16Z, the understanding of "new technology" is not good.
For the business goal, this lesson and that of the OP are essentially inevitable: In anything like the present context, the coveted unicorns are rare and need not fit simplistic patterns. So, much consensus on creating unicorns would contradict that the unicorns are rare.
It seems to me that the article:
(A) is a reasonably correct description of some dysfunctional aspects of the Silicon Valley culture but
(B) omits considerations much more important for the main goal of the Silicon Valley culture or any such activity at all -- business success.
Here I concentrate on this last, business success, i.e., making money with computing, software, and the Internet.
=== New Technologies
In the sense of (A) above, it appears that the article wants to concentrate on "new technologies" by which it likely means, say, Python, Django, Ruby, Rails, Objective-C, JavaScript, jQuery, Node.js, mobile devices, etc.
Two problems:
(a) For a startup seeking the goal of business success, those technologies are mostly just redundant alternative tools from which a given startup need pick only a few.
Sure, a person with more skills with more such tools can be useful quickly in a larger collection of startups by others. So, by concentrating on acquiring skills with so many tools, the person is concentrating on being an employee and at least partly neglecting picking a good project and startup for the real goal of business success.
(b) The "new technologies", when and if really needed for the goal of business success, are not just routine software, and the OP did not explain "new technologies" that are needed or how to acquire them.
=== An Example
For my startup, two weeks a go or so, I got all the production software I planned running.
In writing that software, I decided that my user interface (UI) would be just a simple Web site, not an app, and, for the foundation for the software, selected Windows, the .NET Framework, ASP.NET for developing the Web pages, ADO.NET for interacting with SQL Server, and Visual Basic .NET (VB) for the programming language.
My Web pages are so simple (i) I don't need to write or even read any JavaScript and (ii) even for just my first all English language version, 2+ billion people around the world, eight years old or older, whether they know English or not, should find the site easy to use right away or, in the case of an eight year old without English, soon. So it's all just the simplest HTTP, HTML, and CSS with just some one line text boxes and some links with no pop-ups, pull-downs, or roll-overs. We're talking simple as in "Keep it simple, stupid" (KISS).
My mobile strategy is to have my Web pages quite usable even on nearly any mobile device. E.g., each Web page is just 800 pixels wide with large fonts and high contrast, and a window only 300 pixels wide should be wide enough.
Sure, Python has a lot of software libraries: So, if some such library has some functionality I need that is not in .NET, that I can't find in open source in C# or VB, and that I shouldn't just program myself, then maybe I'll use some Python. Okay. So far, nope.
So far I don't need more of the OP's technologies -- Ruby, Rails, Python, Django, JavaScript, Objective-C, etc. or whatever else the OP had in mind.
So, the OP's view of the role of technologies is not good.
=== New Technology
The OP emphasized "new technology":
Okay, continuing my example, in my startup there is some new technology -- I created it. It's implemented in software, but just as software it is just routine. The most advanced code in the software I wrote is a use of the classic heap data structure as a priority queue.
What's special is what came before the software. And that's not computer science, either.
Instead, my new technology is some applied math I derived, yes, complete with theorems and proofs, based on some advanced prerequisites -- I especially thank A. Kolmogorov and J. von Neumann. Maybe these two guys are "new" to Silicon Valley -- otherwise they go back nearly a century.
The Silicon Valley culture the OP is describing will have a tough time duplicating or equaling my new technology.
So, for new technology, I'm far ahead, not behind.
For the new technology I created, the OP's "The young understand new technologies better than the old do" is exactly backwards.
Net, it appears that the OP believes that the keys to business success are new technologies such as Python. Nope!
Instead, Python is just yet another applications programming language that permits writing routine code and is nothing like a step toward the new technologies important for the goal of business success. Similarly for Ruby, JavaScript, Objective-C, C#, VB, etc.
=== Denouement
Why am I picking on Python?
From what I've read, Python, CPython, IronPython, etc. are fine, and some of the libraries are terrific. Okay, so, there is yet another applications programming language: It will likely have a good variety of elementary data types, classes, allocate-free, If-Then-Else, Do-While, Call-Return, call by value, call by reference (likely won't have call by name), file and console reading and writing, access to TCP/IP, some means of exceptional condition handling, e.g., Try-Catch, some facilities for multiple threads and locks, etc. It might be compiled, interpretive, or run on a JVM. Okay.
Once I talked with some of the best technical support people at Andreessen-Horowitz (A16Z). They wanted me to be using Python.
I told them that for my startup I had selected Visual Basic .NET (VB).
The A16Z people thought that VB was a toy (they were thinking about the old version of Visual Basic), and I had to explain that (A) for serious production computing on Windows what is crucial is the .NET Framework; (B) essentially the most important language for such work is C#; (C) the .NET version of Visual Basic is different from C# essentially only in a different flavor of syntactic sugar; and (D) for several reasons I prefer the VB flavor.
The A16Z people missed another crucial point: I started with VB only with my present project. Well, right away, less than a minute, I was able to read and write VB. Then with the syntax lessons from just a few, simple code samples, I could write VB right away -- no delay at all. The language was very much not the challenge.
There was a challenge -- the .NET Framework with however many classes and thousands of Web pages of documentation; for serious production software on Windows, .NET is just crucial. The A16Z people didn't understand that.
C#? The syntax looks a lot like that of C so is familiar enough. Of course, I don't like the C syntax -- never did. Used it? Yes. Liked it? No.
Lesson: Even among the best technical support staff at A16Z, the understanding of "new technology" is not good.
For the business goal, this lesson and that of the OP are essentially inevitable: In anything like the present context, the coveted unicorns are rare and need not fit simplistic patterns. So, much consensus on creating unicorns would contradict that the unicorns are rare.
The elephant in the room is that most of SV companies don't do anything technologically sophisticated, so for them it's simpler to take the latest technologies and hire young people who will work without counting their time. Were they working on more complicated problem, they would require more experience.
Age bias is so obvious that its actually celebrated. Look at this example from Jetbrains Jobs page https://www.jetbrains.com/company/jobs/