At 40, I've done some of the best work I've ever done and my pay has been better than ever. I'm 52 now and the trend has only gotten better.
Why? Its because at 40, I had a much deeper understanding of the tech, I understood of the whole business process and I had the maturity to deal with people in a productive way. You won't find all of those in a 25 year old developer.
The only way that age becomes a detriment is if you do not grow. I worked with someone my age who only strong skills are a large enterprise storage system. He is a dinosaur and his future is limited. That's not his age, its the way he chose to build is CV.
I focused on learning new tech; Python, Go, Kubernetes, Cloud, etc. I've also spend a lot of time learning the business aspects of my industry and I've learned to be less of a jerk to people and how to communicate. At 52, I have recruiters contact me all the time.
Age is just number guys. Stay current, keep learning and stay strong.
>At 40, I've done some of the best work I've ever done [...] Its because at 40, I had a much deeper understanding of the tech,
The blog post isn't about self-reported cognitive ability getting stronger (or not declining). It's about the job marketplace.
Maybe it's instructive to compare/contrast different professional careers that depend on mental abilities and how age affects marketability:
- computer programming : oft-reported industry bias against age 40+ and active recruitment (especially by software companies) for 20-somethings.
- corporate executive manager (e.g. CEO, COO, CFO, etc) : age 40+ is typically the target hire age. Being a younger 20-something actually works against being hired for these roles. (To be CEO at age 20, you'd have to be the founder of a startup.)
- surgeon : age 40+ doesn't seem to bother patients. They may rather have a 55-year old do their heart bypass rather than a young 30-year old just out of residency.
Why is experience valued for outside hires of CEOs but not as much for programmers?
In other words, a 55-year old programmer would have 35 more years of experience than a 20-year old but that "extra 35 years of programming" doesn't seem to be valued as much as the "extra 35 years of managing" that a 55-year CEO candidate has. Why?
I have pet theories on that but I'd rather hear what others think.
I agree with your sentiment. I was 51 when I last applied for a job at a new company. Initially I was getting very little interest in my resume. Then I cut out the first 10 years of my career from my resume (and LinkedIn), and downgraded the oldest position listed from a Senior Lead to just a developer -- essentially making me appear 40 instead of 50. Within a couple of weeks I started getting responses.
And it is not like my work from 1990-2000 wasn't valuable. I worked on a complex large scale analytics system in the early 90's and migrated to large scale web-based applications in the later half of the decade. I'm proud of that work and have some interesting lessons and stories from that time period, but they are telltale of my age and were working against me.
From the perspective of someone who has been on the hiring side, I see this a bit differently.
Senior developer positions are more common now, in part from title inflation but also the rise of more complex online interactions and businesses. By cutting the senior bit out of your resume, you no longer look overqualified for the more numerous junior / "regular" developer positions.
While your work from the 90's is likely very interesting, for many companies the soft skills and lessons learned will be more applicable to whatever role they have available, best included as a summary.
I promise that most hiring managers aren't going to read a 10 page resume, or even a 4 page one. 9 times out of 10, they just want to answer a simple question: should the team take time to find out more about this candidate? If the first page of your resume doesn't answer that, it likely won't make the cut.
On a final note, "30 years experience" really isn't a great sign. I have indeed worked with the type of person who has basically had the same experience over and over for 30 years, not growing, learning new technical or leadership skills, etc. That is totally fine for many positions, but it is mark against them for many others.
I was told it's unusual to include more than ten years of work history on your resume in most fields. So I stop at ten years now and don't include dates on my degrees, and I haven't had any trouble. It helps that I've somewhat deliberately kept learning new things at every job (otherwise I get bored!).
And of course it's BS that this is necessary. But until the entire culture shifts I'll just keep doing what I'm doing and then telling people how old I am after I've signed the offer.
Ageism is real. It's not some sour grapes of under-performers who let their skills decline, or move or think at a dotard pace. It's essentially "We don't want anyone old because old = bad, new = good."
I think it is a lot about under-performers that want to hang onto their "years of experience" as a selling point and being angry that there is not much of a market for "years of experience" only.
Maybe they were not under-performers 10-15 or 20 years ago, but if someone gives 20 pages of resume and most of it happened in 90's I would not be interested. Because it is quite easy to see such person is hanging onto his past performance like Al Bundy to his 4 touchdowns in high school.
If someone would be 50yrs old or even 60 but his last couple of years are taking most of resume and they did interesting work at that age I would be curious to talk to such person.
It is not that they would need to have latest frameworks or libraries listed on the CV. It is more about if they did meaningful work in last year and not that they did meaningful work 20 years ago and now they are just hanging around doing whatever.
So my resume concentrates on the last five years, with the prior 30+ being mere bullet items, in the event you want to ask. You are correct that no one really cares about what you have done outside the last five years.
This is also true. Definitely can't slack off on the couch with a hand in their pants. Even someone with little experience can become perpetually stuck starting at the beginning of their career in low performance if they don't push themselves towards excellence. Slacking off at any point leads to a downward spiral of decay.
> Why is experience valued for outside hires of CEOs but not as much for programmers? In other words, a 55-year old programmer would have 35 more years of experience than a 20-year old but that "extra 35 years of programming" doesn't seem to be valued as much as the "extra 35 years of managing" that a 55-year CEO candidate has. Why?
I'll bite – I think it is because instead of licensing and regulating our profession like surgeons, we have opened it up to creativity and inclusion like artists or fashion designers.
As a result, programming job trends are far more similar to fashion or art than medicine. You always want the clothes from the hip new designer, but a few stalwarts (Yves Saint Laurent, Ralph Lauren, etc.) are evergreen and always in demand. They even end up influencing the larger trends of fashion. If you ask Ralph Lauren how things are going, he'll say "I'm 81 and I have no problems finding work!". You might even have individual designers who are discovered at 81 and become a hit. But that is not the condition for the average fashion designer who is 81.
Similarly, you'll hear from plenty of older programmers for whom things have worked out as they get older. My hypothesis is that they are also the ones who have kept up with changing fashions and paradigms.
Indeed, one of the things you'll hear from "older" developers is "you gotta keep learning new stuff" and "learn how to learn". You might find yourself with some extended contract for maintaining a legacy codebase that is too big or important or risky to migrate... then you may be "set" for some years, but that's certainly not a majority of cases I see. And... if you're early 50s and have some in-demand niche skills that might be out of fashion in say, 5-10 years, but you have work lined up right now, that may be enough to just double down and stay put, vs trying to learn a bunch of new tools. You'll still be 'behind' on the new tools, and you'll still be competing against some degree of implicit ageism.
The problem I've witnessed is this creates a perverse incentive to keep the organization using old tech even when its against the organizations best interest. I've seen developers essentially lie to non-software-minded managers as a means of not being forced to learn a new platform.
There's a lot of factors at play. Yes, there's incentives to 'lie' and say "this can't be upgraded". There's also incentives to say "this is old and is bad and we have to rewrite!" - I've seen a lot of resume-driven-development. There are people who will lie to avoid having to learn an old platform as well.
Very true. In my experience the rationale to lie to upgrade has a higher burden because it has to overcome the inertia of a status quo that has at least worked for some time.
It tends to be easier to advocate for a past solution than an unproven one.
To be fair, most of my experience is where software is an enabling function, not viewed as the end deliverable. E.g., control software for hardware. In most instances, the project managers were hardware folks and that tends to cause the problems you might be alluding towards.
This falls inline with what I was going to respond with, but your response puts a better angle on it.
I was going to suggest that the nature of software moves much faster than many other disciplines, even other STEM ones. At least in industry*, a mechanical engineer isn't as likely to have to un-learn and re-learn like a software engineer. This tends to make those industries a bit more slow moving which, in turn, makes experience in the traditional ways of doing things a bit more valuable.
I know NCEES toyed with the idea of a software engineer professional license, but it died on the vine because so few people took it up. I suspect the outcome would have been different if industry or regulation made it a priority, like it is for civil engineers.
>My hypothesis is that they are also the ones who have kept up with changing fashions and paradigms.*
This is my thought as well, but I think a lot of bias comes because of other life events. The SWEs I knew who felt left out just didn't have enough bandwidth to spend extra hours each week learning when they had many of the other commitments that generally start creeping in in one's 30s onward.
*(In academia, there's a bit more emphasis on 'state-of-the-art', I presume).
I always tell people that software development, as a career, is like being in college forever. You have to be in the learning mindset your whole career. Part of that learning, is learning technology, and part of that learning, is learning people and organizations. Organizations are very different, today, than they were in 1990. Less change than the underlying technology, but changed none the less.
> ...but a few stalwarts (Yves Saint Laurent, Ralph Lauren, etc.) are evergreen and always in demand. They even end up influencing the larger trends of fashion.
The "old" brands you are wearing are all the result of stalwart designers from the past.
Something tells me you're not in the fashion industry.
The average customer doesn't give a shit about the hot new thing, be it fashion or web framework, but the customers aren't the ones hiring talent and shaping the industry.
Carhartt produces clothes designed by others. If you look at their wikipedia page, all the designers mentioned are either old and famous, or the young "hot new thing".
The implicit assumption powering this is that programming experience from 35 years ago is not only irrelevant to today’s challenges, but undesirable due to having the wrong habits and patterns of thinking; this stands in contrast to surgery or management skills which are widely perceived to be more timeless with candidate value compounding with experience.
It’s plainly false for all sorts of reasons, but that’s the source of the disparity.
> The implicit assumption powering this is that programming experience from 35 years ago is not only irrelevant to today’s challenges, but undesirable
I think the implicit assumption has it the wrong way around. It seems like the industry takes about 30 years to catch up with the mathematicians who had discovered the solution to our problems.
We create this problem for ourselves. Some hot new web framework rediscovers the continuation monad and treats it as a novel invention. Giving it a slapping new name, a slick logo, and talks at the hottest industry events. A whole generation of developers learn to talk the talk, walk the walk, and hit a wall. The next framework comes along and suddenly they're, "too out of fashion."
Computing hasn't changed radically in a long time and certainly not programming.
> Computing hasn't changed radically in a long time and certainly not programming.
This might depend on what you consider radical.
Web forms vs MVC vs react + restful API are fairly different coding paradigms.
Trying to create a windows service in net framework 2.0 is totally different than net core 5.
Or using SQLDataReader to read executed sql strings vs entity framework?
Even just dependency injection and scope definitions (transient, singleton, scoped) is very basic yet is something I’ve seen older developers tripping over. At least it’s an easy to identify run time error as it validates the container when running in development.
I’m not saying older developers are bad, but developers with the mindset that coding now is the same as coding 20 years ago are either using a language that never developed itself or are going to stumble over the changes that did occur.
This is actually the attitude that I find highly undesirable in "experienced" programmers. They recognize that Y is just X with some fancy dressing, but fail to appreciate the immense value added by that fancy dressing and thus treat Y as if it were X and never take advantage of any of the improvements, or expect Y to do things that X could be made to do but really is best done by Z nowadays.
You're still trying to accomplish the same goals, and there are only so many building blocks, so yes the big picture stays roughly the same and its only the details that change, but the devil is in those details. I find working with people who are not only ignorant of the details, but proud to recognize that they are "just" details, to be a nightmare.
I've met plenty of older developers that refused to adapt and keep learning. On the other hand, the best developers I've known have all been older. It's not about the skills you acquired at age X. It's about you attitude towards continual learning and improving, regardless of your age.
A lot of companies are run with the Taylorism hierarchy. The people at the bottom are making the widgets. The layer above them are the managers, who are good at managing workers. A layer above them are executives who are good at making strategic management decisions that the managers will implement.
That system worked well during WW2 and postwar America. Someone who was a manager at an airplane factory could move to another company and be a manager at a washing machine factory.
While it is true that some management and people skills can transfer between industries, the big problem with Taylorism in tech is that the skillset needed to make the right management decision is orthogonal to the skillset required to get into a traditional executive role. Andy Grove, from Intel, was very successful at adopting a new management framework for this scenario as described in his book "High Output Management"
Not everyone is as a good of a manager as Grove, so you still see a lot of managers following Taylorism hierarchy. And that requires that engineers assume the lowest level of the system and accept that their "managers" are qualified to make decisions. Young people without much exposure to the business side of things are much more likely to accept these positions. Managers are afraid of hiring someone 40+, who may know both the tech side and business side of things and be aware of management mistakes due to the manager's lack of technical expertise.
As mentioned elsewhere in the this chat, I'm a 45 yo principal engineer at my current company who has seen nothing but an increase in attention from recruiters since turning 40.
I'm also directly involved in hiring for my team, having helped add 15 members over the last year, working directly w/ the director to review all resumes, handling maybe 30% of the screens, and usually the veto vote. We've interviewed a number of engineers in their 40s and 50s.
Experience is great and we're always welcoming of older devs... but there is a caveat. If that experience is tempered by a somewhat pessimistic attitude, which is often the case, there is rarely a chance to move forward. It's not being old - it's being worn out.
AFA the resumes of older devs, we often cut them out because they're an objectively terrible, wall of text mess that goes on for 4+ pages. Like 2/3 of the time this is the case.
I'm a 50+ staff eng, and I agree that I'm getting as much interest as ever from recruiters. Just gotta stay current and never take on the attitude I see from older engineers of "this new crap is just what we used to do back in the day". New stuff is different and has value, just accept it and stop whining.
As for resumes, I personally don't get the page limit, since I love long resumes with detail when I'm evaluating engineers, but understand the marketplace absolutely hates them. I don't know if it is HR or auto pre-filters or the hiring managers, but it doesn't matter. All I know is that when looking for a job most recently, I had a 3+ page resume and was getting some, but not many, hits. Then, as an experiment, I trimmed it down to a single page, making it ridiculously thin in my judgement, ran it through the various sites that judge the resume based on keywords, and came up with a custom resume (lightly so) for each posting. I suddenly jumped up to a 75%+ call back rate.
Keep your resume to 1 page, cut out the details on the old jobs unless it is really interesting, and basically just list the tech you know.
For me it’s all about communication style. I see those wall of text resumes and I see a person that is going to be a poor communicator and possibly a sloppy coder - not knowing when to self-edit and separate the wheat from the chaff on what actually brought value to the roles they took.
Detail is great but concision is greater. The resume is a marketing vehicle and it should be well honed. We can dig into what someone knows during the half dozen hours we spend interviewing them.
I understand the need to fake overwhelming optimism to get by interviewers with mindsets similar to yours. Too much honesty can be bad in this industry, especially at higher levels, where diplomacy and soft skills are very important.
I have that optimism and it certainly is not fake. I love what I do. Yes, I bring experience to the table but not bad energy.
WTF would you want to hire someone who poisons the well? It doesn't matter what the job/industry is, in what situation would that be remotely desirable?
If you say so. But just as you doubt the vigor of the “somewhat pessimistic” candidate (in your words, you didn’t say they were toxic), others will doubt the sincerity of your overwhelming optimism. So is life.
When we discuss these types of candidates, that is always the tone of the discussion.
It's good to discuss the pluses and minuses of an approach, we encourage this in our architecture section of the interview loop and during the initial screen when discussing line items in the resumes.
It's having a general negative attitude... bad mouthing past employers, being negative to a tech stack (and literally not couching it with any reasoning what-soever when we try to dig in), being negative to past arch decisions by co-workers without providing what are better solutions, things like that. Sometimes it's implied, sometimes it's more direct, but it there is a distinct lack of social intelligence that seems to happen more w/ older candidates that just suggests someone is burnt out. Wisdom should bring skill, not attitude.
Forest from the trees here. You pay someone to bring value to the team. That is not valuable to anyone. We're not running charities.
You’ll find a lack of social intelligence in the entire age range, but younger candidates seem to get more of a pass than older ones (or perhaps because the senior candidates have more rope to hang themselves with). Over negativity about past employers is indeed a warning sign (though some negativity is fine, like if you ask the question “what did you dislike about your past employer? “), but pessimism in small quantities shouldn’t be taken as an automatic negative. I would definitely be suspicious if all the opinions a senior candidate had were positive. If they can’t list the bad as well as good about some tech, they probably don’t really understand it.
"You’ll find a lack of social intelligence in the entire age range"
But this is specifically an issue more prevalent in older candidates, and is in large part the reason for a pass. We pass on younger candidates as well for this reason, but most prevalently for skill.
"If they can’t list the bad as well as good about some tech, they probably don’t really understand it."
I literally just said we consider this a positive and that we specifically dig in for this. It seems like you're willfully misinterpreting the message here, which is underscoring the point I'm actually making.
Really, what you are saying is 100% spot on, but seems to be misunderstood for some reason.
If presented with a difficult problem, there are people that go "nah, that can't be done, here's a long list of reasons why".
There are also people that go "That's going to be difficult, but maybe we can try A, B or C and I recall reading about this cool new tech that could perhaps help"
Be open to change and open to accepting that new things could be good and interesting.
I'm 43. Hiring engineers. Working with some 50+ engineers that are the absolute best I've ever worked with.
This is 100% correct. As a hiring manager, the attitude of candidates was probably equally important as their skills when it comes to the decision of whether to hire. The baseline of is this someone I would enjoy working with every day? Is this someone my team would enjoy working with every day? If it's not a solid yes I'm going to pass on you.
This must be some kind of cultural difference in the purpose of jobs. Where I come from, the purpose of work is get things done, put food on the table, and hopefully not make the world a worse place in the process. Enjoying the company of everyone you work with is not a significant consideration.
You might be missing out on a lot of great people because of your high first impression bar. And I don’t mean good workers but bad social skills, but people who are actually really chill to work with even if they don’t show it so quickly. This is why most culture fit filters really don’t work well, people have a wrong or too narrow impression of who they would enjoy working with everyday.
I can't stand the jaded senior engineer archetype. They're absolutely toxic to the junior and mid-level engineers who look up to them.
Years ago i was at a coffee shop and overheard a conversation between a college student and what had to have been an assigned mentor. This guy was going on and on about the very worst of his experiences in his career yet, in a weird way, bragging about them at the same. This poor kid was writing every word down in a notebook she had. He got up to the restroom and i walked over and politely told her this guy is only filling her head with poison and to run as far and as fast away from them as possible. She got up and left.
As long as you're not gonna be ageist that's fine to hate a certain type of engineer. Remember you will get old one day too and you'll be surprised how fast time flies.
I understand what you mean but I’m 45 and have been around the block a few times. I’m not sure if this analogy works completely but teaching someone how to climb a mountain safely is good.
Beating into the head of an aspiring climber the details of every injury/death disillusioning them of even an attempt is full stop unacceptable.
I get you buddy seems like you had a bad experience with some old dude. But you're no spring chicken yourself, you will get to that age eventually. Let's just all be humane to each other and judge each other according to merit as much as possible.
I'm 37 and wanna keep working 15 years from now...
Some pessimism is good. We're older, we've seen it fail already. Insanity is doing the same thing over and over again just in a different programming language. That's why you hire older programmers.
Why do you think they have a pessimistic attitude?
I´ll use myself as an example.
I started coding professionally at 23 (I´m 43). For years I pushed myself to be the best coder I could. At 35 I got laid-off. After that I just got sucky jobs were I´m treated like they have me there as a favor (and I work with the latest, and I´m, even with the pessimism, a top performer).
A coworker of mine that thought that coding was a losers job, coded for some months and went to work as a B.A and later as a PM, nowadays is an engineering manager which earns way more than me and is treated way way better. His whole programming experience is an 8-month part time stint with Winforms. And sadly he is not the exception...
With all due respect, there is no reason to have had sucky jobs over the last 8 years. The market has only gotten increasingly hotter... if you're in a tight spot career-wise, do the work to get into a better company working w/ better people.
If it's an issue w/ passing interviews at better companies, interviewing unto itself is a skill that should be regularly honed.
When I was a younger engineer I was stuck in a job that was unsatisfying for about 5 years... every 1.5 years or so I would interview w/ 3-5 positions, usually one or two would be close to an offer but I ended up empty-handed, would get deflated and give up.
Over the last decade I've taken the job search much more seriously, usually interviewing at 15-20 companies so I can end up w/ 3-5 offers to choose from. Yes, it's very time consuming (probably some 60-70 hours of my time over 5-6 weeks), but the quality of the companies I've worked at has been consequently more satisfying.
I've met plenty of toxic/ego maniacs/pessimistic people who were in there 20s or 30s. Sure age might correlate a bit with the pessimistic side of things but not terribly so imo.
Older programmers are judged more on their experience, a 55 year old candidate is expected to have 35 or so years of experience, but interviewing for that is tough. Instead, reputation is more important (having a bunch of people vouch for you so you be hired in as a staff/principal IC), but not everyone will have that, actually a lot of people won’t. So the 20 year old is an unknown quantity, they are all potential, a 55 year old candidate has to be the exact opposite (known quantity, not much accommodation for potential), and so…well, I’m sure we can see the problem with that.
And if you change your career late in life, you are even more screwed by these kinds of standards. A 40 or 45 year old can’t just get into the industry via an entry level position. Even if they would have a 20 year career ahead of them.
People don't look at a surgeon aged 55 asking themselves why that surgeon failed to move on to the next level. Unfortunately the same isn't true at all for programmers, for some reason it's assumed to be an entry position. If the path to surgery would be through nursing experience, aging nurses would have a much lower standing amongst all their future surgeon peers than they have now.
Seen from this angle, the ageism seems to be an unsurprising outcome of the relatively informal qualification structure in software tech: apparently opportunity for all cannot come without a bit of stigmatization for those who refuse to strive for it.
Is it because large swaths of the industry use non experienced people to do the hiring? Experience values experience. Lack of experience values perceived longevity, ability to pay less, and zeal.
Also, age is not experience. Age is usually an ingredient to experience (though some make use of less age than others to gain experience). But in and of itself, it does not create useful experience (maybe wisdom is the word we’re looking for here). I’ve worked with many older engineers who hadn’t gained useful experience. They’re still making the same mistakes they did years ago. And I’ve worked with younger engineers who I can tell are going to be old dinosaurs from the get go. They like the high paying career and the problem solving aspect, but the desire to evolve and improve their game play just isn’t there.
Because let's face it: writing code is seen as digging trenches.
I hear all the time from fellow developers how important we are. We get a lot inside jokes how non-devs don't understand things and all the self importance of devs that comes with it.
I have a friend that is hanging a lot out with musicians/artists where they do the same thing as devs - thinking they are important.
While developers earn more than musicians - a lot of musicians are just menial workers performing what they are told - coding is still menial work to be performed. So it is implementing other people ideas or they can just get another violinist.
Surgeon while is quite physical and menial, everyone agrees it is occupation that deals with life and death - most developers are nowhere close to such responsibility.
Ok, but dev managers are also managing people digging trenches, not people in life and death situations, and they don´t face the same problems devs face. And they tend to be more "self important" than devs.
> Why is experience valued for outside hires of CEOs but not as much for programmers?
In my experience, it’s that younger devs are cheaper, much cheaper, than older devs. Most software development is easy enough that you don’t need someone with 20 years experience. I can hire 2 or 3 people for the same price. There’s always a budget for resources, and that budget is usually as small as it needs to be. Web dev, CRUD apps, mobile apps are the norm, not Facebook scale. The tools are mature enough that a 20-25 year old can do the development, and their salary expectations are much lower.
> The blog post isn't about self-reported cognitive ability getting stronger (or not declining). It's about the job marketplace.
C'mon! You don't expect someone here to have actually read the story.
He didn't even get the irony of the title (Usually the expression goes the other way, i.e., "50 is the new 40") which means he didn't even read the title too well, either.
- computer programming : oft-reported industry bias against age 40+ and active recruitment (especially by software companies) for 20-somethings.
I think this is rational. 20-somethings have the least to unlearn, so you can get them to do things your way instead of the unique independent ways an experienced person would.
Secondly, 20-somethings are much more easily abused with long hours and intangible or possible future rewards.
20-somethings are also really fun to work with. Sponges for knowledge and so much energy.
I think the (sometimes justified) fear is that an older programmer may have stopped learning X years prior, and gotten stuck in old practices. It's probably really easy to fall into a groove and say "it worked back then, and it still does". This attitude may be detrimental in a workplace that strives to innovate and wishes to test new technologies.
Experience at that level is expensive and companies are less inclined to pay that much. They also are less likely to believe you'll be comfortable with taking a lower rate for a long duration. This is true for both CEO and high end programmer with decades of experience.
I’m 45 and have never gotten more attention from recruiters, despite the fact I entered the job market during the height of the dot com era. My graduation date is clearly marked on all resumes in circulation, as is my experience showing my first internship all the way back in ‘96.
It’s not only the number of ops that hit my plate, but the sheer aggressiveness of the recruiters. Very often am I contacted repeatedly, sometimes up to 5 times, by a recruiter for an op. Many times it’s directly by the hiring manager, the director, cto, or even ceo of the company.
In fact, only in my 40s have most of the major tech companies reached out to set up interviews (Google, Facebook, Amazon, and Apple), and a ton of pre-IPO unicorns. During the pandemic I had the former CEO of Zelle personally interview for his new venture and Brian Acton personally reached out to schedule an interview for One Signal.
I’m just a principal dev who does React and Rails. Been a tech lead in a few startups, never held a title above that, never a de facto people manager and certainly not a director.
I remember the sheer terror I was feeling toward the top of the my 30s because of discussions like this on Hacker News. Had a taste of management in my early 30s and decided it wasn’t for me, and remember toying with ideas for a career switch because surely, I would be dead as a programmer soon. The exact opposite happened.
The key here is Principal. 40 plus is considered fine and good for Architects/Managers and people in leadership positions. Try to get a senior engineer or below job where you are expected to be grinding out code instead.
About the same age as the one you are replying to, usually the best way to work around that is consulting, where you are expected to be business analyst, architect, devops and coder in one package.
Granted, not everyone enjoys doing it, and it comes with lots of politics as baggage as well.
I was a senior at my last 4 roles - IOW, I was a Sr. dev turning 40, and didn't get another higher level role until turning 43.
But yes, I have that experience in my background. I had my first principal role back when I was 32 (but prior to switching away from .NET development) and 2 other lead roles in my 30s.
So we're just going to move the goal posts then? Yes, having desirable skills is a given.
We have a bunch of .NET devs (our BE is .NET) and the average age of these folks probably right around 40, because in general they're going to be older devs who do that.
Even if they're taking the spray-and-pray approach, it certainly doesn't look like they'd be filtering for age. To compare, I'm 43, not even a tech lead and I've received more recruiter contacts over last couple of years than the 20 years before. Many of them were even somewhat relevant to my work experience.
Most refer to specific aspects of my experience, some specifically referencing my current role (ie. they've read my LI, which also clearly shows my grad date)... some are spray and pray. Probably 80% of things that come my way are applicable to what I do both in skillset and title (Lead/principal/staff/director roles).
Does it matter? If there is some way that recruiters are filtering based on age, my age is clearly discernable.
At least some of these are auto-filled templates with scraped data -- I got one where "I was really impressed by your experience at ." -- yes, just a space and a period. Probably slightly modified from the defaults provided by a hiring CRM platform. You can tell the ones that really are different, because they mention something a scraper or AI wouldn't figure out.
During my last job hunt a little over three years ago, I encountered what I think was some subtle ageism or at least discrimination based on family status (lots of questions about my family life when interviewed by the CTO and CEO, ultimately turned down because they didn't think I had the energy/disposition to be devoted enough to the company to put in extra effort when needed).
I ultimately got a job at a better company anyway and probably dodged a bullet, but it's pretty naïve to think it doesn't happen sometimes, especially at startups or places that pride themselves on a "startup mentality."
I (closer to 50) always straight up say I've got two young kids and that I partake actively in their upbringing. One of them with special needs, even.
For me that helps filter out workplaces that would not be a good fit for myself.
There are a number of workplaces where a good balance is actively supported! When needed, everyone will put in extra but the expectation and in fact reality is to keep things 9-5:30 as much as possible.
Legal: "we don't think you have the energy/disposition to be devoted enough to the company to put in extra effort when needed"
Honestly, I'm surprised they even gave a reason. Our HR department has an email template that we must use, which is something along the lines of "we picked someone else, but we'll keep your CV on file, in case anything else opens up". You don't have to give a reason, so if you do, you're only opening yourself up to liability.
Yeah honestly I was surprised too... it was a while ago, so I don't recall if I asked for the reason, or if they volunteered it.
Like I said, I personally see it as dodging a bullet. I probably didn't want to work in that kind of environment anyway. But there may be other people with different situations than mine who would've been rightly miffed by it.
I'm pretty privileged as things go, so I tend to not complain a lot about ageism and discrimination based on family status because there are a lot of folks who have it far worse than I do (even though I recognize it as a legit problem and feel like I've seen it firsthand). This company sorta tipped their hand without saying anything illegal.
Yeah, it is, but honestly what am I gonna do about it? :/ I suppose I could've reported them to... somebody? Sue them for a job I didn't even really want?
In retrospect I probably should've left a bad review on Glassdoor explaining what happened, but it was so long ago I just sorta forgot about it.
The point isn’t that techies over 40 can’t do good work or keep current or invent the future, it’s that they can’t get a job.
As someone a few years north of 40 and recently went looking for a new job, I can identify with much of the article. Although for me, in the market I’m in, I kinda felt the pay for a ‘senior dev’ didn’t really cut it either. The whole pay structure is for younger folks and veterans have a hard job finding work.
I'm in the same boat. Also "senior dev" doesn't mean what it meant 10 years ago. I just had a really quick chat last night with a engineering lead. The position was a "senior dev" with 5-8 years experience in multiple things. Usually those are taken is minimums. They were actually maximums. He was surprised I made it past the initial recruiter screen having 20+ years experience. We thanked each other for our time and said so long after just a couple of minutes.
SV has sort of broken the job search, especially for more senior people. It's not just JR/SR anymore, it's some weird mashup of: Staff, Sr Staff, Principal, Level 3-5, Distinguished... Every company out there is pretending they are a FAANG when hiring, asking for 4-6 hours of your time. I'm working full time with 2 young kids. It's a nightmare.
One has to adapt to the biases and reality for survival. Lie about your age if it ever comes up. Lie downward about your experience too. Fuck their discriminatory bullshit.
i know a career-agent from a job-center that told me the same thing after he had witnessed many qualified and experienced engineers beeing rejected because of age- or buzzword-based discrimination.
> I worked with someone my age who only strong skills are a large enterprise storage system. He is a dinosaur and his future is limited.
At 52, that can be a good move, if that enterprise system will be around somewhere for the next ten years. Remote work makes it an even safer bet. During that time, he can devote more attention to his family, community, and hobbies, instead of trying to make sure he is employable by the maximum number of businesses. You only get paid for one job, no matter how many you're prepared for.
Getting closer to 50 here and finding value in looking after my health. Quit all alcohol nearly a year ago, kept my lifting steady and am now getting close to setting some life long PBs for strength. (Barbell Prescription, garage gym).
This has really helped ground me and keep my focus in tumultuous times.
I feel like my tech and ability to see the bigger picture is only getting better. And I still maintain the same child like joy of tech that I had when I opened my Vic 20 not too far away from 40 years ago.
Indeed, I keep being a jerk to junior developers that constantly comes to me with the same questions after I explained to them 10000 times and they say "Yeaah, I got it now". It is so hard to avoid being a jerk. What should I do?
* Ask why they keep coming? Maybe you aren't understanding their question, they want to build the relationship, or it's a really risky operation and they don't want to undertake it alone. This might be worth digging into.
* Write the answer down to the questions (wiki, internal doc, whatever). When they ask, point them to what you've written down. Will still take some time and interrupt you, but hopefully they will learn they can just go to the doc.
1st, you need to help them get the RCA on why this question, and what context (that isn't often brought up). Its often that framing the question in context elucidates the actual problem they are working on solving, and they are seeing a misfit in concepts with the solution you've gone over with them. This is one (of many) areas where being a senior (experienced) dev/manager/leader is so critical in developing the less senior folks.
2nd, curation of notes, experiences, techniques is absolutely critical for team capability growth. Capture the problems, explain the use case/back story, explain the problems in explicit detail, explain the thought processes around the solution, and the solution. Cut-n-paste examples help. I did this when I ran my company, and found that it was quite helpful to the team. And they followed the example, and documented their own efforts.
Please don't be snide or dismissive with the less experienced. One of the reasons I see many orgs hire older/senior folks is to provide a calming, thoughtful, intentional influence on other team members.
As others have pointed out here, you need to continuously grow, learn new skills, add new capability. This should be a given. I don't want to bring "lifers" (people who hide in a company, doing only one thing, never interested in developing). I want to bring curious, intelligent people, with capability, and experience. Or if lacking experience, then a strong attitude of wanting to get their hands dirty.
About that first point, that to me seem like a genuine and emphatic thing to do but I want to flag that this has the potential to go into the "soft" areas where feelings exist. For a crash course in "feelings and needs" read non-violent communication to be appropriately humbled by how hard (but important) this skill is.
I agree. I have a whole blog[0] about what I wish I had known when I was a new developer. Those "soft skills" (which are actually pretty hard) come up again and again as something I wish I'd known earlier.
It seems trivial to you, but only because _you know to trust the message and what’s written in the wiki already_. The hardest thing about documentation is establishing this chain of trust. By coming to you and getting a verbal confirmation they establish one tiny link in that chain.
Edit: just thinking out loud here. These error messages are equivalent to a random passerby without any skin in the game saying “oh just run this command” — how would one trust them when their job is on the line? I can think of a few common approaches:
- “oh just run this command because paragraph 1.2.3 in the universal code we all agreed to says so” (easy to confirm)
- “oh just run this command because senior engineer X said it’s safe” (assuming you believe that they did say that)
So maybe the error messages should include some equivalent of those.
Just now, one of the junior develops contacted me about a problem trying to start an application we are developing. I asked: "Did you follow the instructions in README.md file?". He said: "Yes". Then when I asked for him to show me the error, I could see he clearly had not made one of the steps in README to start the app. Just to confirm I asked if he had done it and he said: "No, maybe this is why I am getting this error then".
The problem is not reading, it's trust in the information. You telling them that the information is up-to-date and valid and useful is the reason why they read it.
I was the only English-speaking TA (&, thus backup lecturer) to "Intro to C 101" at a major mass-population state university. Class sizes were ~800 students. I had an open-doors/open-lab/open-office policy. By the 4th semester, I remember laying on the floor in front of the class, and yet another bro (blond hair; blue eyes; chiseled jawline; backwards cap) came up to ask me a, frankly, very well thought out question — and I just said "I know I've taught this to you, already". I had; I'd taught it to him & all his bros for years.
What's the quote? "Every year I get older, but the junior devs stay the same age."
> I remember laying on the floor in front of the class
Is there a nuance to this I’m missing? If my professor suddenly decided to lie down in front of the class I would not casualy amble up and ask a question, I’d be more likely to call an ambulance or burst out laughing.
I had 6 identical lab (secondary teaching) sessions per week, each 1 hour long. I handled lecture once a week, for two blocks of 400 students. It’s the equivalent of a decade teaching per school year.
This note makes me again feel industry was the right choice for me. In industry, the value of people asking questions is you get a very accurate way to identify talented people - by which I don’t mean gifted people but people with the understanding, curiosity and confidence to drill thru a brick wall in the way of their goal with the subtle arts reasoning.
Write a knowledge base, or Wiki, or FAQ, or whatever. A place where they can re-read the same thing 10000 times. Maybe add some examples too, in cases where it makes sense (i.e. code).
Even better, make them write it, and you just review it. It'll help them learn faster.
If you have a junior who already understand problem X, ask them to explain it to someone else too. It'll help solidify the knowledge, and at the same time offload you too.
Take my comment as wisdom that came with age and experience, if you will :). I don't think the above would have been my first thought 10 or 15 years back.
One approach I have been experimenting with is copied from surgeons: see one, do one, teach one. We have documents and so on, but for novel Devops-ish rocedures, I will document it, but then pick some to watch on screen share, then the next time they will drive, and I will watch their screen share, then the next time they will demo to another person. It is great for tasks in between we do it every day” and “we’ve never done it before”. Also it builds confidence (and often the docs are better after the train gets a good writer as the see one person).
Make your rate of responding be proportional to their demonstrated ability via questions. At my last job, there was one person that would always ask, not simply new questions but new types questions. I would immediately get back to her. There was a group of people that would always ask a new question, generally either due to a lack of understanding of something or it was a real interesting bug. Them I would return to at the next break. Then there are the people that have no interest in learning how to fish and just wanted a fish. I would slow down responses quite a lot; when they escalate they are introduced to the ticketing system or Jira for assigning fishing tasks to the team.
There are people with such interesting questions I am happy to hear them and talk them they even from three jobs ago. I cultivate them, as these questions extend my detailed knowledge farther than it otherwise would extend.
I think this needs to explicitly be handled by a role in the team. A common team might comprise of a project manager, architect, 1 to 4 more senior devs, some representation from a test team, and a number of juniors, interns etc.
One of the senior devs needs to handle onboarding new people and communicating the ideas of the architects and seniors over and over again to juniors. This is tiresome and boring to some. You need patience and empathy. It can be fun though as you get to meet lots of people and help them when they need it most. Most importantly you give the other seniors the time to work, without them getting involved in yeah just "make clean build" that away type issues.
I actually like the role and if the team doesn't have too much churn, you're just another senior dev.
Unfortunately, it is not only me that has these problems. But I agree that I am not the best teacher in the world. However, I do believe that they are not trying very much and keep calling me or stopping the team with meetings for small problems. I get it when you are new to the company, but for god's sakes when you have 2 years+ and you still keep asking trivial questions, there is some other problem here.
We keep telling people "there are no stupid questions - please ask before assuming anything" then get annoyed when they do exactly that ;)
Though I do get the frustration. I had similar with one of my juniors, and it took me ages to work out that his learning style didn't match with my teaching style. I ended up having to go right back to basics and walk him through everything painstakingly slowly.
I know :D
But, I am only get annoyed when the questions are recurring. I think there should be more effort from the developer to learn by himself if he does not get it from us explaining 100 times, then.
Stop giving them the full answer and only lead them part way there. They will then (hopefully) learn how to look up documentation for themselves. Essentially "teach a man to fish". They don't necessarily want to know the answer, but they want to know how you know the answer.
That is what I am trying unsuccessfully to do. I made a sugestion the other day and did not write the code. He understood the idea but implemented poorly. When I asked why did he implement it that way, he said "it was your suggestion". I tried very very hard to not explode here...
Explain why the implementation is poor, e.g. if there is an unperformant loop that will struggle with large workloads, point that out and ask them to write a test to simulate this, then fix the implementation.
That is what code review is for. It shouldn’t be personal, it’s just here these specific changes will make it more robust or easier to understand or whatever.
"I worked with someone my age who only strong skills are a large enterprise storage system. He is a dinosaur and his future is limited. That's not his age, its the way he chose to build is CV."
I suppose everything is a choice. I have worked on tech that doesn't have a future because the company needs someone to fill those shitty positions. I naively believed the company when they talked about them taking care of employees and being able to make a career out of it.
Yea, don't do that. Being able to sell your story to other tech people why your past projects are fun, interesting and maybe hard makes life so much easier and for the most part makes working more fun too. That doesn't mean every moment has to be amazing and developing but if it rarely is you're painting yourself into a corner.
My understanding is that you are exactly right. It seems to be common that we tend to stop learning and pushing ourselves, get comfortable or maybe even afraid. To each his own, but I think it is more fun and fruitful to keep at it.
So does keeping up with all the latest hotness when you already know it won’t fix your organizational problems.
Hell, I’m only 33 and when asked today what I currently want to learn, had to seriously consider that I didn’t want to learn anything new in particular.
I would feel more inclined to continue to "learn" (read: pick up shiny new frameworks, not actually learn new fundamentals) if the new stuff wasn't just rehashed old stuff. If I need to pick something up, fine, that's trivial, but "learning" for the sake of "learning" is best left to the juniors.
I tell them the truth: I wanna go deep in my stack (Ruby) to the point of learning C and VMs to understand how the Ruby interpreter works. This is what interests me; I really can't see how learning Node or Elixir is gonna make a better programmer than what I want to do.
As I understand the research the "struggle" is more cultural than inherent/biological.
It just so happens that a good chunk of people tend to stop learning and pushing themselves for what ever reason. But if you keep at it, or get back to it, your brain adapts over time and becomes more flexible to to speak.
And by "learning" they mean things that are just slightly outside of your comfort zone.
Anecdotally, people who do that for a very long time, tend to be really smart and interesting I found. It's such a wonderful thing.
Learning is hard - you are pushing the plasticity of your brain. It is like cutting grooves into your brain - but fortunately the experience of insight when you understand new things is quite pleasurable. I think it may take more “conscious intentionality” to choose that discomfort as one ages but it is surely worth it for a life of pleasure. I won’t say learning go channels and go routines was as big a sunflower burst as call back event based programming in C was as a young man, but it was unmistakably cool. Even learning the thought behind all the god-forsaken Java patterns or the dumb borrow checking for Rust make me a larger thinker and better reader and listener to technical ideas.
A life of constant curiosity and willingness to tolerate the pains of learning is a lifetime of childlike awe and playfulness.
How much do you need to learn though? Why not settle for .Net or Java or Node or Django or Rails (if doing web)? They didn't change that brutally in the past 10 years. Sure, there are changes, but nothing that 2-4 hours of catching up monthly won't fix.
I think the issue becomes worse when you change stacks a lot, that isn't very sustainable to me.
Still, despite ambitions and knowledge you are less employable in the eye of HR/Recruiters. They seek very specific set of current tech stack and very recent experience posessed, as well as familiarity of specific management styles just yesterday, for specific tasks. For cheap! On the bulk. Ability to push them around and lower tolerance to eat any bull*t fed to them by (potentially incompetent or clueless) management is also highly valued.
Ideally more senior emloyees worked in multitude of situations and team structure and project is better for productivity, they also have more even performance in long term, but hiring practice seems to be unideal.
Perhaps they have a shorter attention span in mind, promoting replaceablity over long term stability and predictability?
You're not. It completely diminishes the whole point. I have met many younger developers who went through different struggles and are more mature than most 40-years old.
Opposite ageism is also real, this one is a proof of it.
There are many companies that don't want to hire people over 40. I applied to the same company with 2 identical profiles, in one I gave my real age and in one 10 years less, I got invited to an interview on one profile and rejected immediately on the other.
Even my company rejects experienced hires if the job description is not specifically mandating senior-level experience. I just hired one such person that is a bit over 50 years old, I had to fight HR on this.
OP should have had offers pouring in: "using and teaching Python for over 20 years, and designed its built-in set module, but nobody would hire me as a Python programmer when I was laid off by RStudio in February."
If OP can't get an offer(for Python!) then something is really wrong. Where? Possibly they could not get past some silly HR filter.
If you were a Python shop wouldn't you want to have an interview with OP would you?
There is an advice floating around HN that one should contribute meaningfully to some popular open source project and/or write a book about something -> leading to better career prospects.
The above might be helpful but clearly not sufficient. (I've seen good book authors still looking for job prospects)
But still, what is your added level in say Go over a 35 year old who does Go for 5 years already?
Wouldn't it have been better to just stick to one or two techs throughout your career?
Better in what way? Only in ways that make people old rather than ways that make people young. Here is a repeatable path to security.
And say I am only just as good as the newbie in go. Isn’t that fine? I am seeking the pleasures of learning and learning with other smart people, not trying to win a contest. My method to do that is find problems, without a recipe answer, for technology problems that my employers are facing. But the motivating goal is to learn new things and build new things.
> And say I am only just as good as the newbie in go. Isn’t that fine?
Depends on how expensive you are, what the market is like, how well you compensate in other areas (people skills, analytical thought etc) but all in all the market will prefer the 35 year old because our industry is somewhat shitty and ageist. It is what it is. However you will have a very strong network for having worked so many years so you can probably easily overcome this.
The question is one of perception, trends, hiring - not one of materiality. In fact, the point is really about the likely dissonance between perception and reality.
> It's absolutely possible for a 25-year-old to be a more experienced, more technically competent, and more mature than a 40-year-old.
It's also absolutely possible for a pig in a jetpack to fly past your window. Many unusual things are possible, but that doesn't make them any less unusual. In the vast majority of cases, older developers will have more experience and be more mature than younger developers.
No I'm arguing against ageism. I'm over 35 myself.
I'm just realistic that having been alive a long time doesn't automatically infer wisdom like people think it does. Someone who's spent 20 years not really learning anything or bettering themselves can be behind someone who's spent five years working hard.
They said:
> at 40, I had a much deeper understanding of the tech, I understood of the whole business process and I had the maturity to deal with people in a productive way.
Understanding tech, business process, and maturity don't necessarily take a long time to learn. Someone can spend 20 years not bothering to learn these things, while someone who's worked 5 years can have mastered them.
Highly effective people can be young. Don't assume you'll have more of anything compared to them just because you've been around for longer.
I took the gist of the original post as saying they didn't agree with the original article and didn't think age was the defining factor of employment problems at 40. That, by developing and demonstrating relevant skills they hadn't found there to be any problems.
I took the quote as meaning that certain skills take time to master and it's impossible (which I took to be hyperbole) someone with less time would be able to master /all/ of the them; reinforcing their first point about how someone who is older should find it easier to find employment.
Yes, a 25 year old genius developer can be as good as a 40 year old average developer and better than a 40 year old subpar developer. However, geniuses are, by definition, extremely rare, so it should be self-evident that the heuristic is generally valid.
> I focused on learning new tech; Python, Go, Kubernetes, Cloud, etc.
OK, but it's also completely legitimate to just say, "I already know Python so now I just want to focus on building better and better things each year, not getting better at tech." And yet that won't make you employable, even though it's probably the ideal strategy as an entrepreneur and product creator.
The really interesting question is whether you and the other N guys replying claiming that they're enjoying good careers are an outlier or the typical case.
Based on the multitude of threads and articles about ageism posted on HN alone and what we know about ageism in general, I'd say it's the former, but I'd be interested to see if someone actually studied this.
>only strong skills are a large enterprise storage system
Are you describing uploading data to and S3 bucket? Or maintaining tape decks? Depending on how to interpret this, this could be an advanced skill.
For context, I'm learning about how to build a Data Lake that supports a Feature Store for an ML platform. Feature Stores are relatively recent (4ish years?) and only make sense in Enterprises
At 40, I've done some of the best work I've ever done and my pay has been better than ever. I'm 52 now and the trend has only gotten better.
Why? Its because at 40, I had a much deeper understanding of the tech, I understood of the whole business process and I had the maturity to deal with people in a productive way. You won't find all of those in a 25 year old developer.
The only way that age becomes a detriment is if you do not grow. I worked with someone my age who only strong skills are a large enterprise storage system. He is a dinosaur and his future is limited. That's not his age, its the way he chose to build is CV.
I focused on learning new tech; Python, Go, Kubernetes, Cloud, etc. I've also spend a lot of time learning the business aspects of my industry and I've learned to be less of a jerk to people and how to communicate. At 52, I have recruiters contact me all the time.
Age is just number guys. Stay current, keep learning and stay strong.