Yeah The Who's hiring format isn't a perfect fit for how we have it structured. In general, engineering can hire remote first if there's a good fit, and we have local entities or EOR processes for every EU country (to the best of my understanding)
Going through the engineering job posts but they seem to be all in the US. I'm the main maintainer of a popular OSS project using WebAssembly and want to stay in this area (OSS, C, WASM etc.). Looking at "Staff Engineer - Edge Protocols" because of the good overlap with my latest experience. Is this available in Europe as well?
Space efficiency comes to mind as well on overall usability, can't stack anything above it (aside from storage shelves way above), kitchens are rarely big enough to store such a horizontal device, let alone in places where the $/m2 is high, like many city centers.
Also practical reasons, in horizontal config it's way harder to avoid my tomatoes getting squished by leftover casseroles, let alone having a small item roll around to the bottom never to be found again.
> Developing the SQL schema backing that UI is arguably something that is 100% deterministic and can have mathematical proofs established which prove its correctness one way or another.
Maybe I'm misinterpreting your point here, but the way you create the different models, compose the modules which will use them and represent the abstract entities and processes that execute when that UI is interacted with can be done in many ways, both well and very badly, depending on the measurements you take to evaluate it.
All the different terms to consider 'clean', 'maintainable', 'readable', etc. code, I consider to also be somewhat abstract to define in an art-type of way.
The reason I mention this is that the 'visual design' of the UI is not so much a software work as much as a UI/UX designer work. Bringing that design to life in an application using actual code and not a design tool is where the same principles I mentioned above come into play, even if the actual 'visual design' was completed by a different person which might not code, or the same dev.
I would argue that there is a very specific form of normalization that any problem domain should be modeled in - 3NF or BCNF. This is a universal idea because of how it allows for relational algebra to easily produce any higher-order functions over the dataset. Poorly-normalized data is where all of the code & SQL spaghetti originates. These forms of normalization can be specifically tested for and validated.
If you get a super clean domain model in 3NF, you can be assured that writing business logic on top of this will be a breeze. Getting relationships between domain types incorrect, or having facts on the wrong types, is how you get a vicious cycle complexity layering on top of itself as you try to compensate for bad foundations.
One thing that burns a lot of developers is the need for circular dependencies. You cannot say that circular dependencies are disallowed when trying to model the real world. An example in banking would be Accounts can have many Customers related to them, and Customers can have many Accounts related to them. Attempting to "choose sides" on this is folly. The most correct path is to create 3 collections - Customers, Accounts, and AccountCustomers (or CustomerAccounts). Getting this one thing correct can save you years of developer hours on the bigger projects.
If you are using something like .NET, you can abuse LINQ to produce any arbitrary projection you desire in a few lines of code. If you want your business people to have a hand, you can expose SQL as a scripting language against your properly-modeled domain. There are so many good reasons to slow down and pay attention to what you are calling things (and what boxes you put the things in).
To put it more briefly - The argument I am essentially trying to make above is that there is actually one truly correct way to model a specific problem domain and you can test for many degrees of that correctness. I will admit it is never absolute, but I feel it gets damn close if you are thorough in applying single responsibility principle to the logical business facts.
