Skin-Shedding Code

Here’s a bit of lingo that I learned working at Zed: shredding. Or: going on a shred.

What it means is to rewrite code. To take something apart — to feed it into the shredder — and put it back together again, but in a different, better way. It’s refactoring, but switching the scalpel for a sledgehammer.

When you say you refactor something, it might mean you change a single class, method by method, ensuring it works after each change.

Shredding, on the other hand, means to embrace destruction. To go on a shred is to delete five load-bearing functions all at once and recreating them. Deleting a type and its definitions, rebuilding it from the compiler errors. Creating an empty file and building from scratch a better version of what already exists in another file. Shredding is ripping out a page and redoing it.

The concept — taking something apart to recreate it — wasn’t new to me. What surprised me was how often it happens at Zed.

When I pair with Antonio, for example, he will often say “let’s delete this.” My response is usually to chuckle, but then he goes and deletes the whole thing in the time it takes for my pupils to dilate and a single syllable to leave my mouth: “uhm?”

Or when Nathan and Antonio pair, they might bump into something that doesn’t quite do what it should with their new requirements and instead of — clink clink clink — hammering it into shape, they will throw the whole thing out and rebuild it to fit the old and new usecase.

The whole team went on an exceptional, multi-week shred, right before I joined. They rewrote Zed’s underlying UI framework, GPUI, and moved the whole of Zed onto new stilts, resulting in a final +42,150 -330,105 pull request.

“What I really like is that no code here is considered holy,” a colleague said to me, “no code is untouchable.”

Widely practiced, part of the culture — but it’s not easy. Another colleague and I were together working on something and he said, “man, to rewrite such a component — the confidence…” Yes, I said. I knew what he meant: it takes guts to look at something that’s working and decide to break it, confident that you can rebuild it in a better way — instead of changing the tiniest possible part to make your change. It takes experience and self-awareness to know when a shred is a good idea and when it isn’t, when it’s better to make the small change instead.

Eight months after joining Zed, I still don’t know why the shreds work that well. Why doesn’t this codebase fall apart if parts of it are constantly being taken apart and reassembled?

Is it because the founders wrote the whole editor from scratch and know essentially every file in its codebase? Is it because they have been working on text editors for over a decade and know the domain well and how things should work and how they currently work is just a detail? Is it because the whole team is full of excellent programmers? Is it because of… Rust?

Or is it because the shreds aren’t manic destruction sprees, but scoped teardowns? Not a scalpel, not a wrecking ball either, but sledgehammers carefully aimed? Is it because the one who goes on a shred here is careful to not fall into the “… and when it’s rebuilt it should also do this and that” trap?

What I do know is this: I think these regular shreds are healthy for the codebase.

They remove the small things that pile up over time and that no one would put in again if they had to redo it. Controlled wildfires that burn away the underbrush — the most flammable part of a forest — leaving only the trees.

They allow you to throw away local maximums, by giving you the chance to ask: if I had to redo this part, what would it ideally look like? Ignoring sunken costs is what makes a shred a shred.

With regular, scoped rewrites — shreds — that recreate at most a handful of files, the codebase is in a constant state of renewal. Like a snake shedding its skin, it loses what it doesn’t need anymore.