"just meant that developers are expected to bundle their own thin custom-built JREs alongside the application" can be significant initial setup work and overhead, and seemed more so back then. With Java 8, I shipped a combo Swing/JavaFX application, and built it once, and it ran everywhere. Now I have to figure out the module system and figure out how to ship it with platform-specific JREs? That's a lot more packaging overhead for a hobbyist project, or at least, that's what it felt like at the time.
After hearing (from Oracle) in the early 2010s about how JavaFX was the future of GUIs in Java, I can identify with the feeling of betrayal when it was unceremoniously removed from the JDK. If I'd known that was coming, I wouldn't have added JavaFX to my Swing application.
Nowadays we know that there are Bellsoft and Azul (is ZuluFX still a thing?) JVMs that still ship with JavaFX, but when Oracle made that announcement, we didn't know that, There were a couple years there where it looked like a significant refactor to externally linking OpenJFX, and shipping one-distro-per-system instead of one JAR, would be needed to move past Java 8. Now it's not so bad, I still target Java 8 as a minimum, but can point my program's users to the Liberica JDK and everything just runs.
I keep an install of SeaMonkey 2.49.5 on my desktop. It's my preferred platform for browsing FTP and Gopher (the latter with the OverbiteFF add-on), and is the last version of SeaMonkey that has full NPAPI support, useful if I find an old site with a Java applet, or would for some reason need Silverlight. And being based on Firefox 52, it still works with most web sites as well; more recent versions would work even better with modern web sites.
I should try its HTML editor, it might be a nice upgrade from writing my HTML pages in Notepad++.
The vintage UI is part of the charm. Admittedly the "Stop" button is less useful than it was in the '90s, but I'm a believer that we've lost more than we've gained with the trend towards low-chrome browser designs.
Not necessarily recommended, but something that was done by a real team at a real company.
We all had our own GitHub Enterprise accounts. But only one was logged on to each computer. Rather than switch out the accounts when someone else used a computer, we just included the initials of whoever was making the commit in the message. E.g. DU: Fix some bug, if Double Unplussed was making the commit.
This only really worked because no one was using a GitHub login that they also used for personal projects - only the corporate ones were connected. And it made the GitHub statistics on who was contributing what completely useless. But it did mean that we could rotate among the shared computers and push easily, and if you did need to ask someone for help when investigating a bug, you could still see who made the changes via git blame - just by looking at the message instead of who Git thought had pushed it.
Might not work for your use case, and I'm sure some readers will be horrified, but it worked well enough for us, in an XKCD 1172 (https://xkcd.com/1172/) style manner.
Part of the problem is we were all newbies at some point.
I remember the first time I tried to use SCM. It was a collaborative project in college, and our professor recommended we set up a CVS repo (at that point in time, he probably should have recommended SVN, but we didn't know that). We spent about an hour trying to set one up, and eventually concluded it was a waste of time and that we'd just e-mail each other .tar.gz files of the repo and manually sync them. Eventually we did break something and have to go back to the last .tar.gz to un-break it, which wasted another hour or so, but with the friction we'd seen trying to set up CVS, that still seemed preferable to trying SCM again (although it also showed that SCM would have been helpful had we been able to set it up).
GitHub with a password is much easier than setting up a CVS repo as a newbie, and had that been an option then we likely would have succeeded. But I'm much more doubtful that we would have tried and succeeded at token authentication; I also remember how mystifying I found it the first few times I worked somewhere that required it, even understanding the underlying concepts of public key cryptography. The problem is understanding the tools well enough to get it working, and working across operating systems (Linux doesn't have PuTTY; Windows doesn't have the Linux command-line tools; etc.).
When I eventually started using SCM reliably, it was with Mercurial + BitBucket + a password. I recall that I kind of knew I should set up a token, but my first few attempts were unsuccessful (largely due to most instructions being Linux-focused, and being on Windows), and thus I kept using a password for years because making progress on development seemed more useful than figuring out a token. I did use randomly-generated, lengthy, unique passwords, so the risk of using a password seemed pretty low.
So I think this is a bad thing for newcomer-friendliness. Perhaps it is an opportunity for GitLab and whatever other competitors still exist. But I would have rather seen it remain an option, perhaps based on new users choosing whether they're new to Git (allow passwords) or experienced (require tokens, but be able to change it in case they're only experienced with Git, and not with tokens).
In office and proof of vaccination is exactly what I will be looking for when I look for my next job. I also don't like working remotely, so in-office is a requirement, and proof of vaccination is nice insurance against the company switching back to remote in the future due to an outbreak.
I quit my job over the lack of a return to office.
Interacting with people to solve problems is a lot of what I enjoyed about being a software developer, and particularly after starting a new job mid-pandemic where I didn't already know people (the old company imploded for pre-pandemic reasons), work was much more isolating and less rewarding than it was in 2019.
Once it became clear return-to-office was not on any sort of definite timeline, and that I would be fully vaccinated as more places reopened, it became an easy decision to quit. And it's one of the best decisions I've made. My mental health has improved considerably, and I've discovered new hobbies and am in better shape than I ever have been. I should probably have taken a multi-month gap at least once before.
I met a colleague from my old company today (in-person, of course), who reported that ten people have left this year, from an initial number of roughly 60. It's a consulting company, and as far as I know no one has been mandated to return; most of the clients were already remote. So that's a ballpark 15-20% figure, albeit with a small sample size, of people leaving over 7 months from a company without a strong return to office movement. Many of people leaving were people with low tenure at the company, and thus not having the in-person ties that might encourage staying with their friends and colleagues.
Small addendum: I've also noticed that, especially among the more extroverted developers, people who were on a team that went remote tend to be happier than people who join a team that is already remote. I think a lot of this is that the pre-pandemic team members already had good rapport and communication among themselves, and could use that to bridge over to being remote. Whereas when people joined teams as new members post-March 2020, it was much harder for them to build that camaraderie and - importantly - trust with their colleagues.
On the team I joined mid-pandemic, one of the ways this evidenced itself was higher turnover among the people who joined after March. The tech lead also noticed universally slower uptake on team-specific knowledge among the new folks, compared to when previous folks had joined. None of the new folks became team experts in the year I was there, despite having the past experience that would suggest it would be likely they would. And generally, the team continued to rely on its pre-pandemic experts.
All this is having joined a remote team where I think I would have really enjoyed being on the team in the office, and which I know from industry colleagues was a successful team pre-pandemic. Even with those advantages, joining remotely was rough.
In other words, I think we may still be in the honeymoon period for remote work appearing productive among the industry at large. For some people, it may work well in general, and if you specifically recruit those people you may be able to build a successful remote team (some companies did it pre-pandemic, after all). But across the industry, I suspect remote teams will become less productive over time as experienced members switch jobs, and (if they aren't the type that naturally likes being remote) experiences the slower uptake and more isolating experience of being on a team where they've never met their colleagues in real life.
I couldn't disagree more strongly with the author of the linked article. I'd almost call it pro-remote-work propaganda.
But, I say that as a software developer who is extroverted (at least relative to the profession as a whole), and is in my early 30s. Working from home can be super isolating and depressing, and I would rather leave a lucrative career than start another remote job (I already quit my previous remote job, currently living off savings rather than work remotely).
I know some people who like working remotely. But I also have friends who hate it as I do, and are super eager to return to the office (some already have, at least on a part-time/hybrid basis. The two biggest factors are see are introversion vs extroversion, and whether they live with other people. My extroverted friend whose wife works at an in person job, and is thus alone all day, hates it. Another friend who lives by herself hates it. A third whose social life centered on work hated it, and wound up moving in with her parents despite being in her 30s just to have some other people around.
Productivity-wise, I agree with the studies I've seen showing more time, but no more results. I think of my friend who is not confident in his job security and is working at least 50% more hours than in his pre-pandemic in-person job; I've told him several times his colleagues probably don't realize how many hours he is putting in or how effective he is, because he only interacts with about three people and it's all remote. In the first couple months of his job, before his workload went sky-high, he complained that some of his colleagues were completely burnt out and unproductive; now it's no mystery why some of his colleagues are like that.
Another reason I think it's introvert vs extrovert is my conversations with recruiters. I'm that odd software developers who enjoys talking with recruiters, at least the ones who take the time to get to know you. Almost if not 100% of the recruiters I talk with miss being in person. Most of them are young. And guess what, recruiting is a highly extroverted profession.
My prediction for the software industry is there are going to be a lot of people switching jobs over the next year or two, as the people who want to be in the office but are stuck at remote gigs leave, and similarly the people who want to be remote but are stuck at in office gigs leave. Some people will probably prefer hybrid too, but most of the people I know have strong opinions on the topic, and I wouldn't be surprised if hybrid mostly falls by the wayside once uncertainty around covid protocols subsides.
We put street signs on highways in Ohio. Quite handy for knowing whether you're in the correct lane, as it doesn't have the ambiguity that overhead signs can have.
Of course, we do also have overhead signs as a backup and for longer-range visibility. But it's more likely that the overhead signs are useless due to a setting sun than that the on-road ones are due to snow. The streets with on-road signs are very high priorities to plow, so the on-road signs are going to be visible unless it's a very bad storm where you probably shouldn't be on the road, and if you are you're probably going home and already know which lanes to be in.
I'm not saying this should be done for every road; it works best for roads known by a number (I-71; US-23; OH-315, etc.) where you don't have to read a long name. But it's not an daft as idea as it might sound.
After hearing (from Oracle) in the early 2010s about how JavaFX was the future of GUIs in Java, I can identify with the feeling of betrayal when it was unceremoniously removed from the JDK. If I'd known that was coming, I wouldn't have added JavaFX to my Swing application.
Nowadays we know that there are Bellsoft and Azul (is ZuluFX still a thing?) JVMs that still ship with JavaFX, but when Oracle made that announcement, we didn't know that, There were a couple years there where it looked like a significant refactor to externally linking OpenJFX, and shipping one-distro-per-system instead of one JAR, would be needed to move past Java 8. Now it's not so bad, I still target Java 8 as a minimum, but can point my program's users to the Liberica JDK and everything just runs.