Rub-A-Dub Rubber Duck: Don't be Afraid to Debug! by Anna Ossowski

Speaker 1: Come on, no.

Speaker 2: Hello everyone. I hope you had a great time and a great morning here at DjangoCon US and thank you so much for attending my talk. It's my first time in Philadelphia and I'm really excited to be here and it's my second time that I get to speak at DjangoCon and I'm really, really excited. So I'm Anna, I'm from Germany. I have a degree in English and Catholic theology. Some of you may have identified William Shakespeare and Pope Francis on my slide, and Pope Francis was actually in Philadelphia not too long ago. Um but about two years ago I got involved in Python and I now work for Elderion and the Pinix project as a community manager. Besides work, I'm also involved in a few other volunteer-related things. I am DjangoCon US Communications Chair. I'm a former member of the PSF Board of Directors.

Speaker 2: I am PyCon US Open Spaces Chair and I'm one of the leaders of the PyLadies Remote Group. And today I'm here to present my talk with the title Rabba Dab, Rubber Duck, Don't Be Afraid to Debug So it's all it's gonna be all about rubber ducks. As you might have seen, we set up a little rubber duck pond over here, so you're all welcome to take a rubber duck when you leave. Let me show you something first. So this used to be me when I encountered a bug in my code, really frustrated and angry. And this is me now. So the goal of this talk is for you to hopefully feel like a warrior and feel prepared and brave when you encounter when you encounter bugs in your code. and to not be frustrated and

Speaker 2: upset and scared by them anymore, because really books are nothing to be scared of Um I'm an English major, so I love dictionaries, I love definitions. So let's first first let's take a look at what a bug actually So when you type in the bug into the Maryam Webster dictionary, you can you get all of these wonderful definitions. A bug can be an insect or germ, it can be an enthusiastic, prominent, or crazy person. It can be a concealed listening device, a weight allowance for jockeys. That's all interesting. I did not know that the word bug had so many definitions, but unfortunately we're not interested in any of those today. The one we're interested in is this one. A bug Um is a defect, fault, flaw, or imperfection, or in other words, something causes your code not to work.

Speaker 2: Now we know what a bug is, but what's actually debugging? Debug means to make to remove mistakes from your program, or in simpler words, make your code work. So we now get we have that figured out. If there's one thing I want you to take away from this talk, I already said that. I want you to take away that breaking coat is nothing to be scared of. Who of you like I don't know who wh how many of you have are beginners or I I I guess there's a few advanced people here too, who of you at one point in their programming career have been scared of bugs or debugging a program? That's pretty much everyone. And I hope that within the next 25 minutes you will learn that breaking things is pretty great because breaking things gives us the opportunity to learn how to fix them again.

Speaker 2: And I'll tell you a little secret. Most things in coding can be fixed again. You may not be able to debug it yourself, but there's always someone who can help. And if nothing else works, you'll just do it over again Um, let me tell you a little anecdote which has to do with this picture. So I love my mom. She's techni my my mom's very technically challenged, but I love her And last year she broke the on and off button on her PC. She had pushed it in. She had pushed it in way too far and she was like, I don't know what to do with this Will you repair it for me? And so I said, Mom, I have no idea how to do this because I'm not a hardware person. I had never taken a PC apart But I figured, well, we don't really want to spend the money and have it repaired professionally and we don't have the time to do that either.

Speaker 2: And so what did I do? I turned to my friend Google and I Googled how to take her And I took it apart and I fixed the on-off button. It's it's not a perfect solution. You still have to press it kind of hard to turn it on, but that was a year ago and it still works So that was me debugging a real world pro problem. And I found a solution that worked for us. It's not the perfect solution, but it works. And when you when you're coding, you have to remember that sometimes You have to consider if you want the perfect solution, if you just want any solution. Sometimes any solution might work for the moment and then you can always go better, go back and make it better next time Let's take a look at a few debugging strategies and learn how rubber ducks can help us.

Speaker 2: And please keep in mind that this is not an exhaustive list of debugging strategies, nor did I choose a very technical approach on purpose. I wanted to keep this simple because this talk is aimed at beginners or just people who want to learn something different about debugging. Let's start with error messages actually. And please note Okay. Error messages are pretty crucial to debugging And error messages are nothing to be scared of. I remember when I started programming in Python and I saw an error message in my console, I was so scared because I had no idea how to read it, I had no idea what was wrong, and it was just very scary. But once you start getting more into programming, you will notice that error messages actually a very useful feature

