Good Tools Are Invisible

Having designed a good number of internal tools for teams of developers I couldn't agree more.

Earlier I had the tendency to "leave the guts" open, thinking my users were developers and would want that. All it did was put obstacles in my teammates actually doing their work. My teammates must use the tools I made for them to achieve work the company needs them to do, they don't want, nor should they want to, fiddle with a little tool they won't find anywhere else.

I still leave a lot of escape hatches, but I try to design the internal tools in such way as to make the users fall into a pit of success.

Edit: also, error messages, error messages, error messages and auto suggestions for common errors

Edit 2: also the number of people only addressing the examples in the post rather than the spirit of the post is... disappointing.

As a long time terminal user, it does not surprise me much when people just don't get it. The discussion often goes like this:

— In a terminal, I can do so-and-so with a simple command

— Well, in my FrobnicatorStudio, there's a shortcut Ctrl+Alt+So for that

and this can go forever, going into pretty much useless comparisons like "in vim, I can delete 24 lines by pressing four keys" (no Sublime user ever needs that) vs "in Sublime I have multiple cursors" (no vim user ever needs that either).

The proper argument here, probably, is this one: the terminal, with its way of combining small CLI tools into pipelines, covers infinitely many use cases, but indeed has a learning curve, taking probably a year or so to become really comfortable. When you reach that point, you will be, on average, much more productive than an average GUI user, but it requires some dedication, pain, and suffering to reach that point, and people often do it involuntarily.

In my case, my first job required managing customers' servers over ssh, those servers had bare minimum installed (often vi, not vim), and I had no choice other than figuring out how to do things effectively in this setup. If not for that experience, I'm not sure I would've gone through the pain of starting doing things in the terminal.

The effect of the interface becoming "invisible" is actually a function of time spent in the interface. I think what the author is reacting to is discretionary friction; designers or product folks adding features or complexity. The thing is, that friction may be necessary in order to achieve a certain task (think about resolving a merge conflict). And given enough time in the interface, even those "disruptive" steps fade into the background.

To give a concrete example, the console of a 737 is incredibly dense with controls. The airplane itself has many different modes, and there are many moments of intentional friction.

However, if you interview a pilot with 10+ years in a 737, they will tell you the interface has become invisible.

The same goes for the supposedly "bad" Bloomberg terminal. You'll find the same thing in Healthcare, where an interface cluttered with buttons is exactly the right solution for someone who spends 8+ hours/day in a MR scanning software and wants instant access to all the controls.

As programmers, I think we're too quick to generalize our own experience and preferences and try to apply them to others.

Source: I spent 10 years designing consumer and professional software at IDEO

> usually because they don’t realize how much more productive keyboard navigation is than reaching for the mouse a lot of the time.

In a large number of cases people who say they are more productive have never measured it. They have no idea if it is true. There are been many competitions between keyboard and mouse navigation over the years. Depending on the details of how the test is written one will win or the other, often by a significant amount, in many cases the loser is the one that user said was more productive before seeing the real results.

I would also say good tools have better "physics" they've got some coherent internal model that is somewhat easy to intuit about.

I completely agree that the author is right and the strawman is wrong.

For example. The strawman criticizes GUI apps because he cannot navigate them with the keyboard alone. Keyboard-navigated TUIs are the worst type of UI.

CLI > GUI > TUI.

I don't like interactive tools because they're not scriptable. I don't care about keyboard vs mouse per se.

I don't like having to use different tools for the same job depending on if it's local or over SSH, so I prefer non-GUI tools in general. I want to have the same workflow for checking the processes running on a server and on a desktop. So htop it is, even though it's a TUI.

In my experience, actual GUI and TUI applications tend to suck compared to CLI tools. Tend to. The strawman seems to think that somehow this makes that whole class of UI inherently bad, so once again, I couldn't agree more that he's wrong. Then again, I care about the actual experience, not about whether it's inherent or incidental.

Somebody wanted you to try their favorite tool, so they showed you how easy it is to do weird things in it. That doesn't mean they're using it because they can do puzzles!

