This seems to come up a lot, and I agree that age discrimination is an issue. However, there are some obvious reasons for it outside of the the "we think older people are stupid" line. Younger people will often be willing to work more, for less pay, in more marginal conditions. (Witness the discussion a while back about whether ping pong tables and catered food was a perk or a red flag)
Young people have a greater percent of their experience on the most modern platforms and are unlikely to "write FORTRAN in any language" (JS, Ruby, etc).
We've also discussed how homogeneity is valuable to an early startup. Having everyone be culturally similar may allow faster pivoting and interpersonal comprehension.
Finally, tech startups today are largely focused on the "exit": it's not about building and maintaining a product in the long term. Older employees have the planning, analysis, and maintenance experience to establish a product vision for the next decade. But the startup founder (by and large) doesn't want to think of a product over a decade; it's all about MVP, pivots, and fast exits.
Not that any of that is bad, it just doesn't fit well with the average older employee.
I'll admit when hiring I have a little bit of the opposite bias. Very young employees can sometimes be too aggressive about "what is this legacy garbage? we should rewrite it all in RoR and JS". Hey man, we're still maintaining COBOL apps here, slow your roll. It's all about long term planning and maintenance for us.
> Younger people will often be willing to work more...
Younger people have to work more, because they don't have enough experience to work efficiently, yet.
> Young people have a greater percent of their experience on the most modern platforms
So, 1 year of "shiny new tech" > 1 year of "shiny new tech" + 20 years of other relevant experience? Riiiight.
> homogeneity is valuable to an early startup
Wow. Homogeneity is a killer for any team. The whole point of building a team is to find people who can work together, and become more than the sum of their parts. For that, you need people whose strengths cover for their team-mates' weaknesses... the very opposite of homogeneity.
OK, it's not all rubbish. I agree with this...
> Very young employees can sometimes be too aggressive about "what is this legacy garbage? we should rewrite it all in RoR and JS
I don't think you're be fair at all. Young people don't work more because they suck, they work more for a variety of reasons including: they aren't yet jaded or burned out, they don't know how to pace themselves, they have fewer family obligations, they are more excitable.
Second, no one has 20 years of relevant experience. Maybe computer science fundamentals have stayed about the same, but it was 1993 20 years ago, and what we do now looks nothing like what those of us who were around then were doing. Further, all those years of experience could have, and often do, entrench very bad habits. I've seen some atrocious code from people switching from older workhorse languages to more modern ones, it's not pretty.
Finally, /the data suggests/ homogeneity is valuable in early startups. You're not wrong about needing a team with different strengths, but you also need a team that really understands each other intuitively and agrees on fundamental values and principles. There's too much friction otherwise.
I've been designing game APIs for 20+ years, actually. And that's what I'm doing now as a contractor.
I'm still working in C++ like I was in 1993 as well. I first learned C++ in 1989, so that's also 20+ years experience.
>all those years of experience could have, and often do, entrench very bad habits.
Working exclusively with languages like PHP, Ruby, and JavaScript can entrench some pretty atrocious habits as well. I would put my "started with assembly language and moved eventually to high level scripting languages" habits up against a "started with JavaScript" programmer's habits any day.
>Finally, the data suggests homogeneity is valuable in early startups.
What data? I think compatibility between developers is important. But I'm working on a project right now where the median developer age is about 25 (I'm more than twice as old as some team members), and I'm making crazy fast progress on my part of the project, keeping everyone happy. Beyond happy, really; no one expected me to get as far as I have this quickly. And yet I'm putting in 30 hours a week or so.
I think being awesome is valuable, on any project, startup or otherwise, and that "fundamental values and principles" is a red flag indicating "OK working tons of overtime", which is clearly not necessary if you have the awesome.
Just out of curiosity, as someone who has been using C++ a lot for two years rather than 20, do you use a lot of the new C++11 features? I started in 03 and can't think to go back to no smart pointers, move semantics, threading library, or > > template closing.
I've been using boost smart pointers since long before they became part of the C++11 standard. :)
I haven't been using most of the other C++11 features, primarily because they aren't on all the platforms I'm targeting (yet!). But I will. They look very tasty. :)
I would argue that you're doing something perfectly suited for someone with your experience. If you were part of a typical web app SV startup where it was all node.js or ruby then you would be having a hard time keeping up with the "youngsters".
Please don't take this the wrong way as I am extremely respectful of talented c++ game developers. I'm also a game developer but I have no deep background of asm/c/c++. I'm using Unity so I don't need it, but I sure wish I had it.
I was using Ruby before Rails existed, when it was just a "really cool new OO language." At this point I'm done with Ruby because of its many, many problems, and I'm truly amazed that Rails is still as popular as it is. Ruby has gotten so crufty that you need Ruby install managers to track and maintain your various Ruby versions and their respective install libraries. It's a nightmare.
Node.JS is cool in concept; in practice, the code ends up being really ugly because JavaScript doesn't have real closures. Callback hell. You know what I'm talking about.
I'm using Ngnix+LuaJit to get even more performance out of the same server hardware than Node.JS can provide, and I don't need to have nests of callbacks to get non-blocking logic since Lua supports true closures. The code is positively readable, especially compared to Node.
My only regret is that some of the cooler JS client libraries (socket.io in particular) require Node.JS on the server; for my current project (which involves HTML5+JavaScript+networking) it would be really nice to have, though I've already got the Nginx+LuaJit(+ZeroMQ) part of the architecture working, so I'm loathe to add a Node.JS server in addition just to avoid long polling.
So no, you're right, if I were to work with a startup that needed high performance servers, I'd probably not want to be tied down to Node.JS or Ruby. If someone wanted to hire me to handle that problem for them, I wouldn't need the "youngsters" to help me out. But I have enough gig options that I can say no to ones that I don't like. :)
And before you say that "no one knows that stack!", code written this way is far easier to understand by anyone who knows any stack, and that means it wouldn't be hard for a Node.JS expert to step in and maintain it. There also exists a thriving Lua community to pull developers from, for that matter -- some of whom maintain the stack I use. [1]
I agree that the current state of Node.JS is not good, however there is potential for a brighter future. The language itself is improving (such as ECMAScript 6 including yield/generators which will allow things like this https://github.com/visionmedia/co ) which should reduce the callback hell situation. Besides popularity and momentum, the language and runtimes have solid engineering talent behind them (Google, IBM, Microsoft, and others are on the ECMAScript committee and there's several big corporation supported JS engines (V8, SpiderMonkey, Chakra, etc.))
You got me excited there for a moment. Even the new features only talk about generators, not true closures. I see what they're doing with it in Co, but ... well, it's still ugly, and limited. Generators only let you go one function deep, after all; coroutines let you go as deep as you need.
But it does improve the situation, you're right. What I'd love to see happen, though, is for the browsers to all adopt asm.js so I can just run Lua in the browser, so I can be symmetrical with the server... ;)
>there's several big corporation supported JS engines
There's one awesome LuaJIT that's faster than any of the JavaScript engines, not to mention much smaller, easier to build cross-platform or embed, and easier to bind to C code. I only need one, after all. :)
> Second, no one has 20 years of relevant experience. Maybe computer science fundamentals have stayed about the same, but it was 1993 20 years ago, and what we do now looks nothing like what those of us who were around then were doing.
I'll assert the opposite: I haven't seen many new ideas on the software front in the last 20 years. All the advancement has been domain-specific. I bet you could take a team of people who were experts in 1993 and hadn't touched a computer since and still develop a world-beating product today, all else being equal. Heck, Common Lisp has pretty much stagnated for what 15+ years now (the ANSI standard is 20 years old, and CLTL is 30), and ITA is still writing world-beating software with it...
I'm sorry, do we have any evidence that young people work longer? I don't discount that it happens in certain fields, such as finance, but that is forced on them by the system.
Or any evidence that age = worse code?
And, can we see the data for homogeneity? Not anecdotes, data.
edit: recall Woz and Apple. Woz was a briliant designer, who mostly hung out with people like himself. He admits he never could have started or run Apple. Yes, this is an anecdote too. But I suggest thinking about whether 'friction' has value or not. I suggest it does.
>> Second, no one has 20 years of relevant experience.
Depends on what level you're talking about, I suppose.
I'll grant that nobody has 20 years of experience in JSON. However, a guy with twenty years of experience in services through CORBA->SOAP->REST and could be invaluable on an API project, for example. Especially if it's a project that should be built to last.
> what we do now looks nothing like what those of us who were around then were doing
20 years ago I learned some Objective-C. That's still fairly relevant. I recently used an obscure bit of Foundation knowledge no one else around me knew, so to some extent it was even valuable.
Design patterns from 20 years ago may be looking a little long in the tooth, but if you learned the principles as well as the pattern (i.e. what matters most is separation of concerns) that still serves you well today.
If you fire them fast enough yes. Otherwise, young people expect to work for less but to rise high. Otherwise all the energy you see in the beginning is very fast disappearing.
Also, not all young people actually like to be in tech. They don't know it yet that they should be in sales, business analysis, ... You lose them on a regular basis. Older developer on the other hand are going to be at the place they want to be.
Young people work for less money because they are inexperienced. The older worker has to provide the same value for their higher pay via experience. And this is where the problem comes into play: the potential employer might not see the older worker as being worth it, especially if it doesn't appear that they can do more than the younger worker. They might also see potential (room for growth) in the younger candidate that they can't see in older ones. And this is all quite reasonable....also remember that most companies are pyramids, with lots of openings in the bottom and much fewer as you go up....
So you as the tech employee must be aware that your life is short if you don't continuously grow your skills so you don't become an unjustifiable expense later in life. Not only that, but you have to become an expert in marketing these skills.
For anyone it's a matter of working your strengths, and there is nothing a young employee can do against very deep specialist knowledge in a senior employee.
Maybe the problem with the senior workers, is that they are too generalist for the pay they expect. And maybe in too many cases, the expectations to the products produced are not high enough to warrant the pay of a senior developer, which there is nothing to do about, other than raising expectations.
Except that ageism is so prevalent, and the demand for younger employees so dominant, that's it's no longer really the case. New grads are getting stupidly large salaries and signing bonuses.
You returned rubbish for rubbish. Younger people have to work more because they don't work efficiently? Absolute garbage.
I've met my fair share of older devs writing terrible code and taking their sweet ass time to do it. They just clock out on time and go home, safe in their assumption that their mission-critical piece will need their personal maintenance for another decade.
Really? I've been coding for almost 10 years and I haven't met that guy yet. I have several coworkers now who are young, energetic, and have a nasty habit of grossly over-engineering everything they touch.
Actually younger people will work more because:
A) they have more free time, (usually) more passion and are, well, younger (physically just can take more stress)
B) they don't have enough experience to stand up for themself and to negotiate the better deals...
> Very young employees can sometimes be too aggressive about "what is this legacy garbage?
The flipside: I'm old now, but can remember when I was young in the early 2000s.
At the time I was in the Unix space. Older engineers were adamantly pushing Solaris 6 and 8 on incredibly overpriced, poorly performing UltraSPARC over Red Hat on Xeon, for the blindingly obvious reason than they didn't really like learning anything new.
Of course, that was private: to anyone unfamiliar with the platform, they'd simply say that 'you couldn't get support for Linux'. They knew this was false - IBM and Red Hat were banging down their door to sell support contracts (still far cheaper than Sun's rubbish hardware + good support contracts), and Red Hat had hired a lot of Sun's staff - but if they made enough noise, they thought they could slow things down.
It worked, for a couple of years.
(Later on I realised that enterprise architecture purchasing choices are frequently based on dinners, golf tournaments, and straight up dropping cash into your account, but that's a separate story. )
Short version: older engineers can be overly change averse, much like younger engineers can be overly enthusiastic about change.
Maybe we should stop putting all older engineers in the same basket, and same thing goes for the younger ones.
I've known some older engineers (older than me, heh) make crap decisions because they didn't like change.
Then I've seen younger engineers completely mess up good, maintainable code because they think that knowing one language makes them masters of software development.
I try not to hire any of those two persons.
BUT, I've also seen young programmers completely fail because they couldn't adapt to a newer (or older...) technology.
And I know some very much older programmers who are constantly reading up about new stuff, and loving it.
Bottom line, look at who you're hiring, not only how old they are.
I find it odd when start-ups talk about the top recent grad vs the average older worker. The best experienced workers code circles around EVERYBODY else end of story. The only real issue for most startups is convincing them to actually work for you when they have seen enough BS that there harder to convince than most VS's.
If by "code circles around EVERYBODY" you're implying quality rather than quantity, then this is not valuable for most young companies. The quantity of atrocious code produced by some young developers is astounding. Often, that code "works," and the young company is pleased.
"We've also discussed how homogeneity is valuable to an early startup. Having everyone be culturally similar may allow faster pivoting and interpersonal comprehension."
Homogeneity is also the natural state for human beings and not necessarily a sinister plot. If you solve our natural tendency to surround ourselves with people who look and act like us, you'll probably have solved racism, sexism, ageism and just about every other -ism. I' not saying we shouldn't challenge this instinct, but I also don't think we should be surprised that white, 25-year-old, male founders have a tendency to hire other white males in their mid-twenties.
Laugh out loud funny. My first job out of school was doing NeXTstep on real next hardware (early 90's). Fast forward many years, and I'm hanging out on my couch working on my iOS app (i.e. essentially doing the same stuff as my first job).
I don't have a plan other than to make something useful and hope it gains traction. I "release early, and release often", and I work on whatever I feel like doing on any given day.
I've never been paid to write Fortran, and I've only ever seen Cobol once when some cute girl in my college lab needed help, so I gave it a shot.:-)
Anyway, I'd say that you're wrong, but the one thing that I have learned over time, is that it would probably be a waste of time, my most precious resource, trying to convince you otherwise. Ok, back to work...
By the way, if any of you kids want to help out an old man, here's my app:
It is the human equivalent of "right tool for the job" I would think..
Your point about homogeneity is an important one as well. In small organizations, cultural fit - opinions about that culture notwithstanding - is much more important than in larger ones, for the reasons you listed and more.
That said, a wise co-worker once said "you can't have juniors without seniors". While younger workers can be a boon to startups from a price/performance point of view, it is important to also have experienced, if more expensive, employees who can provide guidance and direction to those juniors.
Otherwise, you can find yourself a few years down the road to growth with massive technical debt and a naive technical platform that was built with good intentions but is now full of problems that are extremely hard to correct.
Young people have a greater percent of their experience on the most modern platforms and are unlikely to "write FORTRAN in any language" (JS, Ruby, etc).
They are also more likely to be dumber and lacking in versatility. Older people just have more experience, more knowledge, just by the fact that they have more time to accumulate more knowledge, so they may often may be more productive than 2 or 3 youngsters combined and still have time for family and other hobbies. Of course, that's only true if the older technical folks don't coast and continue to learn since when they were young.
(Yes I am a 22 years old who uses modern frameworks like ruby on rails and meteor. The exact profile that software firms want to hire.)
> They are also more likely to be dumber and lacking in versatility.
I think you mean 'naive' or 'inexperienced'. Stupidity ('dumb' isn't PC, but nobody seems to care anyway) is generally thought of as something inherent.
Could be interpreted as a darwinian selection pressure such that there are smart and dumb noobs, but by the time they're old timers, only the smart ones remain.
(Insert Peter principle jokes, who goes into management jokes, etc)
> We've also discussed how homogeneity is valuable to an early startup. Having everyone be culturally similar may allow faster pivoting and interpersonal comprehension.
I'm amazed this attitude has led to law suits. It feels like blatant, unapologetic, discrimination.
Young people have a greater percent of their experience on the most modern platforms and are unlikely to "write FORTRAN in any language" (JS, Ruby, etc).
We've also discussed how homogeneity is valuable to an early startup. Having everyone be culturally similar may allow faster pivoting and interpersonal comprehension.
Finally, tech startups today are largely focused on the "exit": it's not about building and maintaining a product in the long term. Older employees have the planning, analysis, and maintenance experience to establish a product vision for the next decade. But the startup founder (by and large) doesn't want to think of a product over a decade; it's all about MVP, pivots, and fast exits.
Not that any of that is bad, it just doesn't fit well with the average older employee.
I'll admit when hiring I have a little bit of the opposite bias. Very young employees can sometimes be too aggressive about "what is this legacy garbage? we should rewrite it all in RoR and JS". Hey man, we're still maintaining COBOL apps here, slow your roll. It's all about long term planning and maintenance for us.