Errors and Debugging

Errors and Debugging#

Writing code is not unlike writing papers — first you have to decide what you want to say, then figure out how to say it. With code, however, you’re literally learning a new language in order to do this (albeit one that’s simpler and more logical than a natural human language). And unlike other classes, which might require only a handful of writing assignments over the term, in this course writing code is how you learn, so you will be writing and learning on an ongoing basis.

The great thing about code, compared to learning a language, is that instead of another person, you’re communicating with a computer. It doesn’t judge you or laugh when you make mistakes. And you will make mistakes. So many mistakes. Fortunately, having a non-judgemental interlocutor allows a lot more iteration, trying things out until you get it right. Computers are also very patient, so you don’t have to worry about pausing while you Google how to do/say a certain thing.

So yes, you will make errors. All the time. An important part about learning successfully in this course is accepting that these errors are a natural part of learning, and getting used to figuring out how to solve them. AI assistants will significantly reduce the number of errors you make. But you will not be able to use them effectively if you can’t understand the code they generate. In this way, by reading, running, and modifying AI-generated code, you will being to learn how to code. You will also learn how to recognize and correct mistakes (debugging). This is a critical skill for any coder or data scientist, and it’s something you will be doing throughout this course.

How to deal with Errors#

Firstly, when you make an error, you will likely get some sort of error message — although it’s possible your code did something, it just doesn’t give you the right result. If you get an error message, it will probably look scary, complicated, and confusing. It may even show you way more lines of Python code than you actually wrote! It’s OK — often, most of the error message isn’t that important. Sometimes, the first thing to do is just note that you got an error, and look at your code again. Many errors are due to typos. In programming, you have to be precise with things like spelling, capitalization, spaces, indents, colons, semicolons, commas, periods, even different types of brackets! It will take a while to get used to this. Often you’ll catch an error just by looking at your code more closely.

The second approach is to actually read the error message. If you ran a few lines of code, Python will usually indicate which line triggered the error. Sometimes, it’s due to something that happened earlier, but that’s a good place to start. The error message will often give you some insight into what you did wrong, but it’s rarely super-obvious or helpful — decoding error messages is something you get to learn, too! Also, sometimes the error message will spit out lots of lines of code. Usually this is because whatever you wrote was “calling” (relying on) some other bit of code, for the command you were running. Since much of Python is itself written in Python, the error message may well make it look like the error is not in what you wrote, but in someone else’s code you were trying to run. Don’t worry: 99.9% of the time it is actually your fault. Usually what’s happened is that your command ran, but it passed the wrong information to the underlying code. So once again, you should re-examine what you wrote. But you may also need to read the documentation for the command you’re trying to run, to understand what you did wrong. Usually you will find the reference to your line of code near the top or bottom of all the code that the error message spits out.

Ultimately, writing code requires a lot of patience and trial-and-error. You rarely get it right the first time. Don’t self-flagellate or stress when you get error messages, just view it as part of the process, a puzzle that you can solve. The old adage of “measure twice, cut once” doesn’t apply in coding. Instead, you should just forge ahead and try lots of different things, until you make progress. And of course, there’s class time to ask questions, and your classmates and team members to consult with outside of class time.