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.

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

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.

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

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.

> 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 agree with the premise of the article.

For example I've been using Jujutsu exclusively (as a Git frontend) for years and I don't think about it, I just use it. I reflected on this couple of years. It's existence is completely transparent to me.

I, however, don't agree with sibling commenter that it's a function of time spent with X though. As a counter example: Emacs was my go to editor for 15+ years, last 2 years - because reasons - I was switching between Neovim, Helix, Emacs, Kakoune. 6 months ago I settled with Kakoune.

Even with many years in Emacs, I still tweaked and tuned it. There was always something to do, change, understand. I actively thought about Emacs.

With Kakoune after initial "set me up" phase, it's just as transparent as Jujutsu. Sure, I made complex plugins (for searching, highlighting unbalanced parenthesis and even a GUI wrapper called Kakvide). But the difference is that in Emacs the driver was the tool itself and in Kakoune it's always "I wonder if I can do X".

And so I believe that Kakoune is better tool than Emacs as it's more transparent to me even with a big time difference in usage.

GUI tools were better in the 90s when interfaces were more standardized, and I think the "invisibility" factor was a big part of it. I don't want to have to learn a company's whole design philosophy system because they thought building a packaged web app was "cooler" than using a standard widget toolkit. I find myself using the terminal more and more as time goes on, because I find the total friction to be less when things are predictable. I'd probably not have left the GUI world if we were all still using some modern equivalent of user32.dll.

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.

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

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

Only tangentially related, but this is why I gave up on fountain pens. They are cool and elegant, far too cool to be a practical tool for me. I realized this at one time I was in Bonn; I was thinking deeply about a problem as I was holding this wonderful Sailor Pro Gear in my hand. At some point it slipped, fell on the desk and bent the nib sideways, a total disaster. That broke my stream of thought and ruined my day. Nah. Tools need to cater to me, not vice versa.

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)

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.

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

I think this missed the emotional experience of using a tool.

My kitchen knives are decent knives, but no hand-forged Japanese masterpieces. Using them is a joy though, because I have an ingrained understanding of their ergonomics and how they cut.

I remember how clumsily I handled them at first. I take them to a sharpener regularly.

That experience of built-up familiarity puts me into a state of mind where I feel competent and joyful.

This is also true for my mechanical keyboard and some reference books I keep around my desk.

They are not necessarily the best possible tools, but they’re gateways to who I am at my best in different disciplines.

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

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.

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.

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.

Well said. I do get the appeal of a somewhat fiddly tool though. Tool gives you a little puzzle each day, then you solve it! A little puzzle solved/accomplishment a day keeps people sane. Plus I think it's just nice to feel like you really understand the tool you're using and know it's 'language' for lack of a better word.

I think I've fallen into the same camp of getting tired of things not 'just working' out of the box. Now I'm always happy to use something with less friction over more.

Would I like to use something with community plugins like VS Code and configure it to be exactly what I want? Sure. But everything where I work was designed for bigger editors like QTCreator and then VS - so that's what I use because it has the least friction with our workflow. Would I like to get the absolute best hi-fi music player application? Sure. But HQPlayer is a pain to learn and configure, so I just went with the far-more-user-friendly MusicBee.

Friction is fun when you're young and have time and energy to burn. Less so once work becomes part of the normal routine.

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.

A piano is not inherently a better musical instrument than a harmonica. You could argue that a piano is more complex and more puzzle like requiring more of an investment to learn for similar results.

A harmonica has a much lower barrier to entry and can be mastered over years of practice. So can a piano but with a lot more effort for more or less the same result. They both make music after all.

Ultimately, it comes down to familiarity and basic preferences. Pianos and harmonicas are basically the same if you've used them for long enough and you can get the same results with both (but a harmonica requires a lot less fuss and "games")

[I wish piano players would stop looking down on harmonica players - stop being so tribal!]

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.

