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.
For example, I am a HUGE fan of the way Gusto handles payroll and all the different taxes and form filing for me, because I basically do not even have to think about the problem or fiddle with it at all. But to someone whose job is doing payroll/accounting/taxes or working within giant enterprise HR/legal/finance departments that does more harm than good, because it’s something they have to fight (or less charitably it makes their job too simple).
The other big problem is who is actually making the decision to pay or spend money on a thing, and whether it serves more of a defensive (eg auditability, security, constraints against undesirable behavior) or creative purpose. The creative stuff is sexier but hard to quantify, and end-users won’t actually be willing to pay that much for it relative to how much it helps them or how critical it is to their role.
Unfortunately there is still a thing to balance against, which is forcing people to do the right thing.
There always will be bunch of people who nag about being impeded by doing something correctly, because they feel it is waste of time.
From an org perspective the goal is to create the highest curve of performance over the lifetime engagement of the employee or from the employee perspective their career.
And a lot of that depends on teh relationship of the people involved. From my perspective its a net negative when if my movers worked out the day before, their muscles will be sore and they'll do a worse or slower job. From the moving companies perspective its good, they'll be stronger for more jobs. Unless they quit or are fired that day, in which case we're back to bad.
The real evaluation isn't the macro vs the sublime edit. its does the thought process of making them macro improve them in other things, and what were they doing before that. In my experience no one is going use the time they spent writing a macro or a learning vim to do real meaningful work, they're doing that because they're bored or burned out and want to think about something else they find fun at the time.
your problem isn't your employees choose to write random scripts, its that they dont have a sense of urgency or care about their current task.
I don't have anything else to add but I thought this was a wonderfully evocative phrase.
I spent entire year trying to explain to my manager "most devs who create services want a simple deploy button". Instead, we tried to teach devs how our "infrastructure as a code" works so that they'd contribute. The effect was that only one guy engaged with us this way, and he always sent us AI-generated PRs, and every time he saw an error, he just copy-pasted it to ChatGPT without reading and then the answer back to me.
The project eventually shifted towards my original idea, but in an extremely painful way without any design at all. It's just a toolbox of completely random features glued together because one day manager says "no we don't need to support X" and two months later a Jira ticket "add support of X".
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.
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
This is far more precise. The article talks about this from the users side, how there is a class of user who enjoys learning all of these “extra” features, even though they ultimately provide less value than the core features.
>> If people find vim, emacs, or whatever genuinely good and productive, I’m not going to criticize them for using it. People are most comfortable with what they know. But for the people I am discussing, that same familiarity blinds them to their tools’ flaws, and leads them to celebrate those flaws, flaunting them as games.
— 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.
By a CLI app (with the emphasis on command line) I mean something like grep, sort, cp, git, ls, tar, etc. The normal way of interacting with these is by writing commands on the shell, which means that if you know how to use it normally, you can also use it in a script. Which means that you can combine these into pipelines.
By a TUI app I mean (and I think the article means) something like Vim, Emacs, Tmux, Lynx, Tig, Midnight Commander, Claude Code, etc. - an interactive app that takes over your terminal while you're using it. You're not going to compose those into a pipeline. Or to be more precise, you're not going to use them in pipeline by using them the way you normally use them. If you can use them, it's probably because the app decided to provide a command-line interface in addition to the TUI.
...but not Midnight Commander: it's an outlier in your list, a tool that actively prevents you from learning the way how things work in terminal. Same for all attempts to invent a UI for git.
That being said, it's a hard sell. It's not easy to grok the simplicity of the commandline tools until you've used them to solve what would otherwise be an intractable problem.
But I still use the command line heavily in all my work. I usually have a konsole window that I alt+tab into whenever I need to build or run tests, instead of using Sublime's "build system" support. The only time I use vim is when I need to ssh, or am using Termux on my phone.
> 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,
Extensible GUI tools (Sublime, VSCode, etc) cover infinitely many use cases too, except they offer more reliable and reproducible runtime environments.
I think the reason these types of discussions never die is because people in general tend towards closed mindedness. It's hard to put yourself in other people's shoes, and even harder to entertain the possibility that you're wrong.
But at the end of the day this only matters for novices. After enough experience with them, no matter what you use, your productivity bottleneck isn't going to be your tools (unless its ed...).
Also thanks confirming the multiple cursor YAGNI for vim, could never wrap my head around needing it in the first place.
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.
For me, using my mouse while I'm working feels natural, so trying to change my workflow to learn how to navigate everything by keyboard would be a huge amount of extra effort just to maybe possibly save a little bit of time in some situations.
Again, there is no universal correct answer. Sometimes the keyboard really is better. However sometimes the mouse really is better and because I'm proficient in it I don't break my flow to use it.
By this logic a person who were comfortable with mouse should never grow to like VIM.
> there is no "natural" or "intuitive" way to operate a computer.
Fundamentally a computer is something that execute instructions. It is pretty poor interface to pick instructions from 100 options using a mouse as opposed to type it using a keyboard. A mouse hides the power of the computer behind a set of fixed clickable options. That is a pretty poor interface.
Quite the opposite, my argument is that habits are changeable.
> Fundamentally a computer is something that execute instructions. It is pretty poor interface to pick instructions from 100 options using a mouse as opposed to type it using a keyboard. A mouse hides the power of the computer behind a set of fixed clickable options. That is a pretty poor interface.
You continue to argue for my point. OP was claiming that measured efficiency does not matter because it's about "flow". I argue that one can teach oneself to flow differently, the commands can be learned.
Your argument is sound but this overstates your case a bit. There's a reason we don't type with our toes.
All of this brings me to my questions: Why do you reject measuring how good an interface is? Or given your dismay over keyboard based workflows, why do you think they would win most of the time?
I'd wager that if actually tested, in only a few scenarios the keyboard would win, while hybrids (with both mouse and keyboard input) perform best for most people.
For tools that are mainly for non-text visual information, then the keyboard versus mouse debate is much more heavily weighted in favor of the mouse. Even then, there are times when effective keyboard shortcuts are far more useful than menus and icons. Take any CAD or 3d modeling software as an example. 90% of what a user does will be interacting with visually-presented spatial data, but even then knowing the shortcuts for changing tools or modifying a tool's settings will make you much faster and remove the need to constantly navigate nested menus of options.
What I take issue is with tools that make them hard to use with low contrast between widgets or shortcuts that does not work if a text input is focused. Also tools that forget they have a primary usage and wants me to know everything at once (notifications, big action buttons, guided tours and what not).
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 can take his entire thesis and use it to show that vim is the perfect editor for me precisely because vim is invisible to me when I use it. In part this is because I turned vim into the tool I wanted. He turned sublime into the tool he wanted. His basic point however still stands. If you are making something for someone else to use then making that tool invisible to them is a powerful property.
Alternative view: Maybe that's okay, and greybeards know that.
Mediocre: "something of only moderate or ordinary quality"
Maybe we don't need the latest and greatest extraordinary technology when coding our next CRUD app.
Literally NOT what I was implying or even said anywhere. Quote me where I said anything like that.
To quote myself:
> 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.
This has nothing to do with why I or another person one tool over another, but rather treating the flaws as if they are things to have a puzzle game to work around.
People don't use Linux because they enjoy tweaking config files and everybody else has too busy a life to do that. That's a silly misconception and veiled attempt at feeling superior at those time-wasters.
> rather treating the flaws as if they are things to have a puzzle game to work around
Case in point.
Good tools are indeed invisible, but the arguments the article is built on are very shaky and honestly just sound from someone that didn't spend much time with other tools, but still has strong opinions about them.
I didn't say that either nor even imply it, and you know that when you quote me afterwards. So huh?!?!
> People don't use Linux because they enjoy tweaking config files and everybody else has too busy a life to do that.
A lot of people, including younger myself, got into Linux and Android BECAUSE it was configurable and customizable. And even played around with all of the customizations because it was fun to do. But it didn't really make my general experience better because I was forever trying to correct something I should have to correct in the first place.
I am not sure how much clearer I can be in the article or in my replies to comments.
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.
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.
"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
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.
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.
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.
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.
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?
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.
The same goes for tools like Word, Excel, and PowerPoint. I prefer Markdown for creating presentations and documents, and I even use Vim keybindings in VSCode and JetBrains IDEs (because I am lazy and you can use them nearly everywhere). My "TV/Steam" runs a tiling window manager (Sway) and is controlled by a keyboard instead of a remote (and you guest it, you can use Vim keybindings with sway). At one point, I used the right-hand for mouse at work and the left-hand at home. And, of course, there is the classic switch from a native-language keyboard to an English one for programming. What I'm trying to say is, you can adapt if you're motivated. And sometimes you don't.
I'm also a huge friend of trackpoints instead of touchpads. And I avoid to use the mouse and keyboard at the same time. Usually, mouse while planning, reviewing and presenting and keyboard when creating. And I learn keybindings for software that I use daily because of that.
Less GUI, means more Content / Information on the screen. And sometimes you benefit from that.
My takeaway? Do whatever makes you happy. Rewiring your brain from time to time keeps it flexible and sharp; like learning a new language or playing a musical instrument. It's a workout for your mind.
And Productivity isn't just about speed; it's also about quality. Sometimes, slowing down (by using a mouse) to focus on the craft of your work leads to better results than rushing to get things done as quickly as possible.
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)
And then, at least on the Mac, some of the basic commands in Emacs carry over not just to the terminal, but to things like text input windows in Safari and other Mac-assed apps so I can almost always use ctrl-a to go the beginning of a line, ctrl-e to go to the end, ctrl-k to delete to the end of the line and sometimes also I get esc-del to delete the previous line although that works in terminal, but not a Safari input window (and escape gets captured in IntelliJ’s terminal which kind of stinks).
I do feel that common config across a team is always a good thing. I’ve been the only IntelliJ guy on an Eclipse team and the only Eclipse guy on an IntelliJ team and both cases were worse than conforming to the convention.
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’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.
and
> 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.
If you can affectively use vim macros, then GREAT! But if you cannot, even with using vim for decades, then please don't advertise them as the "fun" part.
And the other thing is that vim has the “dot” command to repeat your last edit. Similar to macros, you think about your local edit first, then about where to repeat it (usually tied to the next item in the search list).
Edit (after reading the article).
Both vim and emacs (which have the steep learning curve) are aimed at power users. It’s best to compare them to professional tools like CAD, DAW, industrial appliances,… The friction when learning is because a lot of users don’t know what’s possible to do or even have the kind of problems that experienced users do (or they fail to perceive them as issues). After a while, it becomes like an extension of your thinking and the tool disappears.
You think about the evolution of the internal state and the suitable commands just appears, just like you think of an idea and the suitable words appears. Learning commands is like expanding your vocabulary, not learning how to speak. Learning how to speak is internalizing the aforementioned conceptual model.
That visual feedback is EXTREMELY useful because I learn of the edge cases to what I am editing in bulk (usually formatting code or tables or whatever) as I am editing it. When you do a macro, you have to try and get it right, and then try again from the start each time to get it right. `dot` et al are not enough in that regard. So the multiple cursors approach is better not because it's a different mindset, but it produces a different feedback loop to correct mistakes.
If you still prefer the macro approach over the multiple cursors approach, then you do you. But as an example in the article, I have seen people think they are being productive by their own standards, and they really aren't.
Search for “vim puzzle” and you’ll find entire websites dedicated to it. Here’s a random one: https://vimventure.dev/
> multiple cursors really are better than macros 99.999% of the time (since they give direct visual feedback)
I don't know what he means, vim macros also give direct visual feedback while writing them. You just edit as normal while recording, and replay those edits later. I think it is technically possible to write a macro without seeing the live effect on the text as you write it, but I've never done that.
I looked up multiple cursors out of interest, I guess the advantage is that it's one interface that is easy to explain. I would use multiple vim commands to replace it in practice.
I'll agree that multiple cursors are maybe better than macros for most of the things that someone would use multiple cursors for, but usually I wouldn't use macro's.
But I think most of the things I do with macro's cannot be done with multiple cursors.
I would be very interested in being proven wrong, if someone has some examples of "this is where multiple cursors are great, and vim doesn't have a good alternative".
And there is the problem. The first time you do the edit, it might be fine, but when you make a mistake in the edit, you then have to go back and correct all of the cases. With multiple cursors, I am seeing instant visual feedback on all instances of the cursor at once. I am getting literally 2D spatial information, compared to the 1D spatial information per each replay. The multiple cursors approach is better not because it's a different mindset or whatever, but rather it produces a different feedback loop to correct mistakes.
If you still prefer the macro approach over the multiple cursors approach, then you do you. But as an example in the article, I have seen people think they are being productive by their own standards, and they really aren't.
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
I can't justify using Emacs myself on a productivity basis. But working in an environment I think is fun while being productive makes me marginally happier.
If you are having fun, and it's a hobby: who cares? If it's in the professional setting, make sure what you are doing is not actually wasting time and/or money, i.e. be productive.
Do you people think we spend our weekends tweaking our configs because that is how we get our fun? Some do, sure, the vast majority have created their config once and find themselves more productive compared to whatever alternative you might be suggesting. Configuring vim or eMacs is an investment, as you are likely to still see it around in 20 years. Being familiar with one’s tools is the key to productivity.
Calling it an ‘obsessive hacker tool’ just shows you don’t know what you’re talking about, but come with preconceived notions about why people prefer other tools.
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.
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 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
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)
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)
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 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."
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.
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"
Though I don’t agree with the author. Visibility isn’t what matters, if you get comfortable with a specialized tool like a CAD software, or a game engine studio like Unreal, it’s not invisible at all but your brain will stop focusing on all the noise on your screen and you become pretty focused and productive. I live emacs, but Rider is also a fantastic editor.
Though I would love for things like LLMs to be way more out of your way, more “invisible”, more tool like. I hate the current UX of having to tame a patronizing, annoying fake human just to get things done the way I want them to be done
Powerful and specialized: automatic transmission, display/monitors
Simple and limited: syntax highlighting, deterministic autocomplete
The closest ones imo that bridge the gap: ssh, google search
It's not until you randomly end up on a system which doesn't have that tool that its usefulness becomes visible; and I mean really visible.
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 first argument is about people. People romanticize the flaws of their tools, turn vim macros into a personality, and mistake the feeling of cleverness for output. Fine. True. Bill is correct that a lot of tool evangelism is tribal signaling dressed up as productivity advice. However, people join these tribes because they get benefit from it. If the tool wasn't meeting their perceived needs, they wouldn't be passionate.
The second argument, the one in the title, is about tools: that being invisible is what makes a tool good. That one is fundamentally wrong, IMO.
Halfway through, Bill admits the invisibility test "is a personal one." Which means: a tool is good when it disappears for you. Sublime is invisible to him because he's been at it for fifteen years. On day one it was not invisible to anyone. In fact, I remember buying a book and reading it back in the day about how to get better at using Sublime. So "good tools are invisible" reduces to "good tools are tools you've already mastered." That's not a claim about tools; rather, it's a claim about experience. Every powerful tool is bad to the novice and invisible to the expert. So I'll categorize this one as a veiled tautology.
Then there's the metric. Bill's "honest test" is wall-clock time and mistakes made. Anyone who's less familiar with a tool is going to make more mistakes up front. I have a couple of professional-grade sanders that I've used for some projects around the house, and because I use them infrequently, I tend to make mistakes when I get started since it's not my core competency.
The right question for a power tool isn't how fast you did the routine thing, it's what became possible that wasn't before. Git is not invisible to anyone, ever, and it's the most successful version control system ever built, for better or worse. Of course, lots of people also think Git is bad, so I'm not making any particular claims on that front, but it did manage to reach a local maxima that led people to jump ship from SVN et al. SQL has been the standard for fifty years and is famously brutal to master. A profiler demands your full attention every time you open it. These tools are good because they expand the frontier of what you can express. A tool that makes the impossible merely hard beats a tool that makes the easy invisible. Bill's metric scores the median task and is blind to the edge, which IME is where I end up spending more of my time as I grow as a software developer..
The configurability section is where the essay argues against itself. Bill's fix for "highly configurable" cop-outs is "good defaults, plus escape hatches for the rare cases." But the escape hatch is the whole problem with his thesis. The moment a tool has escape hatches, the knowledge to use them is valuable, and the tool isn't invisible even to him. He wants the power and wants to disown the learning it costs. You don't get to do that. The escape hatch and the learning curve that leads to it are the same object. He even admits it. In the learning-curve section he concedes a steep curve "could absolutely be a cost worth paying" if the payoff is real productivity. That's the entire counter-thesis. So I'm not really sure what point he's actually trying to make with this article besides that you should have good defaults for tools.
It's not perfect and the bugs that have been there for years (and won't be fixed) have annoyed me for years too. The reason I still stick to Sublime is just because the alternatives that are similar are much much slower. I wish Sublime was actually invisible to me, but it isn't. It's just the most invisible I've found out of the alternatives.
> But the escape hatch is the whole problem with his thesis
I understand what you are saying, but the point of an escape hatch is that for the general everyday cases, the defaults should be good and invisible. But there will always be edge cases which you cannot handle nicely, either there hasn't been a way discovered yet which is better or there are other external accidental things which prevent it from being "nice" (not I am talking about tools in general and not just text editors, maybe even programming languages hint).
> The escape hatch and the learning curve that leads to it are the same object. He even admits it. He even admits it. In the learning-curve section he concedes a steep curve "could absolutely be a cost worth paying" if the payoff is real productivity. That's the entire counter-thesis.
I don't agree with your interpretation of my article. I am talking about certain people in particular that are saying the bad aspect of tool is actually good. If there is a high learning curve for a tool, it needs to eb compared to the current alternatives. But sometimes the curve is "essential" and cannot be improved upon, for better or for worse. I have yet to see many "essentially" high learning curves in the domain of programming.
I am not sure how to summarize the entire article other than what I already wrote in the conclusion.
Removing friction from the context and flow. For what git and sql do, they arguably have the most efficient and effective work flows for their purposes.
Managing complexity becomes unavoidable for certain problems, so for challenges of the tool, sometimes, it's simple the challenge of the problem.
I would say his point is not articulated well. Tools should be less toilsome and provide faster feedback loops.
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.