This Summer, I am exceptionally busy. I am teaching a course "Programming for Engineers" – a first-year course (twelve 90-minute lectures, plus exercises) for 120 engineering students who are to learn programming in C (and a bit of C++). In the past years, this has been one of the less popular courses both among its teachers and its students, so our Dean of Studies was very astonished and happy to have me volunteer for it.
The reason I had volunteered is that earlier this year, my 12-year old daughter and I had toyed with an Arduino micro controller board, writing simple programs that would cause LEDs to blink and buttons to be checked. Left on her own, my daughter (who had no C experience before) already had produced a full traffic light control for an intersection, together with a button to trigger a pedestrian crossing – and all of this within a few hours. The Arduino board served very well as a motivator: Controlling a set of LEDs and buttons is so much more concrete, tangible, and direct than printing "Hello, world" on a screen.
As computer scientists, we tend to abstract away the concrete machinery – because computer science is the science of abstraction, getting rid of concrete details until all that remains is the pure beauty of computation. Unfortunately, this is not the mindset of engineers at all, who see programming not necessarily as an exercise in elegant design, but mainly as a tool to get their actual job done. A micro controller board is a great device to connect between the world of programming and the world of engineering; all of a sudden, everything you learn during programming becomes directly usable for engineering contraptions of any kind.
So, I set off to build the programming course around microcontrollers. Intel donated us 40 Galileo boards (thanks so much!), which we fitted with electronic equipment such as LEDs, 16x2 LCD displays, photo resistors, microphones, speakers, breadboards and (many) cables – all of which would be used to motivate specific programming exercises. Each set would be shared by a group of four students. The process is that we give out a programming assignment each week, which each student solves and submits individually first (using only static checking, without executing them – welcome, cleanroom software engineering), followed by a group session in which the students jointly put together their programs to then test and demonstrate their final working solution on their wired board. Each student must be able to explain the group's program, so they get some exposure to teamwork and understanding programs, too.
So far, it has been a great course. We set off with getting LEDs to blink, subsequently defined our own functions for sending Morse messages. Checking whether a button is pressed is surprisingly hard, as you have to introduce timer checks to handle possible contact bounce. Introducing multiple LEDs to display a voltage level led to arrays and loops; I used the final 20 minutes of the lecture to demonstrate how the Heartbleed bug works through buffer overflows. Later today, we will explore interactive automata, using the LCD display to select drinks from a soda machine. I don't know yet what will be up next week, but I reckon it is time to convey some algorithmic thinking, and by the end of the course, students will be left to their own devices to work on self-designed projects. From what I hear from tutors, students so far are very motivated and eager to learn. What else could you ask for?
The only downside of this course is that it requires quite a lot of preparation. Before each lecture, I have to set up and wire my own microcontroller board, and it takes an extra ten minutes to set up and tear down the mounted camera to transmit live pictures of the board on my presentation; there's also plenty of live programming and interaction, which means I have to build and test all programs in advance. Giving out thousands of electronic pieces to students also was a logistic challenge (thanks to all tutors!). Furthermore, I have to build this course from scratch. Together with my other new course on "Generating Software Tests" (more on that in a later post), I am currently producing no less than 140 slides a week. So if you are eagerly waiting for my response, or wonder why I say "no" to almost everything these days – just keep in mind that this Summer, you are competing with 120 students who all await my latest and greatest.
For those interested: Here is the website of the course, with slides and all (in German).
