Imagine two programmers sitting in front of the same empty editor.

Both know the language.

Both know loops.

Both understand variables, functions, arrays, classes, and conditionals.

The first programmer reads the problem and immediately starts typing.

Ten minutes later, the code is growing.

Twenty minutes later, another if statement appears.

Then another function.

Then a patch to fix the previous patch.

Soon the programmer is staring at a hundred lines of code and no longer remembers exactly why half of them exist.

The second programmer does something strange.

Nothing.

No typing.

No code.

They read the problem again.

Then they take out a piece of paper.

They write down what is known.

What is unknown.

What the input looks like.

What the output should be.

They try a tiny example by hand.

They break the large problem into smaller ones.

Only then do they touch the keyboard.

An hour later, the first programmer is debugging.

The second is almost finished.

This difference is at the heart of V. Anton Spraul's Think Like a Programmer: An Introduction to Creative Problem Solving.

The book is not primarily about memorizing C++ syntax. Spraul uses C++ as the teaching language, but the larger subject is the mental process behind programming: how to move from a confusing problem to a structured solution. Its chapters progress from general problem-solving strategies and puzzles into arrays, pointers and dynamic memory, classes, recursion, code reuse, and finally the broader question of what it means to think like a programmer. (No Starch Press)

And its central lesson is surprisingly simple:

Programming is not really about writing code.

Programming is about solving problems.

Code comes later.

---

The Blank Screen

Every programmer eventually meets the same enemy.

The blank screen.

The problem statement is sitting beside you.

You understand every word.

You know the programming language.

Yet you have absolutely no idea what to write.

This moment is frustrating because beginners often assume experienced programmers don't experience it.

They imagine senior developers reading a problem and instantly seeing the solution.

Usually, that isn't what happens.

Experienced programmers are often simply better at what happens after they don't know the answer.

Instead of panicking, they begin reducing uncertainty.

That is one of the major themes running through Spraul's approach: problem solving can be practiced as a process rather than treated as some mysterious talent people either possess or do not. Reviews of the book likewise emphasize that it focuses on the often-neglected gap between knowing programming syntax and knowing how to construct a solution. (WIRED)

The beginner asks:

"What code should I write?"

The problem solver asks:

"What exactly am I trying to accomplish?"

That small change in question changes everything.

---

First: Understand the Problem

Suppose someone tells you:

"Write a program that validates an identification number."

Your fingers may already be moving toward the keyboard.

Stop.

What does "validates" mean?

How long is the number?

Can it contain letters?

Is there a checksum?

What happens with malformed input?

What should the program return?

Before solving a problem, you need to know what the problem actually is.

This sounds obvious.

Yet countless programming bugs begin because developers solve an assumption rather than the requirement.

The machine is brutally literal.

Humans understand ambiguity.

Computers don't.

If you tell another person:

"Find the biggest number in this list,"

they understand what you probably mean.

The computer needs details.

What if the list is empty?

Can values be negative?

Are duplicates allowed?

What type of number?

What should happen when there is no value?

Thinking like a programmer means discovering these questions before the code forces you to discover them.

---

Solve the Problem With Your Hands First

Imagine being asked to write a program that sorts a pile of numbers.

Before thinking about algorithms, take five cards and write numbers on them.

Now sort them manually.

What did you actually do?

Perhaps you looked for the smallest card.

Placed it first.

Then found the smallest remaining card.

Repeated the process.

Congratulations.

You have already described an algorithm.

The computer version is merely a precise translation of what you just did.

This technique is extremely powerful.

When you don't know how to program the solution, ask yourself:

How would I solve one small example manually?

Write down every step.

Don't skip the "obvious" parts.

Those obvious steps are often exactly what your program needs.

Suppose the task is to determine whether a word is a palindrome.

You try:

LEVEL

You compare:

L ↔ L
E ↔ E
V

Now something becomes visible.

You don't need some magical "palindrome function."

You need a process:

Compare the first and last characters.

Then the second and second-last.

Continue toward the middle.

If any pair differs, stop.

The solution existed before the code.

Programming simply gives it a formal language.

---

Break the Monster Into Smaller Monsters

