How to approach problems

A four-step process that works for almost any programming problem — understand, example, brute force, optimise.

Most programming errors are not syntax errors. They're thinking errors — starting to code before the problem is fully understood. A consistent process fixes this. The four steps below apply whether you're solving a whiteboard puzzle or designing a feature from scratch.

Step 1: Understand the problem precisely

Before touching a keyboard, restate the problem in your own words. What are the inputs? What should the output be? Are there constraints — size limits, edge cases, performance requirements?

If you can't write a one-sentence problem statement, you don't understand the problem yet. This sounds obvious. It isn't. The most common source of wasted work is building the wrong thing with great precision.

Pay special attention to edge cases: empty inputs, single-element inputs, negative numbers, strings with special characters. Real bugs almost always live at the boundaries, not in the happy path.

Step 2: Work through examples by hand

Pick two or three concrete inputs and trace the expected output manually — on paper, in a comment, wherever. Small examples reveal structure that an abstract description hides.

If you're asked to find the maximum number in a list, try [3, 1, 4, 1, 5, 9]. The answer is 9. How did you find it? You scanned left to right, keeping track of the largest value seen so far. That mental process is the algorithm.

Working examples by hand also generates your test cases. A test suite written before the code is worth more than one written after — it's much harder to unconsciously write tests that match your implementation's specific quirks.

Step 3: Write the brute-force solution first

Once you have examples, write the simplest possible solution that produces the right answer. Don't think about speed yet. A slow, obviously-correct solution is far more valuable than a fast, possibly-wrong one.

This step matters more than most beginners expect. Getting something correct first gives you something to validate the optimised version against. It also frequently reveals that the problem is easier than you feared — sometimes the brute-force solution is the right solution.

Step 4: Optimise — but only once it's correct

If the brute-force version is too slow (or uses too much memory), now you optimise. A common pattern: an inner loop that rescans data can often be replaced by a data structure that makes the same information available in O(1) time. You'll see this concretely in the next few lessons.

Notice the order: understand, then example, then correct, then fast. Reversing any step costs time.

What is an algorithm?

An algorithm is a repeatable, finite procedure for solving a class of problem. "Scan a list from left to right, keeping track of the largest value seen" is an algorithm. It doesn't depend on the specific list — it works on any list of comparable values.

Algorithms are the vocabulary of problem-solving. Learning a handful of fundamental ones — linear scan, binary search, depth-first traversal — gives you templates to reach for instead of reinventing from scratch every time.

The four-step process is not a rigid ritual. It's a checklist against the most common ways programmers go wrong. When you're stuck, ask which step you skipped.

Where to go next

Next: solving with lists — applying the four-step process to a set of concrete list problems in Python.

Finished reading? Mark it complete to track your progress.