How to Think Like a Programmer

The first and most important habit is decomposition: taking one intimidating task and splitting it into smaller tasks, then splitting those again, until every piece is something you plainly know how to do. A computer cannot 'build a room schedule' in one leap, and neither can you - but you can read a file, calculate an area, and write a row, and a schedule is just those small acts repeated.

Suppose the task is 'produce a room schedule with areas from my room list.' Decomposed, it becomes: (1) get the list of rooms and their width and length; (2) for each room, multiply width by length to get area; (3) round the area sensibly; (4) collect the results into a table; (5) write that table to a file. None of those five is frightening. That is the whole point of decomposition - it converts one problem you cannot see the end of into a handful you can. It also gives you a place to start, which is half the battle: instead of staring at 'build a schedule' with no purchase, you pick step one and do it, then step two. And it makes progress measurable and mistakes findable - when a five-step script misbehaves, you can check each step in turn rather than squinting at the whole thing. This is not a coding trick; it is the same move as breaking a building into structure, envelope, services and finishes so you can actually design it. When a scripting task feels overwhelming, you have almost always skipped this step. Break it down further, and it stops being overwhelming.

The second habit is spotting patterns - the repetition and sameness inside a task - because repetition is exactly what a computer does cheaply. Look back at the room-schedule steps: step 2 said 'for each room, multiply width by length.' That little phrase 'for each' is a pattern - the same operation applied to every item in a group - and it maps directly onto a loop, the engine of leverage from Lesson 0.1.

Designers are already good at this. You notice that every drawing needs the same title block, that every room over a size threshold needs a second socket, that the parking layout is one stall repeated with a rule. Each observation is a pattern, and each is a candidate to express once in code and apply everywhere. The habit worth building is to listen to how you describe a task out loud: the words 'every', 'each', 'all of them', 'whenever' and 'for the ones that' are your own language flagging a pattern a script could carry. Two patterns are worth naming because they recur endlessly. Repetition - 'do this same thing for every X' - becomes a loop. Conditional rules - 'if this is true, do that; otherwise do the other' - become a decision (an if). Almost every script you will ever write is built from these two shapes wrapped around some data. Training yourself to hear 'for each...' and 'if...' inside a plain-English task is most of what it means to think like a programmer.

An algorithm is just a fancy word for a precise recipe: an ordered list of unambiguous steps that reliably produces a result. The emphasis is on precise and ordered, because a computer, unlike a colleague, has no common sense and will not fill gaps for you. If your steps are vague or out of order, it does the wrong thing exactly as told.

Consider a recipe written for a human: 'add the rooms up and sort them.' A person copes. A computer needs to know: add up which number - area? occupancy? In what order do you sort - ascending or descending, by which field? What happens to a room with no area recorded? Thinking like a programmer means anticipating those questions and pinning down the steps until no ambiguity remains. It also means order matters: you cannot sort rooms by area before you have calculated the areas, and you cannot total a column you have not read yet. A good test of an algorithm is whether a literal-minded stranger could follow it and get your result without asking a single question. If they could not, the gap they would trip on is exactly the gap the computer will trip on too.

Designers meet algorithms constantly without calling them that. A stair-setting-out method, a rule for laying out parking bays, the sequence for issuing a drawing set, a fire-egress calculation - each is an ordered recipe that must be followed precisely to give the right answer. The shift when you script is only that your audience changes from an experienced colleague, who quietly corrects your slips, to a machine, which does not. That is why the discipline of precision feels new even though the underlying activity is familiar: you are writing the same kind of recipe, but now every unstated assumption has to be stated.

How do you get from a plain-English task to real code without drowning in syntax? You use pseudocode - a halfway language. Pseudocode is instructions written in structured, code-shaped English: it borrows the skeleton of programming (for each, if, otherwise, set this to that) but ignores the exact spelling a real language demands. It lets you work out the logic first, when the logic is the hard part, and translate to Python second, when the syntax is the easy part.

Take the rule 'every room over 15 square metres needs two sockets.' In pseudocode:

for each room in the room list:
    if the room's area is greater than 15:
        give the room 2 sockets
    otherwise:
        give the room 1 socket

That is not valid Python, and it does not need to be - it is thinking made visible. Now the translation to Python is almost mechanical:

for room in rooms:
    if room["area"] > 15:
        room["sockets"] = 2
    else:
        room["sockets"] = 1

Notice how little changed: 'for each' became for, 'if ... greater than' became if ... >, 'otherwise' became else. The thinking - decompose, spot the 'for each' and the 'if', order the steps - was done in the pseudocode. This is the habit to build for the whole course: reason in pseudocode first, then reach for syntax. It is also exactly how to brief an AI assistant well - a clear pseudocode outline is a precise instruction it can turn into correct code, which Module 10 explores.

Let us run the whole mindset once, end to end, on a real request: 'from my list of rooms, tell me the total area and which rooms are undersized (below 9 square metres).'

First decompose: (1) get the rooms with their areas; (2) add every area to a running total; (3) check each room against the 9 sqm limit; (4) report the total and the flagged rooms. Next spot the patterns: steps 2 and 3 both say 'for each room' - one loop can do both, accumulating the total and testing the limit as it goes. That 'below 9' test is a conditional. Now write the pseudocode:

set total to 0
set undersized to an empty list
for each room in rooms:
    add the room's area to total
    if the room's area is less than 9:
        add the room's name to undersized
report total and undersized

The steps are precise and ordered - total starts at zero before the loop, and we only report after every room is seen. Get that order wrong and the logic quietly breaks: reset the total inside the loop and it always ends at the last room's area; report inside the loop and you print a new answer for every room instead of one final figure. These are not syntax errors - the code would run - they are thinking errors, and catching them is precisely the skill pseudocode trains.

The Python that follows is a near-transcription of this, which you will be able to write comfortably by the end of Module 2. The lesson to carry forward is that you did the real work before any Python: you decomposed, found the loop and the condition, and ordered the steps. Syntax is the last, easiest mile. Master this way of thinking and every language, and every AI assistant, becomes a tool you can actually direct rather than a black box you hope gets it right.