Definitely seems to be getting worse, outside of AWS itself, more websites seem to be having sporadic or serious issues. Concerning considering how long the outage has been going.
So for me, extremely anecdotally, I host a few fairly low-importance things on a home server (which is just an old desktop computer left sitting under a desk with Ubuntu slapped on it): A VPN (WireGuard), a few Discord bots, a Twitch bot + some auth stuff, and a few other services that I personally use.
These are the issues I've ran into that have caused downtime in the last few years:
- 1x power outage: if I had set up restart on power, probably would have been down for 30-60 minutes, ended up being a few hours (as I had to manually press the power button lol). Probably the longest non-self-inflicted issue.
- Twitch bot library issues: Just typical library bugs. Unrelated to self-hosting.
- IP changes: My IP actually barely ever changes, but I should set up DDNS. Fixable with self-hosting (but requires some amount of effort).
- Running out of disk space: Would be nice to be able to just increase it.
- Prooooooobably an internet outage or two, now that I think about it? Not enough that it's been a serious concern, though, as I can't think of a time that's actually happened. (Or I have a bad memory!)
I think that's actually about it. I rely fairly heavily on my VPN+personal cloud as all my notes, todos, etc are synced through it (Joplin + Nextcloud), so I do notice and pay a lot of attention to any downtime, but this is pretty much all that's ever happened. It's remarkable how stable software/hardware can be. I'm sure I'll eventually have some hardware failure (actually, I upgraded my CPU 1-2 years ago because it turns out the Ryzen 1700 I was using before has some kind of extremely-infrequent issue with Linux that was causing crashes a couple times a month), but it's really nice.
To be clear, though, for an actual business project, I don't think this would be a good idea, mainly due to concerns around residential vs commercial IPs, arbitrary IPs connecting to your local network, etc that I don't fully pay attention to.
> “How's that going to work when ten years in the future you have no one that has learned anything,”
Pretty obvious conclusion that I think anyone who's thought seriously about this situation has already come to. However, I'm not optimistic that most companies will be able to keep themselves from doing this kind of thing, because I think it's become rather clear that it's incredibly difficult for most leadership in 2025 to prioritize long-term sustainability over short-term profitability.
That being said, internships/co-ops have been popular from companies that I'm familiar with for quite a while specifically to ensure that there are streams of potential future employees. I wonder if we'll see even more focus on internships in the future, to further skirt around the difficulties in hiring junior developers?
This one (among others) does really fascinate me. Maybe it’s due to spending a lot of time around diverse groups of people but I’ve never really seen a huge distinction between these words. Washroom, bathroom, toilet, I and everyone I know pretty much would use interchangeably? Or at least wouldn’t blink at someone else using them.
Restroom, and a variety of others, might be slightly more usage specific but still… wouldn’t be unexpected or weird, I’d say?
I always assumed we just called it hydro in BC because so much of the power comes from hydroelectric, but then I moved and it seems we call it hydro everywhere no master source..?
Hydroelectric was historically even more dominant in Canada than today. In places that aren't majority hydro now, they were in the past, like in Ontario and Alberta.
The name of the utility companies in most provinces was probably an influence. Until 1999 in Ontario it was the Ontario Hydro-Electric Power Commission, shortened normally to Ontario Hydro. Manitoba Hydro. Hydro Quebec. I think in Toronto they still stamp manhole covers with THES (Toronto Hydro-Electric System).
In Ontario, we still have Hydro One as a (the?) primary distributor of electricity outside urban environments.
If I remember correctly, Hydro One also serves some parts of the Ottawa area, and their delivery rates were different enough from Hydro Ottawa that it was often a material consideration for where one chose to buy one's house.
They have only recently finished phasing out coal, such that it appears in last year's statistics. And it's still mostly natural gas, i.e. a fossil fuel.
Fixing everything is impractical, but I'd say a safer rule of thumb would be to at least understand small strangenesses/errors. In the case of things that are hard to fix - e.g. design/architectural decisions that lead to certain performance issues or what have you - it's still usually not too time consuming to get a basic understanding of why something is happening.
Still better to quash small bugs and errors where possible, but at least if you know why they happen, you can prevent unforeseen issues.
Sometimes it can take a serious effort to understand why a problem is happening and I'll accept an unknown blip that can be corrected by occasionally hitting a reset button occasionally when dealing with third party software. From my experience my opinion aligns with yours though - it's also worth understanding why an error happens in something you've written, the times we've delayed dealing with mysterious errors that nobody in the team can ascribe we've ended up with a much larger problem when we've finally found the resources to deal with it.
Nobody wants to triage an issue for eight weeks, but one thing to keep in mind is that the more difficult it is to triage an issue the more ignorance about the system that process is revealing - if your most knowledgeable team members are unable to even triage an issue in a modest amount of time it reveals that your most knowledgeable team members have large knowledge gaps when it comes to comprehending your system.
This, at least, goes for a vague comprehension of the cause - there are times you'll know approximately what's going wrong but may get a question from the executive suite about the problem (i.e. "Precisely how many users were affected by the outage that caused us to lose our access_log") that might take weeks or months or be genuinely nigh-on-impossible to answer - I don't count questions like that as part of issue diagnosis. And if it's a futile question you should be highly defensive about developer time.
That's very fair - at least with third party software, it can be nigh impossible to track down a problem.
With third party libraries, I've too-often found myself reading the code to figure something out, although that's a frustrating enough experience I generally wouldn't wish on other people.
This. Understand it all least to a level where you can make an effort vs risk/impact trade off. Ideally eliminate all low effort issues and mitigate high risk or high impact issues. But eliminating them all is not usually practical. And besides, most of the high impact/high effort application risk resides in design and not in warnings that come from logs or the compiler.
I use a Cepstrum (bought a kit + switches + keycaps and put it together; there's no soldering required, so it's quite easy). I never 3D printed tenting, so it's not quite perfect for normal typing, but for gaming it's fantastic - I don't think I can go back to non low-profile switches.
Your book is legendary and I have recommended it to a good number of students/programmers-in-learning. Haven't ever made it through (no matter how good the textbook, I'm still not a textbook person...) but immense respect for the time and dedication required to make such a brilliant and engaging learning material.
You're correct, there are a bunch of different ticket options. Not sure about how it's actually implemented, though.
Slightly tangential, but when I was in Montreal, I was blown away that you just purchase a ticket from a machine and you get a printed out ticket with an NFC chip inside. Not my favourite part of the trip (Montreal is beautiful!) but definitely a cool piece of technology to see being put to such a mundane use.
This is a super interesting anecdote, considering the name definitely confused me at the time - trying to learn web development with no context I did indeed think it was some kind of Mozilla-centric resource. All those times using w3schools over MDN are, in hindsight, a little sad aha.
