Learning Recursion? Try Bloom’s Taxonomy

Learning Recursion? Try Bloom’s Taxonomy Featured Image

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:

Two-dimensional arrangement of Bloom's Taxonomy where one dimension is for cognitive process and the other is for knowledge.
Source: REVISED BLOOM’S TAXONOMY – CENTER FOR EXCELLENCE IN LEARNING AND TEACHINGOpens in a new tab.

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.

Remember 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!

Understand Recursion

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.

Apply Recursion

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!

Analyze Recursion

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 Recursion

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.

Create Recursion

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:

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:

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!

Coding Tangents (43 Articles)—Series Navigation

As a lifelong learner and aspiring teacher, I find that not all subjects carry the same weight. As a result, some topics can fall through the cracks due to time constraints or other commitments. Personally, I find these lost artifacts to be quite fun to discuss. That’s why I’ve decided to launch a whole series to do just that. Welcome to Coding Tangents, a collection of articles that tackle the edge case topics of software development.

In this series, I’ll be tackling topics that I feel many of my own students have been curious about but never really got the chance to explore. In many cases, these are subjects that I think deserve more exposure in the classroom. For instance, did you ever receive a formal explanation of access modifiers? How about package management? Version control?

In some cases, students are forced to learn these subjects on their own. Naturally, this forms a breeding ground for misconceptions which are made popular in online forums like Stack Overflow and Reddit. With this series, I’m hoping to get back to the basics where these subjects can be tackled in their entirety.

Jeremy Grifski

Jeremy grew up in a small town where he enjoyed playing soccer and video games, practicing taekwondo, and trading Pokémon cards. Once out of the nest, he pursued a Bachelors in Computer Engineering with a minor in Game Design. After college, he spent about two years writing software for a major engineering company. Then, he earned a master's in Computer Science and Engineering. Today, he pursues a PhD in Engineering Education in order to ultimately land a teaching gig. In his spare time, Jeremy enjoys spending time with his wife and kid, playing Overwatch 2, Lethal Company, and Baldur's Gate 3, reading manga, watching Penguins hockey, and traveling the world.

Recent Posts