I just turned 40, and I do feel fortunate that I look young. But then I was also recently hired, by a 70 year old who is still himself programming for hire, to make some quirky database code work .
Perhaps this is an unpopular sentiment, but after 33 years of programming I have been observing more and more how many elements of a supposedly hyper-rational field function like religious beliefs or memes. I suspect that one reason people prefer working with young programmers is -- sometimes -- that they don't want push back on the beliefs that are underpinning their enterprises. To take a few simple examples, people with a lot at stake don't necessarily want to be told that something will probably take 3x longer than they think. Or that there are some philosophical issues at play in their strategy.
A truth that can hurt: people generally only consult nerds when they believe they have no other choice. To many people this means they only want programmers for "code monkey" style coding, i.e. I think there may actually be preference for inexperience in the wider world.
I'm sure age will take it's toll eventually, but in my case there is no doubt in my mind I write better code now than, say, 10 or 15 years ago.
Fortunately, there's a solution: freelance and work for people without these biases. It seems like there is no shortage once you leave groupthink environments behind.
I'd echo this, and while this may sound curmudgeonly, too many people either want easy solutions or have shiny new object syndrome. These traits often flourish in the software industry because newly available "solutions" present themselves faster than any one person can even learn their names.
To use an analogy, I refuse to believe the roads would be safer with a bunch of drivers all learning while they go.
But there is a difference between learning as you go from a point experience. For someone with no experience, you make a lot of silly errors, or at least errors that more experienced people know not to make.
Its not like many of the new languages are THAT much different. 90% of work is still done in C, C++ and Java
How many drivers on the road today are still learning after a billion miles of driving? The ones I meet feel like about 100 miles when they are 16 is "good enough" experience and stop learning.
when learning new tech now i find myself determining best practice pretty quickly and it's very comforting (like whoa, how did i know this!). I was never a fast code ninja, and now even less so, but can generally come up with a stable implementation of v1 that will run in production with no surprises and even email me all relevant details if there is a problem. I realize that this is more suitable in corporate style coding than startups which need to test ideas fast and evolve or evaporate.
My own speculation: The obsession with metrics both made it so that globocorps accountants want to hire the cheapest programmers they can, then managers want to leverage metrics and methodologies to to try to squeeze non-busted code out of those subprime workers. I compare this to the distant past, when the tools and languages were worse, but there were fewer programmers with more skills, and the produced things like working, extremely safe aircraft control systems that by the 90s couldn't be replaced for less than a billion dollars and still didn't work right.
I have never considered software to be a rational field (or "art"), I think that is just one of the myths we tell about ourselves. It's its own thing, with bits and pieces taken from many other human endeavors, honestly that's why I like it so much.
I guess in these days of profit free, investor financed startups, keeping faith and a belief in the vision can be more important than delivering. For a while at any rate.
There seem to be more articles about age popping up on HN lately. I find this both weird and disconcerting. As I wrote in a comment in another thread:
> This is idiotic. People over 40 trade one set of skills for another (source: I'm over 40). You lose short-term memory, can't juggle too many things simultaneously, and aren't always up to date on every latest fad. But what you gain is fantastically valuable: intuition, abstract thinking, systems thinking, ability to detect patterns in large systems, ability to notice that certain problems have been solved in a different field, and lots more. As I grow older, I notice these changes, and while I do regret not being able to remember IP addresses after switching to a different window (get a larger monitor, or just copy&paste), I am very happy with the overall shift.
To put this in other words, as I age, I found that yes, I do have less ability to do brilliant-late-night-ninja-coding stunts, but overall what I gained translates into Getting Things Done. Which is why I find this ageism trend mindboggling: is there a CEO out there that doesn't want his company to Get Things Done?
To give a tangible practical example: I just wrote and launched PartsBox.io (https://partsbox.io/) as a side project. I could only do it in the time constraints involved because I knew which shortcuts I could take and which code I should not write. My 25-year old self would likely have written brilliant ninja code (that no one would ever see), but would never have gotten the project shipped.
> There seem to be more articles about age popping up on HN lately. I find this both weird and disconcerting.
Not so weird.
We're now 30+ years from the dawn of the desktop PC marketplace. 20+ years from the dawn of the web and associated original internet startup mania. 10+ years from the post-collapse web 2.0 resurgence with Ajax and frameworks. Pushing a decade since the introduction of the smartphone.
Every bright-eyed twentysomething that could bask in the glory of their wunderkind youth at the start of each of those eras -- everybody who knew PG was talking to/about them in his essays -- has now wound the course that time dictates everybody's gotta take: they arrived at being older.
So of course there's a lot of interest in what that means in the software industry. And maybe some rueful reflection from some participants on what they thought that meant when they were younger.
"but overall what I gained translates into Getting Things Done. "
This. I don't pump ridiculous amounts of code, but what I do, Works, and is mostly bug free or easily repairable. Thus I have a reputation as a guy who gets things done.
Companies should really be aware of the maintenance overhead caused by fixing old badly done code.
Maybe it's the market dynamics. Most code bases are new (their age is not measured in decades) so the organizations have not gained the institutional understanding what a sinkhole of profits badly executed code is. Some companies use this as a business model an charge "maintenance costs" and such things so there is also the pathological motivation to maintain this status quo of "implement cheaply, fix expensively"
I have a developer friend in his 50s. He writes the most solid code I've ever seen. I'd be surprised if one of his services hits a major bug in production.
However, there's a slight problem: We don't need that level of solidity. The rest of the stack is comparatively less solid, so his time would be better spent getting ten easy, frequently-hit bugs out of the rest of the codebase, rather than get one unlikely-to-hit bug out of his.
He hates producing code that's not up to his standard, but when our fleet of cars consists of a Lamborghini he built and a beat-up Yugo some other guy built, I'd rather my friend changed the rusty oil of the Yugo rather than make sure that all the bolts on the Lamborghini are within tolerance.
I 100% agree with this: the lesson to be learned from getting older and being burned by bad code is not that no code should ever be written badly, but that you should learn how and when to care, and by how much. I think too many experienced programmers have been subject to problematic code that they pre-emptively try to make everything bug-free, and very often times that's a huge opportunity cost.
> Companies should really be aware of the maintenance overhead caused by fixing old badly done code.
This is a fascinating theory on programming ageism. It's common knowledge that most software buyers undervalue tech debt and the costs of maintenance/upgrades. That presumably translates for less interest in planning, experience, and thoroughness compared to speed.
And most of that isn't controversial, but I rarely see it raised in the context of preferring young and inexperienced devs. I suspect there's at least some truth to it, because highly self-aware software companies seem uncommonly willing to poach older experts.
I am under 30 but ageism scares the shit out of me.
I love to build things and I am not keen on sliding into a management position. But this becomes the easiest career path once your soft skills start to increase to the detriment of raw coding skills.
On the other hand I've seen enough engineers with decades of experience who said no to going into management and who are now basically irrelevant.
Both these outcomes are scary but they seem to be the defaults for someone who goes with the flow.
I just turned 50, and I still code and still love it. Like other people here have pointed out, keeping your skills up-to-date is key, and making a conscious decision to stay coding instead drifting into management.
A good way to stay relevant is to change jobs now and then (maybe every 5 years or so), and also using your own time to learn new things.
The problem with keeping your skills up-to-date is that many of the skills listed in laundry list job reqs are in things that have only existed for a few years. They're things that a sharp college kid can be just as knowledgeable about.
Yes, definitely possible, kudos for pulling it off! But it requires careful long-term proactive decisions and actions. Which is not what most humans are particularly good at. That's why I used the word "scary".
When you are a junior engineer you just crank out code and the level and employability of your skills automagically increase. But after some time this free lunch quietly stops. You suddenly have to manage your career.
Right. People should be less concerned with competing with people in their 20s and more concerned with how they are going to keep up with the other people their age who instead of doing fun, hacker, startup stuff and chasing money spent their time being the "stupidest" person in the room and learning the (an) industry.
"Sliding into management" might sound like it's an easy path, but it's an entirely different profession. Only those who are interested and have the ability should ever consider this route.
Recently turned 31 and I too am scared of it. I think all software engineers / devs should think about FI/RE (financial independence / early retirement).
Or at least get setup, so you have money in the bank. You never know when you might need it later on in life. If you do experience tough times, for finding a job.
Beyond getting things done, I read recently that older, experienced developers shape culture. It is really true, and I didn't realize it until recently. You have much more obligation when you are older to act in the way that you want your team to act and approve what you think should be approved. You are usually a mentor and role model whether you want to be and think you are or not, and you can't just work hard and that rub off on your team; you need to show them how to help themselves rather than do their work for them, otherwise you're setting yourself up for problems.
"... I do have less ability to do brilliant-late-night-ninja-coding stunts,..."
Isn't this an advantage as well? How many ninja stunts have you seen without hundreds of bugs and being easily integrated into existing stuff and not requiring to change many existing things because they don't fit anymore with the genius code (and thus replacing well tested bits with alpha quality code)?
Being older helps to plan well before you code and get a result that does the job. As you said: getting things done.
Even long ago, I discovered that once I reached a certain level of tiredness, it was pointless to keep coding, because after a night's sleep I'd realize it was all garbage and had to revert to a previous version.
Past that point there's no possible justification except "I need to show something functional to someone tomorrow".
I confess that, once upon a 5 A.M., I thought it would be clever to store X-Y position values not as a tuple but as two halves of a single int. There was a reason, but looking at it the next day there certainly wasn't a good enough reason. That set my low-water mark for coding while tired.
Yes, this. And that goes even if one is already awake due to insomnia: one owes it to oneself as well as to one's colleagues not to write code when one's mind is not in tip-top shape.
>How many ninja stunts have you seen without hundreds of bugs and being easily integrated into existing stuff and not requiring to change many existing things because they don't fit anymore with the genius code (and thus replacing well tested bits with alpha quality code)?
I am familiar with the stereotype you're referencing, and have seen it from myself and others. However, to genuinely answer your question of "how many ninja stunts have you seen without hundreds of bugs..." I must answer: Many.
For the first 3 years of my company's life, I a full half of the code was done as "late night ninja coding". In between getting steady work done, I would often think about a few harder problems/features/projects, and take notes from those thoughts over a few days/weeks,on what would be the best method of accomplishing said problem/feature/project. I called it the "think twice, code once" mentality.
Eventually it would culminate (almost always in the evening) when I would either realize one last detail that made it all click, or realize that there was nothing left to plan out, and it was time to dig in and code.
Cue an overnight session where all of that planning would be brought into reality. With tests.
Even now, when my lifestyle and product allows for less of this, I still do so occasionally and it brings me great joy, significant productivity and very few bugs. Think twice, code once, and of course YMMV.
Yes, some of us have been around long enough to know that implicit declaration of variables is a bad idea, not a brilliant one overlooked by everyone else :-)
This is pretty much how I feel these days. Short term memory is nowhere near as good, (a problem solved by pen and notepad to a degree). But far better skills around the bigger picture of writing an application.
I am 54, a former CTO, CIO and current CTO and love to code. I believe "now" is the most exciting time in tech ever (and I started on mainframes, went through client server, n tier, web and whatever we are now). I believe open source is truly changing the world in a massively positive way. I'm sure someone younger could do my job, but I think "perspective" matters. I love learning and just moved a bunch of production workload to Kubernetes. Not sure exactly why this touched me the way it did but I dread the day I hang up my spurs. The industry just gets more and more interesting to me.
Ah, but do they need more junior developers than senior developers? Senior/lead devs who can take a project and execute the whole thing, including leading team members, are very valuable.
That's an amazing idea. Age as version. I always have felt I love today more than yesterday. I'm happy not to be in university, or school, anymore.
While I might miss specific events or groups I was part of in the past but I never wish to go back in time. It takes so much time and effort to build yourself and your life moving forward that going back would be a waste.
Thanks for the idea! It has solved a long time puzzle :)
Life is a continuous deployment setup with an unusual trait where public version auto-increments every N time units.
To preserve versioning semanticity, gotta habitually push out new code. Gotta strike the balance between squashing bugs, polishing UI interactions, testing new features, and self-refactoring. Gotta avoid feature creep, observe deprecation roadmaps, ensure social network integrations are in order… all those routine things.
I am not really "old" (ie over 40), but I have interviewed older candidates for some technical roles at very different companies, and I've found there are either old people who believe they know better at everything whose skills have not improved much since their early 30s, and then old people who stay up to date on technologies, trends, and realize that programming is a field you never really ever master with time or age; it shifts too much to be able to ever fully grasp it.
The "old" people who are curmudgeonly and stuck on older technical stacks are the ones who don't fare well. The ones who are current in skillset never seem to have an issue and generally impress the people they meet, as they bring both experience and current technical knowledge to the table. Anecdotally, I would say 8/10 of the 40+ crowd I have interviewed fall into the "old technical stack" / "i know better" crowd, and I think these are the ones that poison the well for the good guys.
I am beginning to believe that the trick to software engineering as a career vs. management is to stay current above all else. If you let yourself become obsolesced, you will be thrown aside like an old PowerBook. That's the reality of the technology industry and has little to do with age.
The older I get the more I realize how these old curmudgeons were often right. They've been there to witness the cycles of technology and aren't impressed with the shiny new ones that are often worse than the old ones. They aren't interested in the cloud because it's modern day mainframes for instance.
Lately I've been taking a look at a lot of older tools and being pleasantly surprised by how capable they are compared to modern ones. I started coding professionally in a world of virtual machines and xml files, now where moving back to native compilations and json. Eventually we'll rediscover ini files and how there even simpler than json and we can avoid the curly bracket tax. I've used every build tool under the sun but recently discovered that make was simpler and better than anything else I've used. We've gone full circle on ORM's and now writing sql is in vogue again.
I wish I'd learned more from those guys much earlier.
> The older I get the more I realize how these old curmudgeons were often right. They've been there to witness the cycles of technology and aren't impressed with the shiny new ones that are often worse than the old ones. They aren't interested in the cloud because it's modern day mainframes for instance.
This is actually one of my biggest career problems. I mean, it's an advantage, too... I can pretty quickly understand new things, because they are similar to old things, but... on an emotional level part of me rebels from the new cool thing simply because the old thing worked, often more reliably, and this new thing? this new thing has a bunch of little subtle differences and bugs that I have to learn and deal with and fix, just like the old thing had a decade ago, so my natural reaction to the latest fad is usually a negative emotional response, and pointing out that it's essentially the same thing as the old thing.
This causes obvious problems, of course, with the people who got promoted for "demonstrating complexity" when they wrote or implemented the new system.
I need to learn to point out the similarities to the thing I know, but to do so without the negativity, because, uh, cultural fit. (so bitter!)
>They aren't interested in the cloud because it's modern day mainframes for instance.
This is the opposite of true. Mainframes were all about complete reliability; you can always rely on the hardware, or at least that's what you are paying for. "The cloud" is all about the chaos monkey, about writing your application to deal with any server failing (or returning nonsense) at any time.
The disillusionment with "the cloud" comes from having to deal with managers who think that "the cloud" means reliability, when it really means "write your applications so they can deal with hardware that is significantly less reliable than hardware managed by in-house sysadmins"
RE the cloud/mainframe comparison. I was thinking more of the centralization aspect. The web seems to have gone from this vast network where anyone could set up their own server, everything was decentralized (except DNS which was the source of quite a few debates) and no one had any sort of control over it. Now much of the web seems to have condensed into a handful of data centers and we've given too much control to a few companies. The recent cencorship of twitter (and now youtube) really crystalized this for me.
On the other hand I see things like docker (I was late to the game here) and even though everyone seems to be focusing on the cloud aspect I can see it being a brilliant tool for decentralizing again. The tech could easily be leveraged to make things like setting up an email server possible again for small companies or families.
> I need to learn to point out the similarities to the thing I know, but to do so without the negativity, because, uh, cultural fit. (so bitter!)
If you work it out let me know ;) It feels like I've spent a good chunk of my career doing this and I'm only 10 years in. The old reliable tools have all be on the same platform FFS.
re: Chaos Monkey. I love this, and I'm 48. 99.999% uptime meant that once a year your program did something completely disastrous because the server flunked.
Assuming our hardware was reliable was a mistake. Writing code so that it's chaos-monkey-proof is a great step forward.
As for the generational thing... meh, we're ugly. People like hiring the beautiful folks. Startup folks think they're immortal, having some greying old fart in the corner wheezing away reminds them that they're not.
I remember someone giving a talk on it in the mid aughts, and I think it's a wonderful way to describe what happens in real-world networks and systems.
>Assuming our hardware was reliable was a mistake. Writing code so that it's chaos-monkey-proof is a great step forward.
Hah. Part of it is that I am the guy who is responsible for keeping that multi-year uptime (and on most of my own hardware, this is mostly a matter of vetting updates, security and otherwise, and implementing workarounds) - but I like to point out that building a system that can deal with the chaos monkey is... well, it's way harder than throwing up a reliable SQL server with a reliable backup and someone like me on pager. Especially if you want to beat the "the system fucks up once a year" record that even mediocre server-grade hardware can achieve.
That said, if you can write such software, I agree that the end result is better, I mean, like half my skillset is in Linux/BSD and environments where reboots cost big bucks, but I'm not going to cry about turning in my pager. I'm just saying, it's hard and most people screw it up and end up building something less reliable than well-managed hardware with a competent oncall.
>As for the generational thing... meh, we're ugly. People like hiring the beautiful folks. Startup folks think they're immortal, having some greying old fart in the corner wheezing away reminds them that they're not.
Eh, I think that most of the startups that only hire pretty people also tend to pay such that they can't afford someone who is good who has a few decades of experience, so it might be more of a budgetary/age thing; young people, generally, will work for less.
I think it might also be a San Francisco thing. The fitness of the people interviewing me goes up and the wages they offer me go down when I head up that direction.
The strong impression I get is that it's a seller's market for programming work most places in the United States, but a buyer's market in and around the Bay Area. I've never worked there myself, only visited, but I have known a lot of folks from there with hair-raising tales to tell. Things seem a lot more equitable elsewhere.
Eh, I'm contrasting San Francisco, above, with the South Bay; both are "bay area" (conventionally, the south bay is "silicon valley" - historically, San Francisco is not "silicon valley" though that definition seems to move every bubble.)
In the South Bay, I largely don't have cultural fit problems, and I can pretty easily score pretty good jobs at second and third-tier companies (getting jobs at top-tier companies is a real challenge, still, but considering the compensation and prestige at the end of that particular tunnel, I can see why.)
In San Francisco, though, I quite often have 'cultural fit' issues, and often can't even get into startups that pay really poorly.
On the other hand, most places don't need that level of reliablity. If a company email server went down for a few hours it's not that big a deal. Even for most large corps, only a certain few things need that level of reliability.
I often see it get written into contracts with very little thought as to what it means. You get some great looks from managment when you break the figure down into minutes though, especially when you don't have 24/7 staffing. A poorly timed cosmic ray could ruin your SLA.
* It would where I'm at now, because someone thought it would be a good idea to handle a critical business process by emails csv's.
I've also seen people make the other mistake, though. I've had people screaming about 2 hours of downtime violating our 99.999% SLA, apparently not realizing the five nines means the thing can be down eight hours a year (an entire business day) and still be in spec.
Its likely that someone who says "NO" all the time is right some of the time and its fair that they get credit for being right. At the same time, they need to be held accountable when something they said "NO" to turns out to be a really big deal. Im sure someone said Java is a fad when it was launched or that python was useless and so on.
A lot of people were saying no to java, at least on the consumer desktop which was one of it's first big aims. That's one of the thing's that young, naïve me put down to old farts being out of touch.
Two decades on their C/C++ win32/x apps are running and no one has java installed in their desktop to run mine. They have every reason to be smug.
Obviously Java didn't succeed as a desktop application development language, but the JVM and the java eco system has succeeded by any objective measure. I see your point that what matters is what does a person say "NO" to.
We're so eager to justify arbitrary technical fads. Use something until you have enough experience to start seeing its flaws, move on to something shiny and new and perfect until you've used it long enough to see its flaws, repeat.
You can very easily find yourself in a situation where every project is either your first in technology X, or trying to maintain something that was someone else's first attempt at using it. "Legacy" means "proven in production and making the company money" but too often these days it is seen as a dirty word.
Code is code and stacks are irrelevant. As other commenters have said, curmudgeonly old guys say, "I know better" and quite a few of them do ;-). But I think get get your point.
The other day, a promising young programmer asked me how to deal with the overwhelming load of new frameworks. Which ones should he learn? Which ones should he ignore? What should he do if he picks the wrong one? How will he know?
In my opinion, it really doesn't matter as long as he is learning something new. You only get stuck when you try to stick to the things you are familiar with. You need to keep stretching yourself time after time.
If someone says to me, "Do it in Python", "Do it in Elixir", "Do it in Haskell", "Do it in Go"... it just doesn't matter to me. I've been through that blender before a hundred times. In fact, that's precisely why you would pick a guy like me. I'm not trying to keep up with the current trends. That doesn't matter. But I'm also trying not to hang on with a death grip to what little I know.
On the other hand, if you need some guy who knows every single detail of how Rails works, hire a young guy who has only ever worked with Rails before. You need a mix on a team. Pair him up with an old guy so that he gets some perspective before he burns out his career.
> curmudgeonly old guys say, "I know better" and quite a few of them do
Oh, absolutely, we often do. But, like the ancient kungfu master trope, you can't tell your juniors this directly, it's a realisation they have to reach themselves. Sometimes while being smacked in the face by the consequences of not listening.
(More seriously, being a curmudgeon doesn't help; being a mentor does)
Making generalizations from a set of interviewees is very risky - because interviewees are very, very different from the general population. I should know because I recently made this same error.
Background: Current company recently got series B, and I'm trying to aggressively scale the engineering team. As such, I've been rapidly phone screening candidates at a much higher volume than usual.
After screening the first set, I began feeling very sad about the current state of software engineering. The average age was probably about 27. All had CS degrees. All were experienced Java developers. And, yet most did not know the difference between a long and an int. Most couldn't describe the differences between linked lists, arrays, and hash tables. Most could not explain how to make a block of code thread safe. Most could not describe how an interface is different from a class. Most could not explain the difference between value passing and reference passing.
I was so aghast. I mentioned in passing to a co-worker that computer science degrees must have become so dumbed down over the last decade. But, then I realized my mistake.
Of course these interviewees sucked! Very few of the good candidates were looking for work. So, I was only seeing the worst of the worst - not a random sample.
> Of course these interviewees sucked! Very few of the good candidates were looking for work. So, I was only seeing the worst of the worst - not a random sample.
Another thing I've seen many times is that the listing either wasn't written well, circulated in the right communities, or that details like compensation or the environment scared off people with better options. That can be a very delicate subject to bring up because many places don't want to admit that the problem could be their business rather than the candidate pool.
Let's say you're a good, experienced developer. You get 10 recruiter messages per week. You ignore most of them but 1 in 20 you decide to read. There's a 10% chance that the description looks like a good fit. You contact the recruiter and tell them your salary requirements. There's a 15% chance that it's in your range. You decide to set up a phone screen. But, since you're valuable to your current company, you're extremely busy. There's a 20% chance that you can make the call.
I'm too lazy to calculate that, but that's a huge number of people to contact just to phone screen one good person.
> Making generalizations from a set of interviewees is very risky - because interviewees are very, very different from the general population.
While I agree with this statement, the ageism I think is plaguing the Valley is an interviewing/HR/hiring issue, as it is in that process that their confirmation bias is being reinforced there when they bring the old dogs through the door.
FWIW the best engineers I have ever worked with, in my opinion, always seem to be the ones ten years or so ahead of where I am. They're the ones I am always learning something from.
>> If you let yourself become obsolesced, you will be thrown aside like an old PowerBook.
There are many large companies (mainly, banks and card corps) paying really, really good salaries for people with 30+ years experience with COBOL, JCL, REXX and the like. You know, mainframe stuff.
Obsolescence is in the eye of the adolescent, if I may be so bold.
You know, I always heard this, and I have kind of a morbid fascination with old mainframe technologies, even though I've never used any professionally. So I looked pretty deeply into that job scene. Turns out the vast majority of the jobs hiring for COBOL etc pay 70,000 to 80,000 a year. It's not bad pay in some parts of the country, and the hours are generally reasonable. But they're not really, really good salaries.
I worked in one of those roles for a year or so, though in the UK. From the salaries you quote, I assume you mean the US? In the UK that sort of money is quite good.
The salary you quote, converted to UK money, is about right for entry-level roles. I was hired in that company at a graduate level and I had no experience of mainframes whatsoever when I got the job (which I hunted down out of the same morbid fascination you mention).
My older colleagues though, the ones with 30+ years experience, they would be getting much better money than that. It would depend on the position also, but I heard of at least one graybeard who was asked back from retirement, because the company couldn't afford to lose his expertise.
Now, I don't know what they paid him, but I'm pretty sure it's what I call a really, really good salary.
It pays sensibly because it's a job that really needs to be done, but it
doesn't pay too well because it's not a rocket science and it's easy to find
somebody who can be trained to do it.
+1 Exactly right. I am in my 60s and I have a satisfying consulting business, occasionally being an employee, but mostly consulting over the last several decades.
My formula is to spend at least 15 hours a week on non-billable learning projects, writing technical books, etc. A lot of this time is simply reading papers in my areas of interest (deep learning, functional languages like Haskell, application of deep learning to NLP, etc.) and writing enough code to make sure I understand new technologies.
It sounds like your idea of staying current is different from what others are talking about in this thread. Do you keep up with the latest JS frameworks and nodejs? Rails? There's a distinction to be made between learning new things that are actually useful (deep learning, NLP, new programming paradigms) instead of learning the latest framework just to do something we could already do with another technology 5-10 years ago.
When I used Rails (a long time ago) and Node.js (last year) for work, then yes I did get up to speed on both of them and enjoyed it.
I agree that core technologies like linear algebra, machine learning, etc. aren't the current topic. The main thing is to learn new things, and as someone else here said, maybe it does not matter so much what you learn as long as you learn new things.
This is true for all ages and categories; there are good and bad younger programmers, good and bad middle-aged managers, good and bad grey beard *nix sysadmins etc.
Oh, I agree. I think there is a definite issue of people ascribing "old dogs, old tricks", and that bias is the hard thing to overcome. It's especially hard when a lot of people are confirming that.
It's the age equivalent of https://xkcd.com/385/ . When it's a younger person, it's "this person can't code for <x> because they don't have experience." It's harder to quell that cognitive dissonance when you don't have that out and forces you to place the blame on incompetence.
Thinking about it, I find that I straddle the line on this. I'm up to date on the New Shiny and will happily run with whatever flavor of the month language, framework, and programming paradigm that a given gig wants. Yeah, sure, Node.js with tons of functional stuff mixed in pulling from a NoSQL store and React on the front end. I'm your guy. We're gonna change the world!
But for my own stuff, there's no way I'd use any of that crap. Good old C#, SQL Server and a proper boring stack and tool set that I know won't just up and fall over on a Saturday morning and leave me debugging NPM dependencies all weekend instead of bouldering in the forest with the kids. This stuff is my proper income stream, and the most important thing is that it works. If that means I have to write a "for" loop and declare variables and risk 19 year old kids snooting down at my code, so be it.
But yeah, the key is to never get so far down in to that comfy hole that you can't hop back into the present day when it's time to talk shop with the cool kids.
Yeah, mostly just javascript, with the occasional bit of jquery thrown in. Like I say, I've been quite deep in to various front end frameworks and scripting libraries and learned what is useful and what to avoid.
Turns out you can get a lot done when you don't have to constantly fight with terrible 3rd party javascript.
So really age doesn't matter - experience and aptitude does. Here's your quote minus references to age.
"I've found there are either people who believe they know better at everything whose skills have not improved much, and then people who stay up to date on technologies, trends, and realize that programming is a field you never really ever master with time"
Yeah, for the vast majority of engineering programming is like selling shoes. You just need about 4 years experience and you pretty much know it all. Certain skill sets are great for older folks though. Security, for example. You want to work with someone who has a long track record of being trustworthy.
That being said, there is something compelling about an older engineer who constantly re-invents himself with the latest technology.
> Yeah, for the vast majority of engineering programming is like selling shoes. You just need about 4 years experience and you pretty much know it all.
That's the point I'm trying not to make. Are you building a startup that's effectively a CRUD app? If so, sure, that's pretty much all you need and is why coder schools have become so prevalent - they get you to a practicing point that covers the bases of most small websites and very, very basic startups.
Age and experience brings with it something vital: the ability to build long term pattern recognition of technology business cycles, the "all is old is new again", the ways that novel technologies may fall like their predecessors. This is not something you learn in a CS program or even a few years out of college. It's something you only learn by playing with tens of languages and mastering six or seven over decades, by constantly learning, by being part of those business cycles. This skillset is often discredited and is enormously valuable, but I believe it requires a tireless passion for novelty and modern technique to become a multiplier on skill.
Experience is more important if you are actually developing algorithms rather that making another app. It takes time and practice of genius to get a handle on required mathematics for AI, adaptive systems or advanced data structures. It is no accident that mathematicians are divided into super young genius and old bearded wizard camps.
I disagree with "This is not something you learn in a CS program". Anyone who has taken a SICP course will know "all is old is new again". But in large I agree with you.
I have been programming for 30 years. I can look at code that is 10 years old and see how much I have improved in those 10 years. 26 year old code? It was a joke. I thought I knew it all back then, but for about the last 20 years, I have been working with the realization that I know less than 10% about this field. Your statement cannot be true unless you only work in the very limited scope of CRUD apps. Even then, you probably still have a lot to learn about SQL optimization (I know, you use an ORM and do not worry about those pesky details:<)
I am continuously amazed by the poor quality or performance of a lot of commercial software, probably borne out of hiring practices that espouse the same belief you do.
You will never "know it all" about programming. If you seriously think then you can learn all in 4 years I'm really wondering what kind of things are you working on.
My biggest to date (but not the only one): having received complaints, I figured in 2 days that the culprit is the change in the manufacturing-workweek-number of the DDR ICs. It took them several months onsite with people travelling from abroad and with expensive equipment to find the real root cause, and guess what they have found?
And I am not even a hardware engineer. How did I do that? Intuition. You need lots of time to develop intuition, much more than 4 years, and once you got it, it saves lots of time and money.
I have also seen other experienced engineers do this sort of tricks, and I pity the workplaces where people aren't familiar with this.
There is a difference between being able to write code and being able to write nice maintainable code that is easy for others to understand. It took me a lot longer than 4 years to reach the second stage.
My observation is that most devs get stuck in their favorite stack no matter what their age is. A lot of younger guys I talk to are stuck on node.js or whatever is cool right now and can't be bothered to consider alternatives either.
I think there is just a large percentage of people in tech that do it to make an income with the least amount of thinking. Only a small percentage is really interested in the technology.
I am afraid the story is total and complete crap. The reality is that Amazon is Logan's run. Yes, PE engineers are old and yes they are a tiny percentage of the total army. What does that tell you? It tells you that they keep a tiny number around to make engineers believe there is a path. The reality is though that path is only for a very very select few..
Wow, I'm so amused at the downvotes. It's like a completely and absolute denial of reality. If you imagine for a moment that PE role is a realistic path for a typical engineer at amazon you are in total fantasy world.
Was it? The reality is that you have someone who has benefited from having either a hugely beneficial nurtured environment or perfect DNA trying to espouse that this is actually realistic for all engineers at amazon. It isn't! Trust me! Amazon grinds you as much as possible. If you imagine for a moment that you are a typical engineer at amazon and your ass will age like fine wine you are being totally and utterly manipulated.
That being said, there are ways to succeed as you age. Working at amazon is not one of them. Specializing in engineering areas that require a track record of deliverables is. It's Bayesian probability. That is what your advantage is if you are old.
Being trustworthy helps in things like security. Young kids between the age of 16-25 are freakin random and they might be the next snowden for all a manager knows. Older people who have never done anything irresponsible in their life can benefit here.
Also, leveraging technologies in your resume that are once again fashionable. Devops in the cloud, neural networks in deep learning, etc.
Is any of this fair? Of course the F not. But neither is being discriminated against because you're old.
No one's disagreeing with your point. But when you open with unnecessary rude snarkiness, people will dismiss you before you even get to your point. Presentation is important.
That is sad. They could have made double the SDE2 salary of $120k somewhere else. No one is really sure what Amazon PE's did or do to be a principal engineer. Most people think PE's bribed or extorted their way into the job at Amazon as that is the only realistic "path" to that particular job. All that Amazon SDE's know is that there are two levels, SDE 1 and SDE 2 which comprise 95% of Amazon SDE jobs and 99.9% of open positions. Both pay less than every other place.
Interesting. I won't disagree with you that the path from 2 to 3 has been awkward in the past. But there have been major changes lately because it was identified as a problem, and it's shown results.
I now work with 3 SDE3s between two related teams. Meanwhile, a friend and sometimes mentor of mine just got his PE promotion. I honestly take offense to the notion that he didn't deserve it, that he bribed his way into it. Fantastic developer and well deserving of the title.
I hate to say it, but I am approaching 35 and already feel too "old" for my own good.
Many of my bosses have been 5+ years younger than me.
I am eyeballing jobs that are paying exactly what I got paid 8 years ago, just because they are local/family friendly.
I am not experienced enough with management or executive roles to take one.
I am too much of a generalist to get a senior role in a given field, except the one field I specialize in, which is fairly useless when it comes to paid jobs.
I'm not a competitive coder, but I can meet any reasonable deadline. Unfortunately, the trend is now to value the former much more than the latter because it is easier to measure in the interview process.
The majority of jobs out there (frankly) do not require much skill for functional results, so there is someone out there 10 years younger than me who can put in more time for less pay.
Additionally, there are people with 2 or 3 years of industry programming experience making over $250k. It sets a weird baseline that makes it impossible to scale up for more experienced coders.
The most elite people in the valley struck it rich fresh out of college. These are the people who dictate the flow of cash in the software world. What reason do they have to believe that an old software engineer is valuable, even as they themselves grow older?
I don't expect the world to be fair. But I feel like there has to be some sort of value in experience?
I'm starting a new software consultancy that's hiring 40+ coders exclusively, at below market value, then leases them back to the companies that just got rid of them. The only difference is that I hide them away somewhere, call it "untapped talent" or something that doesn't give away the age and show up at meetings instead of them, with my 26 years and sneakers and a hoodie. Call it job market arbitrage.
if a 40+ developer (who ships product and gets things done rather than a "coder" as you refer to them), works for less than market rate, there is a reason, and usually not a good one. This is not something to base a company on.
Most of us are working at well above market rates, not in Silicon Vally (there is serious software in the energy, medical, financial, etc... field being written elsewhere) and are not in the job market.
> if a 40+ developer (who ships product and gets things done rather than a "coder" as you refer to them), works for less than market rate, there is a reason, and usually not a good one.
I'm only 36, but my personal experience would bias me to assume it is because the companies that would pay market rate aren't willing to even talk to them. It's hella illegal, but I would not be surprised if a company basing their product on technologies that are only 3 - 4 years old is silently, perhaps even unconsciously, ignoring resumes from people with 15+ years of work experience, even if they have the experience in those recent technologies.
Whenever this topic comes up, I see a rush to deny that ageism is a problem in the industry, or that it isn't ageism alone but bad choices made by certain people, or...
It would bother me, but I know that ageism is one form of discrimination that eventually hits us all. Beware, young people. The rationalization you do today will be used against you in a couple of decades. And you'll know better then, but you're not listening to the gray-hairs today, and probably neither will the people refusing to hire you then.
Fortunately, some companies treat their gray-hairs better than others, and while you'd think startups were the best route of all, since no boss can refuse to hire you then, it turns out that ageism is pretty widespread, and it can be hard to get funding for a startup, and even hard to land customers if you're the public face of a startup.
Every year, we all get a bit closer to it happening to us.
I think a lot of this is more lack of exposure rather thanan intentional denial. The ageism that happens in technology is hard for younger people to recognize and acknowledge because they don't have first hand experience with it, and stories online only go so far since it's hard to verify. This, combined with the fact that there is a strong sense of meritocray when it comes to technology, and I think people just naturally assume that your work always speaks for itself.
This is one of those things where more visibility and discussion will eventually help, it's just right now there's a large social aspect that needs to be dealt with first. Personally, I'm very familiar with the difficulties older coders face as one of my colleagues at my last job battled it pretty much daily, and even when he took over as lead programmer for our small university, the management and even his underlings really didn't want to listen to him much either. But he was stuck - like a lot of people at the University, he wanted to leave because things were getting bad across the board (management issues resulting in enrollment loss, which means less money), but he was 50+. Since we were in the Seattle Area, this meant the only tech hiring was Amazon and other Seattle based start ups, none of which wanted a 50+ year old man, even if he could hack and plan with the best of them.
It's experiences like this that I think help shape people's perspective. A more personal experience, seeing it actually affect someone in exactly the way they described it. It would be great if we could just accept that sometimes people's biases do influence their judgement, but sometimes it requires a more impactful approach.
> If you help build something important and impactful, call it X, it's easy to slip into year after year of being the world’s greatest expert on X, and when X isn't important and impactful any more, you're in a bad place.
Gosling, who he quotes at the top of the article, worked on NeWS, a primary competitor to X. And, I imagine he knows plenty of people who literally worked on X, since he worked at multiple major UNIX vendors during that period.
Getting somewhat far afield of the OP, but in healthcare, the bigger trend seems to be a move from HL7v2 past the dumpster fire that was XML-based HL7v3 to JSON-based FHIR.
I don't like reading articles like these. This article was the impetus I needed to create https://oldgeekjobs.com/ just now.
I'm 37 and just recently phone interviewed for a job with two twenty-somethings. I felt I got discriminated against not so much because of my age, but because I just wasn't into the same things as them and wouldn't have been a good 'cultural fit'. My age played a factor in that respect.
If you're cool working with old hackers, post your jobs on there for free. I'll circle back around tomorrow and make it classier.
Some people think Silicon Valley represents the entire United States, and that software development only happens in Silicon Valley, hence the myopic views and the memes.
Hmm, a depressing reminder of my own predicament: I hitting that midlife midcareer crisis point...
I'm forty this year and still coding. I dabbled in mgmt in my early thirties and didn't enjoy it, so stuck at coding.
I am extremely up-to-date and well-versed in everything modern - like most of us here, its my consuming passion too - but I'm completely underwhelmed by the JS frameworks so I can seem a bit "not with it" perhaps?
I do a lot of architecture - I've been a chief architect for big subsystems on a small OS, even. Not that I seem to have any impact or sway on mgmt, who keep repeating the technical mistakes I keep pointing out anyway..
So here's the nub: if I moved on, I doubt I'd be replaced. Companies don't feel they need people like me. And they can have someone young, cheap, without family and without work-life-balance and without strong opinions to point out technical flaws in plans etc. They'd all probably be relieved!
Leaving us "old geeks" unemployable in anywhere near the quantities soon available...
If you are up-to-date and coding is your passion, then you should have no trouble to get a job, regardless of your age. Actually, for many positions your experience is an advantage. Some teams do need people with solid opinions to keep their younger colleagues on the rails.
"There are all these little communities at Google: Gayglers, Jewglers, and my favorite, the Greyglers; that’s the only T-shirt I took with me and still wear. The Greyglers are led by Vint Cerf, "
I see a lot of these articles, which I like reading btw, about technicians, too old to do the work. [0] Let's turn this idea on it's head: What about "Management, period". Management itself a big source of company inefficiency. [1]
What technology is being created to push down the cost of executive compensation in buiness?
[0] "Just 120 of the Audi factory’s best employees qualify to work on the prestigious R8 assembly line. More than half of R8 workers are over 40. It is said that the easiest way to spot them is to look for the gray hair. The factory calls them “silverliners.”" ~ http://natgeotv.com/ca/megafactories/audi-facts
> What technology is being created to push down the cost of executive compensation in business?
Other way round: business exists to provide executive compensation, and the job of the executive is to squeeze everything he (and it's usually a he) can from the investors and the employees.
The platonic ideal of a 21st-century company is a CEO and a computer. The computer hires a cloud of transient workers and the CEO pitches slides to investors. Any resemblance to Uber is a coincidence..
> What technology is being created to push down the cost of executive compensation in buiness?
I imagine this technology would be difficult to market and thus difficult to sustain, given that the prospective customers (i.e. decision-makers who control companies' funds) would have personal negative incentives against purchasing it.
This reminds me of some friends whose startup's product was software to make lawyers more time-efficient with (billable) administrative tasks. It turns out customers don't come banging down your door to buy a product that 'helps' them make less money.
"given that the prospective customers (i.e. decision-makers who control companies' funds) would have personal negative incentives against purchasing it."
That is something I would believe, push-back from existing people in companies. What about new companies selling products? (remember ways of making money in SW: internal services, contract/consulting and product)
This did strike a chord. I'm 37. I've been programming since leaving university. I had a stint of about 6 years in the middle of my career where I stagnated. While it was fun (I did a lot of climbing, biking, caving etc.), it was hard getting out of that hole, and I'm glad to be out.
Anyway, I'm now travelling for a year (my partner made me quit my job ;) which has been lots of fun. I've caught up on a lot of books, playing with elixir, sharpening tools. But, I'm wondering what to do when I go back home, and finding it hard to decide. I already have an offer, and I'm not particularly worried about having work, but more about having the _right_ work. I'm not sure how many more options to change I'll have. Coupled to that, I'd like to work on projects which I feel are doing something useful for society.
Options:
1. Work remotely for a company I've worked for before. Should be decent cash. Codebase is horrible legacy stuff (but improving). Just me and another (more junior) developer.
2. Work for a pretty professional company in town. Excellent excellent team, I'd learn heaps, but it'd be just straight business work (not ticking the "useful to society" box.
I have a couple of options in both of those categories (I think ;). I've been stung before being a solo developer and I'm not that excited about being the most senior on the team. I'm an OK developer, but I know there are lots smarter, and I like learning from others.
So decisions decisions. It feels to me the older I get the fewer of these types of decisions I want to mess up.
go with the job that offers a better working environment and/or work life balance.
the technical work itself is what you make of it, even learning by replacing legacy stuff with newer better stuff is always a possibility. choose to use technology that is interesting to you. spend personal time catching up on it if it's impossible to do 'on the clock'. "garbage in, garbage out", basically.
however, the conditions in which you do the work in are not under your control and carry the heaviest personal cost.
This is the thing, the remote environment would be entirely under my control and I think the work-life balance would be fine.
The non-remote job would be more challenging work, probably a bit more corporate & rigid, but have a killer team to work with and learn from.
I'm with you on the "learning by replacingn legacy stuff with newer stuff" ... that train is already in motion and there's certainly a lot you can learn by doing that properly.
Thanks for the thoughts, I'll add them to the melting pot.
There's a contest to find a hidden treasure in a forest. All that is given is a short description of the place where the treasure lies, and a couple of hints on how to get there.
A young kid, in tip-top shape stands next to an overweight graybeard. He snickers at the older fellow, confident that he will find the treasure first. The whistle blows, and off they go running. Or rather, the younger fellow goes running. The older guy stretches a bit more, buys a bottle of water, and huddles off into the woods. He walks at a fair pace, not really breaking a sweat, as he knows it's going to get hot in an hour, as the sun hits the middle of the sky. He's been in these woods plenty of times in the past thirty years.
The young kids runs here, runs there, looking for anything that may resemble the clues he was given. He is fast. He has the latest gear and newest gadget. However, he's not really sure where to begin.
The old guy has a hunch where to go. He knows where the blueberry bushes grow that were mentioned in the clue. He knows where the sunny clearing with the three rocks is. It takes him a bit of time, but he is going in the right direction. He rests in the shade for a bit and hydrates when the sun is at its harshest.
The young fellow is dehydrated. He's run over 12 km, he thinks he saw some of the mentioned clues, but he's not sure. He needs to get back to town to get a drink of water.
The afternoon sets in. The young fellow is covering a lot of ground, but is not rally getting anywhere. The graybeard, meanwhile, has found the little pond and the hollow trunk that holds the little treasure chest. It takes him some time to walk back to the finish line.
When doing anything, there is the experience and velocity aspect. If you're running fast but don't know which way is right, you will make many mistakes. Your speed will allow you to recover quickly. If you're experienced, you will likely plan better and your slower progress will be in a more correct direction.
What is better? I wish we could all be spry 90-year-old veterans with the speed and stamina of 18-year-olds. For most of us, it does not work that way. Different projects require different skills. More established companies don't want to risk key project on inexperienced talent. Young startups don't really know what is going to work, so making lots of mistakes and recovering quickly may be an advantage. It's getting the right mix of people for the job that is the key.
One option more people should consider: work for the government. There are strong legal and union protections against discrimination in many areas including age and most agencies are both desperately in need of good technical staff and have challenges and requirements which are more complicated than the average startup so your greater experience (both on the job and in life) is a selling point rather than a drawback.
Public sector work sometimes does, but lots of times has "or equivalent experience", and much more often than private sector work has clear and objective definitions of what is the "equivalent" alternative for particular purposes.
18F isn't currently hiring and hasn't been for months.
USDS sure doesn't act like it is desperately in need of good technical staff. Best I can tell is that they are desperately in need of people who can sell Agile to government suits.
I have no personal experience with USAJobs, but the experiences of the many people I know who have is that you are SOL if you don't have veterans preferences.
> I have no personal experience with USAJobs, but the experiences of the many people I know who have is that you are SOL if you don't have veterans preferences.
Having gone through that multiple times personally, veteran's preference is not a requirement.
Not an actual requirement, but a practical one. As in, if an eligible veteran applies they will get hired over you. I don't know what positions you have applied for, or how they compare to the positions the people I know applied for. One guy had a long string of "Eligible, Not Referred" rejections, or did until USAJobs was redesigned and they got flushed with the old database.
No they aren't. You would need to be qualified for and accepted into the uniformed services to get them. That pretty much disqualifies everyone the article is discussing, unless they have served already.
Reading the article feels like I am talking to my old neighbour who likes tell me about his good old days, which is a good thing.
Anyway, that advice at the end of the article is BS. Being older does not stop you from coding, and it does not stop you from being an engineer. Engineering is not age dependent, but practicing it as a job may be.
Well, the point is if you still want to be able to get bills paid. And if you are not inventor of XML, or inventor of Java, you have to keep your eyes open.
Seriously. Gosling says "almost every old friend of mine is screwed", and it should be a safe assumption that he bonded with equally smart and talented engineers at places such as Sun Microsystems. It's unreal.
These days, re-inventing the wheel and blogging (writing books, speaking at events) about how you solved 'your' problems, are the new way.
There are many very intelligent younger people (as there have always been), but most of them, brought up on the shoulders of giant, are no longer interested in what those giants did and think they can fix the world on their own.
I just turned 40 and just got hired. I think the big difference between now and my last hiring in the oughts is that I was able to take a much more active role in my own career-path decisions (this one is interesting, that one used the word "rock star" so I won't bother, etc.). Part of that is because I'm now married and somewhat more financially secure, but, hey: that in itself is part of being older.
Now, I'm not a coder, except to the extent that every sysadmin is, and my field's definition of "output" is different (and for that matter ops in general is grayer than dev). But just personally I feel a confidence in my skills and experience that I didn't have even a decade ago at 30. And also I seem to have a longer attention span than I used to (9am HN commenting notwithstanding). I have a much better sense of how long an implementation will take, what its blockers might be, etc.
Good to see another sysadmin input on this thread. Any bits that you would advise us younger (not that much, 30 yrs old) sysadmins about what to expect from the future?
So my biggest bit of advice is to get out of the tech sector as much as possible. One of the great things about ops is that there literally is not an industry that doesn't employ us. I've worked for non-profits, education, farms (you'd be amazed some of the data needs agribusiness has), and now aerospace. I've even gigged for food service (a local brewery paid me in beer...)
The advantage of this is that gets you out of some of the myopia that the tech sector has a tendency to instill, as well as broadening your geographical opportunities beyond the few tech hot spots. It also teaches you the three most important words a sysadmin has to learn to say: "I don't know". A sysadmin who can't say that immediately when it's true is going to have problems (after all ops is about 85% reading documentation), and figuring out how to get data from a barn to a datacenter will teach you to say it quickly.
Another piece of advice: if you haven't already, work in a datacenter, at least once, for at least a year, before you quit in disgust (everybody does). No datacenter sysadmin is happy, but it's a huge resume buff and it teaches you a lot.
Let's put our money where our mouth is. I believe it is legal in the US to hire only people over 40. GeezerSoft - "because old age and treachery will always beat youth and exuberance"
Robert C. Martin sometimes shares an observation in his talks - it's not that the industry is trying to avoid old programmers, it's just that they are orders of magnitude rarer than the young ones due to the exponential dev population growth.
For that to be a complete explanation, you need to ignore or flat out disbelieve everyone who talks about having a harder time getting a job once they seem old.
> I’m one. We’re not exactly common on the ground; my profession, apparently not content with having excluded a whole gender, is mostly doing without the services of a couple of generations.
The bulk of the problem is that the software field has been growing exponentially for a long time. If you double in size in 2 years, and the bulk of the new guys are actually new to the workforce (as seems to be the norm), then instead of a nice even distribution of ages, you'll end up with nearly half of your workforce less than 2 years out of school.
This isn't really a solvable problem, short of waiting for the size of the software industry to level out, and then waiting for the younguns to grow up.
I'm not saying that there's no discrimination -- I have no data -- but it's likely to be less rampant than this makes out.
40-plus women are basically not employable in the technology sector.
If this isn't prejudice, I don't know what is. It's not, "40-plus women are employable if they are competent." It's that being a 40-plus woman is enough of a signal, people feel justified enough to "err on the side of false negative." Really, how many 40-plus women have most 20-somethings actually encountered as coders in the workplace? How many 40-plus women have most 20-somethings actually encountered as managers in the workplace? I suspect this prejudice comes from outside the workplace.
Exactly. People are not avoiding hiring 40+ year old women because of bad experiences with the work of 40 year old women, they're not hiring 40+ year old women because they don't like women, and they don't like people over 40.
Somehow I feel the key to staying relevant is not programming skills but choosing a practical domain where the software is implemented, and becoming an expert in it. Mine's CAD. We have ton of older people, and no age discrimination that I can tell.
I'm not sure if this works in other fields. Probably in lots of niches.
One of the biggest issues I see with this mentality going forward is
a) lack of mentors for younger generations;
b) repeating the same mistakes our generation made.
a) is bad. b) is worse.
a) and b) combined lead to fads in which one burns tremendous amounts of time figuring out what it is and how it works, only to become obsolete by the time one masters it.
Old people like me pick their technology very carefully, because they've already burned exorbitant amounts of time mastering all kinds of technology fads during their lifetime, only to find that most of them don't fix, or make the problems even worse.
In plain English: we reject 99% of the fads out there because we can tell from experience what will work and what won't, and what the challenges and pathologies will be if we deploy on that particular fad. We don't reject fads a priori just because it is something new, but on the very simple metric:
could it be as bulletproof as possible, so I don't get a call at two o' clock in the morning?
Yes: continue research. Attempt breakage. Re-evaluate based on the results of breakage.
No: reject.
Where we, the old people failed: I take on apprentices. Most of my peers do not. That is why we end up with, for example,
...where a few lines of AWK code would do. And my peers are nowadays almost embarrassed to even mention such robust technology, instead of actively teaching and promoting it:
this is where we failed: to teach. To take on apprentices. This is why humanity keeps repeating the same mistakes over and over again, and nowhere does that appear to be so acute as in information technology.
We can do better. Take on apprentices, and have them commit to teaching others once they themselves become masters.
I don't mean casual mentorship; I mean a formal apprenticeship. Yes, that means you Bryan, and you Adam. And you Jerry. And you Max. And you Robert. You know who you are.
> I don't mean casual mentorship; I mean a formal apprenticeship.
This is an intriguing idea. But our culture doesn't offer much in the way of a framework for it. Will you expand upon what you mean by it, and how you've made it work for you and others?
I arrange my work spaces such that there is always a chair and ample desk room for anyone to bring their laptop over, plop themselves next to me, and start talking to me about the problem they want to solve.
I've also planned an apprenticeship program, where I had pupils formally assigned to me to mentor. I'd start them while they were still at the university doing their bachelors or masters. Usually they are new to UNIX, so the first thing I have them do is read the entire manual page for tcsh and zsh. Then move on to teaching them how to shell script, then how to program in AWK. Once they're past that, I move on to teaching them C.
For shell programming, I tutor them one on one, covering looping, input, syntax, interface design with getopts). I teach them why having ".sh", ".pl", ".py" or any other extension on an executable is a bad idea on UNIX, and there I cover what it actually means for a file to be executable on UNIX. I teach them about the runtime linker. I teach them about compiling and linking, about how functions map to symbols in an ELF executable. I teach them about ELF. About process spawning, context switching, high interrupt counts, 32- versus 64-bit code, instruction encoding. About what being a zombie process actually means, how they become such, how they get adopted by init(1M).
Eventually they hit deeper and deeper problems, so I inevitably end up teaching debugging and OS programming.
For teaching them how to program in AWK, I have them go through all the chapters and all the exercises in the Gray AWK book by Aho, Weinberger, and Kernighan. Then I help them with the actual real world problems they are attempting to solve with AWK, by showing them how to do it and explaining how it works. This is usually the time when I cover all the formal algorithms they're supposed to be learning at the university but aren't: stacks, queues, linked lists, doubly linked lists, sorting, pointers and pointer arithmetic, topological sorting.
For teaching them C, I have them go through the ANSI C programming language book, 2nd edition, and then cover anything that they don't understand with examples. Then I have them follow that up with the Advanced C programming by Example book. Then I cover dbx(1), gdb(1), and mdb(1) with them (what I know about mdb(1) anyway, and I touch upon kdb(1)). Throughout all of this, I cover cpp(1), make(1S), gmake(1), and m4, as well as lex(1) and yacc(1).
If I am forced by circumstance to teach them on GNU/Linux, I constantly and consistently pound it into my students' heads never to use GNU constructs or GNU specific features; by the time I'm done, they are able to write clean, portable programs in shell which work on any UNIX-like platform without any modification, and ditto for C programs. I purposely teach them to stay the hell away from bash(1), and use either the original Bourne or Korn shells to program.
If they are apprenticed to me for a long enough time, I will also cover complete UNIX system, network, and security administration (up to and including locking down the system and configuring the firewall and IPsec); by the time I cover the material, any of my students should be able to take on and pass a Solaris system administration exams and get certified. And with that knowledge and some shallow preparation, they can then easily ace the redhat Enterprise Linux certification exams.
Next, I cover SQL and database administration. Usually the places I work / consult at have Oracle, so I teach them how to administer an Oracle database, show them where the documentation can be found, and generally prepare them to take the Oracle database administration exam. If we have it, I will also cover PostgreSQL, and I cover SQLite. Finally, I show them all the bugs and all the issues in MySQL with a warning to stay the hell away from it and never use it for projects. By the time I'm done with them, they are comfortable taking on a database administrator's job or programming applications in PL/SQL inside of the Oracle database. And where there is Oracle, sooner or later, there is Automatic Storage Manager (ASM), so covering that inevitably leads to covering storage area network administration on the OS side, which ties into their UNIX administration I taught them earlier.
By the time I'm done with them, they are able to comfortably program applications in shell, AWK, or C, in addition to being able to administer UNIX systems and relational databases.
From that point on, they have enough knowledge to master pretty much anything in computer science.
Imagine if he had said white people, or straight people, he would have been torn apart, but he got away with blatant prejudice and no-one batted an eyelid. That's the culture we have to change.
Here in the UK they spent the last 25 years dumbing down the education system so that A grades are now average and fully half the population get a university degree. Surely that can only serve to reinforce the impression of young people that they're smarter than older generations?
And from what I hear, the presidency requires long hours, time spent away from one's family, and a relatively low salary - all things that older people supposedly can't handle.
That's because they're executives. Executives are allowed to be half-dead and half-crazy, in fact the older and more secure the company, the more they're expected to be.
I wonder if I'll be the oldest one in this thread? I'm 64, turning 65 in January. Been programming since 1968.
I don't really like the term "coding", because when I got started, a coder was pretty close to the bottom rung. You had Systems Analysts who wrote specifications, Programmers who turned those specs into flowcharts, Coders who translated the flowcharts into actual code on coding forms [1], Keypunch Operators who punched that code onto punch cards, and finally the true high priests, the Computer Operators who ran your batch jobs and gave you back the printouts.
At least that's what they told us the serious enterprise software companies did. In truth, we were a bunch of hackers who punched our own programs on Teletype machines.
Later I got into writing DOS applications and TSRs and custom BIOSes, and then Windows programming starting with version 1.0. Some application programming, some language design, and some systems hacking like figuring out how to hook into the Windows font rendering before they had scalable fonts, so I could render Adobe's Type 1 fonts behind Windows' back. Worked on Visual Basic and created the VBX interface.
10-15 years later, I switched to web app development and had a pretty good run with that. Helped develop jQuery and taught a lot of people how to use it, got into GIS and mapmaking, did a bunch of election results maps for Google.
Then a funny thing happened: I got into VR, and it turned out all my Windows experience was relevant again. I was talking with a VR startup today and the CEO said "I thought you were just a VR developer - but you've done all this Windows systems hacking too? Maybe you can help us!" (They are trying to do some tricky DirectX system integration.) And the VR work also gave me a chance to get up to speed on Android and iOS development.
They say to leave everything more than 10 years ago off your resume so people won't realize how old you are. But if I did that, this VR company wouldn't have noticed my Windows experience from back in the day. And if you meet me you'll figure out my age soon enough!
At this point I've programmed in about 40 languages and a bunch of different platforms. If you ask me what my greatest strength is, maybe it's that I'm comfortable jumping around all sorts of languages and OSes, and I can pretty much always figure out a way to hook them together.
But I envy people who have become world-class experts in one important thing. One friend is a data scientist who does everything in Python. Another is an iOS expert who knows everything there is to know about Objective-C and never wants to use another language.
So maybe jumping around so much is my great weakness too. When I talk with companies, they are often looking for someone who is the best at one particular thing. It may be data science, Android or iOS development, web front end, or whatever, but they want that one specialty. They may talk about "full stack" developers, but it tends to be a pretty specific "full" stack.
What is the most productive role for someone like me who has worked on so many different kinds of systems that I've lost count?
I am not even 30 yet (but close) and as a generalist with lower-level inclination could see something similar.
At my first day at my first job at gamedev consulting company, around seven years ago, I've got PSP devkit with a task to port a game to PSP. Game was using an internal cross-platform framework that had some support for PSP. I learned on the job how to run and debug code on devkit. I had to extend framework's support for PSP. It was very satisfying project. Later on I also learned on the job some iOS and Android programming. I heard about a colleague that was sent to a client as a help in iOS project, when his first experience with iOS was a book that he was reading on the plane. It all worked, because people there were great generalists.
After a few companies and pause in mobile development (around 2 years) I applied for an iOS developer job in cool startup. The guy that was checking my competency was asking me many questions that I didn't knew answers to. But I could quite reliably imagine most probable answer and he was totally surprised that I could quickly get to the answers (even if my vocabulary was a bit off), by just thinking. I couldn't believe that someone in his position can be surprised by such things. Later on HR person was asking me why I want to be iOS developer if I don't even have a mac or iPhone. I described my previous experiences and that I didn't have PSP devkit or prototype set-top box (at other job) at home either, but it just did not compute for that person. In the end I didn't get the job, but after all this I wouldn't take it.
I think that for such cool new companies their stack is so advanced and so special that they cannot comprehend that some generalist can do the same as many of their specialists in no time. Maybe it is more generalist vs specialist than young vs old?
Thanks, you are very kind. But if you read between the lines, you may note that I'm not quite as happy with my story as I'd like to be. There were so many opportunities I've had that I didn't capitalize on.
jQuery was one. Another was Visual Basic, the VBX, and being known at the time as a Famous Windows Programmer. Before that was my infamous Steve Jobs story:
Maybe this is one big advantage of youth: you can make mistakes like this and still have many years to correct them. At my age, well, I still do have plenty of good years ahead of me, but I certainly don't have as much room to "pivot" as I used to.
I don't really like the term "coding", because when I got started, a coder was pretty close to the bottom rung.
As a profession we have done ourselves an enormous disservice by letting outsiders label us "coders". If the journos that do it became known as "typists" they would explode with indignation.
> So maybe jumping around so much is my great weakness too.
I've seen it suggested that if anybody lists 20 different programming languages on a resume, they're "obviously lying because it's impossible for any one person to have learned so many programming languages."
I'm a fifty-year-old developer, and a woman. Apparently, I was hired by my current company a year ago to be a crash test dummy/scapegoat, rather than an agent of righteous refactoring to a dreadful legacy codebase mostly written by "recent grads."
If your management is moving towards stack ranking, you'll find a couple of us around, because we're like the expendables on _Star Trek_: we're easily discarded.
You could try another industry. I work in the IT department of a law firm. There are 20 people on my team, 12 of them are women, and most of them are over 40.
Weird, I just realized that I'm, with my 38 years of age are the oldest coder at my company, never thought of that. But I was over 30 when I started at the university doing computer science, so I still want to code a bit first.
I'm also 38, and probably at the high end of the majority of the programmers at my workplace, but we have a handful of much older programmers who will probably be retiring over the next 5-10 years, and not many in between (ages in the mid 40s to early 50s seem pretty rare among the coders here). In our case, a large percentage of the coders in the 50+ ages are very much specialists supporting software and systems that are being phased out in part because it is becoming more difficult to support those environments every year.
It is difficult to find career paths which continue to make it worthwhile and still continue coding, but it's also difficult to find people who want to continue coding and can keep up with the progress of technology. Further, it's difficult to evaluate whether someone has the right combination of skills, desire, and adaptability in the hiring process. Unfortunately, most people seem more likely to associate 2 out of 3 of those traits with youth, and those also happen to be the hardest traits to see on a resume. For example, if someone has worked on a lot of projects in a lot of different software environments with different programming languages, it can be difficult to determine whether this means they can adapt well to change, or they can't work well with a team or grasp the necessary concepts for a given platform or language.
I'm 39 and I'm so scared, also being in Sicily so very far from the IT scene, that I'm investing my savings to buy some land here to do agriculture when I'll no longer be able to pay my bills with programming.
I remember having a conversation with my father, an engineer, a few years ago when I was in my early 30s. He was adamant that I start thinking about either going to technical management (which he had done) or switching fields.
My arrogant (or cueless, as you wish) self then smuggly told him "software is different. People don't care if you are a rolling hairball as long as you can write code".
He was right, of course.
I'm not sure with star programmers with hot properties such as yourself this will be an issue but then there is the pull quote from Gosling in the OP!
Today if a young engineer asks for my advice, I consistently tell them to either take the necessary steps to end up on the stakeholder side of tech, or to save like mad while the going is good to allow for the necessary career switch at mid 30s.
Totally agree! And it's better to make people aware of this in our industry so that they start planning ahead and even ask for an adequate compensation when doing this job... I think it will be a problem with me as well if I would like to continue as a programmer in my later years, but I'll probably switch to project management or something like that when I'll feel that it's the right moment, however this will likely mean at least to relocate to Milan (north Italy) or alike. Or... agricolture if my project will work.
> ask for an adequate compensation when doing this job
That appears to be one of the motivations for certain prominent voices in the industry dismissing the value of experience. To be fair, even in early 90s there were telltale ads for "senior engineer, 3 years of experience" :)) I used to laugh when I saw those back then but now the joke's on me.
> I'll probably switch to project management or something like that when I'll feel that it's the right moment
None of my business but why not build a business around Redis and tend to your garden in the warmer climes. Milan is charming in a way but it[']s the coldest (in the psychological/emotional sense) Italian city I have ever visited.
As an over 50 developer, I find for me personally its better to start up a company, or join a small company as CTO. That way your useful experience is maximized from both a leadership and technical perspective.
You get to know the principles behind the code pretty well after 2 decades at it. In Los Angeles we just don't seem to have the same level of overt ageism. I've been coding since 1995 and haven't had to even dye my hair much less go for plastic surgery. If you're working your mind as hard as we do it keeps you sharp. Maybe other people your age couldn't learn this but your mind is much sharper than average and stays sharp thanks to daily mental workouts of solving hard engineering problems.
It's actually pretty true to my experience. I'd rather work with someone who's confident and self-assured, rather than emotionally needy. I'd rather work with someone who's experienced. I'd rather work with someone who's professional.
It is not ageism, it is supply and demand, as simple as that.
How many people had access to computers 25 - 30 years ago? Very few, like me, and we were privileged. Getting time to learn with a computer was expensive like getting knowledge about programming them. For example computer APIs were on books you had to buy.
You also had to spend so much time fixing your computer's BSD(blue screen of death), making your (software)modem to work, or your Linux distribution to install when it was all from the command line.
Now everybody can buy a Raspi for 40 dollars and connect it to TV and it just works. Everybody can access top quality tutorials on youtube, all the APIs and other documentation is online.
People in Ghana, Kenya or India can share a Raspi computer and learn. Chinese could also start buying them. While the West access to tech privilege persist, the gap is narrower and narrower over time.
This means there are a hundred times more programmers than in the past, specially young people. If they can compete with you watching youtube channels, they will, obviously.
If you have certain age with only programming knowledge you are not privileged anymore. This is tough for some people to understand.
I remember when knowing HTML alone could earn you lots of bucks. Not happening anymore.
I'm 48 and been a programmer since I was at school. I do contracting/consulting work so regularly change jobs, and I personally feel I have encountered surprisingly little ageism. I suppose a lot of it comes down to your attitude and enthusiasm.
I think the following generally helps:-
* Keep your CV/resume impressive. Nothing says "unemployable" like 10 years running an outdated DB system at a boring company;
* Change job or interview frequently;
* Don't try to adopt all the latest fads (impossible, anyway) - instead, play to your strengths and focus on your general area of expertise, and every few years learn a new relevant language or system in depth;
* Keep those old-school skills sharp! You can always impress a 21-year-old hacker in a hoodie if your command line / regex / disassembly / wireshark (or tcpdump!) skills are better than his.
The other side of this discussion is the exploitation of young engineers. Companies know they can pay them less and work them more.
Just look at the video game industry. Relies on a steady stream of suckers who can be used up and spit out. Their love of games is taken advantage of.
Many older workers are better, not worse, than their younger counterparts. They are discriminated against because they can't be so easily fooled (e.g. thinking a beer fridge is an acceptable trade for lots of unpaid overtime)
Experience matters. It took me years to even realize that programming is only half of my job. Though I'm not yet an OG, I'm a better engineer than when I started.
Not sure if it's because of the startup culture or simply because there are actually no older candidates.
In my case, 36yo, in a startup, I'm the oldest in it. But I've been interviewing many people and I think we only got 1 candidate which was older than me (we didn't hire because it was not a good fit, with so much experience but without much experience in our tech stack, we thought it would mean paying a fair amount for someone to be basically learning from us, as we were looking for coders, not architects/principals/leads).
It's kind of ironic hearing you claim that there are no older candidates, then in the next paragraph you confirm having rejected candidates due to not knowing the particular tech stack your team uses.
Even if there were legitimate reasons for not hiring that person (sounds like he/she was not a good fit fortheposition), the way you frame it sounds like you do not understand/appreciate what a senior engineer brings to the table. You don't pay seasoned professionals to come and learn the latest fad (though for them, it will look like a perk), you pay them to double check your ideas and spot potential problems they have seen before.
If you are offering a junior position with junior-level salary, and the senior candidate is OK with that, what's not to like? There are of course risks about the new hire jumping ship when something better comes, and you may structure their pay to discourage early attrittion. But if you blame the senior guy for not being junior enough, that's exactly the ageist attitude we are discussing here.
> candidates due to not knowing the particular tech stack your team uses.
candidate, in singular: it was only one.
> you do not understand/appreciate what a senior engineer brings to the table. You don't pay seasoned professionals to come and learn the latest fad
I completely agree, but this particular candidate had been using JavaScript for the past year and when we asked him why did he switch to JavaScript from the other tech stack he was using before, he answered something along the lines of "well, it's the latest fad".
So believe when I tell you, we rejected him exactly because of the opposite reasons you state.
Whenever I read such articles, I am completely at a loss as to what it means to code. Do they mean churning out code, like a codemonkey, for something that some architect has designed? Do they mean getting their hands dirty by pitching in to write some code for something that they themselves have architected? Do they mean doing the whole gig, starting from vague idea to producing a usable software, all by themselves and thus having to write all the code themselves instead of hiring a young ninja?
Perhaps this is an unpopular sentiment, but after 33 years of programming I have been observing more and more how many elements of a supposedly hyper-rational field function like religious beliefs or memes. I suspect that one reason people prefer working with young programmers is -- sometimes -- that they don't want push back on the beliefs that are underpinning their enterprises. To take a few simple examples, people with a lot at stake don't necessarily want to be told that something will probably take 3x longer than they think. Or that there are some philosophical issues at play in their strategy.
A truth that can hurt: people generally only consult nerds when they believe they have no other choice. To many people this means they only want programmers for "code monkey" style coding, i.e. I think there may actually be preference for inexperience in the wider world.
I'm sure age will take it's toll eventually, but in my case there is no doubt in my mind I write better code now than, say, 10 or 15 years ago.
Fortunately, there's a solution: freelance and work for people without these biases. It seems like there is no shortage once you leave groupthink environments behind.