Skip to main content

Command Palette

Search for a command to run...

Knowing When to Stop

Updated
•2 min read•View as Markdown
S
I'm Sushanth, a high school senior in Hyderabad, India. This is where I write about the things I spend time on: learning from mistakes, building things in code, and the tools I actually work with day to day. I hold the Candidate Master title and a FIDE International Master norm, earned across roughly 140 rated tournaments in six countries. I stopped competing in 2025, but the habit competition taught me, sitting down after every loss and figuring out exactly where I went wrong, shapes how I approach everything else. On the technical side, I've gone deep on C/C++ through Duke University and University of London coursework. I'm also someone who likes a good terminal workflow and enjoys exploring (and abandoning) productivity tools. Expect posts on Neovim, tmux, what broke this week, and whatever I'm tinkering with.

Corral taught me what a multiplexer is. TUIOS is the one I actually want.

Last week I published a post about Corral, the terminal multiplexer I'd started building even though I already had Tmux configured and working. That post ended by admitting Corral might end up half-finished, quietly replaced by the thing it was trying to improve on, and that I'd be fine with it. I wrote that on a Thursday. I decommissioned the project five days later.

The reason is TUIOS, a terminal multiplexer someone built over the last year, with four thousand stars on GitHub, that does everything Corral was trying to do: tiling panes, workspaces, sessions that survive restarts, and the agent-aware stuff that was my whole reason for looking past Tmux. Finding it made the decision easy, right up until the part where I had to admit the time already in Corral was gone. That was the only part that felt bad.

Which is the sunk cost fallacy wearing a productivity hat. The repo isn't an investment I have to see through because of the hours already in it. I started Corral to learn what a multiplexer is from the inside, since configuring one only shows you the outside. That happened. I got the understanding in the two weeks the project ran. The mistake would have been keeping it alive out of loyalty to the version of me that started it.

Knowing when to stop is a skill, and it's a different skill from knowing when to start. Starting is easy, the first weeks feel productive, momentum does the thinking. Stopping means re-evaluating the bet with the information you have now instead of the information you had when you placed it. When I started, no single tool combined the things I wanted. When I found TUIOS, that stopped being true. The right response to new information is to update the plan, not to protect the old one.

I've written before about the cheapest step in a pipeline being the decision not to run it. Same idea one level up: the cheapest feature is the one you decide not to build, and the best tool is sometimes the one you didn't write.

Corral gave me the learning. TUIOS gives me the multiplexer. I don't think that's a failure story. I think that's the version of last week's post that ended well.