Immature poets imitate; mature poets steal; bad poets deface what they take, and good poets make it into something better, or at least something different.

– T.S. Eliot, 19201

A public garden

Work is changing, and you can see it in dotfiles: new repos keep appearing, and old ones that sat quiet for years now change weekly. Harnesses, agent rules and novel ways of working sprout up faster than anyone can try them, and we each tinker our way toward something better. I can run one experiment at a time. Collectively, we’re running hundreds.

My dotfiles have been public since 2012. They started public because bootstrapping a new machine is easier without auth. Then it became a philosophy: command line or death, love your editor, show your work. Public, but personal. My goal was never to have someone else clone verbatim.

For most of those years I picked up new tricks by watching whoever sat next to me, until remote work took that room away in 2020. Someone else’s dotfiles are the nearest thing to sitting beside them: the config itself, with a commit history that admits when they changed their mind. So I stopped waiting to bump into good ideas and went looking for people who publish theirs.

Level 60 spells

Two dotfiles repos with the same goals will disagree on nearly every tool. @samandmoore’s repo keeps fish, zsh and bash side by side. Mine is bash-first, and the spike to try fish has sat open since August. Which shell wins is the least interesting part of either repo. What’s worth taking is a decision, and the reason someone made it.

One way to share codified wisdom is to publish a framework. As an acolyte, you run an installer and gain hundreds of aliases, a plugin system, and choices made for you. Level 60 spells at level 10. Nothing in it is wrong. It’s someone else’s philosophy: having learned it, you must obey it or fight it.

A framework is a bet that your problem is my problem, and its author carries the cost: packaging, docs, and keeping it working on machines they’ve never seen. Most people never sign up for that, so their best decisions stay on their own laptops.

The bet was fair when rewriting the parts that didn’t fit cost more than adopting the whole thing. That’s changed. Rewriting a small tool now costs less than bending my workflow to fit yours, so I can take the approach, not the distribution.

@obra’s manifest is a text file listing a path and an optional os flag. It’s a file in his repo, not a product. Mine is a manifest with host conditions and a small bash driver behind it, because that is what my machines need. I read his, took the shape, and conjured my own.

Something different, by constraint

Sam’s setup rings a terminal notification when an agent finishes its turn. Ok, I recognize that problem! Long agent turns end silently, so you never know when it is your move. I took the idea and it broke on contact: macOS notifications are disabled on my machines. What shipped instead was a tmux bell that flags the window and keeps it flagged until I look.

Something different, in Eliot’s sense, and not by design. By constraint.

Then it kept going. Scoping that bell meant reading my terminal config. iTerm2 keeps its settings in a binary plist: the one piece of my setup no symlink could manage and no diff could review. kitty keeps its config in a text file. I installed it alongside to see, and immediately became a convert. (Thanks for the inspo, Sam!)

Under the old economics that is a failure: his thing would not install, and refitting it cost more than living with the silence. Now the refit is the cheap part, and the calculation turns over. The artifact was never the valuable half. The reasoning was.

And vice versa

So, I do not have to learn your way. I can read it, make it mine, and you can do the same. My deploy.sh is there for whoever it helps: not a project I maintain out of duty, but a worked example, meant for reading rather than installing.

The return is not a faster setup. It’s random acts of enlightenment: I went looking for a notification and came home with a new terminal.

I codified the looking. A skill is a written procedure my coding agent follows, and /find-inspiration points it at a repo with similar goals and different decisions. It profiles their setup, compares it against mine, and hands me a list of ideas to take, adapt or decline. Every call is still mine, and every yes still needs babysitting. The skill logs each decision with its reason, and the yeses become issues.

The reasons matter most on the nos. The same run that gave me the bell turned down Sam’s theme switcher as “built for a tiling-WM stack this machine does not have.” A fact about my desk, not a verdict on his.

Try it. Point it at my repo, or at anyone’s whose setup you admire. Fork the skill and bend it to your own conventions. Steal what works, publish it with your reasons, and credit whoever you took it from. My README’s credits are how the next person finds the people I found.

Cuttings

What comes next remains to be seen. The old open-source compact (“here’s my code; I’ll probably keep it working if you like it”) feels archaic or one-sided now. The new deal asks less of both of us: read my decisions, and make your own. Nobody has to maintain anything for anyone else.2 One person’s problem, solved well and in public where someone facing the same wall can read it, is enough.

Gardeners have always traded cuttings, not plants. A cutting roots in your soil and grows into something different.


  1. T.S. Eliot, “Philip Massinger,” in The Sacred Wood (1920), via Project Gutenberg. Also see the Picasso version: “good artists borrow; great artists steal.” ↩︎

  2. Ok, you caught me. Nobody needs to maintain small, bespoke things for anyone else. Please keep maintaining PostgreSQL. ↩︎