I am dedicated to using my new superpowers to connect people and bringing them closer together by building mindful software. Do not show me a magic trick unless you are prepared to reveal all your secrets. Former Stage Manager with experience in event planning and leadership. Button aficionado.View the profile
About the talk
RailsConf 2019 - Filling the Knowledge Gap: Debugging Edition by Mina Slater
We’re generally never officially taught to debug. No one tells us at bootcamp or in online tutorials what to do when our code doesn’t work. It’s one of those learn-it-on-the-job sort of things and comes with experience. As early-career developers, we get a lot of syntax thrown at us when we’re first learning, but in actuality, the majority of our time is spent trying to fix broken code. But why should we slog through it alone? Let’s explore some Rails debugging techniques together!
Thanks for coming to my first ever conference talk. Thank you. I before we begin I just want to point out that I have the links to other linked to my slides in the top left there. And if you wanted to follow along and my Twitter handle is enough for ride. Is that something that you do? So the title of my talk in the program is filling the knowledge Gap to biking Edition and that's really just a fancy way to say that this is a talk about what I wish my bootcamp. I taught me about the bugging. So first
off I'm going to do a little bit of introduction. My name is Mina Slater and my pronouns are she and her I graduated from a coding bootcamp in April 2018. So about a year ago. I am currently a developer at a Consulting agency in Chicago called Tandem and it's my first time attending railsconf. Just a fun fact if you can tell already I'm terrified call. So if you want a career for a long time, like I was starting a new job in a new field is scary enough. I was transitioning from a Pioneer career in theater where I was the expert
at my job to a new industry in a team where everyone knew more than I did. I knew I was going to be the most inexperienced developer in my company, but I was ready to face the challenge with this new career head on now. I was prepared to put a lot of time and energy into learning and improving and becoming the best developer I could But I wasn't prepared to discover just how much I didn't know. I quickly found out where my skills are lacking though. I was inefficient and at a loss when it came to things like testing
and dividing so I was really out of ocelot. And unfortunately, I don't think my experience was all that unique. A majority of coding bootcamps leave graduates with some knowledge gaps in essential skills, like the biking and a lot of us suffer at our struggle out of Hurst jobs because of it. Now when I first started learning to code see you in error message Papa was really scary. It was my toe telling me that I did something wrong or that I have made a mistake. And since we have all been conditioned to avoid mistake, it felt
like a failure on my part the big read error messages reminded me of big red x's on my teachers used to put on my test in school. And they were intimidating me into inaction and as an attempt to avoid them I just didn't run my coat is often because you can get error message if you don't run your program, right? So I will write toad in the bubble if my text editor I was stare at a wondering if it looks right and the only indication that I had of rightness with a very limited knowledge that I had about the programming language I was working in.
So if you can imagine I wasted hours upon hours trying to make things right before I would run any of it. So when I eventually let the program run it, of course. Didn't work and without having been taught to debug or seen anyone demonstrated. I didn't have any idea how to approach it. I didn't know how to read the other messages or that I should even read them at all my only approach was staring at the code. Come through it line by line. And hoping to find any
typos or obvious mistakes. No one told me that there were better ways and I practice myself into the parking bad if I can have it without knowing it. Now don't get me wrong. I'm not saying that boot camps don't produce quality developers. In fact more companies to hire career Changers and boot camp graduates because we bring past experience is in soft skills are harder to teach but that's a 40-minute talk for another day. No, there's only so much that you can cram into someone's
brain over the course of three months. So I understand that boot camps have to make compromises and they usually have to focus on things like syntax and super basic practices, like assigning variables making loops and defining methods. Things like testing ended biking dish out to the side. So after I finished boot camp as started working, it was quickly apparent that there were better ways to fix bugs. I had to stop what I was doing staring and hoping but I didn't know what I was supposed to replace it with.
So the part of my brain where the fucking knowledge should live with a big empty Gap. I had to overcome it by filling it with proper tools and strategies. A tandem repair program all the time and pairing gave me an opportunity to observe a more experience developer at work. I have a really supportive team that lets me openly confront what I don't know and they encouraged me to ask questions. We will break things together and fix them as a pair. It also gave me exposure to how different people like to approach bugs and errors for instance.
Shania was really good about using the Network's happen the tools and Sasha is a wizard in the rails console. Does someone really smart said to me once that is software? You have to break everything first. Before you can piece it back together and make it work. And I think this applies to learning as well because if we can't admit what we don't know we won't learn it. How do you supportive work environment allows me to confront might not like gaps. So I will know when I see something that I want to store away in those spaces and that can be a new
approach to a problem or unusual. And what I want to achieve in the next 30 minutes is to share with you the more important lessons. I learned about the biking over the course of my first-year working as software. I'm not trying to turn you all into Master the buggers honestly 30 minutes just one won't be enough for that. But I also want to give you a better place than I had to start so you can go further in the course of that year. I've organized the things I learned about the fucking into 3 main categories or license if you will. I like the number one. Look under the hood. Let the
number to tap the phone lines and lesson number three find a bug right a test. These are not meant to be roadmaps, but rather starting points were dividing can begin and depending on the issue at hand. We can use one of the three mix and match them or just go another route all together. So I'm to watch the number one look under the hood. So I wasn't maybe exaggerating when I said that I wasn't taught any dividing strategies that all we were told to console log everything. So I was
peacocks inspect internally giving us more useful information as Developers. For instance. If you take a nap if I drop ject a puppy named Dottie. The inside a real console here. We can see the difference between using puts two output are puppy object. and using p so depending on what is useful for the circumstance. It's important to know the difference between them and remember what is available to us. Upended bugging lettuce leaf breadcrumbs to in the form of these pain statements around our code
and Visually track the path of our program and look at actual pieces of data we can watch and make sure that all the data is at the expected and if an output we expected to see didn't show up at all. It's safe to say that our program never hit that section of code at all. So Aaron Patterson is the famous. We self-proclaimed puts debugger a link to the blog post about it is included at the end of my deck most of the things that he covers in the supposed feels very much over my head and honestly, I'm not a print of bugger like him. I'm a private Buckner and what we just
talked about is the extent to which I use these pain method. but nowadays my go-to tool for peeking under the hood of my rails application is pry Price of gem that allows us to open up a console session at any given point of our program just by dropping binding. Pry. Into the parts of the code that we want to get a closer look at. So the next time we run the program it will pause there and give us an interactive console in the terminal. That's why something like this is called interactive still bugging is served. Largely the same purpose as using parts to
explore the inner workings of our program. But he gives us more freedom in our explorations. So I have a simple app here. It's called Puppy gachi. I built it maybe a year-and-a-half two years ago when I was trying to teach myself rails. Attract the puppy that each owner of the sort each user owns and these puppies get hungry or bored over time. So that users can log in to check on their kennel and feed or play with them. Now it's inspired by Tamagotchi. If you remember what those are I have a I have put a couple of break points into the service
object that I used to age the puppies and reset their hunger and boredom levels. We also have a few private methods that I have folded up and below the keyword private their the bottom. So if we reload the page here in the browser. We just see that the load patches and it appears to be unresponsive. So if we pop into our server laws will be able to see the request from the rillo hit the server and stop at our first binding pry. The most things that we can do in the rails Council are available to us in the procession for the gym also gives us a
lot of extra commands to get more information about our program. One of the basic ones is LS. So using Heroes we can get an overview of everything that is available to us from within the current context, which is puppy aging service. So we can see from the output that the puppy aging service has eight public instance method process among other things, but it doesn't show me the private methods because I don't have access to those from within fry. And a gem that is used a lot side by side with tie is probably by bug which gives his commands
to navigate through the code base and the ones from that that I use most often are next step and continue. So here we are still tied into the initialize method in the puppy aging service We're stopped online for and we can tell because of the arrow that's on the left of the fly number. That line of code is telling our at puppy is this variable to point to the puppy object that we passed in when initializing the puppy aging service and right now it hasn't been executed yet. So if we look at our instance variable puppies
We can see that it doesn't have the value right now is no but if we use the next command the program will run the next line set the result to a puppy and stop and line 5. And we can then see that our puppy has a value now. So at this point we've looked at a couple of variables. We've also run a couple of commands star displays a getting a little bit messy. We can clean this up by clearing the terminal and using where am I to help us reorient ourselves in the procession? So from here
if we want to have a look into the change time method online V. Who's the result is being sent to the other instance variable. We have time he lapsed we can use step to step into this next method call. So you see that this Lance is into the definition of change time, which is a private method to find on the service class. Now sometimes step will take us into real source code or the source code of some other Jen we're using. It's important to remember not to panic when price at The Possession and sub somewhere else familiar.
It's all just code so we can learn to read it in time. Now the Waze navigation to marijuana to demonstrate is continue which will tell Pride to continue running the program until it hits the next breakpoint, which remember we have in our public instance method process. So when we're done with the session and want our program to carry out the rest of the actions we can they use the exit to get out of the procession. So being able to peek under the hood of my program was a game-changer for me. The hardest part of learning to code was overcoming the disconnect
between the text and the editor and what shows up in the browser. It's especially hard to conceptualize when working with a dynamically typed language like Ruby where we can assign data of any type to the same variables without any warning about potential problem that has anybody run into this error message here before. Yeah, okay as expected the actual method name in this message changes, but the Sarah and I are really close friends. I see him all the time. If you're unfamiliar with it, this message is telling us that the program wants to
invoke a method select. On something whose value is no. In this example select is a ruby built-in method on the array and innumerable passes. So if the object is being called on is anything but an instance if either of these classes the method call results in this air and it's a message. We'll see every time we try to use the method on something that has the incorrect data type. Essence are many answers to where how and why the data is in unexpectedly. Now, I'm opening up the program using puts or pride is a
uploaded correctly and where we would go to check the status of our applications trips to and from the server. When we first open up the desk Schewels, you won't see any network activities logs here yet. So let's go back to puppy. She again went with the duct tools open and we can see that the network app is once it's opened up. We can reload the page or repeat the action and watch the logs populates with all the network activities. To each row in a table at the bottom represents an
HTTP request and the column gives you more information about each of the requests. The ones that I look at most often are the names of the resources the status which is the HTTP Response Code and the resource type. The some lines will appear in red if there are bad requests, maybe a 500 internal server error or a 403 Forbidden. When we click into one of these lines, so we have access to more information like the request and response headers and the response body these sections will let us look at the request more closely
and what I typically do here is check to make sure that the requests are going out to the server with all the information that the backend needs to process the request. In the headers tab under an individual request line. There's a request payload section that will tell us what information went out to the server and we can see whether it's behaving as expected or identify where it's not And on the flip side there is a response to app that will show as what came back from the server as a result of our request as well. So in this case, it looks like a request resulted
in a 500 internal error because erased an argument are on the back end. Do this demonstrates something that it's really easy to forget that even though a bug manifest itself on the front end doesn't necessarily mean it's something wrong with the front end code. I have been tricked by this and spent a lot of time investigating the reacts code only to realize that it's actually a back-end issue disguising itself as a front-end are. Now we can also look for similar information from the server side by peeking into the logs. This is where the server will log information about each
request coming in how the server result that request and the result of the request. This is also where exceptions and errors warnings will show up and where the price session will open if the program has a Breaking Point. This is also where server logs this is what the server log will look like for the refresh. We just did on a puppy. She where we saw the network tabs us where we saw the network logs in the browser. So like with a network tap we can see the HTTP request. Which route is it hits? the response status code
and the exception that was raised which we saw earlier is part of the response body. This is where it's really beneficial to know. Our program's inside and out as you can see the server logs. Don't always tell us when something is misbehaving. They're definitely not always color coded. So knowing what the server logs look like when it runs properly will help us recognize when it doesn't. What's the number 3 find a bug ride a test? The person errors are a very normal part of software development because
developers are only human. But we also want to make sure that any future changes we make to the code won't create any regressions and result in the same bugs again. I know a lot of times bugs exist because we failed to account for and write code to cover certain edge cases. Most of the time the program will run without issue. But ideally our program will run seamlessly for as many end-users as possible. Has to cover the condition under which are bugs show up will prevent that code regression and let us know when the
bug has been fixed. So running a test will also give us clues about how to proceed when looking for a solution. For example recently my coworker shamaya and I were working on something where we had to write a method to sort some after fracture objects into a list to Pastor the front end. We had one database query that returned an off after breast a relation a list of evaluations and another Prairie that we turned one single evaluation. The purpose of our method was to push these results together into one list
sorted based on certain attributes so that the front end will display them in the proper order. Not in our implementation of this method we wrote S2 cover all the cases that we could think of. So with a fully greentext wheat and the UI revealing no unexpected behaviors. We created a pull request for the future after the team had reviewed it. We eventually merged it into the phone base. No couple of hours later when another co-worker Sasha was working in the QA environment. She found at the page that we were working on with broken.
And after a little bit of investigating she concluded that the page couldn't render because one of the queries the database return to nothing. Our method was adding a nail into the list of objects. We passed our friend then. But why react try to display something that was on to find everything fell apart? I ended up working with her to find a solution for the bug and the first thing she suggested that we do was write a test to account for this particular stage of the program. AR test basically said hey if one of the queries comes back with no results we
expected to be excluded from the list that we passed to react. Now we didn't know when we started to biking what specific line. So we need to change or what the change would look like but backed up by the tests. We would know right away when it's been fixed and not only that each time. We try to solution. We would run the test hoping that they would fail and new and exciting ways. That sometimes in our jobs as developers, it feels like we're just killing bug after bug. We fix code almost as often as writing new lines of them
and goods if I can have its are almost as important as writing clean code. So for the developer that I was a year ago. This was a really anxiety-inducing idea. I could have written ducote method after method, but I had no idea how to find that variable. That was unexpectedly. No. But fortunately I work with really smart developers with a lot of experience. Through pair programming I was able to piece together a little something from each of their strategy into my very own debarking tool kit and little by little I'm gathering
lessons to fill up those knowledge gaps that I have found in myself. So in a perfect world bootcamps will put more emphasis on teaching the techniques and practices of the biking. It would prevent the graduates from learning bad habits and prepare us better for our first jobs. But as it is what we can do is help each other by sharing what knowledge we do have and emitting openly about what we do not because I knew early on that. Hey, I don't know what to do when something breaks. I was able to focus on that and learn the lessons that I shared with you
today. Now I would like to go back to Aaron again here to close this talk. So I found a tweet the other day that he had penned it from back in January. It's not a bug. It's just taking the code path Less Traveled. He said no entender love and I don't know him that well, obviously, but he was probably making a joke. But this actually made me feel more at ease about the bugging. Because when we frame it is this way errors and bugs are just edge cases that we haven't considered yet. So we shouldn't really be intimidated by
them. And I hope after the time that we spent together you feel more equipped to come find your next bug or are. So now please go away and break your code. Thank you. Now if I may have another minute of your time, I wanted to tell you a little bit about the company that I work for the last time we were at railsconf we would know instead of mind, but we have since changed our name to Tandem. A 10mm. Is it design and Technology Consulting agency located in Chicago
at the company. We ain't to create product and services that will affect the society and our community in a positive way and having recently completed our apprenticeship program. I benefited firsthand from tandems dedication to hiring and growing Talent. We use pair programming to support each other's advancement and maintain our quality of work. So if any of you are looking for work, we are hiring and if any of that sounds appealing to you, please do come talk to me. I would love to tell you more about the position that we are currently looking to sell. Thank you again.
Buy this talk
Access to all the recordings of the event
Buy this video
With ConferenceCast.tv, you get access to our library of the world's best conference talks.