The main problem with hiring grey beards, as you put it, is that a lot of them aren't amazing, but due to years, they have an authorative attitude and expect to be paid more than your 20 something devs. If it's my money, I'd hire the 20 year old with gaping holes in their knowledge who are willing and eager to learn over the 40s something dev who thinks their way is better because they're 10 years my senior. I have a lot of anecdotal experience where I've rejected folks who were lacking a basic understanding of the pro's and con's of something. These guys aren't rejected because they don't understand the subject, but because they fail to accept there are scenarios where doing something the other way is better, or that at the very least, things at a bit give and take. This, I postulate, is generally because these guys have 10 years of 1 years experience, rather than the experience they're trying to sell themselves as having. These are the type of guys who will struggle when they're older. That said, when it comes down to it, most of the guys I try to hire are older than me. Age isn't a deciding factor, they just tend to be better.
Something that really frustrates me is people who are more expert than me but can't justify their pronouncements. I had a high school friend who I'm sure was smarter than me claim, "No one does object oriented programming the right way [except him]," but when pressed would just deliberately play games and mystify. Most DBAs I've worked with had their preferred way of doing things, but were incapable of answering Why? It's not easy working with these people. I've come to really value a colleague who can teach---that is, who can explain why they choose what they do.
I'd say anecdotally 2 out of 5 times I've encountered this it's been someone covering up for their own lack of understanding. These are the worst and the most inflexible. All but one DBA I've worked with was this way. It's the natural result of cargo-culting.
2 out of 5 times it's because the person doesn't have patience to explain all the background you'd need to understand, or they don't trust that you have sufficient background. Sysadmins do this all the time. If you're smart and already pretty familiar with their field, it's very frustrating. This isn't as bad as the former case, but it indicates personnel conflict and lack of trust. It's understandable though, e.g. answering technical questions for business people. I've gotten pretty skilled at giving non-jargony, intelligible, short, "popularizing" answers, that also invite further questions if desired. But it's not easy.
And 1 out of 5 it's because people with experience have forgotten the reasons. I've been there too. Just the other week on a Rails project someone wanted to use an ActiveRecord default_scope of "where deleted_at is null", and I had felt the pain of that on past projects, but it took a while to dredge up the details from my memory.
Most of the above reasons don't correlate with age/experience, but the last one does. Experienced people have so internalized certain lessons that they've forgotten the reasons behind them. You could say this is a bit like Michael Polanyi's "tacit knowledge". In this case, hopefully they still have mental flexibility to recognize that nothing is 100%, and if you give them time to remember and communicate their reasons, you can have a reasoned discussion and make a good decision. But recognize that making people think in this way often "feels like work." You are asking them to exert themselves, so it's important to communicate in a way that isn't challenging their knowledge but asking them to share it more deeply.
This is a great point. I try to get people to argue stuff on technical merits, and it's surprisingly hard to do. An example I work with now is the guy who bad mouths sql, non stop, and also promotes nosql non stop. He can't compare and contrast the two, even in general terms. Makes it impossible to have a discussion with him.
I try to be conginizant of where my biases are, and be able to support my assertions on technical grouds. When you do tht though, you often times see there are indeed many valid ways to do things.
That's actually a cracking point. I want to work with people who can defend their positions. The reasoning behind our decisions should be clear, if it isn't, you lose points against the guys who can do it. Luckily, age typically makes you better at this, which is what makes it really suspect when you get an older guy pulling an appeal to authority.
"with gaping holes in their knowledge who are willing and eager to learn"
If you don't mind the 'learning' involving data loss, security breaches and competitive disadvantages... sure. Go for it.
I say this as someone who did learning 20+ years ago, and have lost data, had security issues, and had many of the issues that come with learning technology (and business). My employers and clients absorbed part of those learning costs. But make no mistake about it, we all paid a price for those mistakes. You also will pay something extra for hiring those who are "willing and eager to learn" - it's just the nature of the beast.
Thinking that price is the only factor, and that maybe someone will take "a bit longer" to get something done is naive.
"I've rejected folks who were lacking a basic understanding of the pro's and con's of something...This, I postulate, is generally because these guys have 10 years of 1 years experience".
Did you bother to be honest with them about why you "rejected" these folks?
I'm one of those "40 somethings" who don't always think "my way" is better, but I can generally tell you why "your way" is crap, what it'll cost in the short and long term, and what the less crappy options are. I don't generally have a single "my way" because rarely does one approach fit even most problems well.
Hi there, you seem a tad upset. You should probably note my last sentence where I point out most of the better folks who I want to work with are older. My point was that simply being older doesn't make someone better, and that I'd rather train a junior than deal with a stubborn incompetent senior team mate. Unless you think the latter applies to you, you probably shouldn't be upset, I'm not generlising, I'm pointing out that if you're good, you don't need to worry.
That said, the assumption that you know better than me because you're 10 years older is part of the folly of what I'm pointing out. Indeed, you may know more than I do in my area of expertise, however you should base that on fact and merit. You should not assume that's the case just because you're older than me. If you tried that in an interview with me, indeed, it wouldn't last long and as a blunt Scottish guy, you'd certainly know why.
"and that I'd rather train a junior than deal with a stubborn incompetent senior team mate"
I was pointing out that the 'junior' often has more hidden costs than people realize. If you really are training someone - that's great, but I see far too little of that, and often just a hiring of the younger person either because they're perceived as cheaper, or a fear that the older person won't be a 'team player' (sometimes meaning "won't rollover and do whatever we say, work overtime, etc").
I'm not upset at you.
"I'm pointing out that if you're good, you don't need to worry."
Hrm... you still need to worry some, because you still need the other parties to be able to recognize that you're good (and to do that you need to be able to identify folks who are savvy enough to do that, ad infinitum). I've seen a lot of good folks get passed over for flashier/trendier folks who end up wasting lots of time/money.
The one other thing that comes with age more is a different perspective on time - it goes much faster than it did before, and watching people squander resources is... sometimes difficult.
It's actually not a case of fearing there are people who are difficult to deal with,
I have absolutly no doubt you've experienced people who are stuck in their ways have as many hidden costs as the junior.
I've taken over from older devs who don't use version control, nor a dev environment, refuse to use frameworks or follow coding standards.
Should we honestly believe they don't have hidden costs? Would you really rather deal with them than train a kid?
Either way, I'm only trying to counter the "old is good". I fully accept there are amazing older IT workers, just not that older is always better.
