The Planned Obsolescence of Old Coders (opens in new tab)

And this attitude is why older developers find it harder to get a job (I’m in my mid 40s myself).

What older coders have that younger ones do not, is experience. This can often halve the workload on some projects. The older I get in this profession, the more results I get out of less and less code.

I keep seeing this as an excuse for older developers who don’t want to keep up the date and stay marketable. Code is code. At some point you have to put lines in editor to make stuff work.

Also, let's not immediately fetishize the newer stuff. It is often a less well implemented retread of older technology. Seems like people have less patience for learning existing systems, so they just re-write some quick and dirty replacement and call it good. Perhaps it might be better if younger programmers learned the old stuff instead of just badly reinventing the wheel every few years.

The market can stay irrational longer than you can stay solvent.

That's pure gold. Not to say there haven't been advances--there certainly have been. But, there's also the issue of the shininess of new tech giving it undue cred, while simultaneously translating to an outsized denigration of the tech it purports to replace.

Frankly, a lot of these problems have been solved, and solved well.

Look at NoSQL as an example. There are certainly use cases for it, but then people went nuts, exclaiming things like "RDBMS must die" and touting no ACID transactions as a feature/benefit. Then, you get the trickle of reports that maybe NoSQL wasn't the best choice for this or that.

Finally, fast-forward to 2018 and you have announcements from MongoDB that they now support ACID transactions.

Many older coders have seen enough of these cycles, and have adopted a justifiably-cynical posture of "wait for it...".

I think if you pick a concrete example of this phenomena (say, Java applets vs. WebAssembly) and you ask "so why didn't someone take Java Applets and update them, why do we need WebAssembly?", the answers to why this happens start to become more apparent. It's not so much that Java applets were good and then we decided they were unfashionable, as that Java applets were always kind of ugly and we eventually stopped tolerating them.

For examples from before say, 2000, say Turbo Pascal a lot of the answer is because the thing in question was a proprietary product so once the financially backed dev team stopped working on it users were forced to move on to something else. Other times it's because the thing was written for an 80's computer platform that no longer exists outside of emulation and retrocomputing collections. Sometimes it's that the graphical standards the original used were for hardware with very different capabilities and making the thing usefully work on a newer system would almost require a total rewrite anyway.

