Knowing the subtlelties of memory management in the 80' didn't help the Ruby coders to create RoR and run Basecamp, or the Python coders to create Django and run the Washington Post.
People jumped at ORM, CSS frameworks and JS wrappers, and won the day because they traded memory and CPU for what the user wanted.
The new generation will do the same. They will figure out how to be super productive with AI, way more than what we are. And our superpower will be useful in specialized cases, but mostly, their impacts will be small compared to the order of magnitude of speed they'll gain by using the new paradigm.
People said interpreted languages were a waste, that you had to learn SQL, that Electron was an abomination.
But the people building stuff always win, not what we think is the right way.
That's why PHP won at some point. JS won at some point.
And something super practical (but that will make us say uhh...) made by AI will win at some point.
That's also why all the open letters and ethics committees will have no impact: the short term advantage given to AI users will be such that they will take everything over by storm.
It's already happening in porn: we just gave millions of teenage boys a shiny new toy, and they are spending days and nights on it. New incredible models come out every day. Some hyper specialized. Last week, I saw a publication of a new model specially trained on only vagina called "bettervulva" and one for boobs called "breastinclass". Somebody spent hundreds of hours on those, collecting the data, annotating it, and training.
I guarantee each niche of the world is doing exactly the same. Not to mention each new model is coded with somebody who has the previous models to help with the new one, code included.
You are sort of ignoring the bias in your own AI extremist prediction.
People who have decided to go all in in learning an interpreted language like Perl or even PHP, had to continuously also learn react, js, ruby,... and gazillions of other languages and frameworks to remain in business over the last two decades.
While people who invested in learning C, Java or SQL have as much healthy opportunities to pursue today with almost the same amount of knowledge that they had accumulated three decades ago. Their life has been much less stressful, pretty much on auto-pilot, while those who were pursuing the latest technology are constantly living on the edge having to continuously relearn entire new framework on average every 3-5 years to remain relevant.
So yes all these glitzy languages have "won" but it wasn't by these "ancient" languages losing.
If I had to bet I would say a decade from now, based on the last 50 years history of computing, I can easily imagine the same amount of jobs for C programmers as we have today but there will be as many Ruby jobs as we have perl jobs today.
Reskilling has its upsides, you are exposed to many more paradigms and communities that do things completely differently which allows for a lot of cross pollination. living life on autopilot isn’t usually a source of great insights.
Reskilling is much more productive and fun when you are doing it for the intellectual journey and insight, rather than because you need to do it to find a job.
Indeed being able to auto-pilot your job allows you an amazing amount of time and freedom to learn new things deeply. See also the detrimental effects of "publish or perish" mindset in academia.
Which pretty much sums up today's work culture. I was just talking about this same exact thing, yesterday.
That's absolutely heartbreaking.
In the old days, we would have a team, that would compete, as a team, against other corporations. Our team would stick together, work together, and, quite often, function as a unit; leveraging each others' strengths, and compensating for each others' weaknesses.
Nowadays, we look at our team members as "the competition." In fact, we may actually be making plans to move to the other team.
But I have written programs in C, that were still in use, 25 years later. I have written programs in PHP, that were still (are still) in use, 15 years later.
There'll always be room for the classics.
That said, I'm quite looking forward to seeing what I can do with the new AI stuff.
I never publish or react to individual velocity as a manager. It's all about what the dev and QA team gets across as a whole to the Done pile each week, and I use a rolling ten week average. I know what each person is doing still but if they spend four hours collaborating on something nobody loses points.
Well my team wins more than most others and we've replaced teams and fixed many failed projects so that helps too. And if the company is dense there's others that aren't and lots that will follow where I go to next.
Everyone is at best a temporary ally, friends and community groups are just atrophying daily as we continue to not invest in people and community and invest in more alienation.
The idea that nobody saw their coworkers as competition for a promotion, or bonus, or face-time with the boss in the past, and that there are no teams that stick together and work together today, is fanciful at best.
These are "Because I can find an exception, your position is invalid." arguments. Not sure I can recall the exact fallacy title, but it's a fairly typical debating tactic.
I disagree that there's a fallacy at play here. The GP (GGP) should support their bold claim that "times have changed" and "people/teams aren't the same as they used to be." If anything, that's an extremely common fallacy and is not to be believed without sufficient evidence.
Actually, that's a fairly typical thing to say to someone that's older, and has lived through those times.
And I am sorry. Things definitely used to be better than they are now, in some ways, and definitely used to be worse, in other ways (for example, it used to be a very white, very male demographic). It's not my fault that things went the way they did. Folks liked money, so folks built a culture that maximized profit, and eschewed humanity.
I am quite sorry about that, but it doesn't change the fact that it was not always so.
It's not in my personal interest to go about creating a slideshow on "how things used to be." I know what I know. I lived it. I ran teams, exactly like I described, and I was a proud member of very large, high-functioning teams that stuck together for decades without stabbing each other in the back.
I don't disbelieve you, but I'm saying your experience can't be generalized in that way. Only aggregate data can tell us these things. Your experience may well have followed the exact trajectory you've described, but maybe 90% of people see the opposite.
While maybe it does sum up our work culture it shouldn't influence how you work. Rarely have I seen someone who "runs faster" be more valued (monetarily or among senior peers) than someone who churns out quality and runs "a little slower".
Team is still very much a thing and if your team members are looking at each other as competition then that sounds like a culture thing, maybe the norm, still not acceptable.
The collateral damage of careerism is objectifying your coworkers as either enemies or things to manipulate in order to advance yourself. It's the belief that all software devs are temporarily embarrassed FAANG devs.
This mindset will damage you over the long run, and the resulting career success may or may not be able to offset it. A zero sum mindset will lock you into this view along with the accompanying anxiety.
Given how quickly income inequality is rising, can you blame people for taking any advantage possible to try to stay ahead of the curve? If it means throwing your teammates under the bus to get more money, that's unfortunate but it's going to happen.
With those new interpreted language that are easy to pick and have a low-barrier of entry you are constantly having to run faster than an influx of fresh energetic high school dropouts and boot camp graduates.
With less fashionable language that require significant expertise and experience in picking them up like C (understanding the hardware level) and Java (understanding the JVM and OOP concepts) the barriers of entry are much higher and this will mean you have to outrun fewer people in the long run to survive.
I am pretty sure that you can programm java without knowing details about the JVM and I would think, that most java programmers do exactly this. I think only in high performance scenarios knowing more is beneficial?
But I have not touched java in a long time .. as I have indeed choosen the web as plattform.
But I don't feel threatened by the high school kids coming from boot camps.
Edit:
I know what a pointer is, so I can work closely with wasm libaries.
I know algorithms and how to structure data and why I am structuring data this way in this case, so I can adopt in another case.
I know how to achieve performant simple code.
I know how to debug layers of code with sideeffects over sideeffects. Raceconditions, memory leaks, etc. (All a thing in js, too). Using and understanding the profiler etc.
Someone coming from a coding bootcamp, does not know this. He or she might learn it after years of practice, which is allright by me - but they are no direct threat to me, despite that I don't even really know react for example.
not feeling threatened doesn't mean you're not under threat.
It's entirely possible that between your skill level and those boot campers is a few(dozen) percents of workforce. But at the same time it's entirely possible that if you are not as quickly progressing as the growth of the industry, you could become a part of the same percentile as bootcampers in no time.
It's not only about performance, it's also about maintainability. Codebases written by inexperienced programmers are extremely convoluted, nothing is decoupled and functions are extremely long and do multiple things. Extremely hard code to maintain or add features to.
A lot of the Java programmers I know professionally know fuck all about JVM internals, etc. Its largely unnecessary unless you have to chase down some extremely subtle bug most of the time.
A lot of them are senior or principal product engineers at companies you will have heard of.
Whereas with C, its extremely necessary to get into the weeds - otherwise your code just crashes or suffers some memory corruption issue, race condition, etc etc.
> I am pretty sure that you can programm java without knowing details about the JVM
yeah that was the whole point of object oriented programming and Java to begin with. You don't need to know the details of the underlying implementation, focus on the problem you're trying to solve.
"You don't need to kill a chasing bear to survive, you just need to run faster than your friend."
Problem with this approach is you run out of friends quick. People in bear country cary bear spray, have dogs to scare off bears and electric fences to keep them out.
We have tools and culture to not have to deal with/rely on survival of the fittest if we don't let fear control us - whether at work or in nature.
I find it hard to believe people who learned Java don't have to learn new things every now and then. Yeah maybe they stuck to Java but the whole backend ecosystem looks way different than even 10 years ago.
Even C is debatable.
Of course, everyone is always learning, you can't remain static. But you could afford to become more and more of a specialist in Java and growing your job opportunities that you can apply to.
If you became more and more of a specialist in Perl on the other hand you would have had to completely relearn something new by now to find as many opportunities as you used to in the late 90s.
I don't think it made a huge difference in most of these guys careers. I'm sure Perl "specialists" were able to move stacks if they wanted to...and you learn most of it on the job anyway so its not like you had to take a year off to catch up learning Java. So yeah it was a time investment for people but I don't think its as dramatic as you're making it seem.
I'm saying this based on the fact the job market was amazing for software developers in the last decade or more.
Things now might be different.
There are a considerable number of Perl jobs out there - just not many "greenfield" perl jobs.
Most of them are maintaining existing codebases (not a fun job), and some are "help port this legacy codebase to not perl".
I'd not discount Perl. Its incredibly fast to develop services in, stable as fuck, runs anywhere, performant (relatively), flexible, and if you were a startup looking to get a product out the door, just offer decent TC to a couple of old hands you can ship something viable fast.
A horrifying amount of applications out there that I've seen are basically just that - wrassling some text around, but with a billion layers of unnecessary abstraction.
I get to see a lot of peoples code in my job. Most of it is ridiculous levels of over engineering
Exactly my point. You had proportionally as many perl jobs in the late 90s as you have Ruby jobs today. It even had early mover advantage in the scripting space and insanely good ecosystem of libraries.
I have not stopped messing with Stable Diffusion and llms for like 7 months now and I've been a software engineer for 20 years. I use copilot and chatgpt and my own brain and have released two compiled python apps on itch ( first real apps I've ever built and released from the ground up on my own) - both are ai tools, one for stable diffusion one for flan-t5. I'll be releasing a unity solitaire game soon as well, and ive been training my own models.
This is the most fun I've had creating things since I started programming.
> This is the most fun I've had creating things since I started programming.
Definitely getting that vibe over here. I've been revisiting the exploration-style programming I was doing when I was young - Mandelbrot sets, Truchet tiles, all the old Computer Recreations columns stuff. Things you code up just to see what they look like.
Being able to say "Turn this pseudocode into a Processing sketch" is a joyous thing.
I've gone from hating PHP for most of my career, to now having a grudging appreciation for it. Its a clusterfuck, but it works really well, and deployment barely gets simpler than "untar into webroot, done".
There is still required setup for things like PHP, like what reads from the webroot and serves the requests. Other things, like binaries, can be almost completely self-contained and do everything, and then you just move the binary to the server and run it, and you get the full environment needed, no Apache with mod_php required (or what the kids use nowadays)
I also forgot briefly what a complete fucking nightmare instrumenting/debugging PHP (on say, a LAMP stack) can be - which is the inevitable result when PHP decides to behave in "interesting" ways.
I think what the GP is getting at is that one’s personal feelings about Electron do not matter whatsoever. There are fantastic billion dollar products built with the framework, that’s an objective fact. We can criticize it from a technical standpoint all we like, but the market is not something we can out reason.
It’s a bit like calling e-scooters an abomination. It’s just an opinion, and one that certainly isn’t stopping money from being made.
Except that the pendulum has sung quite a bit in a few of those cases. Strong type systems that work best with a compile step have been clawing back ground from loosely typed dynamic languages, and the power and utility of Postgres/RDS has kicked off a mini SQL renaissance.
> Knowing the subtlelties of memory management in the 80' didn't help the Ruby coders to create RoR and run Basecamp, or the Python coders to create Django and run the Washington Post
Those programmers didn't need to know the subtleties of memory management because when they programmed in Ruby they didn't have to debug in C. GPT is very different.
Sort of off topic - but Django was actually created by the author of this post! But in Lawrence, KS to run a small little newspaper's site (Lawrence Journal-World). WaPo then adopted it, which was obviously a huge boon to the growth of the framework.
On the contrary, if you don't know, then you don't know. If you're always needing to use ChatGPT or other LLMs then what happens in a world where they're unreliable?
It think it depends on if your see SWE as creative or not. We've had plenty of tools to increase productivity and user experiences still suck too much too often.
Making something easier doesn't necessarily increase quality. It's early days. It's a fool's errand tp try to predict the future. Now more than ever.
Knowing the subtlelties of memory management in the 80' didn't help the Ruby coders to create RoR and run Basecamp, or the Python coders to create Django and run the Washington Post.
People jumped at ORM, CSS frameworks and JS wrappers, and won the day because they traded memory and CPU for what the user wanted.
The new generation will do the same. They will figure out how to be super productive with AI, way more than what we are. And our superpower will be useful in specialized cases, but mostly, their impacts will be small compared to the order of magnitude of speed they'll gain by using the new paradigm.
People said interpreted languages were a waste, that you had to learn SQL, that Electron was an abomination.
But the people building stuff always win, not what we think is the right way.
That's why PHP won at some point. JS won at some point.
And something super practical (but that will make us say uhh...) made by AI will win at some point.
That's also why all the open letters and ethics committees will have no impact: the short term advantage given to AI users will be such that they will take everything over by storm.
It's already happening in porn: we just gave millions of teenage boys a shiny new toy, and they are spending days and nights on it. New incredible models come out every day. Some hyper specialized. Last week, I saw a publication of a new model specially trained on only vagina called "bettervulva" and one for boobs called "breastinclass". Somebody spent hundreds of hours on those, collecting the data, annotating it, and training.
I guarantee each niche of the world is doing exactly the same. Not to mention each new model is coded with somebody who has the previous models to help with the new one, code included.
This is snowball from now on.