The Worst Typo I Ever Made

The “onosecond” is the second after making a terrible mistake. The second, when you realize what you just did and that there is nothing you can do about it, the second, when all the now inevitable consequences run through your mind. It's the second after sending a text message to the wrong person, after deleting the wrong file, after revealing the secret you thought you already knew. The “onosecond” is that breathless moment when all you can do is say “oh, no.” This is the story of the

worst

typo

I have

ever

made

. I was maybe 18 or 19 years old and I was in charge of converting an old website into a new, faster platform.

Half a dozen volunteers spent days transferring all the articles, copying them from the old site, updating them, and then saving them in their new place. It had been a great effort, but

ever

ything was practically fixed now. There was one thing I had to do: search and replace across all those pages of content. And I was

made

aware of the mistake people often make there: It's called a clbuttic mistake, where someone wants to censor the word "ass" and search and replace gets a little more enthusiastic than they thought. This problem: much simpler. The volunteers had just written the articles in plain text and I needed to add simple formatting.

Anywhere there were three dashes, I just needed to replace them with a label for a horizontal line. There is no way search and replace can go wrong. Good? This was the mid-2000s, so the site was nothing fancy - it was a standard SQL database. SQL is a structured query language: it is an international standard for sending commands to basic databases and is still used today. I hadn't bothered to set up any tools to help me. I was the only one working on the site, so I was just using the command line. Which meant that with a single statement I could change every record in the active database, every page, at a time.

Working on a live database is a bit like working with a live electrical wire. Sure, it's physically possible, it would speed things up, and there are very, very rare occasions where it might be the only option. But in general, if you are working on mains electricity, you should turn it off first. And if you're working on a database, you're not working on the live version. I was working on the live version. Because she was young, and careless, and besides, the hard part was over, right? After all that conversion work, which was a lot of work, I just had to issue a few final commands.

Update the list of items and set the content field to itself, just have the dashes replaced with the label. So I typed the command, hit Enter, and... Oh, no. Reading 5,000 pages, searching and replacing all that text, and putting it all back into the database should have taken a little more than a hundredth of a second. He still didn't know what had happened, but he knew something had gone wrong. Hold that thought. In the history of computing, the undo command was invented independently several times. In the 1970s, programmers at the Xerox PARC research center were the first to map it to that easy-access keyboard shortcut Ctrl-Z.

Or "Zed." His work there later inspired many features that ended up in Apple computers. And most of the time, undo is linear: there's an ordered list of commands we've issued, and we can undo (or redo) our way back and forth through that list. The most basic way to implement this is to store the exact state of the document after each command, or even after each key press, and simply return to that. It consumes a lot of memory and there are many ways to optimize it, but it will work. It's also an easy mental model for users to navigate: simply move back and forth in time.

But if you go back in time and then make a small change, you won't be able to retrace your path forward. Like a time traveler in science fiction, you have broken the future. So if you want to recover something you deleted and bring it with you, you'll have to be very careful not to accidentally press the wrong key while it's there again. Now, a lot of people have tried creating "undo trees": if you go back and change history, it just creates a new timeline and you can move through the timelines as you like. There are some text editors that will do that for you and even display all the branches.

But it's a tricky thing to keep in mind and has never found widespread appeal. There are source control systems that work the same way, like Git: every time you save your file and "commit" it, that copy is available forever. Multiple people can work on files at the same time, make changes to different "branches" and everything is merged back together afterwards. It is incredibly useful for any software development project. But trying to do that with every keystroke, rather than every saved version of a file, is too much. Saving keystrokes works in memory, which is fast; saving files works to disk which is comparatively slow.

Microsoft Word used to have a quick save feature, where if you updated some things in the document, it didn't actually save everything again: it just added those changes to the end, so it didn't save them. You have to wait five or ten seconds every time you press Control-S to save on an old '90s computer. It turned out that leaving things in files that users thought they had deleted was a huge privacy and security risk, and that it was deprecated in 2003. That model - fast undo for live jobs in memory and saving to slower disk when you finished a task - is still used in many places... although it's slowly changing.

