Teaching People to Code — Part 1, Talking to Beginners

Like many of my age and generation, I started learning to program with BASIC. These were the days when you bought magazines full of pages and pages of code for games or basic applications. You spent hours with your friends painstakingly typing these programs in to a computer to find there was a typo, or the game didn’t work, and then giving up. It was more about hanging out with your friends, whilst your parents felt like you were learning something.

BASIC had flaws, but one thing I liked about it was that the code was clear and verbose. This is why programs took pages to do anything. There is little chance of any language released now having such ‘wonderful’ syntax as (including mandatory line numbers):

5 LET S = 0
10 MAT INPUT V
20 LET N = NUM
30 IF N = 0 THEN 99
40 FOR I = 1 TO N
45 LET S = S + V(I)
50 NEXT I
60 PRINT S/N
70 GO TO 5
99 END

(Thanks to Wikipedia)

But you must admit, that for a beginner, it’s clear what’s happening.

Years later I learnt ‘modern’ programming via a series of languages including PHP, Lingo, C++, Visual Basic and Java. I’m sure we covered Object Oriented programming, but mostly I remember it being procedural. This wasn’t helped by my years working with Drupal, which didn’t have solid OOP concepts until version 8.

Fast forward to the present and some of my motivations for this post. For the past months I have been teaching programming to recent Syrian refugees in Berlin and our language of choice has been Ruby (and Rails).

Laying aside a recent growing exodus of programmers from using Ruby (That’s a whole other story), we (the teachers) are unsure if it was a good choice. The Ruby community is amazingly supportive and welcoming and that makes many students succeed in learning to program through shear perseverance and support of the community.

However we have noticed that some of the characteristics of Ruby that attracted experienced programmers are actually obfuscating and confusing. I don’t want to turn this post into a ‘Ruby Bash’, because that’s not what it’s supposed to be. I like Ruby and it’s not the only language that has these problems. My recent experience teaching it to absolute beginners has meant that I have practical examples to illustrate my point. I also acknowledge that some of these lessons might be due to teaching the wrong topics in the wrong order, or unlearning some of the common tasks experienced programmers undertake, at least in the short term.

Shortcut Tools

Programmers are a little bit lazy, or to be more accurate we like to find ways to reduce repeatedly typing the same boilerplate and instead focus on the important and unique parts of a project. With Rails, scaffolding does just this, with a handful of commands you can have the underpinnings of a MVC application.

But these tools can completely confuse beginners. They don’t understand what was just created, why, where or how it fits together.

Shortcut Syntax

To an experienced programmer, writing:

(0..100).each {
print i
}

Instead of:

var i;
for (i=0;i<100;i++) {
puts i;
}

Is an amazing and sensible shortcut, in fact it’s efficient, there’s no need to initialize a variable or write all that horrible semi-colon separated syntax. But think about it from a beginners perspective. In the Ruby example, the only words that really make sense are `each` and `print`, what are the rest actually doing? It’s not to say that a student can’t learn these concepts, but in some respects, whilst learning, the second examples is actually clearer and shows a student what is happening.

‘Do What you Like’ Languages

There has been a trend towards languages that let you write casually, not having to worry about variable types and so forth. This popularity seems to be waning, or at least, increasingly supplemented, by much stricter languages. These have advantages of speed and efficiency, but I do wonder if it’s also a case of changing trends. Languages that force you to make certain linguistic steps may take longer to learn, but there is less ‘grey area’ around what is and isn’t possible.

The Real World of Work and ‘Take homes’

Often we’re keen to get students onto the most useful and ‘real word’ concepts and practices as quickly as possible. Many contemporary ‘learn to code’ programs are strongly focussed on getting participants ‘work ready’ and placed in jobs. I could (and may do) write an entire post about some of my issues with these programs, but in short they can introduce students to concepts that they may not be ready for. Most notably based on my recent experience are…

Object-Oriented Programming (OOP)

OOP is a fundamental concept for many modern programming languages but often is taught straight after learning complete basics like variables, logic and loops. Students have barely come to grips with what a program even looks like and then are thrown a massive curveball.

OOP is one of those concepts that makes far more sense in advanced applications, when writing basic programs it seems an unnecessary and extraneous complication. Teachers can throw around terms and examples built on solid comparisons like animals and vehicles, but the practical need and application is still hard to grasp.

Version Control

Version control is similar. If you are working with a team on a large project with regularly moving and changing parts, then it makes perfect sense. When you are working alone or in a small team it can feel like an over-complication. Git is wonderful, but remembering its workflow is a pain, where missing one step can throw things into disarray, and merging for the first dozen times is a confusing process.

Great Chris, but what do you suggest we do about it?

Good question. It’s easy to criticize and who’s to say I’m even correct? First I want mention a tip or two that I have found useful in teaching coding and then try to get some crowd-sourced feedback on what languages people feel are good for beginners and why.

Assume Nothing

You’ve heard this before I’m sure, but I want you to try taking it a stage further. Here’s a little soundbite for you:

If you assume nothing, there is nothing to lose.

Well, you may lose some time, but not that much. In practice this means that you shouldn’t assume anyone has heard of your favorite build system / language / IDE / editor or assume that anyone has any of the same experiences as you. Just because you think they should have, doesn’t mean they have. Of course, if you ask first, then go ahead, but check.

People are generally OK with a little repetition if it’s needed. If they understand something already and have to listen to it explained again, they probably wont mind and may even catch something they didn’t previously.

Context

This is a big one for me. Coders are often great at explaining that something is cool, but not so good at explaining why. When educating people, don’t just mention what it can do faster, better and bigger than before, but also why that is good for them or for you. They will listen, learn and remember far better.

Community

At risk of sounding contradictory, some languages (especially Ruby and Python) have amazing communities that try hard to nurture beginners. These communities may not make the languages any easier to understand, but for those who stick it out, they will find it easier to expand and sustain their knowledge. Most importantly more supportive communities help reduce exposure to noxious influences who may put of a beginner.

The Best Programming Languages to Learn

This is where you come in. I’d like to hear from you what languages you think are the easiest to learn and understand. I also want to hear why you have that opinion and if you have any, your experiences teaching them.

In a couple of weeks I’ll gather these stories and write part two, taking a balanced examination (with beginner assistance) of the true accessibility of these languages and how best to teach them.

I am sure you also have opinions on some of what I have written and that’s great. Please, when expressing them, try to be constructive and see a beginners perspective. Thanks!

Podcast

All of the Weekly Squeak posts are accompanied by a podcast where I go more in-depth into the topic, subscribe here or listen to the individual episode to the left.