One of the issues is using the word "engineer" for any of the brogrammer types. an engineer in any other proper engineering discipline does not become worthless with age, their experience actually counts for something.

Somehow we have confused people who stitch together software from pieces of "magic" that they do not understand with engineers.

The work I did in my 20s cannot even begin to compare with what I am doing today in my 30s. Those years of experience really makes a massive difference.

It is time people are honest about ageism and simply states the real reason they prefer fresh grad or 20-something brogrammers. It normally boils down to those people being willing to work longer hours for less money. At least in most of the cases of ageism that I have seen.

My fiancee who is a commercial bank loan underwriter made this observation: There are some people who have been in her industry for decades, but effectively have little experience, because they don't examine their decisions and figure out why things went right and went wrong. Then there are other people who have far less "experience" in terms of the number of years they have been working, but are effectively more experienced, because they can analyze new opportunities using the data they've encountered before.

Experience as a software developer does count for something, so long as you're aware, and you're constantly developing models for evaluating cost/benefit and risk. If you can add in the ability to deal with and manage people, then you will have a very valuable and uncommon toolbox of skills!

There's an argument to be made that 20-somethings shouldn't work more than 40 hours a week or should require higher pay. Or that employers should place more value on the work of more experienced developers. Or both.

But I don't think experienced developers should be exempt from keeping what they're bringing competitive with less experienced ones. That's a market--which is reality.

Agreed, however very few ever come out and says that so directly. In a lot of cases the reasons are given as not having the right "cultural fit", or being "over qualified" or some other excuse because the person hiring cannot stomach it to simply say "we want cheap resources that we can work to the bone".

No one should feel like they need to perform the equivalent of slave labour in order to get a job. 20-somethings should not have to work 80 hour weeks. Allowing them the free time to pursue their interests will make them better employees.

It's possible the problem (at a macro level) is caused by other correlating factors, such as differing salary expectations and how up-to-date skillsets are.

https://news.ycombinator.com/item?id=15642428

If it's that hard for me, it seems true to say it's much harder for someone much older.

I hear you about the -ism fanaticism. But there seem to be serious problems on the horizon. I can't make you believe them. All I can do is try to relate it to something in your life.

I just think the key difference in our industry is that it's far more punishing than others if you're not keeping up to date with relevant skills.

I'm 29 and my last search was two years ago. My last job had me primarily doing ColdFusion-based web development and occasionally iOS development. A big part of the reason I left was specifically to avoid finding myself trapped with few relevant skills a few years later.

I got into and built hobby projects around an upcoming "hot" new paradigm (serverless) and learned Python along the way to do it. Being able to talk passionately about that (and cloud architecture in general) was key to finding my next position even though most of my cloud experience on the job was with the plain stuff (like normal VMs).

But despite being 27, I wasn't immune from having to branch out, learn new things, and become passionate about something to find a new position. Respectfully: our industry doesn't allow for one to stick to the same skillset for long. Your post reinforces what I had feared, which is that people are blaming ageism while sitting on a skillset that is no longer competitive.

I think this is a problem that needs to be handled, and maybe that's through a more industry norm "20% time" for trying new things, a stronger case for experience applying well to new concepts, or something else. But I don't think the problem is ageism.

That's shortsighted and your employer's process sounds shortsighted.

I don't give a crap if you've already used React, Redux, Express, whatever new flavor of the months are coming. If you're 23 and actively using them, odds are you're still going to be worth much less to my team than someone 40 who has to pick them up their first couple months but can immediately contribute valuable, hard-earned broadly-applicable timeless lessons about how to build and operate software.

My job as employer, and my team's job as onboarders, is to train you in the specific skills. Yours is to bring a proven ability to learn, and the general knowledge, wisdom, and thought processes to know how to build things right.

I don't care if you're passionate, I want to know that you'll be professional enough to take pride in what you do and hold yourself to a standard worth being paid for.

If you're a hiring manager and can't figure out better questions than "can you prove you know some things about X technology already," well, please don't get too much better, cause I enjoy being able to hire the skilled people you overlook without as much competition. ;)

Odds are fine, but they aren't a shortcut for using your brain. If a team's culture makes its members instantly side with either the 40 year old or the 23 year old when he/she makes a claim like "we don't need to write tests", "there are no problems in my code", or "we should convert our entire existing repo to <different style/library/language>", then that culture is stifling discussion and actively harming the quality of the code the team writes. Same applies to hiring decisions.

It's frustrating to see ageism swinging back and forth like a pendulum. There's value in having both the crystallised intelligence of older workers and the fluid intelligence of younger workers on one team, provided they firstly get hired and secondly manage to work together.

Just as the majority of 23 year olds are what you are imagining (inexperienced, know-it-alls, chasing the latest fad, etc.) I would say the majority of 40 year old programmers are just as useless in the other direction.