Speaker 2: because they help you a ton. They help you figure out what is wrong with your code. You just have to learn how to read them. And in Python, we have three types of error messages. The first type are the so-called syntax errors. I'm going to put up these slides on slide deck afterwards so you can read uh what's on the slide later. I'm not gonna point it out now because I'm gonna run out of time probably. Um the syntax errors are basically errors in the Python language and Python will find these kind of errors as it parses the program before it executes the program. So basically syntax errors are mistakes in Python like you would make grammatical mistakes in English, for example Let's look at a very simple example. When I run this code, I get the following error message.

Speaker 2: You can see that the parser repeats the line and displays an arrow pointing at the earliest point in the line where the arrow was detected. The arrow is detected at the token preceding the arrow. So you can see here that the arrow is here. Add my closing bracket, so we know that the error must appear after the closing bracket. And Python is also so smart to tell us which file and which line the error occurs in. So I named this file very creatively example1. py. And my program has two lines and Python says it's in line the error is in line number one. So who of you know what is causing the error? Yes? Right. I forget to add a colon. And that is something that will happen all the time. You just forget one simple

Speaker 2: letter or sign and it causes the program not to run correctly And if you can't see anything with that anything wrong in your code, if Python says line number one is wrong and you look through the line and there's nothing wrong. Sometimes the Python interpreter is not always right, so look if there is nothing wrong in that line, look in the preceding lines of code. The second type of error messages are the so-called runtime errors or exceptions. These errors occur when your program is syntactically correct, which means it is free of syntax errors, so Python will parse the program and it'll be fine. But then it'll execute the program and it'll stop executing it because it finds a runtime error and an exception. And when Python does that, we call that it crashes, the your

Speaker 2: program crashes. Let's look at some examples of runtime errors. So we have the division by zero error. Python gives us this error because we're trying to divide 5 by 0 and that just doesn't work. So it says uh-uh zero division error. Then and it tells us where the error occurs. Here it just says STDIN, which means standard input, because I typed in the code in the console and I didn't save a file, and it tells us in line number one. And it also tells us that the error occurred as a traceback. Another type of runtime error is using is using an identifier which has not been identified. So you can see that I'm trying to do two plus Django Pony.

Speaker 2: And Python says uh-uh name error, the name Django Pony has not been defined. And then we have the performing an operation on incompatible types. So you can see we're trying to do 7 plus 7 and Python says type error. Why does this not work? Right. Um and then we have two other types common types of runtime errors when we're a list or a dictionary or an object doesn't exist or we're trying to exact to um access a file which doesn't exist. And whenever we're as programmers we work with users all the time and we work We work with people and people make mistakes. And um sometimes you can predict that a certain pr

Speaker 2: part of your program is might cause errors. So if you're accessing a file, for example, and you might know oh the user's gonna type in the wrong file or the file might not exist, you can prevent your program from crashing By using a try and accept block. So first the try class is executed and the user is prompted to enter a number here in my example. And if no exception occurs, the program will run But if an exception occurs, which means if the user doesn't enter a number or enter something invalid, the accept clause will run and our program will not crash. So you can see that I was prompted to enter a number and I typed in Anna, which is obviously not a number. So then in instead of getting an error message and instead of my program

Speaker 2: crashing Python tells me sorry that was not a valid number because I told Python in the accept clause that's what I would like for my user to see. And then I was prompted to enter a number again and I entered number three this time, which means my program Ran this time. Had I entered my name my name again, then it would have done the same thing over and over and over again, but it would not have crashed And the third type of errors and probably the hard hardest one to debug are the so-called logical errors. They occur when your program is free of syntax errors and free of runtime errors, but there's something wrong in the logic of your program. And you will have to find these errors by basically reviewing parts of your code because there won't be an error message So you kind of have to figure out how to solve this and I will tell you how.

Speaker 2: And this was just a very brief introduction to error mess uh to error messages. There's a whole science to it, so I would recommend these two um sources. They're pretty beginner friendly and they help me a lot while preparing my talk. So again I will put my slides up on speaker deck afterwards. you can find them there. Okay. So sometimes though you'll stumble across error messages and you still don't know what Python wants. you just don't know what is wrong. So we're programmers and what do programmers turn to when they don't know what works? Yes or Google? Um Google can actually be a very helpful tool, but be cautious when using Google because Google can cause a lot of frustrations

Speaker 2: because Google will only work if you tell it very precisely what is wrong with your code. Sometimes copying and pasting code into Google might work and you might be able to pull up just the right stack overflow answer, but it doesn't always work that way. So I'll give you an example. This is me explaining to Google very poorly what the problem is. I made some changes to my code, but I can't access my website on the internet and I don't know why and it's really frustrating. Please help me Google. This is me over-exaggerating, but you know. And so you you can see the results I get. They're not very helpful at all. They don't even mention Django anywhere close. These are the top four results And this is me doing a little better, at least now I get results that mention Django.

