It has a column called Taxonomy_Substrate_or_Functional_Group
unique() returns a character vector
distinct_corals has more than 4 values in it
-1:4 evaluates to -1, -2, -3, -4
[-1:4] drops the first four elements from a vector
The result is the unique “corals” in the dataset (except the first four)
Step 2: Hypothesize
The error message says:
Error in `distinct_corals[-1:4]`:! only 0's may be mixed with negative subscripts
That leads me to believe the error is in the indexing. So I will prioritize these assumptions:
distinct_corals has more than 4 values in it
-1:4 evaluates to -1, -2, -3, -4
[-1:4] drops the first four elements from a vector
Step 3: Test
Begin with the assumption:
distinct_corals has more than 4 values in it
I’ll use the length function to test that assumption.
length(distinct_corals)
[1] 37
This assumption holds up - it’s not the source of the bug.
Step 4: Proceed
Move on to the next assumption:
-1:4 evaluates to -1, -2, -3, -4
Let’s check it out.
-1:4
[1] -1 0 1 2 3 4
This assumption fails - revealing the error in my mental model. Now I can fix both the bug and my understanding of sequences.
Your turn: find the bugs
There are 8 bugs scattered around the room.
Form eight groups, one at each bug.
Round 1: Brainstorm
For 5 minutes, brainstorm assumptions about how the code works.
Write down as many assumptions as you can, one per sticky note.
Round 2: Prioritize
Rotate to the next bug.
Go through the previous group’s brainstorm.
Pick the two assumptions you think are most likely related to the source of the bug.
Move those two sticky notes into the boxes above.
Round 3: Test
Rotate to the next bug.
Pick one of the prioritized assumptions from the previous group.
Describe a test for that assumption.
Round 4: Test
Rotate one more time.
Describe a test for the last remaining assumption.
When the loop stalls: make a reprex
Sometimes you work through Observe -> Hypothesize -> Test -> Proceed and you’re still stuck. Time to ask for help.
A reprex (“reproducible example”) is a small, self-contained snippet that lets someone else run into your exact bug.
Building one is a debugging tool in itself: about 80% of the time, making a good reprex reveals the source of the problem before anyone else even looks at it.
A good reprex is…
Reproducible
Include everything needed to run it: library() calls, any data, and the code itself. Someone else should be able to copy-paste and get your exact error.
Minimal
Strip away everything unrelated to the bug. Use the smallest, simplest data that still triggers the problem.
Self-contained
Don’t rely on objects that only exist in your environment. Build any data the code needs within the reprex, before the problem code runs.
Making a reprex
Write the smallest version of your code that still reproduces the bug.
Copy it to your clipboard.
Run:
reprex::reprex()
reprex() runs your code in a fresh R session and copies a nicely formatted, ready-to-paste version — including output and errors — back to your clipboard.
Paste it wherever you’re asking for help (Slack, GitHub issue, etc).
Before and after
❌ Not a reprex
“My mean() isn’t working, it just gives me NA, please help!!”
No code, no data, no error message — nobody can reproduce this.
✅ A reprex
y <-c(1, 2, NA, 4)mean(y)#> [1] NA
Runnable, minimal, and shows exactly what’s happening.
Ko, Amy J., and Brad A. Myers. 2005. “A Framework and Methodology for Studying the Causes of Software Errors in Programming Systems.”Journal of Visual Languages & Computing 16 (1-2): 41–84. https://doi.org/10.1016/j.jvlc.2004.08.003.
