What's Actually in the Folder
I keep mentioning the folder. People keep asking what is actually in it. Here is the answer.
A few of you emailed after the last post asking the same question. “You keep talking about this folder. What’s actually in it?”
Fair. I have been writing around it for months instead of writing about it. Today is the day I write about it.
Quick context if you are new here: five years ago, after a three-hour debug of an Oracle row lock that turned out to be a missing transactional annotation, I started a folder on my laptop called incidents. The first doc was incident-001.md. Symptom, wrong root cause, actual root cause, fix, what should have prevented it. Five sections, four paragraphs. I labeled it and saved it and did not plan to ever do it again.
Five years and three companies later, the folder has 80+ entries in it. After the May layoff I started cleaning it up and organizing it into something readable, partly because I needed income, mostly because I had been meaning to do it for years and never had time.
What follows is what is actually in there now. Six bundles, each one a different angle on the same five years.
I am writing this for two reasons. One, some of you have been asking what to buy and I owe you a clear answer. Two, the catalog is not really separate from this Substack. They came out of the same notebook. Reading one helps with the other.
The Spring Boot one
Almost half the incidents in the folder are Spring-specific. That is partly because three of the last five years were on Spring Boot services. It is also because Spring’s annotation magic creates a specific class of bugs that other frameworks do not produce in the same way.
The @Transactional ones especially. Self-invocation that silently disables the annotation. Default propagation that opens a new transaction when you did not mean it to. Missing annotations on entry points where Spring Data wraps each save in its own tiny transaction, which is fine until it is not.
Plus all the HikariCP stuff. Default pool sizes that worked at one tenth your current traffic. Connection leaks that look like database problems. The retry pattern that creates the cascade.
Plus two complete starter codebases with auth, gateway, and service discovery wired. Those took weeks to build the first time. They should not take weeks for the next engineer who needs them.
This is the Spring Boot Production System. Nine documents, two starter codebases, the 47-check pre-deploy system.
The 80-incident library
The same folder, sorted differently. Eighty-plus production incidents documented end to end. Pattern library underneath them — silent failures, load-revealed bugs, cascade failures, configuration drift. The diagnostic playbooks for the during-incident phase. The postmortem framework for after.
I keep saying pattern recognition is the actual skill that separates a thirty-minute fix from a three-hour debug. This is the bundle that holds the patterns. If you have been on call for a year or two and want the version compressed into a system instead of learning it the slow way, this is it.
Production Incident Playbook. Nine documents.
The starter kit for first on-call
Smaller version of the one above. For engineers who have never been paged before, or who have been paged a few times and still freeze. Six documents. The minimum to walk into a rotation without panic.
The reason this exists as a separate product: the full pattern library above is overwhelming if you have never had a 2 AM page. You do not need 80 incidents. You need four playbooks and a runbook structure. This is that.
The interview prep
I have written about the senior interview I bombed a few times now. The “I fixed a database issue” answer. Nine seconds. Offer lost.
The bundle is what I built after that, over the course of preparing for three more interview loops and losing two of them before something clicked. The behavioral framework with the four senior signals. Eight stories every engineer needs ready. Five word-for-word salary scripts. System design walkthroughs for the questions that come up most often.
The salary scripts alone are the chapter most engineers skip and the chapter that has paid for the whole bundle back ten times in feedback emails. If you are interviewing in 2026, this is the one to read first.
If your weak round is specifically system design and the rest of your interview performance is fine, there is a focused product for that round only. Same author, narrower scope.
Everything in one
The full folder, organized. 28 documents. Spring Boot, infrastructure (Docker, Kubernetes, Linux, Redis, PostgreSQL), incident response, senior interviews, and 50 case studies of incidents costing $10K to $1M.
This is the bundle for engineers who keep buying the smaller ones and want to just have everything at once. Buying every component separately is $516. The bundle is $199.
I am not going to oversell this. It is the most expensive thing in the catalog and it is for a specific kind of buyer — usually a tech lead or someone setting up a team library. If you are a single engineer just trying to solve one specific thing, one of the smaller bundles above is the right product. If you want all of it on a hard drive, this is.
Production Engineering System.
What I am keeping for myself
There are a few things in the folder that are not in any of the bundles. Conversations with managers I do not want to publish. Postmortems from specific incidents that would identify the company even with names removed. Interview transcripts where the person I was talking to said something I should not repeat. About thirty documents, roughly.
I am not putting those out. Some of them I might write about here on Substack someday, with enough abstraction that they cannot be traced back. Most of them are just for me.
The folder turned out to be more than a publishing pipeline. It turned out to be a record of five years of work that I am increasingly grateful I kept. The published parts pay rent. The unpublished parts are the actual archive.
What I am doing this week
The job hunt is going. Three companies in active loops. One I am cautiously optimistic about, two I will not be heartbroken to lose. The catalog is producing enough income to extend the trough by about a month, which is what I needed it to do. The writing is slow but it is happening.
The folder keeps filling. New things going in this week: notes from an interview loop that went badly, a recruiter conversation about salary I want to remember, three patterns from a contracting project that match patterns in the existing playbooks but with a new variation.
Future-me will be glad past-me kept writing it down. Future-me is, statistically, often someone going through the same trough I am in now. That is who I am writing for.
If you have your own version of the folder, keep filling it. It pays back in ways you cannot predict at year two.
And if you do not have one yet, today is a fine day to start.
— Devrim