Previous Entry Share Next Entry
Age discrimination, or simply aging skills?
device
jducoeur
Boy, I have rather mixed feelings about this article. Summary: a 64-year-old software engineer, who interviewed with Google unsuccessfully several years ago, is trying to set up a class-action age-discrimination lawsuit against them.

Actually, no, that's not true -- my feelings really aren't mixed. Mind, I fall into the class in question: I'm 50, and I did interview unsuccessfully at Google back in 2012. But that had nothing to do with age -- AFAIK, that had to do with the fact that we were in the middle of the nymwars at the time, and I made it unambiguously clear that I was going to be a complete and deliberate pain in the ass about it if I was hired.

I won't claim that there's no age discrimination in the software industry, but I would bet there's a good deal less than many older engineers would like to believe. The reality is, it comes down to skills, because skills in the software industry rust *frighteningly* fast. I mean, the guy launching the suit was specifically looking for assignments in C++, Java and PHP. Of those three, the only one I consider *marginally* current is Java, and I would far rather see someone with C# experience. (Yes, yes, you can all read your anti-Microsoft bigotry in. The fact is, Java is only now catching up to where C# was ten years ago.) And I'd consider PHP on a resume to be a strong net negative.

I've known too many engineers who really believe that software was basically solved by Knuth, Dijkstra and company fifty years ago, and that getting up to date is simply a matter of learning the syntax of another language. That's bullshit -- it's never been true, and it's less true than ever now. The programming business has not only continued to evolve in recent decades, that evolution is *accelerating*.

That's happening at all levels. The languages are in the middle of another paradigm shift: if you're not comfortable with at least the core of functional programming (as well as OO), you are facing obsolescence. Software architecture has realigned almost out of recognition over the past five years: you need to be comfortable with scalable approaches, preferably including map-reduce approaches such as Hadoop / Spark / whatever, and ideally grokking the Actor model as well -- not to mention being completely solid on parallel programming. Even the *process* of software development has changed radically in the 15 years since Extreme Programming started the revolution -- while you need to take the trendy consultants with a grain of salt, you absolutely need to be comfortable with the core agile processes in order to be effective.

It's easy to believe that you're being discriminated against, when the truth is you're just *rusty*. Putting this in concrete terms: I spend an average of 30-60 minutes *per day* on self-education in the field. That takes many forms -- reading documentation on new tech, watching presentations, using new technologies in practice, and participating in the communities around that tech. I consider that to be part of my job, and I've never hidden it from employers -- if I'm going to stay sharp, I need to put in the time learning and exercising new skills, so that's part of what you're paying me for.

The lawsuit cites the low average age of Google employees as the basis for believing there is age discrimination. Even granting their numbers (which I don't -- they're based on self-reported data from Payscale, which I would bet skews young), I'm suspicious of the assumptions here. I *expect* any high-end software company to skew young -- not because of intentional discrimination (at this point, most sensible companies will hire any really good programmers they can find), but because there just aren't enough 50-year-olds who are willing to put in the work and discipline to stay sharp. If your skills aren't current, don't expect people to want to hire you.

The moral of all this is, as I've said many times: if you want to work in software, you need to focus on self-education, and make a lifelong habit of it. Several of my friends are professional veterinarians, and I've always found the mandatory continuing education requirements of that field to be intriguingly wise. I enjoy working in an unregulated field, and I suspect most other programmers do as well, but that just means that you have to take responsibility for that continuing education yourself. Expect that to be *hard* -- the world is constantly changing, and you are never going to get to stop and breathe. But it's necessary if you want to stay relevant, and if you embrace it whole-heartedly, it does keep things mighty interesting...

  • 1
(Deleted comment)
I work for a company with many 50+ programmers, who productively contribute to world-class software. This is intentional and has positive results. Previous company was a strong mix of ages.

I'm going to go with age-related discrimination as a systemic reason for so many companies ti skew young. Older workers are seen as expensive specialists unwilling or unable to learn new skills, all of which are to some extent true. But it may not be a reason to pass on such employees, and the numbers don't hold up if you look at all hires.

This stands against whether they provide organizational value commensurate with their cost. But profit drives companies to the cheapest, easiest-to-mold pieces of clay they can find...and then we end up with short-sighted software that encourages the worst in human interaction. Likewise, without a counterbalance people hire people who look like them, age especially included in that.

While I'll grant that that's probably true of some companies, especially at the lower-tech end of the field, I am dubious about it at the higher end. Everyone is fighting to hire skilled engineers at this point, because they're horribly thin on the ground; passing on good ones is just plain dumb from a competitive POV.

I have also worked with a considerable number of skilled older programmers -- but I've also observed a pretty clear bell-curve effect, with more and more of them ceasing to keep up with the times as they get older. I've always assumed this is part of why so many gradually move into management instead.

Keep in mind my viewpoint, as both an older programmer and someone who hopes to need to hire programmers. I care about this issue a *lot*. I think you underestimate the effect of, "unable to learn new skills". The sad truth is, *I* wouldn't hire the majority of programmers my age, because they have demonstrated that they are falling behind the times. It makes me tear my hair out, how many guys I've worked with who turned out to be less useful than an entry-level programmer, because at least the newbie *understands* the uphill road ahead of him.

