> 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

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.

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. :)

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.

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]

[1] http://openresty.org/

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. :)

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...

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.

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.

I worked at my first Internet startup in 1993.

Sadly, the web archive only tracks it back to '97... http://web.archive.org/web/19970429192003/http://www.link.ca...

I started in ops, installing things like web and email servers. My first application was doing email parsing.

Oddly, today (literally), I'm writing code to do email parsing.

> I've seen some atrocious code from people switching from older workhorse languages to more modern ones, it's not pretty

I've seen atrocious code too. Young, old, legacy, greenfield ... none of these things have anything to do with code quality.

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.

Younger people have to work more, because they don't have enough experience to work efficiently, yet..."

You conveniently glossed over his main point...

that young people will work for less money.

I think that's a HUGE selling point.

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.

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.

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.

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.

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.

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 don't think we are. I for one judge individuals as individuals. That doesn't mean we can't observe the wider group and make observations.

> Bottom line, look at who you're hiring, not only how old they are.

Of course.

If you were young in the early 2000s, you are not old now. You are barely approaching middle age.

Outside tech, indeed I wouldn't be considered old.

Startups don't die from producing too little code; they die from not writing enough code that really matters to the end user.

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.

It doesn't have to be an organized plot to be sinister. Thousands of people acting semi-independently can end up with a sinister outcome.

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:

https://itunes.apple.com/us/app/h4-spanish-lite/id388918463?...

I've got Russian, Chinese, French, German, and Italian versions too. Like Elon says, seek negative feedback...

http://www.mediabistro.com/appnewser/elon-musk-pay-attention...

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.

Yup, I'm speaking from experience here. ;-)

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.)

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.

(Insert Peter principle jokes, who goes into management jokes, etc)

I'm amazed this attitude has led to law suits. It feels like blatant, unapologetic, discrimination.