Starbase Tour with Elon Musk [PART 1 // Summer 2021]

This series is said to eventually have three parts. Part one [0] and two (this submission) were filmed at the production site "Starbase" (Boca Chica village, Texas). The third and last part is going to be at the launch site, a few kilometers/miles further to the east, right next to the beach. Part three has not been released yet. Tim Dodd usually makes a good interview partner for Elon Musk because he is more knowledgable about rockets than most reporters and can ask way more interesting questions than they could. If you haven't seen the first part yet, I would recommend to start with it [0] instead of jumping right into this one. [0] Part 1: [this video] (53 minutes long!)

Here's a great complimentary nugget of wisdom Elon Musk shared on the tour he gave of Starbase recently that intersects with a closely related concept. 17:29 Possibly the most common error of a smart engineer is to optimize the thing that should not exist. And say, well, why would you do that? Well, everyone has been trained in high school and college that you gotta answer the question, convergent logic. So you can't tell a professor, "your question is dumb", or you will get a bad grade. You have to answer the question. So everyone is basically, without knowing it, they got like mental straight jacket on that is they'll work on optimizing the thing that should simply not exist. [this video]

Everyday Astronaut's walk and talk with Elon Musk where he attempts to explain his management process, starts at 13:30 of part 1: [this video] Here's a rough summary: 1. Make requirements less dumb. 2. Delete part or process steps. If you're not occasionally adding things back (he says 10%) (ideally in improved versions), you're not removing things often enough. 3. Simplify, optimize, solve. Everyone's trained to jump to this because the educational process requires you to answer a question as posed, when often the question is dumb and shouldn't be dealt with as-stated. 4. Accelerate process 5. Automate Those tend to blur together at the edges. I'm sure if he formalized this and wrote it down for mass consumption it'd be presented differently, but it's his current mental model. Process testing - remove unnecessary in-process testing after production line debugging is done. Obviously there are nuances, he's not saying to do no in-process testing, but rather to remove testing which was intended to reveal information once that's already been collected and addressed. He cautions about false positives from in-process testing, and notes most testing can be done end of line with acceptable results. Finally, it's important to understand the context. The part about part/step deletion in particular, when things get added back 10% of the time, is not appropriate for all development processes. That would have to be adjusted a the specific product and market objective.

If I had to choose between network television and YouTube, I would choose YouTube every day of the week and twice on Sunday. I mean, I enjoy Seinfeld too, but on the whole YouTube is both more entertaining and vastly more useful and educational than network television. Not because the content has the highest production values, but because the content matches my interests and needs. That's the true power of targeted advertising. It allows creators to focus on niches that can't be served by content produced for a mass audience. Even large 'niches' get dumbed down to the lowest common denominator for network television. Case in point: Here's Jay Leno interviewing Elon Musk about SpaceX Starship for network television [1] vs YouTuber Tim Dodd [2]. Leno's program is fine for people who don't follow space. For my niche Dodd is vastly better, but he can't draw a wide enough audience to make money on non-targeted ads like Leno can. And the thing is, everyone has their niches. There is no large population of people out there who are average in every way and need the network television version of everything. The average person doesn't exist. [1] Leno: [link] [2] Dodd: [this video]

Maybe I'm a particularly dull engineer, but I've taken several aspects of personal advice from what he has said in interviews (the especially technical ones, not the ones aimed at a mass audience where he repeats his standard canned speech) and found them useful for myself personally. Here's two examples I've found particularly insightful that shows he has some ability to talk about engineering details. This example where he talks about the choice of steel for Starship as opposed to any other metal, something that would be an otherwise unsual choice: [link] This example that I've personally incorporated into my own thinking where he talks about his "five step process" for engineering design refinement (watch at least until he starts talking about Tesla Model 3 battery stuff): [this video]

This short video clip quickly makes evident why SpaceX has become so dominant, now sending more than 90% of all global cargo to orbit every year. In short: Musk is operating from first principles, questioning everything from the ground up, willing to try things that others are unwilling to consider or have not even thought of before -- there are no sacred cows. The result is that SpaceX is leaving conventionally run competitors saddled with increasingly outdated, higher cost, less scalable systems and processes. Whenever I watch interviews of other CEOs of other space exploration companies (Boeing, Northrop Grumman, United Launch Allience, etc.) or CEOs of other satellite internet service providers (Viasat, Eutelsat OneWeb, Hughesnet, etc.), I come away with the sense they're so far behind they are not even properly competing against SpaceX. --- PS. If you enjoyed this video clip, you'll also want to watch Musk's tour of Starbase: [this video] [link]

I agree that validation is important (e.g. avoid optimising things which shouldn't exist [this video] ). It's all about bang-for-buck: a formal proof can give me lots of confidence about some aspect of a system, but might take a long time and have a maintenance burden; if that time and maintenance could give me more confidence when used to write masses of tests instead, then it's probably better to go with the tests. My go-to approach is property-based testing, since that can exercise edge-cases more effectively than hand-picked examples, whilst taking about the same amount of effort to write. A couple of things in favour of "proper" formal methods (in niche circumstances): - Sometimes the effort calculation tips in favour of a formal methods; e.g. reliably testing concurrent, distributed systems is notoriously hard, and might require even more effort than doing some proofs instead. - Proof objects themselves, and the act of writing them, can be useful for understanding a domain or system, and why certain things are/aren't true. This doesn't apply so much for "yes/no" solvers, like SAT/SMT/resolution/etc. but is often the case for "interactive" systems like Coq/Agda.

Here you have Dr. Daniel Rasky, a NASA Senior scientist talking about SpaceX and Elon. Daniel Rasky was involved in specific studies that were comparing operation of NASA and private companies. He also has first hand experience from working at SpaceX and with Elon. He is expert on advanced entry systems and thermal protection materials and he was for example involved in decision to select PICA as a heat shield for Dragon, and he explains how that went with Elon. [link] Here is Elon answering questions of National Academy of Science members about Starship. He explains in detail why he pushed the team towards steel and away from carbon fibers: [link] Here you have another direct conversation with Elon: [this video] Here is Elon discussing with Sundy Munro mass manufacturing and engineering. Sandy Munro is a veteran engineer from General Motors supplier and directly at Ford. Sandy Munro is now running a consultancy company that tear downs cars and suggests improvements to wide range of clients from the car industry. [link]

>You're being repeatedly downvoted throughout this thread FYI, there's more upvotes than downvotes in total. The most noted visible one was at ~5 then magically dropped to -1. Even though it obviously has merit and hosts a lot of conversation below it, which makes the downvotes a bit suspect. >narrow reading of peoples comments. This seems like that KGB tactic of turning one's argument on its head. What is actually happening is I'm putting way more effort to answering to ill-informed comments because I just don't like watching obvious lies, even if comforting to some, on the web. This is more draining than giving I can say ... >The actual comment you originally replied t.... -Nnope. You picked the subheading right after the main lie: "Musk doesn't build any of that, he's just a source of cash, like a bank crossed with a toddler." >From your own links etc etc It takes trying to read what you've read negatively. For a more illuminating view, there's actually a part that partially answers this in the provided video: [this video] (timestamped link). It's his own stake. You're claiming it's 100% confirmation bias that Elon is given any credit. Let me _try_ to present another take: People remember conflict way better than success. So if it hurts them 20% of the time but succeeds 80% of the time, people WILL remember when it bit them in the ass. Because in that specific instance, everyone was against Elon, and it failed. But in the long the general practice has worked wonders. And obviou