Computer Science & Data: Completion problems

What you'll be able to do: Bridge the gap between following a solution and writing one, by getting code with the middle removed rather than the end.

The gap this sits in

Article 06 named the problem: tutorials train reading, blank files require writing, and nothing connects them. A learner who can follow every line and can't start is stuck between two activities with no rung in between.

Completion problems are the rung. You get working code with a portion removed, and you finish it. Then next time, more is missing. Then more.

The fading is the method. A single fill-in-the-blank is a mild exercise; a sequence of four with growing gaps is a structured route from "I can follow it" to "I can write it" in one sitting.

Which part to remove, which is the whole design decision

This matters more in programming than anywhere else, because the three options train completely different things:

The end removed: tests whether you can carry an approach through. Easiest, and what almost every exercise does.

The middle removed: tests whether you understand why the parts connect, You have the setup and the return; you have to build the bridge.

The beginning removed: testsdesign: what structure does this problem need? This is the hardest and the one that maps to real work, because the blank file is a beginning-removed problem with nothing else given either.

Most students only ever meet the first kind. Ask for the third.

Give me the same problem four times:
1. fully working, with the design decisions commented;
2. working except the last few lines;
3. only the function signature and the return statement. I write the middle;
4. only the requirement.
Don't move on until I've completed each. Tell me where I stall.

Where you stall is the diagnosis. Stalling at 2 means you can't finish a thought; stalling at 3 means you don't understand the mechanism; stalling at 4 means you can't design, which is what the blank file demands.

Across the subject

Functions and control flow. Remove the loop body, keep the setup and return, Then remove the loop and keep the body, a good test of whether you know what the iteration is for.

Recursion. Give the base case, remove the recursive call. Then the reverse, which is harder and more diagnostic.

Data structures. Give the class skeleton and method signatures; implement the bodies. This is close to how real extension work feels.

Algorithms. Give the invariant as a comment and remove the loop. If you can maintain the invariant you understand the algorithm; if you can only reproduce the code you don't.

SQL. Give the SELECT and the expected output, remove the joins and filters. Working backwards from the result is how people actually write queries.

Data pipelines. Give the input and output schemas, remove the transform, This is the most realistic version and the most useful.

ML. Give the evaluation code and remove the model; or give the model and remove the preprocessing. The second finds leakage habits fast.

Tests. Give the test and remove the implementation, which is test-driven development, reframed as a completion problem and much easier to learn this way.

The variant worth using regularly

Give me working code with one section replaced by a comment describing what it should do. Don't tell me how.

That's the most realistic form, because it's what maintaining real software feels like: a requirement, a surrounding context, and you writing the part in between. And it's the format where the surrounding code teaches you the conventions you should match, which is a skill nothing else trains.

Pitfalls

1. Always removing the end. The easiest gap and the least diagnostic.
2. Not fading. One completion problem is an exercise; the sequence is the method.
3. Reading the removed part first. Obvious, and tempting when stuck.
4. Completing without running. Predict, then run (article 01).
5. Taking the scaffold as the design. The given structure was one choice among several, ask what else would have worked.
6. The tell: you complete every version and can't write the thing from scratch the next day. The scaffold was doing more than you noticed, go back and try version 4 first.

Try this today

Take something you can follow and can't write. Ask for the four-version sequence with the beginning removed rather than the end.

Where you stall tells you exactly which part you've been outsourcing to the example.