Do you ever have moments in which you doubt your abilities to use a keyboard and a computer to write a few lines of code? Here is the short story of one of those moments in my life...

I started to write a little function, let's call it .plot_yearly_averages() to add a graph with some averages per year. Once I was happy with the result, I added the function to an existing  R6 class, as a private method.

While running some tests, I realized I have to handle some corner cases, so I modified the function accordingly. To my surprise, the code ran, but it behave unexpectedly, it was like it never heard about my corner cases. Naively, I thought: oh, no problem, it might be that the old definition is still in the global environment, let's clean it. Click on the little broom in RStudio, the notice "Environment is empty" appeared, restart testing, still the old definition...

A more careful look at the class definition, and I realized that I forgot to prepend the function call with "private$", meaning the old definition was indeed used, and not the intended private method.

I found the error, but I decided I have to understand what was actually happening, just to avoid such stupid mistakes in the future.

Here are my learnings. Let's assume two functions:

foo <- function() {
  print("foo")
}

.bar <- function() {
  print(".bar")
}

Calling them produces the expected output:

foo()
[1] "foo"
.bar()
[1] ".bar"

Removing R objects from the global environment is usually done like this:

rm(list = ls())

If you do this, you'll notice that the foo() function definition disappears from the Environment pane in RStudio, and the pane appears empty. But you can still call .bar(), and you get the output.

A closer look to the help for the ls function gives a clue:

?ls
ls(
  name, 
  pos = -1L, 
  envir = as.environment(pos),
  all.names = FALSE, 
  pattern, 
  sorted = TRUE
)

# where 
all.names "is a logical value. If TRUE, all object names are returned. 
If FALSE, names which begin with a . are omitted."

Objects which have names beginning with a dot are referred to as "hidden objects" in RStudio, also the help of ls() does not mention anywhere the word "hidden".
Actually, when clicking on the broom icon in RStudio, there is a checkbox which you need to click if you want to remove also these objects. 

RStudio broom icon

Since I had no idea what hidden objects are, this did not help me.  I find it counterintuitive to add a checkbox for hidden objects for which there is no obvious definition, and which are not shown in the environment pane. More, the notice after the removal is "Environment is empty". This is not true, since hidden objects might still be there.

I found an open RStudio issue with a user requesting an  option to show "hidden" objects starting with . in Environment pane. This would have helped me a lot...

In hindsight, I see an analogy with Linux file system. There, files starting with a dot are usually hidden, because they have a special meaning (e.g. shell settings). 

But I wonder if all this needs to be so complicated. There is a famous design book The design of everyday things by Don Norman. The idea there is that design is successful if the usage of objects is obvious, not requiring explanations. Just search for the term "Norman doors" on the internet to see what I mean...

How things are built and how easy/difficult is to use them has a big impact.

A short true story on that: somebody working in an office orders in December 2023 a desk calendar. She received a pdf file from the colleagues taking care of the  office supplies, so she can point to the page in the pdf file to indicate which calendar she wants to have. The calendar comes in January: it's one with 3 visible months, on a black plastic support, with 2 buttons on the side, which you can rotate to slide the calendar. The visible months: December 2023, January 2024 and February 2024. January passes by, February is there, and then somebody in the office has the idea o slide the calendar to show the month March. It turns out that this does not work. Because the calendar ended with February 2024. You guess by now, this was a calendar for 2023. Of course, there is no point to order a 2023 calendar in December 2024...
  
I imagine this mistake could have been easily avoided by making visible for which year the calendar was...
  
Still not convinced that design is important? Last story for today: I once had the occasion to test a car which was somewhat special. I get in, I try to set the address in the navigation system, after 10 minutes of unsuccessful tries, I realize I have 2 choices: either call one of my colleagues, who previously tested the car. Or read the manual. I chose the manual. After another 5 minutes, I was good to go.
  
In my naive imagination, there should be no need to read the manual to be able to use a car navigation system. My first reaction: well, you obviously don't have enough experience with cars. But then I noticed something strange: there was no address saved at all. Of course, it could be that the previous drivers just deleted them for safety reason.
  
The next day in the office I tell the story. A colleague, who tested the car before me: well, I had the same problem, I gave up after 2 minutes, since I new the way anyway...
  

Make a promise. Show up. Do the work. Repeat.