Large problems feel difficult because the human brain cannot hold every detail simultaneously.

Consider:

"Build an online shopping system."

That is almost meaningless as a programming task.

Where do you begin?

Authentication?

Products?

Payments?

Inventory?

Shipping?

Orders?

Taxes?

Search?

Instead, break it apart.

Shopping System

├── Customer
├── Product Catalog
├── Shopping Cart
├── Inventory
├── Checkout
├── Payment
└── Order Processing

Then take checkout.

Checkout

├── Validate cart
├── Calculate subtotal
├── Apply discount
├── Calculate tax
├── Calculate shipping
├── Process payment
└── Create order

Now take "calculate subtotal."

Suddenly we have something manageable.

For every cart item:

    price × quantity

Add the results.

That can be programmed.

This is one of the most useful habits in software development:

If you cannot solve the problem, reduce its size.

Keep dividing until one piece looks easy.

Then solve that piece.

A surprisingly large system can emerge from many small solutions connected together.

---

Constraints Are Not Your Enemy

Imagine a puzzle:

You must cross a river.

You have a boat.

The boat can carry only two people.

Certain people cannot be left together.

At first the restrictions seem annoying.

But without restrictions, there is no puzzle.

You would simply put everyone in a giant boat and cross.

Constraints give problems their shape.

Programming works the same way.

Maybe memory is limited.

Maybe the input contains one million records.

Maybe responses must return in 100 milliseconds.

Maybe duplicate values are allowed.

Maybe data must remain sorted.

Maybe you cannot modify the original collection.

Instead of complaining about constraints, use them.

They tell you what kind of solution is possible.

If the input contains only ten values, a simple approach might be perfectly adequate.

If the input contains one billion values, the same technique could be disastrous.

The problem has not changed linguistically.

But the constraints have changed the engineering.

---

Don't Solve More Than You Need

There is a particular temptation among programmers.

You are asked to solve:

A

You think:

"But someday we might also need B."

So you design for A and B.

Then:

"Perhaps later C will be required."

Soon you are implementing:

A + B + C + D + plugin system + configuration framework

even though nobody asked for them.

The code becomes sophisticated.

Flexible.

Abstract.

And unnecessarily difficult.

A useful problem-solving discipline is to solve the problem you actually have.

Not every imaginary future version of it.

Good programmers think ahead.

But there is a difference between thoughtful design and speculative complexity.

Sometimes the smartest solution is the boring one.

---

Start With What You Know

When a problem looks overwhelming, find something certain.

Suppose you are trying to decode a strange data format.

You don't understand the whole structure.

But perhaps you know:

The first byte is always a message type.

Good.

Start there.

Then maybe the next four bytes represent length.

Now you know two things.

Continue.

This is similar to solving a jigsaw puzzle.

You rarely begin by understanding the entire image.

You find the corners.

Then the edges.

Then recognizable colors.

Small certainties begin joining together.

Eventually the structure appears.

Programming problems often collapse the same way.

You don't need the entire solution to make progress.

You need one reliable step.

---

Arrays Teach You to Think About Data

The book gradually moves from general puzzles into programming structures such as arrays, pointers, classes, recursion, and reuse. Those topics are not presented merely as language features; they become tools for practicing different ways of organizing and transforming problems. (No Starch Press)

Take an array:

[8, 2, 9, 4, 7]

A beginner sees five numbers.

A programmer starts seeing operations.

Find the maximum.

Count values greater than five.

Reverse the sequence.

Remove duplicates.

Group values.

Search.

Transform.

Compare neighboring values.

Programming becomes easier when you stop seeing data as isolated values and start seeing patterns of operations over data.

For example, many problems have this shape:

Initialize result

For every item:
    examine item
    update result

Return result

Maximum:

result = first item

for each remaining item:
    if item > result:
        result = item

Sum:

result = 0

for each item:
    result += item

Count matching values:

result = 0

for each item:
    if condition:
        result++

Different problems.

Same underlying pattern.

Recognizing patterns is a major part of becoming a stronger programmer.

---

Memory Changes How You See Programs