If you're a programmer, you enjoy being able to get most of your editing done in your editor without going into the menus and digging for a feature, or searching a store for a plugin that allows you to do that. Of course if you have used your editor for years, and you know all the menus, shortcut keys, and have all the necessary plugins added, then you're fine!

Vim or Emacs allow you to learn some fundamental small tools and mix them to get your job done. Sublime and others allow you to find exact tools for those jobs that others put together. At the end, 10 years later, they're the same.

You're not better. They're not better.

A corollary to this I've experienced (and observed in many others) is that maintainers of good tools will very often have a much more negative perception of how users collectively view their tool than how they view it in reality. It can be hard to tell the difference between "10 users complained to me today about bugs/missing features and 9990 used it without issue" and "10 users complained to me today about bugs/missing features and 90 used it without issue", despite there being a huge amount of effort needed to go from having 90% user satisfaction and 99.9%.

I have a strong suspicion that this is a major factor in why so many open source maintainers experience burnout; the unhappy users are going to be more visible than the happy ones, and the fraction unhappy new users needed to produce the same volume of bug reports/feature requests goes down with respect the to rate at which new people start using something. This essentially creates an illusion to the maintainer that no matter how much they work to improve things, nothing they do has made a difference in the overall quality of what people experience, and that saps the motivation to keep going.

I don't really have a good solution to this problem. The only obvious answer is to be more vocal with praise when something works well, but that's the type of collective action problem that tends to not really ever happen in reality. I've personally tried to go out of my way to give frequent and enthusiastic positive feedback when something works well for me, but unless everyone starts doing this, I'm not going to be able to make too much of a difference.

I am afraid the author confuses familiarity with proof that his tools are better. The reality is that every tool has a trade off, and if a user prefers tool X compared to tool Y, it’s not because they are dumb, but likely they make better use of the affordances of that tool that only a power user would get.

Give a developer 10 years each with vim, emacs and Sublime Text, they wouldn’t be so sure which is better. [1] They might have a personal favourite, sure, but would also be able to tell why other people prefer other tools.

I am afraid this is one of those arguments borne of ignorance whereby one is has never given a proper chance to software they are unfamiliar with.

1: to me the mark of a greybeard that has been around a while is a vague dislike of every software and any promise of improving such software. In the long run, every piece of software tends towards mediocrity.

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.

This has traditionally been one of the points of attraction for the Mac desktop. It has a higher than average number of native applications which conform to platform conventions and are specifically designed to not stand out.

The best apps there acknowledge that they’re just one of a wide variety of tools the users reaches for regularly and avoid the hubris that comes with use of UI as brand identity. They don’t try to hog the user’s attention, vie for mindshare, or unnecessarily force the user to learn new or foreign UI patterns. They try their best to avoid saddling the user with any kind of unpleasant surprise (even if that’s just ensuring that common interactions work as expected) and they just sit quietly in the background until needed, serve the user’s purpose, and recede again.

EDIT: a lot of it comes down to small things which compound. For example, native tree views on macOS (NSOutlineView) expand/collapse entire subtrees when the user Option-clicks a disclosure arrow. This can save a ton of time and I die inside a little every time foreign toolkit apps don’t implement it.

> The clearest sign a tool is serving you is that you stop noticing it—it becomes invisible. You don’t celebrate its flaws because you’re not turning them into a hobby, rather you just get mildly annoyed and route around them.

I think this is more dependent on the user than on the tool. Surely, different tools will attract different users and we can probably measure strong correlation.

I also think this position lacks balance. Your tool is never perfect, sometimes you realize you could improve it, and you should balance implementing the change with the effect it'd have on your habits. Sure, the longer you use your tool, the smaller those changes are, but your usage evolves throughout your life, and it's only natural that your tools do so to.

Reminds me of this quote:

"We notice the person who is for ever bowing and fussily servile, and perhaps say, How humble he is! But the truly humble person escapes notice: the world does not know him."

~ Tito Colliander

Great article.

Every time there's a post here on git and I read the comments, I keep thinking of all the years I've used fossil and how it's been completely invisible, in the background, letting me get ahead with my work.

I'd like to pick on the word 'invisible': if the user can get into a flow state with a tool where work becomes the major focus. I can argue that you can get into that state with any tool with enough practice. And sometimes that's only possible if the tool is actually visible to you as in all graphical UI bits you need are exactly where you remember them to be, exactly where your motor reflexes immediately seek and find.

