I had that when workign with a lot of other Europeans. When I moved to a company where everyone was British I had to re-adapt, particularly because I'd become more direct after working with a lot of Germans.
The hydration breaks are a FIFA thing, we can't blame the US for that one. We're not really seeing the ads and half time crap and things as the international broadcasters don't show them.
Traditionally everyone had sash windows ("sliding windows") or casement windows ("swing open") made from wood. Nowadays sash windows are very expensive so almost everyone has casement windows, or even casement windows that look like sash windows, both constructed from UPVC. It's only in historic buildings people typically still install sash windows. I had to do that in my house because of it being a "conservation area" and it cost £14k for four timber double glazed sash windows! There are some UPVC sash windows now but they're pretty uncommon still.
In the UK people predominantly use debit cards but credit cards are widely available. Everyone gets a debit card with any current account (i.e. non-savings account). In March this year there were 2.3 billion debit card transactions vs 400 million credit card transactions according to this:
That's not really true at all though, even in very complex software it's pretty rare to have more than ~10 external dependencies in a C++ project. People tend to roll their own a lot more, partly because dependency management is a lot more painful and fragmented. Boost is effectively an extended standard library, as is abseil, but the language has got much better at incorporating back features since C++ 2011, but even so, the dependencies tend to be slow moving and fairly stable.
I worked in very technical engineering software company and they were super paranoid about their special sauce IP of a product that did analysis of a certain type of data, without being able to see that all the pieces of that special sauce were actually just functions from SciPy strung together and which you could look up in a textbook. Don't get me wrong, you need the right background to understand it and that's not trivial, but if you got someone from the right area you could replicate it pretty easily.
> You can defensively set shipped binaries as fallbacks in the event the application is running on a newer system that dropped critical functionality
Not if they're GPL licensed you can't. And that's a headache most commercial people do not want at all when trying to write software that's often for a marginal part of their audience anyway.
> If the author's vision of the future is correct, then competent software engineers are safe. Domain knowledge can be learnt much quicker than how to apply good engineering principles.
I think this is true in some things and less true in others.
It's a pretty high moat getting into stuff like simulation software because the people working on numerical methods overwhelmingly have PhDs and it's a mixed skill set. Domain expertise here requires you to know maths to a high level. Even mechanical engineers often struggle here; it's often applied mathematicians and physicists turned devs that work on this stuff.
I worked on a fairly gnarly signal processing thing a while back that required bringing together knowledge of physics and software and maths and I found explaining it to people was tricky as their eyes glazed over at some point because their knowledge typically only covered one part of those.
Coding up a decent performing basic 3D finite element solver from scratch in C++. Still needed to know what I was doing but it’s a non trivial problem.
I still couldn’t get it to do more advanced stuff.