A teacher-advisor prints a one-page progress slip for each student before conferences: three terms and a final mark, each shown as a number and a letter. She wrote the program herself, years ago, and it works. You are inheriting it this morning.

Open the file. Here is the part that turns term one’s mark into a letter:

term1 = 78
 
if term1 >= 80:
    term1_letter = "A"
elif term1 >= 70:
    term1_letter = "B"
elif term1 >= 60:
    term1_letter = "C"
else:
    term1_letter = "R"
 
print(f"Term 1: {term1} ({term1_letter})")

Scroll down. The same eight lines of grading appear again for term2, again for term3, and again for final_mark. Four copies, identical except for the name of the mark being graded.

The task

Two jobs, in this order, and no skipping ahead.

Job one — read it. Before touching anything, write down what the program does, in your own words, in three sentences. Then predict its output for a student with marks of 78, 64, 81, and 74. Run it and check your prediction.

Job two — the change request. The advisor emails at 8:40am:

The department moved the B cutoff. It is 72 now, not 70. Can you have it ready for period one?

Make the change. Time yourself. Then trade programs with another pair and grade their change with a mark of exactly 71 in every position.

The count

Hands up, honestly:

  1. How many places did you have to edit?
  2. How many pairs got all four? How many got three?
  3. If the advisor asks tomorrow for a D band between C and R, how many edits is that — and how sure are you of your own number?

The pair that got three out of four did not make a careless mistake. They made the mistake this program is designed to produce.

What tends to surface

The room usually starts by blaming itself — “I should have used find and replace”, “I should have been more careful”. Push back on that. The bug was not in anybody’s attention span and it was not in any single line of code. It was in having four copies at all. A program with four copies of an idea has four chances to disagree with itself, and it will take them.

The second discovery is about reading. Four near-identical blocks make the program look long and feel complicated, when it actually contains one small idea repeated. Programs that are honest about how many ideas they contain are easier to change, which is the beginning of design rather than merely coding.

Where this goes next

What you invented this morning is named, with the same example, in Functions. You will read and change somebody else’s in Writing Functions and drill the mechanics in Functions Practice. Once the thinking has names, whole programs can be built out of named parts — Decomposition and Design — and a set of parts good enough to reuse becomes your next task, The Toolbox.

The answer is not on this page

The one-copy version is not printed here. Your class writes it, on the board, from the sentence somebody says out loud when the cross-grading reveals the miss. The syntax takes four minutes to learn; the reason it exists takes one very annoying email.

Curriculum connection

A3.2

write subprograms (e.g., functions, procedures) that use parameter passing and appropriate variable scope (e.g., local, global), to perform tasks within programs.

Link to original

B2.3

apply the principle of modularity to design reusable code (e.g., subprograms, classes) in computer programs;

Link to original