The tutorial ended, the tab closed, and your repo still has no new file. You probably clicked away mid-demo because a notification popped up, or you thought you’d “come back later” to write the code, but now the exact syntax you just saw is already slipping. Most tutorial watching ends with no tangible output, because passive consumption doesn’t force you to test if you actually understand the content well enough to use it. This recap card system turns 45 minutes of watching into 10 minutes of active work that leaves usable code in your project and clear gaps documented for later.
Three facts you can type without the video
These are not vague takeaways, they are specific, verifiable pieces of information you can write down without pulling the video back up, no guessing allowed. For example, if your most recent tutorial covered adding basic rate limiting to a Node.js Express API, your three facts might be:
- The `express-rate-limit` middleware requires two mandatory configuration properties for default functionality: `windowMs`, which defines the length of the rate limit window in milliseconds, and `max`, which defines the maximum number of allowed requests per unique user in that window.
- If you do not explicitly define a `keyGenerator` function in your rate limit config, the package automatically uses the requesting IP address as the unique identifier to track request counts for each user.
- You can add a custom `message` property to the config that returns a structured JSON response to users who exceed the rate limit, instead of the default plain text “Too many requests, please try again later.”
These facts are specific enough that you can write code directly from them, no context needed. If you can’t come up with three specific facts, that means you didn’t retain enough from the tutorial to use the content, and you need to adjust how you watch tutorials moving forward (e.g. pausing to write facts as you go, instead of binging the whole video first).
One file in your repo that used those facts
Every tutorial you finish should produce at least one small, working file in your repo, no exceptions. Even if you don’t integrate it into your full project yet, you can save it as a standalone snippet in a `snippets/` directory so you have it for later. Below is a concrete mapping of the three facts above to lines in a real, working `src/middleware/rateLimit.js` file:
| Fact Number | Line Number(s) in File | Exact Code Snippet |
|---|---|---|
| 1 | 4-5 | `windowMs: 15 * 60 * 1000, // 15 minute window` `max: 100, // 100 requests per window per IP` |
| 2 | N/A | No custom code required; uses default IP-based key generator |
| 3 | 6 | `message: { error: “Rate limit exceeded”, retryAfter: 900 }` |
The full file is only 12 lines long, including import and export statements, and takes less than 2 minutes to write from the three facts you already noted. Committing this file to your repo immediately after closing the tutorial tab ensures you have a tangible output to show for your time, instead of just a vague memory of watching someone else write code. If you can’t write this file without re-watching the tutorial, that’s a sign you didn’t retain the content well enough, but the replay rule below prevents you from falling into the trap of re-watching the entire video passively.
Question you still cannot answer honestly
Every tutorial will leave gaps in your knowledge, and pretending you don’t have those gaps leads to broken code later when you try to use the content for a real use case. The question should be specific, answerable, and tied directly to the content you just learned. For the rate limit tutorial example, your honest unanswered question might be: “How do I persist rate limit data across multiple server instances so a user isn’t counted separately when their request hits a different server pod in a scaled deployment?”
You don’t need to look up the answer right now, and you don’t need to learn it until you’re actually deploying your API to multiple instances. Writing the question down serves two purposes: it prevents you from overestimating your knowledge of the topic, and it gives you a clear learning goal for when you need that functionality later. If you can’t think of an unanswered question, that’s a red flag—you either didn’t pay enough attention to the tutorial’s limitations, or you’re not being honest with yourself about what you don’t know.
Replay rule only if the file is missing
Re-watching entire tutorials is almost always a waste of time, and you should only ever re-open a tutorial tab if you meet all of the following strict criteria:
- You have already written the full skeleton of the file you’re trying to create, including all import/export statements, and left line comments where you think each of your three noted facts should be implemented.
- Example measurement: You have spent at least 7 consecutive minutes trying to write the code for the file using only your three noted facts, no external searches, no guessing.
- You are only re-watching the specific 1-2 minute segment of the tutorial that covers the exact syntax you’re stuck on, not the full video.
- You will close the tutorial tab immediately after you confirm the correct syntax, and you will not watch any additional sections of the video until you have saved and committed the working file to your repo.
If you haven’t written the file skeleton first, you are not allowed to re-open the tutorial tab. This rule prevents you from falling back into passive consumption mode, and forces you to do the work of recalling and applying the content before you look for help. If you can’t write the skeleton of the file, that means you didn’t retain enough high-level context from the tutorial, and you’re better off picking a simpler tutorial that covers content you can actually apply immediately.
Card you date so hopping is visible later
Save every recap as a dated markdown file in a `.tutorial-recaps/` directory in your project repo, so you can track your learning progress and spot tutorial hopping patterns. The card should include exactly the following fields, no extra fluff:
- Date you completed the tutorial: [YYYY-MM-DD]
- Three verified facts from the tutorial: [paste the three facts you wrote earlier]
- Path of the file added to your repo: [e.g. src/middleware/rateLimit.js, or snippets/rate-limit-demo.js]
- 7-character Git commit hash for the file: [copy from your Git log]
- Honest unanswered question: [paste your question]
- Number of times you replayed tutorial segments to write the file: [0, 1, etc.]
Over time, this directory will become a log of what you’ve learned and what you’ve built. If you see 10+ recap cards in a two-week period with no attached file paths or commit hashes, that’s a clear sign you’re in tutorial hopping mode, and you need to pause learning new content to build a small end-to-end feature with the skills you already have. You can also add an update to the card later when you answer your unanswered question, so you can track how your knowledge grows over time.
Right now, open your most recent project repo, create the `.tutorial-recaps` directory if it doesn’t exist, write the three specific facts you retained from your last closed tutorial tab, and commit both the recap card and the 10-20 line file that uses those facts before you open any new tutorial content.