Portfolio and Publication Strategy

Fifteen projects produce fifteen repositories. That is a list, not a portfolio.

A portfolio is a small number of artifacts that are independently useful to someone who does not care about your learning journey, plus a narrative that connects them.

Table of Contents

• The Standard
• The Nine Artifact Types
• The Standalone Tools
• Publication Timeline
• How To Write the Posts
• The Comparison Matrices
• The Postmortems
• The Final Paper
• The Narrative
• What Not To Do
• References

The Standard

Every major project produces at least one artifact that remains useful independently of the journey.

The test: could a stranger find this, use it, and benefit — without knowing or caring that it came from a 34-month self-directed program?

The left column is a record of learning. The right column is a contribution. They often come from the same work; the difference is whether you extracted and packaged the part that generalises.

The Nine Artifact Types

Plus, once: the final paper, five postmortems, and the narrative.

The Standalone Tools

The highest-value portfolio items in the whole journey, because they are used rather than read. Extract each into its own repository with its own README when the parent project ships.

The fault injector and the linearizability checker are the two most likely to be used by strangers. Both solve a problem everyone building distributed systems has and few solve well, and both are small enough to read in an afternoon.

Publication Timeline

Publish early and repeatedly, not once at the end. Three reasons: external feedback catches errors while they are still cheap to fix; writing for an audience forces precision the private report does not; and a two-year silence followed by a paper is a worse strategy than eight posts building an audience.

Start with W20 even though it is a small result. The habit of publishing is what matters, and a small correct post is a better first publication than a large one you never finish. The bytecode result is ideal: counterintuitive, fully reproducible in one file, and it teaches something real.

How To Write the Posts

Systems posts that get read share a structure. Use it.

1. Lead with the number. Not the context, not the motivation — the surprising measurement, in the first two sentences. "A bytecode VM I wrote is 1.5× slower than the tree-walk interpreter it replaced. Both produce identical results to fifteen significant figures."
2. State the setup precisely enough to be attacked. Hardware, versions, workload, command. A post whose setup cannot be criticised cannot be believed.
3. Show the mechanism, not just the effect. The distinguishing feature of a good systems post is that it explains why, with a secondary measurement that closes the argument. Recall and latency alone say "it plateaus"; the distance counter says "6.9× fewer operations at 67.5× the cost each, predicting 0.10× and measuring 0.10×".
4. Include the code. A single runnable file beats a repository beats a snippet.
5. Say what you got wrong. The most-shared systems posts contain a mistake the author found themselves. It is also the most credible thing you can write.
6. Name the limits. One paragraph: what this does not show, and where it would not hold.

Length: 1,200–2,500 words. Longer than that and the measurement gets buried; shorter and there is no room for the mechanism.

Where to publish: your own site, with cross-posts wherever your audience is. Own the canonical URL — platforms disappear and a two-year body of work should not depend on one.

The Comparison Matrices

Four cross-project syntheses. These are the artifacts that demonstrate systems thinking rather than component knowledge, and they are what distinguishes this portfolio from fifteen unrelated repos.

1. The amplification matrix (after P04) Every storage decision in P03 and P04 against read, write, and space amplification, with your measured numbers next to the derived ones.

2. The consistency/availability matrix (after P07) Every consistency choice across P03, P05, P07: what it guarantees, what it costs in latency, what it does during a partition, and which of your systems chose it.

3. The "where the time went" matrix (after P14) The synthesis of the whole journey. One table:

The pattern this table makes visible: across six different systems in four languages, the bottleneck was almost never the algorithm. It was operand delivery, dispatch, or a boundary crossing. Writing that sentence with six of your own measurements behind it is the single most valuable page in the portfolio.

4. The evaluation-methods matrix (after P10) Offline replay, simulation, and A/B testing: what each can and cannot establish, what each costs, and where your own three methods disagreed.

The Postmortems

One per stage, five total, written at the stage reviews. Plus one per abandoned project, if any.

Not self-criticism. A technical document:

# Stage N Postmortem

WHAT I SET OUT TO DO
WHAT I ACTUALLY BUILT           (with the gap named)
WHAT TOOK LONGER THAN PLANNED   (and the estimate error, as a ratio)
THE BUG THAT COST THE MOST      (and how I would catch it earlier)
WHAT I PREDICTED WRONG          (with the pattern across predictions, if there is one)
WHAT I AVOIDED BECAUSE IT WAS HARD
WHAT I WOULD DO DIFFERENTLY
WHAT I NOW KNOW THAT I DID NOT

The abandoned-project postmortem matters most, and its existence is the difference between a completed learning experience and a wound. Write it the week you stop, not later.

The Final Paper

6,000–10,000 words, following templates/report.md's long form. Full requirements on P15.

The three sections that decide whether it is credible:

• Threats to validity — written before you are asked. Every measurement that could mislead, every assumption you did not verify, every scale you did not test.
• Limitations — what the work does not show. Specific, not modest-sounding.
• Reproducibility appendix — verified by someone who is not you.

The abstract must contain a number. An abstract without one is a description of activity.

Publish the preprint at W126, before the polish. It timestamps the work, it is free, and the version-of-record can come later. See Research Directions for venue options — and note that for systems work, a well-measured post with reproducible code often reaches more of the relevant audience than a workshop paper.

The Narrative

The last artifact, written at W130. One page — a README for the whole journey — that answers:

• What was the goal? Not "learn systems". The specific capability.
• What did I build? Fifteen systems, one table, one line each.
• What did I learn that I could not have learned by reading? The three or four results that required building. The bytecode sign-flip. The ANN constant-factor decomposition. Bélády's anomaly reproduced. The 29× gap to a matrix coprocessor.
• What was I wrong about? The prediction-accuracy record across ~80 notebook entries is a genuinely unusual thing to be able to report.
• What would I do differently? From the five postmortems.
• What is next? From Research Directions.

This is the page you link to, and the fifteen repositories hang off it. Without it, a reader sees a list of projects and has to construct the story themselves, which they will not do.

What Not To Do

References

• Peyton Jones, S. How to Write a Great Research Paper. Microsoft Research, 2004.
• Zobel, J. Writing for Computer Science, 3rd ed. Springer, 2014.
• Shewchuk, J. R. Three Sins of Authors in Computer Science and Math. 1997.
• Collberg, C., Proebsting, T. A. Repeatability in Computer Systems Research. CACM 59(3), 2016.
• Hoefler, T., Belli, R. Scientific Benchmarking of Parallel Computing Systems. SC 2015.
• Blackburn, S. M. et al. The Truth, The Whole Truth, and Nothing But the Truth. ACM TOPLAS 38(4), 2016.
• Bailey, D. H. Twelve Ways to Fool the Masses When Giving Performance Results on Parallel Computers. Supercomputing Review, 1991. Read it as a list of things not to publish.
• Wilson, G. et al. Best Practices for Scientific Computing. PLoS Biology 12(1), 2014.
• Ousterhout, J. Always Measure One Level Deeper. CACM 61(7), 2018. Why the mechanism matters more than the effect — the basis for point 3.