Skip to main content

What To Show, What To Cut

What This Concept Is​

A case study is read by several different audiences. A recruiter skims for keywords and scope. A senior engineer skims for judgment. A hiring manager skims for fit. A future you skims to remember what you actually did. None of them read the whole thing on the first pass.

The concept here is tailoring depth -- choosing at paragraph granularity what to keep and what to drop -- without deleting the hard parts that make the write-up credible.

The rule of thumb: keep the decisions, cut the step-by-step. Show one representative deep dive per subsystem, not three shallow ones. The reader learns more from watching you think hard about one thing than from watching you touch ten things briefly.

There is a second, sharper discipline underneath the first: you must explicitly decide what not to put in. A case study that includes everything is not neutral -- it actively harms itself, because the reviewer's attention is finite and every low-signal paragraph reduces the weight they can give to the strong ones. Cutting is not modesty; it is an allocation strategy.

Why It Matters Here (In the Capstone)​

After ten semesters there is too much material. The temptation is to show everything to prove you covered everything. A case study that tries to include everything ends up including nothing, because readers stop in the middle.

The harder failure mode is the opposite: cutting so aggressively that the result reads like a résumé bullet and the reviewer cannot tell whether you actually did the work or just watched someone else do it. Both failures happen for the same reason -- no explicit decision about what each paragraph is for.

This matters doubly for the capstone because it is your only ten-semester case study. Every paragraph is either load-bearing or dead weight, and there is no second artifact to absorb the cutting-room floor.

A practical consequence: the first reader to actually disagree with your cut list is almost always the most valuable reader. If everyone says "looks good," the draft is either genuinely strong or has no handles to grab. Paragraphs nobody wants to discuss are paragraphs the reviewer skipped -- that is a cut signal, not a success signal.

Concrete Example: Same Project, Two Drafts​

Suppose your capstone is an event-driven inventory service with three upstream feeds, a Postgres write path, a Redis read cache, and an idempotency layer.

Bad draft (kept everything):

"We chose Postgres because of ACID guarantees, Redis because of latency, Kafka because of throughput, and Docker because of deployment. We used GitHub Actions for CI. The schema has 14 tables. The API has 23 endpoints. The frontend uses React..."

Nothing is wrong there. Nothing is interesting either. Every sentence is a shopping list.

Better draft (tailored):

"The hardest part was idempotency across three feeds that retry at different cadences. I settled on a dedupe window keyed by (source, external_id) with a 24-hour TTL in Redis, backed by a unique index on the same tuple in Postgres. This is slightly overbuilt for the current feed volume, but it was cheap to add and makes the failure mode observable instead of silent."

The second paragraph shows one decision, the alternative considered, the current cost, and the reason it survives review. It also implicitly says everything else -- the React frontend, the 23 endpoints -- was ordinary and does not deserve space. That implicit claim is the whole point.

A third test: read both drafts aloud and pay attention to where you speed up. Good readers naturally accelerate through "tools used" listings because there is nothing to latch onto. A draft you yourself speed-read over is a draft that should be cut there, not rewritten there.

Concrete Example: The Cut List​

Before submitting the case study, produce an explicit "cut list" -- paragraphs that a draft included but the final version does not. This is not just for discipline; it is a useful appendix the reviewer never sees but you can use in interviews.

Cut paragraphWhy cutWhere it lives now
Tech stack enumerationZero signal; reviewer can read package.jsonDeleted
Detailed walk of authentication flowUnchanged from Semester 5 courseworkOne sentence + link to S5 module
Full schema diagram with all 14 tablesLoad-bearing only for 3 tablesReduced diagram showing those 3
Three-paragraph CI pipeline descriptionOrdinary; any senior engineer can infer itLinked to repo .github/workflows/
Tutorial-style setup instructionsBelongs in README; not case study materialMoved to README.md
Post-mortem of a bug not in final systemCut unless bug shaped a surviving decisionDeleted; archived in library/raw/incidents/

Maintaining this list separately makes the cutting itself auditable. In interviews, the cut list is the single most useful prep artifact you own -- every "tell me about your capstone" question is answered with a kept paragraph, and every "did you ever try...?" question is answered from the cut list.

Common Confusion / Misconceptions​

"Tailoring depth" is not the same as "making it shorter." It is picking which things are deep and which are one-liners.

Cutting the embarrassing parts. If you spent two weeks debugging a race condition, that race condition is the single most interesting thing in the project. Cutting it removes the only section that proves you can think. Reviewers read hard-won failures as strong signal; smooth success stories pattern-match to "fabricated."

Padding the cut parts. "We used Git" is not information. Replace it with nothing. Fill words that sound careful ("importantly," "notably," "it is worth mentioning") are almost always padding that survived from the draft because the author was afraid to leave silence.

Confusing the README with the case study. The README documents. The case study persuades. The same paragraph usually cannot serve both, because the audiences read with different questions. Write them as separate artifacts and link them; do not duplicate content.

