# If you think you know, you don’t know

> Bloom’s revised taxonomy offers a detailed description of the levels of knowledge. Here’s a personal example to help you better understand it.

- Author: Mathieu Eveillard
- Published: 2023-04-26
- Updated: 2025-03-01
- Tags: Learning
- Canonical: https://www.mathieueveillard.com/articles/taxonomie-de-bloom/
- Translation (fr): https://www.mathieueveillard.com/fr/articles/taxonomie-de-bloom.md

![If you think you know, you don’t know](https://www.mathieueveillard.com/articles/2023-04-26-taxonomie-de-bloom/taxonomie-de-bloom.webp)

Those interested in learning and pedagogy are likely familiar with Bloom’s (revised) taxonomy. First formulated in 1956 and revised in 2001, it clarifies the meaning of the word _knowledge_ by assigning it six possible levels: recall / understand / apply / analyze / evaluate / create.

[Let’s leave it to academics](https://www.coloradocollege.edu/other/assessment/how-to-assess-learning/learning-outcomes/blooms-revised-taxonomy.html) to elaborate on this spectrum, which ranges from the simple ability to reproduce knowledge without even understanding it to the ability to perceive its conceptual limitations, even if that means proposing a more suitable theoretical framework.

This model has its limitations, like any model, but it has the benefit of prompting us to ask ourselves where we stand, those of us who perhaps think we know.

Yours truly, for example.

My knowledge of asymmetric cryptography is minimal: I understand the concepts of private and public keys and know how to use them to generate an HTTPS certificate. But the practical application of this knowledge relies on commercial tools developed by people who, for their part, operate at a much higher level (evaluation or creation). As a result, my knowledge is limited to understanding.

My knowledge of the OAuth2 protocol goes a step further, to the level of implementation. In fact, my understanding is sufficient to identify common pitfalls, starting with the fact that verifying the cryptographic validity of an authentication token isn’t enough: you must also verify that it hasn’t been invalidated (as in the case of a logged-out user). This requires maintaining a database of revoked tokens. My understanding of the subject therefore allows me to design an architecture that doesn’t shoot itself in the foot right from the start 👍

On the other hand, when it comes to Test-Driven Development (TDD), I reached a turning point the day I began to take a critical look at the practice. Yes, sometimes TDD didn’t really help me; it even became counterproductive. It’s now clear to me that developing React components using TDD serves no purpose. Insisting on using TDD at all costs is like [driving screws with a hammer](https://www.mathieueveillard.com/articles/loi-de-linstrument-llm). It’s better to switch tools. **The level of evaluation, therefore, lies in nuance**. We come to recognize the limitations of an approach.

And this leads us to discover our own unique approach to TDD. No doubt, like me, you have your own personal way of blending the outside-in and inside-out approaches, using TDD in some cases and test-after in others. Perhaps TDD has led you, as it has me, to functional programming, and you no longer know how to do things any other way. Your programming style may not have a name, but you’re able to justify it, while remaining open to comparing it with other approaches.

Ultimately, **Bloom’s revised taxonomy will help you assess your level of proficiency in each area of knowledge you draw upon** and, perhaps, if you haven’t already, determine the true nature of your expertise.

So: where do you stand?