Wellness Wednesday: How To Be Your Own Rubber Ducky (And learning when you need a real one . . .)

/ By

Wait, rubber ducky?

It is well known amongst experienced coders that oftentimes simply explaining your problem step by step or problematic code line by line (outloud, to your rubber ducky, literal or figurative) usually helps lead you to the answer you were previously going in circles around. 

Popularized by the book The Pragmatic Programmer, a collection of tips to improve the development process in a practical, sensible way, this strategy forces you to change your perspective and can bring to light assumptions you didn’t realize you were making. 

In this article, we’ll outline strategies to leverage so you can attempt to be your own rubber ducky, before asking a friend or co-worker to lend their ears and brain to your problem.

How long you should spend being your own rubber ducky before you just ask for help will vary from problem to problem, but generally speaking, if you’re stuck for 30 minutes or more on the same problem and you’re not confident you’re making progress, it might be worth a quick sanity-check with a teammate to make sure you’re headed in the right direction. 

You should be aware, sometimes after successfully navigating the “rubber ducky process” you find the answer to your problem was actually painfully obvious, and you somehow spent all this time being confused as heck and you start to feel bad about yourself. You might start to think you’ll never be a “real” developer because if you were, you’d know Y or Z or you wouldn’t have written that bug or you wouldn’t have had to spend X amount of time researching the answer to some problem, or any mutation of trash-talking yourself.

In the biz, we call this rather annoying phenomenon, imposter syndrome. Because code is always changing, making it impossible to ever know everything, imposter syndrome can sometimes be a daily challenge, even for senior developers! Remember that coding is a meritocracy, you get out what you put into it. 

(And even very smart, clever people sometimes make very stupid mistakes.)