So regarding proficiency. I bet you weren't as proficient with multiple cursors and all the things you can do with it when you first used it. (15 years is a long time to remember how it all started.) I could argue that all the key shortcuts and other bits you need to make multiple cursors work effectively doesn't come to everyone instantly. But with time you could and would hit that level.

Overall tho, vim is an interesting comparison to make also because sublime text also has a 'vintage mode'. I personally use it with vim shortcuts enabled. it lets me use vim motions on top of everything sublime offers. Does sublime + vim make it more 'invisible' to me than it is to you?

I generally have issues with arguments like this. It starts with a sexy phrase that projects some earned wisdom but then the rest of the supporting arguments are forced into the narrative most of the time by selectively ignoring important information. You could have just said I love sublime and I prefer it over vim because of this and that. or it could have been a direct critique of linux desktop. they would all stand on their own, even better I would argue, without being shoehorned into an overarching, simple, catchy phrase.

Invisible work doesnt lead to promotion, hence FAANG companies stopped making invisible+good tools, if things are invisible they get deprecated or stay in KTLO and eventually die

> The clearest sign a tool is serving you is that you stop noticing it—it becomes invisible.

It is because you are already very familiar with and accustomed to this tool.

The main meaning of the author probably is (from one article):

We need to remember that the purpose of using tools is to solve specific problems and achieve goals.

No tool is perfect. When using the useful functions of a tool, we also need to tolerate or ignore some of its shortcomings. Don't seek out or switch to a new tool simply because of some insignificant flaws. In the process of selecting and using tools, don't have the perfectionism, and always keep the goal in mind. The important thing is to master the useful functions of the tools to quickly, effectively, and efficiently complete tasks or goals, thereby significantly improving efficiency and productivity, rather than constantly complaining, switching tools, and wasting time and energy.

For the tools we choose, one must become truly familiar with and proficient in their use, continuously customize, modify, and improve them, and strive to use them to the fullest extent, thereby significantly improving efficiency and productivity, and solving practical problems and achieving goals faster and better.

I'm not sure about this.

One of my favorite tools is my bicycle. To me, the user interface of my bicycle is totally invisible. I just pull it out of the garage, hop on, and away I go. And it's not like I enjoy my bicycle as a "puzzle" either -- I just want it to go somewhere.

But to my 6 year old, the user interface is quite literally fear-inducing. Everything about the tool is very "visible" to him. Does that make it a bad tool?

Interesting how all of grep, sed, ls, cp, mv, rm, cat, pwd, chmod etc are well over 50 years old and get used more than ever today. Claude code owes at least some of its success to the well established and solid unix toolchain

The Linux on the desktop one was the biggest “hell, yeah” moment for me. 99% of the desktop preference is familiarity. Since my personal computing has been on a Mac exclusively for the last 24 years and I’ve not used Windows for work more recently than 2018 (and it was sporadically the case in the decade before that), when I do use Windows, it feels like I’m typing in molasses. A Linux desktop feels like I’m typing in molasses with casts on both hands. That the desktop varies depending on the distro and whoever decided on the defaults makes it that much worse.

Meanwhile, I largely use a vanilla setup in MacOS. The only changes in the UI I make beyond the default are installing rectangle and flycut, switching the default keyboard to ABC-Extended and turning off caps lock. Everything else runs with default settings and I’m happier for it, especially when I need to do something on someone else’s machine. Losing those minor customizations doesn’t make the machine unusable or introduce too much friction.

Well this is a take.

It’s weird how much the author fixates on Vim being “visible” and implies multiple cursors and features in Sublime aren’t. Just because your brain is trained to not think about it anymore doesn’t make it any less visible.

Multiple cursors aren’t a native feature in many tools, it is still something to learn how to use, let alone effectively — just as Vim key bindings are. Plus, vim is more than just a TUI choice for terminal-only users, it’s key bindings for people that have learned that a keyboard is a natural extension of themselves and would rather not jump back and forth to mice repeatedly — just as “multiple cursors” can be to a sublime user of 15 years.

