Subjects · Computer Science & Data
Computer Science & Data: the methods that matter most here
Know which methods exploit this subject's unique advantage (that verification is free and instant) and which popular study habits waste it.
What you'll be able to do: Know which methods exploit this subject's unique advantage (that verification is free and instant) and which popular study habits waste it.
What makes computing hard, specifically
Verification is free, which changes everything. You can run it. No other subject gives instant, unambiguous, unlimited feedback at zero cost. Methods that exploit this are disproportionately effective here, and this is the single most important fact about studying the subject.
But "it runs" is not "it's right", and students stop at runs. Code that works on the case you tried, code that works by accident, code that works and is unmaintainable, all feel like success.
Reading code and writing code are different skills, and tutorials train only the first. The gap between following a tutorial and facing a blank file is the defining experience of learning to program, and almost nothing in a course addresses it.
Debugging is a discipline of narrowing and is taught as "look at it again harder". Most students have no procedure at all.
Reasoning about state defeats people. What is the value of this variable at this moment, in this scope, on this iteration, this is the actual difficulty behind most beginner confusion, and it's invisible in the code.
The mathematics arrives late and hard, particularly in ML and algorithms, and gets diagnosed as difficulty with computing.
The ten
| # | Method | Why it earns its place here |
|---|---|---|
| 1 | B15 Predict-then-verify | Free and instant. Predict the output, then run. The highest value-per-second method in any subject |
| 2 | K1 Verification drill | You can check everything, which makes this the one subject where AI output is trivially testable |
| 3 | D8 Code review simulation | Professional practice is about judgement, not correctness, and courses assess only correctness |
| 4 | A2 Contingent hinting | Debugging requires being stuck; a pasted fix removes the whole skill |
| 5 | M17 Flowchart my process | Most students' debugging procedure is "look harder", which a flowchart exposes brutally |
| 6 | G11 Output pushing | Blank-file practice. Reading tutorials is input and produces no capability |
| 7 | A9 Completion problems | The bridge from reading solutions to writing them, with the first step removed |
| 8 | B11 Interleaved practice | Choosing the data structure is the skill; chapters remove the choice |
| 9 | E1 Error cataloguing | Bugs cluster hard by concept, scope, mutation, off-by-one, async ordering |
| 10 | A1 Prerequisite diagnosis | The floor is usually "what does a function call actually do" |
The methods that work badly here, and they're what everyone does
Watching tutorials and reading documentation as primary study.
This is input, and programming is an output skill. The tutorial is comprehensible while you watch, every step makes sense, and you finish feeling you've learned something. Then you open a blank file and can't start.
The technical name for the experience is tutorial hell, and the mechanism is straightforward: following someone else's decisions requires none of the work of making your own. Comprehension of a solution and production of one are close to unrelated, and reading more solutions does not close the gap.
Use tutorials to meet a new thing. Then close them and build something badly.
"Explain this code to me" as a default.
Explanation is comfortable and it is the wrong first move. If you can run it, run it, with predictions (method 1). The explanation tells you what the author thought the code does; running it tells you what it does. In a subject where those can differ, prefer the second.
Ask for an explanation after you've predicted and run, aimed at the gap between what you expected and what happened.
The composed workflow
- Before running anything: predict the output and say why (B15).
- When stuck: attempt, then hint ladder, never a pasted fix (A2).
- After it works: review as a senior engineer would, marked must-fix / should-fix / preference (D8).
- Weekly: log the bugs by concept, not by symptom (E1).
- Regularly: build something from a blank file with no tutorial open (G11).
That addresses state reasoning, debugging, judgement and production, the four things that separate someone who has completed courses from someone who can program.
The ten articles in this subject
01 Predict-then-verify · 02 Verification drill · 03 Code review simulation · 04 Contingent hinting for debugging · 05 Flowchart my debugging process · 06 Output pushing and the blank file · 07 Completion problems · 08 Interleaved practice · 09 Error cataloguing for bugs · 10 Prerequisite diagnosis