Teaching Programming with Authentic Projects and SRS

Introduction

As I teach programming, there are a few learning techniques I want to incorporate that I haven't seen integrated into other learning resources.

I will admit, this effort is a little bit selfish on my part! These are elements that I personally would want to try and incorporate into my own learning, and I'm very much hoping that by teaching in this way I can learn the subjects more deeply and become a better programmer myself.

Focus on Complete and Authentic Projects

Currently, the vast majority of educational material for programming falls into one of two camps. Either it is too deep without necessary breadth, or it is too broad without enough depth. For example, it isn't uncommon to find tutorials that talk about how to build an entire app from scratch. But those tutorials tend to skim over error handling, exclude effective testing practices, and generally don't give a good picture of all the nitty gritty details that make software production ready. On the other side, you will have resources that dive deep into error handling, or testing, but not in the context of any complete project. For example, nearly every single article on testing I have seen seems to come up with some contrived banking example that doesn’t feel like it would translate to anything I would ever build. There are some resources out there that give a good deal of both breadth and depth (FrontendMasters for example, has 10 hour workshops that seem to dive quite deep while also building out full websites or apps), but that doesn't seem to be the norm.

But by focusing on the right type of projects this can be solved. There are three guidelines I will be following to ensure the projects feel authentic (e.g. like a real project, rather than something that is clearly a tutorial project) and give the student a complete picture of development:

• Avoid overly simplifying subjects, instead start with a project that is within an achievable scope for the student.
• Don't skim over elements that would be important in production software. For example, make sure that a version control workflow is introduced early and regularly used, ensure that error handling is done properly, and incorporate unit and integration testing to a reasonable degree.
• Don't skip steps that would be handled by the programmer. Start with the creation of the project the normal way it would be done, don't give a bunch of starter boilerplate. The only thing I might provide is a design spec. For some tutorials I will treat it as if there was a designer on board providing resources. Although I will eventually get more into the design side of things to teach from the perspective of a solo developer.

If I can follow these three rules it will be very easy to write tutorials that will give the student deep insight into what software development is like, rather than simply teaching them how to program.

The final part of this approach is that the student has to apply it beyond what I have taught. After every project I want to give a similarly scoped homework assignment that will be within their grasp and allow them to apply some level of creativity and flair.

Students should come out of these tutorials with experience building real programs, and even with a couple of pieces of software that could theoretically be publishable if they chose to take it the rest of the way. ⁽¹⁾

Spaced Repetition Systems

I have recently been on a bit of an SRS kick. SRS is a system for showing flashcards at a steadily increasing interval, in a way that helps with memorization and learning. After spending time digging into how it can be used, I have decided that I want to incorporate it into my tutorials. Again, this is a somewhat self-serving approach, I personally want to start incorporating more coding concepts into my Anki deck (Anki is probably the best program for spaced repetition currently), so what better way to do that than to think about it as I'm writing tutorials? Using Anki to reinforce these concepts will help with recall and improved learning.

I could leave it up to the individual to just store these things as they learn, but I have found that for myself, it's incredibly difficult to build up a habit around note-taking and capture. Without some trigger to remind me, I don't tend to think about capturing these things into Anki as I go. By incorporating triggers into the tutorial directly, it will be much easier to get in the habit of saving snippets of concepts, syntax, and important details to remember. And hopefully this capture habit will extend beyond these tutorials and help with other learning!

I would highly recommend trying to tack on an Anki review onto something that is already a daily habit. If you can stay on top of it you can build up a massive library of notes and keep them all well-established in your mind without more than a few minutes of review per day.

Someday/Maybe: Supporting other learning styles

Eventually I would like to create youtube videos for the audio/visual learners, and do some basic sketchnotes of concepts to incorporate into both videos and posts to help the visual learners, whether they prefer to watch or read. This is still beyond my current skill set though, so for now I'm focusing on the writing and teaching, and will try to introduce more varied media later on.

One last thing.

If you enjoyed this post, consider signing up for my newsletter. Every week The Wednesday Writeup will come to you with an update on what I have been working on and thinking about, as well as recommendations for things to read and watch. You can check out the backlog and sign up at aengus.substack.com.

I don't have comments on this site, but I would also greatly appreciate any feedback via Twitter or Email.