reflection | Thought splinters

Blog writing barriers to overcome

Fri, 31 May 2019 00:00:00 +0000

Another year has elapsed since I wrote my last blog entry. At first, I thought the problem is only my English. But in the meanwhile, I see several other reasons why I do not blog for the new static website(s).

I will elaborate later on the following thoughts. At the moment, I want to list the possible reasons for my blogging abstinence:

I am still not comfortable with the new community I want to address with these blog entries.
The topics I want to cover are still relatively new for me so that I often believe that my reflections and discussions of these subjects are trivial and not worth reporting.
I am doubtful which of my different upcoming ideas belongs to my German weblog “Gedankensplitter” and which is better suited for the English community.
I am still struggling to get the focus right for my English blogging. In the last few months, I get a better feeling on which two topics I would like to concentrate: Open Science and Data Science. (More on these two topics and their relationship will follow in another blog entry.)
From my professional point of view, I still generate most of the experiences and material in German such Interviews, Reviews, Talks, Lectures, etc..
It is much more exciting for me to learn new things in R or about strategies for Open Science than to continue to blog frequently for my German weblog.
There is not enough time to write for both weblogs. I wonder how other people like Andrew Gelman write at least one blog entry every day, sometimes even 2 or three.
Coming closer to my retirement the necessity to foster my professional online presence is not so vital anymore.
The English language is also a barrier. I am not so comfortable and skilled to write in a witty and informal style as I am used to it in German.
And finally there are these enormous complexities with blogdown and Hugo. There are so many software layers to watch out with all their difficulties arising for updates, incompatibilities, and bugs. As I have not used these technological infrastructures on a daily bases, it happened that I either forgotten many details. Instead of writing down my thoughts, I had to waste my time to re-learn the software tools.

As you can see: A considerable bulk of difficulties and barriers to overcome! Some of the points of this list, I will reflect more in detail at a later time.

Using themes with blogdown: Lesson learned

Thu, 19 Jul 2018 00:00:00 +0000

Report from an Odyssean Journey

After a long interruption …

After almost one year of interruption, I started re-using blogdown again. But instead of writing new content, I had to struggle once again using the sophisticated machinery of Hugo and my academic-theme. With painful experiences, I learned that one has to be cautious with updates to prevent breaking changes. In this post, I will report on my Odyssean experience and — more important — I will suggest guidelines on how to start, explore, and use themes in blogdown.

Finally — after almost one year of interruption — I could reorganize my working responsibilities to spend more time working with blogdown and Hugo.

But (re-)starting blogging using these tools was not easy after such a long period. I did not only forget many procedures but also ran into compatibility problems with the necessary updates. It turned out for me that the R Markdown ecosphere produces not only valuable and powerful tools but is a continuously changing complex still stricken with some fragilities.

After reporting on these difficulties, I will summarize the lessons I learned.

I had problems with my old theme

Last year I was intrigued by the potent docdock theme. It has many dynamic features (aka shortcodes) and is uniquely good suited for complex structured information. I have learned in my posting career with WordPress on Gedankensplitter that over time, new subjects emerge and require a change of the content structure. I was especially delighted that docdock could produce dynamic HTML slides with the reveal.js framework, which I planned to use for tutorials and teaching.

After updating my software machinery (R, R packages, Hugo), I also installed a new release of the docdock theme. And here the odyssey started! I got many error messages which I could not solve. One problem was that I tweaked the theme (sacrificing several days of my summer holiday last year) without the necessary profound knowledge of the way Hugo works. Another problem was that after not using blogdown such a long time, I had forgotten many procedures of the interplay between blogdown and Hugo.

After several days of work, I did not manage to get a functional website. Worse! Meanwhile, I had destroyed my old (functioning) website as well. 😰 This disaster was for me an involuntary learning occasion to dive into Git and GitHub to save my work and restore my repo. I had not worked on a sub-branch and had carelessly committed changes that destroyed my web presence.

DocDock theme still maintained?

To avoid similar issues, I started a clean installation of blogdown with the docdock theme. This time I did not get error messages, but experienced another surprise! The theme style I preferred had other (new) problems: The display of code snippets was not correct anymore and destroyed the page layout. I reported this issue to the theme author. Only now I noticed that the author does not respond to questions. On the issue page of the docdock repo, I found the following message from another user:

