Call of Cthulhu, Pathfinder, Harnmaster (my personal favorite--too bad it had such a shitty IP fight/divergence), Warhammer, Amber, Cyberpunk, and hundreds/thousands more. People in this space are incredibly creative.
There are a lot of people who advocate "clean code" principles without ever having read or knowing about Uncle Bob, because those "enterprise java dev like 10 years ago" folks sort of seeped into the industry.
It's the same thing with TDD zealots. Or any other fad driven development paradigm, which our industry is filled with.
Like everything else in the software industry the context does matter: at larger scales small gains in performance translate to large savings in costs (infrastructure, maintenance, etc.).
Also, "clean code" (as in from the "Clean Code" book) is generally not good advice for most programs anyway. Not only does it eat performance, it's not all that great for building maintainable, extensible systems.
Smart phones didn’t change anything here: 99% of their users didn’t care about the “open” nature of desktops before they were a thing, too. A vanishingly small percentage of computer users care about tinkering and openness. It’s been decades since tinkerers and hackers were the majority of computer users.
That is the case in the vast majority of tech companies, though. They (almost) all have something like a "regional adjustment", "location based" or other classification for salaries in different areas. Some are more extreme than others. The company I work for (it's a relatively well-known tech company) certainly has it, and I know Google and other FAANGs do, too.
In theory TDD drives the interface by ensuring the units under test do what they’re intended (implementation), and that each and every unit is “testable” (interface).
TDD doesn’t really care about “clean” interfaces, only that units of work (functions, methods) are “testable”.
I’d argue this actually creates friction for designing clean interfaces, because in order to satisfy the “testability” requirement one is often forced to make poor (in terms of readability, maintainability, and efficiency) design choices.
One of the theses of TDD is that the tests guide the design and implementation of an under specified (e.g. unknown) problem, given the requirements regarding the outcomes and a complete enough set of test cases. “Theoretically” one should be able to develop a correct solver without knowing how it works by iterative improvements using TDD. It might not be of good quality, but it should work.
Possibly, but my experience is that front-end dev specialists tend to over-complicate things (usually so they can tinker with some new javascript flavored garbage).
No, I just would have to think really hard to recall a front end specialist who didn’t get bogged down in fad chasing or wrote code better than a backend dev half-assing it.
> I don't know why full stack webdevs are paid so poorly.
In my experience it’s because they either don’t really know any of the stack well enough to do more than implement someone else’s design, or else they don’t know most of the stack well enough to do even that without very poor, confusing implementations.
I’ll take a backend person and a backend person willing to do front end work before a full stack “dev” any day of the week. And I’d take the full stack dev before a front end one.
The Bay Area is bad even by American standards. But the places I've been in America do tend to be rather shabby in comparison to places I've visited abroad, in general.