DEV Community

loading...

How to Get Un-Stuck

Sophie DeBenedetto
Engineer at GitHub, graduate of + former teacher at Flatiron School. Cat lover, but I admit I have a dog. Supporting students and junior devs through https://www.break-in.tech/
・7 min read

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

  1. Isolate the problem
  2. Experiment
  3. Understand Your Expectations
  4. Ask Questions
  5. Rubber Ducking
  6. 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!

Discussion (14)

Collapse
phlickey profile image
Phil

Always find it reassuring when people say articulate this. It is one of the most demoralising experiences. While it might not be unique to software, (watch professional chef Brad Leone descend into existential dread trying to make pizzelle cookies) it certainly is something that every dev will face. I'm trying to get better at using the tools you list above and recognizing when I'm making things worse :)

Collapse
sophiedebenedetto profile image
Sophie DeBenedetto Author

Thanks for sharing! I’ve actually been on the lookout for content like this—examples of people in non-tech indristries struggling through similar challenges we face as devs.

Collapse
jackharner profile image
Jack Harner 🚀

I'm one of two technical people at my job. I find it therapeutic to rubber duck off non-technical people. I'm typically able to translate the problem into layman's terms so they can understand. By thinking bigger picture and simpler it helps lay out the problem and usually the solution is clear, just got to zoom out a bit.

Collapse
juanfrank77 profile image
Juan F Gonzalez

I think I got the biggest amount of roadblocks, spinning my wheels and getting stuck last year doing Android development. The most frustrating experience I've had in my career so far cuz it was a mix of not having the right tools, not knowing the environment, not having anyone close to ask things to and having a quite short-for-the-project-scope deadline.

I'll keep these steps somewhere handy next time I encounter another block, think I naturally do most of these already but it only happens after the first 6 hours of struggle and head banging against the desk.

Collapse
sophiedebenedetto profile image
Sophie DeBenedetto Author

So true that it’s easier to follow steps like this after your first 6 hours of head banging! Just yesterday I was stuck on such a frustrating bug and only at the end of the day did I force myself to step back, relax and look at it with fresh eyes. Which is when I finally solved it :)

Collapse
dougmckechie profile image
Douglas McKechie

Fantastic post with some great advice. It really works.

Was also great to learn the name of the situation when you explain something to a colleague and in so doing come up with the answer - Rubber Ducking. That's happened more than a few times :)

Collapse
gbreen84 profile image
Ger Breen

Thank you Sophie. Just checked out tunecore as I had never heard of it before and I came from the music background. Will be sending a few friends over to your site to check it out, looks great for independent artists.

Getting stuck with college assignments is terrible but to know that professionals are in the same boat gives great comfort that we can all work through it and once we take the right steps get our bugs fixed :)

Thanks again

Collapse
liana profile image
Liana Felt (she/her)

Great post

Collapse
luqman10 profile image
Abdul Qadir Luqman

One strategy I use a lot is talking to myself. I try to explain the intent behind my code to myself and it mostly works.

Collapse
ikemkrueger profile image
Ikem Krueger • Edited

You are your own rubber duck. xD

Collapse
ikemkrueger profile image
Ikem Krueger

Whether your an experienced developer

Typo: you‘re

We had forgotten to include a tag in the

of the HTMl doc

Typo: HTML

Collapse
ikemkrueger profile image
Ikem Krueger

What I suggest is to use some version system like git, to hold the costs low for experiments.

Collapse
rafajrg21 profile image
Rafael Romero

I never would have thought that my favorite way of getting unstuck is called "rubber ducking"!! Loved this post