Why the Tech Industry Needs to Deal With Its Ageism Problem

Young people have a greater percent of their experience on the most modern platforms and are unlikely to "write FORTRAN in any language" (JS, Ruby, etc).

We've also discussed how homogeneity is valuable to an early startup. Having everyone be culturally similar may allow faster pivoting and interpersonal comprehension.

Finally, tech startups today are largely focused on the "exit": it's not about building and maintaining a product in the long term. Older employees have the planning, analysis, and maintenance experience to establish a product vision for the next decade. But the startup founder (by and large) doesn't want to think of a product over a decade; it's all about MVP, pivots, and fast exits.

Not that any of that is bad, it just doesn't fit well with the average older employee.

I'll admit when hiring I have a little bit of the opposite bias. Very young employees can sometimes be too aggressive about "what is this legacy garbage? we should rewrite it all in RoR and JS". Hey man, we're still maintaining COBOL apps here, slow your roll. It's all about long term planning and maintenance for us.

>“Eight of the companies, the study said, had median employee age of 30 or younger.” In comparison, the Times reported, the median age of the American worker was 42.3 years old.

Ageism is not the only explanation for this discrepancy. The software industry has exploded in growth in the last twenty years. Most other industries have not seen the same rate of growth. When a labor pool for an industry is strained, it sends a signal to young people to pursue a career in that field. As a result, the labor pool is filled by proportionally more young people.

Eventually the growth of an industry will cease. Then less young people will pursue it as a career path, and the median age of laborers in that field will rise.

I've definitely experienced ageism but I suspect that it is rarely institutionalized. Instead I think that people like me are relatively rare. I have no real interest in management or another career--I like being a developer. That means when I show up for a job interview, I don't exactly fit in since it is likely that few of the candidates are my age or older. Sometimes I can overcome this and other times I'm not really given a chance.

I mostly work as a contractor so I have frequent job changes and I haven't found it to be that much of a problem. It is just another hurdle that has to be overcome. The group I'm working in now, I'm the oldest developer by at least 10 years.

a) When supply of well trained programmers is increased, it happens with 22 year olds, who are graduating from college. There is a 30+ year lag on those folks becoming old programmers. To hire a 50 year old programmer, he would either have had to graduate back in 1985 when there were a lot fewer people studying programming, or else changed careers at some point. And a lot of people don't change careers. There simply aren't as many older programmers available because it's a new field as these things go.

b) I've wasted enough years on dead-end tech that I'm more cautious about what I spend my time on now. Things I have become an expert in that are now useless to me and probably not valued by an employer:

TCL, Oracle 8i and PL/SQL, Ada, Java 1.1/1.2, EJB, Java AWT & Swing, Struts, Delphi, Flex, Paradox, Access + VBScript, ASP.NET 1.0, ODBC/OLE/ADO.NET, Linq to SQL, Subversion/MKS Source Integrity/Rational Clearcase/Perforce, differences between bash/ksh/csh scripting, awk+sed, perl, prototype.

And those are just the dead-ends that I regret exploring, because I think I will never use them again and because I could have spent that time learning something more useful. I know the time wasn't completely wasted, but time spent on prototype would have been better spent on jquery, time spent on linq to sql would have been better spent on nhibernate, etc. Reflecting on that leads to a bit of analysis paralysis when looking at TodoMVC to pick which next framework to invest time and effort in - will this be another flash in the pan, is this nothing but Fire and Motion (1)? I expect many employers would probably benefit more from a team of people who lack that perspective, because they'll be giving up more of their evenings and weekends on things that might pan out. I still do that, but a bit less these days, and I wait a bit longer before I dive in. Some might value my caution, but they probably aren't starting a bootstrapped or VC backed change-the-world-through-web-programming moonshot business.

(1) http://www.joelonsoftware.com/articles/fog0000000339.html

This is all so foreign to me. I moved to SV 2 years ago, and I am 47. Y'all are in such a bubble. Every day the recruitment ads state 'change the world - join our social dog teeth brushing cloud service'. I'm only very slightly joking, merely to avoid calling out the actual companies and services. You know what changes the world? Dialysis machines. Microprocessors. Crash avoidance systems. Artificial hearts. More efficient aircraft. Factory automation.

