After writing a handful of articles on recursion, I figured it was time to write yet another. I’m stuck in recursion myself it seems. Anyway, the angle we’ll be taking today is from Bloom’s Taxonomy, a tool educators use to make curriculum.
Table of Contents
A Light Introduction to Bloom’s Taxonomy
If you’ve ever wondered how educators put curriculum together, there’s a good chance that Bloom’s taxonomy is involved. In short, Bloom’s Taxonomy is a spectrum of cognitive processes that can be mapped to different types of learning objectives. The cognitive processes range from remembering to creating, with a variety of processes in between. My personal favorite representation of this taxonomy is as follows:
At any intersection of this diagram, we have an action verb which can be used to create a learning objective for a particular topic. That said, I think Bloom’s Taxonomy ought to be taught to students as well. That way, they can gauge their own learning and piece together appropriate activities for their studies. To illustrate this, I want to go through the six levels of the taxonomy today with one of my favorite topics: recursion. Let’s get into it!
Six Levels of Recursion
As we go through the six levels of the taxonomy, we’ll start by hitting the lowest level, remember, and work our way up to create. To keep things simple, I’m going to write out some objectives using the action verbs from the diagram above. By the end, try to figure out where you land along the spectrum with regards to your understanding of recursion.
When we first learn recursion, the goal is to remember some features of it, like definitions or uses. Here are some objectives you might gauge yourself on:
- List features of recursion (e.g., base case, recursive case, etc.)
- Recognize when code contains recursion
- Recall the definition of recursion
- Identify real-world examples of recursion
A lot education stops here, so don’t be upset if this is all you can do!
Personally, I don’t love the word “understand” because it’s fairly loaded. In fact, I believe some forms of the taxonomy use “comprehension” instead. Regardless, the idea of understanding is to be able to put thoughts about the topic into your own words, rather than straight memorization. Again, here’s how you can gauge your understanding of recursion:
- Summarize the purpose of recursion
- Classify types of recursive problems (e.g., sequences vs. trees)
- Clarify the instructions for a recursive problem
- Predict when recursion might be an appropriate way to solve a problem
As you can see, these objectives are a bit deeper conceptually. Instead of memorizing a set of facts, you’re putting those facts together to make interpretations.
Application is where we start to get into the core of software development. In other words, can you learn a process and use it in a real situation. Here are some ways you might check that for yourself:
- Respond to a problem in a recursive function
- Provide your own strategies for solving recursion problems
- Carry out a particular strategy for solving a recursion problem
- Use recursion when appropriate
At this point, your recursion ability should be related to using it to solve problems. This is typically the most a computer science course would care to assess, but there’s definitely more you can learn!
Typically, in higher level theory courses, you’ll be asked to move past the use of recursion and begin analyzing it. As always, here are some ways to gauge your ability to analyze recursion.
- Select the most efficient strategy for solving a recursion problem
- Differentiate between strategies for solving recursion problems by efficiency (e.g., Big O) or some other metric
- Integrate a recursive solution into an existing project
- Deconstruct an existing project into recursive and non-recursive components
Analyzing recursion is a mix of real-world skills and academic skills, so it’s not always necessary to have this level of depth. That said, there is still more to go.
Evaluate, which to me sounds a lot like analyze, is the next stage in Bloom’s taxonomy. Alternatively, we might use the term “synthesize.” Regardless, here are yet more ways to gauge your agility:
- Check that a recursive solution meets some set of standards (e.g., efficiency, scaling, etc.)
- Determine the appropriateness of a recursive solution to a particular problem
- Judge the use of recursion relative to appropriate alternatives
- Reflect on your use of recursion over time
As you can see, evaluate is a bit deeper than analyze in that we’re not just reviewing isolated problems and solutions but we’re actually connecting our analysis back to real-world problems and systems.
At the end of the pipeline, we reach create. Creation is not a stage that many folks meet, and there’s no shame in that. In general, it’s very hard to innovate, so don’t sweat it. That said, if you’re an expect in recursion, you might be able to do the following:
- Generate multiple recursive solutions to the same problem
- Assemble a blog post explaining the concept of recursion
- Design a set of strategies for solving recursion problems
- Create an innovative approach to solving a problem that leverages recursion (e.g., dynamic programming)
As you can see from this list, create is all about moving past the concept of recursion and into a sort of meta-domain. Here, we take everything we know about recursion and attempt to expand the limits of it by teaching it to others, design strategies that others can use, and even find brand new ways to use it. No doubt, this is as deep as mastery goes.
At any rate, that’s it for today. Are you tired of me writing about recursion yet? If not, check out some of these related articles:
- The Official Recursion Cheat Sheet
- 5 Tips for Making Sense of Recursion
- Yet Another Way to Learn Recursion
Better yet, visit my list of ways to grow the site. I could really use the support! Otherwise, take care, and see you next time!
Making a Sandwich is Not Rocket Science: How Elitists Always Stay on Top
If you're struggling in the tech field, please read this. I'm looking to build a community for folks who lack proper mentors.
Python software should always be versioned, but it's not always clear how. Luckily, I've shared some of my experience with versioning here.