The Square Canisters Apollo 13 Had, and Why They Had to Change the Air

A strong coding game lets a child see the repaired instruction change the machine they are operating. If the train, rover, bridge, or circuit behaves exactly the same after a “fix,” the child may be collecting a correct answer without learning why it works.

In 1970, Apollo 13’s crew faced a problem that could not be solved with a reassuring message on a screen. Carbon dioxide was building up in the lunar module, and the square lithium hydroxide canisters from the command module would not fit the lunar module’s round openings. At Mission Control in Houston, engineer Ed Smylie led a team that devised an adapter from materials already aboard the spacecraft. The crew followed the transmitted procedure, and the altered setup changed the life-support system’s operation.

NASA’s Apollo 13 Flight Journal documents the problem and the improvised adapter. The instruction mattered because it operated a real system. The crew could see the consequence in the spacecraft’s readings.

The visible-change test

Parents can use a simple question when trying a coding game: after my child repairs a program, what visibly changes?

A useful answer sounds concrete. The train reaches the station. A signal changes. A blocked route clears. A character turns at the missing junction. A circuit lights after the right connection is made.

A weak answer often sounds abstract. The app marks an answer correct, adds points, opens a chest, or moves to the next question. Those actions can confirm completion, but they do not show the child what their instruction caused.

The difference matters because early coding is about cause and effect. Children are learning that instructions have an order, that one missing turn can send a system somewhere else, and that repeating or branching changes what happens next. A visible result gives them something to inspect, revise, and try again.

Watch what happens before the reward

The fastest audit takes a few minutes. Sit nearby while your child faces a broken route or program. Before looking at badges, coins, or the next screen, watch the machine.

Can your child point to the problem? Can they say what they expect the repaired instruction to do? When they make a change, does the game preserve enough of the scene for them to compare the old result with the new one?

A well-made challenge leaves the reasoning on stage. If a train stopped at the wrong place, the child can see where it stopped. If they swap an instruction, the next run shows a different path. The repair becomes evidence.

That also makes mistakes useful. A wrong route can reveal that a turn happened too early. A repeated instruction can send the train past its destination. The child has a reason to adjust the program because the system gave them a clear response, not because a red mark told them to try again.

This is the same reason a child may replay a solved challenge. They may be checking a pattern, testing a different route, or enjoying the moment the machinery responds. What Does It Mean When a Child Replays a Solved Challenge? explores why that return can signal active thinking.

A repair should create a before and after

Look for an app that gives the child a stable problem, a small set of meaningful instructions, and a visible before-and-after result. The program should be short enough for a child to hold in mind, especially at first. The scene should make the goal understandable without requiring a long paragraph of reading.

For younger players, that might mean routing a train toward a lit platform. For older children, it can mean predicting where a sequence ends, adding a repeat, or choosing a branch based on what appears on the track. The complexity can grow, while the basic promise stays clear: this instruction changes this system.

That clarity also helps parents distinguish learning from decorative coding language. Words such as “algorithm,” “STEM,” and “problem solving” do not prove much on their own. A child moving tiles around a screen may be learning, or may be completing a sequence puzzle with a coding theme pasted over it. The visible-change test asks for proof in the play itself.

What to ask after a session

A better post-play question is “What did you change?” rather than “Did you win?”

Listen for an answer with a mechanism: “I put the turn before the bridge,” or “I needed the repeat because the train had to go forward three times.” If your child cannot explain it yet, ask them to run the old program and the new one. The comparison often supplies the words.

Apollo 13’s adapter did not earn points for the crew. It changed the path of air through their spacecraft. A child’s repaired rail route carries far smaller stakes, thankfully, but the learning shape is similar. The instruction has meaning when it produces an observable consequence.

When you next try a coding game, pause after the repair. Watch the train move, the signal change, or the route fail in a new way. That moment is where the lesson lives.