What You Didn't Learn (Yet) -- The Honest Gap List

What This Concept Is

No ten-semester program produces a complete engineer. The gap list is the explicit, written inventory of what you still don't know, scoped to things a working engineer in your chosen track is eventually expected to understand.

The list has 3-5 entries. Each entry has three parts:

the gap, named concretely
why it matters (in the track you chose)
the first concrete step to close it

The purpose is not to enumerate everything you do not know; that list is infinite. The purpose is to name the specific near-term gaps and disarm them.

There is a rarer but more important purpose: the gap list is the artifact that shows you know the difference between what you know, what you know you do not know, and what you do not know you do not know. Most engineers conflate the three, and the conflation is visible in interviews, in reviews, and in design docs. An explicit gap list is the antidote -- it is the public commitment that you operate in the middle category and are actively shrinking it.

The list is also meant to be short. Four to five specific gaps is a plan; fifteen is a dump. The discipline is choosing which gaps matter most for the chosen track and the next 12 months, and deferring the rest. Most people's failure mode is listing too many gaps, not too few.

Why It Matters Here (In the Capstone)

Senior engineers distinguish themselves partly by being able to say "I don't know that yet" without flinching. The honest gap list is where you practice that. It also converts every interview-style question about weaknesses from a panic moment into a pre-thought answer.

This concept is SUPPORTING because it is not strictly needed to graduate -- but omitting it is a tell. A defense without a gap list reads as false confidence. Every peer reviewer and interviewer who has seen a few hundred candidates will feel the absence even if they do not name it.

The gap list is also the partner artifact to the 12-month plan (concept 12). The plan says "here is what I will build"; the gap list says "here is what I am not yet good at, and here is how I will close it." Without the gap list, the plan reads as overconfident; without the plan, the gap list reads as unanchored.

Concrete Example: Four Real Gaps, With Closing Plans

#	Gap	Why it matters (for chosen track: distributed)	First concrete step
1	I have not run a distributed DB in production	Job descriptions assume at least operational familiarity	Run a 3-node Cassandra or CockroachDB locally for a week, cause a partition, observe
2	I can explain Raft but have not read a real implementation end-to-end	Track-level strength requires reading production code, not just papers	Read the `hashicorp/raft` repo main path + tests over two weekends, write one post
3	My threat-modeling instinct is weak	Distributed systems expose surprising attack surfaces	Do one STRIDE pass on the capstone; read one real incident post-mortem per week for a quarter
4	I have not mentored anyone	Senior growth in any track requires this	Volunteer to review one early-career engineer's PRs for three months

These are the shape of honest gaps. They are specific, they connect to the chosen track, and they each have a first step that can be started this week.

Concrete Example: Bad Gap List (What To Avoid)

Contrast:

"I want to learn more about AI, cloud, and leadership."

That is aspirational noise. It does not name a specific missing thing, does not connect to the chosen track, and has no first step. If your first draft looks like this, iterate. An aspirational gap list is worse than none -- it communicates that the author has not actually audited themselves, just declared direction.

A second bad pattern is the "self-flagellation list" -- a dump of everything the author feels insecure about. The gap list is not therapy; it is a graduation artifact. It has to be specific, narrow, and actionable.

Concrete Example: Track-Conditional Gaps

The same engineer picks different gaps depending on the track chosen in concept 12:

Track	Typical gap list shape
Backend	schema evolution at scale, API versioning under real contract pressure, database internals (e.g., index selection), mentoring
Distributed	consensus under production load, operational debugging of replicated state, writing a correctness test suite, mentoring
Platform	internal SDK design, deprecation and migration management, developer-experience measurement, mentoring
Infra / SRE	multi-region design, cost accounting, capacity modeling, incident command
Data	warehouse modeling at scale, query optimizer internals, pipeline observability, data ethics
Security	adversarial incident response, supply-chain attacks, formal threat modeling at scale

The point: the gap list is not generic. It is the specific list of things your chosen track will start to demand within the first 12-24 months. If your gap list could be anyone's, it is not yet your list.

Common Confusion / Misconceptions

Humility theater. Listing gaps so broad they are safe to admit ("I should learn more math"). Safe gaps do not cost anything to declare. Real gaps are specific and slightly uncomfortable to name.

