If you want to learn how to be like Elon Musk, don’t read the book that Elon Musk wrote—read the books that Elon Musk read. I always tell my teams that if you want to be able to do what I can do then you should learn from the people I learn from.
I’m good, but I’ve never invented a programming language used by thousands of people every day. There are smarter people out there and most of my ideas either came directly from them or were some strange amalgamation of ideas from two or more of them.
More importantly, the rest of the posts on this site will assume that you are familiar with the ideas from all of these talks. Rich Hickey will teach you what “complect” means and Jonathan Blow will explain why “optimizations are usually bad”—so I won’t have to.
On my teams we usually watch one of these talks every Friday during lunch. We have some discussion afterwards and then we spend the week looking at how the ideas from these talks can translate to the thing you’re working on right now.
I recommend you watch the talks in order:
Boundaries—Gary Bernhardt
A fantastic introduction to Functional Programming for people who come from an Object-Oriented background. Contrasts Functional vs. Imperative styles of design with an emphasis on Test Driven Development.
Integration Tests Are A Scam—J. B. Rainsberger
You are not testing if your software works, you are testing if your design is good. Mathematical proof that you should stop writing integration tests.
Quieting The Lizard Brain—Seth Godin
Thrash at the beginning, it’s cheap. What you do for a living is not be creative, everyone is creative. What you do for a living is ship. That is the discipline of what a creative artist does.
Programming aesthetics learned from making independent games—Jonathan Blow
How to 10x more productive by outputting a hundred thousand lines of high quality code that never crashes and never leaks memory by basically doing the opposite of what everyone else is doing.
Kill “Microservices” before it’s too late—Chad Fowler
How to build systems that can last for five years or longer. Make the system easier to change by never changing any of its components. Never “refactor” the system again and still replace all the code.
Simple Made Easy—Rich Hickey
Software is hard because of Complexity. The opposite of Complex is Simple. People confuse Simple with Easy. We’re infatuated with Easy. We’re not good at understanding Complexity. You have to understand something to make changes to it.
This is my all time favorite software talk.
Bonus:Out of the Tar Pit—Ben Mosley & Peter Marks
Not a talk, but a 64-page paper that served as a great deal of the inspiration for Rich Hickey’s Simple Made Easy. Includes the most concise description of why software is hard and proposes remedies. The paper is so long because it includes an extensive description of how their ideas might be applied to the design a realistic application.
The first time I got to the end of this list I told my team, “That’s all I got. It took me ten years to assemble that list of talks. I don’t know what I’m going to show you guys next week.” To my surprise they told me they wanted to start the same list from the beginning. It turns out these talks have such high information density that no one ever gets all of it in one sitting. Now that they had spent some time thinking about these ideas and trying to apply them to their daily work, rewatching the same talks a second time helped solidify and deepen their understanding.