Failing just hard enough to learn [Learning & Teaching / Riding higher waves Pt. 2.1]

This post is another reflection on the relationship between teaching and self-directed learning. It focuses on how to find a balance with making learning too hard or not hard enough. Thus the title: How can we deliberately make ourselves and/or our students fail just hard enough to learn? Context: I just found this post in the huge number of unfinished drafts in my WordPress. It was almost done, supposedly from early fall 2021. Some of it are reflections on my own (online) teaching in the summer term of 2021. I thought this was an interesting reflection still, so I decided to fix it up a little and post it now, despite the text not being “new” and some of my thoughts on my own teaching having changed over the last year where I have been teaching more than before as a Postdoc. Because the draft of this post was already so long and got a little longer with some 2022

read more Failing just hard enough to learn [Learning & Teaching / Riding higher waves Pt. 2.1]

Applying deliberate practice to online learning using a learning diary?

Today’s post is about using a learning diary to promote something like deliberate practice for (online) learning. Probably the biggest problem of my online teaching last year was not getting (soliciting?) enough feedback from my students. The only students who ended up ever really communicating with me were the few overachievers who had already had previous experience with the main learning goal of the class, i.e. SQL databases. At the very end of term, ergo after the semester and after I could make any changes, I received feedback from some students new to Digital Humanities that I had been going at a pace which was too fast for them. They were lacking certain information they needed from me to fully engage with the material. However, nobody told me as the class went along (and as you might imagine from knowing some of my teaching materials, I tend to provide very detailed info – so I assumed we were good in

read more Applying deliberate practice to online learning using a learning diary?

Learning to program: Failing fast and error messages

Today I wanted to talk about error messages and why you should learn to love them. If your mission is to learn programming, they show you your weakness and tackling a weakness is always the fastest way to learn. This is why the whole discussion of fixing error messages quickly turns into a philosophical discussion of a way of life: Walking the  path of the Ninja requires you to fail fast, early on, and often. Let me tell you why… Should you care about error messages and warnings? Are they secret messages from the universe? Yes, they are. If you’ve never given a hoot about errors and warnings in your life, congratulations. I don’t either. That is, until the thing doesn’t compile anymore. I am at awe with respect for people who fix mistakes before they become a problem. But I’m not one of them. What does this mean, however, with regard to your attitude towards failure? It probably means

read more Learning to program: Failing fast and error messages

Looking at data with the eyes of a Humanist: How to apply digital skills to your Humanities research questions

In my recent post on how to get started doing DH, I basically said that the essence of being DH is looking at data with the eyes of a Humanist and gave some tips on how to get started in just 10 days. However, it’s not that easy. Learning digital skills and the problem of skill transfer A problem I see a lot is that H people fail to transfer their newly won practical DH skills to their own research questions. They don’t know how to look at their own material as data. They don’t know how to leverage digital methods to help answer their own research questions. But if it isn’t compatible with their own research, they’ll never deepen their knowledge enough to actually profit from their DH skills. If you don’t use them, they are forgotten quickly. So how do you make this transfer which I think is, so far, being neglected as a skill which has to

read more Looking at data with the eyes of a Humanist: How to apply digital skills to your Humanities research questions

Formulating Research Questions For Using DH Methods

In the feedback forms I did on the DH classes I have taught over the last years, I got one feedback I didn’t expect: People were extremely grateful I had practiced with them how to formulate valid research questions which, apparently, no one had ever (really) done with them before. I found that quite astonishing because the DH are all about methods and methods are like specizalized tools. You need to know what you can use them for. So here’s the crashcourse. The Hammer and the Nail I want to start off with an analogy. A hammer is a specialized but not an extremely specialized tool. You can use it for a range of tasks, however, not all tasks are going to work equally well. Some might work but would actually require a more specialized tool if you had one. You can really use the hammer on about anything and almost always, something is going to happen. For example, you

read more Formulating Research Questions For Using DH Methods

Learning from ‘Computer Books’

I just uncovered this book review on William E. Shotts Jr., The Linux Command Line: A Complete Introduction (No Starch Press 2012) I left as a half-done draft months ago. In it, I found a long collection of thoughts on learning programming from books and what common problems are. The book review will still follow at some point, but these are some of the examples of common problems with ‘computer books’. The typical computer book: a long detail-rich, reference-like read I like the Intro to the Linux commandline a lot, but also found that it was very long in pages but the content isn’t super dense. So it was a very long read and I’m always ambivalent about books which are reference-like and super-long. I am a person who likes to read and even I put off reading this book for a long time. I read a chapter every morning while having breakfast. Some chapters I just skimmed because they didn’t contain

read more Learning from ‘Computer Books’

Is learning how to program like learning a foreign language?

Is learning how to program like learning a foreign language? Well, it’s a definite “yes and no” from me. I think many people oversimplify this. And then they say that their programmer friends think the same way to ‘prove the point’. Mostly I bite back the question of how many ‘real languages’ the programmer friends have learned or even learned to a native-like level. Because I think that there are some quite important differences. Since I just read this brilliant article The Ancient Case Against Programming “Languages” by Patrick J. Burns on Eidolon (Apr 24, 2017), I thought I could contribute some of my thoughts on the topic as well. They stem less from the interest in not losing funding for second language education, but rather from some of my own experiences in “second language programming education” or whatever one might call it – the act of learning programming (in your 20ies at earliest) after having learned multiple natural languages as

read more Is learning how to program like learning a foreign language?

A systematic training progression for programming?

As some of you might know, I am currently a fellow, aka at my personal writing retreat at Wolfenbüttel. And I decided to combine this with some sort of a training camp for my bouldering progress because you do need to have some breaks from writing during the day anyway and I can’t always watch Bones or create CV templates. You might have been following some of my bouldering on epigrammetry, the blog, or epigrammetry, the Twitter.   Training progressions in sports Also very few of you might know as well, I used to train a lot for long-distance running (10k) during my teens. So I know what training progressions are. I used to have detailled training plans, eating regimes, supplements to take and all that jazz. I stopped at some point because my immune system kept bullshitting me and as an ambitious person, I couldn’t take the idea of having to start from scratch after a half-year of being

read more A systematic training progression for programming?

Some thoughts on grading

Grading is always a touchy and emotional subject. When students misbehave, you automatically feel the urge to punish them with a bad grade. When students receive a bad grade, they will be angry and pissed off. And ‘bad grade’ is relative to what they expected, not ‘realistically bad’, like in a fail grade. In most cases, they will also think you are unfair if they honestly expected a better grade. And they will be gradually more pissed off, the more work they put in your class. So make sure you put as much thought into planning your grading scheme as into the rest of the preparation, because the grade might just leave the biggest lasting impression on students looking back.   The good student receives bad grade problem I just cleaned out my old archived data and remembered I had this class with a teacher I really liked. But now, I hardly remembered her. Then I realized it probably had something

read more Some thoughts on grading

Riding higher waves

At the risk of boring you all with my frequent thoughts on better teaching, I wanted to give you another metaphor on good teaching, inspired by a surfing class I took. To sum it all up, surfing was great fun. But this year, I was a bit unfortunate to get teachers who were a lot worse than the ones I’d had previously. The high waves and the shallow water make for good metaphors for the basics and the advanced topcis I frequently drone on about in my philosophy of teaching well. So, there you go. The shallows and the high waves The teachers were over-protective of us in the shallow waters. They helped more than we would have needed help and thereby, didn’t teach us to act independently. I wanted to do so, but it was not encouraged and we weren’t given any instructions on how to catch a wave on our own. They wouldn’t even let us paddle onto

read more Riding higher waves

Improve Your Teaching – 10 Simple Tricks

As you might know, good teaching is important to me, so I wanted to share ten simple tricks which I think can improve your teaching. Most of them are about making sure people get the basics which, in my opinion, is one of the biggest mistakes people make in teaching. Let’s get straight at it. 1) Make sure the preliminaries are clear before starting an explanation. If they are not, don’t even bother starting on the explanation, it will be a complete waste of time. Even if this means that you will spend the whole lesson bringing them up-to-date with the preliminaries and you won’t be able to start on the actual topic at all. Make time for this prep work or risk that all of your subsequent explanations will not get through. To find out if the preliminaries and basics are not clear, you might have to plan testing your students regularly (at the start of each block), like

