Getting unstuck – EDS 240

A large part of being a data scientist is ~being okay~ with not immediately knowing the answers to your code challenges – troubleshooting errors, deciphering code, and trying new things (and likely failing at some…er many…of them) is all a part of the job. We all experience it, no matter how many years we’ve been at it.

A cartoon of a fuzzy round monster face showing 10 different emotions experienced during the process of debugging code. The progression goes from (1) 'I got this' - looking determined and optimistic; (2) 'Huh. Really thought that was it.' - looking a bit baffled; (3) '...' - looking up at the ceiling in thought; (4) 'Fine. Restarting.' - looking a bit annoyed; (5) 'OH WTF.' Looking very frazzled and frustrated; (6) 'Zombie meltdown.' - looking like a full meltdown; (7) (blank) - sleeping; (8) 'A NEW HOPE!' - a happy looking monster with a lightbulb above; (9) 'insert awesome theme song' - looking determined and typing away; (10) 'I love coding' - arms raised in victory with a big smile, with confetti falling.

Artwork by Allison Horst

Where to find help

We often learn the most (and remember more of what we learned) when we take the time to troubleshoot on our own (or at least narrow down the potential problem(s)), so you should always plan to start there . The graphic below shows the order in which you should approach different resources for help:

A flow chart showing the steps you should take if you're looking for help on coding problems. First, you you review course materials, check out the suggested background reading, and Google for help. Next, turn to peers (especially your learning partners for the week) -- the best ways to do so are to talk with them in or out of class, or share your question in the #eds240-data-viz Slack channel. Third, turn to your TA by asking them questions in discussion section, by attending their student hours, or by sending them a message over Slack (preferrably in #eds240-data-viz). Lastly, reach out to your instructor by attending student hours or by sending them a message over Slack.

Roadblock checklist

If you hit a roadblock, run through this checklist to make sure you’ve done your due diligence before bringing your question(s) to a peer, TA, or instructor:

revisit the course materials – your question may already be answered in the slides
read the documentation – you can do so directly from RStudio by typing ?function_name in the console
search for and read the package’s, vignette if available – these are often linked on CRAN under the Documents section (e.g. see {dplyr} on CRAN) or found by Googling package_name vignette (e.g. the result of Googling dplyr vignette leads to the dplyr vignette)
try Googling! – don’t forget to a look back some of our suggested troubleshooting and Googling tips in Teach Me How to Google:

How to ask questions

When you decide you’re going to ask a question to a peer / TA / instructor, be sure to (borrowed from Dr. Allison Horst’s Troubleshooting 101 lecture, EDS 221):

Provide context. For example, “I’m trying to do this…” or “I’m working on the task where we do this…”
Share the specific challenge. “I’m specifically trying to [insert function / package] to do this thing.”
Share what happens and what you’ve learned. “I repeatedly get an error message that says [this]. I’ve tried [this] and [this]”
Show your code ideally with a reprex that they can run / test.
Value and expect the Socratic method, especially in classes and workshops – our goal is to provide critical thinking that is transferable, not just to provide a quick fix for a single error.

Some words of wisdom

Finally, Julia Evans shares some funny (and highly relatable) words of wisdom: