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.

>no one has 20 years of relevant experience

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]

[1] http://openresty.org/

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.

> Second, no one has 20 years of relevant experience.

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.

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

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

You conveniently glossed over his main point...

that young people will work for less money.

I think that's a HUGE selling point.

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.

Work for Microsoft or Oracle and you'll find them?

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