computational thinking

Computational thinking is the skill of turning a messy, real-world problem into a sequence of steps precise enough for the fetch-decode-execute cycle from Topic 1 to actually carry out. It rests on four habits practiced together: decomposition, which means splitting one large problem into smaller pieces that can each be solved on their own; pattern recognition, which means noticing that a step already solved once is simply repeating, rather than being brand-new work every time; abstraction, which means deciding which details actually matter for solving the problem and deliberately setting the rest aside — the same idea Topic 3 relied on when it treated eight bits as either an integer or a character depending only on which interpretation mattered, without needing to think about the underlying voltage levels at all; and algorithm design, which means assembling the decomposed, pattern-matched, abstracted pieces into one precise, finite sequence of steps that always produces an answer. Pseudocode is that algorithm written down in a plain, half-English, half-structured form before any real programming language gets involved — a stepping stone whose only job is making sure the sequence of steps is complete and unambiguous, not actually running on a computer yet.

A concrete problem makes all four habits visible at once: how much disk space does a given directory use, counting everything inside every directory nested beneath it? Decomposition splits this into two separately solvable pieces — find the size of one file, and find the size of one directory — where the second piece turns out to depend on the first. Pattern recognition notices something important here: a directory can contain other directories, so the exact same find-the-size-of-a-directory step needs to run again on each one of those, which means the sub-problem is repeating rather than being new work, the core insight behind recursion, a procedure whose own definition calls back to itself. Abstraction keeps the plan simple by setting aside irrelevant detail: the procedure never needs to know how the storage device from Topic 1 physically arranges those bytes on disk, only that each file reports a size in bytes, the exact unit Topic 3 defined. Putting all of this into pseudocode: start a running total at zero; for each entry in the directory, add its size to the total if it is a file, or run this same procedure on it and add whatever total comes back if it is a directory; once every entry has been visited, the running total is the answer. That pseudocode is detailed enough for a person to carry out by hand on a small folder, and precise enough that Programming Fundamentals, a later topic in this series, can turn it directly into real, running code without resolving any further ambiguity.