There are people who get too fancy with vim, but it really is an invisible tool to many. Team around me changed IDEs multiple times and kept complaining about features changing, meanwhile I was using vim with some basic set of plugins like I've been doing for a decade, just works as always. Sublime is also a good invisible tool.

I don't care that vim looks "hacker" and has no GUI, but being able to run it via ssh is very convenient when dealing with remote machines, especially when your codebase isn't allowed to leave that.

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

> 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'm confused by this because I simultaneously agree with Bill by the examples given in the article; things like "ricing" Linux and Vim, but I also advertise Odin as being great due to this friction which may be seen as a limitation.

My favorite example is Odin's approach to metaprogramming and compile-time features. Odin is featureful in this regard, but not nearly to the extent that other languages are (D, Zig, Nim, C++, C) and it may have been the deciding reason I've written far more Odin than any of those other languages.

I _can't_ just do whatever I want at compile-time in Odin. That's a blessing for people like me. I toy with the compiler. I admire languages and language design, and toying with them, learning all of the features, is an expression of that interest. For Odin, there really aren't many novel features for you to toy with. It's just not a toy at all. I don't mean "toy" in then derogatory sense, or to designate others as such. I simply mean that Odin is just not fun to fiddle with, you use it to do something.

"The year of the Linux desktop still isn’t upon us (in 2026), and part of the reason why it has taken so long to get to that point is fundamental: a lot of the people who use Linux love fiddling with configuration files to reshape their system"

"part of the reason", yes, besides people's familiarity with Windows, it being pre-installed, Linux's splintered ecosystem in general, games, drivers for hardware, and so much more...

But what I want to contribute: LLMs like codex can be brilliant for custom setups, maybe not for the layman, but for the now lazy but previously-into-tuning your setup person with an itch remaining. For years I've not been wanting to tune my system, I have actual work to do. A few hours spent configuring a tool for small marginal gains is hours I could spend more productively.

Hence, Default Ubuntu with Gnome, good enough, let's do actual work. But I as I get to work more away from my desk setup (hence away from a docking station and external monitors) and more on my Laptop alone, I recently started to long for my i3 setup from years ago...

A few hours of prompting codex and I have sway set up w/ vim like keybindings, all the information I want in a task bar (I couldn't even tell you which, swaybar I think), a good launcher for applications that I like (it's graphically fancier than the simple default launchers for tiling wms), have kitty as terminal with awesome shortcuts for tab navigation, have bash aliases for saving and loading terminal sessions, no shortcuts (sway versus vim vs kitty) are in conflict, all overlap beautifully and make sense (different modifier keys, but same vim motion like fundamentals). I can simply pull the plug on my docking station or re-attach and everything keeps being fine.

So I have a custom setup, custom to me, that especially on a single screen makes me far more productive, setting it up is 10% the time it used to be, making changes in the future will be 10% it used to be, and I still a) leveraged the capabilities for customization and b) it being simple text based configs I can still leverage that going forward and c) have still the insight if needed (looking at the configs).

Codex on Linux in general feels like a super power. Due to the heavy text-based workflow Linux allows for, the Composability of terminal tools etc, I doubt working together with an LLM on setting up a system could work so well on any other system.

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.

“Good tools are invisible” is not an objectionable thing to claim, but the example used is confusing: a power user of vim presumably feels like their flows are invisible, just like the author feels like his Sublime patterns are invisible. It’s not clear at all that there’s any “good tool” quality to tease apart between the two.

(I say this as a long-time Sublime user.)

I find the best features, or mechanics in games too, are ones that fall out of greater architectural design. For example, if you've ever played popular hero shooter games like Overwatch, Marvel Rivals, or Paladins, they all have different physics engines; you can tell as you switch between the games. Which one's the "most correct" is up for personal interpretation, but they all try to grant the player affordances, abilities, and special 'tech' all while staying a simple engine for models and hitboxes to interact in.

