Title: Teaching folks to program 2019, a.k.a. in the search of an ideal program: Sequence Date: 2020-02-12 00:00 Category: News Slug: teaching-to-program-2019 Lang: en
In this article Michael shares his thoughts on teaching folks to program in 2019.
Preface
Autumn 2019 was the third time I participated as one of the teachers in the course to teach 10-15-year-old folks to program. The course took place from mid. September to mid. December. Each Saturday, we were studying from 10 AM to 12 PM. More details about the structure of each class and the game itself can be found in the 2018 article.
I have the following goals for conducting such courses:
Game
Memory is a simple game we create during the course. The goal of Memory is to find matching items on a playing field. More details, including game mechanics, can be found in the 2018 article. You can play the created game in a web browser by clicking this link.
Tool
When I was creating the tool, my guiding principle was unpretentiousness that manifests itself in the following:
The tool is an integrated development environment (IDE) that is technically a single HTML file. This single file contains both IDE and a project under development (Memory game in our case). The tool looks pretty standard:
Since we only have a single HTML file, we should be able to run it in two modes:
?0
symbols in the address bar.Web browser cache (IndexedDB) is used to keep changes temporarily. To save changes permanently, one has to download the file with the changes by clicking the corresponding button in the middle area.
The first classes
I prepared 80 lines of JavaScript code for the first class and printed the code on paper. Each student received the paper and had to type the code into the tool. The typing exercise had the following goals:
The typing speed turned out to be extremely low: ranging from 14 symbols per minute (a student managed to type only half of the code) to 39 symbols per minute. Since I used to type the code with the speed of 213 symbols per minute, I was shocked by the results and started to doubt we would be able to write the game in an hour by the end of the course.
We spent the second class to find typos in the code. I met typos that I have never seen in my life. I was shocked again: students had a hard time finding the typos even with the correct code on the paper in front of them. It's hard to imagine what would happen to the students’ psyche if we were to pass a brutal UX/UI test with questions like this:
Later I tried to decrease the code down to 10 lines, offered partially completed code so that students could find and fix errors. Nothing helped: students just couldn't comprehend anything as if they saw hieroglyphs instead of familiar letters.
Successful seventh class
The half of the course was over, and I haven't moved an inch. In another attempt to find a way to explain the code I rewrote the game one more time. Now with a module of an intriguing title последовательность
(sequence
in Russian).
To my surprise, the class had a stunning success: we got everything done before “the bell rang”, and the students were burning with enthusiasm. The burning was so strong that we finished the class with a spontaneous brainstorm session where we came up with functionality to make the newly appeared game even better:
The lines in Russian read:
Let's look closer into the class.
Board
Previous classes were using “teachers work with each student individually” approach. After six classes we (two teachers) realized that diving into each student's specific typos/errors takes more time than teaching anything new.
Starting with the seventh class, we decided to hook everyone to the board, i.e., the board became a central place where all of us were working, a place for everyone to stand up, approach the board and write there. PCs became secondary, a place for students to copy the board contents to. This practice clearly indicated school boards exist for many reasons:
I'd like to highlight the fact that teachers work at the board together with students: a teacher sets direction; however, students stand up and come to the board themselves, write answers to the teacher's questions themselves. The benefits of such an approach are the following:
Sequence
последовательность
module of the game looks like this:
The sequence allows to write an algorithm in the form of events and reactions:
начало
(start
), выбор
(selection
), etc.) are lines without indentation;настроить ThreeJS
(configure ThreeJS
), показать заставку
(show splash screen
), etc.) are lines with indentation to signify their relation to events.Thus, when starting the game (начало
event) we configure ThreeJS (настроить ThreeJS
reaction), show splash screen (показать заставку
reaction), and so on.
The class had almost an empty последовательность
module in the beginning; only events were present:
I have duplicated these same events onto the board, leaving free space to add reactions later during the class (I used GIMP to depict free space in the following image):
We were searching for reactions in память.реакции
module (memory.reactions
):
Each reaction of последовательность
module is represented in память.реакции
module by constructor functions. For example, проверить окончание
reaction (check for ending
) has a uniquely corresponding ПроверитьОкончание
function (CheckForEnding
):
function ПроверитьОкончание(мир) // 1.
{
мир.состояние["скрыто сфер"] = 0; // 2.
this.исполнить = function() // 3.
{
мир.состояние["скрыто сфер"] += 2; // 4.
var скрыто = мир.состояние["скрыто сфер"]; // 5.
var сфер = мир.состояние["сферы"].length; // 6.
if (сфер == скрыто) // 7.
{
мир.события["конец"].уведомить(); // 8.
}
};
}
The same code in English would look like this:
function CheckForEnding(world) // 1.
{
world.state["spheres hidden"] = 0; // 2.
this.run = function() // 3.
{
world.state["spheres hidden"] += 2; // 4.
var hidden = world.state["spheres hidden"]; // 5.
var spheres = world.state["spheres"].length; // 6.
if (spheres == hidden) // 7.
{
world.events["ending"].report(); // 8.
}
};
}
Let's look closer:
world
(dictionary) that is used by functions to communicate with each other. world
consists of three regions (dictionary keys):
state
contains variable data used for communication;settings
contain constants to configure functions;events
contain publishers to be able to subscribe functions to events.new
operator while parsing последовательность
module. Practically, everything outside of run
method is considered to be part of the constructor body. In our case, we create spheres hidden
variable to count hidden spheres.run
method is executed each time an event is reported.check for ending
reaction is executed each time a user hides a pair of spheres, we increase spheres hidden
counter by 2
.spheres hidden
counter.ending
event if they are equal, i.e., if all spheres were hidden.Students took turns searching for functions in память.реакции
module:
// // // //
symbols);Such an exercise also highlights who's actively tracking the functions and who's unable to find the next function when it's their turn.
Once the names of all functions have been written on the board, we were mapping reactions (functions) to events in a similar fashion:
начало
Once we have a more-or-less working set of reactions for an event it's time to transfer them from the board to student PCs. That way we managed to fill the board with reactions both on the board:
and in the tool:
The following classes
During the following classes, we were trying to create a new reaction and a corresponding constructor function. First, I tried to put a solution into heads quickly (providing complete lines of code); however, that didn't work. That's why we ended up with learning the following code, which took us several classes:
var кот = "9";
console.log(кот);
Unfortunately, these two lines of code were hard to explain: students were confused with the concept of variables and their values. This wasn't the only problem: the new function required the use of an array, which I failed to explain at all. There's a long road ahead of me before I'm able to explain variables and arrays to students.
Of course, by the end of the course we managed to complete the new function, however, I haven't seen understanding and subsequent faith in themselves, which usually manifests itself with a burning enthusiasm we saw in the seventh class.
The last class
The last class was not using the famous greeting circle at the beginning. Instead, I asked everyone (including myself) to tell what was good (+) and what was bad (-) during the course. Here's the table I got:
The same table in English would look like this:
№ | + | - |
---|---|---|
1 | Personalized ending screen | Touchpad? |
2 | Working on PC | Writing on the board |
3 | Explanation | Discipline |
4 | Flexible learning program | Sometimes unclear and uninteresting |
5 | There's a finished game | Learning program is too big |
6 | A detailed explanation of algorithms | Doing the same thing each time |
7 | Teamwork | Students of disparate skill level |
8 | Interesting / Difficult | Too early |
9 | Sequence | Half of the course |
Surprisingly enough, the folks didn't like to write on the board even though it greatly increased the efficiency of teaching. On the one hand, the “learning program was too big”, on the other hand, we were “doing the same thing each time”, i.e. repeating what we have learned before.
We were saving the game to GitHub from time to time. This was difficult, too: we were spending half an hour while students were authenticating. As always, nobody remembered their passwords (each time), others had to verify it's really them accessing GitHub account on a new device, which required access to e-mail, which sometimes belonged to parents (the folks had to call their parents).
Nonetheless, each student had its own version of the game by the end of the course with personalized beginning and ending screens:
Conclusion
On the one hand, we had significant success:
On the other hand, we had an evident failure:
That's why I'll try to answer the following questions when teaching in 2020:
I'll share answers to these and other questions next year ;)