Top
Best
New

Posted by theanonymousone 1 day ago

Good Tools Are Invisible(www.gingerbill.org)
529 points | 247 commentspage 7
jeffrwells 1 day ago|
In the age of agents, I’ve found the headline claim is even more true

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

noah7z 18 hours ago||
How does this apply to non-personal-computer-based tools? Heidegger has some cool commentary on the topic. I think good tools can be invisible, but they also unlock new capabilities, almost like a new bodily sense or a new organ. It's easy to focus on a text editor's removal of friction between thought and text, but I also wonder what new capabilities our tools will unlock.
chamomeal 1 day ago||
> I’ve had people tell me how “fun” it was to build a macro to handle some one-off text-refactoring problem. But when I looked at what they were doing and how long it took, my honest reaction was: I could have done that in Sublime in a minute with multiple cursors, or just written a quick script

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)

iand675 1 day ago||
The problem with the article is that it's two arguments pretending to be one.

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.

gingerBill 1 day ago||
> Sublime is invisible to him because he's been at it for fifteen years.

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.

itchyouch 1 day ago|||
I think you hit on a point with git and sql I made in a different context.

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.

manithree 1 day ago||
I'm pretty sure he's just finding the most condescending way he can think of to "correct" people who have a lower tolerance for paper cuts than he has.

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?"

frizlab 1 day ago||
Sublime is a very good editor indeed.
laughing_mann 7 hours ago||
Newsflash: it’s 2026. Are you editing your assembly code using dinosaur era text editors?
robwwilliams 1 day ago||
Funny: This title is a classic statement of Martin Heidegger’s. Go programmers!
4ndrewl 1 day ago||
Invisibility is in the eye of the (un?)beholder.

I've used vim for decades. Tried using Sublime about 10? years ago. It just got in the way.

jshaqaw 1 day ago||
Obsessive hacker tools like Emacs are not a productivity enhancer. But If you find them fun go for it. You are allowed to have fun. You are allowed to enjoy your environment. If tinkering with Emacs is fun for you go for it. It's prob not replacing mental cycles for "productive" work. It's replacing zoning out with social media or YouTube between productive work times.

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.

gingerBill 1 day ago||
Which is kind of what I was arguing. Understand that having "fun" is not necessarily equivalent to being "productive". And even by an individuals own standards, the two can be completely different.

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.

computerfriend 1 day ago||
If my measured productivity decreases but my ability to find joy in what I do increases, it's probably worth it. Not to mention the second-order productivity boost that comes along with enjoying one's work.
sph 1 day ago|||
This is an objectively idiotic and uninformed take.

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.

jshaqaw 11 hours ago||
I spend my weekends enjoying life and my family but I guess that’s just part of my objectively idiotic take on life.
jibal 20 hours ago||
> Obsessive hacker tools like Emacs are not a productivity enhancer.

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.

CrociDB 23 hours ago|
This is the type of text that tells more about the person writing than what it's written about. It feels to me his defending so hard his views because he doesn't even believe in it, as if he needs validation. Like, of course there are people who thinks vim is better because of macros, but I'm pretty sure many (if not most) of vim users don't even use that. Vim's main selling point is that you can do _anything_ without a mouse. And it's very customizable. Now, you can be more productive with any tool you want than the average vim user. Heck, I'm pretty sure there's at least one person in the world that's more productive using Notepad++ than the average vim user.

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.

More comments...