(It's pretty much always guys, but that just reflects how few older female programmers there are. Interestingly, though, the few older female programmers I've worked with have been well above-average in terms of continuing to learn. I wonder whether there's an ego effect here -- whether the female programmers typically get less invested in believing that they know it all already.)

In my experience, it's a significant effect. I know a disappointing number of guys who, somewhere along the line, just kind of *relaxed*, stopped really learning, and never really figured out how to start again, much less catch up. If I'm running a serious software company, I absolutely do not want anyone like that in my engineering staff. Yes, they may be good guys, and they often make good managers, but they don't produce good up-to-date software.

It's not about age, it's about mindset -- I want to see a passionate and effective devotion to *learning* in all my engineers. In my experience, yes, that correlates significantly with youth. That's not causation: there are lots of older engineers who have kept their minds lively, and they are often the absolute best; I have hopes to remain in that category myself for another 15-20 years. But that takes serious effort, and I do think it accounts for at least much of what might appear on the surface to be age discrimination...

(Deleted comment)
Scala may be a good example - I certainly enjoyed learning it last year, and would love to continue using it, and expand my knowledge. But it has NOTHING to do with what my employer pays me for, and nothing to do with the work we do. I'd have to switch employers for the sake of that sort of skill-use: and my employment decision is based upon more than just "the neat new thing". (We are doing more functional programming, but not in Scala: our clients don't use it either.)

Fair enough, although I'll point out that most of my discussion is quite relevant to a field next door to yours -- bioinformatics. I'm hearing an awful lot from that end of things in the Scala community right now, both on the back-end side (folks who care about scalability of data processing are getting seduced by Spark) and the front-end (a bunch of folks using Scala.js for knowledge-sharing with RDF, as well as visualization). It's a slow process, but definitely happening.

But yes, the core of your point is exactly right: it all comes down to the skills that given employers currently value. And the thing is, I believe those skill sets are, on average, evolving faster than most programmers realize. Trebly so at any of the cutting-edge Internet companies, many of which are not only *using* these new technologies, they're often deeply involved in *developing* them. (It is now trendy for Internet majors to be significant contributors to the open-source world; I applaud that trend, and am starting to play that game myself a bit.)

Hence, the excerpts given in the article (I haven't read the full complaint) sound like someone missing the point. If you're applying to Google, the skills you brag about should be, eg, Python, Go and MapReduce, not C++ and PHP. Indeed, from my experience of interviewing twice at Google, if you aren't comfortable with MapReduce-style approaches, you're basically a non-starter -- most of the interview questions I got expected you to be fluent in that mode of thinking...

(Deleted comment)
Yep, entirely agreed...

I work at a company that trends to younger developers

It's not age discrimination, so much as the fact that so many programmers with current skills are wanting that they snapped up right of out school.
we generally hire about 4 to 1 - schools to "off the street", and generally seem push for experience in specific positions that may require it, for example when we needed an experienced DBA to manage an infrastructural transition.

In  an ideal world, every skilled occupation would include and/or require continuing ed as part of their standard operation. Ditto conferences, if such are available. It's shameful the number of jobs at which continuing ed isn't encouraged, isn't funded, has to be begged for, has to happen on the employee's own time and/or dime, or just plain doesn't exist. But I'm aware part of that is the short-sighted paranoia that you'll pay to educate an employee and then they'll take that knowledge somewhere else. When many employees leave jobs specifically because they feel they can't learn or grow.


I read somewhere that if you take half an hour (or maybe it was an hour) every day to read and learn about a field, you'll be well versed in a year and an expert in five. The quote is fuzzy because I'm not remembering the source, and I'm not 100% sure I concur, but it's food for thought.


Yep, exactly right. Indeed, I need to remember this as a note for Querki -- while the trendy concept of having 20% of your time for personal projects is cute, I think it's much more important to have an official policy that everyone is *expected* to engage in self-directed continuing education, and budget, eg, 5 hours/week for that, on top of conferences and such. (I'm sure that that's a good policy for programmers; I'm not as confident that it's necessary for everyone, but I suspect it's healthiest to just make it company-wide, on the basis of Lerning Is Gud.)

(Deleted comment)
No job I've ever had has prevented me from wanting to learn more. Some have assisted me in learning more, and that's a lifestyle and career benefit.

To be fair, I think there are a lot of jobs that implicitly (if unintentionally) prevent employees from learning, simply by keeping them too busy with the day-to-day fires to allow it. Everyone has a certain amount of mental budget in the day -- if that's all spent fire-fighting, you're not going to have much left over for growth. Even tuition reimbursement isn't as helpful if you don't have the energy to use it...

(Deleted comment)
So you'd think it's reasonable for a job and continuing education, together, to take up someone's entire life leaving no time for a hobby, and call that a choice with professional consequences rather than an abusive job?

...well, that's certainly the way the majority of professions are headed, but I think it's wrongheaded and the end result is that you get burnout, which has *worse* professional consequences.