read more Improve Your Teaching – 10 Simple Tricks

Didactical Reduction, Part II

In my first post on didactical reduction, I argued that reduction of learning materials to meaningslessness can be detrimental, that teachers should trust in their students’ ability to learn and rise to a challenge. In this post I want to discuss ways of reducing complexity which actually makes sense. The gist is: reduce unneccessary detail, not difficulty. Build complexity in a carefully chosen progression. Telling the difference between unnecessary detail and challenging complexity In my post on why programming classes fail and learning ‘algorithmic thinking’, a main example was that students starting out programmig don’t need to know about data types. I will stick with this example here because I just think it illustrates my point so well. The skill to learn I discussed in the post really wasn’t the ‘vocabulary’ of your first programming language, but ‘learning programming’ means successfully communicating with a computer and in order to do that, you need to develop the skill of algorithmic thinking. This

read more Didactical Reduction, Part II

Why most “learn programming” classes, books and attempts fail

This seems to be a bold claim. Let me explain… There are two reasons why I think most introductory programming classes fail ant that is a) because they never actually teach prorgramming (i.e. “algorithmic thinking”, not the syntax of one concrete language / “your first language”)) and b) because they bombard students with tons of complicated subjects which are not necessary at the beginning, so nobody remembers or understands them anyway. But they confuse the students and distract them from what they really should learn like how to interact with the machine and basic flow control. Use a visual language (like Scratch for PC or Catrobat for mobile devices) and thank me later. Algorithmic thinking When we want to learn or teach how to program, we first need to define what programming is. Like in a human language, knowing the words and the grammar is not enough – knowing a language means “knowing how to communicate using that language”. For

read more Why most “learn programming” classes, books and attempts fail

On Didactical Reduction (especially in the DH)

Didactical reduction means abstracting complexity to facilitate learning. It is the act of reducing and simplifying teaching material as to promote student learning. Sadly, I feel that didactical reduction doesn’t accomplish its ends most of the time. Here is why and how I think we could do better. The road to hell is paved with good intentions I have seen many classes where the content to be taught was reduced so drastically that is became simple and clear – but maybe **too simple and clear. It became meaningless.** The material became so easy to understand (or, even worse, a complex topic was made to seem like a banality), so that students stopped paying attention. “I already know this” or “I get this” are not necessarily thoughts a teacher wants to provoke. We use didactical reduction so that the complexity of a topic is hidden and we don’t scare our pupils. But fear isn’t always a bad thing. Fear means respect. And

read more On Didactical Reduction (especially in the DH)