Maybe not on HN where everyone is above average, but in the flyover states it's absolutely the case. Exceedingly few 40+ year old programmers around these parts I'd describe as holding a relevant modern skillset or holding any interest whatsoever in updating their knowledge or trying to stay competitive. It's almost universal derision over the "flavor of the month" until 10-15 years down the road when they realized flavor of the month turned into Linux and all they have left is bitterness over being left behind.

Just as you have the hiring skills to weed through the huge cruft of useless candidates of your preferred type, some hiring managers hold the skills to wade through the cruft of young hipster bros and find the gems as well. The 80/20 rule typically applies to all things in life.

So put another way - in the end, I'd say it all roughly evens out in my experience. I think age is an extremely poor metric for productivity, and it really depends on the specific individual.

I say all this as someone much closer to 40 than 20.

This has nothing to do with age. In most people's case swim lanes are set early in life. If you weren't good enough at 23, unless some major incident in your life changed you, chances are you will be the same at 40.

This has largely been a problem- most people feel with this popular phenomenon called 'Nerd culture'. Some people have it all figured way early in life, others take long, many never. This fact alone counts for different starting points in life, overall seriousness, and the net time available to make progress. Also if you started out as a Nerd earlier, you are more curious, and more eager to learn, change and adapt to things. Than people who start out later, who just wanted a job to provide for their family, and are in purely for 9 - 5 kind of a job, those people will routinely find themselves stuck in the wrong job- As they have to spend bulk of their time learning things. While they might want to spend that time on recreation.

This whole thing about learning and exploring things just for the heck of it doesn't come naturally to most people.

From my own childhood I remember a bunch of bullies from my lane, routinely taunting and beating up kids. One of them grew up to his mid-20s and woke up to the financial realities of life. He then went to college and did his engineering. But that was 8 years after I had finished my degree, and had a neat 9 - 10 years experience compared to him. I once met him in a bus and he came across as a totally changed person, but he still struggles. Largely because the impulse to do things is different, he just wants a job, and beyond that bulk of his early life throughout childhood, teenage and early adulthood were spent doing unproductive stuff. So there is just no desire or curiosity, or even the mental tools required to sustain a continuous learning life long marathon campaign.

I was mostly trying to provide a counterbalance to the "older is always better" opinion I've seen as well. I was lucky enough early in my career to have a myriad of stellar mentors - both old and young, and learned to simply listen to what folks have to say.

As I get older I do understand how hard it is to keep up with the latest thing in tech, while also handling other responsibilities in life. I almost always tend towards the grumpy guy ranting about the latest fad, so this comment is largely out of character!

I thought I'd toss it in my earlier comment - but it's also selection bias at play here. The guys in their 40's looking for work are likely of a different type than those in their 20's. The stellar candidates who have decades of career behind them typically have a strong social network that places them before they even look at a job board. This is an area where I feel ageism is very real, and kind of terrifies me a little should I find myself in that position.

Older isn't always better, simply because older isn't a separate species or class of humans. Put simply young people eventually become old. If you had major human enterprise issues while you were young, chances are those will remain when you get old.

This extends to other things too.

Why do you think retirement is so hard for people who didn't save well enough in 20s and 30s? Nobody can wake up one day, and run a ultra marathon. Processes for making something like this happen start way early in life.

I think your view is 100% valid and could very well be correct. The key point is I don't think people who disagree should be presumed "-ist."

And if you are correct: Good news! As a hiring manager, you apparently have a wider selection of better candidates because your competitors aren't properly assessing value in the right places.

I would argue, though, that being able to readily assess someone's experience in a modern framework you're actually using might be a less risky hire than assessing someone's abilities in decades-old technologies you don't use, hoping their lack of horizon-broadening over the last ten years hasn't been due to complacency, and paying them more just to find out.

But I could be wrong! And that's OK. We should be able to disagree without the "-ist" so often.

First, what's the deal with passion? Can't land a job if you're not passionate about whatever the prospective employer wants you to work on? Replace that word by "enthusiasm" and it'll be more acceptable. Sorry for singly you out, it's the zeitgeist I'm after.

Second, the "relevant skills" bullshit. Sillysaurus3 had relevant skills for a wide range of jobs. The only problem was the lack of trendy buzzwords in the résumé. Employers just don't want to spend a few weeks (or even a few days) training someone to a new stack.

Regarding training someone for a new stack: You quite possibly are right. I just think it's possible for employers to disagree with your view and not be presumed "-ist."

So do I. There are more ways to be wrong than being an "-ist".

When I started, I was expected to pick anything up as I was working. I got my first job partially as a result of having seen Smalltalk in a programming language class. The important "relevant skills" were enough background to pick up new things (since everywhere was different) and a demonstrated ability to get work done.

I agree with your second paragraph--but isn't that a strong case for investing in a cheaper developer with less experience?