Spraul devotes substantial attention to pointers and dynamic memory, something that reflects the book's C++ teaching context. (No Starch Press)

For developers working mainly in C#, Java, Python, JavaScript, or other managed environments, direct pointer manipulation may appear less important.

But the deeper lesson remains valuable.

Data exists somewhere.

Objects have lifetimes.

References point somewhere.

Memory is finite.

Creating data has a cost.

Copying data has a cost.

Keeping data alive has a cost.

Understanding what your program is actually doing underneath its abstractions changes how you reason about performance and bugs.

You start asking:

Is this copied?

Is this referenced?

Who owns this object?

When does it disappear?

How much memory are we allocating?

Could this grow forever?

Even when modern runtimes manage memory for us, good programmers still think about resources.

Abstraction removes manual work.

It does not repeal physics.

---

Classes Are About Modeling Thought

Beginners sometimes learn classes like this:

Class = fields + methods

Technically true.

Not particularly helpful.

The more important question is:

Why should these things belong together?

Imagine designing a banking system.

You could scatter data everywhere:

accountNumber
balance
customerName
status

and then create unrelated functions to manipulate them.

Or you can recognize a concept:

BankAccount

Now certain data and operations naturally belong together.

BankAccount

Balance
AccountNumber
Status

Deposit()
Withdraw()
Close()

The class becomes a model of an idea.

That is the deeper value of object-oriented design.

Not turning everything into objects.

But organizing software around meaningful concepts.

Good modeling reduces how much your brain must remember.

Instead of thinking about twenty unrelated variables, you think:

Order.

Customer.

Invoice.

Payment.

Names compress complexity.

---

Recursion: Trust the Smaller Problem

Recursion initially feels almost supernatural.

A function calls itself.

How can something solve itself using itself?

Consider walking through folders:

Documents
├── Work
│   ├── Reports
│   └── Contracts
└── Personal
    ├── Photos
    └── Notes

How do you count every file?

You could say:

Count files directly inside this folder.

For each subfolder:
    count everything inside that folder.

Notice something interesting.

"Count everything inside that folder" is exactly the original problem.

But on a smaller folder.

That is recursion.

The mental trick is to stop trying to imagine every recursive call at once.

Instead say:

If I can trust the function to solve a smaller version correctly, what do I need to do for the current version?

And equally important:

When does it stop?

That stopping condition—the base case—is what prevents recursion from falling forever.

Recursion teaches a broader problem-solving idea:

Sometimes solving a large problem means defining how it reduces itself into smaller versions of the same problem.

---

Reuse Means Recognizing What You Already Solved

Imagine writing a function to validate customer email addresses.

Later another module needs the same validation.

You copy the code.

Then another.

Soon five copies exist.

A bug is discovered.

You fix four.

You forget the fifth.

Reuse is not simply a technique for reducing typing.

It is a way of reducing the number of ideas a system must independently maintain.

If a reliable solution already exists, use it.

Functions.

Classes.

Libraries.

Frameworks.

Existing algorithms.

But reuse has another side.

Don't blindly reuse something merely because it exists.

Understand what assumptions it makes.

Understand its inputs.

Understand its limitations.

A programmer's job is not to reinvent everything.

Nor is it to glue together things they don't understand.

It is to know when an existing solution matches the current problem.

---

Debugging Is Problem Solving Too

Your program crashes.

The beginner says:

"It doesn't work."

That statement contains almost no useful information.

A programmer begins narrowing the possibilities.

Does the program start?

Yes.

Does it read the input?

Yes.

Does parsing succeed?

Yes.

Does the error happen before saving?

No.

After saving?

Yes.

Now the universe of possible causes has become much smaller.

This is the same strategy used everywhere else:

divide the problem.

Debugging is almost scientific.

You have a hypothesis.

Maybe the database connection is failing.

Test it.

Wrong.

New hypothesis.

Maybe this value is null.

Test it.

Correct.

Each test removes possibilities.

The worst debugging strategy is random modification.

Change something.

Run.

Change something else.

Run.

Add delays.

Remove code.

Restart everything.

Eventually the problem disappears and nobody understands why.

That isn't debugging.