(Deleted comment)
The rallying cry of the labor movement, back in the day, was "eight for work, eight for sleep, eight for what you will." We *start* losing that-- jobs start requiring time in those off-eight to be competitive-- we start slipping back to what we're already slipping back to, the days when sixteen-hour days were required and employees had time for nothing other than work and sleep, no personal lives, no anything.

I think that's a bit over-stated. The counter-argument is that this self-education is mainly investment in yourself, so it isn't the employer's responsibility.

There is some truth to that. I think that it is *stupid* for an employer in any knowledge industry to not share in that investment -- and IMO, time is the most important currency we have, so an employer who sincerely gives a damn ought to be investing *time* in your self-education, not just throwing money at it -- but that's not the same thing as saying that it is wrong for them not to do so...

(Deleted comment)
Ouch. I hate it when companies do stuff like this. I quite approve of the H-1B program for a variety of reasons (not least, I think the US should be more open to immigration, period), but stunts like this undermine the whole thing.

But yes: ultimately, you are responsible for your own growth. IMO it is wise for companies to co-invest in that (and I'll basically only work for companies that do so), but that doesn't excuse you from owning your life...

(Deleted comment)
My point, I think the one you objected to, was that if you have the energy outside of work to participate in an absorbing hobby, the issue is not energy or time: it is simply a matter of choice and priority.

And now that you restate it like this, I think I can put my finger on why this statement bothers me. You're presuming that energy is a single fungible characteristic, and I think that's just plain untrue.

Illustrating by example: for many people (especially but not exclusively extroverts -- it certainly applies to me), time spent socially, on a hobby, with friends or suchlike, can be fundamentally *re-energizing*. It is less consuming energy than providing it, and can be flatly necessary for long-term health. OTOH, for many (and I suspect most) people, self-education does consume mental energy, which may or may not be available.

So I don't think the equation is as simple as you're making it out to be. Social interaction is often very different from educational interaction, and can have very different effects on one's energy. That makes the choice much more complex: it's not nearly as simple as, "If you have time to play SCA, then you could spend some of that time on education".

(Deleted comment)
the guy launching the suit was specifically looking for assignments in C++, Java and PHP. Of those three, the only one I consider *marginally* current is Java, and I would far rather see someone with C# experience.

Google currently has four "officially supported" internal languages: C++, Java, Python, and Go. (There's also a lot of Javascript and HTML, but most of those are auto-generated.) For the most part, back-end stuff is written in C++, front-end stuff is written in Java, config scripts are written in Python, and new projects started in the past year are (encouraged to be) written in Go. I bet there are people writing in Scala and pretending it's Java. 95% of what I've written in my ten months at Google is in C++, so it's not quite dead yet :-)

Yes, Java 1.8 and C++11 have are just catching up with things that C# had years ago (and Lisp had decades ago). I wasn't happy about joining a mostly-C++ team, but C++11 makes it almost tolerable, and I figured I could put up with it while learning everything else that's going on here.

And yes, functional programming is encouraged at Google whenever it's convenient. OO is ubiquitous. Map-reduce is ubiquitous, although being gradually deprecated in favor of higher-level approaches that treat map-reduce as a building block. (I wrote a quick little throwaway map-reduce today that I ran on 10000 mappers and 1000 reducers.)

As for age distribution, I'm 51, as is my manager. His manager, I think, is in his forties. His manager, I think, is in his sixties. Other members of my team are distributed evenly among twenties, thirties, and forties.


(Deleted comment)

Re: one Googler's view

The real problem here is not the languages that he was interviewing with, which are the 'right' ones for Google, but that he *just doesn't seem like a very skilled programmer*.

"He had a master certification in Java and C++, and boasted of scoring "higher than 96% of all previous test takers" for the Java certification and being in the 89th percentile for the C++ test."

If you are boasting about your performance on the *certification test* for a programming language, you're probably emphasizing the wrong thing.

Reading through his resume, I would probably pass on it, not because of his age, but because of a whole bunch of red flags that seem to say "decent gruntwork programmer, not skilled engineer". His primary position for the past 17 years has been at the same company, and in his description he includes "Data is then sorted and massaged using the Java Tree Classes, Java Hash Tables, and other J2EE/Java 5.0 Collection Classes" -- when you're using terms of art describing such low level functionality as part of your primary role, it likely means that you're not doing anything particularly exciting.

When I was part of hiring at Nokia, I would have skimmed this and put it in the "Nope" pile; and it would have had nothing to do with his age.

I'll say that tech in general, and the Silicon Valley startup scene in particular, tend to be ageist. Often in eye-tearingly blatant fashion – look at the language some startups use to recruit new employees. "Culture fit" benders in San Francisco bars and other brogrammer nonsense exclude basically anyone who isn't young and male.

Large companies are aggressive about stamping this sort of behavior out wherever they see it, if nothing else because getting sued when you have deep pockets is a huge waste of resources. I'm sure pockets of it have existed at Google, because any organization of sufficient size contains assholes, and our training specifically calls out joking references to colleagues' ages as Not OK Even At The Offsite Dinner. I'd be much more shocked about seeing it in hiring given the way the hiring process works internally – there's a ton of peer review.

  • 1
?

Log in

No account? Create an account