If a 20 year old applied for a job that involved writing SQL queries, and couldn't, I'd expect him to be rejected. There's a world of difference between low level C/C++ style programming, and working in Rails day to day, and if you think there isn't, then you should be able to prove it.

I've been a webdev now for some time, and I've written zero SQL queries. Firebase is nice. So is Mongoose. And yes, I can structure it as a traditional SQL relational database with proper indices if needed. I'm not choosing technologies that cause technical debt or problems down the road.

If you think that you can't take a programmer with a decade of experience and a background in security (where I performed SQL injection attacks) and train them to write SQL queries, then that says a lot about the company. I don't regret failing that interview.

We're all here stroking our gray beards about how kids these days don't even understand the tools they're using, and then you turn around and say "i dunno, the ORM handled it for me"?

SQL hasn't appreciably changed in 40 years. I'll take your word that you really know your C/Unix stuff, and I get that gamedev is it's own niche, but I'd expect most senior devs to have developed a rock-solid grasp of SQL just by osmosis over their years.

These sort of things are the reason I have to these days deal with programmers who show me their several thousands of lines of code and feel proud about it, until I show them it can done with a few SQL queries. Or that Java/Python program who proudly flaunts their few thousands of lines of code weekend project, which is basically a awk command that can be written under 3 minutes.

Only a few months back I was asked to review a backend application. The developer explained passionately how his massive structure of Java code plays with the store, which happens to be a key-value store, while the application is largely transactional in nature. Despite explaining to them why this isn't great idea even from an operations perspective, let alone conceptually or design wise they went ahead. Last time I checked they have to often deal with dirty read/write issues in case of temporary failure, and disk crashes apparently are common.

These sort of issues can be avoided if devs sit down and get basic exposure to things SQL, which by the can be done under a few weeks.

After reading your story, for example, I imagine you could spend 3 months part-time doing an online bootcamp like treehouse (focusing on big picture web architecture and syntax) and you would be more than employable as a web dev.

Unfortunately not. I believed it myself, until it became obvious it was a myth:

One interview went like this: They sat me down, opened up postgres, and said "Accomplish these goals." The goals were simple things like write SQL statements to query for certain types of users, or join data together.

I never had any reason to learn any of that. I knew that I could learn it if I needed to. I understood conceptually what joins are, why to use them, and what to avoid and why. The "why" is the crucial ingredient, and I naively thought that would protect me.

No... It's not fun when you have to sheepishly admit in front of three engineers that you have no idea how to write those SQL queries.

It was the same deal with Rails. Ditto for JS. Eventually I went through 5 interviews and struck out on all 5, in a row.

You could spend nights and weekends learning postgresql/SQL, web MVC architecture, JS syntax (for node.js and frontend dev work), and http concepts, in a few months. That's enough to open a lot of interview doors.

The point is that it was impossible to know beforehand which of those skills I'd be quizzed on. It's both difficult and senseless to learn every technology just in case I'm quizzed on it in a 30 minute interview (which really doesn't give you any sense of my skills or learning capabilities anyway).

The sole way to deal with this situation is to plow through a dozen interviews until one sticks.

You say you don't know the job skills that you need for you to hit the ground running

This isn't an accurate description: https://news.ycombinator.com/item?id=15714338

I'm about to hit HN's comment limit, so I think we'll have to leave this off here. Feel free to email me if you'd like to know more or chat about this. It's an interesting topic and I'm simply trying to call attention to the other side of it.

It's so easy to dismiss it as fake or that it doesn't exist. The real world is quite a bit more complicated and messed up in certain ways; it's not just sour grapes talking.

>The sole way to deal with this situation is to plow through a dozen interviews until one sticks.

Yep, and that's pretty much the standard. On the plus side the more you interview the more you see the same questions popping up so you can prep for them. It's an awful numbers game but so long as you keep optimizing/learning that's all that matters.

For what it's worth there was a post on HN a few months back from a high end recruiting company where candidates were highly pre-qualified to interview for certain positions and even then I think their success rate was like 20%. It's the nature of the beast for tech. If your interview offer percentage is too high that probably means you just aren't reaching high enough.

>It's so easy to dismiss it as fake or that it doesn't exist. The real world is quite a bit more complicated and messed up in certain ways; it's not just sour grapes talking.

I'm not dismissing you at all, I've bombed tech interviews before it's the nature of the beast.

It would be really great to get more data behind what is mostly anecdotal evidence. Also getting data from across the US and other countries would be very useful in understanding this better. Without the data it is too easy to go down the dark path.

All sorts of discrimination exists still because "perfectly rational" arguments like yours ignore underlying reasons.

For example: it's the same justification racists used for intelligence tests for voting not too long ago.

But trying to address perceived ageism doesn't solve the problem. Being aware of contributing factors and correcting for them on an individual level does.

Why should dying your hair and wearing skinny jeans affect your hire rate?

"-isms" don't work because they are rational individually, although they might work because they are stereotypically true. Or are you saying that the hiring manager should work on this individually... which would be actually just following the law.

