On a rainy Thursday, a group of four learners sat in a training lab staring at a deployment that refused to start. Aditi had followed the instructions, Varun had double-checked the configuration, and Nisha was convinced the instructor’s sample was wrong. Karan, the quietest of the group, said something that changed their week: “Let’s stop fixing it and explain it to the next batch instead.” This account follows that team as they learned to teach what they had just figured out, and it is an illustration of how the habit works, not a report on any real class.
The lab that would not start
The exercise was routine: package a small web application, push it through a pipeline and see it running. Everything worked until the final stage, where the application kept restarting. The group spent most of the session changing things at random. Aditi edited the port. Varun rewrote a line in the file that told the application where to find its database. Nothing helped, and the clock ran down.
When the instructor stopped by, she did not give them the answer. She asked each of them to explain, in their own words and to the person on their left, what the application needed in order to start. That request is where the learning began.
The moment the explanations fell apart
Aditi went first. “The app needs a database address,” she said, “and a port.” Varun asked where the address comes from. She paused. “From the file.” Which file, he asked, and who reads it, and when? Within a minute she had run out of answers. The group realised that all four of them had been editing a file the running application never read. The explanation had found the gap in a way hours of trial and error had not.
The habit echoes our article on sharpening your reasoning when systems misbehave, which makes the same case: when you cannot explain how something should behave, you are not ready to change it. Slowing down to describe the system turned out to be quicker than guessing, and it left all four of them with a clearer picture of how the pieces fit than the original instructions had.
Writing it for the next batch
Karan proposed the write-up. They would produce a half-page note for whoever took the course next, covering the exact symptom, what they believed, what was true and how to check it. Nisha took the symptom, Varun the wrong assumptions, Aditi the real cause and Karan the verification step. Because they were writing for strangers, they could not rely on shared memory of the afternoon, so each section had to stand on its own.
Their note had a handful of habits worth copying:
- It began with what the screen showed, not with the diagnosis.
- It listed the three wrong guesses, since the next group would try them too.
- It explained why the correct change worked, in two plain sentences.
- It ended with one command to confirm the fix.
- It admitted what the team had not tested.
What changed afterwards
The following week the team met a new problem and approached it differently. Instead of editing at random, they narrated the system out loud first. Nisha later said the exercise had given them a shared routine: describe, predict, then change. The group also noticed that the topic on which they had written a note was the one they were able to answer in the course test, while a neighbouring topic they had only read about felt shaky. Their sample is small and their experience is not evidence of a rule, but it matches what many instructors report.
When the group wanted to understand how the stages of their pipeline connect, they turned to our walkthrough on getting a quick feel for how delivery pipelines fit together, and then rewrote the relevant paragraph of their own note in simpler terms.
Giving the note a public home
Eventually the team wanted the note to live beyond the lab folder. They put it on MyBlogPad, a blogging network where each blog sits on a personal subdomain and several contributors can share one blog, so all four names could appear on a single page. Anyone arriving at the same lab error later could now find it with a search.
Lessons for learners and instructors
- Explain before you edit. If you cannot describe how the system should behave, further changes are guesses.
- Write for a stranger. It forces each step to stand alone.
- Record the wrong turns. They save the next reader time.
- Verify the fix. A check you can run turns a story into a tool.
- Say what you did not test. It keeps the note honest as tools change.
Trying it in your own course
You do not need a special programme. At the end of the next lab, give everyone ten minutes to write a few lines for someone who will take the course next term. Ask them to include the symptom, the wrong assumption and the check. Read two or three aloud and notice which sentences make people frown. Those frowns point to the topics worth revisiting, and the writers themselves will have found them first.
The deployment that would not start eventually did. What the four of them remembered months later, though, was not the fix. It was the afternoon they learned that explaining a problem to a beginner is the quickest way to find out what you still do not know.
