Gute Werkzeuge sind unsichtbar
(gingerbill.org)- Gute Werkzeuge sind Werkzeuge, die in den Hintergrund verschwinden, während Nutzer in ihrer Arbeit aufgehen, und auch das Ziel der Werkzeugmacher besteht darin, das Werkzeug selbst aus dem Bewusstsein verschwinden zu lassen
- Wenn man die Mängel eines Werkzeugs als „interessantes Rätsel“ verpackt, verwechselt man leicht das Gefühl von Cleverness mit tatsächlicher Produktivität
- Die Wahl eines Editors wie vim, emacs oder Sublime kann zum persönlichen Workflow passen, aber wenn man sogar die Schwächen wie ein Identitätssignal verteidigt, wird es schwer, Vor- und Nachteile ehrlich zu sehen
- Auch in der TUI-vs.-GUI-Debatte sollte man die Defizite aktueller Implementierungen nicht mit den wesentlichen Grenzen der Kategorie selbst verwechseln; viele Probleme entstehen schlicht dadurch, dass es an guten Implementierungen fehlt
- Gute Standardeinstellungen sind ein Design, das den Nutzern Zeit spart, und hohe Konfigurierbarkeit oder eine steile Lernkurve sind nur dann den Aufwand wert, wenn sie sich durch echte Produktivität auszahlen
Maßstäbe für gute Werkzeuge
- Gute Werkzeuge müssen unsichtbar sein
- Ein Werkzeug verschwindet in den Hintergrund, wenn Nutzer ihre Arbeit fortsetzen können, ohne sich des Werkzeugs selbst bewusst zu sein
- In dem Moment, in dem das Werkzeug bei einer bestimmten Aufgabe im Weg steht, wird es dem Nutzer wieder bewusst
- Die Haltung, Schwächen als „interessantes Rätsel“ neu zu verpacken, verzerrt die Bewertung eines Werkzeugs
- Die Freude daran, Umwege zu finden, beweist nicht die Qualität des Werkzeugs
- Mängel wie ein Hobby zu genießen und ein Werkzeug tatsächlich gut zu finden, sind zwei verschiedene Dinge
Die Debatte um Texteditoren
- vim ist nur ein Beispiel; dieselbe Logik gilt auch für andere Editoren wie emacs oder Sublime
- Einige Nutzer loben weniger die Stärken von vim als den Prozess, seine Schwächen als „interessantes Rätsel“ zu lösen
- Es gibt Beispiele, in denen das Erstellen eines Makros für ein einmaliges Text-Refactoring als unterhaltsam empfunden wurde
- Wenn sich dieselbe Aufgabe mit den Mehrfach-Cursorn von Sublime in unter einer Minute oder mit einem einfachen Skript erledigen ließ, ist die Makro-Arbeit nach realen Produktivitätsmaßstäben schwach
- Editoren sind wichtig für den Workflow, aber eine Haltung, einem bestimmten Editor wegen seiner „Hacker-Atmosphäre“ fast religiös zu folgen, ist gefährlich
- Für Menschen, die vim oder emacs neu kennenlernen, kann genau diese Atmosphäre reizvoll wirken
- Vertrautheit kann Mängel verdecken und dazu führen, dass man sie wie ein Spiel zur Schau stellt
Warum Sublime genutzt wird und welche Grenzen anerkannt werden
- Sublime ist seit 15 Jahren der verwendete Editor, und die Gründe für diese Wahl lassen sich in einigen Punkten zusammenfassen
- Die Tastenkürzel kommen einem Oberbegriff der grafischen OS-Umgebung nahe, wodurch beim Wechsel zwischen Apps die kognitiven Wechselkosten gering sind
- Mehrfach-Cursor sind in 99,999 % der Fälle besser als Makros
- Mehrfach-Cursor liefern direktes visuelles Feedback
- Im Textbearbeitungs-Workflow gibt es die wenigsten „Rätsel“, die gelöst werden müssen
- Auch Sublime hat weiterhin Mängel
- Manchmal fehlen notwendige Werkzeuge, sodass Plugins genutzt oder Texttransformationen in einem separaten Programm erledigt werden müssen
- Solche Mängel werden nicht als „interessantes Rätsel“ verpackt, sondern schlicht als Unbequemlichkeit akzeptiert
- vim mag für grundlegende Bearbeitung besser sein, gilt aber bei Massenoperationen, die keine grep-artigen Aufgaben sind, als schwächer
- Es wird nicht empfunden, dass vim motions deutlich produktiver wären als der Sublime-Workflow
- Da im Terminal fast nie Code geschrieben wird, besteht praktisch kein Bedarf an einem terminalorientierten Editor
Wenn Werkzeuge zur Identität werden
- Die Wahl eines Werkzeugs kann wie eine Fahne funktionieren, die zeigt, was für ein Mensch man ist
- Die „Hacker-Atmosphäre“ kann über eine bloße Ästhetik hinaus zu einem Tribal-Signal werden
- Wenn die Identität an ein Werkzeug gebunden ist, fühlt sich das Eingeständnis von Mängeln wie eine Verneinung der eigenen Person an
- Deshalb werden Mängel nicht nur ertragen, sondern auch verteidigt und stolz vorgeführt
- Mit Menschen, für die ein Werkzeug Teil ihrer Persönlichkeit geworden ist, ist ein ehrliches Gespräch über Werkzeuge schwer
Das Gefühl von Produktivität und tatsächliche Produktivität
- Das Beispiel mit Editor-Makros zeigt den Unterschied zwischen dem Gefühl von Produktivität und tatsächlicher Produktivität
- Das Gefühl von Cleverness, das beim Lösen kniffliger Probleme entsteht, lässt sich leicht mit realem Output verwechseln
- Werkzeuge, die schwierige Aufgaben heroisch wirken lassen und Cleverness wie eine Leistung erscheinen lassen, können mächtig wirken
- Gleichzeitig kann die tatsächliche Arbeitsgeschwindigkeit im Stillen langsam sein
- Der ehrliche Maßstab ist nicht Flow oder Cleverness, sondern die benötigte Zeit und die Zahl der Fehler
- Viele Werkzeuge, die fast missionarisch empfohlen werden, können nach diesem Maßstab zurückfallen
- Wenn Produktivität das Ziel ist, sollte man die eigenen Überzeugungen tatsächlich hinterfragen und prüfen, was produktiver ist
Die TUI-vs.-GUI-Debatte
- Für Nutzer, die den ganzen Tag im Terminal bleiben, sind die Vorteile von Terminal-Apps klar
- Aber die meisten Programmierer verbringen nicht den ganzen Tag im Terminal
- Die Kritik, GUI-Apps ließen sich nicht nur mit der Tastatur bedienen, bedeutet nicht, dass GUI grundsätzlich schlecht ist
- Viele GUIs unterstützen Tastaturnavigation einfach nicht ausreichend
- Es gibt nichts grundsätzlich Unmögliches daran, GUIs per Tastatur navigierbar zu machen
- Viele Werkzeugmacher setzen das entweder nicht um oder erkennen nicht, dass Tastaturnavigation oft produktiver ist als häufige Mausnutzung
- Der Vergleich, dass eine bestimmte TUI-App besser sei als eine bestimmte GUI-Alternative, kann berechtigt sein
- Daraus abzuleiten, dass TUI grundsätzlich besser sei als GUI, kommt jedoch einem Fehler gleich, bei dem die Grenzen aktueller Implementierungen mit wesentlichen Grenzen verwechselt werden
Linux-Desktop und die Freude am Konfigurieren
- Auch 2026 ist das „Jahr des Linux-Desktops“ nicht gekommen
- Ein Grund dafür ist, dass viele Linux-Nutzer es als „interessantes Rätsel“ mögen, an Konfigurationsdateien zu arbeiten und ihr System zu verändern
- Selbst wenn man solche Phasen selbst durchlaufen hat, möchte man mit der Zeit einfach Werkzeuge, die gut funktionieren
- Stunden oder sogar Tage mit Konfiguration zu verbringen, ist nichts, was man noch will
- Standardeinstellungen sollten gut sein und sofort funktionieren
- Wenn kleine Anpassungen nötig sind, sollten sie in wenigen Sekunden erledigt sein
- Maximale Konfigurierbarkeit sollte nicht das Ziel eines Werkzeugs sein, sondern eine Option für Fälle, in denen sie tatsächlich gebraucht wird
- Ergonomisches Werkzeugdesign bedeutet, gute Standardeinstellungen und bei Bedarf einen Ausweg zugleich zu bieten
Gute Standardeinstellungen und die Verantwortung der Werkzeugmacher
- Gute Standardeinstellungen sind Verantwortung der Werkzeugmacher
- Werkzeugmacher neigen leicht dazu, die Last von Konfiguration, Feinabstimmung und Lernen auf die Nutzer abzuwälzen
- Viel dieser Last ist das Ergebnis davon, dass Designer Entscheidungen vermeiden
- „Hohe Konfigurierbarkeit“ kann zur Ausrede werden, Probleme ohne klare Haltung an den Nutzer weiterzureichen
- Gute Standardeinstellungen sind Respekt vor der Zeit der Nutzer
- Wenn Werkzeugmacher einmal gründlich nachdenken, müssen zahllose Nutzer nicht immer wieder über dasselbe nachdenken
- Auswege sind Einrichtungen für die echte Minderheit mit ungewöhnlichen Anforderungen
- Sie dürfen nicht die Aufgabe ersetzen, den allgemeinen Fall ordentlich zu gestalten
Eine steile Lernkurve ist kein Feature
- Es gibt auch die Verteidigung, dass gerade die Schwierigkeit eines Werkzeugs sein Kern sei
- Die Logik lautet, dass dadurch Unentschlossene ausgesiebt würden und man nach dem Überwinden der Hürde ein Leben lang belohnt werde
- Eine Lernkurve ist ein Kostenfaktor, keine Tugend
- Diese Kosten können sich lohnen, aber die Belohnung muss tatsächliche Produktivität sein
- Das Gefühl, die Kosten bezahlt zu haben, darf nicht selbst die Belohnung sein
- Die Logik „Ich habe Monate gelernt, also muss es wertvoll sein, und andere sollten es auch tun“ verpackt versunkene Kosten als Kompetenz
- An diesem Punkt wird das Rätsel nicht mehr zur Arbeit mit dem Werkzeug, sondern zum Werkzeug selbst
Die wichtigere Haltung als die Werkzeugwahl
- Es ist kein Argument gegen ein bestimmtes Werkzeug, sondern eine Kritik an der Denkweise, mit der Werkzeuge betrachtet werden
- Ob man vim, emacs oder Sublime nutzt, ist letztlich egal
- Maßgeblich ist, ob das Werkzeug in den Hintergrund tritt und dem Nutzer erlaubt, weiterzuarbeiten
- Dieser Maßstab ist persönlich
- Das Problem sind die Erzählungen, die sich um die Werkzeugwahl legen
- Grenzen werden als Features neu verpackt
- Der Aufwand, Mängel zu umgehen, wird als Belohnung verkauft
- Das Werkzeug wird vom „benutzten Ding“ zu einem „Teil der eigenen Person“ erhoben
- Das klarste Zeichen dafür, dass ein Werkzeug richtig dient, ist der Zustand, in dem der Nutzer es nicht mehr wahrnimmt
- Die besten Werkzeuge sind nicht die mit der besten Geschichte, sondern die, bei denen Nutzer vergessen, dass sie sie überhaupt benutzen
1 Kommentare
Hacker-News-Kommentare
Ich stimme dem voll zu, nachdem ich ziemlich viele interne Tools für Entwicklerteams entworfen habe
Früher dachte ich, weil die Nutzer Entwickler sind, sei es besser, die „interne Struktur“ offenzulegen, aber in der Praxis hat das meinen Teamkollegen nur Hindernisse bei ihrer eigentlichen Arbeit geschaffen
Sie nutzen die von mir gebauten Tools, um die Arbeit zu erledigen, die das Unternehmen braucht; sie wollen nicht an irgendwelchen kleinen Tools herumspielen, die sie sonst nirgends sehen würden, und es gibt auch keinen Grund dafür
Ich lasse immer noch viele Auswege offen, aber ich versuche, interne Tools so zu gestalten, dass Nutzer ganz natürlich in eine Erfolgsgrube fallen
Und Fehlermeldungen, Fehlermeldungen, Fehlermeldungen sowie automatische Vorschläge für häufige Fehler sind wichtig
Es ist auch enttäuschend, dass viele Leute sich nur an den Beispielen des Artikels festbeißen und den eigentlichen Punkt verfehlen
Wenn sie dem Nutzer hilft, etwas zu tun, das ihm wirklich wichtig ist, dann ist Konfigurierbarkeit sehr wertvoll; wenn das Tool aber nur ein weniger wichtiges Problem aus dem Weg räumt, kann sie eher stören
Zum Beispiel ist die Art, wie Gusto Gehaltsabrechnung, Steuern und Formulareinreichung übernimmt, wirklich gut. Man muss kaum darüber nachdenken oder etwas anfassen
Aber für jemanden, dessen eigentliche Arbeit Payroll, Buchhaltung oder Steuern ist, oder der in der HR-, Rechts- oder Finanzabteilung eines Großunternehmens arbeitet, kann so eine Vereinfachung schädlich sein. Man muss dann mit dem Tool kämpfen oder, weniger freundlich gesagt, es vereinfacht die eigene Arbeit zu stark
Außerdem ist die Frage, wer tatsächlich bezahlt, ob das Tool einem defensiven Zweck wie Auditierbarkeit, Sicherheit oder der Einschränkung unerwünschten Verhaltens dient oder einem kreativen Zweck, ebenfalls entscheidend. Kreative Funktionen sind attraktiver, aber schwerer zu quantifizieren, und Endnutzer zahlen nicht unbedingt viel Geld, nur weil etwas ihrer Rolle stärker hilft
Man setzt sinnvolle Standardwerte und erlaubt Anpassung bei Bedarf. Man sollte mit den 80-%-Fällen anfangen, Änderungen ermöglichen, wenn jemand sie will, und das Ganze optional halten
Gerade bei Entwickler-Tools gibt es oft die Tendenz, sich mit starken Meinungen zurückzuhalten. Wenn man nicht sicher ist, dass eine Wahl „immer richtig“ ist, wirkt es sicherer, den Nutzer zu fragen, und Entwickler können ziemlich anspruchsvoll sein
Wenn man sagt: „95 % wollen wahrscheinlich diesen Weg, aber die anderen 5 % haben auch einen berechtigten Punkt, also mache ich es für alle gleich offen“, bekommt die Mehrheit am Ende ein schlechteres Tool
Anpassbarkeit zu unterstützen ist viel komplexer, als man denkt. Es geht nicht nur um Bugs; jede einzelne Option macht es schwerer, die User Experience zu verfeinern. Der Testumfang wächst, und flexiblere Abstraktionen sind auch schwerer zu entwerfen
Es gibt aber trotzdem einen Teil, bei dem man die Balance finden muss: Menschen zur richtigen Vorgehensweise zu zwingen
Es gibt immer Leute, die sich beschweren, wenn sie durch korrektes Vorgehen ausgebremst werden, und für sie fühlt sich das oft wie Zeitverschwendung an
Aus Sicht der Organisation ist das Ziel, während der Beschäftigungszeit eines Mitarbeiters die steilste Leistungskurve zu erreichen; aus Sicht des Mitarbeiters geht es um die Leistungskurve über die gesamte Karriere
Vieles hängt von der Beziehung der beteiligten Personen ab. Wenn ein Umzugshelfer vom Training am Vortag Muskelkater hat, ist das aus meiner Sicht langsamer und schlechter, aber aus Sicht der Umzugsfirma kann es gut sein, weil er langfristig stärker wird und mehr Arbeit leisten kann. Wenn er allerdings an dem Tag kündigt oder entlassen wird, ist es wieder schlecht
Die eigentliche Bewertung ist nicht, ob Makros oder Editieren in Sublime besser sind, sondern ob der Denkprozess beim Erstellen von Makros auch bei anderen Aufgaben hilft und was die Person sonst vorher gemacht hätte
Meiner Erfahrung nach würden nur sehr wenige Menschen die Zeit, die sie für Makros oder das Lernen von Vim verwenden, in wirklich sinnvolle Arbeit stecken. Meist sind sie gelangweilt oder ausgebrannt und wollen in dem Moment lieber über etwas anderes nachdenken, das sich interessanter anfühlt
Das Problem ist nicht, dass Mitarbeiter zufällige Skripte schreiben, sondern dass ihnen beim aktuellen Task Dringlichkeit oder Interesse fehlt
Der Effekt, dass ein Interface „unsichtbar“ wird, ist in Wirklichkeit eine Funktion der Zeit, die man in diesem Interface verbracht hat
Worauf der Autor reagiert, scheint eher frei wählbare Reibung zu sein, also Reibung, die Designer oder Produktverantwortliche durch zusätzliche Funktionen oder Komplexität einbauen
Solche Reibung kann aber nötig sein, um bestimmte Aufgaben zu bewältigen. Man denke nur an das Auflösen von Merge-Konflikten. Und wenn man ein System lange genug benutzt, verschwinden selbst solche „störenden“ Schritte irgendwann in den Hintergrund
Konkret ist das Cockpit einer 737 extrem dicht mit Bedienelementen belegt. Auch das Flugzeug selbst hat verschiedene Modi und viel bewusst eingebaute Reibung
Fragt man aber einen Piloten, der seit über zehn Jahren mit der 737 arbeitet, wird er sagen, dass diese Oberfläche für ihn unsichtbar geworden ist
Dasselbe gilt für das oft als „schlecht“ angesehene Bloomberg Terminal. Auch im medizinischen Bereich kann eine Oberfläche voller Buttons genau die richtige Lösung sein für jemanden, der mehr als 8 Stunden am Tag mit MR-Scan-Software arbeitet und sofortigen Zugriff auf alle Bedienelemente haben will
Programmierer neigen dazu, ihre eigenen Erfahrungen und Vorlieben zu schnell zu verallgemeinern und auf andere anzuwenden
Quelle: Ich habe 10 Jahre lang Consumer- und Profi-Software bei IDEO entworfen
Der Artikel behandelt das aus Nutzersicht und geht davon aus, dass es eine Art von Nutzern gibt, die es genießen, „zusätzliche“ Funktionen zu lernen, deren ultimativer Wert geringer ist als der der Kernfunktionalität
Der Kern ist die Passage: „Wenn Menschen vim, emacs usw. benutzen, weil sie sie wirklich gut und produktiv finden, würde ich das nicht kritisieren. Menschen fühlen sich mit dem Vertrauten am wohlsten. Aber ich spreche von den Leuten, die wegen dieser Vertrautheit die Schwächen des Tools nicht mehr sehen und diese Schwächen dann wie in einem Spiel zur Schau stellen und feiern.“
Aus der Perspektive von jemandem, der lange das Terminal benutzt hat, ist es nicht besonders überraschend, dass viele Leute das nicht verstehen. Das Gespräch läuft meist so ab
„Im Terminal kann man mit einfachen Befehlen dies und jenes erledigen“
„In meinem FrobnicatorStudio gibt es dafür den Shortcut Ctrl+Alt+So“
Und so geht es endlos weiter, bis man bei fast bedeutungslosen Vergleichen landet wie „In Vim kann man mit vier Tastendrücken 24 Zeilen löschen“ und „Sublime hat Multi-Cursor“.
Der eigentliche Punkt ist wohl, dass das Terminal dank der Art, wie es kleine Kommandozeilen-Tools zu Pipelines kombiniert, unendlich viele Anwendungsfälle abdecken kann, aber eine Lernkurve hat, die ungefähr ein Jahr dauert, bis es bequem wird.
Wenn man diesen Punkt erreicht, kann man sehr viel produktiver sein als ein durchschnittlicher GUI-Nutzer, aber dorthin zu kommen erfordert Hingabe und Leid, und viele Menschen tun das nicht freiwillig, sondern weil sie müssen.
In meinem Fall musste ich in meinem ersten Job Kundeserver per ssh verwalten, und auf diesen Servern war nur das Nötigste installiert. Oft gab es nicht einmal vim, sondern nur vi, und in dieser Umgebung blieb mir nichts anderes übrig, als herauszufinden, wie ich darin effektiv arbeiten konnte.
Ohne diese Erfahrung bin ich nicht sicher, ob ich den Schmerz auf mich genommen hätte, überhaupt im Terminal zu arbeiten.
Aber irgendwann hatte ich das Gefühl, dort zu viel Zeit zu verschwenden. Ich bin mit tshark und jq, altem bash/awk/grep und gnuplot zurück zur Kommandozeile gegangen und später zu Python, habe aber weiterhin die Ausgabe von tshark verwendet.
Am Ende habe ich sogar Parser für pcap und pcapng gebaut, Verarbeitung für Ethernet-IP-UDP/TCP und eine vollständige Java-IDE, und bin nie wieder zurückgegangen.
Bei allen Daten-Capture- und Explorations-Tools, die ich wiederholt benutzen musste, bin ich denselben verschlungenen Weg gegangen.
Ich vermute, ich bin nicht der Einzige, der diese iterativen Phasen der Tool-Verbesserung durchläuft, und es wäre schön, wenn es dafür eine gut passende Skala gäbe.
Das Terminal gibt einem unendlich viel mehr Möglichkeiten, aber wahrscheinlich gibt es nur etwa 20 Dinge, die man tatsächlich regelmäßig tut. Wenn diese 20 Dinge alles sind, ist das wegen der Lernkurve schwer zu vermitteln.
Wenn man zum Beispiel im Terminal ist und das Build-Skript finden will, kann man so etwas machen wie
cat packages.json | jq .scripts.Innerhalb des Terminals ist das nützlich, aber wenn man in VSCode ist, reicht
ctrl-p -> packages.json -> ctrl-f -> scr, und tatsächlich sind es sogar weniger Tastenanschläge.Arbeitsabläufe sind wirklich sehr persönlich, deshalb würde ich niemandem sagen, er solle seinen ändern, aber ich persönlich bevorzuge statt Tools, die ein Projekt einfach nur als Text behandeln, eher Tools, die die Projektstruktur verstehen, deshalb passt eine IDE besser zu mir.
Kommandozeilen-Apps sind Tools wie grep, sort, cp, git, ls oder tar, mit denen man interagiert, indem man Befehle in die Shell schreibt. Wenn man die allgemeine Verwendung kennt, kann man sie auch in Skripten einsetzen und daher zu Pipelines kombinieren.
Text User Interface Apps sind interaktive Apps, die während der Benutzung das Terminal übernehmen, wie Vim, Emacs, Tmux, Lynx, Tig, Midnight Commander oder Claude Code.
Solche Dinge kombiniert man nicht per Pipeline. Genauer gesagt nutzt man sie in ihrer üblichen Form nicht in einer Pipeline. Wenn es doch geht, dann vermutlich deshalb, weil die App zusätzlich zum TUI eine Kommandozeilen-Schnittstelle anbietet.
Es dauert zwar, bis man für alle Probleme denselben Werkzeugkasten verwenden kann, aber am Ende ist das effizienter.
Schwer zu vermitteln ist es trotzdem. Solange man nicht einmal ein Problem gelöst hat, das sich mit Kommandozeilen-Tools deutlich leichter lösen lässt, ist diese Einfachheit schwer zu begreifen.
Trotzdem benutze ich die Kommandozeile für alles Mögliche sehr viel. Normalerweise habe ich ein konsole-Fenster offen und wechsle per alt+tab dorthin, wenn ich bauen oder testen muss, statt den „build system“-Support von Sublime zu verwenden.
Vim benutze ich nur noch, wenn ich ssh brauche oder auf dem Handy Termux verwende.
Erweiterbare GUI-Tools wie Sublime oder VSCode decken ebenfalls unendlich viele Anwendungsfälle ab und bieten sogar eine stabilere und reproduzierbarere Ausführungsumgebung.
Dass diese Debatten nie enden, liegt meiner Meinung nach daran, dass Menschen meistens engstirnig denken. Es ist schwer, sich in andere hineinzuversetzen, und noch schwerer, die Möglichkeit ernsthaft anzunehmen, dass man selbst falschliegen könnte.
Letztlich ist das nur für Anfänger wichtig. Sobald man ausreichend eingearbeitet ist, ist das Produktivitäts-Nadelöhr unabhängig vom verwendeten Tool nicht mehr das Tool selbst. Außer vielleicht bei ed.
Auf die Behauptung „Sie verstehen nicht, dass Navigation per Tastatur viel produktiver ist, als ständig zur Maus zu greifen“ würde ich sagen: Ein großer Teil der Leute, die behaupten, produktiver zu sein, hat das nie wirklich gemessen.
Über die Jahre gab es viele Wettbewerbe Tastatur- gegen Mausnavigation, und je nach Details des Testdesigns gewann mal die eine, mal die andere Seite, manchmal mit ziemlich großem Abstand.
Nicht selten verlor am Ende genau die Methode, von der die Nutzer vorab behauptet hatten, damit produktiver zu sein.
Es geht nicht darum, einer absoluten Produktivitätskennzahl hinterherzujagen, sondern darum, eine Umgebung zu haben, die den Flow nicht unterbricht.
Für viele Menschen unterbricht das Greifen zur Maus den Flow und fühlt sich unangenehm an, oft schlimmer als nur eine Sekunde langsamer zu sein, weil es einen aus dem Kontext im Kopf herausreißt.
Für mich ist es beim Arbeiten ganz natürlich, die Maus zu benutzen, daher wäre es ein enormer zusätzlicher Aufwand, meinen Workflow so umzustellen, dass die gesamte Navigation per Tastatur erfolgt, nur weil das in manchen Situationen vielleicht minimal Zeit sparen könnte.
Bei Tools wie Textverarbeitungen, IDEs oder Dateimanagern, bei denen Lesen, Eingeben und das Verarbeiten des Gelesenen und Eingegebenen im Mittelpunkt stehen, kann man zeigen, dass Tastaturnavigation schneller und natürlicher ist, sobald der Nutzer die Shortcuts gelernt hat.
Umgekehrt kippt die Debatte Tastatur gegen Maus bei Tools, in denen nicht Text, sondern visuelle Information im Mittelpunkt steht, viel stärker in Richtung Maus.
Trotzdem gibt es Momente, in denen effektive Shortcuts sehr viel nützlicher sind als Menüs und Icons. Man sieht das etwa bei CAD- oder 3D-Modelling-Software: Dort bestehen 90 % der Arbeit darin, mit visuell dargestellten räumlichen Daten zu arbeiten, aber wenn man die Shortcuts zum Werkzeugwechsel oder zum Ändern von Werkzeugeinstellungen kennt, wird man deutlich schneller und muss sich viel seltener durch verschachtelte Menüs wühlen.
Ich mache mir Sorgen, dass der Autor seine Vertrautheit mit seinem eigenen Tool mit einem Beleg dafür verwechselt, dass es besser ist.
Realistisch gesehen hat jedes Tool Trade-offs, und wenn ein Nutzer Tool X gegenüber Tool Y bevorzugt, dann wahrscheinlich nicht, weil er dumm ist, sondern weil er die Affordances dieses Tools, die oft nur Erfahrene verstehen, besser zu nutzen weiß.
Wenn man einen Entwickler vim, emacs und Sublime Text jeweils 10 Jahre lang benutzen ließe, wäre ich mir nicht sicher, dass er sagen könnte, was besser ist. Er hätte persönliche Vorlieben, könnte aber wohl auch erklären, warum andere andere Tools bevorzugen.
Das wirkt wie eine Debatte von jemandem, der unbekannter Software nie wirklich eine faire Chance gegeben hat.
Das Kennzeichen eines langjährigen Veterans ist meiner Ansicht nach ein vages Misstrauen gegenüber jeder Software und jedem Versprechen, diese Software zu verbessern. Langfristig konvergiert jede Software zu Mittelmäßigkeit.
Es wurde nur gesagt, dass ich der Vorstellung nicht zustimme, Reibung eines Tools als Feature zu betrachten.
Mit derselben Argumentation könnte ich zeigen, dass Vim für mich der perfekte Editor ist. Wenn ich Vim benutze, ist es unsichtbar, und in gewissem Maß auch deshalb, weil ich Vim zu dem Tool gemacht habe, das ich will.
Er hat Sublime zu dem Tool gemacht, das er will. Trotzdem bleibt der Kernpunkt bestehen: Wenn man etwas baut, das andere benutzen sollen, dann ist es eine starke Eigenschaft, wenn das Tool für den Nutzer unsichtbar wird.
Mittelmäßig bedeutet „von durchschnittlicher oder gewöhnlicher Qualität“.
Vielleicht braucht man für die nächste CRUD-App nicht zwingend die neueste und beste außergewöhnliche Technologie.
Wenn ich meinen Satz zitiere, lautet er: „Was mich irritiert, ist, dass viele Menschen genau diese Reibung, also die Mühe, die Grenzen eines Tools zu umgehen, als den ‘interessanten’ Teil behandeln und sie als Beleg dafür anpreisen, dass das Tool großartig ist.“
Das hat nichts damit zu tun, warum ich oder irgendjemand ein bestimmtes Tool wählt, sondern mit der Haltung, Mängel als etwas zu behandeln, das man wie in einem Puzzle-Spiel umgeht.
Maintainer guter Tools nehmen die Wahrnehmung ihrer Nutzer oft viel negativer wahr, als diese das Tool tatsächlich sehen.
Es ist schwer, zwischen „Heute haben sich 10 Leute über Bugs oder fehlende Features beschwert und 9990 haben es problemlos benutzt“ und „Heute haben sich 10 Leute beschwert und nur 90 haben es problemlos benutzt“ zu unterscheiden. Aber der Aufwand, um von 90 % auf 99,9 % Nutzerzufriedenheit zu kommen, ist gewaltig unterschiedlich.
Ich vermute stark, dass das ein großer Faktor für viel Burnout bei Open-Source-Maintainern ist.
Unzufriedene Nutzer fallen viel stärker auf als zufriedene, und im Verhältnis zur Geschwindigkeit, mit der neue Nutzer hinzukommen, bleibt der Anteil unzufriedener Nutzer, die dieselbe Menge an Bug-Reports und Feature-Requests erzeugen, gering.
Am Ende entsteht für Maintainer die Illusion, dass sich das wahrgenommene Gesamtniveau der Qualität nicht verändert, egal wie sehr sie verbessern, und das untergräbt die Motivation weiterzumachen.
Ich kenne dafür keine gute Lösung. Die offensichtliche Antwort wäre, häufiger Lob auszusprechen, wenn etwas gut funktioniert, aber in der Realität ist das eher ein kollektives Handlungsproblem, das selten gelöst wird.
Ich persönlich versuche bewusst, oft und mit Nachdruck positives Feedback zu geben, wenn etwas gut funktioniert, aber es ist schwer, einen großen Unterschied zu machen, wenn nicht alle das tun.
Dieses Zitat kommt mir in den Sinn.
„Wir bemerken immer den gekrümmten Rücken und den geschäftigen, kriecherischen Menschen und sagen vielleicht: ‘Wie demütig!’ Aber ein wirklich demütiger Mensch fällt nicht auf. Die Welt kennt ihn nicht.“
~ Tito Colliander
Die Stelle „Das klarste Zeichen dafür, dass ein Tool dir gut dient, ist, dass du es nicht mehr bewusst wahrnimmst, dass es also unsichtbar wird. Man macht seine Mängel nicht zum Hobby, preist sie also nicht, sondern umgeht sie nur mit leichtem Ärger“ scheint stärker von der Nutzerschaft abzuhängen als vom Tool selbst.
Natürlich ziehen unterschiedliche Tools unterschiedliche Nutzer an, und man könnte sogar starke Korrelationen messen.
Diese Position wirkt außerdem unausgewogen. Tools sind nie perfekt, und manchmal erkennt man, dass sie verbessert werden könnten; dann muss man abwägen zwischen der Umsetzung dieser Änderung und ihren Auswirkungen auf die eigenen Gewohnheiten.
Je länger man ein Tool benutzt, desto kleiner werden solche Veränderungen vielleicht, aber die Art, wie man arbeitet, entwickelt sich ein Leben lang weiter, und es ist natürlich, dass Tools das ebenfalls tun.
Eine ziemlich eigentümliche Interpretation
Es ist seltsam, dass der Autor darauf beharrt, Vim sei „sichtbar“, dabei aber andeutet, dass Sublimes Multi-Cursor und Funktionen das nicht seien. Nur weil man sich darauf trainiert hat, nicht mehr darüber nachdenken zu müssen, wird etwas nicht weniger sichtbar.
Multi-Cursor ist in vielen Tools keine Grundfunktion, und wenn man auch den effektiven Einsatz mitzählt, ist es ebenfalls etwas, das man lernen muss. Genau wie Vim-Keybindings.
Außerdem ist Vim mehr als nur eine TUI-Option für reine Terminalnutzer. Es sind auch Keybindings, die Menschen nutzen, die die Tastatur als natürliche Verlängerung ihres Körpers verinnerlicht haben und nicht ständig mit der Maus hin und her wechseln wollen. So wie Multi-Cursor für jemanden, der Sublime seit 15 Jahren nutzt, so etwas sein kann.
„Ich habe Leute darüber reden hören, wie viel ‚Spaß‘ es macht, Makros zu bauen, um einmalige Text-Refactoring-Probleme zu lösen. Aber wenn ich gesehen habe, was sie tun und wie lange es dauert, war meine ehrliche Reaktion: Das hätte ich mit Sublimes Multi-Cursor in einer Minute erledigt oder einfach ein kurzes Skript geschrieben.“
Und: „Was mich verblüfft, ist, dass viele Menschen genau diese Reibung, also den Aufwand, die Grenzen des Tools zu umgehen, als den ‚spaßigen‘ Teil behandeln und das dann als Beleg dafür vermarkten, wie großartig das Tool sei.“
Es ist gut, wenn man Vim-Makros effektiv nutzen kann. Aber wenn man es selbst nach Jahrzehnten mit Vim nicht kann, sollte man es nicht als den „spaßigen“ Teil anpreisen.
Die häufigste Haltung ist eher: Die Lernkurve ist da, aber am Ende lohnt sie sich.
Ich verstehe nicht, was das bedeuten soll. Vim-Makros geben beim Erstellen ebenfalls direktes visuelles Feedback. Man zeichnet sie auf, während man wie gewohnt editiert, und spielt diese Bearbeitungen später wieder ab.
Ob es technisch überhaupt möglich ist, Makros zu verwenden, ohne den Live-Effekt auf den Text während der Erstellung zu sehen, weiß ich nicht, aber ich habe das noch nie so gemacht.
Aus Neugier habe ich mir Multi-Cursor angesehen, und der Vorteil scheint zu sein, dass es ein einziges, leicht erklärbares Interface ist. In der Praxis würde man stattdessen mehrere Vim-Befehle verwenden.
Ich stimme zu, dass Multi-Cursor für die meisten Aufgaben, für die man es einsetzen würde, besser sein kann als Makros. Aber normalerweise würde ich für solche Aufgaben gar keine Makros verwenden.
Die meisten Dinge, die ich mit Makros mache, scheinen mit Multi-Cursor nicht möglich zu sein.
Falls es ein Beispiel gibt nach dem Motto „In dieser Situation ist Multi-Cursor großartig und Vim hat keine gute Alternative“, lasse ich mich gern vom Gegenteil überzeugen.
Das heißt aber nicht, dass Multi-Cursor keine Lernkurve hätte. Man muss immer noch darüber nachdenken, wie man die Cursor an die richtigen Stellen setzt.
Den Ausdruck „unsichtbar“ habe ich früher verwendet, um emacs magit zu beschreiben.
Eine dünne Schicht über der git-Ausgabe, die erscheint, aus dem Zustand der UI Parameter ableitet, die üblichen git-Befehle aufruft und dann wieder verschwindet.
Leichtgewichtig und schnell. Bei großen Projekten offenbar eher nicht, aber so heißt es.