Speaker 2: And this is me being pretty precise. Django can't access development server and browser. And you can see that I get four stack overflow results. And I clicked through all of them and they were all actually pretty helpful. So just keep in mind if you use Google, you have to be pretty precise. And another technique we're going to talk about now is, and which programmers swear by, is the so-called rubber duck debugging. If you've never heard of it before, you might think it's sort of crazy, but rubber decks can actually be real very helpful. So, um These are some ducks from the famous sandbar in Lawrence, Kansas that are taking a vacation in San Diego. And you can see that I have one of me one of them with me here.

Speaker 2: So programmers love and sway by rubber ducks. Um and here's how it works. So you take a rubber deck and you set it on your desk just like I did here, and then you basically explain to your rubber duck what the problem is. And the idea is by speaking out loud and kind of like forming um the idea and the problem in your head, you get an idea what might be wrong with the problem and you might not always be what the with the program and you might not always be able to solve the problem yourself, but at least you get a better idea. You actually learn to phrase what your problem is or you might it might be able to help you Google what the problem is. So the idea is to put it in more precise words.

Speaker 2: Other times rubber duck debugging won't lead you to a solution. So that's when you can turn a stack overflow or Google or IRC or various Slack channels. Another good way to debug programs is to come up with different hypotheses. You look at your code and you just set up one, two, three hypotheses what could be wrong with your code, and then you start going through them and like verifying or falsifying them. just write it down because if you keep it like all in your head then you might get confused. So actually take a piece of paper and write down your ideas. And as I said before, you can take a rubber deck home with you later.

Speaker 2: My boss was who's not here today because he's very sick, but he was so generous to let me order all of these rubber ducks for you so you can take one home later. And we have 200 of them, so please take two or three. And please tweet me pictures of your rubber ducks. I love seeing pictures of rubber ducks, so take one home and tweet me pictures. What's also helpful is breaking your code down into blocks. So we have functions, for example, and you break down your code into self-containing blocks, and then you comment them out, and then you can see. Oh, this section is okay, it's not causing the error, but then the other section might cause the error. Um what's also helpful is when you write code, write ten or twenty lines of code and then put in a print statement and run the code and see if it works.

Speaker 2: And if it's causing an error, you know it's probably within the last 10 or 20 lines of code you just wrote. If it's not causing an error, write the next 10 or 20 lines and see Yep, it's causing an error then. Um and repeat that. If nothing else works, if you have a program running, let's say you have a uh file of like 50 lines of code, try and open up a new and empty file and copy and paste lines of code from your existing program into the new program and just it just helps being organized and trying to debug your program that way by breaking it into smaller chunks of code. It's much easier to debug ten lines of code than to than to look through a thousand lines of code. Commenting out parts of code or writing pseudocode can also be very helpful, especially if you're working with code that is not your own.

Speaker 2: Just go through the code and try to translate code into English or whatever your um mother tongue is. Just make sure you understand what the code is doing, how it is how it is executed draw diagrams like how do different parts of code interact with each other, how are they executed in which order? Just try to understand your program which will help you debug it When you're following a tutorial or documentation and you run into a bug, there are two possibilities. Either you made a mistake or there is a mistake in the tutorial. So if you're going through the Django Girls tutorial or any other Django tutorial, just ask yourself these questions when you encounter a bug. Is the indentation correct? Did you forget any commas or brackets

Speaker 2: Are there any typos or did you leave out a whole line of code actually? That happens all the time. If you're not copying and pasting code but actually typing it, you leave stuff out really early. And by the way, when you're doing a tutorial, I would highly recommend actually typing the coat yourself and not copying and pasting And after you double check and you're absolutely sure that you did not make a mistake, I would highly encourage you to check if the documentation or tutorial is up on GitHub. And if it is, go through the issues and see if someone else reported that bug. And if they did, then you know it's a book in the tutorial, it's not something you did. And if it's not, I would highly encourage you to report that issue. And if it ends up not being an issue at all, some friendly person will tell you that um it's not an issue, but they may

Speaker 2: be able to help you find the solution But it if it if it if it is an issue, then you actually helped a lot of people by reporting it. And in the case of Django, you would go to code. jjango project. com and report it in the Django Buck Tracker by creating a new ticket Um now you may have heard people talk about reproducing bugs. For a long time I honestly had no idea what reproducing bugs is and I um So um after you report a bug in Django, a friendly Django core developer, other Django developer will go and look through Is it too distracting?

