Here is how I spend more hours - sheer frustration, maybe it will be for use for others also.

Starting point: fix a bug in a package, write extensive tests, one particular test file  run successfully when run locally, but fails when running in parallel  (note: running in parallel is done a separate, new environment).  The error: "The R session crashed with exit code 2".

An internet search indicated that this exit code indicates a "suicide"  (assuming my employer watches my browser history, this might cause some eye brow raises...)

A few days ago, after fixing a bug, I decided to write more tests, to ensure the  bug won't happen again. There was an old function, using cat() to indicate the different stages of processing. The corresponding tests used testthat::expect_output and expected the message from the cat() call.

Of course I was tempted to change the message, so the tests immediately failed. I realized there must be a better way. A look at the documentation helped me with this issue.

I recently got badly bitten by functions with default arguments.

When writing code myself, I usually don't introduce default arguments. Until now, the only acceptable case to do this was for existing functions, which needed additional features, but the functions were used in multiple places, and making the change without default arguments would mean many modifications.

Now, I changed my mind. Note to self: forget default arguments, they don't exist. Really, forget them...

Yet another story from wandering through the R land... A few days ago I had to do with an R script, in which data was loaded from a database for a given date, nothing wild, something like:

A few days ago I looked at a table in a report, where numbers were presented together with some positive or negative delta, i.e. "42.42 (+0.42)", "20.12 (- 10.12)". I was about to refactor the code and this is what I saw:

Imagine it's Friday afternoon. Almost everybody left for the weekend, you want to do the same. But the phone rings: there is this script, which creates a file, which needs to be imported, but the import fails. You get a file, which can be imported successfully, now it's up to you to find out why the script does not do what it's supposed to do.

Here another result of interrupted thoughts. Does it happen to you to come into situations where it's obvious to you what the result will be, but not to the other persons involved?

Train, a young man with a bicycle. He leaves the bicycle leaned against the closed door, with the bicycle lock hanging on the handlebars, and hurries to  one of seats in the back of the wagon.

Coming back to work after holidays, the first line of code that I get to see makes me wonder if I forgot all the R code I know...

"This is stupid", I said to my colleague, pointing to a part of a code snippet he wrote. (This after months of which I repeatedly pointed out with various occasions, including reviews, that there are better ways to do it.)

By now you can imagine what followed: "Don't call me stupid" was the immediate answer that I received.