Years ago, I had the good fortune to learn assembly language programming as one of the very first CS classes I took as an undergrad. I loved it and I aced the class, but after graduating in the late 80’s with an advanced degree in computer science, I ended up in research and coded only rarely. In hindsight, I now see that as a mistake, as women in tech especially benefit from their coding skills.
Fast-forward 25 years later, after a career spent mostly in graphics and media tech standards, product management and marketing, not only are my coding skills rusty, but worse, I’ve pretty much forgotten common computer science algorithms and systems architecture.
So, it was quite the experience working my way through Human Resource Machine’s 40 odd levels, called “years”. Humbling, and at times frustrating, I started the game in early January while on a flight overseas, and just finished this week. I found I mostly only had time to play while away from work/home/family obligations, needing at least two-hour blocks of time to think through the exercises without seeking online help. YouTube has many Human Resource Machine “tutorials” but they decrease a bit as the levels increase, as they generally get increasingly complex. You may be wondering why I wanted to even play (if you can call it play!) this particular “learn to code” game? I had already recommended the game to several non-techy friends who asked me what games to get to interest their kids in learning to code. But I said to myself: “Rita, you really shouldn’t recommend anything coding related until you tried it yourself” – as all too often, experienced developers find these coding exercise games trivial, but for some who have had no exposure to computing algorithms, and no experience writing code, even the simpler learn to code games can be off-putting, especially to children. This ended up being the case with Human Resource Machine, at least from my experience. My stepson, a straight-A high school student, for whom no subject seems difficult, said the game became just impossible for him after a few hours of playing and I know of others whose kids quit after around level 20 or so. Year 22, the Fibonacci Visitor, where you have to output the Fibonacci sequence up to, but not including the inputted number, is where/when the game starts to get challenging, at least in my opinion. From there, the complexity escalates with a few minor “breather” years in between.
I digress, and this post is really about programming with Post-its, something I had never considered before, but which worked out surprising well for me, especially considering the quite limiting assembly-language-like syntax of Human Resource Machine. The code is entered into a narrow vertical field to the right of the game scene, which gets frustrating to scroll through as the lines of code increase along with the complexity of the problem being solved.
So, by the time I got to level (Year) 28,I knew I was in a bit over my head. Enter the Post-it notes, which I think I got the idea from after sitting through so many meetings over the years where we would wall-paper Post-it notes to whiteboards during our scrums. Firstly (and for the first time since starting the game), I broke down and went online to find a sort-3 algorithm, quickly choosing this box-trick algorithm from the CS 201 class at Michigan Tech, just to wrap my head around the problem and try to solve it quickly in a way that made sense to me.
This image with the orange Post-it notes pretty much illustrates how I broke out the three subroutines for the sort from the main program, (one section each for whether A, B or C was the lowest valued number).
I ended up with 70 statements and went over the speed challenge, but at least my code was clean and made sense without crazily looping around itself. Designating smallest number “A”, largest number “C”, with middle number “B” I basically coded the six permutations of ABC, as you can see (if you look closely enough) at this Post-it:
Note that I have used five Post-its, one for each of the mini-routines to test for each of the permutations above, except for A, B, C, which falls out neatly from the main program block.
My second biggest challenging level was Prime Factors, Year 40. I quickly got that 2 is the lowest prime factor, and considering how many inputs were shown, I tried to take a shortcut by simply dividing by 2 in a loop, and when I got to the first negative number, I dumped the number out as a number w/o prime factors. Of course, the game then presented me with the number 15. Bomb! Then, I rewrote it to try to find the small possible factor by cycling through, testing and recording the lowest prime factor (in 15’s case, it is 3 of course). I later discovered there are a number of solutions for this one online, but I’m pretty happy with mine.
At the end, I did a quick tally based on the game challenge thresholds given in the hints for each level, and I think I would like to refactor Years 11, 13, 14, 20, 24, 28, 34 38 and 39 if I ever get the time.
You can see all of my Years’ results (some good, some not so good according to the designer’s size and speed thresholds) on my GitHub page.
I would recommend encouraging students to play Human Resource Machine in a beginner high school computer science class, or as a warm up to an assembly language class, if they still exist ;).