06 — Failure Modes (C-Specific)¶

This is not the pre-mortem file — that lives in 99_pre_mortem/. This file is different. This file catalogues the seven ways people specifically fail at learning C, distinct from generic learning failures. Read it once at the start. Read it again at Month 4, when the first symptoms appear. Read it a third time at Month 8, when you’ll be tempted to think you’re past this.

Each failure has: symptoms (what it feels like from inside), warning signs (what an observer would notice), and correction protocol (what to do about it). If two or more show up simultaneously, treat that as an emergency — pause the sprint and address them.

1. The AI Crutch¶

Using Copilot / Cursor / ChatGPT to translate your intent into C, rather than writing it yourself.

Symptoms: you know what you want to happen but not how to express it in C, so you describe it to the AI and paste back the output. It compiles. It works. You move on.
Warning signs: you cannot re-derive the code you “wrote” yesterday. You cannot explain what restrict in your function signature does, but it’s there. Your commit messages have gotten vaguer. You feel a small flinch of shame when someone asks “why did you use this API?”
Correction: the AI policy from 11_tools_setup/08_ai_assist_for_c.md — AI explains, never translates. You may ASK the LLM “why does this segfault” or “what does this K&R paragraph mean.” You may not ASK the LLM “write me a hash table in C.” One “AI-free week” per month, Cursor uninstalled, only man pages and your own brain. If the AI-free week produces nothing, that is your data — your instincts have not formed yet, and you need more time in the small.

2. Never Leaving the Debugger — wait, wrong problem¶

Actually the failure is: never entering the debugger. Reading books but not spending real hours in gdb / lldb / rr. Theory without reflex.

Symptoms: when a segfault happens, your first instinct is to add printf everywhere. You have never single-stepped through your own code. You do not know the syntax for a conditional breakpoint. You have never used watch on a pointer.
Warning signs: your Saturday sessions never touch gdb. Your notebook has zero entries about debugger sessions. You resolve bugs by re-reading the code, not by inspecting the running program.
Correction: enforce a minimum — one gdb session per week, minimum, even if fabricated. Set a breakpoint in a known-good program. Step through it. p, bt, frame, watch, commands. Get comfortable in the tool when nothing is broken, so that when everything is broken at 11 PM, the tool is already familiar. The 2 AM debugger competence from the M13 pitch sentence is built here, in the boring weekly repetitions.

3. The Tutorial Hamster Wheel¶

Always starting a new tutorial, never finishing a project.

Symptoms: you have opened five “Learn C in X Days” tutorials, each of which you got 60% through before moving to the next one. Your GitHub has zero repos with more than 3 commits.
Warning signs: you can quote K&R chapters you “read” but cannot recall the exercises. You buy or bookmark a new book monthly. When someone asks “what have you built?” you describe things you plan to build.
Correction: hard rule — one book at a time, one project at a time. Do not open a second resource until the first is finished OR consciously abandoned with a written note about why. The portfolio rungs in 12_portfolio/ are the anchor — they are what “finished” looks like. If a rung is not shipped, no new tutorial. If a book is not done, no new book.

4. Segfault Dread¶

Every segfault feels like personal failure, and after enough of them, you associate C with anxiety.

Symptoms: dread when you see the word “segmentation fault.” A sinking feeling on Saturday morning when you sit down and see yesterday’s crash. Avoidance — doing anything except opening the debugger.
Warning signs: longer and longer gaps between coding sessions. Rationalizations (“I’ll come back to this after I read another chapter”). Physical fatigue disproportionate to the actual work.
Correction: reframe explicitly. A segfault is a gift. It is the machine telling you that your model of it was wrong — and the machine is willing to tell you WHERE, if you ask (gdb --core=core, valgrind, ASan). Every segfault is a data point about how your intuitions differ from reality. Log the segfault in your lab notebook. Include the fix. After 30 logged segfaults, you will notice they cluster into 5 or 6 kinds, and the dread will convert to pattern recognition. This is the transformation the roadmap is designed to produce.

5. The DSA-Only Trap¶

Solving LeetCode problems in C but never writing a real system.

Symptoms: you’re comfortable with qsort, linked lists, and binary trees. Your GitHub is 200 short problem-solution files. You have never opened a socket, never called mmap, never linked against a library you didn’t write.
Warning signs: you feel “study-ready” but panic when someone says “write a small HTTP server.” You cannot describe what happens when your program starts (execve, ld.so, main). LeetCode difficulty is your only measure of progress.
Correction: the portfolio rungs in 12_portfolio/ are explicitly designed to break this. Every rung is a system, not a problem. DSA is at most 30% of your C time. The other 70% is systems: files, sockets, memory, processes, threads. If you notice a week where LeetCode is 60%+ of your C time, cut it in half next week. LeetCode is a warm-up, not a workout.

6. Skipping Systems¶

Jumping straight to “cool” ML kernels or fancy applications without OS fundamentals. The cargo-cult C engineer.

Symptoms: you can write a SIMD dot-product but you cannot explain what a page fault is. You copy mmap boilerplate but do not understand what the kernel is doing. You optimize for cache but do not know how the TLB works.
Warning signs: when someone asks “why is your program slow,” your explanations bottom out at “it just is.” You cannot read strace or perf output without asking an LLM to interpret it.
Correction: the roadmap ordering is not decorative. 05_systems_programming/ (M5–M6) comes BEFORE 07_applied_c_ml_inference/ (M9–M11) on purpose. If you find yourself skipping ahead because kernels look cooler than syscalls — stop. CS:APP chapters 8–12 are the tax you pay to be allowed to write good ML kernels later. Pay it once, in order, and you’ll never pay it again.

7. The Lone-Wolf Trap¶

Never posting in a community, never getting your code reviewed, letting the ghosts of small mistakes accumulate into large ones.

Symptoms: no one has read your C code except you. You have never had a code review. You are unsure whether your style is idiomatic, whether your error handling is standard, whether your header conventions are sane.
Warning signs: all your habits are self-taught. You use nonstandard formatting because it “feels natural.” You’ve never heard the phrase “strict aliasing” outside a compiler warning.
Correction: post your projects. r/C_Programming, Handmade Network Discord, the Beej mailing list, the comp.lang.c newsgroup (yes, still), Zoho internal channels if any exist. One code-review request per month, minimum, from M3 onwards. Take the critique. Sit with it for a day before replying, so ego cools. Then apply what’s useful and note what’s stylistic disagreement. The mistakes you’d take five years to find alone, you’ll find in five weeks with critique.

The compound danger¶

Each of these on its own is recoverable. Two together compound: an AI-crutch + tutorial-hamster-wheel produces someone who feels like they’re learning while learning nothing. A DSA-only + lone-wolf trap produces someone who is technically competent and totally invisible to the industry. A segfault-dread + never-entering-the-debugger produces the burnout that ends the whole project.

When two co-occur, that IS the emergency. Pause the sprint. Reread this file. Pick a correction protocol for each. Apply for two weeks before scheduling any new deliverables. This is not a delay — this is the discipline the sprint model was designed to enable.

Return to README.md · Next: 07_motivation_sustainment.md