When IT folks say devs don’t know about hardware, they’re usually talking about the forest-level overview in my experience. Stuff like how the software being developed integrates into an existing environment and how to optimize code to fit within the bounds of reality–it may be practical to dump a database directly into memory when it’s a 500 MB testing dataset on your local workstation, but it’s insane to do that with a 500+ GB database in production environment. Similarly, a program may run fine when it’s using a NVMe SSD, but lots of environments even today still depend on arrays of traditional electromechanical hard drives because they offer the most capacity per dollar, and aren’t as prone to suddenly tombstoning when it dies like flash media. Suddenly, once the program is in production, it turns out that same program’s making a bunch of random I/O calls that could be optimized into a more sequential request or batched together into a single transaction, and now it runs like dogshit and drags down every other VM, container, or service sharing that array with it. That’s not accounting for the real dumb shit I’ve read about, like “dev hard coded their local IP address and it breaks in production because of NAT” or “program crashes because it doesn’t account for network latency.”

Game dev is unique because you’re explicitly targeting a single known platform (for consoles) or targeting for an extremely wide range of performance specs (for PC), and hitting an acceptable level of performance pre-release is (somewhat) mandatory, so this kind of mindfulness is drilled into devs much more heavily than business software dev is, especially in-house dev. Business development is almost entirely focused on “does it run without failing catastrophically” and almost everything else–performance, security, cleanliness, resource optimization–is given bare lip service at best.

Why make a better UI when it’ll probably introduce a slew of new bugs?

This bird definitely listens exclusively to metal bands from Nordic regions featuring an opera singer dressed like an ice queen backed by instruments that sound like they just got dragged through a tar pit

Theoretically it can happen. In practical terms, 99% of those cases are out of three things:

• A charade to get an angry customer to go away (pretending to fire an employee)

• The last straw in a series of incidents that add up to justify firing the employee (i.e. the employee has repeatedly made a mistake with no improvement over a long period of time)

• Misconduct egregious enough to warrant firing them on the spot (for example, the employee punches a customer, or shows up to a job site blackout drunk)

The remaining 1% of cases are truly shitty managers that are a nightmare to work for.

I worked graveyard shifts at a gas station for a year or two. My general experience beyond what other people have said–good commute, fucking with your social life, taking its toll on your body, all that–is that working graveyard shifts is lonely. I cannot understate how lonely it got; there were stretches of multiple hours where there were no customers at all, and it was just me and the long list of nightly chores I had to do (mopping floors, prepping food for breakfast rush, restocking shelves, etc., etc.). Not having any human contact at all fucks with your head something fierce, especially when you mix in sleep deprivation and your body rebelling against the normal sleep rhythm into the mix.

My advise is that if you’re going to be working night shift all alone, get into podcasts. Having a radio that I could use to listen to NPR was the main thing that kept me sane, because I could at least have a human voice to listen to and keep my mind somewhat engaged.