> 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 stru…
Good Tools Are Invisible
141–150 of 305 posts
Re: Good Tools Are Invisible
#142As 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)…
But at some point I just figured I was wasting so much time in there. Switched tshark and jq or good old bash/awk/grep and gnuplot, back to the command-line, then python for batteries, still using the output of tshark... and then ended writing a pcap(and ng) parser with ethernet-ip-udp/tcp and a full java IDE and never went back. I went the same meandering path with every data capture and exploration tool I had to use repeatedly.
I feel I'm not the only one having this repeated sequence of tooling improvement, hopefully there is a well named scale to describe it.
Re: Good Tools Are Invisible
#143As 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)…
Re: Good Tools Are Invisible
#144It 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.
Re: Good Tools Are Invisible
#145I 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 o…
good luck editing a photo with CLI tools ( though im sure someone has developed something for this lol) to your point i think there is a lot of merit to having CLI-first development, where if it can be done in a CLI then do it in a CLI. if a GUI is to be built as an assistance tool, great, but let the actions map to commands that could be saved and re-run
Or good luck editing text with CLI tools, for that matter.
Obviously, those need an interactive UI.
> to your point i think there is a lot of merit to having CLI-first development, where if it can be done in a CLI then do it in a CLI. if a GUI is to be built as an assistance tool, great, but let the actions map to commands that could be saved and re-run
And this is probably why CLIs suck less in practice because the development effort isn't diluted by building multiple frontends.
Re: Good Tools Are Invisible
#146I'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.
Re: Good Tools Are Invisible
#147I 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.
Re: Good Tools Are Invisible
#148Earlier quoted context omitted.
I think if you need to measure this kind of thing, you're missing the point in the first place. I don't want to be chasing some absolute productivity metric, I want a setup that doesn't break my flow. For many people, reaching for the mouse breaks their flow and feels wrong, which is oftentimes worse than being a second slower, because it takes you out of the mental frame you were in. For me, using my mouse while I'm…
Reaching for the mouse doesn't break my flow. It makes the thing I was doing invisible in the flow. Keyboard shortcuts require me to think, which makes it FEEL like I'm doing something, and that something is in the flow so it feels like I'm productive. However the mouse doesn't even enter into the flow at all, I just do the thing and get on with the real work without breaking flow. Again, there is no universal correc…
I been doing a lot of Bender. Keyboard on left hand and Mouse on right. The keyboard shortcuts in Blender are excellent, but there are _many_.
I know this sounds silly, but what really breaks my flow is moving my mouse from the middle of the screen where my model is, to the top of the screen where the menus is.
I bought a Stream Deck which is a programmable keyboard with 32 buttons and a screen behind them. I've programmed my most common commands there, so I can just reach across with a finger and smash a button rather than move the mouse away from the center of the screen.
It saves about 1 second, but really makes a huge difference.
Re: Good Tools Are Invisible
#149As 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)…
I don't think your logic is off, but I also think that the FrobnosticatorStudio people have a point. The thing is, yes, the terminal gives you infinitely more capabilities but you probably have like, 20 actual things you do regularly? The learning curve makes it a hard sell when those 20 things are probably all you need. Like, sometimes I'll do something like this if I'm in a terminal and I want to find a build scrip…
Re: Good Tools Are Invisible
#150The 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…
emacs starts with "extensible", so wouldn't extending the tool be part of the interface?
Purchased tools rarely align with this - they provide functionality over customization. especially in the apple world.