"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.

In theory, I could have avoided saying something like this (actually, I can't - at least not yet...). Or I could have reminded the person that "you are not your code", so an opinion about your code is not an opinion about you as a person.

Here is the help manual page for shiny::observeEvent:

observeEvent(
  eventExpr,
  handlerExpr,
  event.env = parent.frame(),
  event.quoted = FALSE,
  handler.env = parent.frame(),
  handler.quoted = FALSE,
  ...,
  label = NULL,
  suspended = FALSE,
  priority = 0,
  domain = getDefaultReactiveDomain(),
  autoDestroy = TRUE,
  ignoreNULL = TRUE,
  ignoreInit = FALSE,
  once = FALSE
)

A typical usage example for me is this one:

shiny::observeEvent(
  eventExpr = input$do_trigger_job,
  handlerExpr = {
    # some
    # R expression
    # i.e. what to do when "do_trigger_job" is clicked
  }
)

Using non-default values for the additional arguments can make the code difficult to reason about:

shiny::observeEvent(
  eventExpr = input$do_trigger_job,
  handlerExpr = {
    # some
    # R expression
    # i.e. what to do when "do_trigger_job" is clicked
  },
  ignoreNULL = FALSE
)

Another approach is to change the order of arguments, leaving handlerExpr as last argument:

shiny::observeEvent(
  eventExpr = input$do_trigger_job,
  ignoreNULL = FALSE,
  handlerExpr = {
    # some
    # R expression
    # i.e. what to do when "do_trigger_job" is clicked
  }
)

This might not look like a big difference, in practice it turns out that the handler expression was very long (of course, this should be avoided - but hey,  sometimes this happens), resulting in bugs which could have been easily avoided if the arguments of the function would have been re-arranged...

Back to the question of my behavior: I knew that one important trait of successful people is that they manage to pause for a few seconds before reacting to an event (even just taking a deep breath helps a lot). 

I was annoyed, before reacting to the code snippet I should have taken at least a deep breath. I did not, so my reaction the event triggered an unproductive outcome:

event → reaction → outcome

While I knew this, I don't 'feel' it, and only very rarely manage to do it.

I recently read 18 minutes, a book by Peter Bregman. What made me thinking, was his advice to reverse the order:

event → outcome → reaction

That is, as response to an event, think of the outcome, THEN react.

In other words, here is what could happen in theory:

  1. Event occurs. React. (Some) outcome → most people
  2. Event occurs. Pause/take a deep breath. React. (Some) outcome. → level 1 to mastery
  3. Event occurs. Pause/take a deep breath. Think how to react. React. (Some) outcome. → level 2 to mastery
  4. [repeat step 3]
  5. [repeat step 3]
  6. ...
  7. [repeat step 3]
  8. Event occurs. Pause/take a deep breath. Think about what outcome you want to have. React accordingly. → become zen
  9. [repeat step 8]
  10. [repeat step 8]
  11. ...
  12. [repeat step 8] → stay zen

I'm still struggling with this concept, since at the first sight, it seems to be in contradiction with my nature - most of the time I'm an open book, I say what I think, even when I don't think much...

Nevertheless, I think it's a piece of advice worth to ponder about...

https://xkcd.com/974/ - The general problem

xkcd_the_general_problem

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