Writing code? Stuck? No problem.

How’s my coding? Just ducky.

Alternatively titled:

• Oh, you stuck?!
• Software developers hate him…
• The brain unlocking system used by Bill Gates that Warren Buffet doesn’t want you to know about…
• One simple trick to get rid of acne… (wait a minute)

Oh, you get it. So maybe at some point in your programming career (or another career? This process works for so many careers), you have found yourself stuck. No? Well, thanks for getting this far in the article, but there is nothing for you here. If you are like me and you have found yourself on multiple (most) occasions stuck hip-deep in the code, the following process might be useful to you.

During a welcome week for new apprentice crafters at 8th Light, one of our directors, Doug Bradbury, gave a talk on the cycling from struck to unstuck. I found the talk motivating as all too often, I’ve found myself buried under a mound of code, imposter syndrome, and frustration. Let’s face it, learning can be difficult, and coding can be complicated. Learning how to code…

It be like that sometimes…

With Doug’s permission, I have written down his list to share with the world at large. As software developers, we look for patterns in everything we do. We have design patterns, architectural patterns, and anti-patterns. Best practices and well-documented procedures abound, but what happens when we’re stuck? We often find ourselves digging through the endless piles of snark in unnamed internet forums (rhymes with Snack Slower-Snow) or combing the tutorials on Youtube and Medium. This process can be time-consuming and necessary, but there are ways to streamline the process.

So here we go:

Read the error message

If there is something syntactically broke with our code, modern IDE’s will let you know. If yours does not, you should seriously consider switching. Even a simple line of code with an error in it will most likely produce a verbose error message in your terminal:

A small Python example would be:

greet = "Hello Snek!

Will provide the following:

File “py_stuff.py”, line 1
 greet = “Hello Snek
                   ^
SyntaxError: EOL while scanning string literalRead the error message

What happened? Well, let’s take a look at the error message.

• I know that in my py_stuff.py file
• I know that in line 1 there is something wrong
• I know that I have a SyntaxError
• I know that there was an EOL (end-of-line) error
• Ok Ok Ok Python even pointed at it for me, I see it!

I just forgot to put a closing in my code, natural fix, right? So let’s move on to step 2.

No Really, Read the Error Message

Boom! I got ya! In all seriousness, read the message before you go Google ninjaing off into the web. A slightly more complicated and admittedly more convoluted situation will be if we throw a class in the mix. This snippet of code will give us a longer error message when we break something:

a_class.py
class Snek:
    def __init__(self, name):
        self.name = name
def my_name_is(self):
        return name
py_stuff.py
from a_class import Snek
jeff = Snek("Jeff")
def who_is_snek(snek):
   sneks_name = snek.my_name_is()
   print("Hello my name is " + sneks_name)
who_is_snek(jeff)

What happens in this situation? We blow up:

Traceback (most recent call last):
  File "py_stuff.py", line 7, in <module>
    who_is_snek(jeff)
  File "py_stuff.py", line 5, in who_is_snek
    sneks_name = snek.my_name_is()
  File "/Users/charleskubiak/Desktop/projects/py_stuff/a_class.py", line 6, in my_name_is
    return name
NameError: name 'name' is not defined

Now we have a longer message to parse through:

• Something blew up on line 7 of py_stuff.py (my function call)
• My function broke down on line 5 of py_stuff.py (taking a valid method and saving it to a variable)
• Next, we see we broke down on line 6 of a_class.py (the return line of my my_name_is() method)
• Finally, we see that name has not been defined (it should be return self.name inside the function)

If we only look at the first line of the error code, we don’t know what’s going on. Error messages or tracebacks will draw a line through your code back to that pesky bug. Hello my name is Jeff.

Check your notes

Do you know what is less time consuming than searching the entire width * length * depth of the internet? Doing that same search of your carefully compiled notes…

You don’t have to search the whole internet if you take good notes!

I will admit that I did not keep great notes during the first part of my software development learning. Since hearing this point, I’ve made a concerted effort to stay organized notes on different IDE issues I’ve come across, links to useful tutorials, design patterns, and notes I’ve taken by hand from books. There are tons of ways for you to organize and compile your notes.

Google it