Is this theme still maintained? Issues and PR’s seem to indicate not. I’m looking to add a documentation theme, but I’m not interested in adding one that’s been abandoned. (Issue 151)

This question is now unanswered for more than 20 days.😡 I do not blame the theme author. People have to work for a living; they donate their work and experiences to us whenever it is possible. But how could I be so naive only to judge my theme selection by the functionality of the theme? Not taking into account

the sustainability of the theme, e.g., its complexity related with its life cycle (updates, bugs),
the responsiveness of the author,
the community of people using this theme and helping each other!

At that moment, I abandoned the docdock theme heavy-heatedly. I had put so much work into its adaption! And I like its functionality and design! Yes, I could still use my working version, but then I will lose future Hugo features. I didn’t trust this theme anymore.

Problems finding another suitable theme

From docdock to ghostwriter

Now I decided to choose a more simple theme and started with the recommended theme list in the blogdown book. The only theme I liked from its design was ghostwriter. I installed it without problems and began using it. My first project was to learn the Xaringan package in combination with blogdown. I stumbled about it reading the new R Markdown book. It could be a way to replace my beloved html5 slide functionality from the docdock theme. Instead of producing slides using reveal.js, I had now to learn with remark.js another tool. But Yihui Xie — the author behind all this fantastic stuff in the R Markdown ecosphere like knitr, blogdown, bookdown, xaringan, etc. — explained convincingly why remark is preferable to other slide frameworks (e.g., slidy.

To shorten a long story: After several hours trying to bring Xaringan to work — I followed the simple synopsis by Tim Mastny in his blog entry Embed Slides in Your Blog — it turned out that in the ghostwriter theme files in the static folder are not rendered and uploaded. This insight came as a big surprise for me! I thought that it is a standard procedure that all files under the static/ directory are copied to public/ when Hugo renders a website. Only when I found an entry by Amber Thomas on Stack Overflow — one of the co-authors of the blogdown book — I learned that this could be possible.

The problem was — at least for me — a tricky one. The website worked locally but not when I deployed it with Netlify. Even when I noticed that there were no static files uploaded in my repository, I still thought it was me, who did something wrong. As a novice user, I always believe that the problem is on my side. But after many fruitless trials, I came up with the idea to try it out with another theme. So I installed the Xmin theme and learned that everything I did was done correctly.

From ghostwriter to Xmin and Academic

I abandoned the ghostwriter theme much more relaxed than before the docdock theme. I was not yet emotionally linked to the theme and had (thankfully) not started with adaption work. I learned from this experience that it is an excellent strategy to test things out with the two minimal themes Xmin or Lithium, which provides a stable reference point.

But how to proceed now? Should I stick with Xmin to be on the secure side? But I do not like this theme from its appearance. Also, my CSS knowledge is feeble, and I do not want to spend much learning and working time to adapt its design.

So my next choice was the academic theme. Last year I had already experimented with it, and it is one of the (more complex) recommendations in the blogdown book. It is a very elaborated theme with fantastic features designed for academic usage. But precisely or targeting the academic community, was the reason why I decided last year against this theme.

I am looking forward to my retirement, and I am fed up from all the administrative university business: The thought of (re)presenting all details of my scientific work and especially to transfer more than 120 publications from my WordPress blog to the blogdown academic framework made me furious. All I was looking for was a decent blog framework open for all the helpful tools from the R Markdown ecosphere.

But incidentally, just at the same time, I noticed problems with some of the WordPress plugins dynamically serving my list of publications. Besides, I understood that I am not forced to use all sections of the academic framework: I could focus on the posts section — and maybe add later on some other parts.

So I returned to my abandoned experiments with the academic-theme as I already did some configuration and had even written some content. First of all, I updated it to the new version and … — Yes, again I ran into troubles! After some trials, I noticed a wired problem: It took me two days to narrow down the error. It turned out that with one of the last update, the academic theme was not compatible with blogdown anymore! I reported this issue to the RStudio community, to George Cushen and Yihui Xie.

Can you imagine my emotional state? I changed between desperation and depression. All in all, it took me already two weeks with the result that I had accomplished nothing!

Crazy Hair GIF from Crazyhair GIFs

Figure 1: Crazy Hair

After taking a short nap to calm down, I reconsidered my situation: Yes, it took me much time, but at the same time, I learned a lot. I am not referring primarily to my speed generating a new blogdown website from scratch with a GitHub repo and deployed by Netlify (It takes my now only 60 seconds 🚀). But hopefully, I will not need this skill so frequently in the future. 😊 In addition to being more comfortable with Git and Github, I had learned general strategies to avoid similar problems in the future!

And there also came some encouraging signals from the community: Both — Georg Cushen and Yihui Xie — responded almost immediately to my posts. Even the problem was not solved at that time; I decided to stick with the academic-theme. From some other interactions (issues and questions to the theme), I had built up trust to the theme author. George is committed to his theme and very busy to deliver the best product possible. So after a roll back to an older version, I began with this article. As it stands now, this was the right decision. George and Yihui solved the issue together within two days.

Lesson learned from my own experience

The following list is an attempt to turn my Odyssean experience into constructive advises for other users. I am sure it is not complete and maybe in some points faulty. If you disagree or have other, better tips: please comment on this post!

I am not going into details, and I take for granted some basic knowledge/experience with RStudio / blogdown / Git / Github and Netlify. To have read the blogdown book is another requirement.

How to choose a theme?

Most important: In choosing a theme do not only focus on functionality and pleasing design.

Additionally:

Advice 01: Look if the theme author is currently active. If there are no updates for several months or later, reconsider to choose this theme.

Advice 02: Look at the repo to decide if the author is responsive to reported issues or pull requests.

Advice 03: Look if the author provides releases from time to time. Unexperienced users like me are still not comfortable with Git/Github. Instead of forking and synchronizing repositories, I prefer to install updates via ZIP files.

Advice 04: Look into the documentation to see if the explanations are comprehensive and up-to-date

Advice 05: Investigate the popularity of the theme. This check is not easily done but improves the changes for support through other users. Look not only at the number of stars and forks in the repo because that could be misleading for your purpose and community.

Advice 06: Recherche also if people often write in blogs and forums about the theme and what kind of community is using this theme.

… keep in mind that a more complicated and fancier theme may require you to learn more about all the underlying technologies like the Hugo templating language, HTML, CSS, and JavaScript. (Blogdown Book)

How to start working with a theme?

Most important: Do not begin with adapting the design of the theme.

Instead:

Advice 07: Start a test site with a test repository and test deployment with Netlify.

Advice 08: Copy the content of themes/<your-theme-name>/exampleSite to your project directory. Not the folder itself, but just the content inside (e.g., the folders static, content and the config.toml). Overwrite these files in your project directory — it is only a site for testing.

Advice 09: Read accompanying instructions and go line by line through the config.toml. Adapt this configuration file to your needs. Make notes not only how but also why you did which setting. Documenting these changes could be helpful later when you have already forgotten you initially considerations and the procedures to follow.

Advice 10: Now start writing text in your test site. I recommend working on real posts you want to publish. Choose predominantly use cases which will be typical for your everyday work. This advice seems strange as you are working still on a test site. It is important to test the theme under real working conditions. Besides, writing real posts are not lost work: You are producing standard text files which you can transfer to other sites or themes if the need arises.

Advice 11: Establish a common workflow and get used to it.

I use the following workflow

I start my daily routine with blogdown::serve_site() using the RStudio addins plugin (CTRL-S on my machine) provided by the blogdown package.

Update 2021-05-19: Due to significant changes starting with blogdown version 1.0 my workflow has changed slightly: It is not necessary anymore to use Build -> More -> Clean All because you can render and publish just one page.

Then I start writing. After saving the file (which automatically updates the local website), I look over the result locally in my browser. (I prefer my Google Chrome browser for detailed inspection and use the RStudio viewer pane only for a general overview or to look up a specific change.)
From time to time — or whenever something seems wrong or not updated — I use Build -> More -> Clean All followed by restarting R. And again blogdown::serve_site() to update locally.
After I have finished my work, I commit and pull the changes to my repo, and after some seconds, when Netlify has deployed the site, I inspect the live result.

Advice 12: After some time with your daily working routine, you get accustomed to all the other features of the theme. Even if there are functions you will not need to use: It is nice to have an overview of what could be possible and what not. This knowledge is also important to understand future updates of the theme.

Advice 13: Not until you feel comfortable with the functionality of the theme and your working habit, you should start to adopt the theme. Here it is important to do all your work on your side of the project; meaning not under the themes directory. Copy those files you are going to change or add under the same structure in your home folder of the RStudio project. Changes on these files will overwrite the virgin theme. One the one hand, your changes are all collected in one place and separated from the original theme. On the other hand, new versions of the theme will not override your changes.

Advice 14: Only when you have finally arrived at a status where you work could be publicly launched, change to the real website. Prepare a fresh installation with your theme, with a new repo and a new deployment by Netlify.

Advice 15: Before you copy your work into a new RStudio project, create a new Git branch and check it out (= change to it). If anything goes irreparably wrong (and believe me: eventually in the long term this will be the case!) you have not destroyed your current web presence. After my odyssey, I worked with two branches besides master: config for bigger changes (new version of the theme, changing the configuration or the structure of my site) and blog for my daily (writing) work. If you decide to merge your branch with master you will have an additional security level: Netlify will check if anything went smoothly before your branch is merged with master. If something went wrong, you would abstain from merging your branch.

Problem-solving strategies

Most important: Keep calm and RTFM!

Advice 16: Use Google (or other search engines) to see if other users experienced the same problem. Start your search inquiry with blogdown <name of your theme> <error message> or different appropriate combination of content. Most of the time, you will get results linked to questions in Stack Overflow or blog posts where other users reported about the same or similar problems.

Advice 17: If you cannot find appropriate problem/solution pairs, I would now — after my Odyssean experience — not yet starting to bother people at discussion fora. Start instead of a new reference (test) site with the XMin theme and try to reproduce the problem. If it works there, then the problem has to do with your theme or the changes you have made.

Advice 18: If the problem persists in your theme, then there are still two possibilities: Either you did something wrong, or it really is a bug in one of the pieces in the R Markdown machinery. Produce a REProducible EXample ( aka Reprex). Read Reprex do’s and don’ts and report the problem at Stack Overflow or to the RStudio Community[(https://community.rstudio.com/). Your replication on the otherwise empty reference site will help you to focus on the essential question and will also provide an excellent reproducible example.

Tom Cruise Help GIF from Tomcruise GIFs

Figure 1: Tom Cruise: Help me, help you!

Several updates

This post has enjoyed several updates already!

Back to docdock

Update 2019-06-03: As you can see from the footer, this website is using the docdock- and not the academic theme I wrote above. I started with the docdock and abandoned it for reasons I mentioned above. After another year of creative abstinence of blog writing, in May 2019, I fired up the blogdown machinery again. But because of a combination of many updates of Hugo (from 0.27 to 0.55.6!) and the academic theme (from 2.4 to 4.3), I not only ran into a bunch of error messages, but I have also lost track of different breaking changes and couldn’t recover. —😳

So I changed to docdock back, but this time with somewhat more knowledge. Hopefully, my activities were not a circle but a helix movement where I managed some advances. Thinking positively, hopefully, I can stick with this theme in the future. I do not want writing another complaining article next year, addressing the same problems again.

Not docdock but Pandoc was the problem

Update 2019-06-07: The reason for my problems mentioned above was an old version of pandoc. I had installed “pandoc-1.19.2-29-jan-2017”, but the latest release of the date of this writing is “pandoc-2.7.2-5-april-2019”. Now I could successfully update Hugo to “v0.55.6” By this occasion I also updated jQuery v2.2.3 to v.3.4.1.

Now there wouldn’t be any reason not to return to the academic theme. But I had worked hard the last week and learned so much about my docdock theme, that I am feeling now very comfortable and will stick with it.

Voila! Back to Academic theme again!

Update 2021-05-19: As you can see from the footer, I am back at the Academic theme again!!! The desired stability of the theme development became an unsupportable disadvantage: I couldn’t use the new features of Hugo any more. With some breaking changes (Content organization via Page Bundles and Goldmark as the new default Hugo markdown library) I became with the docdock theme sidelined.

Why Academic (now Wowchemy web page builder) and not a more simple theme?

After four years of learning and (sometimes bad) experiences, I am feeling more comfortable with the whole production chain and have more confidence to master the complex theme now.
Some changes in blogdown (several checking functions and the possibility to fix the Hugo version) addressed the problem of Hugo as a moving target where users had to follow every revision and update.
Both parts of the community (blogdown and Academic) have grown essentially, so help from other users is much more likely.

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. ↩︎