Thinking like a programmer

Every engineer now writes code. A civil engineer processes thousands of survey points, a chemical engineer fits rate constants to lab data, a mechanical engineer runs a hundred variations of a design calculation overnight, an electrical engineer programs a microcontroller. You do not need to become a professional software developer, but you do need to tell a computer precisely what to do, and to judge whether its answers are right.

This course teaches programming with Python, the language most widely used in engineering and science for calculation, data analysis and automation. It is free, readable, and comes with enormous libraries for numerical work. This first chapter is about the thinking that comes before and around the code: breaking problems into exact steps, planning with pseudocode and flowcharts, running your first programs, reading error messages, and testing results against hand calculations.

What a program is

A computer does exactly what it is told, very fast, and nothing else. It has no common sense and cannot guess what you meant. A program is a precise set of instructions written in a language the computer can carry out.

Behind every program is an algorithm: a finite, unambiguous sequence of steps that solves a problem. The long-division method you learned in school is an algorithm. So is the method of joints from ENGG-130: find the reactions, start at a joint with two unknowns, solve two equations, move to the next joint. Programming is mostly the work of turning a vague task into an algorithm; typing the code is the easier part.

Why do engineers program rather than use spreadsheets or calculators?

• Repetition: the same calculation on thousands of inputs (every beam in a building, every hour of a year of sensor data).
• Reliability: once tested, a program gives the same answer every time; a manual calculation can go wrong in a new way each time.
• Exploration: running a design calculation for hundreds of combinations of parameters to find the best one.
• Automation and control: reading instruments, operating equipment, producing reports.
• Transparency: a well-written program is a record of exactly how a result was obtained, which a reviewer can check.

Breaking a problem down

Large problems become manageable when split into smaller ones, each simple enough to solve directly. This decomposition is the core skill of programming. Ask: what are the inputs? What output is needed? What steps turn one into the other? Can any step be split further?

Pseudocode

Pseudocode is a plain-language description of an algorithm, precise enough to translate line by line into code but free of any language's syntax. Writing it first separates thinking about the logic from fighting with the language.

Flowcharts

A flowchart shows an algorithm as a diagram: ovals for start and end, rectangles for actions, parallelograms for input and output, and diamonds for decisions with yes/no branches. Flowcharts are especially good at showing decisions and loops, and they are still used to document control logic in industry.

Getting started with Python

You can run Python in several ways. Install it free from python.org and use the IDLE editor that comes with it; install a code editor such as VS Code; use Jupyter notebooks, which mix code, results and notes and are popular for engineering analysis; or use an online environment in a web browser. Any of these works for this course.

There are two modes. In the interactive shell (the >>> prompt), you type one line and Python answers immediately, which is handy for trying things. In a script, you write a file of instructions (ending in .py) and run it all at once, which is how real programs are built and saved.

print("Hello, HSM University")
print(2 + 3 * 4)
print("250 psi is", 250 * 6.894757, "kPa")

Running this displays three lines:

Hello, HSM University
14
250 psi is 1723.6892500000001 kPa

Three things to notice. Python runs the lines in order, top to bottom. It follows the usual order of operations, so \(2 + 3 \times 4 = 14\). And the conversion prints a long string of digits ending in ...0001: computers store most decimal numbers in binary, with tiny rounding errors. You will learn to format output neatly, and why this happens, in Lesson 2.

Comments and style

Code is read far more often than it is written, by your teammates, your reviewers, and you in six months. A # starts a comment, which Python ignores. Use comments to explain why, not to repeat what the code obviously does. Give variables meaningful names that include units where it helps: span_m, load_kN. Python's community style guide, PEP 8, recommends lower-case names with underscores and four spaces of indentation.

# Convert the design pressure from the client's spec (psi) to kPa for the code check
PSI_TO_KPA = 6.894757      # exact conversion factor to 7 significant figures
design_pressure_psi = 250
design_pressure_kPa = design_pressure_psi * PSI_TO_KPA
print(design_pressure_kPa)

When things go wrong: three kinds of error

Every programmer, at every level, writes code with errors in it. The skill is finding and fixing them quickly. Errors come in three kinds.

Syntax errors

A syntax error means the code is not valid Python, like a sentence with broken grammar. Python reports it before running anything, with the file, the line and a caret (^) pointing near the problem.

Runtime errors

A runtime error (called an exception in Python) happens when valid code tries to do something impossible: divide by zero, use a variable that does not exist, open a file that is not there. Python stops and prints a traceback, which shows where the error happened. Read tracebacks from the bottom up: the last line says what went wrong.

Logic errors

A logic error is the worst kind: the program runs without complaint and produces a wrong answer. Only checking the result catches it.

Testing: never trust an untested program

A program that runs is not a program that works. Before relying on any result, test it.

• Check a case you can work out by hand. If your beam program says a 1 m simply supported beam with a 2 kN central load has 0.5 kN reactions, something is wrong (they should be 1 kN each).
• Check special cases: zero load should give zero deflection; a symmetric problem should give symmetric answers.
• Check units and orders of magnitude: is a floor deflection of 3 m plausible?
• Check edge cases: what happens with an empty data file, a negative input, a reading exactly at the limit?

This is the same discipline as checking a hand calculation, and it matters even more for code, because a program will repeat the same mistake perfectly, thousands of times, and its neat output looks trustworthy.

Work in small steps. Write a few lines, run them, check the output, then add more. When something breaks, you know it was in the last few lines. Beginners who write a hundred lines before running anything spend hours hunting for errors that would have taken seconds to find one at a time.

Debugging strategies

• Read the error message carefully, starting from the last line.
• Print intermediate values to see where the numbers stop making sense.
• Trace the program by hand on a small example, writing down each variable's value line by line.
• Simplify: comment out parts until the problem disappears, then add them back one at a time.
• Explain the code line by line to someone else (or to an inanimate object; programmers call this "rubber duck debugging"). Saying it aloud often reveals the mistake.

When software fails

Software errors in engineering systems have caused some famous failures, and their lessons apply to every program you write.

Two other cases are worth knowing. On its first flight in 1996, the Ariane 5 rocket veered off course and self-destructed about 40 seconds after launch when software reused from Ariane 4 tried to convert a 64-bit floating-point number, larger on the faster new rocket, into a 16-bit integer; the conversion overflowed and shut down the guidance system. And in the 1980s, the Therac-25 radiation therapy machine gave several patients massive overdoses, some fatal, partly because of software errors that appeared only when operators typed quickly; earlier models had hardware interlocks that the designers relied on software to replace. The common lessons are to test reused code in its new conditions, never to remove safety layers just because software is present, and to treat software as part of the engineered system, with the same rigour as steel and concrete.