Even beyond all that, there's another problem: Software is fairly hard to do literature review for. If I want to know if a particular research idea has been done before, I can hop on Google Scholar and figure it out with a few hours of carefully constructed search queries. Doing the same thing for software is very difficult, especially because most products for the majority of the fields history were proprietary. As a consequence, we don't have our history available to analyze in any easily accessed form. The Internet Archive has been doing what they can to rectify this situation. (See: https://archive.org/details/BeyondCyberpunkMacintosh) Nonetheless, there are still serious problems in this area.

I'm a younger person (23) who shares your frustrations, but I don't think that you can really wag your finger at people when there are real barriers to what you're proposing.

Creaky old software tools from the 70’s that are actually still in use have fought off decades of competitors that attempted to improve them.

So most of the issues I fix are due to mistakes I never would have made, because I already made them 10 or 20 years ago.

The worst part is that I no longer think in code, I think in piping data around and working functionally or declaratively because my brain is so apprehensive of side effects. I've found that younger programmers don't tend to realize how dangerous imperative programming (especially object-oriented programming) can be in the long term.

So what I really struggle with is motivation, because it can be so disheartening to not be listened to, or to work hard on an implementation only to have the elegance of its abstractions muddied beyond recognition by developers who don't take the time to understand them.

It's probably too late for me. I cling to a fantasy though of saving enough money that I can take a step back from programming and work on some of my own demo languages/frameworks that illustrate the flaws with the status quo. Because of handwaving and cargo culting, today's apps and websites encode so little core logic in proportion to lines of code that I'm hopeful I can make a niche for myself working at a higher level of abstraction and bidding less money on contracts someday. But it might just be a fantasy.

If a new technology is good or seems like it has potential I dig into it, and due to experience I can generally pick up something to the point of productivity in a day or two that takes junior developers weeks or months to reach. Or at a minimum know enough to figure out how to trouble shoot blocking bugs others can't solve by knowing where to look for solutions and what those solutions might entail. So to an extent I keep up to date in that I read the value propositions and reviews on new technologies so I know when they might be an appropriate tool in my toolbox to tackle some solution or other, on the flip side i'm not in a rush to pick up every flavor of the week framework or library that is more than likely to vanish with out a trace in 3-4 years.

Meanwhile outside of a persistent google recruiter whose been asking to do an onsite for the last year I've gotten dear john'd for something like 3 roles in the last month including one where i'm personal friends with the SVP of engineering. Is it missing keywords on my resume, my age, my career path, education, wth knows but unless the market has tanked it strongly differs from my experience a few years prior.

https://www.dropbox.com/s/haod1gpfjd723lg/Keith-Brings-Resum...

So much this. I’m in my 40s and I am on my third pivot. The first was a C++ bit twiddler for 12 years. The second was an MS stack “enterprise developer” and now a third - JavaScript everywhere, $cool_kids front end stack, AWS, and the Docker ecosystem. It’s been about a year and it’s going to realistically take 2 to 3 more.

That's a good point. But you also need to consider it from the point of view of the person sitting across the table. You might be very productive solving a problem in COBOL (to exagerate the point), but they are much more comfortable in Python/Vue.js and don't want to burden themselves with legacy ways. Because they can find someone solving the problem in the stack they want.

All they are is dust in the wind.

I'm proud of your grandmother, but TMI, man. TMI.

Any sane person with half a brain hates Electron.

(Not that there are any good alternatives, but still...)

Can I ask where it is you live to see hordes of young people finding solace in classic rock (or any sort of purely guitar-based music) ? Except maybe in US rural communities where it's all about country music (always has been, always will be) those days are well and truly over. "Nobody wants an electric guitar anymore" : https://qz.com/1013293/rock-and-roll-is-dead-sales-of-fender...

Meanwhile electronic music has taken millenials by storm. Tomorrowland festival sold out nearly 400.000 tickets in 40 minutes a few weeks ago. Same kind of numbers every year for Electric Daisy Carnival in the US.

Never in history has there been so much quality music released every day in all genres, because musicians can now do so without the gatekeepers of the past, much like Youtube has shattered the TV networks.

The consequence of that is that it's all about fragmented niches and discovery can be challenging. But there is gem after gem in my Spotify "Weekly Discovery" playlist. There has never been a more exciting time to be a music lover !

This for example: http://www.hawaiianreggae.org/artists

Nice and mellow, lots of young new artists. It's a pretty good scene.

If you look at my resume over the past 10 years and the tech I’ve used, it’s indistinguishable from younger developers.

But...it was popular in the late 90s, which corresponds to us mid-40 age people anyways.

So yes, it's helpful that people keep current, and obviously waiting for a new developer to get up to speed on the particular stack is always a cost (and it isn't a couple of weeks, for anyone). However, if what you really need is a senior person, it may well be worth that time.

Seeing this assumes the hiring manager understands how software is actually produced and maintained, not just what their current tech stack needs. It's surprising how often this isn't true, but a contributing factor is how mid level mangers are made - which is related to this discussion I think.

Also, most coding is maintenance. So yes, an experienced developer in some language is really worth a lot when you initially start out designing your system. But most of the work spent on that system will be maintaining and extending it and to be able to proficiently do that you need to:

1. Grok the problem domain, so you can connect the real-world / problem you're trying to solve with the code in front of you

2. Have a grasp on the limitations of your own system, which will come with experience as you work longer on it

Those things don't really count as languages, they appear to be a mix of development environments, software packages and architectures. Learning these things is critical and hard but there is a key mitigating factor. That factor is that really what needs to be learned is 'how we do things around here' which is typically company specific and needs to be learned by a new hire anyway.

My experience suggest new hires in cognitive roles (at medium-large businesses) take 1-2 years to get to the point where they can be proactively useful, purely from learning who is who, what the corporate history is, what ahs been tried before, why things are what they are and what their role's problem domain is really intended to be by their boss. Compared to that set-up time, the cost of knowing or not-knowing a technology is quite small.

> This whole "learn a new one in a couple weeks" mindset is toxic and needs to die.

It is true though. Learning a new programming language to the point you can write bug-free code and execute someone else's design is really easy. Learning how to solve a new problem is typically the hard part.

I 'learned' Python in 2 weeks. What I write looks a lot like C code, and I didn't make great use of the standard libraries, but it works fine. Compared to that learning how to use a large new library for a new problem typically takes a months.

