TBH the OP post seems to be highlighting that "when we forget history, we're doomed to repeat it."
Not trying to be ageist but a younger dev wouldn't have context on a time when the industry had timestamps as versions and the core reason why SemVer became preferred, as you describe above.
The one thing I consistently see CS programs omit which drives me nuts with new hires. Zero knowledge of version control. Do yourself a favor and learn git now so you don't suffer later. It will help you all throughout your college classes too. TBH I'm not sure why this is such a glaring omission in CS degrees, I guess they just want to teach theory, not practical application but I've seen it consistently missing from new CS grads.
This is very practical advice, and something that several people, in this thread and elsewhere, have told me. I'm made a note of this and will consider it a priority skill. Thanks for taking the time to share this, @engineerDave.
FYI the roots of this approach come from traditional typography, which obviously predates the web. IME the web stuff more or less copies the standards established in typesetting or ends up just reinventing it. You could easily spend a career studying and learning it. I find it best to use a CSS framework like TailwindCSS where there are built in classes for dealing with it.
I never have had a project fail due to it's tech. In my experience, projects rarely fail due to the tech, they fail due to the team and management.
If you get to the point you're referring to, e.g. Twitter having fail whale issues because they built entirely on mostly vanilla Rails, is a good problem to have and one you'll be able to get resources to fix once you get there.
Maybe it's just me but IMO your time would be better spent reading something like Predictably Irrational by Dan Ariely or brushing up on your psych 101 concepts. Learn to deal with the irrationality of your team, your customers, and your boss and your life will be a lot less stressful.
These two comments make me think that a careful study of Conway's Law, its implications, and related understanding of people's behavior when organized to work together may actually be the most important knowledge for software architects.
Barry Oshry is one author that has investigated and detailed organizational behavior and developed simplified models that can provide insight and guidance for daily practice and planning. He has multiple books available, I recommend "Seeing Systems". Here's a video recording of a talk covering some of the content: https://www.youtube.com/watch?v=VYpO-pK7IFA
As a ruby dev this completely makes sense to me based on the Java developers I have worked with. I'm willing to bet he also never even considered jRuby as a happy compromise, also basing this on my experiences with the Java developers I have worked with
I've also noticed that most Java devs dislike Ruby just as much as I (a ruby dev) dislike Java. But the guy who made this decision had never done development in Ruby, Java, or anything else. He was a former db administrator who went into management.
I haven't really seen anyone mention this one but if you run Docker heavily, you're going to want Linux. Mac and windows both run Docker via Hypervisor and it's quite a bit slower, at least for building. Short of that just get a mac. Although TBH this isn't a huge enough reason if you're only incidentally running docker as you can still shift your context to a linux machine on your network for a performant context.
The main reason isn't build quality or anything like that, although IME it's good on the Apple side. It's because mac is the shim between enterprise OS and open source OS. Things like MS Office, MS Outlook might not seem like much until you have to have them. Granted O365 has made some nice strides in making them moot but the web versions can still be limiting. Also if you go into development for anything mac or iOS you'll need to be on macOS for XCode, and you still have the option of installing the Adobe suite of products, as much as I hate using them.
Not trying to be ageist but a younger dev wouldn't have context on a time when the industry had timestamps as versions and the core reason why SemVer became preferred, as you describe above.