There isn't evidence of this, but even if you believed that were the case, you combat it the same way you would any other weak point of your value proposition. You address it head on in a tactful way that resolves those concerns without having to be asked explicitly.

That could include interest and experience in an emerging tool or architecture (combats stereotype that skillset is outdated), casual commentary on the latest Game of Thrones or Silicon Valley season (combats stereotype of bad cultural fit), or a true passion in solving the problems the company sets out to solve (combats stereotype of clock-in clock-out worker). It could also include adjusting your salary expectations more in-line with what your competition is expecting (if necessary).

The possibility that ageism is not the only cause cannot be simply ignored.

This is a loaded and contentious statement ("assuming...victimhood at the first sign").

And trying to address ageism is trying to solve the problem; the problem is ageism.

In your particular example, ageism is manifest because older workers tend to have families and financial obligations (both of which, by the way, contribute to society). That's not "perceived" ageism. It's simply ageism.

If you choose not to work as much as someone else or made choices that require higher compensation, it is not an "-ism" for your employer to choose another candidate on that basis alone. We're going down a dark road claiming victimhood without evidence as quickly as people are.

Those companies that hire the cheapest labour will get the quality they pay for. Let them, it's not your problem. There are enough who care about doing it right that they will eventually find you and will pay you according to the value you bring.

If you know any of them, please list them. One real problem is that the ones who want to do it 'right' are few and possibly not easily identifiable so potential job seekers may not know where to search for them.

Why do you think all the most highly paid actors and actresses are in Hollywood? Do you think they all started life there or do you think they moved there from all over the world because that's where their market is and that's what they love doing?

If you are avoiding older candidates because of presumptions about them in terms of work ethic or compensation expectations, you are wrong. If you are advertising below-market salaries and expecting >40 hr work weeks and only attract younger people, there is nothing wrong with that.

Older candidates are not entitled to employment in the positions they want at the rates they want. They need to compete in the labor market with the rest of us.

You don't seem to understand how discrimination works: the advertisement you describe discriminates against older workers because of how lives typically evolve with age (e.g. ability to sustain long hours, family or other obligations, etc.). The two scenarios you describe aren't objectively independent or even clearly separable.

I don't think it's the employer's responsibility to tailor the job to match a candidate's chosen lifestyle, or that not doing so means you're discriminating. I think people need to be responsible for their own decisions, and if that means you're less competitive relative to another candidate, that is not the employer or the other candidate's fault.

Offering below-market salaries for 80 hour work weeks isn't illegal age discrimination even if this highly correlates with age, those are legitimate criteria that affect work performance, and thus are valid; just as criteria that require workers to be able to lift a certain weight is a legitimate criteria if appropriate to that job role, even if it would disqualify almost all women for applying.

Disqualifying an old man because you think that people of his age won't work 80 hour weeks for a poor wage or can't carry the required goods is prejudice and illegal discrimination. However, disqualifying an old man because you know that this particular man won't work 80 hour weeks for a poor wage and can't carry the required goods is fair game, it's a reasonable evaluation of a potential employee.

Systemic bias exists. One manifestation of that in this industry is the signaling in certain job descriptions and hiring practices. We needn't point to explicit, specific examples (e.g. "hiring manager told me point-blank 'sorry, we do not hire people over 30'") to see a broader effect.

And perhaps "years spent in industry" is not as universally correlative with cost-effectiveness as some claim.

I agree it is currently popular to assume "-ism" simply from disparate outcomes, but I don't think it's right (in both the "correctness" and "morally proper" definitions of the word).

Does it matter if neither the product sales nor the execs will suffer from producing it?

The problem you’re actually describing is completely orthogonal to whether someone is a “brogrammer”. The actual issue is that most programmers learn neither computer engineering nor computer science. Businesses are typically very high time preference, so they don’t care and are willing to hire people who “know how to code” and that’s basically the extent of their knowledge.

Exactly, this is like saying carpenters get obsolete every few years because wood pieces with new joints come in every few years.

>>It normally boils down to those people being willing to work longer hours for less money.

And for naivety, you can easily sell stories like 'work for great exposure' to newly arrived kids.

In Canada the term 'engineer' is regulated at the provincial level, and a person can be prosecuted for labeling themselves as an engineer if they are not registered and licensed with their province's engineering association. For example in Ontario in order to join Professional Engineers Ontario and call yourself an engineer you must meet strict academic and work experience requirements[1], pass an ethics exam, and pay a yearly membership fee. Everyone who graduates from an accredited engineering program in Canada has to take an ethics course and has these rules drilled into their heads. I know I did.

But then I graduated and half the people I run in to at hackathons and conferences did a two week bootcamp and have "Software Engineer" in their job title, and proudly introduce themselves as such.

I call myself a software developer because although I have a software engineering degree I'm not registered with the PEO and it wouldn't benefit me if I was.

