If I see the SpaceX code, and it’s full of thousand line functions with a cognitive complexity of 200 I can confidently say it’s going to be hard to maintain.
Clearly it gets rockets into the sky, but something similar is true for all code that hasn’t failed catastrophically yet.
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?
>Bullshit. I'm a web engineer, and I wouldn't be competent to audit code that runs Space X's rockets, nor would anyone I know in my career space.
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.
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.
>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 repository, and specially in a few hours / days.
I don't know why you think someone would have to know about Twitter's specific implementation of distributed systems in order to inspect those systems for non-twitter-specfifc issues.
I mean, you can do a very general audit of things like “is there CI” or “do they use horribly unsafe serialization everywhere” but I don’t see anything beyond this without a huge amount of effort.
>I mean, you can do a very general audit of things like “is there CI” or “do they use horribly unsafe serialization everywhere” but I don’t see anything beyond this without a huge amount of effort.
Do we know what is or isn't being reviewed? Do we know how much effort is being applied in this process or if there's a defined upper and/or lower bound?
> 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.
>Still, the issues you'll likely encounter inside a car are very very different from the ones you'll see inside [...]
There are many systems involved in those cars, there's also many people working for those kind of companies who do not solely "work on cars."
>Auditing code is more than analyzing runtime/memory complexity.
I agree.
>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.
Take longer than if the team were comprised of Twitter staff or who are already familiar with Twitter's infrastructure and code base? Sure. But that's the case with just about any audit conducted by an outside entity.
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.
>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.
Is this based off real experience in the field of auditing?
I don't think Musk is looking for an itemized bug list. He's probably more interested in overall code quality, estimates on the level of technical debt, and a qualitative feel about the state of things. While a distributed systems person would have an easier go of that, I think most decently-well-rounded software developers would provide value there.
Also remember that Telsa runs their own distributed systems to support the connected features of their cars. Certainly that's not the same as Twitter, but it's definitely in the same ballpark.
You seem to have fooled literally every person replying to your post, then. Perhaps consider that your reactionary post was not quite as "rational" as you'd like to believe, or at least that you haven't yet said what you mean.
>You seem to have fooled literally every person replying to your post, then.
Fooled? No.
>Perhaps consider that your reactionary post was not quite as "rational" as you'd like to believe, or at least that you haven't yet said what you mean.
What part of any of my comments are reactionary? What have I said that I don't mean? I genuinely don't understand.
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.