My point is that it takes experience and time to build something important and large. You can't 'move fast and break things' if you are writing an accounting package or code for a chemical reaction chamber. You don't 'pivot' into a new $1B investment in new microprocessor.

Sure, if you are starting up the social dog teeth cleaning service you probably don't need much more than a few 20 somethings willing to kludge together 10 different half baked components (full stack developers!), and there is no point to knocking that kind of environment - I'm sure it is very cost effective. But I see this kind of thinking and lack of planning leaking into other businesses and ideas. I look at job ads for very difficult undertakings using the SV buzzwords of the day - pivot, agile, and so on, and my neuron starts throbbing.

Moreover, I rather worry about all the people coming up in the bubble, thinking it is bedrock reality. I may be wrong, but I suspect the world's appetite for social X services is small. No, I don't suspect it, I know it. Things like microprocessors, thermostats, smart Tvs, graphics cards, dialysis machines, car entertainment systems, accounting packages, factory floor software, and so much more are the engines of our economy. And I see so many posters on HN that I would never hire for a job that required engineering and planning. They don't have the skills, they aren't learning the skills, and when they are 30-35 all they will know how to do is 'program by magic' - change things until it works. Ya, no, you can't work on my flight computer.

This is probably just personal, but there is a very sour taste in my mouth whenever I hear about 'pivots' and 'exits'. I get why they are important in some HN type companies. But our world is truly built on products that require forethought ('move fast, break things' - new motto of Boeing? Not so much), planning, solid engineering, and great technical skill. I wonder why so many 20 somethings pour their talents in lives in something that will be discarded in a month when their myopic 'leader' goes chasing after the latest shiny thing to catch his eye (which is, IMO, the usual reason for a 'pivot'). I guess it pays well. I wish they were working on a better JIT, a lower wattage cpu, or what have you. I wonder at their job prospects when they are 35, have a family, don't have time to go back to school to learn calculus or what have you, and didn't 'hit' and make fuck you money. And I wish founders would actually do a market survey before launching the 5th dog teeth cleaning service in the same tiny geographic area. So many postmortems on here are truly head scratching. You didn't realize that this tiny pocket of under-served market, which is of keen and relevant interest to dozens of companies all around you, maybe, just maybe, has huge barriers to entry or scaling, and that every other company already explored it and wrote it off as unprofitable? Everyone but you is leaving money on the table? Hmmm.

Sorry, I am just having a 'wow, the silicon valley bubble sure is weird' moment. And I'm old, and cranky. Get off my lawn. But seriously, be very, very careful about taking the ideas and lessons from some tiny start up and trying to apply it to anything outside of that very odd, self-referential world.

The problem is when a candidate who has better qualities gets passed over for a younger candidate based on prejudices based on the previous generalization.

Say you want a skilled programmer who is going to work for a certain wage and put in an amount of overtime, and you pitch it to a fresh college grad, and a 35 year old who just got downsized out of a job; when the interview concludes, it's obvious that they are both willing to take the wage you're offering, and the 35 year old is far more knowledgeable.

If you take the kid because you think the older guy might not be as willing as he claims to put in overtime, or because you think he might be too set in his ways, or because he might be too old to match the cultural fit... That's a problem.

People can hire young people because they're cheap. Especially startups, who maybe can't afford to pay for experience. Likewise, someone with a mortgage and kids might be less willing to look for a job with a risky business. So the average age might drop in those kinds of businesses and that's OK.

The problem is when you see the effect and invent the cause. "More young people are in successful startups, that means avoid old people if you want to be successful".

Instead it could be just "frugal startups are more likely to succeed, so don't spend too much on your labour" in which case given two candidates willing to take the same wage, the one with the better skills should win, regardless of age.

> The average age of a successful entrepreneur in high-growth industries such as computers, health care, and aerospace is 40.

> Twice as many successful entrepreneurs are over 50 as under 25.

> The highest rate of entrepreneurship in America has shifted to the 55–64 age group, with people over 55 almost twice as likely to found successful companies than those between 20 and 34 – in fact, the 20-34 age bracket has the lowest rate of entrepreneurial activity.

