Bloom's Taxonomy for Programmers


Last night’s (10/29/2014) Code Newbie twitter chat focused on the topic of teaching (and hence, learning) technical concepts. It was, as always, a great way to spend an hour. Saron Yitbarek (@saronyitbarek) always does a great job of hosting. If you are a new or novice programmer, or once were a new or novice programmer, it’s worth checking out.

After the chat, I recalled Bloom’s Taxonomy from my days in high school. Bloom’s Taxonomy is a theoretical construct that is used to “distinguish the fundamental questions in the education system”. That is, Bloom’s Taxonomy breaks down the different ways of learning, and what they mean. Here are the types of understanding Bloom identified (loosely paraphrased from Wikipedia):

Some examples as applied to programming:

The more recent versions of the taxonomy put the ways of knowing into four tiers: remembering is most fundamental, then comprehension, then application, and then Analysis, Synthesis, and Evaluation are all in the same tier as sibling concepts. This has changed from what I remember in elementary school in the early 2000’s: the version of the taxonomy that I remember seeing was a strict pyramid, with the tiers in reverse order of what I listed above (Evaluation as the ‘highest’; remembering as the ‘lowest’).

But the subtle changes that education researchers make aren’t relevant to the discussion here. How can programmers guide their learning by understanding Bloom’s Taxonomy?

The act of programming, line by line, mostly occurs at the level of application. However, writing software in generally - being a ‘software developer’ or ‘software engineer’ - mostly occurs at the level of Synthesis and Analysis, while arguments on twitter about testing strategies and design principles (in theory) occur at the level of evaluation. Everything before that - remembering, comprehending, and applying - is there to build up to analysis or synthesis.

This is an important to understand. Learning to program the first time, in addition to learning each new tool, library, method, strategy, pattern, and so on - has to follow through this hierarchy. You must remember the words and the names, so that you can understand how each one works. Then you must be able to apply each piece of the puzzle - for loops, control structures, and so on. Finally, when you get to that point, you can begin to analyze existing software, then synthesize your own new software. Only then can you really start evaluating practices - i.e, arguing about them on twitter.

Hopefully, thinking about your learning process in this context will enable you to overcome obstacles more quickly, and turbo-charge your learning.

Happy Coding!

I'm looking for better ways to build software businesses. Find out if I find something.