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
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.
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)
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.
> 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.
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.
Every time there's a post here on git and red 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.
"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."
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.
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.
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
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
> 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.
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.
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
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 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.
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.
> 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."
The article topic is interesting, but the example it picks to illustrate deserve the purpose a bit. There isn’t any text editor that is really invisible. Dæmons/services are invisible. Copy-paste single clipboard is invisible. Switching displayed context is invisible.
Probably becoming skilled at using Sublime afterward become nice in some cases, but personally I never achieved the cumbersome of integrating multiple text pointers in my habits. In the rare occasion it feels like it might be useful, I know I will need to look at what are the keyboard dance moves again, and by the time I go search for it, my brain already generated several ready to go alternative paths to achieve the change. And I don’t even know if it can do things out of the box like `:grep pattern-to-select-buffer | g!:pattern-line-to-exclude:s:initial-string:target-string:g | update`. That’s already awesomely powerful for this level of granularity.
But that’s a rare case where to make the tool shine: most editor deal with full literal substitution just as well (if not better in term of UI), more complex refactors will be better dealt with with whatever decent modern IDE, and whatever more cases that want would want to cover using some more advanced macro is probably going to be just as easy to deal with a bespoke script.
Also Sublime is not everywhere. Nor is Vim or Emacs to be clear (as soon as you are outside of a Unix lineaged box). Though probably if one need to ssh in some remote box `vi` will most likely be an option, even busybox integrate one. But we are no longer talking about whole contemporary project edition here of course.
Still the underlying point is nice to highlight, melting it with editor war didn’t make it a favor.
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.
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.
What is a good tool that's invisible? I'm genuinely curious. All tools I've used are either simple and heavily limited (so, not "invisible" because hard things are hard) or powerful but heavily specialized (so, not "invisible" because the learning curve is very evident). I feel the trade off is inescapable.
More often than not, good people too. And there are a lot of them. But a single unrepresentative person yelling in the room is all it takes to break stillness of quiet exchanges.
This is truly a high-quality post. I completely agree with it.
Workflow is tied to one's identity.
Regarding the discussion about Linux desktops in this post, I think the reason Linux lacks popularity as an desk operating system is that programmers want their computers to be not a 'product' but their own personal tool. So rather than preferring a unified system, they tend to want more freedom to modify the OS themselves.
In other words, this is about system customizability, and about 14 years ago, Linus Torvalds made a similar point [1].
Personally, I think the TUI vs GUI debate simply depends on the domain you belong to. Those focused on OS or open source work face pressure to become familiar with TUI, while programmers like me who deliver software to factories face pressure toward GUI. The people I deliver to almost always ask for the same thing: 'Make it understandable without reading the manual.'
On the other hand, most of the TUI and low-level work I've encountered has been dominated by the 'Read The Fucking Manual' culture.
I think people see the pros and cons of their environment depending on where they place their identity. I'm a programmer, but honestly, I don't really enjoy looking at a terminal. I look at the logical structure of my code and the logs when it runs, but I'm not really comfortable with the terminal. But the typical end users I deliver to are even less comfortable with terminals than I am. So I don't particularly like terminal culture or memorizing long command strings. They're just more used to clicking buttons.
The problem is that the products we develop don't just stay with developers—they also need to be accessible to ordinary consumers. Of course, those who build tools for developers might not think that way, but I believe that even ordinary consumers should be able to easily operate the software
Others, of course, think differently. In the end, as the author of this post said, it's a matter of identity.
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
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.
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)
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.
> 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.
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.
Great article.
Every time there's a post here on git and red 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.
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
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.
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.
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
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
> 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.
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.
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
Good Editors are Invisible would make more sense. I think this only applies to the class of tools we would call "controllers"
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 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.
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.
> 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.
Funny: This title is a classic statement of Martin Heidegger’s. Go programmers!
Sublime is a very good editor indeed.
People use vim because they want to use vim, not because people tell them to use it.
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."
The article topic is interesting, but the example it picks to illustrate deserve the purpose a bit. There isn’t any text editor that is really invisible. Dæmons/services are invisible. Copy-paste single clipboard is invisible. Switching displayed context is invisible.
Probably becoming skilled at using Sublime afterward become nice in some cases, but personally I never achieved the cumbersome of integrating multiple text pointers in my habits. In the rare occasion it feels like it might be useful, I know I will need to look at what are the keyboard dance moves again, and by the time I go search for it, my brain already generated several ready to go alternative paths to achieve the change. And I don’t even know if it can do things out of the box like `:grep pattern-to-select-buffer | g!:pattern-line-to-exclude:s:initial-string:target-string:g | update`. That’s already awesomely powerful for this level of granularity.
But that’s a rare case where to make the tool shine: most editor deal with full literal substitution just as well (if not better in term of UI), more complex refactors will be better dealt with with whatever decent modern IDE, and whatever more cases that want would want to cover using some more advanced macro is probably going to be just as easy to deal with a bespoke script.
Also Sublime is not everywhere. Nor is Vim or Emacs to be clear (as soon as you are outside of a Unix lineaged box). Though probably if one need to ssh in some remote box `vi` will most likely be an option, even busybox integrate one. But we are no longer talking about whole contemporary project edition here of course.
Still the underlying point is nice to highlight, melting it with editor war didn’t make it a favor.
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"
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.
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.
What is a good tool that's invisible? I'm genuinely curious. All tools I've used are either simple and heavily limited (so, not "invisible" because hard things are hard) or powerful but heavily specialized (so, not "invisible" because the learning curve is very evident). I feel the trade off is inescapable.
Yeah, I'm so sick of hearing "it's way faster to install app on linux by using terminal than using that bloated gui softare center".
This is why LLMs are shit. They get between you and everything and turn it into a negotiation.
An invisible hammer would be more prone to land on your toe.
More often than not, good people too. And there are a lot of them. But a single unrepresentative person yelling in the room is all it takes to break stillness of quiet exchanges.
This is truly a high-quality post. I completely agree with it.
Workflow is tied to one's identity.
Regarding the discussion about Linux desktops in this post, I think the reason Linux lacks popularity as an desk operating system is that programmers want their computers to be not a 'product' but their own personal tool. So rather than preferring a unified system, they tend to want more freedom to modify the OS themselves.
In other words, this is about system customizability, and about 14 years ago, Linus Torvalds made a similar point [1].
Personally, I think the TUI vs GUI debate simply depends on the domain you belong to. Those focused on OS or open source work face pressure to become familiar with TUI, while programmers like me who deliver software to factories face pressure toward GUI. The people I deliver to almost always ask for the same thing: 'Make it understandable without reading the manual.'
On the other hand, most of the TUI and low-level work I've encountered has been dominated by the 'Read The Fucking Manual' culture.
I think people see the pros and cons of their environment depending on where they place their identity. I'm a programmer, but honestly, I don't really enjoy looking at a terminal. I look at the logical structure of my code and the logs when it runs, but I'm not really comfortable with the terminal. But the typical end users I deliver to are even less comfortable with terminals than I am. So I don't particularly like terminal culture or memorizing long command strings. They're just more used to clicking buttons. The problem is that the products we develop don't just stay with developers—they also need to be accessible to ordinary consumers. Of course, those who build tools for developers might not think that way, but I believe that even ordinary consumers should be able to easily operate the software
Others, of course, think differently. In the end, as the author of this post said, it's a matter of identity.
[1] https://www.youtube.com/watch?v=ZPUk1yNVeEI