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.
Why not VSCode? It's support for extensions are great. Emmet for rapid HTML scaffolding, inline hex color preview, autocomplete for attributes, and not to mention great multi-line editing support. And, of course, CoPilot which can write/edit HTML so much faster than I can type. Can you tell I'm a fan?
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.
That's an orthogonal issue, we already use a pre-commit hook that prompts for the committers name instead of caching it. Who commits is one thing, who authenticates a push is another.
I guess we could have a shared github account and I could give it commit rights to the specific repositories. But that's still pretty silly that I should have to do that.
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.
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.
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 feel like I should chime in here. I love going out and partying. I love meeting new people face-to-face. Yet I strongly, strongly prefer working remote as opposed to going to an office. I do not need an office to supply me with human contact - I can go find human contact on my own. Indeed, I much prefer finding human contact on my own rather than at the office because at the office, I have to be careful and somewhat repressed if I do not want to endanger my job, whereas in many other social contexts I can be much freer and truer to myself.
I'm not sure how much I buy this. I fit the introvert profile pretty heavily, with most of my time spent on computers or DIY stuff growing up. The main thing for me is that I'm very entrepreneurial, so my life centers very heavily around work and sometimes side projects. This made the transition to WFH very painful as I no longer had a real way to separate the "work me" from the "home me". Burnout soon came on, and even looking back at rough proxy metrics like KLoC or time in meetings, I completely dipped in Feb 2020 and never recovered. Learning has also severely slowed down. So yeah, as much as I do not enjoy the prospect of city life again, I am ready to go back.
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.
I believe California does some of this in the really complex interchanges in the Bay Area, but I don't remember for certain and it's been years since I've been there.
That isn't quite the same a what this software is or what Groupy does, but that is a fascinating article. I loved this part:
---
For instance, one study subject took twenty minutes of staring at a Windows 3.1 desktop before being able to open a text editing program. Finally, a programmer spoke up that this was unacceptable, to Oran’s relief. But that relief would be short lived: “Our customers are morons!” exclaimed the programmer.
This was frustrating enough, Oran says. But then they talked to that user, and it turns out that he was actually a propulsion engineer for Boeing.
“He was literally a rocket scientist,” Oran says. “And even he couldn’t figure out Windows.”
---
IMO the #1 opportunity for open source software to gain more mainstream acceptance is focusing on making it easier for non-technical users to use. Which is hard when most of your userbase is technical users. Microsoft deserves credit for realizing they had a usability problem, and having made major improvements to that over the years.
> IMO the #1 opportunity for open source software to gain more mainstream acceptance is focusing on making it easier for non-technical users to use. Which is hard when most of your userbase is technical users. Microsoft deserves credit for realizing they had a usability problem, and having made major improvements to that over the years.
... I don't know. On the one hand, I applaud the sentiment. On the other hand, general computing needs of technical users are already becoming a niche too small for the market to serve. If Open Source community gets into their heads that they should optimize for non-technical users, I fear we'll have a dearth of tools...
Seconded. Marketing 101: Make it easy for the consumer to see why they might want to try the product.
I use Stardock's Groupy, and it does this well (and is inexpensive). I'm not sure why I'd want to switch to this when I already have Groupy, although the general idea is one that I think should gain more traction.
Background: I used Opera Presto as my main browser from 2007-2014, and Vivaldi since 2016 (2015 being a mix of Opera, Firefox, and Vivaldi). I've used Firefox as my main browser at work for most of the past four years.
One big factor for me is the customizability without having to rely on extensions. I trust Vivaldi (and von Tetzchner), and don't have to worry about whether I trust extension makers. The customization options in Vivaldi tend to work pretty darn well too, which can be more hit-and-miss with third party ones in Firefox.
Single-key shortcuts are also a big win for Vivaldi for me. I got used to these in Opera and they're great for efficiency while web browsing. Maybe I can get them with an extension for Firefox, but it's enabling one check box in Vivaldi. It's similar to why some people like vim plugins for browsers, but with less vim expertise required.
I've also seen Firefox remove a lot of features over the years. XUL extensions being the big one, but there are others. Firefox Hello. Firefox Panorama, just as I was starting to take a liking to it. Vivaldi has a philosophy of adding features that let you customize the browser to how you like it, and if only 0.2% of users use that feature but it makes them really happy, that's fine. Firefox will remove features if not enough users adopt it. Thus my trust that Firefox is going to keep features that I like has been lowered over the years, making me more hesitant to try new Firefox features, and generally more hesitant about Firefox.
Although I'm considering switching part of my home browsing back to Firefox because of its ability to not autoplay videos. Too many sites have those nowadays (and too often, self-hosted and not as third-party ads that are easily blocked), and Blink-based browsers can't stop them, and I'm getting pretty tired of having to pause/hide videos all the time so I can focus on reading articles.
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.