Finished this a while ago, but just getting around to writing a post about it now.
A great mentor of mine once said, “To know what the code does, start by reading the tests”, which is excellent advice. So this micromaterial follows that process to practice completing some higher-order functions (functions that take functions as arguments and/or return functions):
- Figure out what the code is supposed to do by looking at the tests
- Complete the higher order function code to make the tests pass
- Run it all in Gitpod in the browser! (optional)
Familiar things are easy; Unfamiliar things are hard
When I first got exposed to higher order functions, it warped my head a bit…but after I spent a while trying to write some myself, things eventually started getting clearer, and at some point it all clicked. There are lots of examples in research of familiar things being easier to understand/learn/work with (here is one of them), and it makes intuitive sense.
It’s also related to a commonly-held misconception (especially prevalent in tech), that some people are just “naturally” better at things (eg, pointers, recursion, etc), when in a lot of cases, it could just be the deficient way that learners are presented with these things.
People need repeated exposure to new things (especially intangible concepts like higher-order functions), and ideally this exposure is in the context of meaningful practice. So that’s why this exercise was structured to mimic an actual real-life situation: fix the code so the tests pass. The continually running tests also provide an additional benefit of automatic feedback on whether the learner correctly “fixed” the higher-order function.
So we not only have a clear “what” for the activity (complete some higher-order functions), but also a “why” (to make all the tests green). In a sense, it’s a type of gamification with feedback on how you’re doing…a tried and tested method to help engagement.
Gitpod as a learning environment
So why add Gitpod?
Gitpod is an exceptional product, and in this case, it affords the perfect environment to run our learning exercise. Previously, when creating micromaterials, I tended to target browser-based activities, since the number of dependencies (and therefore barriers to engagement) were basically zero (access to the internet and a browser).
However, if we want to run tests for automated feedback, that means we need to either run them in the browser (which requires a bunch of additional setup) or we run them on a development computer. Gitpod is the best of both worlds, where we have access to a runtime environment via containers using the browser (and all the config lives remotely in a disposable environment!).
And because we can automate the test running on startup via Gitpod configuration (with watching/updating on code changes), that abstracts away another thing we’re not explicitly targeting in our learning objectives.
So going forward, the ability to use Gitpod as an environment for these learning activities opens up a whole load of possibilities that previously would have been very clunky and/or require a significant amount of hacks and workarounds to achieve.
…and to open directly in Gitpod: