Lessons From and For Online Teaching

Like everyone else’s, my teaching has been online in recent months. I have come across some  techniques that help, and will share them here. This article presents teaching techniques; a second one will discuss examination techniques.

These articles take no position on the relative merits and harms of online and onsite teaching; online instruction is with us today whether we like it or not and the topic addressed here is how to do it best. The specific context and experience are important, but will only be presented in the final sections below. First let me cut to the chase and describe the formula that I have found to work and which we may call the troika system.

Scheduling

Class scheduling is a key ingredient, and does not have to be devised in the same way for an online course as for traditional onsite delivery.

I believe that for online teaching the setup we used (devised by my colleague Mauro Pezzè) is more efficient than the usual salami-slicing of one hour here and one hour there. Instead, each course  is given either one or two entire half-day slots (one for a 3-credit course, two for a 6-credit course like mine), to be used at the discretion of the instructor and covering both lectures and lab sessions.

The resulting flexibility enables the instructor to adapt in a nimble way to the constraints (and advantages) of online instruction.

The troika structure

The second major ingredient is the structure chosen for these half-day slots. Each one of them consists of three parts (hence "troika") of approximately equal length (about an hour and a half with a break):

• Part 1: pre-recorded lecture. The students are required to take it before the second part, but they can do so at any convenient time after it is released (one week ahead). As they reside in in various time zones and are subject to various restrictions, they greatly appreciate the resulting flexiblity.
• Part 2: interactive lecture by the instructor. It goes over some of the same material as the recorded part (to explain the more difficult elements), adds some, and includes interaction with the students in a Socratic style or, per the currently fashionable term,  "flip-learning".
• Part 3: lab session, handled by the TAs. The professor can occasionally participate (visiting the various groups if more than one), mostly in silence but occasionally clarifying a point. For a software course the lab session is generally devoted, after some quizzes, to designing or implementing an exercise, with instant compilation and execution through codeboard.io.

Results

The combination works very well; student evaluations were ecstatic about its value (even though the questionnaire did not specifically ask about this aspect). To quote a student evaluation: "Perfect idea with MOOC’s + quizzes + coding exercises resulted in very high and proper comprehension of materials".

The experience is based on only one course (the present article is not a scientific study) but extremely encouraging. The troika’s particular combination seems to work very well. Even though the exams were not particularly easy — involving a mix of questions and a programming project — the course had a very high success rate, far beyond what we would have expected given the circumstances.

Conditions for success: MOOCs

Can the troika formula be replicated? I believe so but I have to point out the conditions that led to success.

The most difficult part is the availability of pre-recorded lectures. Here, looking around various universities’ course sites, one finds lots of unsatisfactory offerings. In many contexts, "offering online education" has just meant recording lectures and making them available. This has to be said: it does not work. At least not in the long term and on a large scale. Students simply get fed up.

Our pre-recorded material is the result of work I did over several years to develop MOOCs (Massive Open Online Courses), first as a skunkworks project (the management of the relevant institution was initially dead set against MOOCs) and then in the official framework of an EdX collaboration.  From EdX standards and practices (and from my collaborator in all these efforts, Marco Piccioni) I learned a considerable amount about what works and what does not. As a result we had our disposal three online courses (see note [1] for the URLs): two on programming and general computing (Computer: Art, Magic, Science?) and one on agile development methods.

A relatively small proportion of university professors have taken the trouble to produce MOOCs. This observation might seem surprising at first since a MOOC is a good opportunity to make your teaching more widely useful, and, if you are a good teacher, build up a reputation. But the reason for this paucity is clear to anyone who did jump into MOOCs (serially in my case). It is strenuous work. Both difficult and tedious, and particularly tough if you are a nervous person like me who has a proclivity for making a slip of the tongue in the last twenty seconds of the n-th retake of a segment. (You would think that it can be corrected in post-processing, but our technicians did not seem to, and I would inevitably end up doing retake n+1.) Every detail in your slides, in your speech and in every tool that you want to demonstrate on your computer has to be impeccable. The effort is comparable to that of writing a textbook.

When I was recording these courses a few years ago I often wondered whether it was all worth it. I hadn’t expected Covid, but the availability of these courses was a lifesaver. I have in fact no idea how I would have managed to give a good online course without the MOOCs.

Your MOOC or mine?

The preceding observations should not discourage others who may not, or not yet, have their own MOOCs. They can use the formula described here with someone else’s MOOC (mine for example…). The "M" in "MOOC" does stand for "mass." Being able to work on the basis of one’s own prepared material does, however, bring more control.

Canned material and spontaneous answers

In either case — using your own MOOC or someone else’s — the combination of canned lectures  and interactive ones is effective, providing a way out of a basic dilemma for lecturers: the lure and risks of ad-libbing. In a traditional setting especially with a large group of students, what do you do with a good question? You can either:

• Answer well and risk running out of time to cover the promised material.  (And ensuring that in the course evaluation students will call the instructor— accurately in my case — "discursive" and "digressive", not meant as compliments.)
• Or  lose the opportunity to seize upon a good question to go into deeper, insightful analysis [3].