If ten times as many people over 50 than people under 25 try to start businesses, then the statistics strongly favor the under-25's. These statistics don't mean anything unless you know the number of people in each age group who start businesses.

> 75% have more than six years of industry experience and 50% have more than 10 years when they create their startup.

What does this even mean? Years worked is not the same as having useful experience.

The article would be much stronger if it showed evidence that older workers were more productive, more likely to succeed at starting a business, or were in some other way undervalued by the current job market.

Of all the big young tech companies, I would think that Google would be the one to benefit most from older, experienced employees (besides the group of all-stars it already has, such as Norvig)...Google's business encroaches on a lot of other domains, and domain knowledge is something that (usually) gets better with age. Perhaps in 5 to 10 years, there will be a bigger group of 40+ yr old professionals with enough tech experience/savvy to be more obvious assets to tech startups.

Starting off with some ageism and general cluelessness of your own doesn't help. If they wanted a "young engineer" to generically optimize data storage, I would be at least half-competent, and could give them the names of several engineers far younger than 77 who would be excellent at such work in general.

What neither I nor virtually any other engineer, young or old, would know, and what the engineer who helped build the thing would, is anything about the specific equipment and code in use on Voyager. This is specialized knowledge, just like a lot of the knowledge young 2013 NASA engineers have.

It is equally as beneficial to employ those engineers to modify the systems they built as it was to employ Lawrence Zottarelli to modify the system he built. Age is unrelated.

I've personally worked with older programmers, and there has been little noticeable difference in capabilities (and often added benefits of organizational know-how). The issue is the pay.

Incidentally, it's the same reason why big companies are championing H1B visas by saying "there aren't enough US nationals to fill the roles" (even though the numbers don't bear the statement out): companies want to pay less for somewhat equivalent skills. Who wouldn't?

I will say this though - I have to constantly step my game up to stay relevant. At 50 I will be expected to not only know programming very well, but the industry as a whole including analysis, planning, finances, management, etc.

Anyone who is on either side of that equation is fooling themselves on the reality of engineering and team dynamics.

Furthermore start-ups also implicitly prefer "just good enough" in order to get your company up and flying enough to quickly accrue investor interest, whereas stability forms the bottom-line of our elder engineers -- and stable systems require far more time than some investors are comfortable with.

Even worse, there is the management aspect. Older people have very different management styles, and throwing caution to the wind is definitely not among their managerial toolset. If your company has older people in positions of power then it definitely scares vast swaths of people away -- from eager investors looking to turn a quick buck and energetic young engineers looking to for autonomy to work without anyone second-guessing their decisions.

Finally, the saying "old is gold" applies quite well, however that gold needs regular polish to remain shining.

1) Move to management to continue advancing

2) Find one of the very few large to midsize companies that has a long-term developer career track comparable to their executive track

3) Start you own thing and exploit the fact that you are more productive than younger developers, and control the purse strings

Large and even mid-size and event ostensibly tech companies still, for the most part, view developers as an R&D cost center. They look at cheap development resources, either young kids or foreign, and think "For the price of 1 developer, I could have 10!"

Now they have 2^10 problems.

... Suzanne Dodd, had to coax another 77-year-old engineer, Lawrence Zottarelli, out of retirement to modify the old technology so it could store more data. It seems the young engineers, growing up in an era of unlimited storage, didn’t know how to tackle the problem.

Last time I checked we still don't have unlimited storage... and Is this really because the young engineers didn't know how to tackle the problem, or because the code was poorly documented and written in a way that would be confusing to anyone who was not the original engineer? Programming styles have changed; people used to have to use their memory very efficiently and therefore had tricks to use it more efficiently that aren't as popular now (sacrificed for readability/maintainability), that doesn't mean that young people can't learn those tricks, just that they haven't had to.

What cannot be overlooked though is the emotional aspect of interviewing. It leads to all sorts of biases, and in a subtle way drives racist and ageist hiring practices. I think that "comfort level" with the applicant is a particularly hazardous feeling as it can be confused with cultural fit. If not checked, hiring people within our comfort zone produces a homogenous work environment and an insular organization.

I often find myself thinking more clearly about candidates when I actively counter the "this person is not in my tribe" notion that I believe is behind "comfort level". After all, we are not a fraternity or sorority hiring to make friends.

