From Problem to Program
The hardest part of programming is often not the syntax but the modelling: deciding how to represent a real-world problem in terms a computer can process. A model is a deliberate simplification — it captures the parts of a problem that matter for the task and ignores the rest.
Modelling has recognizable steps. First, identify the data: what quantities and entities does the problem involve, and what type is each (a number, a list, a name-to-value map)? A shopping cart might be a list of items, each with a price; a phone book is a dictionary from names to numbers. Choosing a fitting data representation is half the battle — the right structure makes the algorithm easy; the wrong one makes it painful.
Second, define the algorithm: the step-by-step procedure that transforms the input data into the desired output. "Total the cart" becomes: start a running sum at zero, loop over each item, add its price to the sum, and report the sum. Writing this in plain, structured pseudocode before real code lets you get the logic right without fighting syntax.
Third, consider what can vary and what must hold — the assumptions and constraints (prices are non-negative; the list may be empty). A good model states these explicitly so the program handles them.
Common pitfall: diving straight into writing code before modelling the problem — before deciding what the data is and sketching the algorithm. This almost always leads to tangled, buggy code. Model first: name the data and its types, write the steps in pseudocode, then translate to real code.