The vocabulary, and what each idea buys

The six

Algorithm. A sequence of unambiguous steps that turns an input into an output. The difficulty is never the sequence; it is the unambiguity. 'Check the beam' is not an algorithm. 'For each load combination, compute the moment; find the section whose moment resistance exceeds it and whose deflection under the serviceability combination is below span/360; return the lightest' is.

Variable and parameter. A named value. Naming it is the point: span rather than 7.2 means the number appears once, and changing it changes every use. Typing the same number in eleven places makes inconsistent updates easy to miss.

Condition. A branch: if the utilisation exceeds one, then take the next section. Conditions are where the engineering judgement gets encoded, and they are where the untested edge cases live. What happens exactly at 1.0? What if the list runs out?

Loop. Repetition. Loops are what make automation worth doing and they are also how one mistake becomes two hundred. A loop over load cases applies your logic — and your error — to every case identically.

Function. A named, reusable piece of behaviour with declared inputs and outputs. This is the unit of reuse, of testing, and of understanding. A function that computes a moment resistance can be tested against a worked example independently of everything around it, and that is what makes the whole assembly trustworthy.

Data structure. How information is organised. A list of load cases, a table of sections, a nested description of a frame. Choosing it badly makes everything downstream awkward; choosing it well makes the code read like the engineering.

Error handling and testing

Two more that are not optional in engineering software.

Error handling. What happens when the input is nonsense — a negative span, an empty section list, a load case with no loads. The right behaviour is nearly always to stop and say so. A tool that returns a plausible number for impossible input is more dangerous than one that crashes, because the crash gets investigated.

Testing. A test is a worked example the computer re-checks every time the code changes. Its value is not that it proves the code right; it is that it catches the day you change something and break something else. Untested code is a hypothesis.

Everything in this course's calculation library is tested this way, and the tests have caught real errors while it was being written — including a beam check that was 12.5 % wrong and would otherwise have been quoted in a lesson.