4 ms·

> I also noticed that older programmers tend to not be as up to date in newer technologies or ways of doing things. I've been doing this a long time and it doe

> I also noticed that older programmers tend to not be as up to date in newer technologies or ways of doing things. I've been doing this a long time and it doesn't matter to me. The newer stuff is most of the time just a variation on a theme that I've seen turnover three or four times since i've been doing this. What older coders have that younger ones do not, is experience. This can often halve the workload on some projects. The older I get in this profession, the more results I get out of less and less code. Also, let's not immediately fetishize the newer stuff. It is often a less well implemented retread of older technology. Seems like people have less patience for learning existing systems, so they just re-write some quick and dirty replacement and call it good. Perhaps it might be better if younger programmers learned the old stuff instead of just badly reinventing the wheel every few years.

howard941 8y ago
This. And older engineers have finer bullshit detectors. ISTM ageism is real, and it's all about the money.
unclebucknasty 8y ago
>Perhaps it might be better if younger programmers learned the old stuff instead of just badly reinventing the wheel every few years. That's pure gold. Not to say there haven't been advances--there certainly have been. But, there's also the issue of the shininess of new tech giving it undue cred, while simultaneously translating to an outsized denigration of the tech it purports to replace. Frankly, a lot of these problems have been solved, and solved well. Look at NoSQL as an example. There are certainly use cases for it, but then people went nuts, exclaiming things like "RDBMS must die" and touting no ACID transactions as a feature/benefit. Then, you get the trickle of reports that maybe NoSQL wasn't the best choice for this or that. Finally, fast-forward to 2018 and you have announcements from MongoDB that they now support ACID transactions. Many older coders have seen enough of these cycles, and have adopted a justifiably-cynical posture of "wait for it...".
- 420codebro 8y ago
  No ACID as a feature - lol. "My car? Fuck the airbags, fuck the seatbelts! It is fast though!"
- james_s_tayler 8y ago
  Yup. And when you chime in with "wait for it..." you get the nasty vitriolic comments thrown at you like you're going to rot in the basement of a fortune 10 feeding a legacy system while the $cool_kids enjoy the sunshine on the beach with their new shiny frameworks. Yet "Wait for it" usually turns out to be correct.
