5 Lessons Learned While Teaching My First Arduino Course

This past spring I had the pleasure of teaching a course at CU Boulder called ‘Objects.’ For all intents and purposes, the class was an intro to Arduino class, in which we focused on four concepts, or ‘legs’ as I called them:

1. Basic Electronics
2. Arduino Microcontrollers, IDE, Community, and Language
3. Interactive/Human Centered Design
4. Digital Fabrication

My goal was to equip my students with everything they need to execute a successful interactive physical computing project, which is a lot to throw at someone over a four month period. I learned a lot about teaching this subject over the course of the semester, and I am very much looking forward to getting to teach again this fall with all my learnings. Below are some key takeaways that I plan to bring with me as I continue on to my second semester. 

Coding Pre-Req

For this class, as per the advice of the existing experienced instructor, I insisted that my students already know at least one programming language comfortably. Whether they learned that before college or during, it was crucial that each student be comfortable with programming basics, like ‘if, then’ statements, ‘for’ and ‘while’ loops, variables, data types etc. There is so much to cover in this course in a short period of time, so it’s super helpful for students to already have a basic understanding of what programming entails. It made teaching them the Arduino language and using the reference tools significantly easier on both them and me. It’s one less brand-new concept/language to throw at them while they are trying to grasp electronics basics. Students with programming experience can often build much more robust projects than those without, so the coding pre-req also helped ensure that all of the students were at a more similar level with their technical skills. 

Grade Subjectively

Despite ensuring that all my students had previous programming experience, it was obvious almost immediately that they were operating at varying levels in both coding skills and electronics knowledge. I taught the class assuming there was zero previous knowledge of electronics, but those who had messed around with circuits before greatly advanced beyond the students who were brand new to it. It definitely made it harder to grade everyone on an even playing field as some projects were miles beyond others, so I made a point on grading students based on where they started individually in the class, as opposed to in reference to the projects of their peers. 

Set Support Limits

One of the most amazing things about working with Arduino and other microcontrollers is the ability to scale projects from a really basic interaction to a pretty robust technical project. I found that a lot of my students were extremely ambitious with their ideas versus the skills we had covered in class. For those that were clearly planning a project beyond their means, I made time to sit with them and help them scale down their idea to something more manageable, setting them up for success in their work. However, there were a handful of super ambitious students who did not want to alter their vision at all. For those students, I made sure to set limits or boundaries on the level of support I could offer throughout the project build. For example, a student decided to work in MAX MSP instead of Arduino for his final project, which I approved with the caveat that I would not be able to help with that language. 

Emphasize Fabrication

I knew this one was going to be trouble before class began because I totally made the same mistakes as a student. Frequently students will leave the fabrication of their larger projects for the last minute and end up in a real pickle when they realize they should have left more time to prototype their enclosure several times over. During our final critique, many of my students made a point of describing how they would change their enclosure if they just had a little more time. Continually emphasizing that enclosures need to be considered and prototyped early on in the build process can definitely help with this situation, but I find that even with intense reminders (which I definitely gave at the top of every class), the students still often learn by doing for this one. It’s hard to understand before you make a thing that the thing will not come out how you thought it would in your head the first time you execute it. That is often something learned with practice. I tried to combat this issue by offering a thorough lecture on product design and prototyping as well as building in benchmark dates during project builds to start prototyping enclosures. It definitely helped in a few cases, but I still think I’ll need to push it more next time. That being said, the plus side of students waiting too long to start prototyping enclosures is that they learned quickly how to improvise when something didn't work. 

Teach About the "Why"

Teaching how to do something is one thing, but teaching them how to think is an entirely different beast. The biggest challenge for me was translating the notion that projects should have a reason for existing, that their work should have meaning. If I ask the student, ‘Why did you make this?’, they should have a clear and quick answer or defense for their work. For example, ‘I made this to help blind people navigate everyday life’ or ‘I made this to use as a meditation device when I feel stressed.’ This is a concept deeply attached to the practice of interactive, human centered design - which was a big focus of study in my class. For large projects, I liked encouraging my students to think about the end users needs as they were coming up with ideas so that their object had a clear purpose. 

Let us know about the biggest lessons you learned teaching Arduino in a classroom setting in the comments below!