[1] http://www.peo.on.ca/index.php?ci_id=1848&la_id=1

Sounds like a racket, especially given that the PEO is a private organization. I’m not sure why this is supposed to be a good thing.

> Everyone who graduates from an accredited engineering program in Canada has to take an ethics course and has these rules drilled into their heads.

It bothers me that people believe that A) ethics can be taught like any other engineering class and B) ethics should be prescribed by some professional association.

> But then I graduated and half the people I run in to at hackathons and conferences did a two week bootcamp

I agree this is a problem, but most of the actual engineers I meet in real life (i.e. people who did a 4-or-more year accredited engineering program, including some who are from Canada) don’t actually have a particularly impressive level of rigor that would set them apart from most of the college-educated programmers I meet.

The US has the same basic system, all that is different is how strictly the word "engineer" is regulated. And that varies by state.

Before that system was adopted, bridges fell down an average of once a week in the USA. We have a lot more and bigger bridges now, but not nearly as many fall down.

Read https://www.amazon.com/Professional-Software-Development-Sch... for case for doing the same thing for software development.

Dunno why you need the qualifier there. There are public and nonprofit rackets, too.

That's also a requirement in Canada (Ontario at least). Work experience has to be completed while working under a P.Eng.

They care about having a legal lever to manipulate so that there is proof that you should have known better.

A better translation of engineer would be "technicien".

French "ingénieurs" come from "Grandes écoles", see https://en.wikipedia.org/wiki/Grandes_%C3%A9coles

[1] http://www.peo.on.ca/index.php?ci_id=2075&la_id=1#whypeng [2] http://www.peo.on.ca/index.php?ci_id=2075&la_id=1#aftergrad [3] https://www.ontario.ca/laws/statute/90p28#BK36

Found it: https://en.wikipedia.org/wiki/Iron_Ring

So Canada has no arms industry? I call shenanigans.

Whether or not Canada has an arms industry is irrelevant to the question of whether or not it's unethical to build weapons.

Having an ethical obligation and acting on it are two different things. People can argue about the philosophy around the ethics of creating weapons. It could be argued that every engineer working on creating weapons is violating the ethical requirements of being an engineer.

If that were true, wouldn't the professional body expel them from membership? Or perform some other form of sanction? Which it hasn't - ever, to my knowledge.

Personally I don't see a problem with this. That's their job title. Whether they have a P. Eng and can legally sign documents is another matter.

You are correct that technically they cannot walk around saying "I am a Software Engineer" unless they are a Professional Engineer. But I don't see the harm of someone saying "I work as a Software Engineer in X company" because:

- that's their job title

- the company chose the title and hired them for that role knowing their qualifications

- to my knowledge there are no legal restrictions on what title a company can give a role

If you want to go after someone calling themselves a "Software Engineer" when they're not a P. Eng I would argue you should go after the company for advertising an "engineer" position without hiring a P. Eng.

Edit: my argument here is that professional engineer licensing bodies should go after companies hiring engineering graduates to fill an "X Engineer" role the same as they would go after an individual falsely claiming to be a P.Eng.

It's stupid to allow companies to hire someone without a P.Eng to an "Engineer" role and then chastise the person for calling themselves by their job title.

The meaning of engineering on the other hand has been watered down to be meaningless. There are no professional standards and no control on what companies represent their staff to be. It sounds prestigious as a title, but that’s about the end of it.

For some disciplines like Software Engineering, I agree.

For other disciplines like Civil engineering, the term has not been watered down. No company would hire someone to certify designs who was not a P. Eng because they are required to employ a P.Eng for this by regulations/law.

This problem has come up because the government/PEO has not reacted to the changing engineering landscape and don't require positions like "Software Engineer" to be filled by an actual P. Eng.

Companies made the title worthless. I don't see how it's fair to fault the person in the position because there is a double standard applied to individuals and companies regarding the term "Engineer"

Apply the standard both ways. People cannot call themselves an "Engineer" unless they hold a P.Eng and companies cannot hire anyone but a P.Eng for an "X Engineer" position.

From [1]: Becoming licensed gives you the right to use “P.Eng.” after your name and “engineer” in your job title. Under the Professional Engineers Act, you may only use “engineer” in your job title if you hold a P.Eng. licence.

So yes, I'd agree that companies shouldn't be using engineer in the job title unless they're hiring a P.Eng, but that doesn't absolve the employee of liability.

[1]http://www.peo.on.ca/index.php?ci_id=2075&la_id=1#whypeng

So, would you agree that if we are going to be strict about who can use the term "Engineer" there shouldn't be a double standard allowing companies to call a position "X Engineer" and then hire someone who isn't a P. Eng for the position?

If Engineer is a restricted term for individuals, then it should be a restricted term for employers as well. Employers having a position with "Engineer" in the title should only be permitted to hire people with a P.Eng.