That is gambling.

---

Getting Stuck Is Part of Programming

One of the most important psychological lessons in problem solving is accepting that confusion is normal.

You will get stuck.

Often.

A developer can spend three hours making no visible progress and then suddenly solve the problem in ten minutes.

Those three hours were not necessarily wasted.

The brain was learning the shape of the problem.

Failed attempts reveal constraints.

Incorrect assumptions disappear.

The search space becomes smaller.

This matters because frustration creates a dangerous reaction:

randomness.

You stop reasoning and begin trying things.

Instead, when stuck:

Write down what you know.

Restate the problem.

Build a smaller example.

Remove irrelevant parts.

Check assumptions.

Try solving it manually.

Explain the problem aloud.

Walk away briefly and return with a fresh mental model.

The objective is not to avoid getting stuck.

It is to become skilled at getting unstuck.

---

Creativity in Programming Is Not Magic

People often imagine creative programmers receiving brilliant ideas from nowhere.

But much programming creativity is combinational.

You have seen several ideas before.

Then a new problem appears.

Your brain notices:

"This part looks like that old search problem."

"This structure resembles a tree."

"This could be represented as a queue."

"This is basically the same state machine we built previously."

Creativity grows from experience.

And experience grows from solving problems.

This explains why exercises matter so much.

Reading a solution produces recognition:

"Yes, that makes sense."

Solving it yourself creates capability:

"I can discover something like that."

Those are not the same thing.

The book deliberately uses open-ended exercises to force the reader to practice the underlying problem-solving process rather than merely observe finished answers. (Google Books)

---

Knowing Syntax Is Not Knowing Programming

Imagine someone memorizes every keyword in C#.

They know:

if
else
for
while
class
interface
async
await
switch

Can they build an ERP system?

Not necessarily.

Knowing vocabulary does not make someone a novelist.

Knowing musical notes does not make someone a composer.

Knowing chess rules does not make someone a strong chess player.

And knowing programming syntax does not automatically make someone a programmer.

Syntax answers:

How do I tell the computer to do something?

Programming asks:

What should I tell the computer to do?

The second question is much harder.

That gap between syntax and reasoning is exactly the territory Think Like a Programmer was written to address. (WIRED)

---

Then AI Arrived

Today there is an interesting new chapter to this story—one written after Spraul's book appeared.

A programmer can ask an AI tool:

Write a function that groups orders by customer
and calculates total revenue.

And code may appear instantly.

This makes the lessons of problem-solving books less important, right?

Perhaps the opposite.

If machines become increasingly good at producing syntax, human value shifts even more toward:

Understanding the real problem.

Defining requirements.

Recognizing bad assumptions.

Breaking systems into components.

Checking whether an answer is correct.

Understanding tradeoffs.

Designing abstractions.

Debugging unexpected behavior.

Knowing what should be built in the first place.

Research into AI-assisted programming has already highlighted that code-generation tools change the programming experience while still creating challenges around comprehension, evaluation, and problem solving—particularly for less-experienced programmers. (arXiv)

AI can generate a function.

But someone still has to know whether that function solves the right problem.

That is programmer thinking.

---

The Programmer Who Doesn't Type

Return to our two programmers.

The first has learned more syntax.

More frameworks.

More shortcuts.

More tools.

The second has learned something less visible.

When facing a problem, they don't immediately reach for code.

They ask:

What do I know?

What don't I know?

What are the constraints?

Can I solve an example manually?

Can I make the problem smaller?

Have I solved something similar before?

What assumptions am I making?

How can I test whether my reasoning is correct?

Only after those questions does code begin to appear.

And because the thinking happened first, the code often becomes simpler.

That may be the central lesson of Think Like a Programmer.

The best programmers are not necessarily those who type fastest.

They are not necessarily those who memorize the most APIs.

They are not even necessarily those who know the most programming languages.

They are the people who can stand in front of a confusing problem...

remain calm...

break it apart...

find something they understand...

solve one piece...

then another...

and slowly turn uncertainty into structure.

At the beginning, there is only a blank screen.

At the end, there is software.

The keyboard performed neither miracle.

The thinking did.