> My Linux laptop doesn't need to be optimized to the hilt the way Google's server farms do. Using the same scheduling algo or whatever in my laptop imposes real costs on my ability to understand my computer, without giving me the benefits Google gets from the algo.
Perhaps I don't fully understand what you're arguing. But here's a scenario, involving a hypothetical developer using similar logic, that often makes me worry. Suppose a developer reasons that the GUI for their application doesn't need to have all of the complexity of, say, a web rendering engine. So they develop their own GUI toolkit that meets their needs and aesthetic. This toolkit lacks some features that are important to some users, but not to this developer, such as accessibility with a screen reader. An application developed using this toolkit becomes popular, and companies start integrating it into their workflows, perhaps even requiring other companies that they work with to use it. Oops, now these companies can't hire an otherwise qualified blind person, or perhaps a formerly productive blind person loses their job [1]. If the original developer had accepted the current division of labor inherent in building high atop the web stack, and yes, the complexity and bloat that come with it, their application might have been fully accessible without them having to deeply understand accessibility.
Yeah, that's a really good example. In general, accessibility and internationalization seem like really good reasons to specialize. We can't all know all possible languages.
It’s not about specialization, though. It’s about getting those benefits from standard and existing tooling. You don’t need to be an expert in accessibility to build accessible software (though it helps of course). But you do need to build accessibility support, which is a lot more work when you do it from scratch.
The longer I work in the industry the more I realize the cost of “doing it from scratch”. If you ask a brand new software engineer to estimate the time for a project, they’ll basically give you an estimate for a prototype. A slightly more experienced engineer will include time to get through code review and maybe shake out the egregious bugs. A more advanced one will remember to cost for tests. I have found you have to get a pretty senior engineer if you want them to accurately account for things like telemetry and logging, deployment, live site management, accessibility, localization, etc.
I’ve seen engineers build a “simple” system and then spend 4x as long as they planned to make it actually supportable because they “didn’t need” the existing tooling. So they rewrote it all but worse.
Perhaps I don't fully understand what you're arguing. But here's a scenario, involving a hypothetical developer using similar logic, that often makes me worry. Suppose a developer reasons that the GUI for their application doesn't need to have all of the complexity of, say, a web rendering engine. So they develop their own GUI toolkit that meets their needs and aesthetic. This toolkit lacks some features that are important to some users, but not to this developer, such as accessibility with a screen reader. An application developed using this toolkit becomes popular, and companies start integrating it into their workflows, perhaps even requiring other companies that they work with to use it. Oops, now these companies can't hire an otherwise qualified blind person, or perhaps a formerly productive blind person loses their job [1]. If the original developer had accepted the current division of labor inherent in building high atop the web stack, and yes, the complexity and bloat that come with it, their application might have been fully accessible without them having to deeply understand accessibility.
[1]: This actually happened, though I'm not sure why the application was inaccessible. https://blindaccessjournal.com/2006/02/my-job-lost-due-to-in... https://blindaccessjournal.com/2006/02/torn-from-the-collect... https://blindaccessjournal.com/2006/02/the-cold-equations/