The Full-Stack Sandwich

I’ve been teaching my son to code. Or rather, I’ve been teaching him how to think like a system.

We started with the classic "PB&J Algorithm." I told him to write down instructions for me to make a sandwich, and I would act as the computer—executing exactly what he wrote, no more, no less.

"Put peanut butter on the bread," he said. I placed the entire jar, unopened, on top of the loaf of bread.

He laughed. "No! Open the jar first!" "How?" I asked. "I am a computer. I do not know what 'open' means. Do I smash it? Do I unscrew it? Counter-clockwise or clockwise?"

This was his first lesson in Imperative Programming vs. Declarative Assumptions.

Level 1: The "Code" (Reducing Assumptions)

In human language, "make a sandwich" is a single declarative statement. We rely on a massive cache of shared context and assumptions (muscle memory, physics, common sense).

In coding, especially when you are starting, you have zero context. You have to handle every exception.

• Check if Knife exists.
• Check if Jar is empty.
• Load Bread.

We realized that a "simple" task is actually a sequence of hundreds of micro-decisions, retries, and evaluations. This is the Unit Level. It’s about syntax, logic, and error handling. It’s "Exercise Form" applied to logic. If you assume the jar is open when it’s closed, the program crashes.

Level 1.5: The "Abstraction" (The Reusable Function)

But we quickly realized that saying "unscrew lid, counteract clockwise, 30 degrees" every time is tedious.

In code, this is where we write a function: openJar().

Once we define openJar(), we stop worrying about the mechanics of the lid. We just call it. This is why we build libraries. This is why we don't write Assembly code for every web app. We build a middle layer—Abstraction—that bridges the gap between the raw mechanics and the high-level intent. We abstract the complexity away so we can focus on the sandwich.

Level 2: The "System" (Zooming Out)

Then, I asked him a question that shifted us from a Coding lesson to a Systems Engineering lesson.

"Where did the peanut butter come from?"

"The store," he said.

"And how did it get to the store?"

Suddenly, the scope of the problem exploded. We weren't just executing the local script of makeSandwich(). We were looking at the dependencies.

To execute the function makeSandwich(), we rely on a global API of agriculture, manufacturing, logistics, and retail.

• The Peanuts: The raw data, grown in specific regions (Data Ingestion).
• The Factory: Processing the raw material into a usable format (ETL Pipelines).
• The Trucking Network: Transporting the payload across the network (Latency and Throughput).
• The Grocery Store: The caching layer where we retrieve the artifacts (Content Delivery Network).

The Principal Engineer's View

This is the lesson I really wanted him to grasp: Complexity is fractal.

When you are a Junior Engineer, you focus on the knife spreading the jelly. You worry about the syntax. You worry about the local algorithm.

When you become a Principal Engineer, you worry about the supply chain.

• Is the peanut butter library deprecated?
• What happens if the grocery store goes down? (Redundancy).
• Why does it cost so much to ship the jelly? (Cost Optimization).

Conclusion: Confidence is Relaxation

Learning to code is frustrating because it forces you to acknowledge how much our brains automate for us. It strips away the comfort of assumption.

But there is beauty in that rigor. Whether you are writing a script to automate a spreadsheet or architecting a distributed system to handle millions of transactions, the principle holds true: You must respect the complexity.

You can’t just "make the sandwich." You have to understand the tools, the space, and the ingredients. Once you understand the system, you stop fighting it, and you start orchestrating it.

When my son finally realized he had to be explicit about everything—about 'unscrewing the lid'—he initially panicked. But then, as he understood the rules of the system, he stopped getting frustrated. He realized the computer wasn't broken; his instructions were just ambiguous.

He relaxed.

That is the ultimate lesson: Confidence is relaxation. True mastery isn't about knowing everything; it's about trusting your understanding of the system enough to handle the unknown.