Good Tools Are Invisible

Good software tools, some argue, should “disappear” in use—removing friction so users focus on their actual work rather than on the tool itself. Commenters debate this ideal across examples like Vim vs. Sublime Text, CLI/TUI vs. GUI workflows, and Linux vs. commercial desktops, weighing configurability and steep learning curves against good defaults, composability and raw power. Many conclude that what feels “invisible” is highly personal and tied to identity and experience: the same tool can be effortless for an expert, opaque for a novice, and either a productivity enhancer or a hobbyist playground depending on how it’s used.

What counts as an “invisible” tool?

  • Many argue “good tools are invisible” means they fade into the background once mastered and don’t demand attention.
  • Others say invisibility is mostly about familiarity over time, not an intrinsic property of the tool.
  • Some suggest a better framing is “low friction” or “removes accidental complexity” rather than literally invisible.

Text editors, Vim/Emacs vs Sublime/IDEs

  • Strong debate around whether modal editors (Vim/Emacs) are inherently “puzzly” or just powerful tools with a learning curve.
  • Supporters say: once the conceptual model (motions, text objects, macros, repeat commands) is internalized, the editor disappears and becomes an extension of thought.
  • Critics counter that some users celebrate friction (e.g., complex macros) as “fun” even when simpler tools or multiple cursors would be faster.
  • Multiple cursors vs macros:
    • Pro-multiple-cursors: better live visual feedback, easier edge-case handling.
    • Pro-macros: more general, composable, can handle cases multiple cursors can’t; visual feedback while recording is enough.
  • Some note many editors (including Vim and modern IDEs) now mix paradigms: modal keybindings, multiple cursors, plugins.

CLI/TUI vs GUI and composability

  • Terminal advocates emphasize composable CLI tools, pipelines, and reuse across contexts (local/SSH/automation).
  • GUI advocates highlight project awareness, structured navigation, and ease for novices; argue that for many, a few frequent operations dominate, making heavy CLI investment unnecessary.
  • Distinction is drawn between CLI (scriptable commands) and TUI (full-screen interactive apps that don’t compose as easily).

Configurability, defaults, and learning curves

  • One camp sees “highly configurable” as often a cop-out that pushes design decisions onto users; prefers strong defaults + narrow escape hatches.
  • Another camp argues deep configurability is valuable for long-lived, central tools (editors, WMs), especially now that LLMs can help with configs.
  • Consensus: steep learning curves can be justified if they unlock genuinely higher ceilings; they’re harmful when they just enable ornamental complexity.

Identity, fun, and productivity

  • Several comments tie tool choice to identity, signaling, and “tribal” editor/OS wars.
  • Some warn that tinkering can become an addictive hobby that feels productive but isn’t; others reply that enjoyment and long-term engagement matter too.

LLMs, agents, and invisible tooling

  • LLMs are criticized as very visible tools: they mediate everything as a “negotiation” with a fake person.
  • Agent-style workflows that hide behind email/iMessage are cited as closer to the “invisible tool” ideal.