Lots of interesting nuggets in this. Stuff I already knew (like Coka-Cola isn't a beverage company, they're a psychology company), and stuff worth taking away (it pays to be #1, #2, or out; and in human affairs what wins are incentives). But mostly a lot of just admitting the world is a magical place full of wild contradictions with no sure way to tell which is applicable to some new context if you have to put your money where your mouth is.
I really like the idea of stealing the big ideas from a variety of fields and working hard at layering them into a lattice of ideas you can leverage. That's actually what lead me to these talks. Probably wouldn't have read it otherwise. It's what I've been trying to do for at least the last decade. Obviously I'm not a securities trader like Munger, but it still proves valuable in software development.
He's also right about decision trees, though these days you'd probably want at least a random forest. The bigger thing is statistics and how it's become too big to ignore. Learning how to properly build (or train as the kids call it) models on data, especially the instinct to collect such data is now a core skill you should know. You'll have a hard time keeping up with anyone who knows how to routinely do this if you remain math illiterate. Statistics especially, unlike geometry, is a branch of math our feeble human brains are really bad at intuiting. It's why there are so many gambling startups right now. It pays to run the house.
A decent overview of concepts from the financial software industry. I mean, clearly written from the point of view of someone working with cryptocurrencies and payment processing, but not in a way that makes it a bad source of information. Honestly some great intermediate topics in there like some of the most common account types, red flags to auditors, and a decent list of some of the major payment networks if you want to dig deeper. Also a bunch of wise words about how trying to integrate against anyone else handling money is a crazy train you better be ready to handle (including some decent strategies).
If you still haven't learned that what a human sees and what a computer stores not only can be different, but often should be, money's a good introductory lesson. Only use floating point for measures, never counts. That is, numbers that have a degree of precision to them. Think like measuring a distance. Is it exactly 3 units, or is it 3.0000...something? They are not to be trusted for exact counts. Just like you don't have 2.00 kids, you don't have $2.00. You have 200 cents and their owners know each by name.
On the testing angle, I'll say I'm at the point that unit tests are dead to me. If you're not fuzzing your code, your tests are performative.
Performance continues to dominate (duh). Why do you care about performance today? AI? No, performance is always important. Blame it on whatever's hot if it helps. Users care about performance because time is money for you and your customers. It's all about convenience. Customers love convenience. Too much if we're being honest. Cost equal, they'll choose the more convenient option every time. Many will choose it even if it costs more if you market it using time-loss aversion. Better still, fast also wins on the cost front. Fast software means you can run more of it on less hardware. Less hardware, less power, lower COGS. But wait, there's more! Faster software encourages doing more with it. If it takes a couple milliseconds to do something, I can do a whole heck of a lot of it in a few minutes. More buy-in, more self-service, more use cases unlocked.
I will emphasise that the minor efficiency wasting patterns stacking up is the dominant problem. It's not slow spots, not a cutting edge algorithm you could have used. It's everyone, everywhere, doing the same slow version out of habit when a faster version exists. It's the problem because fixing it is fighting entropy. As your company scales, the problem gets worse and worse. Fifty nanos wasted on every instance of a given operation, implemented in thousands of places, executed millions of times for large datasets (a.k.a. your most valuable customers). The requirements to fix it is measured in dev years.
Some languages do have syntactic problems that cause performance issues. Other languages have non-optimizing compilers or interpreters. Many have standard libraries with lots of suboptimal functions and data structures. But for the most part, the dominant factor in the performance reputation of a language is cultural, not intrinsic. It's created through a combination of the tools, libraries, and references the community contributes to and learns from. What they consider "idiomatic" or "best practice" code. It's why people think React is slow and Rust is fast even though tons of slow Rust code has been written and plenty of fast React apps exist. It's the people, not the tool. Learn how to use your tools better. Advocate for better tool use.
My only secret to productivity: offload everything from my brain so it doesn't have to remember anything. Use habits, notes, calendars, lists, creative constraints, deadlines. Externalize the work your brain is bad at.
I use paper for most of it. It's on my desk and fridge. I can't forget about it that way. Paper lets me spread things out, reorder them, stack them in piles. This trivially encoding more information through spatial memory than any file system. No software needed. I have a digital calendar, but every month I fill out a large paper one that sits on my fridge. I cross off days. I see everything at a glance. I track habits and chores.
The same logic applies to meetings. I now create notes ahead of time so I never forget to bring up the topics I want to cover in my brief window with someone. Think of something else to discuss? Add it to their card. Each note has the person's name and the things I want to talk about. If we don't get to something, it carries over. No brain power required.
I keep notes for projects, for ideas, inline in my code for things I want to improve later. I no longer bother remembering any of it. I write it down and review it as a habit—usually at the start and end of each day. That's when I prune. The secret to a todo list is copying it fresh every morning and throwing away yesterday's. Do not keep things around. You either do them or stop copying them. A backlog is a lie you tell yourself to avoid the hard work of saying no.
I apply the same system to cooking. I love cooking but hate deciding what to make. It takes me thirty minutes to brainstorm meals whether I'm picking one or a dozen so I build a list. Meal after meal goes on it until I have enough for a grocery run. I fill the back with ingredients to buy and cross them off in the store. The remaining list becomes my menu until it's empty. What's for dinner? Check what's left. It's easy to pick when there are two or three options. I mark meals as short or long depending on perishables so that fresh vegetables go first, then the dishes that keep. I shop roughly once a month.
Deadlines do more than force delivery. They create a rhythm of tension and release. As one approaches, I go into crunch: cutting scope, accepting tradeoffs, shipping. Afterward I relax, unwind, think creatively again. Too many deadlines too close together is death, but a good cadence ebbs and flows like the tides.
I've kept a ledger of all my earnings and expenses for over a decade. I started it in college after discovering the ledger CLI. The file is 18,000 lines now, managed with a text editor and a handful of scripts I wrote myself. It taught me double-entry accounting. More importantly, it gave me clarity. I know exactly how much I need to retire. I know how long my savings last if I quit or get fired tomorrow. Someone once called that kind of cushion "fuck you money" — as in, "fuck you, I don't need to put up with this." And knowing I have that option really reframes my relationship to work. I don't need the job. I choose to work here.
These lessons are about design, not just game design. They're fundamental to human nature. Consider these in the context of your work. You'd be surprised just how much they hold up in other fields. Swap fun for value, swap audience for customers. It's all the same big interconnected lesson about making things for other people.
Fighting against human nature is a loosing battle.
Aesthetics matter.
Resonance is important.
Make use of piggybacking.
Don't confuse "interesting" with "fun".
Understand what emotion your game is trying to evoke.
Allow the player the ability to make the game personal.
The details are where the players fall in love with your game.
Allow your players to have a sense of ownership.
Leave room for the player to explore.
If everyone likes your game, but no one loves it, it will fail.
Don't design to prove you can do something.
Make the fun part also the correct strategy to win.
Don't be afraid to be blunt.
Design the component for the audience it's intended for.
Be more afraid of boring your players than challenging them.
You don't have to change much to change everything.
Restrictions breed creativity.
Your audience is good at recognizing problems and bad at solving them.
All the lessons connect.
Side note to remember from advertising: knowledge → familiarity → preference → quality.
If you want to see why Erlang is powerful without learning its syntax, this talk is for you. You'll also get an introduction to the challenges of running hardware in space. Great stuff throughout.