> Under the Professional Engineers Act, you may only use “engineer” in your job title if you hold a P.Eng. licence.

The company sets the job title. So if they want to hire someone who isn't a P.Eng to the role, that person is supposed to tell the company to change the role title to exclude the term "Engineer" ?

New is usually not better if you actually want scalable, maintainable, and monetizable results.

I disagree that many area's of my knowledge has a half life. My deep understanding of network protocols hasn't aged. My deep understanding of SQL and NoSQL databases hasn't aged. The principles of distributed systems haven't changed, but they have been given more tools. When, where, and how to optimize hasn't changed. Debugging, naming, and design whether it be functional or OO hasn't changed.

Sure there are new tools and methods, but I say the fundamentals are the same.

I'm not knocking coding bootcamps or colleges, I've had hires from both. I'm moreso saying that the idea that a programmers skills are isolated to the code they currently can write is a little shortsighted.

Absolutely. Folks need to get their heads around software engineering as a practiced discipline. Your education is about the fundamentals of how you think and approach, even if the tools themselves change over time.

Paradoxically, the (again, sensible) attitude that fundamentals are the same with a different coating, will distantiate one from chasing the latest fads... which is actually what the [majority of the] market looks for.

There are places where you get a job because you want to rewrite everything, and places where you get a job because you didn't suggest to rewrite anything.

Does any employer in the world interview people with real world skills?

I make it clear in my cover letter that I am capable of picking up new technologies and languages with ease, which if you look at my resume and my personal projects on github is pretty plain and obvious -- I have 15+ years of professional experience in multiple languages and using all kinds of technologies. But they look at my current job/tech stack and say "hey, you don't match ours. sorry".

I even applied to dozens of jobs in the HN Who's Hiring, got a couple phone interviews, and nothing past that.

I finally got a job at a place that was using my stack and wants to convert it to something more modern.

This has definitely been a strange interviewing experience for me. I'm nearing 40 and have to wonder if ageism is becoming an issue for me.

It's like every business is now completely terrified by a wrong hire and will only take the "perfect candidate" but at market rate

One of the "interesting" side effects is that it seems like interviewers are starting with the assumption that the person interviewing is an idiot who knows nothing and then works from there. So any slight misstep or misremembering of something puts you the fail box immediately.

My theory is that part of this is the broken culture of interviewing that we have as an industry. This "tricky CS puzzle" crap that originated at GOOG and MSFT is so prevalent that it's nigh impossible to actually succeed. More than once, it's obvious to me that the people DOING the interviewing couldn't pass their own interview...

I could easily have been denied for other reasons but it's one of numerous interviews where I go through 1-n cs questions and whenever I get to the first one I can't solve the interview is cut short. It's just a giant waste of everyone's time

1) actually I didn't lie, people I knew just kept +1'ing Python on my LinkedIn profile because I talked about it sometimes while I was doing a one off project in Python

For example, learning a new programming language every year for fun is a decent exercise that makes you better with your "current work tool" as well, keeps your tech stack perpetually up to speed, and isn't that hard - the second language takes significant time, the 15th (for 15+ years of professional experience) brings lots of things you've already seen, so you can do something useful on the first day and a reasonable project in the first week.

Would you spend a week learning a new tech stack for an upcoming interview, with the knowledge that they might not hire you? Only to restart the learning process again next week when you interview at another shop?

The big problem is putting all your eggs in one basket, which is bad if that one technology goes out of demand (as the grandparent painfully experienced). It's not something you do for hiring in a week before interview, it's something you do all the time in the years before as a part of your natural interest and "sharpening the saw" - if you spend the last 5 years working with technology A, a person who is "capable of picking up new technologies and languages with ease" would have picked up technologies B, C, D and E during that time anyway, and can go out to employers who want B truthfully claiming that they learned B back in 2015.

Not only is the claim "now it’s five years at most, and, for a software engineer, less than three" an unhelpful mythology, it's laughably incorrect to the point that I can't imagine anyone knowledgable espousing the view with a straight face.

It stems from, on the one hand, "software as popular culture," which is a great way to choose bad tools, and, on the other, the conflation of surface knowledge (the syntax of a new language, the API of a new hot library, etc) with deep knowledge (design principles that transcend language, the ability to evaluate a library based on those principle, etc).

It's narrowly referring to the "framework fads" that do seem to sweep through our profession on about a three-to-five-year cycle.

If software engineers actually burned down all the old code every three years and literally everybody had to learn this new thing in order to do anything at all, this claim would make sense. But it's all additive. Even as we here on HN are shrieking and hooting about Framework B and the way it shines a unique light on the world of programming and how no thinking person could possibly resist its charms, thousands of people keep chugging along on Framework A for years afterwards. In no small part because they've heard it before, and remember that somewhere around the 2 year mark of Framework B's run you can expect well-written and cogent articles about "Framework B Considered Harmful", "Framework B Is Permanently Ruining An Entire Generation Of Programmers", "Why I'm Switching Back To Framework A And Regret Ever Listening To Hacker News" and "Oh Shit, I Bet My Business On Framework B And All My Developers Have Turned Into Feral Wombats And They're Biting Me Ow Ow Ow".

