Hey folks, welcome to The Imposters Club, the podcast for misfits in tech. You know who you are? Who am I? I'm your host, Teddy Kim. I'm a director of software engineering at a SaaS startup, here in Minneapolis. And today, I want to talk about the latticework of mental models. Latticework, whoa, I know, it's a mouthful. Let's take a step back. You've probably heard of Berkshire Hathaway, the investment vehicle that has returned around 2,000,000% of its initial value. Well, one of the dudes behind Berkshire Hathaway's success as an investor named Charlie Munger. Munger is kind of a smart guy. He loves to learn, and over the years, he's accumulated mental models from numerous problem domains, including physics, economics, and philosophy. Munger himself attributes Berkshire Hathaway's success to his continual thirst for knowledge. So here's the thing. When Munger makes investment choices, he's not thinking about problems the same way other people do. He draws on a so-called latticework of mental models that he built up over years and years of deliberate learning. That latticework is part of Berkshire Hathaway's competitive advantage and considering that 2,000,000% return, I'd say it's a pretty big advantage.
Now, Munger isn't an oddball, many luminaries, including Bill Gates and Barack Obama, have attributed their success to the practice of deliberate learning. As a matter of fact, continual learning and success are so tightly linked that the language has become codified as the so-called five-hour rule. The five-hour rule says that the secret to success is to carve out one hour per weekday to read, think and experiment. The question is, why does deliberate learning give you an advantage? How precisely does it contribute to your success? In practical and tangible terms, why should you invest in a latticework of mental models? Listen, everyone I know who quit tech could not evolve past this stage.
Well, the glib answer is that the investment pays off because you will be better at your job. Early in your career, when you get stuck, you have to solve problems through deduction, which is a long, tedious process of logical analysis based on facts and direct observation. Deduction works, but it's grueling and time-consuming. That's why it takes weeks for an early career engineer to do the same task that a senior engineer can do in minutes.
The other way to solve engineering problems is inference, you get to the same destination as you would through deduction, but you get there faster because you're reasoning to a conclusion by finding connections between things you already know. In other words, the inference is a mental leap. Let's take a look at a simple example of inference. In my first comp psych class, we learned how to write bubble sorts, The bubble sort gets its name from the way items bubble to the top of a list. You don't need to know anything about code to be able to visualize bubbles rising to the surface. If you've ever seen a bubble, you get the gist of the bubble sort. So that's how inference works. It gives you a mental shortcut that you already paid for with prior knowledge. That's pretty sweet.
Well, that example is kind of trivial. So let's take a look at something more meaty. Maybe you've heard of the circuit breaker pattern, if you haven't, it's just a way to prevent failure load in a software system by abandoning a transaction that's likely to fail. Years ago, I implemented the circuit breaker pattern using a library called Hystrix. Now under the covers, this library is pretty complex. It does some really nifty things with threading that would have taken me a very long time to figure out, but I didn't have to figure it out. If you know basic electronics, you get the gist of how a software circuit breaker works. The details of this specific implementation are cognitive load that would just slow me down. Now that's a key point and I want to dry it out. When you have a latticework of mental models, knowledge from one problem domain allows you to make a mental leap in another problem domain. Sure, you could have gotten there through deduction, but the time and cost involved would be enormous.
So remember this: deduction plods, inference leaps. You want to leap. If you have an opportunity professionally to go faster, further with less effort, take it. So now I want to tie this all up in a bow, there are two parts first, this is for all of you early career techies out there. When you're struggling with uptake on a new project, or stack or language, or whatever, it doesn't mean you're stupid. You're probably reasoning through deduction, which is inherently slow, tedious, and stressful. But over time, you're going to accumulate mental models that will fuel your inference engine. So don't give up. As you start to solve problems using inference, it will feel like you found wings, you will not believe how effective you can be. You can speed up the process of your program of deliberate learning along the lines of a five-hour rule. I do it, the best engineers I know do it. You should do it too.
Okay, what about the techies who've been around the block a few times? Well, then you have another problem to deal with. Yes, your experience has given you a lot of mental models, but you also have accumulated biases. It's awesome when your bias prevents you from getting burned or making a mistake. But you know, some risks are worth taking. How do you know that your bias isn't preventing you from capitalizing on an opportunity or from learning something that you're going to need to know? If you can't check your bias, your latticework of mental models could turn into a web that holds you back. And before you know it, you'll be left behind. The way to avoid this trap is to run deliberate experiments to pressure test what you think you know, more on that later. The moral of the story is tech is knowledge work, there is no place for intellectual laziness so whether you plod or leap, always be learning.
I'm hiring software engineers! Check out the jobs page to see my open positions.