Posted by theanonymousone 1 day ago
I acquire and operate ecommerce companies, and build a lot of workflows with openclaw-like agents (my own stack).
When it’s working really well, there’s literally no interface needed besides iMessage and email. I’ve built a SaaS app interface style largely to show it off for demos because invisible tools don’t make for great demos
I totally agree with the larger point, but there are things you can do with vim macros that are just an absolute PITA to do with the built-in tools in vscode. Or maybe there is a specific tool that can compete (or beat) a specific use case of a vim macro, but macros are a single tool that covers a zillion use cases. So for this specific example I think there’s a tangible difference in capabilities.
Also 99.9% of the time-saving macros that people write on a day to day basis are not being shared with a single other person. It’s just a tool that becomes invisible to people who are comfortable with it. I’d argue that modal editors are particularly good at getting out of your way! Particularly ones with little or no config, like helix (or even vim mode in an IDE)
The first argument is about people. People romanticize the flaws of their tools, turn vim macros into a personality, and mistake the feeling of cleverness for output. Fine. True. Bill is correct that a lot of tool evangelism is tribal signaling dressed up as productivity advice. However, people join these tribes because they get benefit from it. If the tool wasn't meeting their perceived needs, they wouldn't be passionate.
The second argument, the one in the title, is about tools: that being invisible is what makes a tool good. That one is fundamentally wrong, IMO.
Halfway through, Bill admits the invisibility test "is a personal one." Which means: a tool is good when it disappears for you. Sublime is invisible to him because he's been at it for fifteen years. On day one it was not invisible to anyone. In fact, I remember buying a book and reading it back in the day about how to get better at using Sublime. So "good tools are invisible" reduces to "good tools are tools you've already mastered." That's not a claim about tools; rather, it's a claim about experience. Every powerful tool is bad to the novice and invisible to the expert. So I'll categorize this one as a veiled tautology.
Then there's the metric. Bill's "honest test" is wall-clock time and mistakes made. Anyone who's less familiar with a tool is going to make more mistakes up front. I have a couple of professional-grade sanders that I've used for some projects around the house, and because I use them infrequently, I tend to make mistakes when I get started since it's not my core competency.
The right question for a power tool isn't how fast you did the routine thing, it's what became possible that wasn't before. Git is not invisible to anyone, ever, and it's the most successful version control system ever built, for better or worse. Of course, lots of people also think Git is bad, so I'm not making any particular claims on that front, but it did manage to reach a local maxima that led people to jump ship from SVN et al. SQL has been the standard for fifty years and is famously brutal to master. A profiler demands your full attention every time you open it. These tools are good because they expand the frontier of what you can express. A tool that makes the impossible merely hard beats a tool that makes the easy invisible. Bill's metric scores the median task and is blind to the edge, which IME is where I end up spending more of my time as I grow as a software developer..
The configurability section is where the essay argues against itself. Bill's fix for "highly configurable" cop-outs is "good defaults, plus escape hatches for the rare cases." But the escape hatch is the whole problem with his thesis. The moment a tool has escape hatches, the knowledge to use them is valuable, and the tool isn't invisible even to him. He wants the power and wants to disown the learning it costs. You don't get to do that. The escape hatch and the learning curve that leads to it are the same object. He even admits it. In the learning-curve section he concedes a steep curve "could absolutely be a cost worth paying" if the payoff is real productivity. That's the entire counter-thesis. So I'm not really sure what point he's actually trying to make with this article besides that you should have good defaults for tools.
It's not perfect and the bugs that have been there for years (and won't be fixed) have annoyed me for years too. The reason I still stick to Sublime is just because the alternatives that are similar are much much slower. I wish Sublime was actually invisible to me, but it isn't. It's just the most invisible I've found out of the alternatives.
> But the escape hatch is the whole problem with his thesis
I understand what you are saying, but the point of an escape hatch is that for the general everyday cases, the defaults should be good and invisible. But there will always be edge cases which you cannot handle nicely, either there hasn't been a way discovered yet which is better or there are other external accidental things which prevent it from being "nice" (not I am talking about tools in general and not just text editors, maybe even programming languages hint).
> The escape hatch and the learning curve that leads to it are the same object. He even admits it. He even admits it. In the learning-curve section he concedes a steep curve "could absolutely be a cost worth paying" if the payoff is real productivity. That's the entire counter-thesis.
I don't agree with your interpretation of my article. I am talking about certain people in particular that are saying the bad aspect of tool is actually good. If there is a high learning curve for a tool, it needs to eb compared to the current alternatives. But sometimes the curve is "essential" and cannot be improved upon, for better or for worse. I have yet to see many "essentially" high learning curves in the domain of programming.
I am not sure how to summarize the entire article other than what I already wrote in the conclusion.
Removing friction from the context and flow. For what git and sql do, they arguably have the most efficient and effective work flows for their purposes.
Managing complexity becomes unavoidable for certain problems, so for challenges of the tool, sometimes, it's simple the challenge of the problem.
I would say his point is not articulated well. Tools should be less toilsome and provide faster feedback loops.
The author's message is really "You idiots that can't just ignore the friction you can't fix, and change your habits and workflows to match what the corporate overlords know you really need should just STFU with your tips and tricks for how to customize your power tools, because I don't do that, so why should you?"
I've used vim for decades. Tried using Sublime about 10? years ago. It just got in the way.
I can't justify using Emacs myself on a productivity basis. But working in an environment I think is fun while being productive makes me marginally happier.
If you are having fun, and it's a hobby: who cares? If it's in the professional setting, make sure what you are doing is not actually wasting time and/or money, i.e. be productive.
Do you people think we spend our weekends tweaking our configs because that is how we get our fun? Some do, sure, the vast majority have created their config once and find themselves more productive compared to whatever alternative you might be suggesting. Configuring vim or eMacs is an investment, as you are likely to still see it around in 20 years. Being familiar with one’s tools is the key to productivity.
Calling it an ‘obsessive hacker tool’ just shows you don’t know what you’re talking about, but come with preconceived notions about why people prefer other tools.
This is intellectually dishonest framing. "obsessive hacker tools" is incoherent -- it's not the tool that is obsessive or a hacker. I don't obsessively hack emacs--I barely know elisp--and emacs is very much a productivity enhancer for me. The main benefit of the hackability of emacs for me is that hackers write useful packages for it that I occasionally run across and install.
His whole rant on Linux and "highly configurable software" vs good defaults is just plainly nonsense to me.
> “Highly configurable” is often just an excuse for shipping no opinion at all and calling the resulting work your problem."
I couldn't disagree more. You can argue that Linux or other open-source software don't have "good defaults" is mostly because there's way less investment in 1) user experience; 2) quality assurance; mostly because there's no product logic involved in it.
Especially if you think that Linux, for example, is the mostly used in servers, and it works usually fantastically well in most server VMs. Maybe it needs a lot of fiddling to make it work on your old dell laptop because it's not where the work is put at. Windows will run well on it because Microsoft puts people actively working on making it run on most commercial user-end hardware. Apple machines will work perfectly on their hardware because that's what they're made for.
Arch Linux is not just better than any other Linux distro. It's better at one thing, just like Ubuntu is better at something else.
> I don’t want my tools to be “fun”. I want my tools to be invisible. > A good tool is and ought to be invisible—striving to make such tools is the goal of a toolmaker.
Bit of a wrong take, on my opinion. Every tool has its quirkiness, and you should embrace it. No tool is invisible. It feels less "visible" as you build more "muscle memory", but it's still there. We have to embrace the tools as part of the craft, not pretend they don't exist.