I present to you: The Internet.

If you haven’t encountered the issue previously or if you didn’t catch it in one of your notes, you’re probably going have to look it up on the internet. The good news is that people have been laying down code for so 70 odd years now, and someone has 1. Most definitely felt your pain & 2. Has been kind enough to document it somewhere.

Here are some issues that you will run into:

• It’s easy to turn to someone else and say, “Well, when I executed this line of code and I thought it was going to return the value of line 43 in my py_stuff class.”

Huh?

If you try throwing that into Google, you’re probably not going to get the answer that you are looking for. What you will get is a ton of bad results that take your time and lead nowhere. One of the skills developers learn is to harness the power of search engines.

Knowing how to ask for information is a considerable part of what we do every day. If you are struggling with your search, a great template to get you started is to take your error code and scrub the execution specific data out of it.

The last part of my error code above was NameError: name ‘name’ is not defined. We know that 'name' was specific to my program, so we should remove that and search for the generic answer.

• The search result might contain dated information. I’ve found this especially true when dealing with quickly evolving frameworks like React that have readily available, deprecated, and often labeled as dangerous.
• The search result might contain incorrect information. You will find that sometimes the most popular result some forums might be inaccurate.

Read the google search results

For all of the reasons mentioned above, you must fight your conditioning to grab that top link and latch onto it. For many searches, the top result may contain what you need, but don’t be afraid to dig deeper into listed results if the first one doesn’t yield a solution.

Read the google search results again

Not to beat a dead Commodore 64, but you’re going to have to get used to getting into those search results. I’m not kidding.

Rubber duck

Sure, you look like your crazy, but rubber ducking works. It doesn’t have to be rubber, and it doesn’t have to be a duck, but find something that you can focus on your attention on, and let them have it. Remember, in high school, when you had to read your papers out loud? (involuntary shudder) When we learn something on a screen or piece of paper, our brain tends to auto-correct small errors as we process them visually. When we say something out loud, our brain has another chance to say, “Wait a minute!”.

Think back to those days of book reports and career choice papers and how a sentence looked great on paper, read great on paper, and drug its nails across the chalkboard when you read it out loud. Your code can make that same noise.

Ask a peer

Co-worker, fellow student, internet forum hero, rando who’s coding on the other side of the coffee shop from you? There are people all around you that are struggling with the same things you are. Reach out and ask for help. People who work with code understand how frustrating it can sometimes be, and we software development professionals are excellent upstanding citizens always willing to lend a hand. TOOT! (get it? that was me tooting my own horn).

Honestly, that may not always be the case for EVERYBODY, but there are many resources and opportunities for interaction within the community. You have to be willing to reach out and ask for help. Admittedly, it’s not always easy exposing your ignorance on an issue to others (it ranks right up there with pulling your tooth), but sometimes you have to bite (pun intended) the bullet and get it done.

Ask an expert

Asking an expert can be daunting. If you have a hard time approaching your peers, it can be even more of an uphill battle to ask the 10X dev in the corner.

Technical experts:

• Like seeing new and exciting issues in their field of expertise.
• Dislike having their time wasted.

This whole checklist has been building up to this moment. If you have followed it, then you are helping to mitigate the chance that you will come across as wasting someone’s time before approaching them. By following this checklist, you can contact them with the hard-earned badge of confidence. Now when you approach an experienced developer or technical expert, you don’t have to worry that your question is going to be received negatively.

You can say, “Hey, I ran into this issue, and I saw this bit of information in the error message. I spent a few minutes matching it up to my code, and after I tried searching for Issue A and Issue B, I don’t think the results had the information I was looking for in it. When I ask Peer #1 about it, they weren’t sure of the answer either. Is there something else I should be searching for? Would you mind taking a look at the code with me?

Whew! You did it! This cycle will repeat itself over and over again until you are the expert.

Record it

Lastly, you’ve fought hard for this new-found knowledge. Don’t let it ride off into the sunset, never to be heard from again. Write that stuff down! Put it in your notes and reuse it. The act of rewriting what you’ve found into your notes will help cement it into your memory and make it easier to find the next time you run across the issue.

I hope this helps.
Good luck.
Happy coding.