Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Good Tools Are Invisible

gingerbill.org

Post reply on HN
Print view View original

71–80 of 305 posts

Re: Good Tools Are Invisible

#71

Post by itchyouch »

iand675 wrote: post #46

The problem with the article is that it's two arguments pretending to be one. The first argument is about people. People romanticize the flaws of their tools, turn vim macros into a personality, and mistake the feeling of cleverness for output. Fine. True. Bill is correct that a lot of tool evangelism is tribal signaling dressed up as productivity advice. However, people join these tribes because they get benefit fro…

I think you hit on a point with git and sql I made in a different context.

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.

Re: Good Tools Are Invisible

#72

Post by jb3689 »

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)

Re: Good Tools Are Invisible

#73

Post by diabllicseagull »

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.

Re: Good Tools Are Invisible

#74

Post by bensyverson »

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

Re: Good Tools Are Invisible

#75

Post by skydhash »

elsjaako wrote: post #69
skydhash wrote: post #63

Earlier quoted context omitted.

The things about multiple cursors is that you think about the processing while doing it, while most people using macros looks at the structure of the text first and then devise the macro. I wouldn’t say the latter is faster, but it’s a different mindset. 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…

Exactly. And I'm no purist - I'm happy to use "dot" with a mouse if I want to easily repeat an edit in tens of places if they're not nicely aligned or searchable.

One of the things about Emacs and Vim is that you have commands that does things. They all have the same conceptual model. In vim, you have the text objects, the motions, and the counts (and more advanced ones like line and pattern addressing). In emacs, you have the point, the mark, and the arguments (including the universal one) (the advanced ones are which modes are currently active). That’s mostly the internal state that matters when you think about an edit which changes A to B.

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.

Re: Good Tools Are Invisible

#78

Post by cws_ai_buddy »

jrimbault wrote: post #13

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

[flagged]

Re: Good Tools Are Invisible

#79

Post by gingerBill »

skydhash wrote: post #63
gingerBill wrote: post #53

Earlier quoted context omitted.

That's not what I was saying. I used vim macros specifically as an example, not Vim as a whole. > 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 t…

The things about multiple cursors is that you think about the processing while doing it, while most people using macros looks at the structure of the text first and then devise the macro. I wouldn’t say the latter is faster, but it’s a different mindset. 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…

> The things about multiple cursors is that you think about the processing while doing it

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.

Post reply on HN