Leslie Lamport reveals that the concept of using state machines to build distributed systems was a key part of his seminal "Time, Clocks" paper. However, this practical idea was completely overshadowed by the more theoretical "happened-before" relation. He had to reread his own paper to confirm he wasn't "going crazy" when people claimed it wasn't there.

A key reason formal methods remained in academia is their fragility in development pipelines. A minor code change, like renaming a variable, can cause a previously fast-running proof to time out indefinitely in a CI/CD environment. Solving this "brittleness" is critical for industrial adoption.

When Leslie Lamport suggested mathematicians adopt a hierarchical structure for proofs, the reaction was not academic debate but pure anger. He speculates the hostility stemmed from a fear that such rigor would expose unstated assumptions and force them to write proofs detailed enough for a computer to verify, revealing flaws in their thinking.

The term "formal methods" isn't a single, complex technique but a range of mathematical approaches. Many developers already use them via simple tools like Java's type checker (weak guarantees, easy to use), while full functional correctness requires PhD-level interactive theorem provers (strong guarantees, high cost).

While the computational problem of finding a proof is intractable, the real-world bottleneck is the human process of defining the specification. Getting stakeholders to agree on what a property like "all data at rest is encrypted" truly means requires intense negotiation and is by far the most difficult part.

Lamport emphasizes the critical distinction between an algorithm and code. An algorithm is the abstract, high-level solution, while code is just one implementation. He argues that engineers often mistakenly jump directly to code, conflating core synchronization problems with irrelevant implementation details, which leads to flawed systems.

To ensure his critical work on fault tolerance was widely understood, Lamport created the "Byzantine Generals" narrative. He learned from Dijkstra's "Dining Philosophers" that a memorable story is key to an idea's popularity and adoption, even if the underlying problem is complex and highly technical.

A formal proof doesn't make a system "perfect"; it only answers the specific properties you asked it to prove. Thinking of it as a perfect query engine, a system can be proven against 5,000 properties, but a critical flaw might exist in the 5,001st property you never thought to ask about.

Lamport's Bakery Algorithm solved a major concurrency problem. Its most surprising feature was its ability to function correctly even if a process reads a garbage value while another is writing. This property was so counter-intuitive that his colleagues initially refused to believe the proof was correct.