Sonntagmorgen, ich lese einen Absatz auf theapparchitect.com laut vor. Nicht weil ich das immer mache, sondern weil mich ein Satz zum dritten Mal aufgehalten hat. Er klang steif. Nicht falsch, aber steif. Nach einem Moment hatte ich den Schuldigen gefunden: ein Gedankenstrich mitten im Satz, der Text in zwei gleichgewichtige Hälften teilte und beide irgendwie schwerer machte, als sie sein mussten. Ich habe ihn durch einen Punkt ersetzt. Der Satz atmete auf. Und dann habe ich dasselbe durch drei Websites gemacht.
Drei Sites, eine Entscheidung, kein neues Feature
Das war der komplette Inhalt dieser Woche: ein einziger redaktioneller Commit, dreimal ausgerollt. theapparchitect.com, civo-cloud-manager.app, marcelrgberger.com — überall dieselbe Änderung, überall derselbe Grund.
Als Software Architekt schreibe ich mehr als Code. Ich schreibe Fehlermeldungen, die Nutzer lesen. Ich schreibe Dokumentation, die Entwickler nach mir lesen werden. Und ich schreibe Texte auf meinen eigenen Sites, die potenzielle Kunden lesen — meistens spätabends, in fünf Minuten, auf dem Handy. Für diesen Kontext sind Gedankenstriche eine schlechte Wahl. Sie signalisieren Schriftsprache. Sie signalisieren “hier hat jemand lange nachgedacht”. Das ist nicht immer ein Vorteil.
Die Entscheidung klingt trivial. Ich dachte zuerst auch, das sei in zwanzig Minuten erledigt. Es hat länger gedauert. Nicht wegen der Suche und des Ersetzens — das geht mit einem Regex in Sekunden. Sondern weil ich jeden Satz, der einen Gedankenstrich enthielt, neu lesen musste. Etwa die Hälfte davon war mit einem Punkt oder einem Komma besser bedient. Ein Viertel hätte ich anders gebaut, wenn ich heute von vorn anfinge. Das verbleibende Viertel bekam seinen Gedankenstrich zurück, weil er dort wirklich der richtige war.
Das ist der Teil, der mich aufgehalten hat: der Unterschied zwischen “ersetze alle Gedankenstriche” und “entscheide für jeden Satz einzeln”. Ersteres ist Formatierung. Letzteres ist Schreiben. Ich habe letzteres gemacht.
Was mich das über meinen eigenen Code lehrt
Es gibt eine direkte Analogie zur Softwareentwicklung, und ich bringe sie nur kurz, weil sie mir diese Woche wirklich aufgefallen ist.
Wenn ich eine Funktion umbenenne, weil ihr Name nicht mehr beschreibt, was sie tut, wirkt das nach außen wie eine Kleinigkeit. Im Diff ist es eine Zeile. In der Wirkung auf alle, die den Code danach lesen, ist es eine der wertvollsten Arten, Zeit zu investieren. Dasselbe gilt für einen Satz, der auf den ersten Blick richtig ist, aber beim Vorlesen stolpert.
Beide Entscheidungen sind unsichtbar, wenn sie gut getroffen wurden. Sichtbar wird nur, wenn sie schlecht getroffen wurden: der Name, der verwirrt, der Satz, der abbricht, der Gedankenstrich, der ausbremst.
Diese Woche war eine Woche für unsichtbare Entscheidungen.
Was das mit Kundenprojekten zu tun hat
Wenn jemand eine App entwickeln lassen möchte und auf einer dieser Sites landet, liest er nicht das Impressum. Er liest einen Absatz, vielleicht zwei. In dieser Zeit entscheidet er, ob die Person hinter der Site jemand ist, der zuhört — oder jemand, der redet.
Copy, die holpert, gibt die falsche Antwort. Nicht weil der Leser das bewusst analysiert, sondern weil holpernde Sprache denselben Eindruck hinterlässt wie holpernde Software: irgendwas stimmt da nicht, ich weiß nur nicht genau was.
Das ist der Grund, warum ich drei Commits für drei Sites gemacht habe und kein einziges neues Feature gebaut habe. Wer wissen will, was ich sonst baue, findet das auf der Projektseite.
Nächste Woche wird mehr los sein. Ich habe in Civo Cloud Manager eine Baustelle offen, die ich diese Woche bewusst nicht angefasst habe — manchmal ist die beste Entscheidung, eine Sache fertig zu machen, bevor man die nächste aufmacht.