Computer Science & Data: Output pushing and the blank file

What you'll be able to do: Start from nothing, which is the thing tutorials never train and the thing every real task requires.

Tutorial hell, named precisely

You follow a tutorial. Every step makes sense. The code works. You understand what each line does and why. You finish feeling you've learned something.

Then you open an empty file and cannot begin.

This experience is common enough to have a name, and the mechanism is simple: following someone else's decisions requires none of the work of making your own. The tutorial made every hard choice, what to build, how to structure it, what to name things, which library, what to do first, and handed you the consequences to type.

Comprehension of a solution and production of one are close to unrelated skills, More tutorials do not close the gap; they widen the feeling of competence while leaving the gap where it was.

Programming is an output skill. Almost all study of it is input.

What a blank file demands that a tutorial doesn't

• Deciding what to build at all, and scoping it to something finishable.
• Choosing the first line. This is genuinely hard and never practised.
• Naming things before you know what they'll be.
• Deciding when something is good enough to move on from.
• Recovering when the approach turns out to be wrong halfway.
• Sitting with not knowing, which is the part tutorials most thoroughly remove.

None of those appear in any tutorial, because a tutorial is a record of someone who has already done all of them.

How to practise it

1. Set a small, finishable target. Not "build a web app". Something that reads a file and prints a summary. Finishing is the point; ambition is the enemy here.
2. Close everything. No tutorial, no previous project open, no documentation until you're stuck on a specific fact.
3. Write the first line badly. It doesn't matter. Momentum matters.
4. Get it working ugly before making it good. Two phases, in that order.
5. Note what you avoided. The most valuable signal, see below.
6. Only then ask for review (article 03).

I'm going to build [small thing] from an empty file with nothing open. Don't give me code and don't suggest an approach. If I get stuck, ask me what I've tried. At the end, tell me what I avoided doing and what I routed around.

The avoidance signal

This is the highest-value thing in the method and it's invisible without asking.

You avoid what you can't do. You write a loop because you're not sure about the comprehension. You use a list because you're unsure when a dictionary is right, You copy a pattern you half-understand rather than the one that fits. You skip error handling entirely.

None of that leaves a trace. The code works, and the gaps are silent.

Looking at what I wrote: what did I route around? Which language features or patterns did I avoid, and what did I use instead?

That list is your actual study plan, and it's completely different from the list you'd have written yourself.

Across the subject

Programming fundamentals. Small scripts, from blank, weekly. This is the core of the method.

Data analysis. Load an unfamiliar dataset and answer one question you made up. No tutorial has your question.

SQL. Write queries against a schema you haven't seen, from a written requirement. Reading queries teaches almost nothing.

Algorithms. Implement from the description, not from a reference implementation. Then compare, the differences are instructive.

ML. Build a baseline before reading anything about the problem. A baseline you produced tells you what the task is actually like.

Systems and networking. Configure something from the documentation rather than a copy-pasted config. This is where copy-paste habits cost most.

The honest difficulty

Blank-file practice is unpleasant in a way tutorials aren't. You will be slow, you will write bad code, and you will not feel the steady competence a tutorial provides.

That discomfort is the same one as interleaving and retrieval practice: the feeling of a session and its value are anticorrelated. Expect it, and judge the method on what you can do in a month rather than on how the hour felt.

Pitfalls

1. Having a tutorial open "just in case". It will get opened.
2. Too ambitious a target. Unfinished projects teach less than finished small ones.
3. Polishing before it works. Ugly-then-good, in that order.
4. Not asking what you avoided. The gaps are silent by construction.
5. Asking for code when stuck. Use the hint ladder (article 04).
6. The tell: you've completed many tutorials and have never built anything nobody told you to build.

Try this today

Pick something you could finish in an hour. Close every tab.

Write the first line badly. When it works, ask only: what did I route around?

That answer is what you're actually missing, and no tutorial was going to tell you.