teaching strategies | Thought splinters

Using GitHub as a Mentoring Tool

Sun, 01 Aug 2021 00:00:00 +0000

Beginner, Intermediate, and Expert Level

For several years I am interested to learn R, the free software environment for statistical computing and graphics. After

reading several books,
finished some (paid) introductory (MOOC) courses successfully with Coursera
and especially some smaller (paid) projects

I would say that I am now (stuck?) on an intermediate skill level. I believe that this is the most challenging step in progressing to an expert for a self-determined learner. There are always so many different avenues to follow up. This is especially true with R and its

ever increasing amount of new R packages (To date: 20010 (MRAN) resp. 17954 (CRAN), 3452 (Bioconductor).
hundreds of books (see: the searchable list on r-project.org, a curated list on GitHub by Roman Tselgelskyi, but also my Wakelet on free R Books
an unknown number of (free) online tutorials (see the general list and university listed free R tutorials by Pairach Piboonrungroj and my Wakelet on learn R programming)

Comparing my skill level with the three learner paths suggested by RStudio Education, I could affirm my personal assessment. From the six tasks proposals on the intermediate path

grab some R cheat sheets
learn to get help (see, for instance, my activities on StackOverflow)
improve your visualizations
develop interactive applications with htmlwidgets and Shiny
simplify your model explorations with tidymodels
explore other specialized packages

I have some skills with the first three, and I also experimented already with Shiny. I even had worked on some steps at the expert levels by writing an R package: (bib2academic got 16 stars, but I did not manage to submit it to CRAN. It is now obsolete as a similar function was integrated into the Academic Hugo website (now Wowchemy website builder).

Project for Motivation Necessary

But to continue this path, I would need some strong motivation. I tried, for instance, to read the (not yet finished) book Mastering Shiny. As with all books and papers by Hadley Wickham, it is well written and exciting. But to learn continuously, I would need a practical project where I get not only real-world challenges but also a strong personal motivation to complete the product. In finishing the project/product, I would have to learn to overcome several real-world challenges where I would need to look for help and consult/experiment with several new functions or packages.

But this strategy has two advantages:

It is very laborious as the specific questions are not (yet) clear enough. Fora like StackOverflow are not suitable as the problem space is not delimited, a concrete coding question with a REPREX (REPRoducible EXamples) is not available.
It is error-prone and not efficient. Am I posing the right question? Do I look at the right places? It is not guaranteed that one finds the optimal solution. This is particularly awkward if the answer in the R community is very well known.

Looking for a Human Mentor

I believe with a mentor, one could overcome these insecurities fast. The mentor — an experienced user — could ask questions to narrow the search space and point out helpful hints about what and where to look. Wikipedia, for instance, has established a similar program for their user community called Adopt-a-user.

The Adopt-a-user program is designed to help new and inexperienced users by pairing them with more experienced Wikipedians. These editors (referred to as adopters or mentors) will “adopt” newer users, guiding them along the way as they learn about Wikipedia and its various aspects. (Wikipedia)

In Wikipedia, the intention is to help novice contributors get orientation and some guided practice with the very complex rule set for writing or changing Wikipedia entries. My thought is to find a mentor to advance at the intermediate level. I think there is plenty of material for the R beginners freely available. But more important: You will learn R from scratch as an individual and do not need to worry at the beginning stage about an already developed complex rule which you have to observe and follow.

As far as I know, there is no mentor program for R users. The next best alternative is a more open and friendly community. An excellent example, in my opinion, would be the RStudio Community. But even there, you should have a concrete question to ask.

GitHub as a Mentoring Tool

An instructive example

I recently found out that GitHub could be used as an educational tool. I will you give an example which was very exciting for me:

Often I was confronted with the problem of how to calculate and format nicely a contingency table in R. The free web material on the web on this question is abound (e.g., Datacamp, Data Science Central, R-Bloggers, TechVidvan, Statology, …). But many examples still teach the Base R commands. They do not mention new procedures with the tidydata approach and related packages like tidyr. And they do not worry about outputting the table in a publishing-ready format.

There are many contingency tables published in the recently finished books Introduction to Modern Statistics.

Table 1: Descriptive statistics for the stent study.
	30 days	365 days
Group	Stroke	No event	Stroke	No event
Control	13	214	28	199
Treatment	33	191	45	179
Total	46	405	73	378

I could look up the source code from lines 85-101 via GitHub and learn how to produce the above table. (In the following code chunk, I have focussed on the table appearance and left out different previous data transformations to prepare the two data sets stent30 and stent365. Furthermore, the code differs somewhat from the original due to some CSS styles of this website.).

```{r stent-study}
suppressMessages(library(janitor))
suppressMessages(library(kableExtra))
suppressMessages(library(openintro))
suppressMessages(library(tidyverse))

stent %>%
  mutate(group = str_to_title(group)) %>%
  pivot_longer(cols = c(`30 days`, `365 days`), 
               names_to = "stage", 
               values_to = "outcome") %>%
  count(group, stage, outcome) %>%
  pivot_wider(names_from = c(stage, outcome), values_from = n) %>%
  adorn_totals(where = "row") %>%
  kbl(linesep = "", booktabs = TRUE, caption = "Descriptive statistics for the stent study.",
      col.names = c("Group", "Stroke", "No event", "Stroke", "No event"),
      table.attr = "style='width: 75%;'") %>%
  add_header_above(c(" " = 1, "30 days" = 2, "365 days" = 2), extra_css = "border-bottom: 2px solid") %>%
  row_spec(1, extra_css = "border-top: 2px solid") %>%
  row_spec(3, extra_css = "border-top: 2px solid") %>%
  kable_styling(bootstrap_options = c("striped", "condensed"), 
                latex_options = c("striped", "hold_position"),
                full_width = T, position = 'center')
```

Lesson learned

Looking into the source code at GitHub, I learned several issues:

I experimented already with the janitor package, and I am happy to get the confirmation that it is a widely used package to “provide quick counts of variable combinations (i.e., frequency tables and crosstabs)” and to “format [nicely] the tabulation results.” (From the Janitor package description.)
I also did know about the kableExtra package and had the kable_styling function already used several times.
The other kableExtra functions (add_header_above(), row_spec(), kbl()) I had not used before. Especially add_header_above() has an important role for special headings in contingency tables.
The parameter extra_css was entirely new for me. I have never heard about it and didn’t even know that it exists.

For me, this learning experience was very instructive! I admit that this example could have been asked via a friendly forum: For instance: “How could I produce a contingency table formatted professionally for print by using the tidyverse approach?” Additionally, one would have to provide some code to show where one stands and what approach one is using.

Looking Experts over their Shoulders

But this was just one example where I knew about the problem and had already tried several approaches to find a solution. But what about code patterns I didn’t even know and could therefore not ask the right question?

Finding a GitHub project with code snippets one needs urgently is just the beginning. There is a big chance that the same repository (aka ‘repo’) hides more code snippets to learn from. And maybe the person behind this one GitHub repos maintains other repositories that are also very interesting?

In my case, it turned out that Mine Çetakaya-Rundel, one of the authors and the person responsible for the repository management, has educational approaches that are similar to mine. But she is way off more skilled in R and statistics. I am especially interested in her usage of the learnr package for interactive tutorials and have watched a series of three videos on Teaching Statistics and Data Science Online.

In a certain sense, she functions as a mentor for me — even if she doesn’t know about it 🥸. Meanwhile, we had some exchanges on GitHub issues as I am interested in learning how to use the learnr package for introductions into statistics via R-Tutorials. Regularly if I find a problem as a user reading and following the tutorial exercises, I try to fix the code in my fork and send the solutions as pull requests (PR) to Mine. Besides learning to use GitHub in a collaborative setting, I have already profited in many ways. I learned about packages I have never heard of (see, for example, the list of packages used for the book) and saw code snippets that transformed data in a much more elegant way as I used to do.

Summary

To inspect code on GitHub is a suitable strategy for intermediate (programming) learners. I illustrated it with an R example, but I think you could generalize it as a learning strategy. I recommend the following steps:

Note names and/or repositories you learned from successful internet recherche. By searching answers or asking questions via StackOverflow, you will encounter the same names, blog addresses, Twitter messages, repos again and again.
Look around if these person/websites generally work on problems you are interested in. Look into the profile and follow the activities of these persons on their blog, Twitter, YouTube, GitHub … accounts.
Decide on a person and select a specific project. I recommend focusing not only on a particular person but also on picking one project to concentrate on. Ideally, it is a current project the person is still interested in and produces code you want to learn and use for your own work later on.
Think about a possibility to get involved in the project. The idea is to give the person and the community something back for its/their mentoring function and commit yourself to relevant real-world problems. The possibilities depend on your skills and interests. It may be advertising the project, writing a favorable review, fixing typos, commenting via the issue part of the repo, recommending code changes via PRs, or financially supporting the author(s) and/or the ongoing project.

Finally, I would like to add also a warning: “Following” a person should not develop to stalking. It is essential not to be intrusive or pushy. You will see already after a short time if the person values your contribution(s), e.g., by answering friendly or thoughtfully, accepting your PRs, etc. If you get the impression that your engagement is disruptive, then stop it immediately. Either look at the code silently without interaction or try to find another “mentor” or project to get involved.

What is obvious, and for whom?

Tue, 17 Oct 2017 00:00:00 +0000

In the last few weeks, I tried to work with bookdown, an R package developed by Yihui Xie. This program is/was for me much harder to understand, unlike blogdown by the same author. In blogdown, I could even – after some initial problems – write a tutorial which even the developer applauded :sweat_smile:.

But with bookdown, it was different: Not only that I misunderstood some program functions but more importantly, I could not adequately report my problems in one case, I did not communicate vital information in the other case I did not look at the right place where my question was explicitly addressed. It is not a surprise that Yihui Xie got angry with me and even wrote a blog post about the incident. He gave me the advice:

Please do not make these assumptions when filing issues

Be aware: This is a somewhat theoretical/philosophical discussion.

For me, as a professional educator, this is a fundamental question. Where to start with explanations and where to stop? Should I provide just the information to solve the problem, or should I give some background information? What kind of advice should I give to prevent similar issues in the future? These are examples of questions I have to consider as a teacher all the time. But this time, I am on the other side of this communication exchange - I am the learner and student, and I am the one who has to ask the expert.

Yihui Xie is not blaming me as a user, as he wrote in his last paragraph of the mentioned blog post. You can see his positive attitude in the post on The Minimal Reproducible Example Paradox where he is complaining that many users do not provide a minimal reproducible example or do not know how to produce one. He comes to a somewhat depressing conclusion:

How many times have I reminded a user of posting a minimal, self-contained, and reproducible example (reprex)? Probably 500 times. How many times do I think I will still need to remind users of this? Perhaps 5000 times.

But again: This is a typical situation we have in education as well. We are explaining the same thing over and over but — to different people, students, learners, classes, etc. Even if we explicitly mention common errors and misunderstandings, some learners will always commit these mistakes. When we describe operations you should not undertake, you can be sure there are one or two who will follow precisely these wrong paths.

Tacit knowledge and language games

So what? Are people dumb? Do they deliberately ignore advice? I don’t think so, but instead, there is a gap which cannot be overcome only with linguistic means. It is also a question of transferring tacit knowledge’ to use a notion introduced by Michael Polanyi:

I shall reconsider human knowledge by starting from the fact that {{< hl >}}we know more than we can tell{{< /hl >}}.(Polanyi 2009)

Many philosophers (e.g., Søren Kirkegaard, Ludwig Wittgenstein, Gregory Bateson, Susan Langer, Jürgen Habermas, Nelson Goodman, to name a few) have reflected about the limitation of linguistic expressions. Wittgenstein, for example, has pointed out that we cannot explain the meaning of every word or sentence because we have to use language with other words and sentences. It is an endless regress that we cannot solve with language alone. We have to share a common ground, and we have to know how “to play the language game.” Following some quotes to give you a flavor of the argument:

One has already to know (or be able to do) something to be capable of asking a thing’s name. But what does one have to know? (Philosophical Investigations 30) … When one shows someone the king in chess and says: “This is the king,” this does not tell him the use of this piece-unless he already knows the rules of the game up to this last point. (31) … Someone coming into a strange country will sometimes learn the language of the inhabitants from ostensive definitions that they give him; and he will often have to ‘guess’ the meaning of these definitions; and will guess sometimes right, sometimes wrong. (Wittgenstein 1961)

To use a famous philosophical example (Quine 1960): If I point to a white rabbit and say in my foreign language, “Gavagai!” you have to guess the meaning. Do I say, “There is a rabbit!” or “Look at the nice white color!” So even an ostensive definition is under-determined and does not help to choose the right interpretation and to solve the ambiguity of meaning in our speech acts.

One proposal which could serve as an avenue of escape for this gap or paradox is to invent a special kind of notational system. Common examples to demonstrate this strategy is chess notation or musical notation. I believe that a minimal reproductive example or to deliver the sessionInfo() is also a kind of notational system. But the problem is the same: One has to learn this (new) language to use it correctly.

Many different layers

The malice of the situation is the assumption that from the fact that we are using the same (English) words and sentences that we communicate the same meaning and understand to each other. The expert believes that (s)he has expressed every necessary information and so the novice in asking a question. – And this is mostly correct – from his/her point of view or understanding.¹

I have reflected why for me, using bookdown was so much more complicated than blogdown. I started several months ago with bookdown, but I gave up and started another trial after I had some success with blogdown. This sequence seems weird as it appears that for Yihui Xie, the situation was inverse.²

I think there are different reasons:

Blogdown was written together with Amber Thomas and Alison Presmanes Hill. It was an excellent inventive and successful strategy to integrate authors who can provide the perspective of the user side. In the blogdown book, there are some beneficial chapters about action strategies. They give, on the one hand, practical tips and contain, on the other hand, some (technical) simplification. We, educationalists, call this method “pedagogical reduction”). I refer to chapters like A quick example or A recommended workflow.
The success in working with blogdown is more straight and comes in smaller bits and pieces. You write a sentence with Markdown in your blog, and you can see the result immediately. It seems - at least for laypeople like me - that in blogdown, there are not so many hidden conversion processes as this appears to be the case in bookdown. Bookdown, by definition, provides the means for cross-media publishing resulting in three different products (website, PDF, and ePub), all three with their underlying structure and rules.

The importance of mental models

But there is one common point why both blogdown and bookdown are intrinsically difficult to understand for novices: Many different layers of software are working together to produce the result. I am not sure if I am even able to enumerate these different layers correctly: There is

the used hardware,
the operating system,
R with all its various packages,
the programming and writing environment RStudio,
Rmarkdown using pandoc,
knitr,
blogdown or bookdown,
the used theme,
with needs for adoption CSS knowledge,
git and GitHub,
and last but not least, Netlify.

All of these different tools work on top of each other and/or together. And all of these different levels have their complexities, laws, functions, manuals, commands, etc.

As long as everything works fine, there is no need to understand the different parts and their interaction and/or synergy. But when something breaks down, then a shift of focus occurs, or as Heidegger says, the worldliness becomes obvious, changing tool usage from “ready-to-hand” to “present-at-hand”(Heidegger 2008). In “ready-to-hand” awareness, you are using tools to fulfill their purpose (to write a blog post); in a breakdown (= “ready-to-hand” awareness), you get consciousness of the complexities inside your tools machinery.³

But here comes now the problem: As users, we are only experts in “ready-to-hand” awareness, and we have no clue about the functionality inside the black box. We can only report some weird behavior about some experienced phenomenon from the “ready-to-hand” perspective. We, laypersons, have constructed a mental model about the functionality of our tools, and we are reporting about the problems with the underlying implicit assumptions of our mental model. The mental model functions as a world view: We see all the different objects, people, etc., under a particular perspective guided by our underlying tacit assumptions.

After the breakdown, we should question our mental model, but this is very difficult: Our worldview has worked successfully so far. One will not change the world view with just one different fact. The same happens with scientific theories: One other point is a challenge to elaborate on the theory, improve it, and incorporate the anomaly into the argument. Maybe the problem lies in the reluctant fact itself (e.g., the software has a bug, or the author misreported the effect).

Lesson learned

So what the fuss with all these abstract ideas? Where is the practical impact of all these considerations? — I make the case in this article that we should focus separately on two different kinds of explanations:

On the one hand, we users need “ready-to-hand” reasons which are easy to follow even if they are simplified and do not cover all eventualities. We need guidelines, step-by-step (video)-tutorials, etc. Are there shortcuts, tips, and rules of thumb one could follow? And we would need tons of examples! But people who provide this kind of explanation should be aware: This explanation always is under-determined and cannot prevent misunderstandings. Lacking the necessary knowledge, we still have to interpret what “Gavagai!” means.
On the other hand, we users need at the same time “present-to-hand” explanations to build up correct mental models of the inherent complexities and functionalities of the tools. Which software components rely on which other parts? What is the task of component X, and how is it related to the ready-to-hand functionality? But people who provide this kind of explanation should be aware: This level of explication is not a technical one, not directed to other experts. (This is another critical third level of description and documentation, one I will not cover here in this article). So we would need individual formats like diagrams of the interconnectedness and synergistic effects. The result is a kind of multiple representations and would provide additional access to discover the functionality of different parts of the software machinery.⁴
A piece of advice like “Please do not make this assumption when filing issues.” are basic ethical guidelines but not very practical and helpful. We are always using (implicit) assumptions. In stating one proposition, we rely on a set of different assumptions; otherwise, we could not use language and construct meaningful sentences. The problem is to know what assumptions are to test and what assumptions are to rely on.⁵

There is no possibility to examine all belief systems at the same time. The whole book “On Certainty” by Ludwig Wittgenstein Wittgenstein (1975) is full of aphorisms about tacit assumptions we rely on. Our knowledge does not consist of separated propositions but is a system of interconnected views/opinions. I will close this post with some quotes by Wittgenstein to illustrate this point.

§139. Not only rules, but also examples are needed for establishing a practice. Our rules leave loop-holes open, and the practice has to speak for itself."

§142. It is not single axioms that strike me as obvious, it is a system in which consequences and premises give one another mutual support.

§144. The child learns to believe a host of things. I.e. it learns to act according to these beliefs. Bit by bit there forms a system of what is believed, and in that system some things stand unshakeably fast and some are more or less liable to shift. What stands fast does so, not because it is intrinsically obvious or convincing; it is instead held fast by what lies around it.⁶

StackOverflow for instance, is very, very good for “ready-to-hand” explanations but does - as far as I know - a lousy job for building up mental models. Discussions about different but similar software packages, their advantages and disadvantages are forbidden.⁷

References

Heidegger, Martin. 2008. Being and Time. Reprint. New York: Harper Perennial Modern Classics.

Polanyi, Michael. 2009. The Tacit Dimension. University of Chicago Press.

Quine, Willard Van Orman. 1960. Word and Object. The Mit Press.

Wittgenstein, Ludwig. 1961. Philosophical investigations. New York: Macmillan.

———. 1975. On Certainty. Revised ed. Oxford: John Wiley; Sons Ltd.

I could tell some jokes about misunderstandings between Germans and Austrians, both using German as their native language. ↩︎
He said that blogdown was especially complicated to develop, but I cannot find the place at the moment to quote it correctly. ↩︎
For an understandable description of the philosophical concept of ‘breakdown’ read this example on Human-Computer Interaction ↩︎
An essential step for me in understanding the complex template structure of Hugo was to write in every template the sentence: “This here is the template ” and to see what happens in different situations ↩︎
BTW: This is the same conclusion as Yihui Xie has drawn: “To clarify, I’m not blaming this user. I can totally understand it. Many users do the same thing. The problem is that there are so many possibilities for software to screw up, so you have to describe everything clearly to eliminate as many possibilities as possible.”— So we do have the same analysis. Still, I propose (in addition to reflect and report all hidden assumptions) another new long-term strategy (namely helping to build up correct mental models about the complex software dependencies) to prevent similar faults as I have committed. ↩︎
To prevent a possible misunderstanding: I do not think that only or even predominantly software engineers are responsible for the two mentioned explanation levels. Their expertise is to develop programs, document them, and resolve bugs. I just want to point out that there should be more focus on these two levels and that more people should be concerned about providing information on these two levels. ↩︎
At least this is *my* mental model from StackOverflow For instance, the moderator closed my question about the difference between packrat and checkpoint as off-topic. ↩︎