The language + tools aren’t barriers anymore, the interesting part of solving business problems and how to apply the tools become the fun ones.

Moreover, if you're proud of how hard it is to learn ins and outs of your tech stack, you're likely using a shitty tech stack and costing your company tons of money.

But to your actual comment: I'm learning new things all the time. My focus when I'm coding in my spare time is a simple IDE, some project management tools, and a simple game engine I am building. I learn new things in those projects literally every day.

I'm not going to do a bunch of hello world apps in random new "Pro" technologies. I did a lot of that in my 20s, it was fun and I was curious about them, but my interests have shifted.

There are enough jobs I can say "no" to the people who want only coders who are using the newest "Pro" toolset.

Honestly, a good hiring manager will realize you ideally want BOTH that person and people like me on a team. One person will know that Rails 7 solves our new problem, and the other will know that a simple refactor will save 30 hours of headscratching over the next year.

And this is where ageism rears its head.

If two people apply for the same position, and you're OK hiring someone who has only 2 years of experience for the position, don't ask for more from someone who's been working for 20 years.

If I were interviewing such a candidate, I'd dig into why they built a custom framework. The answer to that question could be quite enlightening, especially if they mention business reasons for doing so, or if they talk about what they've learned since then.

When I started my own business a decade ago, I decided that existing web frameworks wouldn't suit my needs and built my own. Though I built a framework that suited my needs extremely well, it was a massive distraction from my actual business (which wasn't even tech). In interviews, I freely discuss how my NIH syndrome contributed to my inability to get the business off the ground; I've found that it tends to go over rather well with interviewers.

If they're over 45, then they likely worked in the late 90s and early 00s. If they were like many of us, then they worked on at least some web applications back then. This was far before jQuery and even Prototype.js on the frontend. Java, PHP and Perl were commonly used on the backend (or where I lived, more often IIS with asp). But the start of the career of someone in their 50s and even 45+ was before any commonly-used framework in open source scripting languages used for web development (unless you consider PHP to be a framework).

Even Spring framework was only created in 2003 (I just checked to confirm). Symfony in PHP was 2005. And those took several years to catch on in their respective ecosystems.

Tons of companies had in-house frameworks back then. Who did you think wrote them?

Even if someone working back then never explicitly built a framework, they used design patterns that mirror today's frameworks. If not, they were writing spaghetti code (and to be fair, that was pretty common back then).

Based on your username and your assertion ("older than you"), you're what, 45? Have you forgotten what it was like back then?

Granted, I hear what you're saying, but I'm not convinced your blanket dismissal is the right analysis without digging deeper on the individual details.

Agreed. However, if you're a software company you've already likely made all of those decisions. If I come work for you, I'm stuck with them. It doesn't matter if I like the package manager or the frameworks. That's just the background against which we work.

Our work is making our lives better, and solving the company's problems to the best of our ability, given all those constraints.

> honestly, I would be more concerned about hiring someone who built their own bespoke framework from scratch

Yes! I feel honestly quite nervous about sharing that aspect of my work, because I worry people will see me as out of touch.

But I am quite up front that I don't advocate using my toolkit in production environments. My professional advice is usually quite conservative. I tend to advocate for minimal disruption and using standard tools as they were meant to be used.

However, because I do that all day at work, I see all the cracks and warts in the architecture and when I go home I want to work on the future.

And even though you are correct "building a framework rarely adds business value"... that's not what motivates me. I do think there is value being created, and I will eventually be able to cash in on that. But I am doing it because I am interested in the future, and I want to work on tools that transcend the pointless busywork I have to deal with day to day, in the name of meeting quarterly goals (which TBF is crucially important in a business context).

I get direct enjoyment from working in my own little hobby world where those constraints don't exist, and that is enough motivation for me.

It's almost like you're pretending the years between 2008-2012 never happened, but I'm sure that's not the case.

Hum... My experience is that whatever framework a business use in any widespread manner, I do always have to build another one on top, because generalist libraries completely suck for productivity. Unless you are a single app shop, then you can just hard-code everything.

I don't get how improving development speed does not add business value.

Not really, you pick up something you forget much faster than something you've never seen before. It's all in there somewhere.

