Your loss, really. I've interviewed and worked with several young engineers who were really top-notch, who worked out great, and were mature in their approach to work and life in general. They also tend to come with a lower price tag. Some have not worked out so well, but I don't have any reason to believe that the failure rate changes dramatically with age.
As I myself get older, I'm not so sure that the maturity level changes all that much either. People are just better at hiding their flaws as they grow older, then you find out too late when there's an issue.
Despite their intelligence they've always required constant senior level supervision, and have generally been the ones most likely to create maintenance-heavy components due to inexperience.
I'm not sure why our experiences differ so substantially, but I'm happy to hire only senior engineers and let other companies pay to train the young ones. The senior engineers are more than worth the minimal financial premium.
Sounds like you have bad projects management and let people go cowboy and build bad things because you don't communicate with each other.
As for documentation, I'm not sure quite what to say. The best person to document code is the person that's writing it. The best person to document things that aren't code is a technical writer, not an engineer.
Getting good work out of junior engineers requires a management investment greater than the cost of simply hiring experienced engineers to begin with, and they still will not produce code to the same level of robustness and quality.
I can see from your company that you don't operate this way. I assume this choice expands the apparent pool of available applicants, but it also ensures that your company is likely completely uninteresting to senior, experienced, genuinely expert engineers.
In my experience, there are two kinds of engineering managers. The first is the kind that has figured out (or thinks they've figured out) how to get decent enough code out of inexperienced or just plain bad engineers. The second is the kind that realizes that they don't have to work nearly so hard or jump through so many procedural hoops if they just hire people that know what they're doing to begin with.
What's more, those experienced people tend to have extensive contacts and make it easy to hire their friends.
That said, I'm happy to let you spend the time, money, and energy training and managing junior engineers, while dealing with their subpar work output.
You certainly have an active imagination, so I'm sure the next things you make up would be just as interesting.
Flatline3, you're wrong in pretty much every particular about how I work and how my company works.
It's certainly possible to mentor younger developers well and at low organizational cost. It depends a lot on your process. In particular, I think pair programming, frequent commits, good unit tests, and collective code ownership together make it entirely safe to hire somebody younger, and you get substantial benefits.
I also think it's shortsighted to say, "Hey, let the shitty shops train junior developers." Great senior developers have to come from somewhere, and I think they'll never get great working at places that don't have their acts at least somewhat together. I benefited a lot from people taking a chance on me when I was younger, and I think I have a professional obligation to return the favor.
Yet, there seems to be quite a bit of this on here.
However, what we're talking about is experience. Those with little experience are not members of a protected class.
As far as I know, nothing ever happened because of that.
That said, I hate ageism. Always have. However, as I get older, I find it more annoying that 22 year olds think they are "old." I'm 35 and Know I'm not old so 13 years my junior as old is just silly. Certainly 22 year olds can be mature. Old... no.
No. Caused me to raise my eyebrows too.
Ageism cuts both ways, and it's never an excuse for winning an argument or evaluating a person. You evaluate people on their merits or you pass over valuable people and pay the price for it.
Older people can be full of hubris too, using appeals to experience and authority arguments to shortcut rational thinking.
Using the I'm more experienced than you argument is the same as people saying you insist on C++ cause that is what your comfortable and experienced with, and you'll cost the company millions in lost productivity.
Just as a nice case study...
I was "old" when SOAP got popular (late twenties early thirties). Most of my (age) peer group seemed to agree with me in that it seemed over complicated and messy. We were, of course, old stick-in-the-muds who couldn't adapt to the new technology :-)
It was the "young" developers who jumped on it more than anybody else that I saw - the everything-in-xml crowd.
Ten years on, of course, the "young" crowd are now seen as "old".
Plus ça change, plus c'est la même chose :-)
Ageism cuts both ways, and it's never an excuse for winning an argument or evaluating a person. You evaluate people on their merits or you pass over valuable people and pay the price for it.
Amen. Young and old both have stick-in-the-mud types. It's just that the young folk haven't had the time to demonstrate whether they are stick-in-the-mud types. You don't want to hire them whatever their age.
Using node.js (or whatever) doesn't make you cool, hip, and open to new ideas. I can guarantee that, if this forum is still around in ten years time, there will be somebody complaining about this old fker who wants to do everything in node.js :-)
In the same way (not industry-related) I've observed that people who are 50+ years are seen as "elderly". That was 60 or 65 some 15 years ago.
All other things being equal, I'll always pick the older engineer with more experience and maturity than the young engineer without.
Woman are this, women are that, we don't want to hire women because they are XYZ. People don't say it as much explicitly anymore, but I see it in their attitudes.
Every woman is different, as is every 18 year old. We should not have pre-conceived notions about what they are like, we should have a hiring process that is a meritocracy where we will let anyone prove to us they have what it takes. Just because you haven't met a young person who would make a good engineer at your company doesn't mean they don't exist. Young people, like women, have often not been aware or been encouraged to seek opportunities in engineering.
I still haven't met any. I've met plenty of smart kids, and I'm pretty sure I was one, 15 years ago. However, I had no idea what I was doing, and worse yet, had the hubris to think I did.
I was insufferable, and I'd never hire 15-years-ago me. I also won't hire any other young engineers -- I'll let them find out how little they actually know on someone else's dime.
On the other hand, if I was in the VC game, I'd absolutely leverage young engineers as grist for my mill. They're the most amenable to the risk, and it doesn't really matter if the vast majority of small investments fail (and they will, especially given the inexperienced teams), if you hit just a few home run exits.
> Bad news! It gets worse. At some point, just when you start to feel like you know what you don't know, you realize that they are making new things up faster than you can keep track. Talking to people a generation younger than me can be a humbling experience. I have to tread carefully, as you do when you're talking with a person from another country.
That's unnecessarily defeatist. There are steady advances, but there's very little that's genuinely new under the sun, and quite a bit of what the youngsters get excited about is just the cyclic rediscovery of what we already knew.