Live data from Hacker News

Good Tools Are Invisible

gingerbill.org

141–150 of 305 posts

Re: Good Tools Are Invisible

#141
post #49

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

Theoretically yes, but in reality I have found that often it's much easier to just fix something locally or with a workaround rather than jumping through all hoops required to get somebody in another team or even another company to understand and agree with you on your (or your teams) issues, let alone fix them in a satisfactory way.

Re: Good Tools Are Invisible

#142
post #11

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

I have a similar relationship with wireshark. I understand the use of a live capture and display and the attraction of the click GUI.

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

#143
post #11

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

But this only speaks about what some GUIs lack, it's not necessarily true that GUI apps can't be composable, it's just that seldom they are made as such. The true potential of a GUI app is much richer than what terminal currently offers (unless it starts to receive capabilities usually present only in GUIs, as we can see with some of them - but then it's a GUI with the severe terminal restrictions, a strange beast).

Re: Good Tools Are Invisible

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

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

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

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

Re: Good Tools Are Invisible

#145

I completely agree that the author is right and the strawman is wrong. For example. The strawman criticizes GUI apps because he cannot navigate them with the keyboard alone. Keyboard-navigated TUIs are the worst type of UI. CLI > GUI > TUI. I don't like interactive tools because they're not scriptable. I don't care about keyboard vs mouse per se. I don't like having to use different tools for the same job depending 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

> good luck editing a photo with CLI tools

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

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

Re: Good Tools Are Invisible

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

Re: Good Tools Are Invisible

#148

Earlier 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 have an anecdote to contribute.

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

#149
post #11

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

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…

Ctrl-shift-o -> scr is what I use. I love symbol navigation :)

Re: Good Tools Are Invisible

#150

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…

> The effect of the interface becoming "invisible" is actually a function of time spent in the interface.

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.

Post reply on HN