On the frontend, React has been king for quite a long time now, with no obvious contender in sight. Of course there's stuff like Vue but the difference isn't so big that people are throwing away their gigantic React codebases to restart anew with Vue (things that did happen a lot with jquery, bootstrap and even angular based frontends). The new kids on the block may be better, but only by a relatively small margin.

Similarly on the backend, Rails has been unfashionable for quite a while now, but there's no obvious single new framework that people are flocking to. Sure, there's many hip options, like Elixir/Phoenix, vanilla Go, and bunch of "serverless" frameworks, but just as many people just start their new projects on Rails, Laravel, and ExpressJS, because that shit is productive and it just works.

I feel like, decades after the desktop UI world, the web as a platform has pretty much matured. The core concepts aren't changing that much anymore. I think that maybe something fundamentally new has to happen again for this cycle to truly restart - just like the web as a software platform was once fundamentally new. We'll get new programmers who can reinvent all these ideas again in confusingly subtly different ways. It'll be fun!

Sure, there are frameworks that turn over in <3 year timeframes, but even utterly reckless JS cowboys don't pretend experience in an old framework is worthless.

I suppose I shouldn't be surprised, though, because the article also offers: "With the advent of the cloud and off-the-shelf A.P.I.s—the building blocks of sites and apps—all you really need to launch a startup is a bold idea." It feels like the only skill acknowledged in the entire article is putting a basic JS frontend on a website.

The only timeless ageism thing is the willingness of old men to schnooker young turks into things, whether that is getting blown up on a battlefield for king and country or getting exploited to make guys like Khosla money.