Using the gap list as a self-improvement manifesto. Four gaps is better than fifteen. The discipline is choosing which few things to close first. A fifteen-item list is a dump, not a plan.

Treating gaps as shameful. A reviewer reading a well-scoped gap list concludes the engineer knows where they are weak, which is a much stronger signal than a candidate pretending to be even.

Confusing "unknown" with "gap." You do not have to close every unknown. A gap is an unknown that your chosen track will demand of you within the plan horizon. Things outside that horizon stay on a separate "someday" list, not the gap list.

How To Use It (In Your Capstone)

Produce the gap list in this order:

Re-read your strength grid (concept 10). Low cells are gap candidates.
Re-read your 12-month plan (concept 12). The plan implies gaps; surface them.
Pick 3-5 gaps with highest relevance to your chosen track.
For each, write one sentence of why it matters and one concrete first step.
Share with one peer or mentor. Accept their challenge if they flag an omitted gap.
Commit the list as library/raw/gaps.md alongside the specialization plan.
Six months after graduation, revisit and mark closed gaps; if the list has not changed at all, the plan is not being followed.

Check Yourself

Is each gap a specific thing, not a topic area?
Does each gap connect directly to your chosen track?
Can each "first step" actually start this week without new resources?
If a peer read the list, could they predict at least one interview question you would struggle with?
Is the list short (3-5 entries), or has it sprawled into a manifesto?
Is there a calendar reminder to revisit this list in 6 months?

Mini Drill or Application (Capstone-scoped)

Three drills:

Draft the list. Write your gap list now. Aim for four entries using the three-part structure (gap / why / first step). Read aloud. If any entry sounds safe, replace it with a less-safe one.
Mock-defense import. Open the stumble log from concept 14's mock defense. For every stumble that was actually a gap (not just a story needing polish), lift it into the gap list. Duplicates become the first signal of the most urgent gap.
Peer-reviewed final. Share the list with one peer or mentor. Ask specifically: "what gap did I omit that you would have expected?" If they name one, add it. File as library/raw/gaps.md alongside the specialization plan.

Six months after graduation, come back to this file. Mark any gap you have closed. If all four are still open, the plan from concept 12 is not being followed -- course-correct.

Transfer / How This Synthesizes Prior Semesters

Naming specific gaps honestly is a skill the degree has quietly been preparing you for across many semesters; the gap list is where those disciplines converge on a personal artifact:

S10 M05 c4 concept 10 -- strength grid -- the low cells are literal gap candidates; the list is downstream of the grid.
S10 M05 c4 concept 12 -- 12-month plan -- the plan and the gap list are mirror artifacts: the plan names what you will build, the gap list names what the plan leaves unresolved.
S7 M05 ADRs & reviews -- ADRs include "consequences" because decisions carry tradeoffs; the same discipline applied to your own direction produces the gap list.
S8 M05 technical leadership & strategy -- senior engineers are distinguished partly by ease with "I don't know that yet"; practicing here is how you earn that ease under pressure.
S10 M05 c5 concept 14 -- interview defense -- the stumble log from the mock defense is the most honest input into the gap list; recycle it directly.
S3 M05 applied design & code review -- the same critical eye that finds weaknesses in a colleague's code, applied inward, is what populates the gap list with specifics rather than aspirations.

The transferable move: claim less, close more. Senior careers compound on the difference between "I should learn X" (aspirational) and "I have X on my named 6-month list" (commitment). The gap list is where you practice the second voice, and it is the voice that makes your bio, your defense, and your post-graduation plan credible together.

Source Backbone

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

Software Engineering at Google - engineering evidence, review, and team-scale standards.
Fundamentals of Software Architecture - architecture vocabulary and tradeoff defense.
Building Secure and Reliable Systems - security and operational evidence standards.

What This Concept Is​

Why It Matters Here (In the Capstone)​

Concrete Example: Four Real Gaps, With Closing Plans​

Concrete Example: Bad Gap List (What To Avoid)​

Concrete Example: Track-Conditional Gaps​

Common Confusion / Misconceptions​

How To Use It (In Your Capstone)​

Check Yourself​

Mini Drill or Application (Capstone-scoped)​

Transfer / How This Synthesizes Prior Semesters​

See also (integrative)​

Source Backbone​