There’s a well-known framework in education called Bloom’s Taxonomy. Most developers have never heard of it. That’s a shame, because it might be one of the most useful mental models for understanding why you feel stuck — and what to actually do about it.

What Is Bloom’s Taxonomy?

Originally developed by Benjamin Bloom and colleagues in 1956 and revised in 2001, Bloom’s Taxonomy is a hierarchical classification of cognitive learning objectives. In plain English: it’s a ladder of thinking skills, ordered from simple to complex.

The six levels are:

1. Remember — Recall facts and basic concepts
2. Understand — Explain ideas in your own words
3. Apply — Use knowledge in new situations
4. Analyze — Break down information and draw connections
5. Evaluate — Justify decisions, weigh trade-offs
6. Create — Produce something new and original

The crucial insight is that the levels are hierarchical. You can’t meaningfully evaluate something you don’t understand. You can’t create something robust if you can’t analyze the problem space. Each level builds on the one below it.

Mapping the Levels to Software Engineering

Let’s make this concrete.

Remember — Syntax, Vocabulary, Facts

This is knowing that git commit saves a snapshot of your changes. It’s memorising HTTP status codes, knowing what a for-loop looks like, or recalling that TCP is connection-oriented and UDP isn’t.

This level is necessary but nowhere near sufficient. A developer who only operates here is essentially a search engine — fast at retrieval, but unable to reason.

Understand — The “Why” Behind the “What”

Being able to explain recursion without just repeating a textbook definition. Understanding what actually happens in memory when a function calls itself. Describing the difference between a stack and a heap not because you memorised the answer, but because you genuinely get the model.

This is where foundational reading — not just tutorials — pays off. Books like Computer Systems: A Programmer’s Perspective or The Pragmatic Programmer are so valuable precisely because they build understanding, not just recall.

Apply — Writing Code That Works

This is the level most bootcamps and online courses are designed around, and for good reason — it’s where learning becomes tangible. Given a prompt, you can implement a binary search. You can set up a REST API. You can write a SQL query that returns the right data.

Apply is deeply satisfying. It’s also where many developers plateau.

Analyze — Reading, Debugging, Comparing

Here’s where it gets interesting — and harder. Analysis means you can read unfamiliar code and understand what it’s doing. You can debug a production issue you’ve never seen before by reasoning through the system. You can compare REST vs GraphQL not in the abstract, but for a specific use case with specific constraints.

This is the level where “tutorial hell” lives. Developers who are stuck consuming content without building, or who only build things they’ve already seen, struggle to cross into genuine analysis. The scaffolding has to come off at some point.

To build this muscle deliberately: read open source code. Debug things that aren’t yours. Force yourself to articulate the trade-offs between two approaches before choosing one.

Evaluate — Architectural Judgement

This is where senior engineers spend a disproportionate amount of their time. Not writing code, but making defensible decisions about systems.

Should this be a microservice or a monolith? What’s the right database for this workload? Is this abstraction actually warranted, or is it premature complexity? Evaluation means you can argue a position with reasons — and you can change your mind when the reasons change.

Good code review lives here. Not “this is wrong” but “here’s why this approach will create problems at scale, and here’s an alternative worth considering.”

Create — Designing What Doesn’t Exist Yet

The top of the ladder: writing technical specs, designing systems from scratch, building frameworks or libraries that other developers use, and solving problems that don’t have Stack Overflow answers.

This isn’t just about being clever. It’s about having internalised enough from the lower levels — recall, comprehension, application, analysis, evaluation — that you can synthesise something genuinely new. Strong engineers aren’t just good at following patterns; they know when to follow them and when to break them.

The Practical Takeaway

Bloom’s Taxonomy is most useful as a self-assessment tool. When you feel stuck, ask yourself: which level am I actually operating at, and which level does this problem require?

Most developers underestimate how much time they spend at Remember and Apply — and overestimate how much time they spend at Analyze and Evaluate. Watching tutorials counts as Remember at best. Building something you’ve already built before is Apply. Neither of these will get you to senior.

The deliberate practices that actually move the needle:

• Read code you didn’t write (Analyze)
• Debug unfamiliar systems (Analyze)
• Make architectural decisions and write them down (Evaluate)
• Justify your choices to someone else (Evaluate)
• Design something from a blank page (Create)

The jump from competent to strong is almost always a jump from Apply to Analyze and beyond. Bloom’s Taxonomy won’t make that jump for you — but it can show you exactly where you are on the ladder, and what the next rung looks like.