Fable
The person who could explain the problems finally started moving the abacus
In the academy there was a teacher who was very good at explaining arithmetic problems. He could explain the problems clearly and could also state the general approach. But when it came to long calculations, he often got the decimal point or parentheses wrong.
At first the student thought the teacher wasn't clever enough. The more detailed the teacher's explanation, the more hidden the error, because every sentence sounded reasonable and only the final number was wrong.
The director first asked the gentleman to calculate slowly in his head. Speed dropped and errors decreased somewhat, but complex accounts were still worrying.
One day, the teacher no longer directly gave the answer. He first translated the problem into a clear set of abacus steps: which numbers to take, which formula to follow, how many times to loop, and what to output at the end.
The calculator beside him moved the abacus step by step and quickly gave an exact result. The teacher was responsible for understanding the problem and writing the steps, while the calculator was responsible for executing calculations that would not be ambiguous.
The first collaboration also went wrong. The gentleman translated the problem incorrectly, and no matter how accurately the abacus was calculated, it would only be accurately wrong. The director required every step to be checkable and the inputs and outputs to be written clearly. Later the gentleman encountered a type of problem: the prompt was very long, but only three steps actually needed calculation. He first extracted the variables in his own words, then handed the steps to the calculator; if the problem statement was ambiguous, he asked first instead of rushing to use the abacus.
Later, whenever the academy encountered tables, dates, statistics and logic problems, it had the master first write executable steps, then let a tool compute the result. Explanation still mattered, but computation was handed to a reliable executor. The academy also learned to check two risks. If the steps were written wrong, it was a comprehension error; if the steps were correct but the abacus executed wrong, it was a tool or input error. Looking at them separately, fixing mistakes stays orderly.
The students discovered that the best answer was not for the teacher to pretend he could mentally calculate every detail, but to know when to turn reasoning into a program. The teacher said: language is good at understanding problems, programs are good at strict execution. Complex problems should let each do the part it does more reliably. Later the steward wrote this experience into the daily rules: first look at the scenario, then look at the boundaries, and finally look at who can take over when it fails. Only when all of these are clear will a beautiful demo become deliverable work.