Upgrade your brain virtual machine

All of our brains use models to experience everyday life. An easy example is seeing the egg splat on the floor in your head right as it rolls off the table which somehow invokes the physics collider simulator you have going on up there. Everyone we interact with has the person base class with some properties about their gender, age, etc. which defines all the basic assumptions (and stereotypes we’ve picked up) about how the person will act. If I hit this person they’ll be angry of course. Then down through all the convoluted hierarchy of your brain’s person class there’s a person instance for each of the Jennifer’s, Steve’s, and Mike’s in your life. The more experience you have with the person the better your model is, all the way to the weird dialogs you have with these people in your head.

Now when you’re programming you have all sorts of these models going on too. Say you’re writing some gnarly C code with pointers tying themselves in knots. As you read each line of the code in your head you’ve got to have a model of the current state of all your memory, variables, and data structures that you’re updating as you parse each instruction. Just like the computer. Your brain is a virtual machine reading the code and executing it. As you might have noticed there are a few differences.

First and most importantly your virtual machine has a few bugs and missing features. Every time you write if(x = y) expecting one thing but finding out the real computer comes up with something different you’ve encountered a bug. Just like when your imaginary conversation never turns out the same in person. If you’re a disciplined developer you’ve filed a bug report about that one and got it fixed before it happens again. Developing new features for your brain VM happens slowly over time with experience and reading. Going through a new language tutorial is the equivalent of the first commit of a new emulator.

There are a few more components to your VM though, namely the hardware it runs on. You have CPU, RAM, hard drive, and even a network adapter to talk to people if we want to over extend the metaphor. Just as you’re always looking for the bottle neck in your code, you should always be looking for your weakest link and improving it. That might mean reading more code to improve your execution speed, doing memory drills so you can keep more in your working mental state, or talking to more people to find new algorithms you didn’t know about.

No one should be content with old hardware and unfixed bugs.