(although I agree with the sibling comment — one doesn't really learn most languages in a few weeks)

Better to hire for your particular skills. And younger is cheaper.

Anyways the article as a whole is heavy on anecdote and low on data & facts. There is an emphasis on outcome metrics but the author doesn't bother to examine any data on productivity vs age.

Asians, especially from India have an out of proportion presence in technology jobs. It is no different than any other ethnic industry affiliation. Irish were cops, Greeks own diners, and South Asians are huge in tech, and have ethnic social networks that connect folks to jobs, just like any other tightly meshed ethnic community.

> The organizers know how male and white the tech industry is, so they make a special effort to recruit a diverse speaker lineup.

Yes, the author was using social awareness to segue into ageism, but it is still factually incorrect (or at least highly misleading) to state that the industry is predominantly "white".

Does it make sense to consider Python an old language if it's still a living language? The next version is coming out in October, and most new projects started today are running on versions released within the three years.

This seems pretty different than something like COBOL, where it's technically still being developed but not in anywhere near the same way.

But fundamentally, if you can't move the decision making power/responsibility/(+ to some degree compensation) out to non-traditional locations in your org structure, you'll naturally have to move those people towards the more traditional locations....

>This has been known forever, yet it still happens - Why?

This problem exists in hardware departments too. My best guess is that they want managers familiar with the tech/industry/company. My second best guess is that it's a natural human tendency and hasn't been addressed systematically.

Making a real time video chat client is now a literal programming exercise, it used to be the domain of multi-million dollar venture backed startups that were valued in the billions.

Real time chat between users is now a feature that is added to an application in a day, or even a few hours if you follow any of the myriads of tutorials available on YouTube.

Go from writing a UI in C/C++ to writing it in any of the higher level languages. Assuming you don't get caught in some design pattern trap that results in massive code bloat, it is now possible to do things in hours that used to take days to weeks.

Heck, transparency is no longer "write some ASM" routines, it is setting an opacity variable!

Some tech stacks, such as those for making basic CRUD apps, may have actually degraded a bit, but at the same time someone who is only slightly technical can now drag and drop their way to an online store front that is a fair bit more powerful that Viaweb was back in the day!

Heck, it is possible to now go from an empty folder to writing+deploy HTTPS API endpoints in under half an hour.

Edit:

More stuff!

App (not web!) updates can be deployed to users by uploading a file and having a client pull down the changes and seamlessly switch over to the new code next time the app is launched. Versus mailing out disks!

There are app stores that you upload intermediate code to and they'll compile apps to the appropriate architecture for a customer's device!

During 72 hours of coding for Ludem Dare, game developers and artists work together to create games that are as complex as a full fledged commercial game would have been 25 years ago.

And of course, many corporate software engineering efforts continue to fail or go massively over budget for largely political reasons.

On the other hand, companies who engage in age discrimination are probably shit companies, so are you really losing out by them not considering you?

To be fair, I don't plan to retire at 39 or 40, as long as someone hires me with reasonable compensation (2x would be a dream!). I'm purely trying to protect myself against a foobar scenario where indeed, I become obsolete from the point of view of most employers, due to "old" age.

You're assuming that he would actually want to stay in that other place long enough for the house purchase to make financial sense. You have to own a house at least 5 years for it to work out, minimum. Moreoever, in the big tech hub, you're making more money, so if you keep your living costs low, you'll bank more cash than living someplace cheaper.

Curious, why? I am having no problem being hireable right now at all (literally just joined a FAANG recently).

As far as I know, it would be impossible to get the same pay I'm getting now anywhere else. Even after considering the high cost of living, the spread between income and cost of living is very high, and allows me to stash away a significant amount of savings every year, to pay for my future freedom. I really doubt I'd be able to save that much if I were working anywhere else.

What else would you suggest?

If I could go back in time I would have the done the bay area thing when I was young too. But, life is a bit of give and take - there are some good things that happened in my life not taking that course (even if they didn't all work out as planned). So you kinda have to appreciate those parts of life and accept the fact that you are maybe not in the financial situation you wish you were in.

The only guarantee we have in life is this moment :)

"the software engineering labor market can stay irrational towards older people longer than the 2 decades past 40 where I could stay effectively employable".

I'm 34, so it might become different when I'm in my forties, but so far it's not getting any harder. Your summary below is spot on.

> I understand how computing systems work generally and the laws of physics impose some hard limitations that sort of massage any solution to look similar enough to any other that it isn't that hard to figure out what is going on. Sure I'll lack some of the deep knowledge that someone who has focused solely on these set of technologies may have but honestly most of the programmers I meet don't have that to begin with.

Additionally, there are different levels of knowing a language. You can write perfectly workable programs in C without ever touching function pointers. So what's your level of mastery?

And then there are more difficult languages. Have you tried C++ or Scala? Ever explored the esoterical intricacies of Java's type system? Lisp? Objective-C? Kotlin? ADA?

Ok, that's languages. How about parallelism? Massive parallelism? Tight resource constraints such as limited memory? Error handling? Modern language and compiler design?

I'm not trying to say you need to know all these things to be a decent coder. My point is there are many harder problems out there and maybe if you're bored you might want to try working on some of them.

I'm 40, and it's easier than ever.

I do get a bit pissy now when I have to spend a week learning some technology that I end up using for 15 minutes to do one thing, and then discard, but that's about it. (That has, unfortunately, happened.) But otherwise, it's easy. I've done non-trivial development now in languages that I don't even properly know, I just know all the surrounding languages and how to Google fast enough to make up for the rest.

I will also get a bit pissy when I do one project over here and they're all in Ansible, and I do another project over here and it uses Salt, and then I tweak something over there and it's in Puppet, and then I have to help out over there and they're in Terraform + Docker + some home grown Compose thing that predates Compose, etc. That general category of things was a legit advancement and I prefer using them to what came before (in my world, nothing but precious snowflake servers), but I'm frustrated that I have to keep relearning the easy "surface syntax" stuff over and over again for what is almost the same exact task.

I will also admit to a bit of impatience with the "re-inventing the wheel" phase of new technologies. For a recent example, the initial AWS "serverless" stuff (dumb name, inevitable idea) was written with like zero attention paid to the basic needs of source control, or the utter inevitability of how your service that was designed to have like 10 5-line scripts in it will be used to implement the next Amazon, so I stayed far away from it. Even now I'm not sure it's all that great. Docker I'm still not all that up on for somewhat similar reasons; for all the "innovation" in it it took years to be able to do basic things halfway properly. I'm definitely kind of done riding the cutting edge in the sense of chasing down communities that I can look at and tell are just going to be chasing their own tails for the next couple of years.

Sometimes a tech community comes out led by a person or a team that has experience, though, and when that happens I'm all over it.

Plus at this point there's literally so many things going on that nobody can keep up, not even the "young bucks". There is not a single person on this planet who is at expert level with all of the cream-of-the-crop Javascript frameworks, and there hasn't been in a long time. There's just too many now. When $YOUNG_GUY is up-to-date on 80% of the hot new shit and $OLD_GUY is sneering at it and up-to-date on 0% of it, back in the 1990s and such, yeah, $YOUNG_GUY might have an advantage. But when $YOUNG_GUY is up-to-date on 3% of the hot new shit and $OLD_GUY is up-to-date on 1.5% of it, and also knows a lot more stuff and can drop into a much wider array of projects and contribute (with the contribution being something other than "Let's rewrite all of this in $HOT_NEW_SHIT before we do anything else!"), the difference is far less extreme, even on the new tech's terms.

Unsurprisingly, computer programming isn't such special and amazing stuff that, almost uniquely in all the fields of human endeavor, you're worse after doing it for 20 years than you were after doing it for 2. Other than cases where the body itself just breaks down, like professional-level sports, almost nothing works like that. I think it's a historical accident of some very unique circumstances in the 1990s that have lead anyone to believe programming is different. I think the idea has gone a long ways towards dissipating already, but has a long way to go yet, too.

In the first case I didn't particularly mean to specialize, but just to continuously do things you really don't even know if you can, to continually push against what you think is possible for yourself: create a js framework for instance, even a terrible one that you abandon after a year and move on to a completely different project, but that requires you to dig and research and stretch your brain. The second case was more you know it's possible and it's just following a tutorial to get up to speed on the techniques; someone else did the "hard" work, and you're not really getting anything out of it.

The first thing gives you skills that age well: you'll learn about lots of gotchas about the internals of how js and presumably other language runtimes work etc, which will help in lots of different positions; the second just gives you a line item on your resume until that fad is gone.

E.g. this free (!) intensive course in Sweden: https://www.academy.se/artiklar/tieto-och-academy-startar-ko...

My hunch that consulting jobs that require COBOL are primarily looking for experience (especially with finance systems) than for 40 years experience specifically with COBOL.