On Building Tooling for Your Workflow (breach)
On Building Tooling for Your Workflow (breach)
I have been obsessed with my workflow for as long as I have been an engineer. It sits at the intersection of productivity and daily habit, two things that feel deeply personal to me, and getting it right has always felt worth caring about. So lately I have gone full meta: building tooling to make myself more effective at the work of doing work.
The project is called breach. Partly because I think whales are cool (I have been watching a lot of Survivor and the whale b-roll is great), and partly because I like the metaphor of "breaching" hidden information to the surface, which is exactly what the tool is for.
The pain point
My workflow lives across way too many git repositories. Some of that comes from working in a microservice architecture professionally; the rest is just me having way too many side projects :). Either way, the cost is the same: context is fragmented, status is invisible, and keeping things in sync is death by a thousand papercuts.
The failure modes are quiet ones: you branch off a main that turned out to be three weeks stale, you miss a failing CI build on a side project for a week because you weren't looking at that tab, and you spend the first ten minutes of every morning running the same handful of commands across five directories just to figure out what state you're in. None of these are catastrophic on their own, but together they tax your attention all day, every day, the kind of friction that's invisible until you remove it.
What it does
Breach focuses on three things, mostly:
- Visibility into many repositories at once. A single view of what's dirty, what's behind, and what's ahead, so I no longer have to
cdthrough directories trying to remember what state everything is in. - A simple workflow for keeping up to date with many remotes. All the boring, error-prone glue work of pulling, fetching, and syncing, reduced to something I don't have to think about.
- Remote CI as a first-class citizen. I want to know when something is failing without having to babysit twelve browser tabs, because CI status belongs at your fingertips, not on a dashboard you have to remember to check.
The plan
The plan is to get aggressive about it: hunt for the micro-optimizations that quietly cost me time and mental energy and codify them into breach one by one, iterating fast and using it constantly so that the friction I actually feel dictates what gets built next.
And then open source the whole thing, because workflows are deeply personal and I have no illusion that mine will fit anyone else's perfectly. But if some piece of it resonates (if you also have too many repos and not enough visibility), there's a good chance the same friction is grinding on you too, and it is better to share notes than to each reinvent the same handful of git wrappers in private.
If you want to follow along or try it out as it evolves, it lives here: github.com/nbritten/breach.