Then there's coyote time and networking latency. All these little but meaningful details to consider on top of the base action of making a space for 'things to happen'.

When implementing a feature, I feel I'm always thinking back to when I'd get frustrated with the ways Paladins characters clip on walls more than in Overwatch, or the jarring air mobility difference between games like TF2 and the floaty feel found in the others already mentioned so far. I want the feature to feel like it could emerge as a result of the first natural instinct from play. Like when you enter a game world and you obviously know the keyboard and mouse 'control the world', so you start there and begin mapping your intuition of the experience. It starts with the surface visual communications. The HUD, the world itself, the buttons. Maybe your keyboard lights up and shows you what keys to press (chroma sdk for example). Then gets deeper as your experience grows. And the best features, ui, designs, games, etc. engage people who are curious enough to keep digging without enforcing the digging upon the average user.

One important thing falls out of a design philosophy like that. You never exclude a power user, and never baby a new user. It just... is the tool itself.

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.

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

I mostly agree with the points made, however I would not call this "invisible" as it was chosen to be called in the title.

Good tools should be obvious, with the main ways to use it being very low friction and low cognitive overhead. That is not the same as them being invisible. It is just a different type of visibility (one that doesn't require users to get a driving license before they can use the tool properly).

When I design such tools, I tend to think about the problem from the users perspective. What is the information they really need to know? In which environment does the rest of the context reside? Which error cases exist, who will have to deal with them and what will they need to know?

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

This is also true from the inverse. Making every tool visible may feel good to some users. They sit in their F16 cockpit, and they like having all those buttons, and knowing what they do.

But this does not scale. You can fit 100 buttons in front of you. You can learn each one and the best situations to use each. But can you fit 1000 buttons in front of you? No. Different humans have different complexity thresholds. Some humans can deal with 10 buttons, and some 250 buttons! But no human can deal with 2000 buttons. There exists a hard limit on tool complexity.

If you want your tool to be useful, then as you increase the number of different humans that sit in your cockpit, you naturally must lower the number of buttons in front of them. The tools must tend towards invisibility.

I agree with Odin creator here. I am not sure when or why we have come to a conclusion in our professional industry that "real software engineer uses vim/emacs/insert your CLI editor here" type of mental model. Is it just the testosterone level speaking here?

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

"invisible" is something I used to describe emacs magit. It's a thin layer over git output, it pops up, it infers parameters from ui state, call the usual git command, and goes out. Lean and fast (unless large project it seems).

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

This is a very interesting idea, partially because I recently wrote about how Svelte is kind of "invisible" as a tool for writing webapps (compared to f.ex. React). Much like gingerBill says here, when I use Svelte the tool "disappears into the background", at least for me.

Something I was hoping this would discuss is why do good tools feel invisible? But doesn't seem like it really went into that.

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

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

Finally someone put my thought on this topic into words! (Hopefully the author used a suitably invisible tool to write this.)

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.

I live with default wallpaper and default melody on my phone, so yep, having good defaults is fine. But in some huge products, you usually less then 10% features (and everyone is using different 10%), so it's nice to have ability to tweak things and make you need around.

The best tool has just a single button that has already been pressed for you. The mechanical action is there just for satisfaction.

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

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

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

I'm building

Inquir Compute - Function as a Service, https://inquir.org

and

Inquir Search - Search as a Service, https://search.inquir.org

considering pretty good services, use them almost on daily basis building some random staff

e.g. deployed

https://aleksandr-kubarskii-0931e2-hn-8439d2.inquir.org/

https://aleksandr-kubarskii-0931e2-psx-d82ded.inquir.org

https://aleksandr-kubarskii-0931e2-anime-42854a.inquir.org/

and some more

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

Look, I'm sorry to be that guy. But if you're struggling to bulk edit text in vim, you're definitely holding it wrong.

And emacs isn't even in the same category of tools, though I understand why one might think it is.

My retraction aside, I agree that the BEST software is the one you never really think about. Raycast is a great, recent example for me. Or perhaps Keyboard Maestro. It takes some fiddling to get set up, but then it just becomes a part of how I use my Mac. I only notice it when it breaks because my flow breaks.

"I want the defaults to be good and just work, and when I do need to tweak something minor, it should take seconds."

This is Apple's secret, its strange how so many people can't see this or why no ine has comprehensively replicated it.

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

word for word why softwares like herdr, haicue, ampcode is getting adopted for ai tooling where it is hot, although just because its cli bound it doesnt mean you cant have elaborate almost-gui text interfaces... lynx is a good example from past.

Vim is a bad example to use here. I certainly have no hacker-vibe pretensions, I use Xcode almost exclusively, but with the Vim key bindings which have been integrated very well. The productivity gains with Vim commands are impressive.

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

Progressive disclosure is a good framing. Sane defaults keep common workflows fast, while a well-designed escape hatch lets advanced users solve exceptional cases without making every screen noisy.

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.

Sublime is a very good editor indeed.

This is my mentality but when it comes to my company. I want to have clients for which I consistently produce solid work, no flash, no news headlines. Doing the work and quietly building a reputation.

i learned to code primarily from really old guys so i started on vim. i was forced to use vim because i was doing a lot of remote hpc work. now i like vim. use vim/tmux combo to improve my mouseless workflow. i just need a better way to look at all my files and pdfs without touching my mouse. i should try sublime as i cant have any real comparison between the two without having tried both. but i much prefer mouseless workflows.

An easy to learn UI is not without merit but neither is a complex UI with greater inherent flexibility.

I like old, analogue synthesisers. To pick two very famous examples:

I love the MiniMoog because it's very low friction.

https://en.wikipedia.org/wiki/Minimoog

It's a classic that's simple to learn and quick to get useful sounds. It's a funk bomb.

I prefer the Arp 2600 though (it's the voice of R2D2!).

https://en.wikipedia.org/wiki/ARP_2600

The 2600 makes it really easy to the block signal path so no sound gets out, which can be confusing. Once you learn it though it can do all kinds of tricks the MiniMoog can't.

An Arp 2600 can make two completely different sounds at the same time though and a MiniMoog can't. Bob Moog himself was a fan of the 2600.

Both are classics, still being copied to this day, but for different reasons.

Or to put it another way, a piano is harder to learn than a tambourine. That doesn't make either worse in the right circumstances.

> taking a tool’s shortcomings and reselling them as a “puzzle game” which is “fun” to solve

cough Perl cough

this reminds me of some programmers' blog where he talked about the line between when software does something helpful automatically for a user, vs the line of where it nags you to make decisions it could have made itself.

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.

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

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.

Solved problems are invisible.

The very first paragraph about macros taking a while is wrong. They are really useful and once in your muscle memory a near instantly accessible solution to small tedious tasks. This is true in Neovim and Emacs.

I also don't use these editors for identity. That is also dumb. I use them because it's fun and they are invisible tools once mastered.

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.

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

So that's why they are so hard to find!

I get the sentiment and agree with it but vim has multiple cursors. I'm sure gingerbill is aware of this so to use that example is a little strange.

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.

So, I think of articles like this that evaluate "software" or "tools" or the value of "coding" so often miss the huge point of "there are a lot of different kinds of software/tools."

It just depends on what you're DOING. It's all so very subjective. And I think the smart direction here would be for us to be clearer and force ourselves to be more specific when we begin to evaluate approaches like this.

Certain types of work NEED invisible tools. Other types of work NEED "legible" complexity. To say nothing of individual preferences.

I just don't see much value in sweeping generalizations like this article.

Newsflash: it’s 2026. Are you editing your assembly code using dinosaur era text editors?

*not true of hammers (jk, great post)

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

Skill issue.

100%

An invisible hammer would be more prone to land on your toe.

This is why LLMs are shit. They get between you and everything and turn it into a negotiation.

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.

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

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.

I only recently switched to emacs, and my motivation was not that I like tinkering but that having a flexible gui thing I can create custom views for w/ LLMs have basically 0 cost of producing new tools/uis. It's much the same with the linux example, I have been a lifelong windows user but switched around a year ago. I've tried multiple times in the past but hated tinkering and the issues that came up so never stuck with it. Now with LLMs I'm using a tiling wm and can just have a suite of hotkeys that automate everything I need to do, and if I ever want a new thing I can create the new view in a minute and never think about it again. The niceness in openness in tools is being about to integrate with everything else I use effortlessly. I wouldn't say invisibility the goal, but even further the idea of an isolated tool is an abstraction of the general human-computer interface. Your window manager is just as much a part of your ide or text editor as anything else, it's just the mediating layers between you and the program. From a phenomenological perspective the distinction between the different tools or piece of software is essentially arbitrary. Having more open tools that allow you to integrate with your WM and other things allows you to create that effortless, thoughtless experience. I would say a good tool is frictionless, not invisible. What constitutes frictionless for different people will obviously vary based on say how many different computers do you need to work on, what is the breadth of different kind of software and environments you need to work on? How do you control going between those? A frictionless code editor for me is not a code editor that is simple like sublime which in order to integrate with what I do I assume I could figure out some way to do it with a ton of custom scripting, but what is frictionless for me is what is open enough to allow me to go between a variety of different contexts without thinking about it, and being able to have whatever I want at hand without thinking about it. In the past I hate tinkering so much I would have never wanted to deal with this, and on windows particular it's practically not possible.

Just as an example of a frictionless tool, along with programming I also make music (including for some games I work on). When I was on windows to set up practicing playing music I had a preset in my daw I could open quickly, it would need to load then I could begin playing. On linux I just have something built into my taskbar with a performant amp sim and other audio thing always running so at any particular moment I can simply click something in my taskbar and immediately start using my guitar, mic, or analog synth I have set up on my computer. There's another menu to manage the mixing between channels, and things to run midi backing tracks I can practice to play along with. I could do this all on windows but doing each specific thing would require running something, making sure all my devices are still set up properly, using some other program whose UI I don't control to do something for me and just doing a bunch of different steps that impedes my ability to do this. Now I can just the moment I want to click something and it is immediately working with 0 frustration, it's a frictionless tool. I'm not just programming I'm also making music, games, assets for those games, and being able to leverage my WM/text editor to keep track of those things so I can cognitively offload them, and switch between them painlessly is to me the benefit of tooling. If I'm doing stuff with a team I can still leverage most of it but obviously the rest of the team isn't able to see the stuff I use to interact with it. The cost of creating small bespoke script/tooling/uis is essentially 0 now, and using AI to create bespoke tooling to me is a much safer approach than using AI to create code as it's just not really an issue if there's a bug in some of my personal scripts. I use odin for the game I am working on and I love it for it's simplicity and clarity, rather than using functions or programming language abstractions like classes to hide and organize functionality I just have some custom tooling for organize a mostly flat giant main game function. To me that's by far the least friction in understanding it and working on it. My main issue is across the projects I am working on, programming or otherwise, keeping things straight and coherent and being able to access and work with the associated files without thinking. Cognitively offloading to the greatest extent possible, so that what I do actually want to do is always at hand. I would say it's the opposite of invisibility though. (The psychoanalysis of what draws people to different editors is fairly boring and low effort, I absolutely hate tinkering. I am writing a game in Odin rather than using Godot because having to learn some poorly designed UI and how to futz around with it instead of just being able to do what I want is impossibly frustrating to me, it's a friction that locks me into future friction while the friction of learning emacs removed friction to other things)

[flagged]

[flagged]

[dead]

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

[dead]

[dead]

[dead]

[dead]

[dead]