Teaching in the 36K Computer Lab, part 6

Part 6, Block Coding

My goal for the time I was in 36K was to teach students computer programming, aka coding. I began by discussing robots and commands. Now it was time to transition from spoken commands to a live person/pretend robot (move forward, turn right) to block commands (rectangular blocks with arrows pointing in the direction the robot is supposed to go).

Here is an example of a command block for making an on-screen character move one step to the right (or East). It is from the code.org website.

In the code.org environment, command blocks are stacked in a column, like puzzle pieces, to create a sequence of commands (i.e., an algorithm). Below is an example of five East blocks attached to a “when run” block. This means that when another block, called a “Run” block, is pressed, then these commands beneath the “when run” block will activate.










I told the students that pressing the “Run” block is like when you press a light switch: the electricity begins to flow through the wires and the light bulbs and light is created. So in the same way, you press the “Run” switch here, and something else happens there (in the “when run” section).

[BTW: Code.org is a great resource to learn programming: it lets teachers set up classes, assign exciting challenging courses, and track student progress. More on this later]

Here is an example of an on-screen robot being commanded by an algorithm. There is a “repeat” block in use. Do you think the code is beautiful? (The code.org doesn’t think so)

What would you do to beautify the code? Here is a screen shot. Do you see that the robot has already moved one space to the right in the screen shot?

To be continued

Teaching in the 36K Computer Lab, part 5

Part 5, Beautiful Code

In the previous post, I had the students command the Bender Robot to walk to the light switch using only “turn left,” “turn right” and “move forward” commands.

I explained:

that “command” is both a verb and a noun: you command a robot to do something with commands.)

I explained:

that the list of commands it took to get me to the light switch (i.e., turn right, move forward two steps, turn left, move forward six steps, etc.) was called a “sequence” of commands, which is also known as an algorithm. (I wrote one or both of these vocabulary words on the smartboard depending on the level of the students).

I explained:

that it is better to stay “move forward ten steps” rather than “move forward one step” ten times.

I explained:

that less is more, that shorter code is more beautify code.

I explained:

“If, when commanding a robot, you can use either five commands to do something, or you can use four commands to do the same thing, it is better — it is more beautiful — to use four commands. And, if you can do the same thing with just three commands, it is more beautiful to do it with three. Fewer commands equals more beautiful coding.”

I explained:

“see my face? That is not the beauty I am talking about. I am talking about the beauty of using the fewest commands to accomplish something.”

This was the introduction to beautiful code, and I brought it up in subsequent lessons.

To be continued

Teaching in the 36K Computer Lab, part 4

Part 4: Commanding Robot Bender

After all the students had come up to the board to write their names, I made a new Notebook page and wrote “Robotics.” I asked the class if anyone knew what this meant. I underlined “robot” in red and asked again. Students called out answers, and we agreed that it was the study of robots, or making robots move, or something like that. Some students started doing the “robot dance” in their seats or out of their seats.

I told them that “I am a robot.” Yes, Mr. Bender is a robot. And I only understand three things: turn left [I turned left]; turn right [I turned right]; and move forward [I shuffled forward]. I explained that I had to turn off the light switch by the door, and they — the student programmer-coders — had to command me to get to the light switch.

I didn’t know the students’ names yet so I had to use my book to call the students in turn to give me commands. There were obstacles in the room — chairs, desks, legs — but through trial and error each one give me a command.

  • some students stood up to count the floor tiles to tell me how many steps to take;
  • some students had to get out of their seats to see what to command me;
  • some students estimated the number of steps [NB: A para used the term “guesstimate,” which is a bit slangy and should be avoided to avoid confusion]
  • some students gave commands that were bad, e.g., “move forward 100 spaces” in the small computer lab. So I moved forward until I hit an obstacle and then kept moving my legs in place. I told the student that it was a bad command and I returned to the prior position. I told the student to fix the command and try again.
  • some students gave bad commands to be silly; some did it on purpose
  • some students had to work on their estimation skills and counting skills.

After I was commanded to go to the light switch — at which point I turned off the light, so the kids really knew I accomplished the task — I asked if anyone else wanted to be the robot. Hands flew into the air and so we practiced commanding other student robots to move around the room.

To be continued

February 2023