Living Museum of Learning
One Trip or Two?
Tianjing was working on a familiar programming problem:
Find the second-largest number in a list.
Her program generated seven random numbers:
[60, 51, 95, 134, 181, 15, 181]
and produced:
134
At first glance, everything looked fine.
But then we found a bug.
Her code began with:
max = box[0]
second = box[0]
and later tried to handle a special case:
if max == second:
second = box[1]
The problem appears when box[0] and box[1] are both the largest numbers.
The special case does not correctly solve the situation.
We could have spent a long time fixing the code.
But we didn't.
There was a more interesting question waiting.
I asked Tianjing:
“Do we really need two trips through the list?”
We went to the whiteboard.
She drew several classrooms, one after another, and a little stick figure representing herself walking through them carrying the heavy task of finding the second-largest number.
This time, she even gave herself two eyes.
😂
I asked whether she could do the job in a single trip.
She thought for a moment.
Then:
“应该行吧，只走一趟。”
“Should work, I guess. Just one trip.”
And she started walking through her imaginary classrooms.
She kept two numbers.
When a new number arrived, she compared it with the two candidates.
If necessary, she crossed out the smaller one and kept the better candidate.
Then she moved on.
Room by room.
Number by number.
One trip.
Something important had changed.
The original question looked like a programming problem:
“How do I write code that finds the second-largest number?”
But Tianjing had begun treating it as an algorithm-design problem:
“What information do I need to carry as I walk through the list?”
The answer was surprisingly small.
She didn't need to remember every number.
She didn't need to go back.
She didn't need a second trip.
She only needed to maintain two important candidates as she moved forward.
The whiteboard algorithm came before the code.
Then came the inevitable question:
“But how can this become code?”
She wasn't quite sure yet.
I told her:
“It won't be a big problem for you, because you already have this great algorithm.”
The hard part had already happened.
The code was simply waiting to be written.
A bug is sometimes useful because it exposes a deeper question.
In this case, the bug made us look beyond the immediate code and ask:
Can we solve the problem more simply?
Tianjing discovered that an algorithm does not have to imitate the way a person might casually solve a problem.
A person might look for the largest number first, then search again for the second-largest.
A programmer can ask:
What is the smallest amount of information I need to carry forward?
That question leads naturally to a one-pass solution.
And there was another small but important shift.
Tianjing didn't begin by asking for code.
She began by drawing.
Rooms.
A person.
Two numbers.
Crossing one out.
Moving forward.
The algorithm became visible before it became executable.
This is one of the most valuable transitions in programming:
Think first. Code second.
And when the thinking is good enough, turning it into code is no longer the scary part.
Tianjing trusts Donald.
For sure. 😂
Now Donald just has to make sure the code deserves that trust.