hedora 8y ago
I’d add that survivor bias applies both to technologies and developers. Creaky old software tools from the 70’s that are actually still in use have fought off decades of competitors that attempted to improve them.
unimpressive 8y ago
>Perhaps it might be better if younger programmers learned the old stuff instead of just badly reinventing the wheel every few years. I think if you pick a concrete example of this phenomena (say, Java applets vs. WebAssembly) and you ask "so why didn't someone take Java Applets and update them, why do we need WebAssembly?", the answers to why this happens start to become more apparent. It's not so much that Java applets were good and then we decided they were unfashionable, as that Java applets were always kind of ugly and we eventually stopped tolerating them. For examples from before say, 2000, say Turbo Pascal a lot of the answer is because the thing in question was a proprietary product so once the financially backed dev team stopped working on it users were forced to move on to something else. Other times it's because the thing was written for an 80's computer platform that no longer exists outside of emulation and retrocomputing collections. Sometimes it's that the graphical standards the original used were for hardware with very different capabilities and making the thing usefully work on a newer system would almost require a total rewrite anyway. Even beyond all that, there's another problem: Software is fairly hard to do literature review for. If I want to know if a particular research idea has been done before, I can hop on Google Scholar and figure it out with a few hours of carefully constructed search queries. Doing the same thing for software is very difficult, especially because most products for the majority of the fields history were proprietary. As a consequence, we don't have our history available to analyze in any easily accessed form. The Internet Archive has been doing what they can to rectify this situation. (See: https://archive.org/details/BeyondCyberpunkMacintosh https://archive.org/details/BeyondCyberpunkMacintosh) Nonetheless, there are still serious problems in this area. I'm a younger person (23) who shares your frustrations, but I don't think that you can really wag your finger at people when there are real barriers to what you're proposing.
- gerbilly 8y ago
  Well, in my comments I was restricting my examples mostly to server side software running on UNIX. This eliminates much of the proprietary lockin and portability problems you mention. I never was saying people should just keep using Delphi into the 21st century. Also, my comments apply to broad categories of solutions not just software implementations in the narrow sense. For example: I just replaced (had to for perf reasons) a NOSQL solution in one of our applications with MySQL. Ironically, the application would actually scale better with NoSQL in theory, but the choices the developers made along the way (data modelling and API design) made it perform worse on the NoSQL DB than on MySQL. The tactical solution, which fits our needs and the size of our user base, turned out to be to replace a new shiny thing, with an older technology. The benefit gained was more flexibility with queries, which in turn allowed us to speed things up significantly with little effort. The previous team burned a lot of time learning the new NoSQL thing to then not get any benefit from it at all.
scarface74 8y ago
I've been doing this a long time and it doesn't matter to me. And this attitude is why older developers find it harder to get a job (I’m in my mid 40s myself). What older coders have that younger ones do not, is experience. This can often halve the workload on some projects. The older I get in this profession, the more results I get out of less and less code. I keep seeing this as an excuse for older developers who don’t want to keep up the date and stay marketable. Code is code. At some point you have to put lines in editor to make stuff work. Also, let's not immediately fetishize the newer stuff. It is often a less well implemented retread of older technology. Seems like people have less patience for learning existing systems, so they just re-write some quick and dirty replacement and call it good. Perhaps it might be better if younger programmers learned the old stuff instead of just badly reinventing the wheel every few years. The market can stay irrational longer than you can stay solvent.
- gerbilly 8y ago
  Nice reply. I myself do not find it harder to find jobs, and I'm even older than you. My post above didn't mention it, but I also learn new stuff. And some of it is really useful. I don't insist the client use my preferred technologies. I may recommend them, sure, but in the end I'll learn what I have to do get the job done. This whole thread reminds me of a story: A small town barber has been cutting hair for decades, and charging his customers a fair price. One day a national chain opens a salon just across the street and advertises $10 haircuts. A customer asks, "Aren't you worried they'll drive you out of business?" The barber grabs a piece of cardboard, scribbles something on it quickly, and props it up in the window. The sign reads: "We fix $10 haircuts." I think the best business model for an older developer is to fix $10 haircuts. Seek out those kind of jobs that capitalize on your experience. There are so many messes out there that if you can bill yourself as a cleanup guy, you'll never run out of clients.
- walshemj 8y ago
  It's not about churning out so many kloc's of code - its about solving problems.
  - scarface74 8y ago

howard941 8y ago

This. And older engineers have finer bullshit detectors. ISTM ageism is real, and it's all about the money.

unclebucknasty 8y ago

>Perhaps it might be better if younger programmers learned the old stuff instead of just badly reinventing the wheel every few years. That's pure gold. Not to say there haven't been advances--there certainly have been. But, there's also the issue of the shininess of new tech giving it undue cred, while simultaneously translating to an outsized denigration of the tech it purports to replace. Frankly, a lot of these problems have been solved, and solved well. Look at NoSQL as an example. There are certainly use cases for it, but then people went nuts, exclaiming things like "RDBMS must die" and touting no ACID transactions as a feature/benefit. Then, you get the trickle of reports that maybe NoSQL wasn't the best choice for this or that. Finally, fast-forward to 2018 and you have announcements from MongoDB that they now support ACID transactions. Many older coders have seen enough of these cycles, and have adopted a justifiably-cynical posture of "wait for it...".

420codebro 8y ago
No ACID as a feature - lol. "My car? Fuck the airbags, fuck the seatbelts! It is fast though!"
james_s_tayler 8y ago
Yup. And when you chime in with "wait for it..." you get the nasty vitriolic comments thrown at you like you're going to rot in the basement of a fortune 10 feeding a legacy system while the $cool_kids enjoy the sunshine on the beach with their new shiny frameworks. Yet "Wait for it" usually turns out to be correct.

hedora 8y ago

I’d add that survivor bias applies both to technologies and developers. Creaky old software tools from the 70’s that are actually still in use have fought off decades of competitors that attempted to improve them.

unimpressive 8y ago

>Perhaps it might be better if younger programmers learned the old stuff instead of just badly reinventing the wheel every few years. I think if you pick a concrete example of this phenomena (say, Java applets vs. WebAssembly) and you ask "so why didn't someone take Java Applets and update them, why do we need WebAssembly?", the answers to why this happens start to become more apparent. It's not so much that Java applets were good and then we decided they were unfashionable, as that Java applets were always kind of ugly and we eventually stopped tolerating them. For examples from before say, 2000, say Turbo Pascal a lot of the answer is because the thing in question was a proprietary product so once the financially backed dev team stopped working on it users were forced to move on to something else. Other times it's because the thing was written for an 80's computer platform that no longer exists outside of emulation and retrocomputing collections. Sometimes it's that the graphical standards the original used were for hardware with very different capabilities and making the thing usefully work on a newer system would almost require a total rewrite anyway. Even beyond all that, there's another problem: Software is fairly hard to do literature review for. If I want to know if a particular research idea has been done before, I can hop on Google Scholar and figure it out with a few hours of carefully constructed search queries. Doing the same thing for software is very difficult, especially because most products for the majority of the fields history were proprietary. As a consequence, we don't have our history available to analyze in any easily accessed form. The Internet Archive has been doing what they can to rectify this situation. (See: https://archive.org/details/BeyondCyberpunkMacintosh https://archive.org/details/BeyondCyberpunkMacintosh) Nonetheless, there are still serious problems in this area. I'm a younger person (23) who shares your frustrations, but I don't think that you can really wag your finger at people when there are real barriers to what you're proposing.

gerbilly 8y ago
Well, in my comments I was restricting my examples mostly to server side software running on UNIX. This eliminates much of the proprietary lockin and portability problems you mention. I never was saying people should just keep using Delphi into the 21st century. Also, my comments apply to broad categories of solutions not just software implementations in the narrow sense. For example: I just replaced (had to for perf reasons) a NOSQL solution in one of our applications with MySQL. Ironically, the application would actually scale better with NoSQL in theory, but the choices the developers made along the way (data modelling and API design) made it perform worse on the NoSQL DB than on MySQL. The tactical solution, which fits our needs and the size of our user base, turned out to be to replace a new shiny thing, with an older technology. The benefit gained was more flexibility with queries, which in turn allowed us to speed things up significantly with little effort. The previous team burned a lot of time learning the new NoSQL thing to then not get any benefit from it at all.

scarface74 8y ago

I've been doing this a long time and it doesn't matter to me. And this attitude is why older developers find it harder to get a job (I’m in my mid 40s myself). What older coders have that younger ones do not, is experience. This can often halve the workload on some projects. The older I get in this profession, the more results I get out of less and less code. I keep seeing this as an excuse for older developers who don’t want to keep up the date and stay marketable. Code is code. At some point you have to put lines in editor to make stuff work. Also, let's not immediately fetishize the newer stuff. It is often a less well implemented retread of older technology. Seems like people have less patience for learning existing systems, so they just re-write some quick and dirty replacement and call it good. Perhaps it might be better if younger programmers learned the old stuff instead of just badly reinventing the wheel every few years. The market can stay irrational longer than you can stay solvent.

gerbilly 8y ago
Nice reply. I myself do not find it harder to find jobs, and I'm even older than you. My post above didn't mention it, but I also learn new stuff. And some of it is really useful. I don't insist the client use my preferred technologies. I may recommend them, sure, but in the end I'll learn what I have to do get the job done. This whole thread reminds me of a story: A small town barber has been cutting hair for decades, and charging his customers a fair price. One day a national chain opens a salon just across the street and advertises $10 haircuts. A customer asks, "Aren't you worried they'll drive you out of business?" The barber grabs a piece of cardboard, scribbles something on it quickly, and props it up in the window. The sign reads: "We fix $10 haircuts." I think the best business model for an older developer is to fix $10 haircuts. Seek out those kind of jobs that capitalize on your experience. There are so many messes out there that if you can bill yourself as a cleanup guy, you'll never run out of clients.
walshemj 8y ago
It's not about churning out so many kloc's of code - its about solving problems.
- scarface74 8y ago