Steps To Being Your Own Rubber Ducky:

  1. Pulse check
    1. Are you feeling calm, cool and collected? Or frustrated, annoyed and grumpy?
      1. Working with code can sometimes be super frustrating, but nobody does their best problem solving when their emotions are running high, so your first step is to cool off. 
      2. Try one of the following:
        1. Take 10 minutes to go for a walk, preferably outside. 
        2. Take 5 minutes to stretch. 
        3. Take 3 minutes to meditate. (Start a timer. Close your eyes. Focus on your breath and nothing else. When your mind starts to wander, just start to think about your breath again.)
        4. Close your eyes and take 5 deep breaths.
  2. Time check
    1. Have you been working (a.k.a banging your head against the wall) on this for more than 30 minutes straight?
      1. If so, double check your answer to #1 “Pulse Check”. You’re probably due for a breather, at the very least, close your eyes and take 5 deep breaths.
  3. Problem definition 
    1. What is the problem you’re trying to solve?
      1. Put the problem into 2-3 clear, concise sentences.
        1. A good idea is to type these up into a scratch file on your computer, or speak out loud to yourself. This is a crucial skill for a programmer and a huge step in the right direction of being your own rubber ducky.
        2. If you’re struggling with this, using the following guiding questions below to help.
          1. Why are you writing this code?
          2. What do you expect the code to do?
          3. What is the code actually doing?
  4. Error / Exception handling
    1. If your code is not throwing an error, skip to step #5.
    2. What does the error message say?
      1. Error messages and their contained stack traces vary significantly from language to language, but you can typically find the exact exception on the very bottom line of the error message.
      2. Once you’ve identified the exact error, use your noodle to think about what that error message is trying to tell you. If you’re still stuck, float on over to #5 to search for where others have encountered this error message. By understanding their solution to this problem, you can gain insight as to what your solution might need to be.
        1. In this example we know the error occurred on line 54, which resulted in a TypeError because we can’t loop over a single integer. Fix this by changing len(secret) to range(len(secret)).
        2. Example search string: “Python TypeError: int object is not iterable”
        1. In this example we know the error occurred on line 14, which resulted in a compilation error because in C# private variables can only be assigned to within the same struct in which they’re declared (in this case, it’d have to be within the Car class). Sometimes the fix isn’t obvious from the information you’ve found on the internet but doing this search would lead you down the path of understanding what private fields are in C# classes. Once you understand that, your problem evolves to “Why do I think I need to assign this value here? What assumptions have I made about the logic in this code base? Should that field really be marked as private?”
        2. Example search string: “C# inaccessible due to its protection level”
  5. “Let Me Google That For You” check 
    1. Is this a coding language specific problem that you can search the internet for?
      1. Every developer in the world utilizes internet search engines to help them figure out how to solve a problem. There are N number of coding-specific question/answer forums, documentation pages, and tutorials out there that are goldmines of information. That being said, before you execute any code you find on the internet, you must understand EXACTLY what it is doing. One more time for the folks in the back, BEFORE you execute ANY code you find on the internet, YOU MUST UNDERSTAND EXACTLY WHAT IT IS DOING. 
        1. Yikes, what’s with the dramatic capitalization? 
          1. It has happened countless times that someone ran a script they found on the internet and it resulted in some form of undesirable behavior (file deletion, virus attack, etc.). 
          2. But possibly even worse is you use the code and it works right away! You skip happily to put your code up for review. But someone asks, “hey what happens with this code in scenario X?” and you ain’t got a clue! If you can’t explain your code to your teammates or your teammates can’t easily understand what’s happening, it’s probably not code you should be using.
          3. Take the time to do the additional research upfront or do some line-by-line testing in an online IDE.
      2. Search Like a Pro: You can try searching for your problem by starting with the name of the language or tool you’re working with (Javascript, node.js, C#, Jenkins, etc.) followed by a few keywords or an excerpt from your problem definition (#3) or your error message (#4).
        1. Example Problem Definition: “My Python dictionary has another dictionary for one of the values, I don’t know how to interact with this kind of data structure.”
        2. Example problem search strings: “python nested dictionary”, “python dictionary as dictionary value”
    2. Is this a problem with code that is unique to the business logic of the company?
      1. Unfortunately, you’re likely not going to find much help on the internet for problems that hinge on proprietary applications. You can always try searching any internal documentation sources (docs, wiki pages). 
        1. Example Problem Definitions: 
          1. “My code receives data from our company’s WizzyWig application. I don’t understand what the field ‘KLM’ means or why the ‘ABC’ field is missing.”  
          2. “I’m getting an ‘access denied’ or permission-related error with the credentials (username/password) my application is using.”
      2. If you’re still stuck, you’re probably going to need to recruit some help from your teammates. But you’ve got one more trick up your sleeve, so hop on down to the next step.
  6. Last resort: Codebase omni-search
    1. Has your problem already been solved by someone else within your codebase?
      1. If you’re writing a completely net-new codebase, you’re probably safe to skip to #7.
      2. If you’re working with an enterprise-level application, there’s a good chance someone has had to work through the same or a similar problem that you’re encountering. Learning how to identify these scenarios can help you keep your code patterns consistent with what is expected by your teammates, such as: naming format of classes, variables, and functions, how to log error or debug messages, how to write your tests, how to type or value check, etc.  
        1. The shortcut for doing a “Find all in all files” in your codebase will vary by IDE, so you may need to do a preliminary search to figure out how to search all files for your specific IDE.
          1. Note: there are unique shortcuts for each IDE to navigate directly to a class or function’s definition. Learn the shortcuts for these, as that is a much more efficient use of your time!
        2. If you’re trying to figure out how to interact with an object (class, function, data structure, database objects like stored procedures, tables, views) that is unique to your codebase, do an omni search for that object’s name. Very possible to get tons of results here, but take a few minutes to look at how others have interacted with that object. Can you apply what you’re seeing to help you curate a better search within the codebase?
        3. Note: Keep in mind reading code is a skill in and of itself, it is much harder than creating your own code. Be patient with yourself. Go one line of code at a time. Research what you don’t understand. It is in your best interest to develop this skill as thoroughly as possible from the beginning! The more you do it, the better you will get, simple as that.
  7. Finding a “real” Rubber Ducky
    1. The key is to be cognisant of people’s time. To be clear, you should not feel guilty about asking for help, every single developer in the world has asked for help at some point. The best way to thank the person who’s helping you (and make it likely they’ll gladly help you again) is to put yourself in their shoes and think about what you’d need to know to be able to answer your question, before you loop them in.
    2. Here are a couple ways you can make sure you have your ducks in a row (use your discretion to pick and choose from this list as appropriate for your problem):
      1. Be ready to explain the problem you’re trying to solve. (duh.)
      2. Be ready to give background information on why you’re making the change (like a JIRA or issue tracking ticket number).
      3. Be ready to screen share and show them the exact lines of code you’re talking about, even demo the exact problematic behavior you’re seeing. 
      4. Be ready to share the link to the code you’re talking about in source control so they can access the entire codebase if needed.
    3. When you’re ready, reach out to a mentor or team member and ask if you could borrow their ears for a few minutes. You’re most likely going to be better off calling or video chatting with them, do not try to send a novel over email/chat messages. 

Further Reading:

Donate
Donate
Scroll to Top