So I fell down a rabbit hole the other day. As I was digging through a box in my storage unit, I ran across a very old flyer that I’ve held onto out of nostalgia all these years. On it, a grinning, sweater-clad William Shatner–not long after the first Star Trek movie but before Wrath of Khan–proclaimed the Commodore VIC-20 to be “The Wonder Computer of the 1980s.”

For those who aren’t old enough to remember (or who are and had better things to do with their time in the 80s), the VIC-20 was an early “home computer” with considerably less operating memory than you’d find in even the dumbest “smart watch” today. Still, for a couple of years, it was my whole world. I don’t remember exactly what I said or did to convince my parents to buy it for me (at a whopping price tag of $300), but whatever it was, I’m sure I’ve never been as persuasive about anything else in my entire life.

With the exception of a few hours spent puttering around with the Radio Shack computers at our school, that VIC-20 was largely how I taught myself to code, in an early programming language called BASIC. By today’s coding standards, BASIC was rather primitive, but it introduced me to the core principles of all programming languages, which I’ve carried with me to this day. Most of my free time was consumed by exploring variables and IF/THEN statements and FOR/NEXT loops, eagerly typing out hundreds of lines of code in a day as much to see what was possible as to create actual things like rudimentary games and applications.

As mentioned, the VIC-20 didn’t have much in the way of operating memory. Only about 5KB of RAM out of the box, as I recall. To put that into perspective, the laptop I’m writing this on now has 16GB–three million times as much. So for a coder, the memory the VIC-20 did have was a precious commodity. This meant that if you were trying to write any kind of decent program, you either had to “steal” memory from small pockets of it nestled between the machine code that controlled the computer’s core functionality or sometimes even tell your program to change those system settings directly. And to do this, you would use the same two commands, over and over–PEEK and POKE.

All things considered, PEEK was relatively passive and harmless. It allowed you to see what the current value of a memory cell was. By contrast, POKE was both incredibly empowering and tantalizingly dangerous, because it allowed you to change an existing value to something else. Do it right, and your game gets a cool new feature. But POKE the wrong memory cell, and your keyboard simply stops working. Or your monitor (in my case, an old black and white TV), fills up with gibberish. Either of which, along with a dozen other equally terrible outcomes, could mean an entire day’s lost work in the blink of an eye.

Decades later, even though I’ve long since grown beyond just programming, I find that the core of what I’ve done, not only as a web developer who sometimes codes but as a businessperson in general, still revolves around the dynamic embodied by those two simple, yet powerful commands.

In business, as in life, it’s important to PEEK, because we need to know both what’s already been done and what lies ahead. Leaping without looking, without “measuring twice,” as the saying goes, can mean wasted effort, wasted time, and wasted resources.

Yet it’s equally important to not be so afraid of a bad outcome that we don’t POKE when the time is right. After all, inertia can be a worse outcome than failure, and much has been written about the concept of “failing forward”–learning from unexpected or undesirable results. Do your homework, yes, certainly. Know your business, avail yourself of analytics, ask all the right questions. But ultimately, unless you’re willing to act, to risk everything going wrong, you won’t ever move forward and do something great.

As a coding method, PEEK and POKE have long since become antiquated. Today’s programmers have more than enough memory on hand to do all kinds of amazing things that could barely have been imagined in the 80s. But as a concept, PEEK and POKE live on, at least for me. They are two sides of a coin that I find myself flipping around in my head on a daily basis. You can just as easily call them Examination and Execution. Or maybe Analysis and Action. But whatever you call them, it’s clear that in any kind of business, or even life in general, one doesn’t make sense without the other.