Do people have fun building vim macros? Vim macros are awesome because they don't involve reading manuals, memorizing obtuse key commands which you never use on a regular basis, or understanding weird configuration lines - you just use the editor the way you normally would except you're hitting record. Vim's power is that I can be editing, notice I don't have something, make it in 2 minutes, and then get back to more normal work. At least try to understand the thing first before criticizing it?

Running tests is a good example: do you want to run them from your IDE or do you want to run tests in the terminal?

The IDE folks praise the simplicity of having one tool which can run tests quickly without requiring added context and with having other IDE features able to load test context quickly.

The terminal folks praise the modularity, at-will configuration, and transparency. You do things the way the rest of the community does which makes it easier to get support and debug when things go wrong. Tests become a small tool you can reuse in other contexts (git bisect, watch commands, CI)

Premise makes a ton of sense. Having had a chance to build my own tools for myself, I buy this a lot. Some additional notes here: https://backstory-production-ef74.up.railway.app/b/2xxrr6?ne...

I like TUIs because I can pipe the output of CLIs directly into them, and I don't have to leave my terminal environment. GUIs can't compete with that.

You see this a lot with beginners, because until you’ve done the work long enough to truly know what works, you only really know what you have seen through other people’s performance of the work (to the degree it is even understandable and perceptible to you). Also your social circle is probably mostly other beginners or more experienced people who are evaluating you in terms of basic competency/understanding as someone who knows more than a guy off the street who wants to be or claims to be capable of something.

So the costly/difficult-to-fake signaling of competency through complex setups, or tool fluency, has very high personal value because it positions you as someone who is interested and capable of learning about this stuff. And if you don’t have any real work to do yet, or even know what it is all the work is actually done for, it’s the most obvious place to start.

Once you understand this you can start to understand how developer tools marketing actually works, and why “this completely eliminated that problem entirely!” is NOT what developers get excited about paying for or using unless it’s something they/their social peers don’t value. Conversely, if you create a vessel for them to participate in some kind of social trend/signaling game within their social world it stops mattering as much or not it’s more productive or doesn’t actually save any time.

This applies in almost all social systems, if you’re interested in learning more about it some good terms are “costly signaling”, “mechanism design”, and animal psychology. Just don’t let yourself think you’re too smart to do it yourself - it’s inherent to the act of socializing, so anytime you’re doing that, your perceptible behavioral signals are going to affect the outcome, whether you like it or not

Good Editors are Invisible would make more sense. I think this only applies to the class of tools we would call "controllers"

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.

I was once in a meeting with a guy for a specific purpose and he wasted about 10 minutes lecturing me on why he uses vim, I had no issue with it but honestly that entire world is absurd to me, do what you want as long as it works for you

People use vim because they want to use vim, not because people tell them to use it.

I think of "invisibility" as a way of removing unnecessary friction and the author doesn't quite drive home that point effectively.

Good invisibility is like well designed roads. Smooth, clear markings, adequately wide or narrow for the desired speed, easy and obvious signs. Unbothersome and pleasant. Drivers simply drive, rather than get bothered by, "gotta avoid the pothole. Here's comes the bumpy part. That blindspot, I gotta slow down for way too much. Unseen pedestrians pop out here."

This is where invisibility in interstate highway regulations are obvious.

When I see TUI vs GUI comparisons, it distills to friction for a given context/workflow.

I worked in a restaurant with a micros system. It was a very easy to use GUI that was touch screen button driven. A 1 person order could easily be entered in 6-7 button pushes in 2-3 seconds to a seasoned operator: drink > coke > dish > steak > medium > a1 > submit

The beauty with micros was that it reduced the typical navigate > select > add > back-to-navigate workflow into 1-2 button presses with a receipt-like tally providing immediate state feedback.

In this scenario, telling a user to get into a terminal console and type "cd Foo; ./add ketchup" would violate the invisibility principle. It has nothing to do with TUI or GUI.

To me, good tools get out of the way, in the given context. Micros did that.

CLI users are in a CLI flow, thus introducing a mouse to a keyboard workflow violates the invisibility workflow. But for a GUI user to hit up the terminal violates their flow.

