Rung 1 (M1) — The Toolchain Trio

This is the fastest possible public signal that you have re-tooled after two years away from C++. Three tiny command-line utilities — wc, jsonpp, logtail — in one repo, all built with CMake, all with tests, all with a real README. Nothing clever. Nothing production-grade. Just a clean, boring, modern C++ repo that says: “I can set up a project.”

You will be tempted to skip this rung because it feels beneath you. Do not skip it. This rung exists so that when you push Rung 2 in M3, your GitHub already has commits, a real repo, and a shape. Employers who click your GitHub link see “actively writing C++ in 2026” — not an empty profile.

What It Is

A single public GitHub repo called cpp-refresh-2026 with three subdirectories, each a self-contained CMake target:

  • wc/ — Word-count clone. Reads stdin or a file. Reports lines, words, bytes. Flags: -l, -w, -c. Handles UTF-8 without breaking (bytes vs. code points documented).

  • jsonpp/ — JSON pretty-printer. Reads stdin, emits pretty-printed JSON to stdout. Uses nlohmann/json as a dependency (fetched via CMake FetchContent). Handles the pretty-print indent flag --indent N.

  • logtail/ — A tiny tail -f-like filter with regex. Reads a file, follows appended lines, prints only lines matching a regex pattern. Flag: --pattern <regex>, --from-start.

Each subdirectory has its own main.cpp, its own tests, and its own binary. One top-level CMakeLists.txt orchestrates all three.

Why It Matters (Employer Signal)

One line: “This person can start a C++ project without asking for help.”

That sounds trivial. It is not. A meaningful fraction of C++ candidates cannot produce a public repo with CMake + tests + GitHub Actions CI + a working README on their own. If a hiring manager clicks your GitHub and sees this repo, they immediately conclude: setup friction is not going to slow this person down. That is a real signal. It is not the signal that gets you hired, but it is the signal that gets you past the first click.

Repo Organization Decision: One Repo, Three Subdirs

You have two options. Take the first one.

  • Option A (recommended): one repo, three subdirs. Faster to set up. Single CI pipeline. Single README that shows all three. Easier to iterate. This is your Rung 1.

  • Option B: three separate repos. More “professional”-looking on GitHub. Higher setup overhead. Splits your commit graph across three places. Do not do this at Rung 1. Save the one-repo-per-artifact pattern for Rungs 2–8.

The reason to bundle: Rung 1 is about velocity of shipping a first thing. Three repos triples the setup cost for zero additional signal.

Acceptance Checklist

Do not mark this rung done until every box is checked.

  • Repo is public on your GitHub, named cpp-refresh-2026.

  • Root CMakeLists.txt builds all three binaries with cmake -S . -B build && cmake --build build.

  • Requires C++20 (set(CMAKE_CXX_STANDARD 20)). Compiles clean with -Wall -Wextra -Wpedantic -Werror.

  • Each binary has at least 5 unit tests using Catch2 or GoogleTest (fetched via FetchContent).

  • .github/workflows/ci.yml runs build + tests on Ubuntu latest with GCC and Clang.

  • Top-level README.md has the 5 sections listed below.

  • .clang-format file committed (Google or LLVM style is fine — pick one).

  • .gitignore covers build/, .DS_Store, IDE dirs.

  • Each binary handles --help and prints usage.

  • Repo shared on r/cpp_questions with a “just returning after 2 years” framing.

README Structure (5 Sections — Copy This)

Your top-level README must have exactly these five sections in this order. This is the minimum quality bar for every rung on this ladder from now on.

  1. What this is — 2-3 sentences. What each of the three binaries does.

  2. How to build — The exact cmake commands. Assume the reader has never built C++ before.

  3. How to run — One example command per binary, with expected output pasted.

  4. Tests — How to run the test suite (ctest --test-dir build). CI badge at the top.

  5. Notes — A short “why I built this” — explicitly frame as “returning to C++ after 2 years in ML”. This framing is the signal, not the code.

Where to Publish and Share

  • GitHub: public repo, MIT license.

  • Reddit: post to r/cpp_questions with title “Returning to C++ after 2 years — first weekend’s toolchain trio, feedback welcome.” Do not post to r/cpp for Rung 1 — the bar there is higher and this doesn’t clear it. r/cpp_questions is the right venue: humbler, more welcoming, and reviewers there are generous with pointers on CMake and modern idioms.

  • Do not share on LinkedIn or HN. Rung 1 is not that kind of signal.

The feedback you get on r/cpp_questions is the actual point of this rung — it will surface CMake anti-patterns and modern-idiom misses that you will otherwise carry forward through the whole ladder.

Common Ways This Rung Fails

  • You over-engineer wc to handle every edge case. Stop. Handle ASCII correctly, document that multi-byte UTF-8 counts bytes not code points, and move on. Perfectionism at Rung 1 costs you Rung 2.

  • You skip CI because “it’s just a small repo.” Then Rung 2 also has no CI, then Rung 5 also has no CI, and by Rung 8 you have never set up a matrix build. Do it now while stakes are low.

  • You bury the framing in the README. Reviewers on r/cpp_questions calibrate their feedback to your context — lead the Notes section with “returning after 2 years” so you get level-appropriate advice, not RTFM.

  • You wait to publish until “everything is clean.” Publish rough. Polish after. See the publication cadence rule in README.md.

What Most People Get Wrong

They treat Rung 1 as a throwaway warmup and skip the tests, CI, and clang-format. Then when they get to Rung 5 (concurrency) and want to run ThreadSanitizer under CI, they realize they have never set up CI at all, and now they are debugging YAML while trying to reason about lock-free code. Do the boring infra now. The reason Rung 1 is boring is because it is teaching you the infrastructure you will lean on for the next twelve months.

Extension Challenges (Only If M1 Has Slack)

These are for the case where you finish the base spec with a week to spare. Do not stretch at the cost of shipping the base.

  • Add a benchmark target using nanobench that times wc against system /usr/bin/wc on a large file.

  • Add a --jobs N flag to logtail that parallelizes the regex match across N threads (bad idea for real logs, but a nice concurrency warmup).

  • Add a GitHub Actions matrix that also runs on macOS with AppleClang.