> it makes you far more productive as an individual, which if true should be an easy sell
Writing unit tests where needed makes you more productive in the long run. Writing in modern languages makes you more productive. Remember how people writing assembly thought compiled languages would rot your brain!
But people just resist change and new ways of doing things. They don't care about actual productivity, they care about feeling productive with the tools they already know.
It's a hard sell when an application moves a button! People don't like change. Change is always a hard sell to a lot of people, even when it benefits them.
To the contrary, people resist change for good reasons: changes to tools rob attention and focus from the work, often for completely arbitrary or decorative reasons. Sometimes changes remove or break important aspects of the tool and force someone to waste time developing a new workflow which is, on average, no better than the previous one. It is vanishingly rare that the software team making the changes in question did sufficiently rigorous testing to show that the new version is a net "benefit" for most users of the software; they don't have time for that. All too often, no significant group of users was even consulted about the changes, which were made for reasons like advancing someone's career ("shipped X feature changes") or looking different for the sake of marketing something merely re-arranged as new ("the old style was so 2018").
The teams making changes to software are, on average, moderately worse than the teams who originally developed the software, if only because they missed out on the early development experience, and often don't fully understand the context and reasons for the original design and don't reason from first principles when making updates, but copy the aspects they notice superficially while undermining the principles they were originally established on.
Even when the changes are independently advantageous, it is common for changes to one part of a system to gratuitously break a variety of other parts that are dependent on it. Trying to manage and fix a complex web of inter-dependent software which is constantly changing and breaking is an overwhelming challenge for individual humans, and unfortunately often not a sufficient priority for groups and organizations.
> "Remember how people writing assembly thought compiled languages would rot your brain!"
No, I don't remember that and I've been around awhile. (I'm sure one could find a handful of examples of people saying that but one can find examples of people saying sincerely that the earth is flat.) It was generally understood that the code emitted by early, simple compilers on early CISC processors wasn't nearly as good as hand-tuned assembly code but that the trade-off could be worthwhile. Eventually, compilers did get good enough to reduce the cases where hand-tuned assembly could make a difference to essentially nothing but this was identified through benchmarking by the people who used assembly the most themselves.
If you want to sell us on change, please stop lying right to our faces.
Note also that it took, more or less, a hardware revolution in the form of RISC, to make compilers able to compete. A big piece of the RISC philosophy was to make it easier for compiler writers.
They eventually got there, (and I expect AI will eventually get there too), but it took a lot of evolution.
Starting with the 386, the ISA got a lot more compiler friendly. Up to 286, each register had a specialised task (AX,CX,DX,BX means Accumulator, Count, Data,Base register). Instructions worked with specific regs only (xlat, loop). When 386 and 32 bits happened, the instructions became more generic and easily combinable with any register. I remember people raving over the power of the SIB byte or the possibility to multiply any pair of register. While not RISC, it got clearly more easy for compilers to work with the ISA, and I remember reading in magazines that this was an explicit design intention.
Lots of x86 assembly out there from that time period. Beating the compiler in the eighties and nineties was a bit of a hobby and lots of people could do it.
Modern ISA designers (including those evolving the x86_64 ISA) absolutely take into account just how easy it is for a compiler to target their new instructions. x86 in modern times has a lot of RISC influence once you get past instruction decode.
> Writing unit tests where needed makes you more productive in the long run.
Debatable? It has positive effects for organizations and for the society, but from a selfish point of view, you gain relatively little from writing tests. In your own code, a test might save you debugging time once in a blue moon, but the gains are almost certainly offset by the considerable effort of writing a comprehensive suite of tests in the first place.
Again, it's prudent to have tests for more altruistic reasons, but individual productivity probably ain't it.
> Writing in modern languages makes you more productive.
With two big caveats. First, for every successful modern language that actually makes you more productive, there's 20 that make waves on HN but turn out to be duds. So some reluctance is rational. Otherwise, you end up wasting time learning dead-end languages over and over again.
Second, it's perfectly reasonable to say that Rust or whatever makes an average programmer more productive, but it won't necessarily make a programmer with 30 years of C++ experience more productive. This is simply because it will take them a long time to unlearn old habits and reach the same level of mastery in the new thing.
My point is, you can view these through the prism of rational thinking, not stubbornness. In a corporate setting, the interests of the many might override the preferences of the few. But if you're an open-source developer and don't want to use $new_thing, I don't think we have the moral high ground to force you.
> In your own code, a test might save you debugging time once in a blue moon
It’s much more than this. You feel it when you make a change and you are super confident you don’t have to do a bunch of testing to make sure everything still behaves correctly. This is the main thing good automated tests get you.
Early compilers really did suck. They were long term big wins for sure, but it wasn't unreasonable for someone who was really good at hand assembly, on tightly constrained systems, to think they could beat the compiler at metrics that mattered.
Compilers did get better, and continue to--just look at my username. But in the early days one could make very strong, very reasonable, cases for sticking with assembly.
> Remember how people writing assembly thought compiled languages would rot your brain!
Well, how'd you describe web apps of today if not precisely brainrot?
> They don't care about actual productivity, they care about feeling productive
Funny you'd say that, because that describes a large portion of "AI coders". Sure they pump out a lot of lines of code, and it might even work initially, but in the long run it's hardly more productive.
> It's a hard sell when an application moves a button!
Because usually that is just change for the sake of change. How many updates are there every day that add nothing at all? More than updates that actually add something useful, at least.
> Change is always a hard sell to a lot of people, even when it benefits them.
You're assuming that the change is beneficial to people when you say this, but more often than not that just isn't true. Most of the time, change in software doesn't benefit people. Software companies love to move stuff around just to look busy, ruin features that were working just fine, add user hostile things (like forcing Copilot on people!), etc. It should be no surprise that users are sick of it.
Writing unit tests where needed makes you more productive in the long run. Writing in modern languages makes you more productive. Remember how people writing assembly thought compiled languages would rot your brain!
But people just resist change and new ways of doing things. They don't care about actual productivity, they care about feeling productive with the tools they already know.
It's a hard sell when an application moves a button! People don't like change. Change is always a hard sell to a lot of people, even when it benefits them.