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’

Algorithms, Variables, Debugging? Intro to Programming Concepts

Since I am about to prepare a workshop on natural language processing and a pre-workshop-workshop where I need to quickly/crashcourse introduce my (non-digital) Classicist friends to some basics on programming, let me share a list of programming concepts I compiled with you. I would be happy for your suggestions and comments regarding mistakes. I will probably publish this together with some key concepts of quantitative text analysis (blogpost to come) on a cheatsheet or as slides for you later 😉 Intro to key concepts of programming This list of concepts is not super-structured and meant to work as a ‘reference tool’ as well as a text to be read, so I tried to give it a more or less useful ‘chronology’, meaning that later parts kind of build on earlier ones. I start off with what a computer program or algorithm actually is and how we translate between source code (the code we write) and the code which gets fed

read more Algorithms, Variables, Debugging? Intro to Programming Concepts

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?

How to improve at programming when your current position doesn’t require it & Online Learning Resources

Have you ever felt like you would like to get better at programming, maybe even get a position involving more programming some day but the fact that you currently don’t really need it at your current position seems to hold you back? This post is for you. Daily practice is key for improvement You need daily practice if you actually want to improve. You already need daily practice just to keep your skills sharp during a time where you don’t need to use them. Also, if you don’t even have programming skills yet, you probably are too tired after work to sit down and work on a private programming project. But you should. Programming is a skill which takes a long time to learn. That is, if you want to reach a decent skill level. This means that you have to start regular practice long before you actually need that skill or need to apply for a job, if possible.

read more How to improve at programming when your current position doesn’t require it & Online Learning Resources

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

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

Learn programming from a book vs. tutorial? Thoughts on deliberate practice

In this short little post, I want to share some thoughts on deliberate practice and how it affects coding, learning how to program, etc. I will argue that, in the long run, you can only become a better programmer with some systematic (self-)education, be it from books or academic classes. Tutorials alone, on the other hand, get you actionable quickly but do this at the expense of providing “the bigger picture” which will ultimately harm and slow down your progress. The concept of deliberate practice I have been intrigued by the concept of ‘deliberate practice’ for a few years now. It mostly comes up in the context of the so-called 10.000h rule (popularized by Malcolm Gladwell’s The tipping point – which is full of blatantly false information by the way and has been debunked by Steven Pinker, see Resources). Deliberate practice is needed for expertise and reaching a level of mastery. If you just want the ‘quick fix’, don’t bother

read more Learn programming from a book vs. tutorial? Thoughts on deliberate practice

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)