Ultimately, all workflows are in search of a faster/less-toilsome feedback loop to the desired goal and tools are in service to the loop. Well designed tools with rabid followings understand through usage where to add friction, and where to cut toil and I'd argue this is where CLIs shine with decades of refinement of the same tool chain.

GUIs are a, it depends on how composable or self contained the given problem for a GUI interface is.

But yes, tools should be invisible. How they become invisible depends.

Huh? Facebook mindless scrolling for drones?

Don’t agree especially with Vim. There are tools you have to learn first to use them properly not to harm yourself.

Author picked wrong analogy.

It is like nagging that excavator has some leavers instead of steering wheel.

Someone nagging they can’t quit Vim is far from Vim being example of bad tool.

Year of Linux on desktop is there as most of games actually run on Linux now thanks to Steam and SteamDeck.

> What baffles me is that so many people treat that friction—the effort of working around a tool’s limitations—as the “fun” part, and then advertise it as evidence that the tool is great.

I think it’s fine if that’s your hobby, but I agree that in a professional context one should be much more critical of their tools. Even asking “why do I need a tool for this at all?” will reveal shortcomings in processes, data structures or other tools that will reap much greater rewards if effort is put into fixing those instead of optimizing use of a quirky tool.

*not true of hammers (jk, great post)

I rarely use vi{,m} these days but I sometimes still instinctively type motions or :commands into other terminal editors (which naturally blurts them out into the text buffer). When using something like Sublime or VSCode, I'm always hunting through menus, documentation and search engines to do something simple like ":%!sort -u". Kate is a bit unwieldy—far from invisible—but I've found it to be the most frictionless editor on the market by a wide margin.

I have a methodological explanation why good tools are invisible. Explained it here: https://nextmovetheory.com/library/the-nature-of-product/epi...

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

> 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)

Keybooard and Mouse. Everytime. I have the same question.

How much do you type in a day that moving the hand to the mouse is a productivity loss? I spend a lot of time staring (thinking, planning) than typing. So, moving my hand to the mouse and back barely has any impact.

I think this article might miss the point that tools like vim often have a much higher ceiling than the transparent or conventional alternative. You get good at the puzzle part of it (which goes along with any craft), and you are able to do things faster than your former self could have conceived.

I remember coming up as a programmer and seeing someone who was truly excellent at using their text editor making large sets of changes that would have taken me double or triple the time and having this feeling of, "ohhh that's the payout."

Sublime is a very good editor indeed.

Funny: This title is a classic statement of Martin Heidegger’s. Go programmers!

Agree that good tool should be invisible. We want essential not accidental complexity in how the tool works.

But good tool should also be fun and makes us feel productive. We can't neglect the emotional aspects of designs. And at the end of the day, if a less productive tool makes us much happier, we will less likely be burned out. That is productivity in the long term.

Maybe only AI Agent doesn't care about the emotional aspects fro tool use, but that's a separate topic.

Also, it's not about steep learning curves. We want low floor, high ceiling tools. Some of the examples the author used are either low floor low ceiling, or high floor high ceiling. Neither is ideal.

Well that’s a lot of platitudes for such a short post…

Skill issue.

There was an old blog post comparing pianos to text editors.

A "simpler" piano would only have white keys, but to a piano expert the piano appears invisible (and powerful) after the initial learning curve.

I think an important attribute of mastery is related to consistency over time. Microsoft Word '95 vs 2007 (the ribbon) is a great example.

Mostly MS's keyboard shortcuts have been consistent (Alt-F4, Ctrl-B, Alt-F-S), but their UI has been inconsistent (making mastery harder).

In any case: "tools for experts may seem initially awkward to non-experts"

...and: "initially non-awkward tools may hamper capabilities as the operator skill increases"

I know the link is by the creator of Odin, but I can speak personally for my passion for seamless tools. I have ever had as seamless, high-flow of a development environment as I do now using Nim with Sublime on Mint at work. Every one of these tools is intended to slide out of the way of your thoughts, and they do so deftly. I'm never fighting the tools; instead, the tools are facilitating me transforming my thoughts into compiled programs. All of my time and energy is spent formulating a sound model rather than fiddling with configs or fighting obtuse features.

Solved problems are invisible.

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.