Good Tools Are Invisible

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

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

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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

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

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

A 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!]

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.

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.

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

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

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

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

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

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"

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

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

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?