The latency one hits hard, as someone approaching this from the other side who came up through Ops and learned software development over time. So much software

The latency one hits hard, as someone approaching this from the other side who came up through Ops and learned software development over time. So much software I've had to support was written with the assumption of flawless network connectivity. No latency, no dropped packets, no fluctuation in response time. If there was any disruption or a call didn't return within a very short timeout, the app just blocked and eventually crashed. Any sort of network maintenance was a huge problem because a couple seconds of spanning tree reconverging or whatever meant a significant outage until all the applications recovered. This was of course always the network's/ops' fault, using patterns and libraries that have been around for over a decade to handle the inherently unreliable nature of computer networks was never on the table. I've seen some replies that this is basic stuff everyone should know, but the fact is, people don't. Even Senior or Principal engineers (depending on the company). You can get very far in software engineering without understanding anything outside the bubble of your domain. Hell this is basically why the field of SRE exists, because a lot of developers do not know how to write reliable software that works in the real world, not just in a perfect test environment. If you've somehow worked your entire career surrounded by engineers who have even an entry level understanding of how networks function, you're the outlier. More often I've found people invent their own bizarre mental model of what's happening that only has the vaguest grounding in reality. And honestly that's ok much of the time. Everyone can't be an expert in everything. Just have some grace about it. Don't pull a Dunning-Kruger and assume because you are a fabulous Java developer you are automatically an expert in every technical field. Most of us aren't.