Speaker 2: They will look at your uh buck and they will try to reproduce it in the on their own computer in their own development uh environment and W why they do that is they want to figure out is it really a bug in Django or does it have something to do with your setup, with your computer, something like that. And that's actually pretty smart because if it's not a bug in Django, then we don't need to go ahead and Try to fix something that really does not be does not need to be fixed. And if you're debugging something, try and if you been doing it for a long time, try and ask a friend, hey, can you reproduce that book for me in your own development environment or on your computer? And if they can reproduce it, um then you know it's actually a bug and something else and if they can't reproduce it then you know it has something to do with your setup.

Speaker 2: And while they're reproduci ri while they reproduce it, they will have to go through the same steps you took while encountering the bug and they may actually be able to help you figure out which step you got wrong. So these two approaches I talked about are pretty hands-on. They're not very scientific. But there's also tools that you can use. that will help you debug. Other s smart people wrote the Django debug toolbar, the PDB, PyFlex, PyLin, PyChecker, PEP8. So and there's other tools too. So if you um want to take a less hands-on approach, please feel free to check these out. I don't m I didn't mention them because I wanted to

Speaker 2: go wanted to follow a simpler approach, but I just wanted to make you aware that they are there. Now errors in code and debugging can be very frustrating. Um it's not a nice emotion to be frustrated uh all the time. I saw on Twitter a while ago someone said Um well writing code you feel like a king or queen one day and then you feel like an absolute failure the other day when w when your code just doesn't work But how do you deal with frustration in a healthy where we're all programmers? We deal with with frustration on a daily basis. And like Patrick here, we don't want to destroy all of our MacBooks. So Obviously, everyone is different, but there are a few things that you can do that help me. First of all, I would like to recommend that you ask uh

Speaker 2: for help after a certain amount of time. Don't try and debug your code for five hours at a time because you probably won't find the solution and you will just get more and more frustrated. Just um try to debug it for 30 minutes and if If you can't do it, try to ask someone for help. Step away from the computer for a while, take a nap, go for a walk, go to your happy place, color in your coloring book. That's what I do. Just do something different Um or a lot of times I go to bed and I get a good nights of sleep and I wake up in the morning and the solution popped into my head magically Do you maybe you know the feeling when you like stare at your computer for a while and you do not see the mistake and then you just give yourself a break or let someone else look at it and then you finally see what was wrong all along

Speaker 2: Um or look for a different solution. If one person cannot help you or they can't explain something in a very efficient way for you, ask a different person. I remember when I did the Code Academy Python tutorial, um there was a section on binary numbers and I totally did not get that concept at all and my friend tried to explain it to me all night and I still didn't understand it. So then I found a short YouTube video, a two-minute YouTube video, and afterwards it clicked for me. So it wasn't that I was too stupid. to understand binary numbers, I just needed a different solution. So if that happens to you, don't blame it on you or on the person explaining it to you. You just need a different um Explanation. And here's one thing I want you to remember remember. You are not the code you write.

Speaker 2: Code is just code and you're still a wonderful person even if your code doesn't work one day. So remember that. Take a sticky note and put it on your desk. You're not the coat you write. You're not a failure. Your coat may fail, but you're not a failure. You being you not being able to debug your code may have a million reasons, but it has nothing to do with you being stupid or any other issues you may have And if you can find a solution, here's a few things you can turn to that I already mentioned. Stack Overflow is pretty It's a pretty great tool. There are some nasty people on there, but usually you can find a good solution. It is true. Uh Slack, we have There's a lot of Slack channels. There's the um

Speaker 2: we have a Slack channel for Pinx where we're always happy to answer questions. The Pie ladies have a Slack channel, the Django Girls have a Slack channel. You can turn to the Django Girls Gitter, IRC, go to your local meetup. Sometimes Twitter can be very helpful. Don't be afraid to ping people on Twitter or to just email them, especially if you know that they're an expert in the field you have you're struggling with. Just Turn to them for help and use the hashtags Python or Django on Twitter. And when your code finally works, I hope you'll do the happy dance. Um that's all I have for you today. I won't be doing a QA because I prefer chatting to people one-on-one, but I'll be here all week. So if you'd like to chat with me. Come see me now

Speaker 2: or during the next two days or tweet me at OSS Anna 16. And I'd love to hear from you. And please all grab a rubber duck. Don't forget to grab a rubber deck and tweet them to me. Um I had to put this in. It's I thought it was funny. So now and go break all the things, take them apart, put them back together, fix them, be confident and always remember that there's a solution for everything. Thank you.