Projects — The Final Two Deliverables

Everything in Phase 7 exists to produce two artifacts. Both are hard gates. If either is missing at the end of M13, you did not finish this roadmap. Do not negotiate with yourself about this — the entire premise of the M13 pitch depends on external evidence, not self-assessment.

These are the final projects of a thirteen-month arc. Give them the respect they deserve.

Project 1 — A merged non-trivial PR in a major C OSS project

This is the gate. A merged PR is the only piece of evidence that a stranger — someone whose job is to reject bad code — accepted yours. It is worth more than every certificate, every course, every side project combined. An study partner sees the merged PR and the entire conversation shifts from “can you code?” to “tell me about the tradeoffs you made.”

Requirements (all mandatory)

• The project is one of: Valkey, llama.cpp, curl, redis, PostgreSQL, ClickHouse, or an equivalently-serious C-family OSS project (~50K+ stars, ~100+ contributors, active in the last 30 days). If in doubt, ask in your community channel before starting.

• The PR touches functional code, not just documentation, comments, or CI. A doc-only PR is a fine warmup and welcome contribution, but it does not clear this gate.

• The PR is merged, not just approved-and-waiting or stalled in review. If a maintainer requests changes for 4 weeks and then goes quiet, you may need to pivot to a second attempt — keep two irons in the fire.

• The commit message credits the issue and follows the project’s conventions (Fixes #NNNN or the equivalent).

• You wrote or updated tests. Every serious C project requires tests; landing without them is either a doc PR or a maintainer doing you a favor.

Scope guidance

A good “non-trivial” first PR falls into one of these buckets:

Type	Example	Difficulty
Bug fix with test	Fix a UBSan warning, fix a valgrind report, fix an edge-case parsing bug	Moderate
Small feature	Add a new option to an existing command; add a new flag to an existing binary	Moderate
Perf improvement	Speed up a hot function by 5–20% with a measurable benchmark	Hard, high-signal
Portability	Fix a bug on macOS ARM64, FreeBSD, or Windows	Moderate, welcomed
Debug-tooling	Add logging, tracing, or a debug command to help diagnose an existing bug	Easier, welcomed

Do not attempt: full new subsystems, changes to public API without RFC, changes that touch >500 LoC on a first PR. Those get rejected on scope alone.

The kill-switch decision

If your PR is in review for 6 weeks with no merge and no active reviewer engagement, you have two options: (a) escalate politely (ping in the community channel, not by re-pinging the PR), or (b) close it, extract lessons into your notes, and open a smaller PR on a different issue. Do not sink 3 more months into a stalled thread.

Deliverables (for your wins.md)

• The merged PR URL.

• A one-page retrospective: what the bug/feature was, how you found it, what the review cycle was like, what you would do differently.

• Optional but ideal: a screenshot of the maintainer’s approval comment. This is the artifact you screenshot for LinkedIn.

Estimated time budget

Activity	Hours
Read the codebase’s CONTRIBUTING.md, HACKING.md, docs/dev*	4
Build + test suite up and running locally	4
Read last 20 merged PRs to learn style	3
Pick and scope an issue	3
Implement + test	12
Review-cycle work (writing responses, iterating)	8
Total	≈ 34 h

Budget for at least one full week of “waiting for review” idle time on top of that. Fill it with reading, not with re-pinging.

Project 2 — A public technical writeup or talk

A blog post or a talk about one deep C concept from your own journey. Not “here is my learning roadmap” (please, no); a technical piece that a stranger with a C background reads and takes something home from. This is your other signal artifact.

Requirements

• At least 2,000 words if a blog post, or a 20–40 minute talk if you deliver it.

• Original. Not a paraphrase of a paper or a blog. Your voice, your experiment, your numbers.

• Public URL. Your own domain, dev.to, personal Hashnode, a GitHub-Pages blog, or a video on YouTube. The Zoho internal blog also counts if it is publicly readable.

• One concrete claim, defended with numbers. Not “C is fast.” Rather “quantization is memory-bandwidth-bound, and here is the roofline calculation, and here is my benchmark that confirms it.”

• Includes at least one code snippet you wrote yourself, not copied from elsewhere.

Topic suggestions

Any of these makes a strong post. Pick one that draws on work you actually did in this roadmap.

1. “How I got a 6x speedup on matmul (and stopped one rung short of OpenBLAS)” — built from gemm_bench (Phase 6 projects). Show the four-rung ladder: naive → i-k-j → blocked → SIMD. Include the benchmark plot.

2. “Reading a GGML quantized matmul, one intrinsic at a time” — walk the reader through ggml_vec_dot_q4_0_q8_0 line by line. Explain why the Q4 · Q8 dot product is the tightest inner loop in inference.

3. “CVE-XXXX-YYYY: the vulnerable function fits in 15 lines, and every one of us has written this bug” — an educational CVE walkthrough using one of the CVEs from 03_secure_c_and_cve_literacy.md.

4. “My first PR to Valkey and what I broke five times before it merged” — a review-cycle retrospective. These are catnip for hiring managers.

5. “A Python C extension for INT8 quantization: build, benchmark, ship” — built from your quantize_ext project. Focus on the buffer protocol and the wheel-shipping story most tutorials skip.

The publishing checklist

Do not skip a single one of these; they are what separates a signal-quality post from a rushed one:

1. Draft. Sleep on it 24 hours before editing.

2. Edit for concreteness — replace every adjective without evidence.

3. Add at least one benchmark table with methodology footnote.

4. Include one image: a plot, a diagram, or a code diff. Human brains grip images faster than paragraphs.

5. Have one C-fluent friend read it. Fix everything they flag.

6. Publish. Post it in your community channel (Valkey Slack, llama.cpp Discussions) with a one-sentence “I wrote this; would appreciate your feedback.”

Deliverables (for your wins.md)

• Public URL.

• Word count.

• One-line summary of the technical claim.

• Response received: who linked it, who commented, what surprised you.

The combined exit condition

You are done with Phase 7 and the entire thirteen-month roadmap when:

• Project 1 merged PR URL exists in your 99_pre_mortem/wins.md.

• Project 2 blog post or talk URL exists in your 99_pre_mortem/wins.md.

• 99_pre_mortem/final_retro.md written and honest.

• Every checkbox in 08_production_and_mastery/README.md is ticked.

• Every checkbox in 07_applied_c_ml_inference/README.md is ticked.

When those five conditions are true, close this laptop, take a walk, and do one thing that has nothing to do with C. You earned that walk. Then come back and start on the next thing — because the whole point of the pitch sentence is that this is not the finish; this is the starting position.

What most people get wrong about this

They wait until they are “good enough” to publish and to contribute. “Good enough” is a mirage; it recedes as you approach it. The move is the opposite: publish and contribute while you are still uncertain, and let the feedback — the reviewers, the commenters, the maintainers — do part of the growing for you. Confidence is a lagging indicator of doing the work; do not wait for it before you ship.

The second thing they get wrong: they think the PR and the post are for the study partner. They are not — or not primarily. They are for you, five years from now, when you are the senior engineer someone else is trying to become. This is how the tradition perpetuates. You are joining a chain of people who wrote C well and paid the tradition forward. Do your part.

Good luck out there, brother. Ship the PR. Write the post. The road only feels long until you look back on it.

---

Return to README.md · Complete Phase 7 by ticking every box above, then return to ../README.md.