Except you would be wrong. Or at least not obviously right: safety critical code does all sorts of weird things in the interests of verifiability because it must be exactly right: it doesn't get "maintained", because once it's flight proven you do not change it without an entirely new verification process.

This also leads to interesting practices at times like favouring repeating code over writing separate functions to ensure the flow of reading doesn't jump around and instead always moves forward.

Is there any reason to suspect that Twitter's code will be of this terrible quality? If not, then again: what's the point of bringing random engineers in to take a look at code from an entirely unfamiliar domain?

You can probably read the code. Whether you can accurately assess it for the right set of tradeoffs is generally far harder.

At Twitter's scale the issues are far less about "this code smells funny" but how dozens of systems interact together. Ain't nobody gonna figure out problems by simply checking out a handful of repositories, and specially in a few hours / days.

> You're still missing the point. It isn't about knowing how rockets work or anything in particular. It's about being able to search for and recognize issues.

Still, the issues you'll likely encounter inside a car are very very different from the ones you'll see inside a historically grown distributed system serving millions of web, app and API requests. Auditing code is more than analyzing runtime/memory complexity.

Thats not to say it's impossible for Tesla engineers to audit. But I'd imagine it would take quite a bit of time to gather meaningful insight into the landscape and would hardly be an efficient use of the time of senior Tesla engineers.

I'm not missing the point. "Searching for and recognizing issues" is not somehow completely independent from the domain of the code in question. More importantly, different domains often have completely different primary concerns. E.g. web app engineering is often concerned with reducing cycle time because the technology means that you can instantly release updates. That's obviously very different from the concerns of launching a rocket, and I would expect them to have very different engineering practices.

In short, experience matters.

I implore you to consider that auditing code is more than just big-O analyses.

It's more polite than "webshit", but the overall comment isn't making the case that the more polite term should be used... I'd like it if people calling themselves web engineers held themselves to a higher standard. And were able to see that even if someone is a webshit now, they might have been something else in the past, and something else again in the future, tech is such a great career space in that it's not incredibly difficult to change what domains you're working on. Even apart from general expertise that allows an engineer to go and review arbitrary code (with full understanding, and immediately? No, but you can get started, and find common areas and boundaries, and find who the main contributors are and who isn't so important, and draw big black boxes over areas that really need a specific expert's look, and there's tons of automated tools that can help too e.g. security audit consulting firms can find issues in huge codebases quite fast), it would be surprising if Tesla didn't already have some former Twitter employees already who could contribute to this review if it makes sense to use them. Let alone former employees from other companies that have systems similar to Twitter's. It'd be surprising if all the engineers selected were just people who have never worked for another company besides Tesla.