Teaching programming to beginners: The path is secondary

I want to point out that the way (i.e. the “how”) in education is secondary. Much more important are the teachers with their professional and didactic competences and the fact that they are allowed to teach according to “their special teaching methods”.

Many different ways of teaching computer science

If you ask 1,000 computer science teachers which is the right way to teach computer science, you are sure to get 1,000 different answers:

• The first point of contention is which programming paradigm to start with.
• The second point of contention (sometimes heated) is which programming language to use.
• The third point of contention is the development environment (IDE).
•  Only then come methodological and other differences.

I believe (without scientific evidence) that the order of precedence for programming paradigms when starting out in programming is as follows:

1. Procedural / Structured / Imperative
2. Object-oriented
3. Functional
4. Logical

This means that very often people still start with procedural or structured programming and hardly ever start with the logical paradigm. Dr. Sperber, for example, made a plea in his article for starting with a functional paradigm (as a reminder: one opinion out of 1,000).

With programming languages, the first big decision is: Do you take one that is actually in demand on the job market (JavaScript, Java, Python, C# etc.) or do you take one that is (supposedly) more suitable for beginners. Visual languages or build-your-own-blocks languages like Scratch and Snap! also play a role here, where only puzzle pieces are put together instead of writing source code. Or, as a professor of computer science didactics at the FU Berlin put it at an event for teachers: “I don’t understand how you can teach beginners without Scratch! (Reminder: one opinion out of 1,000).

The learning environments are similar to the programming languages. In spite of the danger of overtaxing beginners, should a professional IDE such as VisualStudio, NetBeans, IntelliJ, Eclipse etc. or a didactically reduced IDE such as JavaEditor be used in class? Especially learning environments that work with images seem to generate great interest among children and young people at first:

• turtles drawing circles etc. (JavaTurtle)
• australian wombats or rockets (Greenfoot)
• cats (Scratch)
  house with sunrise and sunset (BlueJ)

The German site https://www.programmierenlernen24.de/java-programmieren-lernen/, for example, suggests Eclipse as an IDE for Java (remember: one opinion out of 1,000).

Two concrete ways: Starting out structured or object-oriented?

Since the turn of the millennium, there has been a great dispute in computer science didactics worldwide. One camp listed many good reasons for a so-called objects-first entry (i.e. a start with the object-oriented paradigm) into computer science teaching. The other camp provided just as many good arguments why one should first enter imperative/structured/procedural and only later go into OOP (objects-later). The camps were relatively irreconcilable: each was convinced of its way.

As part of my dissertation, I did an empirical study between 2006 and 2012 comparing the two paths. The results of the study suggest that the objects-first or objects-later debate is of less importance than previously thought. I quote:

“In my opinion, the debate should rather focus on the advantages and disadvantages of each path, especially on the differences in the processes. In the future, the question no longer needs to be which of the two paradigms the teacher starts with in the initial computer science lessons, since in relation to a school year (with approx. 100 school hours) the classes had the same learning success. Rather, the teacher must ask himself why certain topics are experienced as difficult by the students or are not learned well, why certain topic transitions cause difficulties and how the subjective experience and learning success can be increased”.¹

What is true for these two ways is probably true for all: each way has its certain advantages and disadvantages.

Many good ways independent of programming language, IDE and paradigm

During my dissertation time, there was a very useful institution: a so-called PhD colloquium, where all German-speaking (from Germany, Switzerland and Austria) computer science didactics PhD students met about twice a year to report on their dissertation efforts. The procedure for the majority of all topics was (simplified) as follows:

1. The doctoral student used a specific tool / programming language / method in the classroom.
2. Learning outcomes in computer science classes improved as a result.

I remembered this when I read in Dr. Sperber’s article his plea for starting with a functional paradigm and for a didactic approach of so-called construction manuals (remember: one opinion out of 1,000).

I believe all the persons that they are convinced of their way. I also believe that most of them, starting from their “old” way, have really improved teaching through their new way. But always only in the context of their teacher and their convictions.

The different paths are always characterised by the paradigm, the programming language, the IDE, other methods and the addressees.

The programming language is rather irrelevant: If you can do one, you can do (almost) all. Of course, within a paradigm (object-oriented, functional, logical). For the object-oriented paradigm, this means, for example, that it makes no difference to the learning success whether the programming language is Java or C# or ….

I also do not consider a discussion about the best paradigm to be purposeful: a follower of functional programming will argue that the whole world consists of functions, a follower of object-oriented programming will see objects everywhere in the world. However, a good OO programmer should have basic knowledge of functional programming and vice versa.

In practice, the choice of a programming language often depends on the application problem or the company philosophy. In addition, there are programming languages that do not realise only one paradigm. For example, Java allows functional programming to enter object-oriented programming via the lambdas. And that is a good thing. In computer science classes, many languages have proven themselves well. Moreover, IDE and programming language are often coupled with each other. And of course, each IDE has its specific advantages and disadvantages.

But even if the way is secondary, it must be appropriate for the target audience. Teaching children and young people will be different from teaching adults. A one-off taster course will be structured differently from lessons at vocational school (for IT specialists, for example).

The path is not the goal, but the “good” teacher!

If the path is secondary, then what comes first? Let us now turn to the most important influence: the teachers! Nowadays, they must have a bundle of competences:

1. Professional competences

While in the past it may have been knowledge of control structures, search and sorting algorithms, structure diagrams and programme flow charts, today a lot more is required:

• different process models (waterfall, V-Model, Scrum, etc.),
• UML (class and object diagrams, activity and use case diagrams, sequence and state diagrams, etc.),
• at least two programming paradigms,
• professional source code writing (design patterns, clean code, Git, etc.),
• database systems (ER model, normalisation, SQL, NoSQL),
• data protection and data security,
• web and app programming,
• currently: AI
• and the ability to tackle new topics using GitHub, StackOverflow etc.

2. Didactic and pedagogical competences and methodological competences

Methodological competences can be acquired by anyone (if willing). There are enough books, examples and experts for this. The didactic and pedagogical competences, on the other hand, are more difficult. Here I would say provocatively (based on my experience with my colleagues and the so-called career changers): You can’t be made into a teacher, you are born to be a teacher. Do you have a natural authority, do you have a knack for learners and do you notice when they fall asleep or are overwhelmed (etc.)?

3. Tool competences

Tool competences are also important for successful learning:Ideally, a teacher should be able to switch briefly from the JavaEditor or the IntelliJ IDE to Greenfoot, Scratch, Snap!, BlueJ or JavaTurtle in order to visualise something and/or make the teaching more varied.

Quintessence

The quintessence of this article is: Each of the felt 1,000 ways has special advantages and special disadvantages! There is no such thing as the silver bullet!

Much more important than the paths are the teachers. And it is important that the teachers are allowed to teach the way they are convinced of.

Notes:

[1] German Dissertation, Page 385

Dr Ehlert has been editor and co-author of the textbook since 2019: Anwendungsentwicklung in Theorie und Praxis.

t2informatik develops and modernises software as a service provider. Click here to learn more.