Building a Catalog of Reusable Work
A slice library is a moat for solo operators and small shops and a highway for larger teams, and it is valuable in both settings only when it is kept usable.
Two Practitioners, One Finished Engagement
Picture two practitioners who each finish a client engagement. Both produced useful pieces of work along the way: a data-handling routine, a configuration pattern, and a set of checks written to confirm results. The first practitioner closes the project folder and moves on. The second spends an extra hour pulling the reusable pieces out of the project, tidying them up, and saving them where they can be found again. A year later, which of them can start the next engagement faster?
The answer is the second practitioner, and the reason is the subject of this article. The source material calls the collection of reusable parts a slice library, and it makes a sharp point about it: the library does not build itself. Someone has to decide to build it, and that decision has to be repeated after every piece of work. Before looking at how this happens, it helps to see why the library is worth that effort in the first place.
How a Library Grows Across Engagements
The central claim of the source is that the library grows only through deliberate action. It is built because the FDE, at the end of every engagement, makes time to extract reusable parts, document them, and add them to the catalog. None of these steps happens automatically as a side effect of doing the project. Each one has to be chosen.
Tracing a small illustrative library through three engagements
Suppose a practitioner starts with an empty library and finishes three client engagements. Each engagement ends with the same routine: extract the reusable parts, write the README, and add the entry to the catalog. The names and counts here are invented for teaching purposes and are not drawn from the source.
- 1Engagement 1 closes
The routine runs and produces one documented entry, a data-handling routine with its README. The library now holds one usable part where it previously held none.
- 2Engagement 2 closes
The routine runs again and adds a configuration pattern with its README. The library now holds two entries. The first entry has not changed, but the practitioner now has two starting points instead of one.
- 3Engagement 3 starts
The practitioner searches the catalog before writing new code and finds the data-handling routine. They reuse it, adapt it to the new client, and spend their time on the parts that are genuinely new.
The benefit does not show up at the close of any single engagement. It shows up in the third one, when work starts from existing parts instead of from nothing. The source describes this as compounding: each engagement that ends with an extracted, documented piece leaves the library slightly larger and easier to use.
Why the Library Matters
The source gives the slice library a different job depending on who is working. The metaphors point to the same underlying asset, but they describe different ways of getting value from it. Both roles depend on the library being kept in a usable state.
The End-of-Engagement Routine
Maintenance can be thought of as a short sequence that runs at the close of each engagement. The source names three actions in order. The diagram below summarizes that ordering as a pipeline. It is a summary of the source's sequence rather than a separate procedure.
Read the pipeline as a chain of dependencies. The template is the raw material. The README is what makes that material usable by someone else. The catalog entry is what makes the finished piece findable at all. Each step relies on the one before it, and skipping a step weakens the ones that follow.
Where the README and Catalog Entry Fit
The README is what lets someone else pick up a part. The source is direct about this: skipping documentation undermines the library even when the code itself is sound. A clean template with no README gives the next FDE the code but no stated way to understand it, decide whether it fits a new engagement, or use it safely.
Mistakes That Stall the Library
Common mistake Treating extraction as something that happens on its own
Why it failsThe source states that the library does not build itself. Parts are added only when the FDE deliberately makes time at the end of an engagement.
Do this insteadMake the three-step routine a fixed part of closing every engagement.
Common mistake Saving the code but skipping the README
Why it failsThe source warns that skipping documentation undermines the library even when the code itself is sound.
Do this insteadWrite the README before the entry goes into the catalog, so the next FDE can pick the work up.
Common mistake Adding a finished part to the catalog without a findable entry
Why it failsThe catalog entry is what makes the finished piece findable at all. A part nobody can locate provides no moat or highway value.
Do this insteadAdd every documented template to the catalog as the final step of the routine.
Common mistake Assuming the library's value appears in the current engagement
Check Your Reading
What do you think happens?
Before reading the answer, predict: if a practitioner extracts a clean template but never writes a README, which of the three routine steps has been skipped, and what does the next FDE lose?
Reveal answer
The README step has been skipped. The next FDE has the template but no stated way to pick it up.
The source names the README as what lets someone else pick up a part. Skipping it undermines the library even when the code is sound.
A small shop finishes an engagement and produces a configuration pattern. Using only the three-step routine from this article, describe what the practitioner must do before the pattern counts as a usable part of the library, and explain what each step contributes.
Hints
- Count the steps in the order the source gives them.
- Ask what the next FDE needs to find the pattern and what they need to understand it.
Key Takeaways
- A slice library is a moat for solo operators and small shops, protecting their accumulated know-how, and a highway for larger teams, moving work between people.
- The library grows only through deliberate action. At the end of every engagement, the FDE extracts reusable parts into a clean template, writes a README for the next FDE, and adds the result to the catalog.
- The README lets someone else pick up a part, and the catalog entry makes the finished piece findable. Skipping documentation undermines the library even when the code is sound.
- The benefit of the library compounds across engagements and shows up when later work starts from existing parts instead of from nothing.