The troika system addresses the dilemma: the MOOC part is the place for strictly-timed, non-discursive, sticking-to-the-script presentations of all the essential elements; the interactive lecture is for deeper explanations and the occasional foray into an unexpected area, prompted by an inquisitive student’s question.

In the interactive lecture, even if you go over some of the same material, you can be much more relaxed and take the time to answer such spontaneous questions.

A cloud-based programming workbench

Another godsend from earlier work was the availability of Codeboard, a brilliant cloud-based workbench [2] designed by members of my former group at ETH Zurich, particularly Christian Estler aided by others (Marco Piccioni again and Martin Nordio).

Codeboard, used by many universities, makes it possible to compile and run programs written in various programming languages. Everything is done on the cloud; there is no need to download anything. This last feature is particularly appropriate for beginning students, who can be put away by mundane tasks of setting up control files and other infrastructure for running programs. Even advanced students do not necessarily have the patience to install a new environment for every course. In addition, solving a programming exercise often involves, aside from the interesting part (devising or implementing a good architecture, algorithm and data structures), much auxiliary work (starting execution, reading test data, printing out results…) with no immediate pedagogical value.

With Codeboard you get a framework for your program (prepared by the instructor), with all the control files and auxiliary code already available; the instructor can choose which part to write and which part to leave to the students to fill — the pedagogically relevant architecture, algorithms and data structure. The students can compile their attempts, correct compilation errors, and run the result on tests prepared by the instructor. Some tests can be public and some secret.

Codeboard can also serve to grade online programming tests and exams, with the last possibility being particularly useful. (If you hide some tests, the students cannot just kludge their code in response to the tests so that it passes all of them: they have to get the logic right.)

Along with the half-day scheduling scheme and the troika time division, Codeboard provides an essential ingredient for success.

Context and background

Here, for reference, are the specific background and context of the present work. The institution is the Schaffhausen Institute of Technology (SIT, sit.org), a newly created and ambitious research-led university in Schaffhausen, Switzerland. The curriculum is SIT’s first master program, devoted to Computer Science and Software Engineering and taught for the first time in the current academic year. My course was initially supposed to be the program’s general software engineering course, but when I understood the makeup of the first class I decided that the students needed to be brought up to speed in programming and design in addition to general software engineering topics. I retargeted the course accordingly, changing the name to Software Construction, Architecture and Engineering.

The program has a little over 30 students, with highly diverse backgrounds and from many different countries in Europe, Africa, Asia and the US. In this first semester, for reasons that will be obvious to everyone, all students were working remotely. They will be transferring to Schaffhausen in the coming months as conditions permit. As a welcome mitigation to the the thorny problem of working across many time zones, the vast majority of the students were east of us, making it acceptable to have, in the case of our course at least, morning sessions.

When the world went online a year ago I was surprised to see that many academics in other institutions had barely heard about tools such as Zoom. I was fortunate to have had a long experience of remote work (using diverse tools), both in a company setting (at Eiffel Software, we moved to distributed development over 15 years ago) and for teaching. With colleagues from various universities we ran for many years a Distributed and Oursourced Software Engineering laboratory, with collaborative projects between students in different universities (see a record of publications about that experience here).

As early as 2008 I published in Communications of the ACM an article entitled Design and Code Reviews in the Age of the Internet which detailed our experience running distributed projects and presented some advice about, among others, how to run meetings and sustain good communication.

I was perhaps, as a result of these experiences, better prepared than some — although certainly not prepared for the many surprises that the last year has brought to all of us. Like everyone, I am eagerly waiting for the return of the irreplaceable experience of in-person teaching. Like others, I doubt that what comes next will ever be the full status quo ante. To a higher degree or to a lesser degree, online teaching will figure in our future.

Lessons?

Aside from the description of the specific context, as just given, this article has emphasized the general lessons.

I am keenly aware and have already noted that one successful course is no substitute for a systematic study.  Scientific studies take time, however; even if we had extensive metrics, and wrote an article for SIGCSE, and managed to get it accepted (a dubious "and" since program committees are no longer impressed by so-called "Marco Polo papers"), it would appear sometime in the Spring of 2022 at the earliest.

Online teaching is a reality now, and so is the need for sharing fruitful techniques that can help dedicated teachers cope with the circumstances. I hope the ones presented above do.

References and notes

[1] Online courses available from the Swiss MOOC platform (initially from EdX), courtesy of ETH Zurich (and providing the opportunity to thank Dr. Gerd Kortemeyer and Prof. Sarah Springman, rector of ETH, for making them available):

• CAMS (Computing: Art, Magic, Science?), part 1, available here from ETH Zurich.
• CAMS, part 2, available here from ETH Zurich.
• Agile Software Development, available here from ETH Zurich.

[2] Codeboard cloud-based workbench for teaching programming: codeboard.io.

[3] In an earlier article on this blog, I told the story of John McCarthy’s long and "discursive" answer to one of my naïve student’s questions, which marked me forever although it probably led McCarthy to skip some other topic.

Bertrand Meyer is professor and provost at the Schaffhausen Institute of Technology (Switzerland) and chief technology officer of Eiffel Software (Goleta, CA).