An old programmer loses his job(medium.com)
medium.com
An old programmer loses his job
https://medium.com/writers-blokke/an-old-programmer-loses-his-job-caa4670f34dc
79 comments
Take a job with a lesser title / pay but in exchange get exposure to the new tech you want. Do that for a year or two and the next position you'll be back on par.
Depends on what specifically interviewers are looking for, but:
- You do have production experience, just not with the new software - You know the new software, and especially if it’s new, you probably know it as good as most other developers - Your prior coding experience won’t 100% transfer over to new tasks, but it won’t 0% transfer either. For example many programming languages are very similar, if you’re familiar with one general-purpose language you’re ~almost~ familiar with all of them (C++, Rust, C#, Java, Scala, Kotlin, Swift, TypeScript, etc.)
- You do have production experience, just not with the new software - You know the new software, and especially if it’s new, you probably know it as good as most other developers - Your prior coding experience won’t 100% transfer over to new tasks, but it won’t 0% transfer either. For example many programming languages are very similar, if you’re familiar with one general-purpose language you’re ~almost~ familiar with all of them (C++, Rust, C#, Java, Scala, Kotlin, Swift, TypeScript, etc.)
> but no actual production experience
Ok, so it would be unethical for me to suggest that you lie and imply that you have actual production experience but... there's really no way for most interviewers to realistically check whether or not the company you worked for did or didn't use (say) AWS Aurora in some internal projects. That's why they do technical screens and ask you trivia questions about things.
Ok, so it would be unethical for me to suggest that you lie and imply that you have actual production experience but... there's really no way for most interviewers to realistically check whether or not the company you worked for did or didn't use (say) AWS Aurora in some internal projects. That's why they do technical screens and ask you trivia questions about things.
If you're working in software development already, all decent employers should encourage you to constantly learn, even if it isn't directly related to the job at hand.
If this isn't the case, it's a huge red flag.
It’s simple: Every year find out what the most in demand tech is for getting a job. Then learn what you don’t know already. Repeat. That’s it.
Eh? Why the downvote? That’s what I have always done and it works.
I didn't downvote you, but I could imagine it is because your comment does not actually address the point made by the OP: which is that you can learn new tech that is not applied in your job only on a theoretical level, but you will not be able to claim applied knowledge of it on your resume.
I think though that there's other ways to apply new things you learn than just in your job. Open source projects come to mind, of course.
However, that raises a related point: if our field one where it's a necessity to spend a substantial amount of hours in addition to your day job (for both studying new tech and finding ways to apply it) just to stay relevant for the job market?
I think though that there's other ways to apply new things you learn than just in your job. Open source projects come to mind, of course.
However, that raises a related point: if our field one where it's a necessity to spend a substantial amount of hours in addition to your day job (for both studying new tech and finding ways to apply it) just to stay relevant for the job market?
Well I disagree with that. The skills you learn in your spare time are 100% applicable to the job you are after as long as you make sure you solve “real” problems when learning it. Otherwise logically it would be impossible for anybody to get a first job since they (with no previous job) doesn’t have any skills :) I more than once have gotten a job based on skills I learned outside of work. I just made sure I could clearly demonstrate that I had the skills.
I know what you mean but keep in mind that the kind of jobs you can score as a newbie are - for that very reason - also quite limited.
But just to be clear: no-one claimed that you cannot learn any new skills outside you work. The point was really more about the difficulty of demonstrating that you actually have said skills, and not just say you do.
But just to be clear: no-one claimed that you cannot learn any new skills outside you work. The point was really more about the difficulty of demonstrating that you actually have said skills, and not just say you do.
The easiest transition is to learn a new skill applicable to what you're already doing. Tell your employer that your Cobol project is ultimately unmaintainable and they will have difficulty hiring Cobol engineers in the future. This is true and you both know it. Propose rewriting the system in Java (or whatever you want to learn, so long as it's a reasonable choice from an engineering perspective). They'll often go for it. Improve your odds by finding a small piece of the system to replace as a pilot project, where success on that small piece would offer immediate benefits like new automation options or the elimination of legacy equipment. If it's a small risk, they'll usually let you try, and if it works out, they'll often let you keep going. They don't want to be stuck with a project they suddenly can't maintain, and you're the best person to replace it -- not because you're a Java expert, but because you're an existing system expert. Find a low cost, low risk approach and it becomes a very good deal for them. They usually take you up on it (and are delighted by the opportunity), if they can spare the time and expense. Sometimes they really can't, and the answer for that is to be patient. And there's room here for going rogue and doing it without permission - I have done this many times in my career, and finding an opportune moment to say, "by the way, I had a slow week a while back and used it to make this more efficient and modern alternative for us" is almost always received well, especially if it just happens to be helpful with this week's painful problem. Skills used to tackle the same projects you already know how to do are both easy to move into, still take advantage of your experience, and are often easy to weave into your professional life. Boom, Java experience. The real beauty of this is that for your next job, they don't know you only have six months of Java experience. They see you worked at Corp for 5 years, you did Java there, and you can clearly do Java now. They don't usually ask too many questions.
A harder (but still pretty easy) transition is to work on something other people at your company are doing, but which you aren't. Perhaps there's a group doing big data and you want to get into it but you've never done it. Learning the skill on the job can be a hard sell, but it isn't always impossible. It's worth asking. Employers like working with smart people they already know, and can see it as a better bet to teach a known good guy a new skill than hire someone with the skill who turns out to be a terrible engineer. Some places will actually send you to school to get the certificate or whatever. However, this route often doesn't work because they genuinely can't afford to train you. Your odds of success go way up if you're willing to learn it on your own time. They improve even more if you can get pretty good at it. It helps further if the people on the team respect your intelligence and capability. The killer strategy is to make your preferences known, keep doing excellent work on your old system that no one else is willing to do, build up karma that way, get really good at the other thing on your own time and talk shop to the other team about their work, wait for a good time for the company. . . . your odds of eventually getting in are excellent. Boom, data science experience.
For something totally unrelated to what your company does, this is a lot harder. You have to both learn the skill and demonstrate competence on your own time. Your best bet is to build up a portfolio of accomplishments and side projects that you can share. This isn't the same as professional experience, but professional experience demonstrating you're capable, properly socialized, and people will actually trust you with stuff for years on end -- all of this still puts you ahead of total newbies, even if the specific skill is new to you. The truth is that talent is in such desperate demand (especially if you chose your new skill wisely) that interviewers are usually much more interested in whether you can actually do the work than they are in what your resume says. So just make sure you really can do it, and you really can prove that. Some employers really will insist that you have those 15 years of Haskell experience the job req says they want. But most of them will see solid general engineering experience on your resume, see during the coding portion of the interview and by looking at your public work that you really can do the job, and they'll decide you're probably the best bet they're going to get to fill the position anytime this year, and they really do need the help. Don't take "X years of Y experience" too seriously. If you really can Y, your odds are excellent.
A harder (but still pretty easy) transition is to work on something other people at your company are doing, but which you aren't. Perhaps there's a group doing big data and you want to get into it but you've never done it. Learning the skill on the job can be a hard sell, but it isn't always impossible. It's worth asking. Employers like working with smart people they already know, and can see it as a better bet to teach a known good guy a new skill than hire someone with the skill who turns out to be a terrible engineer. Some places will actually send you to school to get the certificate or whatever. However, this route often doesn't work because they genuinely can't afford to train you. Your odds of success go way up if you're willing to learn it on your own time. They improve even more if you can get pretty good at it. It helps further if the people on the team respect your intelligence and capability. The killer strategy is to make your preferences known, keep doing excellent work on your old system that no one else is willing to do, build up karma that way, get really good at the other thing on your own time and talk shop to the other team about their work, wait for a good time for the company. . . . your odds of eventually getting in are excellent. Boom, data science experience.
For something totally unrelated to what your company does, this is a lot harder. You have to both learn the skill and demonstrate competence on your own time. Your best bet is to build up a portfolio of accomplishments and side projects that you can share. This isn't the same as professional experience, but professional experience demonstrating you're capable, properly socialized, and people will actually trust you with stuff for years on end -- all of this still puts you ahead of total newbies, even if the specific skill is new to you. The truth is that talent is in such desperate demand (especially if you chose your new skill wisely) that interviewers are usually much more interested in whether you can actually do the work than they are in what your resume says. So just make sure you really can do it, and you really can prove that. Some employers really will insist that you have those 15 years of Haskell experience the job req says they want. But most of them will see solid general engineering experience on your resume, see during the coding portion of the interview and by looking at your public work that you really can do the job, and they'll decide you're probably the best bet they're going to get to fill the position anytime this year, and they really do need the help. Don't take "X years of Y experience" too seriously. If you really can Y, your odds are excellent.
Programming is a a commodity skill these days, less and less money in it.
When I compare today's salaries with what developers were paid in the 90s, I don't get that impression. Salaries keep going up.
Yep. Thats why recruiters/employers are so desperate to fill jobs. That's why governments (pushed by big tech) are trying to teach toddlers how to code. That's why 200k+ salaries for senior positions are now pretty common.
I cant think of any objective reason this would be true. Salaries are going up and our influence in the world is just going up. Through covid our value seems to have gone up even more actually.
the whole field's expanded; the average pay is lower because there is so much janitorial work to be done, but the high end has exploded.
Nope. Quite the opposite actually.
1) That's not true. There's a narrative outside the field that it can be outsourced, even VCs have "sagely" told me that, but it's a lay person misunderstanding. (Ironically, very little semi hardware is done in US startups, so that leaves only software.)
2) US companies keep ratcheting up interview demands, which artificially constrains eligible candidates.
Examples are using coderpad where your code has to compile and pass a test/performance suite now, and doing random memory quizzes in addition to programming. But that's the fault of the hiring company.
2) US companies keep ratcheting up interview demands, which artificially constrains eligible candidates.
Examples are using coderpad where your code has to compile and pass a test/performance suite now, and doing random memory quizzes in addition to programming. But that's the fault of the hiring company.
LeetCode?
We do have a strange profession.
There aren’t clear pathways to careers for people who might need to transition.
We do have a strange profession.
There aren’t clear pathways to careers for people who might need to transition.
There is a lot of age-ism in the industry.
But there are also a lot of people who thought that if they learned one environment they'd have a job forever, like their dad running the panel stamper at GM or working in a coal mine.
I know of one particular guy who learned dBase III and is still using it, and stubbornly refuses to move off it despite his employer deep-sixing the system in favour of a new outsourced one. The old one "still works" despite blowing out the theoretical size limit of dBase III and having to live every day on a knife edge of not knowing whether the environment will start again today, but he is uninterested in learning anything new.
I'm not 65 but I am over 50. I don't find it hard to keep up with new tech, in fact that experience makes it easier as all the "new tech" is usually just old stuff reinvented by people who don't know history. Which is fine, it's boring to read about the crufty beardies and their epic hacks. Perhaps it's better to keep it an open secret so I can keep programming longer.
But there are also a lot of people who thought that if they learned one environment they'd have a job forever, like their dad running the panel stamper at GM or working in a coal mine.
I know of one particular guy who learned dBase III and is still using it, and stubbornly refuses to move off it despite his employer deep-sixing the system in favour of a new outsourced one. The old one "still works" despite blowing out the theoretical size limit of dBase III and having to live every day on a knife edge of not knowing whether the environment will start again today, but he is uninterested in learning anything new.
I'm not 65 but I am over 50. I don't find it hard to keep up with new tech, in fact that experience makes it easier as all the "new tech" is usually just old stuff reinvented by people who don't know history. Which is fine, it's boring to read about the crufty beardies and their epic hacks. Perhaps it's better to keep it an open secret so I can keep programming longer.
Yes, I've been surprised too by the sentiment in the article of "it's too hard to keep up with new developments in programming languages" because that is what we all face, be it young or old.
It is true, though, that it feels like change has been accelerated greatly over recent years. I mean, how many different programming language were actually used outside of niche applications in the 80s, maybe even 90s? More than a couple, for sure, but if you look at popular languages right now, there's a really long (and not overly thin) tail. And a lot of the languages you'll find on that list are fairly young, while older languages have mostly disappeared (besides C maybe).
I do wonder though what the author finds so hard to learn. I'm not exactly new, either, but with more experience I don't necessarily find new things harder to learn than when I was young. It's different - perhaps my brain doesn't work as quickly any more but with more experience, it's either to recognize where "new" concepts are very similar to stuff you already know.
With programming, I think there are people who get it easily and those who struggle. And don't mean "at first" but in general, and those who struggle would probably struggle with any language be it new or old, while those to which it comes more naturally should be able to adjust to new languages fairly easily, no?
But then again, it's not just the languages that are new, but development styles have also changed quite dramatically since the time the author first entered the industry. Just think how much powerful IDEs have changed the style of development - hot swap, time traveling debuggers, inline documentation, on-the-fly compilation with in-editor error messages, refactoring support,... This is all stuff that the author is implicitly referring to as well.
It is true, though, that it feels like change has been accelerated greatly over recent years. I mean, how many different programming language were actually used outside of niche applications in the 80s, maybe even 90s? More than a couple, for sure, but if you look at popular languages right now, there's a really long (and not overly thin) tail. And a lot of the languages you'll find on that list are fairly young, while older languages have mostly disappeared (besides C maybe).
I do wonder though what the author finds so hard to learn. I'm not exactly new, either, but with more experience I don't necessarily find new things harder to learn than when I was young. It's different - perhaps my brain doesn't work as quickly any more but with more experience, it's either to recognize where "new" concepts are very similar to stuff you already know.
With programming, I think there are people who get it easily and those who struggle. And don't mean "at first" but in general, and those who struggle would probably struggle with any language be it new or old, while those to which it comes more naturally should be able to adjust to new languages fairly easily, no?
But then again, it's not just the languages that are new, but development styles have also changed quite dramatically since the time the author first entered the industry. Just think how much powerful IDEs have changed the style of development - hot swap, time traveling debuggers, inline documentation, on-the-fly compilation with in-editor error messages, refactoring support,... This is all stuff that the author is implicitly referring to as well.
> Yes, I've been surprised too by the sentiment in the article of "it's too hard to keep up with new developments in programming languages" because that is what we all face, be it young or old.
What you're ignoring here is that in your 20's and early 30's you have nothing but time. You can spend your evenings and weekends reading O'Reilly books and churning out cool side projects. As you get older, non-work responsibilities increase massively for most people, as you spend time taking care of children, elderly parents, doing small home repairs, etc. Suddenly you can't just drop everything and spend the entire weekend reading documentation and tutorials when $BIG_CORP suddenly decides that all work must henceforth be done in $SEXY_NEW_FRAMEWORK_X.
What you're ignoring here is that in your 20's and early 30's you have nothing but time. You can spend your evenings and weekends reading O'Reilly books and churning out cool side projects. As you get older, non-work responsibilities increase massively for most people, as you spend time taking care of children, elderly parents, doing small home repairs, etc. Suddenly you can't just drop everything and spend the entire weekend reading documentation and tutorials when $BIG_CORP suddenly decides that all work must henceforth be done in $SEXY_NEW_FRAMEWORK_X.
I agree with the time issue, but we didn't have resources like StackOverflow or reams of personal blogs back then. I find it easier to learn something new now, at least easier to get over that initial learning curve. Proficiency still takes time but it always did.
>that in your 20's and early 30's you have nothing but time
20's and 30's are where lots of people have time pulled away by kids, not later (median in 2020 was around 28 for kids). And in your 50's and 60's people generally have lots more time as kids move out (28+20=48 = kids gone or at least not such a time sink).
If anything, 50's and 60's should be a golden age of learning.
20's and 30's are where lots of people have time pulled away by kids, not later (median in 2020 was around 28 for kids). And in your 50's and 60's people generally have lots more time as kids move out (28+20=48 = kids gone or at least not such a time sink).
If anything, 50's and 60's should be a golden age of learning.
I have worked with plenty of young people who had zero interest in learning anything new. It isn’t an age problem. It is a personality problem.
Exactly. Although to me the style of programming has kind of come full circle. We all used to make fun of Emacs as an operating system in search of a good editor, but VSCode is basically a very Emacs like environment.
The resurgence of the command line has surprised me, in a good way. Sitting at a debian box with VSCode and a few terminal windows humming isn't a big leap from what having a sparcstation on my desk used to feel like.
Visual Studio and Android Studio suddenly feel very old fashioned and confining.
Edit: to be fair, if your background was mainframe programming, most of those paradigms would be pretty alien.
The resurgence of the command line has surprised me, in a good way. Sitting at a debian box with VSCode and a few terminal windows humming isn't a big leap from what having a sparcstation on my desk used to feel like.
Visual Studio and Android Studio suddenly feel very old fashioned and confining.
Edit: to be fair, if your background was mainframe programming, most of those paradigms would be pretty alien.
Interesting.
Would you mind elaborating about this "full circle" analogy? How come the preferred way of coding is now a combination of a powerful editor + the command line (again)?
Would you mind elaborating about this "full circle" analogy? How come the preferred way of coding is now a combination of a powerful editor + the command line (again)?
If you had a Sun3 or a Sparcstation, you would have a windowing environment that most of us basically used like having a corral of terminals in front of us (or at least that's what I would do). Actually I think the first Sun I sat at (at the Australian National University in Canberra) was running SunView:
https://en.wikipedia.org/wiki/SunView
At the time, the Sun workstation (and competitors) made the graphics on a PC look pathetic. A PC simply couldn't drive enough dots on the screen to compete with Sun or SGI.
I'm talking about programming a big system in C here but other languages would be similar.
A pile of terminals would be your editors. If you were lucky, you could drag out your window and the editor would still format OK (vi was good at this, emacs sometimes not so good depending on your local sysadmin and what they had installed). Other editors... didn't really do that and you were stuck with whatever the termcap entries on the machine looked like.
There were native "windowed" editors available but they mostly sucked for a programmer as they were more like "point and click" and didn't have all the buffer commands, quick jump to the line you wanted etc. shortcuts that a good programmers editor has. Line numbers are important!
Most non-trivial programs have lots of source files, so you would have half a dozen vi sessions in half a dozen windows running. One window I would use just for running the compiler. The workflow was: compile the program, compiler spits out line number and file where problem is. Likely you already have it open so jump over to that window, fix the problem, :w!, recompile.
Once it compiled, fire up dbx or whatever was installed and run your stuff. dbx was (is?) capable of setting break points, inspecting things etc. You'd find the issue, kill the debugger, fix it, recompile. Happy programmers felt a new freedom compared to being hunched over a vt220 terminal. It was bliss.
Then, Visual Basic turned up. It took all the ideas of something like Turbo Pascal (everything on one screen) and kinda smooshed it together with the workstation windows idea, but instead of little windows all over the place, you have one big window with a pile of little windows inside it. For small screens (say 640x480) it felt a bit like having a Sun. Well, it felt like a Fisher Price toy but for putting together CRUD GUI apps it was pretty much unbeatable.
At that point I had moved onto Smalltalk (VisualWorks) but it was not like Unix. Everything is inside the environment - windows spread out everywhere but no command line stuff whatsoever. For the time it was fantastic (sorry digression).
Eventually, as the capabilities of PC's increased the industry kind of settled on things like Visual Studio where you have one screen, and tabs, and everything you need to do is on a menu somewhere. But having somebody have to program up all those menu items just about kills the release cycle of new features. Every time you add a new feature to the compiler you have to change the properties screen, test it, merge it, roll it into the next release. I understand why Microsoft in particular abandoned that idea for .NET where the importance of a PowerShell window really started to come into play.
Outside of MS you start to get things like Node.js where you need to run a command line tool to set things up. So it became normalised to want a rich CLI and all the nice things like "more" and "grep" suddenly become more useful again. Which is unfortunate if you are running Windows because suddenly you have to install a pile of 3rd party stuff. And along with it the most uselessly named system in the history of uselessly named things: chocalety. Hey whoever named chocalety, go f*ck yourself.
So VSCode is almost back to where I started. It has a bunch of tabs instead of different editor windows, but a lot of the time I'm in a terminal running "code ." and starting another instance of it. The compiler is running in a terminal session within VSCode but you don't have to do things that way and sometimes I don't, I have another terminal open where I do "dotnet start" or "docker run" and just attach to the process rather than using the vscode built-in launch stuff, because I want to drag that output window out nice and long instead of being cramped to 8 lines at the bottom of VSCode.
Onion on belt etc.
edit: If you really want to know where all the Ctrl-Z, bg, fg etc. stuff came from in the Unix shells, it was programmers who had 10 vi sessions running on a single terminal and were switching around between tasks.
At the time, the Sun workstation (and competitors) made the graphics on a PC look pathetic. A PC simply couldn't drive enough dots on the screen to compete with Sun or SGI.
I'm talking about programming a big system in C here but other languages would be similar.
A pile of terminals would be your editors. If you were lucky, you could drag out your window and the editor would still format OK (vi was good at this, emacs sometimes not so good depending on your local sysadmin and what they had installed). Other editors... didn't really do that and you were stuck with whatever the termcap entries on the machine looked like.
There were native "windowed" editors available but they mostly sucked for a programmer as they were more like "point and click" and didn't have all the buffer commands, quick jump to the line you wanted etc. shortcuts that a good programmers editor has. Line numbers are important!
Most non-trivial programs have lots of source files, so you would have half a dozen vi sessions in half a dozen windows running. One window I would use just for running the compiler. The workflow was: compile the program, compiler spits out line number and file where problem is. Likely you already have it open so jump over to that window, fix the problem, :w!, recompile.
Once it compiled, fire up dbx or whatever was installed and run your stuff. dbx was (is?) capable of setting break points, inspecting things etc. You'd find the issue, kill the debugger, fix it, recompile. Happy programmers felt a new freedom compared to being hunched over a vt220 terminal. It was bliss.
Then, Visual Basic turned up. It took all the ideas of something like Turbo Pascal (everything on one screen) and kinda smooshed it together with the workstation windows idea, but instead of little windows all over the place, you have one big window with a pile of little windows inside it. For small screens (say 640x480) it felt a bit like having a Sun. Well, it felt like a Fisher Price toy but for putting together CRUD GUI apps it was pretty much unbeatable.
At that point I had moved onto Smalltalk (VisualWorks) but it was not like Unix. Everything is inside the environment - windows spread out everywhere but no command line stuff whatsoever. For the time it was fantastic (sorry digression).
Eventually, as the capabilities of PC's increased the industry kind of settled on things like Visual Studio where you have one screen, and tabs, and everything you need to do is on a menu somewhere. But having somebody have to program up all those menu items just about kills the release cycle of new features. Every time you add a new feature to the compiler you have to change the properties screen, test it, merge it, roll it into the next release. I understand why Microsoft in particular abandoned that idea for .NET where the importance of a PowerShell window really started to come into play.
Outside of MS you start to get things like Node.js where you need to run a command line tool to set things up. So it became normalised to want a rich CLI and all the nice things like "more" and "grep" suddenly become more useful again. Which is unfortunate if you are running Windows because suddenly you have to install a pile of 3rd party stuff. And along with it the most uselessly named system in the history of uselessly named things: chocalety. Hey whoever named chocalety, go f*ck yourself.
So VSCode is almost back to where I started. It has a bunch of tabs instead of different editor windows, but a lot of the time I'm in a terminal running "code ." and starting another instance of it. The compiler is running in a terminal session within VSCode but you don't have to do things that way and sometimes I don't, I have another terminal open where I do "dotnet start" or "docker run" and just attach to the process rather than using the vscode built-in launch stuff, because I want to drag that output window out nice and long instead of being cramped to 8 lines at the bottom of VSCode.
Onion on belt etc.
edit: If you really want to know where all the Ctrl-Z, bg, fg etc. stuff came from in the Unix shells, it was programmers who had 10 vi sessions running on a single terminal and were switching around between tasks.
I'm old enough to have worked on SPARCstations too. I have fond memories of them, actually.
It was at the time when the big debate was whether to use GNU Emacs or XEmacs. If you weren't in team vi, that is.
I remember sharing Emacs frames between machines (using `xhost +`) to do "pair programming"... or rather, have your more experienced co-worker debug your awful code for you ;-)
Anyway, thanks for the interesting write-up. I myself never got into vi, although I don't subscribe to the flamewar mentality of old. I wish I were proficient in both.
Emacs, by the way, always had multiple "tabs" that you could switch between. Just sayin' ;-)
It was at the time when the big debate was whether to use GNU Emacs or XEmacs. If you weren't in team vi, that is.
I remember sharing Emacs frames between machines (using `xhost +`) to do "pair programming"... or rather, have your more experienced co-worker debug your awful code for you ;-)
Anyway, thanks for the interesting write-up. I myself never got into vi, although I don't subscribe to the flamewar mentality of old. I wish I were proficient in both.
Emacs, by the way, always had multiple "tabs" that you could switch between. Just sayin' ;-)
The Sun gear was really cool to work on. I think occasionally I would like to buy an old one just to have around.
My mentor at the time hated emacs. She said everybody had to learn vi because on a new machine it might be the only thing installed. The flamewars over it seem quaint now.
My mentor at the time hated emacs. She said everybody had to learn vi because on a new machine it might be the only thing installed. The flamewars over it seem quaint now.
I learned enough vi to get by the few times I actually had to use it for that reason (nothing else installed). Which comes down to cursor movement, changing the mode, deleting lines and chars, and :wq!
But in all these years I hardly ever encountered a situation where I had to edit some files on a machine that only had vi installed. Perhaps I would have learned it by now if that had been the case more often.
But in all these years I hardly ever encountered a situation where I had to edit some files on a machine that only had vi installed. Perhaps I would have learned it by now if that had been the case more often.
> I mean, how many different programming language were actually used outside of niche applications in the 80s, maybe even 90s?
I started my career in 1985. I've never been a mainframe programmer, but I know back in the day they were using Cobol (still do!), RPG, PL/1, and JCL.
On the minicomputer side they were using Fortran, Lisp and C.
Microcomputers also adopted C but also added Pascal, Modula-2/3, and of course, Basic.
In the late 70's and even early 80's they were still working on the paradigm shift to structured programming. That's table stakes today but yes, there was a time when structured programming was a paradigm shift. Structured programming was all the buzz.
And then came those weirdos from Xerox PARC with Smalltalk and talking about "object-oriented programming." Great. Another paradigm shift. Bjarne Stroustrup then had to go and post incrementally improve C to add object-oriented programming to give us C++.
So far we've only made it to 1986 and we haven't talked about platforms! The various mainframes, minicomputers and microcomputers and all the different operating systems running on all of them.
Since you said "maybe even 90s" then I would remind you that's when Python, Perl, Java, Ruby, and C# all came into being.
From my perspective things have slowed down dramatically over the past 10-15 years. We only have 4 major OSs, 2 microprocessor architectures and there haven't been that many new languages: Go, Rust, Julia, Scala, Kotlin, and Clojure (hmm, maybe there have been a few new languages!) You could argue there's another paradigm shift afoot, functional programming, but it's been around since the 80's (!) and hasn't had widespread adoption.
Finally, it's far easier to learn today than it was back then pre-widespread internet. You used to have to read periodicals and buy books. There weren't videos, tutorials, and the plethora of training options there are today. Add to it that all the tools you need to get started are free and you're all set!
Bottom line - I'd say it's easier than ever to keep up with new developments. The field is moving slower and there's more resources available to keep up with the changes.
I started my career in 1985. I've never been a mainframe programmer, but I know back in the day they were using Cobol (still do!), RPG, PL/1, and JCL.
On the minicomputer side they were using Fortran, Lisp and C.
Microcomputers also adopted C but also added Pascal, Modula-2/3, and of course, Basic.
In the late 70's and even early 80's they were still working on the paradigm shift to structured programming. That's table stakes today but yes, there was a time when structured programming was a paradigm shift. Structured programming was all the buzz.
And then came those weirdos from Xerox PARC with Smalltalk and talking about "object-oriented programming." Great. Another paradigm shift. Bjarne Stroustrup then had to go and post incrementally improve C to add object-oriented programming to give us C++.
So far we've only made it to 1986 and we haven't talked about platforms! The various mainframes, minicomputers and microcomputers and all the different operating systems running on all of them.
Since you said "maybe even 90s" then I would remind you that's when Python, Perl, Java, Ruby, and C# all came into being.
From my perspective things have slowed down dramatically over the past 10-15 years. We only have 4 major OSs, 2 microprocessor architectures and there haven't been that many new languages: Go, Rust, Julia, Scala, Kotlin, and Clojure (hmm, maybe there have been a few new languages!) You could argue there's another paradigm shift afoot, functional programming, but it's been around since the 80's (!) and hasn't had widespread adoption.
Finally, it's far easier to learn today than it was back then pre-widespread internet. You used to have to read periodicals and buy books. There weren't videos, tutorials, and the plethora of training options there are today. Add to it that all the tools you need to get started are free and you're all set!
Bottom line - I'd say it's easier than ever to keep up with new developments. The field is moving slower and there's more resources available to keep up with the changes.
I'm just happy we've all settled on a single endian-ness :)
> I mean, how many different programming language were actually used outside of niche applications in the 80s, maybe even 90s? More than a couple, for sure, but if you look at popular languages right now, there's a really long (and not overly thin) tail.
First, I think there were a lot of languages then, too. It's just that you haven't heard of them. SNOBOL? JOVIAL? There were 1700 known languages in 1965 (quote at the top of https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf). In 1990, say, there was Lisp, FORTRAN, COBOL, BASIC, PL/I, APL, probably still some ALGOL. Then there was the Unix-flavored stuff: C, PERL, awk, sed. There was Pascal, Simula, and Smalltalk.
Today I think the picture is similar, except for one thing: web frameworks. If you exclude web frameworks, there aren't that many languages in general use today. C, C++, C#, Java, go, python, Swift. Maybe Clojure, Kotlin, or Scala, depending on how you define "general use".
I think that a huge amount of the churn is in web languages and web frameworks. Outside of that, languages aren't moving that fast at all.
First, I think there were a lot of languages then, too. It's just that you haven't heard of them. SNOBOL? JOVIAL? There were 1700 known languages in 1965 (quote at the top of https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf). In 1990, say, there was Lisp, FORTRAN, COBOL, BASIC, PL/I, APL, probably still some ALGOL. Then there was the Unix-flavored stuff: C, PERL, awk, sed. There was Pascal, Simula, and Smalltalk.
Today I think the picture is similar, except for one thing: web frameworks. If you exclude web frameworks, there aren't that many languages in general use today. C, C++, C#, Java, go, python, Swift. Maybe Clojure, Kotlin, or Scala, depending on how you define "general use".
I think that a huge amount of the churn is in web languages and web frameworks. Outside of that, languages aren't moving that fast at all.
[deleted]
>> But there are also a lot of people who thought that if they learned one environment they'd have a job forever
Well that's how it worked out for me. I learned Java in the 90's and have used it at every job since for a quarter century. It's changed some, but it hasn't changed that much. It's not going anywhere. I learned other technologies when I had the chance but it hasn't really mattered, all that was wasted effort.
I guess it matters more for front-end development, but over the years that has shifted into being done by a separate team most places I've worked. I don't touch front-end code where I work now.
Well that's how it worked out for me. I learned Java in the 90's and have used it at every job since for a quarter century. It's changed some, but it hasn't changed that much. It's not going anywhere. I learned other technologies when I had the chance but it hasn't really mattered, all that was wasted effort.
I guess it matters more for front-end development, but over the years that has shifted into being done by a separate team most places I've worked. I don't touch front-end code where I work now.
I agree. I am also over 50 and have zero problems learning new tech. It actually gets easier the more I learn because underneath the surface most “new” tech is just a rebranding of old tech invented 20 years ago. But I have worked with older and younger software developers who simply refused to learn anything new. So I don’t think it is an age issue. It is a personality issue.
It's harder if your current job sucks and doesn't embrace new tech. That's 8-9 hours a day wasted you could be learning new tech. So then you get home, cook dinner, etc. and try to squeeze in something new?
It's not impossible but I think if you aren't in a job (or working for yourself) that you're learning something new every day then you're falling behind.
I also don't fault the guy. Nothing in human history has ever changed this fast.
It's not impossible but I think if you aren't in a job (or working for yourself) that you're learning something new every day then you're falling behind.
I also don't fault the guy. Nothing in human history has ever changed this fast.
I really would like to hear perspectives of old people like your self about various recent trends and how they are a repetition of old innovations. For example example about containers (or vms?) as meta processes and kubernetes as some type of meta-os. Or computer languages which are just interfaces to the same base algorithms. Or anything really. I also have the vague feeling that there are repeating patters, but I don’t have a deep historical perspective to make this feeling more concrete. Does anyone have a blog or something?
I don't know about repeating patterns, what I see with containers is sort of novel but has its roots in competition between time sharing systems and transaction processing systems.
I've never used Multics but it seems that the guys who wrote unix and VMS and other mini computer OS were time sharers. One box, lots of users, how do we stop users from stomping on one another. The final paradigm was that your programs can pretend they own the whole machine and the operating system handles keeping everybody safe from one another.
This is fine if everybody runs single programs but eventually hits the wall when you need competing environments.
Personal computers and networking fixed that, but now I want to share my running program, I need a server again. A big, shared machine only my environment clashes with yours, so containers are born. They are networked personal computers in conception.
The other pattern is transaction programming. IBM mainframes didn't really do time sharing, you write up your job and schedule it. Some jobs are then triggered by conditions or events. Its more like a domino stack than processes trying to pretend they are the only thing running. AWS lambda functions are the modern equivalent but without the safety of proper queues that something like CICS provided. They will get there.
For some problems, you need interactivity. For others, you really want transaction processing. I think transaction processing is really underutilised in modern systems as we all scramble just to make stuff work and the time sharing and personal computer modes of thinking dominate the problem space.
I've never used Multics but it seems that the guys who wrote unix and VMS and other mini computer OS were time sharers. One box, lots of users, how do we stop users from stomping on one another. The final paradigm was that your programs can pretend they own the whole machine and the operating system handles keeping everybody safe from one another.
This is fine if everybody runs single programs but eventually hits the wall when you need competing environments.
Personal computers and networking fixed that, but now I want to share my running program, I need a server again. A big, shared machine only my environment clashes with yours, so containers are born. They are networked personal computers in conception.
The other pattern is transaction programming. IBM mainframes didn't really do time sharing, you write up your job and schedule it. Some jobs are then triggered by conditions or events. Its more like a domino stack than processes trying to pretend they are the only thing running. AWS lambda functions are the modern equivalent but without the safety of proper queues that something like CICS provided. They will get there.
For some problems, you need interactivity. For others, you really want transaction processing. I think transaction processing is really underutilised in modern systems as we all scramble just to make stuff work and the time sharing and personal computer modes of thinking dominate the problem space.
Human knowledge is evolving incredibly quickly, and has since before computers were even invented.
The first computer I played with was the (then new) Commodore PET, with 4KB RAM. My elementary school had one, and access to it was like some sort of special privilege.
There’s a certain tendency people tend to have, which is to believe that “things were better in the old days,” or “they don’t make ‘em like they used to.” Or “there are no new ideas.”
I dunno, for me going back to the pre-smartphone, pre-Google, pre-Internet world… pass.
Naturally, there are a wealth of core ideas, algorithms, patterns which have stood the test of time and even evolved and flourished. But our understanding of even basic ideas has significantly changed over time.
Personally, I’ve generally elected to not get too caught up with fads, and to focus on understanding fundamental ideas, algorithms, mathematics; how things fit together into robust, efficient, flexible systems.
The first computer I played with was the (then new) Commodore PET, with 4KB RAM. My elementary school had one, and access to it was like some sort of special privilege.
There’s a certain tendency people tend to have, which is to believe that “things were better in the old days,” or “they don’t make ‘em like they used to.” Or “there are no new ideas.”
I dunno, for me going back to the pre-smartphone, pre-Google, pre-Internet world… pass.
Naturally, there are a wealth of core ideas, algorithms, patterns which have stood the test of time and even evolved and flourished. But our understanding of even basic ideas has significantly changed over time.
Personally, I’ve generally elected to not get too caught up with fads, and to focus on understanding fundamental ideas, algorithms, mathematics; how things fit together into robust, efficient, flexible systems.
This is my nightmare. My current delusion that keeps me stable - is that since I know the fundamentals straight, like what makes a processor better, what makes a language better and what makes a framework/library better I should be able float and proactively sense incoming waves. But only time can tell what happens to current generation software engineers who get old.
Right.
There's also an amazing influx of new competition from countries where wages are a lot cheaper than in the West.
Give it 10, 20 more years, and programmers might be the new factory workers: easy to replace, and hence not a valuable asset any more.
You might think "But hey! Factory work is mostly manual labor that almost anyone can do. Programming needs intellectual acumen.", and watch kids with AI-powered tools eat your lunch.
There's also an amazing influx of new competition from countries where wages are a lot cheaper than in the West.
Give it 10, 20 more years, and programmers might be the new factory workers: easy to replace, and hence not a valuable asset any more.
You might think "But hey! Factory work is mostly manual labor that almost anyone can do. Programming needs intellectual acumen.", and watch kids with AI-powered tools eat your lunch.
This is one of the few big disadvantages of being from an English-speaking country. Here in Germany, being fluent in German is still a major plus in job interviews that the vast majority of global talent doesn't have. It gets less relevant as business gets ever more international, but for now at least it definetely made it easier to get my career started and progress.
Agreed. It's also a fact often ignored by politics and administration: my local university now offers all CS lectures in English to attract international students. Consequently, there are lots of them, and there's little incentive for them to learn the local language as they can get along in every day life pretty well, given that they stay mostly amongst themselves.
But once they graduate and start looking for jobs in the same area that they've become acquainted with over the course of three years or so, and where by now their center of life really is, they find out the same thing you report about Germany: outside the university circles, you won't get very far with English.
So the majority will go back home again after a while, often times not so much by choice but just because they're forced to.
I imagine this is double tragic for a place like Germany where studying is (almost) free: you give international students a high-quality, free education which is then promptly taken out of the country again.
But once they graduate and start looking for jobs in the same area that they've become acquainted with over the course of three years or so, and where by now their center of life really is, they find out the same thing you report about Germany: outside the university circles, you won't get very far with English.
So the majority will go back home again after a while, often times not so much by choice but just because they're forced to.
I imagine this is double tragic for a place like Germany where studying is (almost) free: you give international students a high-quality, free education which is then promptly taken out of the country again.
That's very true, and now that you mention it, my Bachelor's degree had 30 points reserved for "General job market skills", I took some courses in project management and Chinese, but I don't think there were any for learning German as a foreign language. That's actually a surprisingly big oversight, and I might ask around in my party about plans to account for that.
On the last point I'd say though that they are of course welcome to stay, but also welcome to take their skills back home. I made a lot of friends from developing nations, or wartorn places like Syria, that will hopefully make a real difference there. Giving free education to talented people is probably one of the most effective ways to help the world become a better place.
On the last point I'd say though that they are of course welcome to stay, but also welcome to take their skills back home. I made a lot of friends from developing nations, or wartorn places like Syria, that will hopefully make a real difference there. Giving free education to talented people is probably one of the most effective ways to help the world become a better place.
You should be more worried about AI in the future. And that will affect the young programmers just as much as the old ones.
And just to clarify, this concern is not about the current programming-related AI technologies, which have nothing like human abilities. It's about anticipating advances that have not yet occurred.
And just to clarify, this concern is not about the current programming-related AI technologies, which have nothing like human abilities. It's about anticipating advances that have not yet occurred.
> Every time I learned a new PC programming language, the industry changed.
That doesn't sound about right. Maybe he just chose the wrong ones? I agree that the churn rate for methodologies and architectures is high in the industry, but not so much for programming languages. Java is 25+ year old. C# is close. Python is not going anywhere soon. Even Cobol is still somewhat relevant today.
That doesn't sound about right. Maybe he just chose the wrong ones? I agree that the churn rate for methodologies and architectures is high in the industry, but not so much for programming languages. Java is 25+ year old. C# is close. Python is not going anywhere soon. Even Cobol is still somewhat relevant today.
Yea, I think it's probably an exaggeration for dramatic purposes.
I've been around the block for a while, too, and I don't think I've ever learned a language of which I thought it might be useful career-wise which then later fell of the surface of the Earth completely.
I mean, how long does it take to learn a new language, once you're experienced with some others? Hardly as long as new trends arise and die again.
I've been around the block for a while, too, and I don't think I've ever learned a language of which I thought it might be useful career-wise which then later fell of the surface of the Earth completely.
I mean, how long does it take to learn a new language, once you're experienced with some others? Hardly as long as new trends arise and die again.
If you ever made the switch to C# or Java, there is plenty of work available in those and the work has been stable for a long time.
"They never came up with any prospects and two months later, they contacted me to see if I found a job yet. I told them that I thought that was supposed to be their job."
Not taking ownership of your own job search is a red flag.
Author also failed to act on early warning signs and thought that he could make himself too valuable to be let go.
So it seems that it's less about age and more about mindset.
Not taking ownership of your own job search is a red flag.
Author also failed to act on early warning signs and thought that he could make himself too valuable to be let go.
So it seems that it's less about age and more about mindset.
Not taking ownership of your own job search is a red flag.
Yes, but the author clearly has taken active steps to find a new job himself. I mean, the fact that he got in touch with a company to help him search is already evidence of that, but as he later writes, he did find some part-time jobs at least by his own doing.
I can sympathize with his reaction: what's the point of hiring a company to help you find a job when all they do is call you two months later to ask whether they're still needed?
Of course, we only know his side of the story...
Yes, but the author clearly has taken active steps to find a new job himself. I mean, the fact that he got in touch with a company to help him search is already evidence of that, but as he later writes, he did find some part-time jobs at least by his own doing.
I can sympathize with his reaction: what's the point of hiring a company to help you find a job when all they do is call you two months later to ask whether they're still needed?
Of course, we only know his side of the story...
Looking through his various articles and profiles; I don't see any relevant language from the last 10+ years (Java, Python, JavaScript). He seems to have scratched C, C++ and C#, all of which are still in use, but he didn't really get into them? His history of learning "new tech" seems extremely modest. It seems I've had significant exposure to more languages and architectures in my University program than he had in his 30 year long career. And from the year of experience I've had, I can also tell that switching between languages and APIs is easy. So, maybe age-ism is a thing, but I'd also argue a lot of age-ism can be reduced to "I never even tried keeping up and hyper-specialized myself into a dying corner even when the signs became clear I'm becoming outdated, so why doesn't anyone hire me?"
It seems I've had significant exposure to more languages and architectures in my University program than he had in his 30 year long career.
That wouldn't surprise me. Larger companies are often well advised to keep their production languages to a minimum. I mean, even Google when they first started out (straight out of grad school) wisely restricted the number of supported languages.
If you stay with the same company for a long time, I can easily imagine that you don't get a lot of exposure to new trends. I mean, C has been around for a while now and depending on the field of application can still be the go-to language.
That wouldn't surprise me. Larger companies are often well advised to keep their production languages to a minimum. I mean, even Google when they first started out (straight out of grad school) wisely restricted the number of supported languages.
If you stay with the same company for a long time, I can easily imagine that you don't get a lot of exposure to new trends. I mean, C has been around for a while now and depending on the field of application can still be the go-to language.
> So, maybe age-ism is a thing, but I'd also argue a lot of age-ism can be reduced to "I never even tried keeping up and hyper-specialized myself into a dying corner even when the signs became clear I'm becoming outdated, so why doesn't anyone hire me?"
My experience has been exactly this. I've read many such complaints in the last 20 years of working, and in every single case the author has pigeonholed themselves into a long obsolete corner of the industry. There is a difference between 30 years of experience and 5 years repeated 6 times.
It is important to get onto the right team to have a long lived tech career. Your business domain should be big enough so you organically have to move with the rest of the industry. By 20+ years, you should be in a senior enough position to help lead the change.
I've never met a tech guru who was up to date and didn't retire or move on to other things on his/her own terms.
My experience has been exactly this. I've read many such complaints in the last 20 years of working, and in every single case the author has pigeonholed themselves into a long obsolete corner of the industry. There is a difference between 30 years of experience and 5 years repeated 6 times.
It is important to get onto the right team to have a long lived tech career. Your business domain should be big enough so you organically have to move with the rest of the industry. By 20+ years, you should be in a senior enough position to help lead the change.
I've never met a tech guru who was up to date and didn't retire or move on to other things on his/her own terms.
To a certain extent, I'm surprised he's having a tough time if he's a COBOL and SQL programmer. COBOL and SQL consultants bank decent money.
I suspect there is a geographic mismatch. COBOL programmers probably can't be remote-only.
I suspect there is a geographic mismatch. COBOL programmers probably can't be remote-only.
Not to mention, C/C++/C# are not things you can just scratch at, you need to dive in and make it your home, otherwise no one will take you seriously. C/C++/C# dabblers are dime a dozen, but if you crack the top 10% suddenly you're valuable.
Python/JVM/Ruby are the opposite: It's more about a diverse skillset, because most of the time you'll have to use Java AND Python, or Python AND Ruby.
Python/JVM/Ruby are the opposite: It's more about a diverse skillset, because most of the time you'll have to use Java AND Python, or Python AND Ruby.
Agree. Don’t just learn random tech. Learn tech that is actually needed by potential employers.
Not to be mean, but he has worked in the US for 30 years and does not have a 401(k)? He says he can not live on social security alone, so he has not saved a dime? I could understand it from a manual laborer, but from someone in a profession where research skills are critical?
Not mean just but incredibly ignorant we had two devastating recession that hollowed many 401ks. Mine were. Oh you could understand from “a manual laborer” how very 1890s of you. You know whats nice Andrew Mellon given the frequency and severity of the recession you to might get some education in this.
I'm much younger than the author, and have been ravaged by all the same devastating recessions, but have still managed to save quite a bit without really having to sacrifice. At the least, in 20 years when I get to be retirement age, I do expect to be able to retire - I agree with OP, he must have been saving next to nothing.
The recessions only hollowed out 401ks if you liquidated at the bottom. If you held, the later gains made up for the losses and a lot more.
As the saying goes - time in market beats timing the market.
I have a friend with a wealthy father who has never bought even a single bond share. He has stayed invested in equities his entire career and into retirement. He was already retired in 2008 - and the drop was a mere hiccup for him. He didn't panic-sell and just continued making his required minimum distributions like normal.
I have a friend with a wealthy father who has never bought even a single bond share. He has stayed invested in equities his entire career and into retirement. He was already retired in 2008 - and the drop was a mere hiccup for him. He didn't panic-sell and just continued making his required minimum distributions like normal.
A lot of people had to in order to keep their homes, cars, kids in college, etc.
I think that greatly depends on what you invested in. E.g. the stock price of Citi bank hasn't recovered to this day.
My (sort of) counterpoint:
I was at a conference yesterday for IoT in the energy industry, and my main two observations were
* #1 complaint from industry was the skills gap in the current (aging out) workforce. (Of course, as automation has decimated that workforce, there's major reluctance to assist in your own potential demise ...)
* the main pitch from vendors was young people with those skills only want to work in tech / consulting / startups.
So definitely a competitive advantage is your ability to retrain your experienced staff, and definitely a personal moat is your ability to brand yourself as an old dog who is happy to learn new tricks.
I was at a conference yesterday for IoT in the energy industry, and my main two observations were
* #1 complaint from industry was the skills gap in the current (aging out) workforce. (Of course, as automation has decimated that workforce, there's major reluctance to assist in your own potential demise ...)
* the main pitch from vendors was young people with those skills only want to work in tech / consulting / startups.
So definitely a competitive advantage is your ability to retrain your experienced staff, and definitely a personal moat is your ability to brand yourself as an old dog who is happy to learn new tricks.
I'm 37, and I feel like I'm sorta on the cusp of being considered "old" for a lot of positions. I entered the field in ~2007, and I've been keeping an eye on the "ageism" that's always been talked about. I think it's real, but not insurmountable. I may catch some flack for this, but it honestly seems like being a white male in the US has about the same negative impact on my employer choices at this point - it's not a _negative_, but with all else being equal I will be passed over for a position if I'm in the running with someone who identifies as a woman or a minority.
That aside, a couple of things about your comment really struck me:
> Of course, as automation has decimated that workforce, there's major reluctance to assist in your own potential demise ...
I love automating myself out of a job, and that's been my primary goal everywhere I've ever worked. It was moderately successful at the "Fortune 100 Big Co." where I started out, but my career progression there was much slower than I'd hoped. I made the move to startups and fell in love. Yeah, it's less stable, but the compensation is generally better. Keep a few months' income in savings and you can ride out the instability.
There is a sweet spot where I like to join a company. Ideally they've built a product that works, they have a proven sales and marketing group that has actually made enough sales to prove that there are customers out there for it, they have funding available to grow the business faster than would be possible via bootstrapping, and finally, they're beginning the transition from a small engineering team of early employees to a much larger group composed of multiple teams.
I'm in that situation right now, and I'm loving it. Everything I do is intended to be short- to medium-term, and I make a conscious decision to put an end date on every project I work on and pass it off to another group within the organization. This is very much "automatic myself out of a job", as at the end of each project I'm somewhat adrift and no one is depending on me for anything more than occasional support adn guidance.
I also build relationships with leadership and the early employees by setting up meetings in the beginning and making explicit that I want to understand and buy in to the existing company culture so I can consciously promote and foster it as the group grows.
In my experience, this approach has worked either very well or very poorly, depending on the company and its culture. I'm happy where I am today, and if all goes according to plan will have the ability to make the decision in the next 2-3 years how I want to approach the future: specialize as an IC, make the move to engineering leadership, or exit the industry and take one of my side hustles full time.
> [...] young people with those skills only want to work in tech / consulting / startups.
As a group, I'd guess more young people want to work in this kind of environment, sure. A larger proportion of older engineers have a lower risk tolerance and/or don't want to skill up quickly and on a regular basis.
I noticed early in my career though that the older engineers who do have those skills and want to work at startups are worth their weight in gold. They're (obviously) just as capable as their younger peers but have the benefit of wealth of personal experience in similar situations. They can draw on that to save the company many expensive mistakes. Sometimes you have to make them feel comfortable first, though. A lot of the older engineers I've worked with have been badly burned by speaking up in the past and seem to be hesitant to do so as a result.
That aside, a couple of things about your comment really struck me:
> Of course, as automation has decimated that workforce, there's major reluctance to assist in your own potential demise ...
I love automating myself out of a job, and that's been my primary goal everywhere I've ever worked. It was moderately successful at the "Fortune 100 Big Co." where I started out, but my career progression there was much slower than I'd hoped. I made the move to startups and fell in love. Yeah, it's less stable, but the compensation is generally better. Keep a few months' income in savings and you can ride out the instability.
There is a sweet spot where I like to join a company. Ideally they've built a product that works, they have a proven sales and marketing group that has actually made enough sales to prove that there are customers out there for it, they have funding available to grow the business faster than would be possible via bootstrapping, and finally, they're beginning the transition from a small engineering team of early employees to a much larger group composed of multiple teams.
I'm in that situation right now, and I'm loving it. Everything I do is intended to be short- to medium-term, and I make a conscious decision to put an end date on every project I work on and pass it off to another group within the organization. This is very much "automatic myself out of a job", as at the end of each project I'm somewhat adrift and no one is depending on me for anything more than occasional support adn guidance.
I also build relationships with leadership and the early employees by setting up meetings in the beginning and making explicit that I want to understand and buy in to the existing company culture so I can consciously promote and foster it as the group grows.
In my experience, this approach has worked either very well or very poorly, depending on the company and its culture. I'm happy where I am today, and if all goes according to plan will have the ability to make the decision in the next 2-3 years how I want to approach the future: specialize as an IC, make the move to engineering leadership, or exit the industry and take one of my side hustles full time.
> [...] young people with those skills only want to work in tech / consulting / startups.
As a group, I'd guess more young people want to work in this kind of environment, sure. A larger proportion of older engineers have a lower risk tolerance and/or don't want to skill up quickly and on a regular basis.
I noticed early in my career though that the older engineers who do have those skills and want to work at startups are worth their weight in gold. They're (obviously) just as capable as their younger peers but have the benefit of wealth of personal experience in similar situations. They can draw on that to save the company many expensive mistakes. Sometimes you have to make them feel comfortable first, though. A lot of the older engineers I've worked with have been badly burned by speaking up in the past and seem to be hesitant to do so as a result.
I know we talk a lot about ageism in this industry, but does this not happen in other industries? I genuinely don't know. I just don't think this angle has been explored.
How many associates at top law or accountancy firms are over 40? 50? From my crude linkedin survey, not very many. It seems that in these environments you either progress up, or move down the tiers until you can progress.
I think it's fair to compare programming roles to these 'entry' roles in other professions, with staff engineer and engineering management roles more analogous to 'partner'.
I'm not trying to discuss the merits of older programmers - I'm just unsure that the ageism is more of (or only) a problem in tech narrative is that strong.
How many associates at top law or accountancy firms are over 40? 50? From my crude linkedin survey, not very many. It seems that in these environments you either progress up, or move down the tiers until you can progress.
I think it's fair to compare programming roles to these 'entry' roles in other professions, with staff engineer and engineering management roles more analogous to 'partner'.
I'm not trying to discuss the merits of older programmers - I'm just unsure that the ageism is more of (or only) a problem in tech narrative is that strong.
> I know we talk a lot about ageism in this industry, but does this not happen in other industries? I genuinely don't know. I just don't think this angle has been explored.
It can happen, but it's much less common. Right or wrong, people have different expectations of different fields. I you ask someone to imagine an outstanding lawyer or doctor, they probably envision someone in late middle age, maybe with some grey around the temples. If your doctor walks in the room and looks about 25, you're probably not going to be thrilled. Now, if you ask those same people to image an outstanding programmer, they probably envision a young person in the twenties.
It can happen, but it's much less common. Right or wrong, people have different expectations of different fields. I you ask someone to imagine an outstanding lawyer or doctor, they probably envision someone in late middle age, maybe with some grey around the temples. If your doctor walks in the room and looks about 25, you're probably not going to be thrilled. Now, if you ask those same people to image an outstanding programmer, they probably envision a young person in the twenties.
I'm of the same age cohort as the author. I was thoroughly enjoying coding until my early 40s when I found myself wasting an entire day now and then debugging some obscure point in Java but with slow-to-no progress. This burned out my motivation in a hurry and I could see the ageism writing on the wall so I did a sideways move into tech writing. Surprisingly, a lot of tech writers have not themselves done tech, so hey presto a competitive advantage. If you can use your engineering background to formulate mental models that you can then write clearly (and creatively) about, give it a try, and while you're at it provide feedback to the UX people to get more consistency into the UIs.
Do you do tech writing full time, if so, what kind of companies employ tech writer's?
It was full time, but now retired. You're looking at companies that are large enough and technically oriented enough that they finally hit a stage where they NEED one (or more) dedicated full-time tech writer(s). Writers who can interview technical people, and then translate the material they gather into something digestible by the firm's customers. Typically not consumer-oriented companies - more like B2B - software, electronics, but many other industrial areas too.
It sounds like the author had expected his existing skills to remain relevant for a very long time.
It's certainly a slog keeping up with change in the software industry. It's not just that things keep changing, it's that the wheel keeps being reinvented and that's just tedious.
I remember working with an older programmer when I was about 30 who was retraining as a lawyer. He said he was just bored with having to learn essentially the same things but in different forms over and over again.
It's certainly a slog keeping up with change in the software industry. It's not just that things keep changing, it's that the wheel keeps being reinvented and that's just tedious.
I remember working with an older programmer when I was about 30 who was retraining as a lawyer. He said he was just bored with having to learn essentially the same things but in different forms over and over again.
I definitely think ageism is a real problem, and as someone who's happy to hire older developers it's a shock when they talk about their rejection rate compared to what the 20-somethings and 30-somethings face.
But I can also see where the stereotype comes from. The big problem for older developers is developing a misplaced sense of pride in being unwilling to engage with the inevitable changes in technology. After a few rejections it's easy to start rationalising this as, "they don't want someone experienced who'll be expensive and know they're being taken advantage of" or "they know I'll show up all the idiotic decisions that greenhorn CTO is making" - which worsens the problem, because now as well as the age and skills disadvantage they're coming across as arrogant in interviews. It's hard to talk people out of this spiral because they think the attitude is a good thing, and they're getting that reinforced by all the people in a similar boat saying similar things.
(This is probably too much an aside, but IME older folks are some of the most naive about the salaries they should be asking for and how the company should treat them! For a company, the big benefit of hiring people who're 50+ is the tendency to be too good at the, "I'm just going to do what you ask me to do for whatever I'm paid without challenging anything" aspect. Recent graduates these days don't put up with the nonsense their forebears did.)
One of my favourite teams to work with had two 50+ guys in it. One who had the most incredible enthusiasm for new technology, and of course with 30 odd years of picking up a new tech every few months was incredible at it. You'd see him study something over a weekend and come back going, "so this is really a functional language at core, and I've worked out the idiomatic way to build an API in it is using this". The other built a lot of the testing code and did a fantastic job of playing the age-worn cynic in a way that made the younger team members laugh while embedding the point about defensive coding and building for testability. But there have also been plenty of older devs more of the, "J2SE was fine for me and it should be fine for you; all those new language features only make your code unreadable, you'll understand once you've been doing this job as long as I have" school which drives the stereotype.
The sad thing is I reckon you can tell which way a developer is going to go as early as 5-7 years into their career, because by that point things will have moved on from what they first learnt and you can see whether they're engaging with it or refusing to change.
Of course, for the author of the article there's the additional problem that any typical HR department will be drawing a big red flag in the "years until retirement" column, and in a lot of companies they will have veto power too early on in the process for a hiring manager to interview and find out what the actual story is. As others have mentioned it's difficult to overcome this, but you need to take charge and start looking for jobs on platforms where you'll be talking directly with team leads and engineering managers rather than going through the classic agency > HR > interview process route, which is basically designed for risk elimination through standardisation.
tl;dr: if you find yourself getting old in spite of your youthful belief that would never happen, stay enthusiastic and don't get bitter. I guess that covers more of life than just software development.
But I can also see where the stereotype comes from. The big problem for older developers is developing a misplaced sense of pride in being unwilling to engage with the inevitable changes in technology. After a few rejections it's easy to start rationalising this as, "they don't want someone experienced who'll be expensive and know they're being taken advantage of" or "they know I'll show up all the idiotic decisions that greenhorn CTO is making" - which worsens the problem, because now as well as the age and skills disadvantage they're coming across as arrogant in interviews. It's hard to talk people out of this spiral because they think the attitude is a good thing, and they're getting that reinforced by all the people in a similar boat saying similar things.
(This is probably too much an aside, but IME older folks are some of the most naive about the salaries they should be asking for and how the company should treat them! For a company, the big benefit of hiring people who're 50+ is the tendency to be too good at the, "I'm just going to do what you ask me to do for whatever I'm paid without challenging anything" aspect. Recent graduates these days don't put up with the nonsense their forebears did.)
One of my favourite teams to work with had two 50+ guys in it. One who had the most incredible enthusiasm for new technology, and of course with 30 odd years of picking up a new tech every few months was incredible at it. You'd see him study something over a weekend and come back going, "so this is really a functional language at core, and I've worked out the idiomatic way to build an API in it is using this". The other built a lot of the testing code and did a fantastic job of playing the age-worn cynic in a way that made the younger team members laugh while embedding the point about defensive coding and building for testability. But there have also been plenty of older devs more of the, "J2SE was fine for me and it should be fine for you; all those new language features only make your code unreadable, you'll understand once you've been doing this job as long as I have" school which drives the stereotype.
The sad thing is I reckon you can tell which way a developer is going to go as early as 5-7 years into their career, because by that point things will have moved on from what they first learnt and you can see whether they're engaging with it or refusing to change.
Of course, for the author of the article there's the additional problem that any typical HR department will be drawing a big red flag in the "years until retirement" column, and in a lot of companies they will have veto power too early on in the process for a hiring manager to interview and find out what the actual story is. As others have mentioned it's difficult to overcome this, but you need to take charge and start looking for jobs on platforms where you'll be talking directly with team leads and engineering managers rather than going through the classic agency > HR > interview process route, which is basically designed for risk elimination through standardisation.
tl;dr: if you find yourself getting old in spite of your youthful belief that would never happen, stay enthusiastic and don't get bitter. I guess that covers more of life than just software development.
Remember that in the "old days", computers were very expensive and the selection of operating system and languages was almost always made by business executives based on money and trade press. Workers would typically have NO say in what language or systems they would use during their "day job" unless they changed jobs...and in those days, if one changed jobs too often, they were considered a risk. As if that didn't limit one's ability to learn new languages, employers would also only accept workers who were not experienced in their desired language/system during a very limited window, generally just after mass adoption, for example, during FORTRAN to C or Ada, TurboPascal to Delphi to Visual Basic, C to C++, etc.) so, for example, an ace FORTRAN programmer wouldn't get the chance to jump anywhere if they waited until, say 1990, to do so. By the same token, as people age, with more mouths to feed and more bills to pay, they become risk averse and many would avoid such language transitions altogether and in doing so, would render themselves obsolete as their unchosen language died. Still others would bet the farm and change jobs frequently, but wind up with dead-ends (Ada, FoxPro, TurboPascal, etc.) In the world of today, one can buy a computer for $40/mo that runs every language ever written (one way or another), but that just wasn't the case back in the day.
When an old Boomer says they did all the right things by learning new languages, they mean they took the risks they were (quite unfairly) expected to take (just to try and preserve their occupation), but in some way, they couldn't always keep up with industry changes. (Combine This with H1B-fraud and C-suite wage theft like https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_L... and you have a retirement disaster decades in the making.)
To the 65 year old, you're not that old for a non-physical occupation (look at Woz) and when I started in this business 40+ years ago (tho still not yet old enough to qualify for the senior menu at Dennys), it was common to find guys your age around teaching us younglings --I learned a lot from them, miss them and I have sincere pity for the post-Y2K generations that lost that after the elders were forever purged (first to be RIF'ed and all at once as the dot-com bubble crashed demand for tech from 2001-2006). From following some of the elders through all of that, I know you're going to want to avoid head hunters, focus on marketing yourself to small companies and approach future work assignments as a LOYAL AND DEPENDABLE partner not just a body showing up to a "job". Pay attention to your shoes. Not fair that you have to hustle more as you get older, but nobody ever promised you fairness. (Also, I strongly recommend against investing in another line of business at 65, as I've seen that not work out a lot.) Lastly, don't listen to the critical voices on here and similar sites!
[ https://youtu.be/fLVN05Jl6wA ]
When an old Boomer says they did all the right things by learning new languages, they mean they took the risks they were (quite unfairly) expected to take (just to try and preserve their occupation), but in some way, they couldn't always keep up with industry changes. (Combine This with H1B-fraud and C-suite wage theft like https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_L... and you have a retirement disaster decades in the making.)
To the 65 year old, you're not that old for a non-physical occupation (look at Woz) and when I started in this business 40+ years ago (tho still not yet old enough to qualify for the senior menu at Dennys), it was common to find guys your age around teaching us younglings --I learned a lot from them, miss them and I have sincere pity for the post-Y2K generations that lost that after the elders were forever purged (first to be RIF'ed and all at once as the dot-com bubble crashed demand for tech from 2001-2006). From following some of the elders through all of that, I know you're going to want to avoid head hunters, focus on marketing yourself to small companies and approach future work assignments as a LOYAL AND DEPENDABLE partner not just a body showing up to a "job". Pay attention to your shoes. Not fair that you have to hustle more as you get older, but nobody ever promised you fairness. (Also, I strongly recommend against investing in another line of business at 65, as I've seen that not work out a lot.) Lastly, don't listen to the critical voices on here and similar sites!
[ https://youtu.be/fLVN05Jl6wA ]
A word that is always important to ALL OF US: Diversify.
Don't put all of your eggs in one basket. None of us can expect to stay in the same field that we start off in for the whole of our working life. In my own case, I started in Pharmacy, but developed expertise in aviation, computing and rental properties.
While the aviation and computing didn't become the main thrusts of my work, they became important sidelines. When it comes to rental properties, my wife and I had little savings due to our two divorces, and we needed to ensure that there would be some form of income after we retired from our 'main jobs'. So we took a few risks to build up a stable of rental properties while we still had our main-job incomes.
Today, retired, our income comes from rental properties and some of the property-management is made easier by my computing expertise.
The aviation? Well, after I became a commercial-pilot, the aviation industry went through a down-turn for several years and it never became the enjoyable cash-cow that I hoped it would. All the same, it was a fun time that I would have been disappointed to have missed.
Another thing to always keep in mind: For instance, when they moved their offices, I came in on my own time to help physically move computers and helped to hook up all the cables.
If you discount your own worth by working without pay, why should the employer consider you to be worth more?
Don't put all of your eggs in one basket. None of us can expect to stay in the same field that we start off in for the whole of our working life. In my own case, I started in Pharmacy, but developed expertise in aviation, computing and rental properties.
While the aviation and computing didn't become the main thrusts of my work, they became important sidelines. When it comes to rental properties, my wife and I had little savings due to our two divorces, and we needed to ensure that there would be some form of income after we retired from our 'main jobs'. So we took a few risks to build up a stable of rental properties while we still had our main-job incomes.
Today, retired, our income comes from rental properties and some of the property-management is made easier by my computing expertise.
The aviation? Well, after I became a commercial-pilot, the aviation industry went through a down-turn for several years and it never became the enjoyable cash-cow that I hoped it would. All the same, it was a fun time that I would have been disappointed to have missed.
Another thing to always keep in mind: For instance, when they moved their offices, I came in on my own time to help physically move computers and helped to hook up all the cables.
If you discount your own worth by working without pay, why should the employer consider you to be worth more?
Imagine being a Cobol or dBase III developer. You recognize that some new technology (say AWS Aurora) is in demand.
So you study a whole bunch during your off time. You do tons of courses, hobby projects, and even take the applicable certifications.
Here's my question: then what? You have textbook knowledge of this new skill, but no actual production experience. What's the best way for these re-skilling workers to make the jump from learning to earning?