The biggest feature I miss from Google is the constellation of citc and the distributed build system that revolves around it. Most is described or implied by "Why Google stores billions of lines of code in a single repository" (2016) [1].
The key idea is that any human-written change only ever touches ~1-100 files, and there's never any need to store or maintain the entire source tree in your local persistence store. By only ever working on deltas, you can have highly efficient distributed and cached builds. This architecture imposes significant constraints: you must express your build graph in a modular way [2], you collocate your distributed FUSE backend and build system for speed, and all development is over the network. But it comes with many benefits at scale: near-perfect caching, instant "branch switching", fast builds even with deep and wide dep graphs, and excellent affected target determination so flakes/outages in one part of the codebase don't affect the rest of it.
I've worked in JS for around 12 years now and welcome this change of keeping JS as a scripting language but incrementally retiring it for performance-intensive general-purpose applications.
To my eye, JavaScript has three applications:
* A GUI-building language: A language and ecosystem we use to build UIs, where code runs on the end user's machine, served over the Web or as desktop applications using a compatible API (e.g. Electron).
* A scripting language: An approachable high-level C-like language.
* A general purpose programming language: A server-side or developer machine-side programming language for computational tasks like linking dependencies, transpiling code, type checking, orchestrating tasks.
At the first it's unbeatable, and the ergonomics and ecosystem are phenomenal. This is why it "won" as a language to write even desktop apps like VSCode and Discord.
At the second, performance doesn't matter anyway, so making JS capable of this just makes it approachable for folks who learned the language for the GUI-building purpose.
It's at the third application that the fundamental limitations of JavaScript---the programming language---really show. These are things like the lack of true multithreading (technically possible with significant limitations around shared memory and messaging and high overhead with Web Workers), lack of low-level primitives to fine-tune performance, and the ease with which authors can accidentally write extremely slow code. So much of this (TypeScript compilation, NPM package resolution/linking, Webpack bundling) in the modern Web ecosystem is regrettably still done in mostly JS.
I hope the JS community rallies around one general-purpose language to offload these tasks to as well as a uniform shim layer like Ruby's C extensions so we don't end up with a chaotic mishmash of different technologies. If nothing else, it would be nice to have a good excuse to write not-JS every once in a while!
I worked on the vendor (not auditor) side of accessibility audits, which have similar structural issues as security reports. The amount of latitude individual vendors have in shaping the scope of testing, setting cadence/private review phases, and picking auditors in the first place is stunning, and even though there are public standards (VPAT/WCAG/Section 508/EN 301 549), these degrees of freedom made reports completely incomparable across even vendors with the same commodity software products. Downstream from us, 90% of customers didn't closely scrutinize the contents or quality of the report and just needed it to exist.
The problem is the ultimate consumer[1] of these reports, legal and procurement agents at buying companies, themselves don't care about the actual quality of the report except insofar as it satisfies their own transitive legal/sales requirements, and it's turtles all the way down. This harms users/customers at the end of the day because they don't have time to scrutinize the details of each individual report or have any real power. If we care about the end goal (secure, accessible software), we need for the auditing firms to collaborate we the government, judiciary, and ancillary vendors to tighten standards to include random[2], uniform checks (same auditor, same methodology, multiple vendors at once).
In the US, OSHA designates NRTLs like UL to perform safety testing, which are required everywhere from workplace standards to insurance requirements. In comparison, at least for accessibility, merely having your vendor have any assessment report is likely enough CYA to withstand a legal challenge. I acknowledge the power of recent website lawsuits to use the broader ADA to raise the bar here, but ADA's "enforcement through private lawsuits" enforcement mechanism is spotty and I think won't result in enough structural improvement.
[1] - These reports also serve as PR/marketing, which is probably moreso the case with Mozilla VPN, but in most enterprise software where these assessments are taking place, the marketing side is very much a secondary goal compared to the individual legal/sales relationship that hinges on the report.
[2] - I think removing the opportunity for vendors to fine-tune scope or prepare or respond to concerns (at least until the next review cycle) is a big step in the right direction, but unfortunately, the legal climate is very much all-or-nothing and not good at nuance. Section 508 (I'm not personally familiar with PCI/SOX/etc. but suspect those are similar) is formally speaking "all or nothing" check all the boxes things, and in that climate, good random audits will basically be always-failing, and if you make too hard a standard that even reasonable vendors can't meet with an earnest effort, you'll end up constricting the market into a meta-game of who can hack the auditing process. See federal government procurement.
Even if content license holders don't require Netflix to go above and beyond, building sophisticated DRM is a moat against other streaming services. If Netflix can build a sophisticated VPN-detection service, copyright holders will be much less willing to license their content to upstarts who can't match its capabilities.
In the same vein, it can be rational behavior for a market leader who deals in private information (most online advertising companies) to advocate for consumer privacy protections. It "hurts" them, but if the resulting regulations are so onerous that only incumbent(s) can comply, it can restrict the competitive landscape and paradoxically be advantageous to the existing leaders.
There's no secret sauce. The typical aphorisms of software development are generally correct and apply here:
* internalize the cost of core changes and don't push them downstream unless you have a really good reason
* staff a core team to take care of high ROI horizontal efforts that have high fixed cost to do efficiently, e.g. TypeScript migration of a massive codebase
* be careful of what you take on
* complexity and code are costs and not end goals
Reading them is one thing but seeing the principles play out in detail amidst the mess of reality was illuminating for me. The author's blog[1] touches on these themes a bit more and I think are a good glimpse into their stewardship of the TS/JS codebase.
I worked on the infra team for a TypeScript-based product downstream of the author. His and his team's approach and writings influenced at a lot of my thinking about core development, and I'll always be grateful for having had the opportunity to learn from them by osmosis.
The success or failure with which any companies hires and retains folks like these is a mystery to me. As the evidence shows, Google (and I suspect almost any >100-person company) is far too much an amorphous glob/slime mold to even have a single coherent approach to this problem. But what are the successful strategies here? How important is it even to retain this kind of talent? How do we know how a company is even doing in this regard?
In my meager-in-comparison 6.5 years at Google, while I certainly saw many amazing SWEs come and many go, I'm far from knowing what the real trajectory was. But I can imagine that for many folks, the perceived trajectory would be a major motivating or demotivating factor to stay or to leave themselves.
The key idea is that any human-written change only ever touches ~1-100 files, and there's never any need to store or maintain the entire source tree in your local persistence store. By only ever working on deltas, you can have highly efficient distributed and cached builds. This architecture imposes significant constraints: you must express your build graph in a modular way [2], you collocate your distributed FUSE backend and build system for speed, and all development is over the network. But it comes with many benefits at scale: near-perfect caching, instant "branch switching", fast builds even with deep and wide dep graphs, and excellent affected target determination so flakes/outages in one part of the codebase don't affect the rest of it.
[1] - https://dl.acm.org/doi/pdf/10.1145/2854146 [2] - https://bazel.build/