The commercial versions of IDA still do COM and MZ executables as far as I'm aware, although it's been dropped from the free versions since 5. (Which is still available from ScummVM's reverse engineering page, but is only a disassembler and doesn't come with the decompiler)
Ghidra does a vaguely OK job with MZ executables, providing they've been unpacked first. It really struggles to represent DOS function calls properly, you'll find arguments go missing from the decompiled code. There are some third-party plugins which improve things a bit. And it doesn't have signatures for any of the libraries so the output will just be a lot of `if ((var26 & 0xFEEE) && var42 > 0xE0) { ... }` and it's up to you to work out when one of the variables is actually a pointer to video memory or whatever.
Reko can also decompile this era of code, it does have a tendency to crash on any more complex program but will be fine for simple files. Similar problem that the decompiled pseudo-C code doesn't really illuminate what's going on any more than just reading the disassembled x86 assembly language and walking through any tricky sections in the DOSBox debugger does. Without all of the Win32 API calls modern programs make there's a lot more work needed to figure out what's going on.
Personally I find I also end up needing to use a vintage tool like Sourcer alongside the modern ones, because the newer stuff doesn't annotate things which were common in the era like directly referencing the BIOS data area or reading the interrupt table from memory rather than using the DOS calls for it. It's that or spending a lot of your reverse-engineering time discovering how things were done in the DOS days.
I'm getting the same sort of vibe from my corners of the Internet: people moving away from the big walled gardens and doing more distributed things like forums and running their own Mastodon instances. Some long-lived forums are undergoing amazing resurrections, seeing more posts in 2022 than they have between 2017-2021. I do pick up a general theme of being able to control the experience, whether that's the UI or being able to set moderation policies.
IMO Reddit killed their vibe when they removed the distinction between post karma and comment karma, in the subs I visited it seemed to encourage the upvoting of very basic questions and observations that were easy to farm karma from by posting the same answers, comments and jokes every time. (I'm aware that some of the smaller and more actively moderated communities have escaped this, sadly it didn't cover the main ones I was interested in.)
I think there's a very specific form of overengineering afflicting products currently, which I'd classify as "endless revisiting". This is where companies build something which works well enough, but then get trapped in a cycle of endlessly tweaking that one thing. Inevitably the amount of code churn in this one area combined with the need for some semblance of backward compatibility results in something that is fragile, complex and slow.
Plus the annoyance as a user that whenever you use this thing, all your tools are in a slightly different place and work slightly differently to how you left them. IMO there's a need for better balance between "it works well enough, leave it alone" and "we haven't fully optimised this workflow yet" in product development.
I think the problem is not necessarily things such as likes, upvotes, shares or other features but platforms which don't consider Goodhart's law when they introduce them.
Large Reddits tend toward bland and repetitive cookie-cutter content not solely because Reddit has a voting mechanism, but because the site's structure allows that mechanism to be highly vulnerable to karma farming. There are many casual users who don't notice the content is low-effort or repetitive, special interest subs make it easy to target posts, and the volume is too high for moderators to handle (and many will have a "we can't delete things which are popular and within the rules, even if we don't like them" policy).
Facebook (and YouTube, and to some extent Twitter) are a weird branch of that. The application of Goodhart's law wasn't initially to the users but to the platforms themselves. I have little doubt that initially they started with an altruistic observation that people spent more time on the site if they tended to see content from their most entertaining friends, but then someone realised seeing bad takes from a stranger was even more engaging and so you should see that instead. People realise they get more visibility for being controversial, and again there is no real moderation for this, so we have even more of a tyre fire than the blandness which upvote-driven sites tend toward.
(Twitter at least still offer tools to curate and remove algorithmic ranking from your feed, even if they try to nudge users away from them. That doesn't protect more popular users from the "trolling brings me attention" culture elsewhere on the site, though.)
I think HN is less affected by karma farming due to having a broader range of topics, active moderation of repetitive content and perhaps most importantly a relatively small community with a strong appreciation that the upvote should be used sparingly for interesting and unique content. Also the text and link based format helps - this might change quickly if e.g. HN allowed posting photos of vintage computer equipment, which could disproportionately gain upvotes compared to insightful long-format articles despite being easier to produce.
Javascript editors trying to reinvent desktop paradigms but without the 40-odd years of practice and having all the events arrive whenever they feel like is one of the most frequent irritations of web-based platforms for me, because you use a text editor so frequently and therefore encounter its problems similarly often.
For example, earlier today I was editing a small internal app in Retool. I typed something, instinctively went for Cmd-Z, and it reverts a bunch of changes I made in the query I had open 5 minutes ago. Of course, by the time I spot it and hit Shift-Cmd-Z, the internal state has updated so now it redoes some other unrelated undo operation and I have two broken things to fix.
And then of course there's Notion, the champion of "you've hit a keyboard shortcut and it's applied it to something halfway across the screen from the selection, or possibly just given up trying to do anything useful and deleted a few paragraphs of text at random". Perhaps they were pining for the outrageously janky experience that was attempting to make even the most innocuous of formatting changes in earlier versions of Word For Windows.
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.
One surprisingly practical use I found for things like this; when internal tools throw up a 404 or a 503 with the usual default status page, people assume "oh it's not working, I'll try again later".
When they get an unexpected cat (or dog, in this case) they tend to go and ask their tech team, "what's with the cat?" It's not a substitute for good logging and alerting in any way, and is totally unsuitable for environments where internal tools need to appear professional and sensible, but as a way to get people to pay attention when something goes wrong then a cute animal can work a lot better than a "normal" notification.
At the start of this year I started an experiment; whenever an application distracted me more than once per day with a push notification or toast, it would have its permissions to send any notification of any type revoked. Even if it was a work-related app, probably the scariest category of things to turn off.
A surprise for me was that once the biggest offenders were turned off, my brain craved the low-reward distraction fix - I would find myself compulsively refreshing Twitter or a forum in the hope of getting that same brief, low-value, "here is something you need to look at" reward. But it didn't come, and while I lost close to a month of leisure time on compulsive-refreshing I found that "there is no reward here" eventually filtered through to my subconscious.
The other shock was how little people at work noticed the difference between "I have a notification, let me respond to that" and "I'm at a nice break, let me check my messages". I thought median response time going from a few seconds to a few minutes would be problematic but nobody even notices. (Perhaps they're also too distracted?) Of course there is the worst case that I get head down in something and then I'm 2-3 hours out before I can get back, but it helps we have a team where we can be quite open with the idea of, "I quit Slack if I need focus time, here are emergency ways to contact me if necessary"
I am not yet back to reading books. I hope that will come in time. But I definitely find myself better at engaging with long-form entertainment, without stopping and getting distracted within the first few minutes.
I have a mental image of people setting great store in which platform Douglas Adams has moved to lately, given his tendency to hop between media and delight in the new and interesting.
I can certainly see him both being delighted by Twitter and also becoming incredibly bored with Twitter, over not too long a time period...
Ghidra does a vaguely OK job with MZ executables, providing they've been unpacked first. It really struggles to represent DOS function calls properly, you'll find arguments go missing from the decompiled code. There are some third-party plugins which improve things a bit. And it doesn't have signatures for any of the libraries so the output will just be a lot of `if ((var26 & 0xFEEE) && var42 > 0xE0) { ... }` and it's up to you to work out when one of the variables is actually a pointer to video memory or whatever.
Reko can also decompile this era of code, it does have a tendency to crash on any more complex program but will be fine for simple files. Similar problem that the decompiled pseudo-C code doesn't really illuminate what's going on any more than just reading the disassembled x86 assembly language and walking through any tricky sections in the DOSBox debugger does. Without all of the Win32 API calls modern programs make there's a lot more work needed to figure out what's going on.
Personally I find I also end up needing to use a vintage tool like Sourcer alongside the modern ones, because the newer stuff doesn't annotate things which were common in the era like directly referencing the BIOS data area or reading the interrupt table from memory rather than using the DOS calls for it. It's that or spending a lot of your reverse-engineering time discovering how things were done in the DOS days.