Wishful Thinking from SICP, Practically

February 04, 2026 [thinking, cpp] #thinking #reading #sicp

This is not a pure technical blog post. It is an attempt to connect engineering principles to real life.

Many of the challenges we face—confusion, anxiety, overthinking—are surprisingly similar to the problems we solve as engineers. While revisiting Structure and Interpretation of Computer Programs (SICP), I found an idea that quietly gave me answers: wishful thinking.

What is Wishful Thinking?

In Chapter 2 of SICP, the authors introduce a powerful strategy for building abstractions: wishful thinking. The idea is simple but profound: write code as if the pieces you need already exist. Define the interface you wish you had, then trust that the implementation details can be filled in later.

When explaining this concept, the authors write:

We are using here a powerful strategy of synthesis: wishful thinking. We haven’t yet said how a rational number is represented, or how the procedures numer, denom, and make-rat should be implemented. Even so, if we did have these three procedures, we could then add, subtract, multiply, divide, and test equality ...

To make this concrete, here's the same concept in C++ without OOP. Notice how we use functions that don't exist yet, and we haven't defined how the Rational data type is represented—that's wishful thinking:

int numer(const Rational& r);
int denom(const Rational& r);
Rational make_rat(int numerator, int denominator);

// Now we can write high-level operations using our "wished" interface
Rational add_rat(const Rational& x, const Rational& y) {
  return make_rat(numer(x) * denom(y) + numer(y) * denom(x),
                  denom(x) * denom(y));
}

Rational sub_rat(const Rational& x, const Rational& y) {
  return make_rat(numer(x) * denom(y) - numer(y) * denom(x),
                  denom(x) * denom(y));
}

Rational mul_rat(const Rational& x, const Rational& y) {
  return make_rat(numer(x) * numer(y),
                  denom(x) * denom(y));
}

Rational div_rat(const Rational& x, const Rational& y) {
  return make_rat(numer(x) * denom(y),
                  denom(x) * numer(y));
}

bool equal_rat(const Rational& x, const Rational& y) {
  return numer(x) * denom(y) == numer(y) * denom(x);
}

Now, the rest of the missing pieces tend to emerge naturally, almost effortlessly.

This way of thinking gave me a way to stop reacting blindly to every signal, and instead design my next step deliberately. In that sense, wishful thinking wasn’t just a programming technique for me—it became a survival tool.

How I Apply Wishful Thinking to My Life

How do I actually use wishful thinking in my life?

I follow these steps:

  1. Define the outcome

    Specify the mental state or concrete achievement you are aiming for.

  2. Identify the procedures

    Define the procedures that would contribute to achieving that outcome, without worrying about their implementation yet.

  3. Lazy evaluation

    Defer thinking and decision‑making until action is actually required. Avoid premature optimization, over‑planning, or the urge to make everything perfect upfront.

For example, I define my perfect day like this:

(define (a-great-day)
  (let ([breakfast (with-hot-coffee)]
        [commute-to-work (listen-to-good-music)]
        [work (perform-meaningful-contribution)]
        [family (initiate-a-warm-hug)]
        [growth (learn-1-simple-thing-today)])))

Or my ideal life:

(define (my-ideal-life)
  (let ([mind (inner-peace)]
        [body (healthy-body)]
        [family (cherish-everyday)]
        [interaction (spread-warmth-and-kindness)])))

The following are my own reminders:

01. Define the Goal

A gentle reminder from Naval Ravikant: “Desire is a contract you make with yourself to be unhappy until you get what you want.” That quote forces me to define my “good day” and “ideal life” with extreme restraint.

I often catch myself chasing things that society rewards—status, recognition, external validation. But pursuing those metrics usually leads to anxiety and dissatisfaction, which is the opposite of what I actually want. The irony is obvious: I was optimizing for the wrong objective function.

Clarity is not motivation; it is a filter.

When the end state is not clearly defined, every option feels equally important. Everything competes for attention, and motion feels like progress—but nothing converges.

Once the end state is clear, most options fall away naturally. What looked like luck was just knowing where I was heading.

Effortless doesn't mean easy. It means the system knows where it's going.

02. Find the Procedures

Always work top-down, not bottom-up. Think recursive.

I worked in an environment where every contribution was scrutinized, but recognition was scarce. Over time, I started doubting myself—even as I shipped solid work, optimized hot paths, kept regressions stable.

For years, my filter was too permissive. Every opinion felt equally valid. If someone said I wasn't good enough, I believed them. That slowly eroded my sense of direction.

Eventually I saw it: not every environment is designed to recognize every kind of value. Some places reward what I'm good at. This one didn't.

So I set a boundary. Only feedback aligned with growth gets through now. Everything else—fear, comparison, the need to prove myself—gets filtered out.

Once I stopped optimizing for someone else's definition of success, the path forward became clearer.

Not all feedback is input; some of it is noise.

03. Lazy Evaluation

This is the most important part.

  1. Before execution, don’t panic.

    Avoid catastrophizing the future. Trust that when execution starts, the next required step will naturally become clearer. Just like a lazy evaluator, clarity is produced only when demanded.

  2. Execute lazily. Live at runtime.

    This idea maps surprisingly well to Zen thinking. Zen does not ask you to stop thinking—it asks you to stop precomputing.

    When I execute a task, I try to stay fully inside the current stack frame. I am only here, only now. In that sense, I am a single-threaded system.

    Humans are not compilers running with -O3. We don't need to speculate every branch, unroll every loop, or pipeline every future scenario. Multitasking looks powerful, but for human brains it often results in cache stalls, context switching, and mental thrashing.

  3. Meaning emerges during execution, not before it.

    Zen has a quiet reminder:

    The path appears where the feet land.

    In engineering terms, many insights are late-bound. They cannot be derived at design time—they emerge only when the system runs. Wishful thinking lets me defer unnecessary decisions. Zen teaches me to stay present enough to recognize the right one when it finally arrives.

Conclusion

Wishful thinking is not about pretending things will work out. It begins with a wish—a clearly defined outcome that is worth moving toward.

But a wish alone is fragile. What makes it actionable is trust:

By choosing what to wish for carefully, and by trusting the process enough to proceed without full certainty, I stop waiting for permission—from circumstances, from people, or from future versions of myself.

Wish gives direction.
Trust gives motion.

Together, they allow progress without anxiety, and commitment without rigidity. That is what wishful thinking really means to me.

Knowing this and living this are different things. I practice wishful thinking the same way I practice Medicine Buddha practice—not expecting overnight transformation, but trusting that each iteration compounds. Some days I remember. Some days I spiral back. But each time I catch myself, the next time gets easier.

Other Reference

Index
What is Wishful Thinking?
How I Apply Wishful Thinking to My Life
- 01. Define the Goal
- 02. Find the Procedures
- 03. Lazy Evaluation
Conclusion
Other Reference