How Do You Actually Teach Engineering Judgment?

We teach engineering judgment using a fixed four-step sequence: learn the concept, implement it, find its limitations yourself, then understand why real systems need something stronger. The step most programs skip, deliberately finding where your own solution breaks, is the one that actually builds judgment. It shows up across our curriculum, not just in one project.

What Is Engineering Judgment, and Why Is It Hard to Teach?

Engineering judgment is the ability to look at a working piece of code and know whether it is actually good enough, not just whether it runs. Most programs teach the first half of that, how to build something that works, and skip the second half almost entirely. Students come out able to write code but not always able to say whether that code should be trusted.

You cannot teach that skill with a lecture. Judgment is built by putting a student in a position where they have to evaluate their own work and find where it falls short. So instead of teaching it directly, we build it into a repeatable sequence.

What Is the Four-Step Sequence?

The sequence has four steps, in this order, and the order is not incidental.

Step 1: Learn the concept. Before any code gets written, the student understands the idea they are about to work with. This step is the part every curriculum already does.

Step 2: Implement it. The concept stops being theoretical the moment it has to run. A student can nod along to an explanation and still have no real understanding of it until they have made it work themselves.

Step 3: See its limitations. This is the step that gets skipped most often, and it is the one that actually matters. Students are pushed to test and examine their own implementation until its weaknesses become apparent, rather than being told about those weaknesses in advance.

Step 4: Understand why real systems need more. The limitations found in step three are not treated as a mistake to be fixed and forgotten. They are the reason production systems are built the way they are. Step four connects what the student just discovered to why the stronger, more complicated version of the solution exists.

Why Does Step 3 Matter More Than the Others?

Because it is the only step that cannot be handed to a student secondhand. You can tell someone that a simple solution has weaknesses, and they will nod and agree, but that agreement is shallow. It does not change how they approach the next problem.

Finding the weakness yourself, in code you wrote, against assumptions you made, is a different kind of learning. It is not information anymore. It is experience. A student who has personally watched their own solution fail under a condition they did not anticipate carries that lesson into every future project, whether or not the subject matter is related.

Is This Sequence Specific to One Subject?

No. This is where the sequence stops being a teaching technique for one topic and becomes a general approach. The pattern, learn it, build it, break it, understand why real systems are harder, generalizes well beyond any single subject. It works anywhere there is a meaningful gap between a beginner's first working solution and a production-grade one: certain areas of cryptography and information protection are a clear example of this, because that gap is large, well documented, and easy to demonstrate, but the same shape of learning applies wherever that gap exists.

What's the Point If the Student's First Solution Isn't Good Enough?

This is usually the objection. If step three is designed to expose weaknesses, why have students build the weak version at all?

Because the weak version is not the point. The discovery is. A student told that beginner approaches to a problem have limitations has learned a fact. A student who built the beginner approach, tested it, and watched it fail has learned a principle: that understanding the limitations of a solution matters as much as understanding the solution itself. One of those lessons survives contact with a real, unfamiliar problem later. The other one usually does not.

Does This Mean the Exercises Are Meant to Look Like Production Systems?

No, and this distinction is stated deliberately, not left implied. The objective is never to pretend that a beginner-level exercise represents a production-grade system. The whole sequence depends on students knowing exactly where the line sits between what they built and what a real system requires. Blurring that line would undercut step four entirely, since the lesson only lands if students understand they are looking at a deliberately simplified version of a much harder problem.

Teaching a concept is easy. Teaching someone to distrust their own first solution, on purpose, until they have earned the right to trust it, is harder, and it is not something a lecture can do on its own. The four-step sequence, learn it, build it, break it, understand why real systems need more, is how we get there. It is not a cryptography technique. It is how we teach judgment, and cryptography is just one place we happen to use it.