If you type text in Google Docs or other cloud-based platforms, your keystrokes are constantly saved and synchronized. You never actually need to press "save." Which means that depending on the application you're working on, you'll have to change your mental model of how your work is saved. And sometimes you don't want to save every keystroke and command. If you got frustrated with your boss, wrote some... colorful comments in your code, and then deleted them, they probably shouldn't be stored forever. Or maybe you pasted a password, security key, or credit card number into the wrong file and you definitely don't want Derek the intern to have access to that forever.

Anyway: the thing is, there are all kinds of systems, big and small, designed to let you undo and redo. In MySQL, the language I was using for that database, they had "transactions". And you could type the command START TRANSACTION. Any edits you make will be accepted, but they will not be properly, definitively, and irrevocably saved until you type COMMIT. If you made a mistake, you typed ROLLBACK and the database simply forgot that those commands were ever sent. Which is great, right? Because everyone makes

typo

s. Can you tell it apart? Because it's really subtle. The database had gone into the "articles" table and, for each article, had changed the "content" field.

Those words—“articles” and “content”—are surrounded by inverted commas, that strange character to the left of the 1 on most keyboards. The backticks mean "this is the name of a table or field", I mean something in the database. That's all good. Then he looked at the "replace" command. And I told him that for each article, he should extract the content and replace the dashes with the tag. Everything is in the correct order there, I remember checking that I had everything in order. Except that's where I went wrong. Those, right there? They are not inverted commas. They are apostrophes.

And the apostrophes mean "this is a literal text string." Not a name. So, as I had ordered, the database quickly took the literal word "content", c-o-n-t-e-n-t, looked for hyphens, found none, replaced nothing, and then put that word "content" in the content field. For 5,000 items. And I looked at the website. All the hard work of the volunteers. 5,000 pages. Each page, simply replaced with the word "content". Honestly, my pulse goes up a little when I think about that. He was almost physically sick. Because I knew what was going to happen next. Because that typo is a completely reasonable mistake.

There's nothing wrong with being wrong like that. Everyone makes mistakes like that, all the time. And we press Control-Z. Or we click on the 'Undo' button. In Gmail, we press "undo send," at least for the 30 seconds before it actually sends the message. And if you happen to be stupid enough to work on a live SQL database, type ROLLBACK. He hadn't told her to initiate a transaction. And there are all kinds of words you could use to describe the idea of ​​working on a live database without even a transaction as a safety net. Ridiculous. Asinine. Thoughtless. But the one I think is most accurate is: negligent.

The only reason that typo was the

worst

I've ever made was because of all the bad decisions that led up to it. Working on a live database. Thinking I couldn't mess up a simple order. Not having any type of backup! Days of work by volunteers and at no point did I think, you know what? Maybe we should get a copy of that somewhere else just in case. That should have been backed up daily or hourly. The root cause of all of that, of all the subsequent days where I had to apologize to so many people, the root cause was not a typo.

It was overconfidence and negligence that meant I had no way to undo my mistakes. It's the kind of lesson you only learn once. Programmers and anyone who works with software, we have this magical ability to undo. No professional working with real-world physical things has that option. So if he doesn't have a backup of his code, his thesis, the photos on his phone, or his database, get a backup. Don't leave it for the future. And if you have one ready: check that it works. Because you don't want to have the same feeling of: oh, no. If you are technical enough to make it to the end of this video, then you should definitely use a password manager.

Every once in a while you'll see a big news article about how a company had a security breach and, yes, sometimes, that's what happened, but other times, it's just that someone found or bought a list of usernames and passwords from another security breach. at a different company and are simply testing them all to see if there are any matches. Reusing the same password or variations of it is a bad idea. That's why I recommend Dashlane as a password manager, partly because they sponsor this video, but also because I read their security white paper. And so have many other people who know more about crypto than I do.

Being able to easily use long, complicated, symbol-filled passwords that are different for each website and app, automatically synced across iOS, Android, Windows, Mac, and Linux, is incredibly useful. Additionally, they will automatically fill in your credit card information and personal details if you wish. And if you're working from home right now for a large company, then sure, your company's IT may be working great, but maybe you're in the person where you have ten people who need to share an account on some email service. other company. The only person who knows the password can no longer simply walk up to your desk and log in.

So instead of sending that password via email or Slack, or calling someone and asking them to write it down: Dashlane for Business lets teams of people share passwords securely. Go to www.dashlane.com/tomscott to try Dashlane for free and you can use my code tomscott to get 10% off Dashlane Premium and to support this channel.