Good Tools Are Invisible

好的工具是“隐形”的

TL;DR: A good tool is and ought to be invisible—striving to make such tools is the goal of a toolmaker. One habit I see a lot, and have to push back on, is taking a tool’s shortcomings and reselling them as a “puzzle game” which is “fun” to solve. I don’t want my tools to be “fun”. I want my tools to be invisible. 简而言之：好的工具是，也应当是“隐形”的——致力于打造这样的工具是工具制造者的目标。我经常看到一种习惯，并且不得不对此提出反驳：有些人将工具的缺陷包装成一种“益智游戏”，并宣称解决这些问题很有“乐趣”。我不希望我的工具变得“有趣”，我希望它们是隐形的。

Text Editor Wars

文本编辑器之争

Let’s take vim as an example (This is just an example, and applies to other editors too). I constantly see some people praise it not for what actually makes it good, but by taking the things it’s bad at and turning them into a puzzle to have “fun” solving. 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. 以 Vim 为例（这只是个例子，同样适用于其他编辑器）。我经常看到有人称赞它，不是因为它真正优秀的地方，而是把它的短板变成了一个需要“有趣”解决的谜题。曾有人告诉我，编写一个宏来处理一次性的文本重构问题是多么“有趣”。但当我观察他们的操作过程和耗时后，我真实的反应是：我在 Sublime 里用多光标功能一分钟就能搞定，或者写个简单的脚本也行。

To be clear, I’m not saying text editors don’t matter to your workflow. I’m questioning the near-religious devotion people have to a tool because it gives them a “hacker vibe”—which is basically the whole appeal for newcomers to vim or emacs. That’s what I mean by “invisible tools”. When you’re proficient with your editor of choice—whatever it is—it disappears into the background. But the moment it cannot handle something easily, it stops being invisible. 需要明确的是，我并不是说文本编辑器对工作流不重要。我质疑的是人们对某种工具近乎宗教般的狂热，仅仅因为它能带来一种“黑客氛围”——这基本上是 Vim 或 Emacs 对新手的所有吸引力所在。这就是我所说的“隐形工具”。当你精通你选择的编辑器时——无论它是哪一款——它就会消失在后台。但一旦它无法轻松处理某项任务，它就不再是隐形的了。

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 know plenty of things wrong with my own editor of choice: Sublime. I don’t dress those flaws up as fun little puzzles to solve. I just get annoyed that it lacks the tools I actually need, forcing me to write a plugin or reach for a separate program to write to transform text the way I want. 让我困惑的是，许多人竟然把这种摩擦力——即绕过工具局限性所付出的努力——视为“乐趣”，并将其作为工具优秀的证据进行宣传。我非常清楚我所使用的编辑器 Sublime 的诸多缺陷。我不会把这些缺陷包装成有趣的谜题。我只会因为缺少我真正需要的工具而感到恼火，被迫去写插件或寻找其他程序来按我想要的方式转换文本。

I’ve been using Sublime for 15 years now. It’s my editor of choice for a few reasons: its shortcuts are a superset of the graphical OS environment (which minimizes the mental context-switch when moving between applications), multiple cursors really are better than macros 99.999% of the time (I think I’ve only “needed” a macro in Sublime twice in the past decade, and in both cases, setting up the macro took longer than if I just wrote a script to do the same thing), and it leaves me with the fewest “puzzles” to solve in my text-editing workflow. 我使用 Sublime 已经 15 年了。它是我的首选编辑器，原因有几点：它的快捷键是图形化操作系统环境的超集（这最大限度地减少了在不同应用程序间切换时的思维负担）；在 99.999% 的情况下，多光标功能确实比宏更好用（过去十年里，我想我只有两次“需要”用到宏，而且在这两次中，设置宏的时间比直接写个脚本完成同样任务的时间还要长）；它让我在文本编辑工作流中需要解决的“谜题”最少。

I’ve found something like vim to be better at basic editing but worse at bulk operations—and I don’t mean grep-like operations—which is why I’ve stuck with Sublime for so long. I never found vim motions to be that much more productive than my Sublime workflow either, and that wasn’t just down to lack of trying or familiarity (To be honest, I have forgotten most of my “vim motions” knowledge over the years, because I don’t regularly exercise it, nor do I need to). And since I virtually never write code in a terminal, my need for a terminal-oriented editor is effectively nonexistent. 我发现像 Vim 这样的工具在基础编辑上更强，但在批量操作上较弱——我指的不是 grep 那种操作——这就是我长期坚持使用 Sublime 的原因。我也从未觉得 Vim 的移动指令比我的 Sublime 工作流效率高出多少，这不仅仅是因为我尝试得不够或不够熟悉（老实说，这些年来我已经忘记了大部分“Vim 移动指令”知识，因为我不常练习，也不需要）。而且由于我几乎从不在终端里写代码，我对终端导向的编辑器的需求实际上为零。

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. 如果人们觉得 Vim、Emacs 或其他任何工具确实好用且高效，我不会批评他们。人们总是对自己熟悉的东西感到最舒适。但对于我所讨论的这类人来说，这种熟悉感让他们对工具的缺陷视而不见，甚至转而赞美这些缺陷，将其炫耀为一种游戏。