It comes down to being professional and objective, and being mature enough to hire and work with people outside of our generation or culture.

1. Business travel is a plus to the young crowd and a minus to the older.

2. Legacy technology is a plus to the older crowd and a minus to the younger.

3. Large vs small teams. A younger group will have more generalists, and older group more specialists. A younger team will be small with minimal layers in the way. An older team will need a larger group to support the specialization gained over the years of experience.

Picture a large company that designs motherboards. No travel, established technology, large teams of specialists. Now envision a distributed team of <10 working on some new document classification web app on AWS. I'd wager that a completely different age group would be found in each circumstance. Not necessarily due to ageism.

1. They have a family with responsibilities, sick kids, and dance recitals, etc.

The bad:

Leads to, less professional growth outside of work, more personal days, more sick days, more personal phone calls during work.

The good:

Once comfortable, they rarely leave the job unless forced out.

2. They attempt to solve every problem with the same set of solutions. Few attempt to find new technologies or try different things.

The bad:

The implementation may not be the best one available that will set up the business for future success.

The good:

Solutions are generally predictable.

3. Lack of motivation to prove themselves.

The bad:

The project deadlines are just met. They do just what's asked of them and not more.

The good:

Deadlines are met. They don't try to tackle mroe than they are capable of by expanding the problem domain.

I worked at one place where boomer IT staff were happy. One guy told me, "It's great, I just plan to coast a few more years to retirement."

Gen X and younger people were miserable at this place. One guy who was 27 was fed up with not being taken seriously so he (1) started an MBA program (which the employer had to support at least partially) and (2) deliberately gained weight, and (3) went to a hair salon and had them do a fancy tint job on his hair with aluminum foil and stuff so he'd get grey highlights.

I could be totally off, but from what I know and have seen this seems to be the trends.

For a moment, I was speechless.

Not sure if it was just social awkwardness and shyness that made our young founder jump to that question. But in what universe is that ever an appropriate question in a job interview?

(I'm in my early thirties.)

An unwillingness to train does exist in the more seasoned veteran demographic; but it's just as bad when you get young developer that is a evangelical about their particular niche.

Outside data is ALWAYS dirty.

There is no clean data. And part of the value of experience is knowing how to handle this. For example, assume I get a very large data set from a third party that is crucial to my project. Unfortunately, all the fields are strings. Years of experience have taught me the following ways to deal with this:

1) Implement a lot of logic and validation into the program itself or as a pre-process step. This is a lot of work, requires a lot of domain knowledge, you may still miss a few edge cases, it will force the deadline to be pushed back, and increase the budget. However, those are the disadvantages. The advantages are that this could become a competitive advantage. Maybe no one else knows or has tried to clean up this data before. Identifying and doing this work can lead to a whole new business. A classic example of this is GIS data. GIS data is very very dirty. Street, St, St., Highway, Hwy, Freeway, Fwy, all typical examples of how dirty the data is. Companies like Navteq are based on their ability to clean up GIS data. Apple's Map app was a disaster because Google is so good at and has years of experience cleaning up GIS data.

2) Push back on the third party to clean up their data. Doing this takes some finesse and social/business skills. You can't just say, the data is hard to handle. That sounds like whining and laziness. Your manager can't do anything to help you if that's all you have. Instead one tactic is to make a schema (this is what WSDL and XML Schemas were invented for) and tell the third party that their data must conform. Then it becomes their problem. They might push back, but now your manager has something to fight with. But if they agree to conform and the schema is bad, then it will become your fault (the third party will just say, hey it conforms to your schema so that's your problem). So you better make sure the schema is good (experience helps here). And it may require meetings with the third party's technical team to compromise or figure out what a good schema is (which requires social/business skills and experience).

3) Identifying these problems early. If these data issues are not considered or found early, they will lead to big issues later. This is why senior developers get their work done fast and go home early. They don't make mistakes like using floats for currency or assuming a string is always a certain format. Junior developers make those kinds of mistakes and spend 80 hour weeks fixing it in the code, rewriting unit tests, and running scripts against the database to carefully migrate the data. They may seem more "productive" but they created the work (like the broken windows fallacy).