4 ms·

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

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.

kleiba 5y ago
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.
- smackeyacky 5y ago
  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.
  - kleiba 5y ago
    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)?
    - smackeyacky 5y ago
      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 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.
redis_mlc 5y ago
> he is uninterested in learning anything new. You failed to mention that the various dbase versions and clones haven't been surpassed yet, decades later. If I needed an internal inventory system, I'd first see if there was something like dbase still available. Also, excusing industry ageism with a single anecdote is the opposite of being logical, especially in a STEM field.
rufus_foreman 5y ago
>> 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.
mbrodersen 5y ago
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.
2OEH8eoCRo0 5y ago
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.
bluepoint 5y ago
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?
- dougabug 5y ago
  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.
- smackeyacky 5y ago
  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.

kleiba 5y ago

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.

smackeyacky 5y ago
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.
- kleiba 5y ago
  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)?
  - smackeyacky 5y ago
    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 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.

redis_mlc 5y ago

> he is uninterested in learning anything new. You failed to mention that the various dbase versions and clones haven't been surpassed yet, decades later. If I needed an internal inventory system, I'd first see if there was something like dbase still available. Also, excusing industry ageism with a single anecdote is the opposite of being logical, especially in a STEM field.

rufus_foreman 5y ago

>> 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.

mbrodersen 5y ago

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.

2OEH8eoCRo0 5y ago

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.

bluepoint 5y ago

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?

dougabug 5y ago
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.
smackeyacky 5y ago
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.