Elon Musk is an idiot when it comes to code
(That's a more provocative title than I'd normally go with, but I couldn't think of a better one.)
One thing that seems to be a trend at software-related organizations that Elon Musk comes into contact with is people being asked to bring him (or his high-level minions) their code to justify their jobs. The idea seems to be that the people who write the best code are the best people to keep around. That's very much not (always) true.
I've been in the software industry for over a decade. I've been lucky enough to spend most of that time working at a large corporation with very good developers. However, over the years, there are two traps related to "code quality" that I've seen time and time again.
First is that "good code" isn't a thing that exists. Code is not a "thing" at all in the traditional sense. Code is a system or tool for solving a problem. I've had coworkers who are brilliant and write excellent code that executes quickly and consistently and is perfect for solving a problem that isn't the one we need to solve. Sometimes this is because they misunderstand the problem; sometimes it's because (as best as I can tell) the problem we're working on isn't "hard" enough for them, and so they write code that's good for a much more difficult case but is actually suboptimal in performance for the case we're dealing with. In both situations the code itself, viewed in a vacuum, can look really good. And if you ask them about it and ask them to justify it, and aren’t independently involved with the actual problem, they can talk it up really well because it is legitimately a great solution. However, although it's nice to work with people who are great at solving problems, I'd prefer to work with people who are good at solving the problems that we need to solve. (I don’t think this is usually a permanent problem - both misunderstanding and overcomplicating can be improved with practice - but if there are no pragmatic programmers available to set a better example, it won’t change.)
Second is best summed up in the saying, "perfect is the enemy of good". Obviously perfection is ideal in the abstract (that’s pretty much its definition), but if the choice is between code that's perfect and takes a year to write and code that's "good enough" and can be done in a week or a month, the "good enough" code is almost always going to be the better choice. Now, there are certainly cases where code needs to be perfect, generally tied to how "deep in the stack" it is. An OS kernel should be perfection in every byte; the client-side Javascript in a website can be the jankiest mess in the world and as long as it functions okay most of the time that's good enough, even if it's inefficient and buggy when edge cases arise. Being able to decide where on this spectrum a given piece of software falls is a skill that’s important for successful product delivery but not at all taught in university computer science curricula (or at least, it wasn’t 15 years ago when I was in college, and based on the younger folks I’ve worked with it still seems to be missing). (There’s a longer debate to be had on the vast differences between “computer science” and “software development”, and where academic programs should focus, but that’s for a different day.)
An obvious disclaimer: None of that is meant to say that hacky code is better than cleanly-written code in some sort of abstract sense. If everything else is equal, obviously cleaner, more performant code is preferred. However, the overall software development process is way more complex than just that and focusing too much on code in a vacuum generally doesn’t end well.