Launch & Retrospective

A launch is a claim: this commit is the thing, and here is the evidence. The evidence has to come from that commit. A README showing last month's benchmark numbers, or a demo running a build from before the last refactor, is exactly the kind of inconsistency a careful reader notices, and it undermines everything else.

The checklist, as dependencies:

• CI green on the release commit: tests, clippy, docs, the week tests (cargo xtask test).
• Benchmark report regenerated at that commit on the reference machine (week 51's generator), and the README's numbers come from it.
• Demo deployed from that commit's image (week 47), and its build id visible somewhere a reader can check.
• Licence chosen. MIT/Apache-2.0 dual licensing is the Rust ecosystem's convention.
• Changelog and version tag: a v1.0.0 (or v0.1.0) tag, with a changelog entry that says what's in it.
• Repository hygiene: no secrets in history, issue templates, a short CONTRIBUTING file, and the stranger test (week 51) passed.
• Announcement last, linking to all of the above.

The drill is the launch gate as code: order the checklist by its dependencies, then refuse to launch with unfinished items or evidence produced at an older commit.

#[derive(Debug, Clone)]
pub struct Item {
    pub id: &'static str,
    pub deps: Vec<&'static str>,        // items that must be done first
    pub done: bool,
    pub evidence: Option<&'static str>, // commit the evidence was produced at, if the item has evidence
}

#[derive(Debug, Clone, PartialEq, Eq)]
pub enum Problem {
    UnknownDep { item: &'static str, dep: &'static str },
    Cycle,
    NotDone(&'static str),
    StaleEvidence(&'static str),
}

/// Every item after all of its deps. Whenever several items are ready at
/// once, take the smallest id (string order) first.
/// Errors: the first UnknownDep found scanning items in list order and each
/// item's deps in order; otherwise Cycle if not every item can be ordered.
pub fn launch_order(items: &[Item]) -> Result<Vec<&'static str>, Problem> {
    let _ = items;
    todo!()
}

/// The launch gate. If launch_order fails, return just that error.
/// Otherwise, walking items in launch order: NotDone(id) for an item that
/// isn't done; StaleEvidence(id) for a done item whose evidence is
/// Some(commit) with commit != head. An empty Vec means: ship it.
pub fn gate(items: &[Item], head: &str) -> Vec<Problem> {
    let _ = (items, head);
    todo!()
}

Write one launch post, on your own site, that the rest of your sharing links to. Its structure:

1. What it is, in two sentences, and a picture: the terminal watching the live demo.
2. Why it's interesting: the one or two hard problems (determinism with microsecond latency, failover without double fills) and how you solved them.
3. Numbers with method: the headline table from the generated report, the machine, and what limits each number.
4. What you learned: the single most surprising thing (coordinated omission? false sharing? how hard tail loss is to detect?).
5. Links: repo, demo, report, architecture overview.

Expect the first critical comment to target your weakest number or your strongest claim. Thank them, answer with data, and fix what they found in public. That exchange often impresses hiring readers more than the project itself.

A retrospective that starts with feelings ends with the loudest memory. Start with data: your weekly planned and actual hours, which benchmark targets you hit in each phase, the drills and recall checks you marked for review, and the week reports from the lab. Three questions to answer from the numbers before you write a word of interpretation:

• How biased were your estimates? The median ratio of actual to planned hours tells you your personal planning-fallacy factor. Most people land well above 100%. The worst weeks tell you which kind of work you underestimate (debugging concurrency? performance work with no clear stopping point?).
• Where did the targets slip? Benchmark hit rate per phase shows whether the foundation, production, performance or mastery phase was hardest for you, which is usually not the one you'd guess.
• When did you have momentum? The longest run of consecutive on-plan weeks, and what was true during it.

#[derive(Debug, Clone, Copy)]
pub struct WeekLog {
    pub week: u32, // 1..=52
    pub planned_h: u32,
    pub actual_h: u32,
    pub benches_met: u32,
    pub benches_total: u32,
}

#[derive(Debug, Clone, PartialEq, Eq)]
pub struct Retro {
    /// Σ (actual_h − planned_h).
    pub overrun_h: i64,
    /// Median of actual_h × 100 / planned_h (integer division) over weeks
    /// with planned_h > 0; for an even count take the LOWER middle value.
    /// 0 if there are no such weeks.
    pub median_ratio_pct: u32,
    /// Up to 3 weeks with the highest ratio (same definition), highest
    /// first; ties → lower week number first.
    pub worst_weeks: Vec<u32>,
    /// Per phase (weeks 1–12, 13–24, 25–40, 41–52):
    /// Σ benches_met × 100 / Σ benches_total (integer division), None if Σ total = 0.
    pub phase_hit_pct: [Option<u32>; 4],
    /// Longest run of consecutive week NUMBERS (a missing week breaks the
    /// run) where actual_h × 100 <= planned_h × 110. Logs may be unsorted.
    pub longest_on_plan_streak: u32,
}

pub fn retro(logs: &[WeekLog]) -> Retro {
    let _ = logs;
    todo!()
}

Now interpret, using the 4Ls: what you liked, what you learned, what you lacked (skills, tools, time, feedback) and what you longed for. Keep it blameless, even though the only person involved is you. The point is to find the conditions that produced the outcomes, not to grade yourself. "I skipped the profiler in week 26 because I was behind schedule" is useful. "I was lazy" isn't.

The most valuable single exercise is to redo an early design with what you know now. Take week 1's channel, week 6's order book or week 13's gateway and write how you'd design it today. The differences (where you'd put the thread boundaries, what you'd measure first, which invariant you'd encode in types) are the clearest record of what the year changed.

You used dozens of crates this year, and you now know some of their internals better than most of their users. Contributions are the strongest public signal of judgement and collaboration, and they make you better at reading other people's code. Start small and specific:

• A bug or papercut you hit, with a minimal reproduction. Your replay and chaos tooling makes reproductions your strength.
• Docs: an example of the exact use you needed, or a missing statement of cost or ordering guarantees.
• Benchmarks or tests that cover a case the project lacks.
• Performance work, carefully: open an issue with measurements first, agree on the approach, then send a focused PR with before/after numbers and methodology. Maintainers merge evidence, not enthusiasm.

Read the project's CONTRIBUTING guide, look at recently merged PRs to calibrate size and style, and keep your first PR small enough to review in ten minutes.

Before the day ends, list five crates you depended on this year, write one concrete contribution for each (a bug, a doc gap, a benchmark, a test) with the evidence you already have, and open the issue for the best one.

You now have breadth across a whole trading system. The next year should buy depth in one area, chosen by what you liked and what the roles you want reward:

• Hardware and the network edge: kernel bypass in production (ef_vi, DPDK), hardware timestamping, PTP, and FPGA feed handlers and order entry, where the lowest-latency firms compete.
• Correctness: formal specification of your replication and failover protocol in TLA+ (Leslie Lamport's Specifying Systems is the reference), model checking, and deterministic simulation at scale.
• Distributed systems: consensus (Raft, Paxos) for the control plane (configuration, reference data), multi-site disaster recovery, and the latency cost of each.
• Quantitative work: microstructure research, execution algorithms, and simulation fidelity, turning weeks 41–45 into a research practice.
• Performance engineering as a discipline: compilers and codegen, profiling tooling, and contributing performance work to the Rust ecosystem itself.

Write the plan the way this curriculum was written: a sequence of weeks, each with a reading, a build task and a measurable target, plus a quarterly review using this week's retro drill on the new logs.