Cutting along the wrong axis. Length-based cuts ("make it 20% shorter") usually cut the wrong things -- often the hard-won details. Decision-based cuts ("keep the paragraphs that carry a choice you made") usually cut the right things. If your cut list is mostly prose at the ends of sections (the polishing), you cut along the wrong axis; real cuts happen in the middle, where the shopping-list paragraphs hide.

Treating the case study as timeless. A case study ages. A paragraph that was interesting in month one ("I'm learning about dedup keys") is ballast in month twelve. Re-read the draft as a stranger six months later and re-cut -- anything that sounds like a learning log rather than a decision record is a re-cut candidate.

How To Use It (In Your Capstone)​

Apply this pass to every draft:

  1. For each paragraph, write a 5-word summary in the margin.
  2. If two paragraphs share a summary, merge them.
  3. If a paragraph's summary is "tools we used" or "libraries chosen," delete it unless one specific choice was non-obvious.
  4. Keep exactly one deep dive per major subsystem. No more.
  5. If you cannot find a deep dive for a subsystem, that subsystem probably does not need its own paragraph.
  6. Maintain an explicit cut list of deleted paragraphs, with a one-line reason each.
  7. After the cut, re-read end-to-end aloud. If the pace feels too fast, you were right; first drafts feel slow on purpose.

Check Yourself​

  1. For each paragraph in your current draft, can you state what it would cost the reader to skip it?
  2. Which paragraphs are about decisions vs about tools? Is the ratio at least 2:1?
  3. What is the single most embarrassing or hardest part of the project, and is it visible in the writeup?
  4. Do you have an explicit cut list with at least five deleted paragraphs?
  5. If a reviewer asked "what did you not put in this write-up?", could you answer in 30 seconds with specifics?
  6. Is there exactly one deep dive per major subsystem, no more?

Mini Drill or Application (Capstone-scoped)​

Three drills:

  1. Margin summary. Take your current capstone draft and do the margin-summary pass. Count how many paragraphs reduce to "tools we used." Delete them. Count again. The second number is your signal density.
  2. Deep-dive pick. List your capstone's top three subsystems. For each, write the one-paragraph deep dive you would keep. If one subsystem's paragraph sounds generic, that subsystem is not interesting in your case study and should be collapsed to a sentence.
  3. Explicit cut list. Open a sibling file library/raw/case-study/cut-list.md. Record every paragraph you cut, in the table format above, with a one-line reason. Keep it in the repo; it is a legitimate artifact showing judgment.
  4. Hostile-reviewer pass. Hand the draft to one peer with this exact instruction: "underline every paragraph that would not survive a senior engineer's skim." Do not argue with the underlines; the underlines are the signal. Cut or rewrite every underlined paragraph before shipping.
  5. Three-audience check. Write three imagined readers in the margin -- recruiter, senior engineer, future-you -- and mark each paragraph with which audience(s) it serves. Any paragraph that serves none is a cut candidate. Any paragraph that serves all three is load-bearing; protect it.
  6. 90-second skim simulation. Hand the draft to a peer and give them exactly 90 seconds. Ask them afterward to describe the project out loud. The gap between what they say and what the paragraphs tried to say is the cut/rewrite signal, by paragraph, in priority order.

If your case study loses more than 25% of its paragraphs across these drills, that is a good sign, not a bad one.

Transfer / How This Synthesizes Prior Semesters​

The "cut ruthlessly, keep the decisions" discipline is not prose-specific; it is the same move you have practiced across the degree in different disguises:

  • S3 M05 applied design & code review -- removing an unused helper is the same act as cutting a shopping-list paragraph. Signal density is a code-review value before it is a prose value.
  • S7 M05 ADRs & reviews -- short ADRs beat long ones for exactly the same reason: the reviewer's attention is finite and every filler sentence drops the weight of the strong ones.
  • S8 M05 technical leadership & strategy -- the "less but louder" executive-communication rule is the same attention-budget argument pushed to the top of the org chart.
  • S10 M04 operational readiness & security review -- a runbook that tries to cover every failure covers none. One runbook deep, five linked, is the same shape as one deep-dive paragraph plus five one-liners.
  • S2 M01 algorithm analysis & design -- reviewers allocate attention the way algorithms allocate memory: budget first, fill second. The case study competes for the same resource.
  • S6 M02 storage engines & indexing -- the same "keep the hot path short, push cold data to an index" discipline is why the deep dive goes in the write-up and the CI config goes in a link.
  • S4 M05 abstraction & interpretation -- the decision about what to abstract in code is the same decision about what to elevate in prose; both are about which level to present to the reader.

The single transferable move: decide explicitly what to leave out. Every semester you skipped that move, the artifact was weaker for it -- and reviewers can still feel it. The case study is the last chance in the degree to practice that move on an artifact you control end-to-end, which is why getting it right here tends to generalize forward into everything from design docs to incident reports to promotion packets.

See also (integrative)​

Source Backbone​

Portfolio assessment packages evidence from the whole curriculum. These books provide the technical and professional backbone for the narrative.