(ETA: Unless you're familiar with the output of such publications, I suppose, at least enough so to validate the "Gell-Mann amnesia" concept firsthand. I can't say they serve no useful purpose - one doesn't care to contemplate packs of feral journalists roaming the streets, shaking down sundry passersby for tweed and elbow patches - but really, one is well advised not to take them overly seriously.)

Is there a way out? Sure:

1. If you actually are that good of a software engineer, start a My Code As Service company - it is the "402 PAY_ME_A_TRUCKLOAD_OF_MONEY" response. There are gobs of companies out there that pay gobs of money for rock star performers because there are just not that many of them.

2. Create - or buy - your own lifestyle business. You will never make millions of dollars but you should be comfortable.

3. Stop pretending that coding matters. Start managing those that produce code. Being a technically competent manager is a great way not to get fired.

Being a good coder in such a company could be problematic, because they won't be able to recognize ability or benefit from the difference in skill to an average coder. These companies will treat programmers poorly, will try to save costs, outsource, etc.

I don't get why you claim that younger people will replace 40-somethings. It's not like the older devs will break outside of the warranty period.

Companies in EU countries have the opposite problem, they can't easily dismiss employees, even when perhaps justified.

I wouldn't want to work in the US, it's too darwinian. A company shouldn't be able to dismiss an empoyee just because there's someone cheaper available.

Or: this argument is meaningless because it's assuming more supply (of someone like you) than jobs (and perfectly informed employers for that matter).

Not to mention everything else that isn't programming per se - domain knowledge, talking to people, negotiating, in which order to develop things...

More details on what I think makes a good dev: https://henrikwarne.com/2014/06/30/what-makes-a-good-program... and about programmer knowledge: https://henrikwarne.com/2014/12/15/programmer-knowledge/

C is a language invented in the 70s. If you kept up with thread APIS when they became usable in the late 90s you could quite easily have had a 40 year career in one tech stack, and be looking at a bit of consultancy by now (if you haven't moved in to management or other areas).

So even without keeping current on frameworks and languages, the idea that knowledge becomes obsolete in our field after just a few years is wrong. You do need to keep an eye on wider trends and newer tools, but still.

That said, there is still ageism in this arena. And I'm breaking out because, really, there are better things to be doing in 2017 :)

As is always the case when a claim is made about "companies having trouble finding developers" of some sort: Are they actually having trouble finding developers despite offering top-of-market salary, remote work and gold plated benefits? Or are they the usual "we think we offer above average salary with great benefits!" companies who get no interest from developers and conclude there's a shortage?

I tend to agree with your viewpoint, particularly when it comes to arguments about the need to mass-import developers from overseas. Are you struggling to recruit due to a genuine shortage? Or are you trying to get people with good experience to work for you for £30K pa?

A few more well=-paid positions might make a difference to the perceived value of technical staff in the country's small to medium businesses.

I suspect you are from the US, and I am from Europe, so this might be a problem. But still, if you are willing to write me an email, my address can be found through my github account that is linked in my profile.

If that's interesting, reply in the positive here and I'll ping you the details of the company and the agency I've been working through. They have a bunch of people from around Europe, and AFAICT one travels in from Germany each week.

It's all subjective, of course, and partly I'm just bored of doing the same thing for so long.

That's very true, but might not necessarily favor either of your two examples. The choice between "20yr C++ veteran and 3yr node coder" is not always obvious or clear-cut, and the quality differential does not, in my experience, clearly favor either side based on that information alone.

I've seen people who left school and coded like crazy for a few years on flaky and fad-oriented stacks--because that was where they could get employed in a hurry with zero experience and a lot of debt. I've seen those people emerge from those environments with an incredibly solid understanding of software design principles and how to do things professionally while balancing time/money/legacy/human/etc. concerns. They learned those lessons not by refining their craft over 20 years of working on an old stack, but in just over 2 years of working on a stack where every day they had to ask their "rockstar" colleagues questions like "Why is this simple thing so hard to do? Why do you keep writing the same kind of bug over and over? What alternatives exist to these tools/strategies?" and not getting good answers. These folks didn't code much outside of work, but they did read about other tools/practices in their free time. By the time they left, they learned excellent techniques (and professionalism) out of acute, concentrated discomfort at what they were made to work on, even while everyone else was taking shots of the piss and calling it brandy.

(And yes, I've seen people in that same situation internalize the cancer and become "X. It's the future!" zombies.)

And I've seen 20+ year veterans who were extremely proficient in a very few (one or two) methodologies, who tried to apply those methodologies to everything--even use cases where it didn't make sense, confused their colleagues, and directly induced bugs ("Making a chat app prototype/mockup for management next week? JavaScript doesn't have CORBA support? Let's write low-level TCP code in Node so we can emulate CORBA using a library I'll write for you. Thrift is too new, I don't care if it's already supported; WebSockets are the 'wrong model'; you need a proper brokered architecture for this . . . proof of concept . . . wait, why is my TCP reading code corrupting data because of off-by-one errors in my read loop?").

I've seen very senior programmers whose "breadth" of tools understanding consisted of re-implementing very specific design patterns from e.g. Java or C in a dozen languages, rather than learning to use the tool that was correct for the job.

I've seen extremely experienced people whose expert understanding of a few things concealed intense insecurity about their knowledge in other areas, and who defensively tried to fit many square pegs in round holes--anything from "we need to use this email collaboration tool I'm super good at that everyone (happily using $other_solution already) has never heard of", to crazy implementations of object/factory patterns in functional languages, to bizarre architecture review and management practices. These people were all competent, and very experienced. They were also scared--not of learning new things, but of being inferior in any single way to their colleagues, even after decades coding. That's a shame, since those folks had the most to teach others, if they'd taken time to have a sense of perspective and/or face their fears.

(And yes, I've seen people with that experience be refined into amazing teachers and stellar coders over the years--people who could get deep understanding of a totally unfamiliar tool in a week, be teaching others to use it in two, and be teaching others when not to use it in three.)

TL;DR the choice is not that simple. But I haven't seen a clear correlation either way between time-spent-in-industry alone and professionalism or output quality. Every industry has old deadweight and young cocky rockstar-wannabes.

But that's my whole point. Age discrimination isn't the only reason 'technical half-life is 3 years' is bogus (not [only] morally outrageous but wasteful of the discrimator's own dollars) -- but also because we should have actual standards. And not just any standards! Things like code cost and quality vs price. I feel like we've gone a bit through the looking glass because explicit knowledge of how to program well is maybe 15% of the actual craft.

[Unrelated side note: I've heard of people using flash cards to try and learn programming. This is deeply weird to me! But I think it also reflects this 'half life of programming knowledge' way of thinking.]

A colleague of mine also recently got a very good offer for helping maintain a codebase in Informix-4GL.

Hipster companies hire by buzzword of the year. Stay away from those.

Note also that the statement is also talking about the "half life", indicating an understanding that there is a part to expertise that is less susceptible to aging. One can criticize that the concept of half life is misapplied, because the underlying process isn't stochastic, i. e. that half of knowledge will not again half in another half life. But then one would be splitting half hairs, which of course is one of the engineering skills that never go out of date.

Coming back, there weren't all that many surprises. I went from first exposure to ES6, Babel, Webpack, protobuf RPC, and Kubernetes, to shipping, inside a month. And I am not in any way special. So I hope I might be excused for feeling I have some basis for the statement that I think you're vastly overestimating the scale of the issue here.

I think this may be the key.

Unfortunately it's partially valid. Job ads in particular are (presumably for a want of some other way to whittle down the pile of incoming resumes) considerably biased towards frameworks and gizmos that have been around 3 years or less.

Yes there are new languages and frameworks we have to learn, but if we apply any effort ...

You'd think a lot of these places assuming we're all utterly incapable of "learning", they way they phrase some of these requirement lists.