Twenty years and one day ago it was New Year’s Eve, 1999, and tensions around the world were running high. For months, the country had been rushing toward a single event — the moment computers around the globe moved into the new millennium and updated their internal clocks from 12:59:99 on 12/31/99 to 01:00:00 on 1/1/00.

Those last two digits — 99 and 00 — were the crux of everyone’s worries. While human beings could assume the “00” represented 2000, there was a (substantiated) fear that many computers would interpret those digits as 1900. This simple programming shortcut, and all the problems it introduced, became known as the Y2K bug.

In retrospect, it’s easy to see how this problem came about. All computers have a finite amount of storage and resources, and in old computers, even more so. When we address our friends and family, we don’t call out their first, middle, and last names every single time we speak to them. Instead, we typically only use their first names, and frequently use nicknames or pronouns. The Y2K issue was a lot like that; in 01/01/85, everybody knew what the “85” stood for. And when calendars rolled over to the next year, computers understood that “85” was less than “86.” As the year 2000 approached, it became obvious that subtracting 99 from 00 was going to break a lot of programs.

One of the easiest visual examples of the problem (and non-threatening) appears in the Activision game Little Computer People. The game, which was released in the 1980s, introduced a “virtual person” living inside people’s computers. The person could be interacted with, but players also had to supply their little computer person with food, water, and positive attention. To keep track of progress, gamers are asked to enter the current date each time they start the game. The date assumes the year begins with “19,” which means if you were to play the game after 2000 you would enter “00,” at which point you would find one very irritated and starving little computer person.

Once people understood the Y2K problem, it was pretty easy to imagine problem scenarios. How could an ATM process a cash transaction on January 1, 1900, decades before a customer’s account had been activated? How would airports handle flights whose electronic flight plans were suddenly 100 years old? Everything from the electronics in our home to medical equipment was suddenly suspect, and imaginations ran wild.

On a scale of one to ten — ones being people who were absolutely convinced that nothing bad would happen and tens representing those who believed civilization might literally crumble — I, and many people I knew, were solid “fives.” I assumed that some programs and computer systems would most likely break or crash due to the Y2K bug, but that our most critical systems (ones used by financial institutions, medical equipment, and transportation) would be patched prior to the arrival of the new year. That being said, I certainly knew people on both ends of that sliding scale. A co-worker of mine — a smart guy, one I looked up to — told me in confidence he had buried food and weapons in a remote location “just in case.”

Part of the reason I was convinced all the Y2K bugs would be eradicated was because Susan and I both worked on fixing the problem. At work we had hundreds of servers running Novell 3.11, which was not Y2K-compliant. Because our remote offices were not yet connected to a wide area network, patching these servers meant putting people like me on planes and flying them around the country with floppy disks in our luggage. Our internal goal was to have all production servers patched by the end of 1998, but the discovery of additional servers in the spring of ’99 had me back in the air, patching more machines.

Back home, Susan was doing her part by upgrading several Access databases. During her team’s audit, Susan identified and personally rewrote seventeen separate databases. Today, this many changes to government databases would take years to coordinate and millions of dollars to execute. Back then, with time of the essence and far fewer IT employees to do the work, it was on people like my wife to identify and fix these types of problems.

For every real Y2K problem identified, a hundred of fake ones were thrust in front of the public. There were commercials, infomercials, video tapes, and loads of computer programs that promised to help people avoid the Y2K bug. 99% of these things were snake oil — fake products peddled by enterprising scam artists who preyed upon people’s fears. Yes, date rollover problems existed inside lots of computer code, but following moronic advice like powering off your computer (or your VCR, or your toaster) right before midnight just fueled the flames.

There is a misnomer today that the Y2K bug was a bunch of nonsense. This perception comes from the fact that when clocks rolled past midnight at the end of 1999, nothing happened. Part of this is because many problems were fixed. Part of this is because many problems were overblown, or simply made up.

If you want to hear more of my Y2K-related stories, I recorded an episode of You Don’t Know Flack full of them a few years ago. If you want to listen to a great podcast that covers everything about the Y2K bug, check out Dan Taberski’s terrific Surviving Y2K podcast. It’s fantastic.