How to Have Fun Building
Yes, I've "Tried Everything"
Yesterday I had a student come after school to discuss their science fair project about transducers. The student’s goal was to use an Arduino and a simple program to plot some properties of the transducer. The student was disgruntled -- they had followed a tutorial online, plugged in their Arduino, their transducer, pressed play, and their program produced an empty line plot. And yes, they had "tried everything” to make it work. Knowing almost nothing about the problem domain, how could I help this student?
End to End and Iterate
If our goal in a project is to produce a line plot, step one to success is producing a line plot. A plot of anything. Pick a number, any number, and plot that line. There should be a certain amount of joy that comes from seeing a straight line on a line plot. That’s what a line plot is for, after all! Once we’ve got a line, then maybe we can make that line better. We can install drivers for our Arduino, we can sample the output of current on some port, we can plug in a transducer, we can update the sample rate, and now we’ve got our science fair project.
Making an end to end working product and iterating requires a small inversion of engineering steps but it makes all the difference. A traditional assignment in a computer science class might be structured as follows: on day one, sit down and plan your algorithms and data structures. Draw some flowcharts, write some pseudocode, create some documentation and then and only then can you start coding. From a student perspective, I cannot think of anything more dreadful than screwing around in draw.io when all I want to do is build something cool. Flowcharts and documentation have a place, but not until the student falls in love with building.
In teaching, improving motivation for a student to finish a project is about eleven orders of magnitude more important than teaching specific content (this claim has not been empirically validated). A student will learn whatever content is required as a means to an end, but they will probably give up after some time with no tangible progress. While I’m advocating against flowcharts, I’m not advocating against planning. We need to avoid a student writing 114,000 lines of code that doesn’t compile and calling for help, complaining about why [insert programming language here] is out to get them. The plan we help students write must be about how to plan to have fun -- how to build, and improve, improve, improve, improve, improve, improve, improve, improve, and improve your final product.