Tools as an Identity

工具即身份

Part of why these debates turn religious is that a tool choice becomes a flag you plant—it says something about who you are. The “hacker vibe” isn’t a mere aesthetic; it’s tribal signaling, and that’s the real trap. Once your identity is invested in a tool, admitting its flaws starts to feel like admitting something about yourself. So people don’t just tolerate the flaws—they defend them, and eventually flaunt them. You cannot have an honest conversation about a tool with someone who’s decided the tool is part of their personality. 这些争论之所以演变成宗教般的狂热，部分原因在于工具的选择成了你竖起的一面旗帜——它代表了你是谁。“黑客氛围”不仅仅是一种审美，它是一种部落信号，这才是真正的陷阱。一旦你的身份与某种工具绑定，承认它的缺陷就开始变得像是在承认你自己的不足。因此，人们不仅容忍这些缺陷，还会为之辩护，最终甚至炫耀它们。如果你和一个已经把工具视为人格一部分的人讨论工具，你是不可能进行坦诚交流的。

Feeling Productive versus being Productive

感觉高效与真正高效

The text-editor-macro anecdote I mentioned is really about a gap between feeling productive versus being productive. There’s a sensation of cleverness that comes from solving a fiddly problem, and it’s easy to mistake that feeling for actual output. A tool that makes hard things feel heroic and clever feel like an achievement can register as “powerful” while quietly being slow. The honest test isn’t how engaged or clever you felt, it’s wall-clock time and how many mistakes you made getting there. A lot of the tools people evangelize would lose that test. If productivity is actually the goal, actually question your own views on this, and try to see what makes you more productive. You will be surprised when you do. 我提到的关于文本编辑器宏的轶事，实际上反映了“感觉高效”与“真正高效”之间的差距。解决棘手问题时会产生一种聪明感，人们很容易把这种感觉误认为是实际产出。一个让困难任务显得英勇、巧妙并带来成就感的工具，可能会被视为“强大”，但实际上却可能效率低下。真正的检验标准不是你感觉自己有多投入或多聪明，而是实际耗时以及你在过程中犯了多少错。许多人们极力推崇的工具在这一测试中都会败下阵来。如果生产力确实是你的目标，请审视一下自己的观点，看看究竟是什么让你变得更高效。当你这样做时，你会感到惊讶的。

Terminal UIs vs GUIs

终端界面 (TUI) 与图形界面 (GUI)

Another example in this same vein is when people advocate for terminal apps over GUIs. If you’re stuck in a terminal all day, then I completely get the obvious advantage, but most programmers aren’t stuck in a terminal all day. From those people who generally advocate for a TUI over a GUI, one of the criticisms of GUI apps tends to be: “I cannot navigate them with the keyboard alone”. Okay? That doesn’t make GUI apps inherently bad. It just means the GUIs people build aren’t good enough to be keyboard-navigable. There’s nothing inherently impossible about making a GUI navigable with a keyboard, rather it’s just that most toolmakers never bother to implement, and usually because they don’t realize how much more productive keyboard navigation is than reaching for the mouse a lot of the time. 同样，另一个例子是人们推崇终端应用胜过图形界面应用。如果你整天都待在终端里，我完全理解其明显的优势，但大多数程序员并非如此。在那些倾向于推崇 TUI 而非 GUI 的人中，对 GUI 应用的批评之一往往是：“我无法仅用键盘操作它们”。那又怎样？这并不意味着 GUI 应用本身很糟糕。这只是意味着人们构建的 GUI 还不够好，无法实现键盘导航。让 GUI 支持键盘导航并没有什么本质上的困难，只是大多数工具制造者懒得去实现，通常是因为他们没有意识到，在很多时候，键盘导航比频繁使用鼠标要高效得多。

If the argument was that a specific TUI app is better than the other alternatives which are GUI based, then that is a fair argument, but arguing that TUIs are inherently better than GUIs is very misinformed. And this is the common mistake: people look at the current state of a category of tools and assume its current limitations are inherent/essential, when really no one has put in the work to make those tools better. 如果论点是某个特定的 TUI 应用比其他 GUI 替代品更好，那是一个合理的论点；但如果争论说 TUI 本质上就比 GUI 更好，那就非常无知了。这就是常见的错误：人们观察某一类工具的现状，并假设其当前的局限性是本质的或必然的，而实际上只是没有人投入精力去改进这些工具而已。