This post is a preview of content you'll get by subscribing to Break In––a newsletter for people learning to code, looking for their first dev jobs or working hard in those first jobs. Break In shares real experiences and advice from real devs who have been through it before. Subscribe to get our bi-monthly newsletter, start asking questions or even contribute your own experiences.
I'm Stuck!
A few weeks ago, I found myself facing a particularly thorny challenge. I had to re-write some code that was responsible for delivering music content to some of the online stores (think Spotify, iTunes, etc.) that my company partnered with.
I started out my day pretty smoothly, making some good progress. Until about 5p.m. when all of a sudden, I hit a road block. Upon actually sending each song on an album over to the remote server hosted by a given store partner, I was receiving an error message that I had never seen before. I was stressed out--it was nearing the end of the day and I still hadn't finished what I set out to do; I was super confused--all of a sudden I was seeing an error message that I had never seen before, and I had no idea what it meant. Because I felt stressed and frustrated, I didn't stop to think out my approach to solving the problem. I just threw myself into it. I tried a bunch of different random approaches, none of which made any difference. It got later and alter in the evening and I was getting more and more frazzled. Finally, I gave up (and cried a little bit, I'll be honest).
I ended up sleeping on it. When I revisited the issue the next day with a clear head, I was able to take a systematic approach to solving the problem and in less than an hour I had fixed the bug.
I think a lot of people can recognize themselves in this story. Whether your an experienced developer stuck on a nasty bug, or a beginner programmer who is struggling, anyone can get stuck. Let's get un-stuck together with this handy guide!
A Guide to Getting Un-Stuck
- Isolate the problem
- Experiment
- Understand Your Expectations
- Ask Questions
- Rubber Ducking
- Take a Break
Isolate the Problem
You're staring down a nasty bug in your code, your program just won't do what you want it to do and you don't know why. The first step in dealing with an issue like this is to isolate the problem.
Let's revisit my experience writing some code to deliver music to online stores. I started getting an error message when the code responsible for transferring content to the online store's remote server was executing. The error message was something along the lines of "Permission denied!" when trying to actually move file X to the remote server.
The code that caused this error was responsible for two things: 1) Connecting to the remote server, 2) Transferring the files to that server.
So, in order to isolate the problem, my first question is: which of these two responsibilities is causing the error? I can answer this question by removing or commenting out the code that is responsible for one or the other, or I can try executing each discreet line of code in my terminal.
By taking this approach, I was able to see that my code was successfully connecting to the server, but it was not successfully transferring files to that server. I had narrowed down the problem and I knew where to focus my debugging efforts.
Our takeaway is this: When our program has a bug, or we can't achieve the desired behavior, we need to identify all of the code that might be responsible for the problem. Then, we need to pare it down. Start with just one line or section of code, and gradually re-introduce the remaining code to find the exact section of our program that is causing the issue.
Experiment
Once we know exactly which part of our code is causing the problem, we're ready to dig deeper. When I'm really really stuck and I have no idea why a bug is occurring or why something won't work, I like to just start experimenting. Let's take a look at another example.
Recently, one of my students approached me with a CSS problem. They were trying to change the font style and color of a header on their page. They showed me the CSS file and the code for styling the header looked 100% correct to me. Yet the styles where not showing up on the page. I had no idea why!
So we just started experimenting. We tried making a really simple change to the CSS--styling the body of the entire page to have a background color. Surely this styling would show up, even if there was some other style on the page interfering with their attempts to style the header, right?
Wrong!
Our background color did not show up at all. This revealed the real issue--no CSS styles where showing up on the page. This understanding led us to ask the question: "Does our HTML page even know about our CSS file?" The answer to that question was NO. We had forgotten to include a <link> tag in the <head> of the HTMl doc to link to the CSS file. Problem solved!
Don't be afraid to try different tweaks and changes to your code, just to provoke different behavior. This can help reveal the real underlying problem, or at least give us insight into what that problem might be. In order for experimenting to be helpful though, we need to have a clear understanding of what we expect to happen when we make specific changes to our code.
Understand Your Expectations
One way to simplify a complex problem is to clearly define our expected behavior. Ask youself: "Why is this a problem? Exactly what behavior am I seeing that I shouldn't be seeing?/Exactly what behavior am I missing that I should be seeing?"
We need to clearly define the parameters of the problem if we are going to solve that problem. Once we start experimenting with new code, we need to clearly define what we expect to happen with each change we make. Going back and forth between writing a line or two of code, and viewing the results of our changes, we can can gain a better understanding of the impact of our code.
Ask Questions
If you feel like you're ready to throw your computer out the window, its time to stop coding and start asking questions. The specific set of resources available to you may be different depending on your situation. If you're in a class with other students, ask a fellow student or a teacher. If you're a junior dev, ask a co-worker or a senior team member.
There are some resources though that are available to everyone:
- Google it! Developers at all skill-levels Google things every day. This is a real and valuable programming skill and you shouldn't shy away from it.
- Ask a question on a forum like Stack Overflow. Stack Overflow exists because people want to help you solve your problem. Use it!
- Go to a meetup. There are lots of excellent meetups geared to beginner programmers, as well as meetups that function as study groups with people volunteering to answer questions and help out. Get out there and meet some other programmers!
- Ask a friend or classmate. If you're taking an online or in-person class, talk to the other humans learning to code with you! They almost certainly don't bite and are very likely to be struggling with questions of their own too.
And here's the icing on the cake--asking questions is an important skill to develop as a programmer. You will never stop facing tough challenges or learning new things, and your ability to ask clear and concise questions will always be an asset to you. So practice early and often and don't hesitate to reach out for help.
Rubber Ducking
Have you ever asked a question of a friend, co-worker or teacher only to stop yourself halfway through an realize--"I got it!"
Well, there's actually a name for that in programming: Rubber Ducking.
Here's how it works: By articulating the problem, you gain an understanding of what your program does, vs. what you expect it to do, and why it doesn't do what you expect it to. Beyond that, by taking a step back and explaining the problem to someone else, you look at it from a new perspective and often gain a new understanding of the issue.
There are lots of ways to engage in this practice.
- Talk to a friend or roommate--they don't have to know anything about code, they just have to be willing to listen to you :)
- Talk to a co-worker or classmate
- Talk to an inanimate object--like an actual rubber duck!
It's all about taking a step back and articulating the problem in order to look at it differently.
Take a Break
When you're stuck, frustrated and confused, you have two options for dealing with those feelings. Ignore them, push ahead and exhaust your self (I cried, remember?). Or, take a break!
Even if you're break only lasts a few minutes, stand up from your desk, move around, think about something else for just a little while. Often enough, when you revisit the problem with fresh eyes, the solution will jump out at you.
This is the hardest piece of advice for a lot of us to take. When we are right in the middle of a thorny problem, stopping to do something else for even a minute can feel counter intuitive and just wrong. But a tired and frustrated brain can't do much for you. Give yourself the break you need and deserve and you'll see the payoff when you revisit the problem.
Don't Give Up
Getting stuck is a terrible feeling. At best, it eats up time and energy, at worst, it makes you doubt your ability to move forward as a programmer. But getting stuck is one of the most common experiences you will have a developer. Don't be afraid of getting stuck; if you apply some of the principles laid out here, you don't have to be stuck for long.
Want More?
If you enjoyed this post, you should subscribe to Break In, an upcoming newsletter for people working hard to break into tech! Upcoming issues will include closer looks at some of the topics discussed here--rubber duck debugging, asking Stack Overflow questions, asking teammates and classmates for help, finding the right meetup for you, and more!