Diese Woche habe ich einen Absatz auf theapparchitect.com laut vorgelesen. Das mache ich nicht immer, aber ein Satz hatte mich zum dritten Mal aufgehalten. Er klang steif, nicht falsch, aber steif. Nach einem Moment hatte ich den Schuldigen gefunden: einen Gedankenstrich mitten im Satz, der den Text in zwei gleich schwere Hälften teilte und beide schwerfälliger machte als nötig. Ich habe ihn durch einen Punkt ersetzt, und der Satz kam zur Ruhe. Danach habe ich dasselbe auf drei Websites gemacht.
Drei Websites, eine Entscheidung, kein neues Feature
Mehr ist in dieser Woche nicht passiert: ein einziger redaktioneller Commit, dreimal ausgerollt. Auf theapparchitect.com, civo-cloud-manager.app und marcelrgberger.com gab es überall dieselbe Änderung aus demselben Grund.
Als Software-Architekt schreibe ich mehr als Code. Ich schreibe Fehlermeldungen, die Nutzer lesen, und Dokumentation für die Entwickler, die nach mir kommen. Und ich schreibe die Texte auf meinen eigenen Websites, die mögliche Kunden lesen, meistens zwischendurch, in fünf Minuten, auf dem Handy. In diesem Umfeld sind Gedankenstriche eine schlechte Wahl. Sie wirken nach Schriftsprache und nach „hier hat jemand lange nachgedacht“. Das ist nicht immer ein Vorteil.
Die Entscheidung klingt banal. Anfangs dachte ich auch, das sei in zwanzig Minuten erledigt. Es dauerte länger. Suchen und Ersetzen war nicht das Problem, das geht mit einem regulären Ausdruck in Sekunden. Aufwendig war, dass ich jeden Satz mit Gedankenstrich neu lesen musste. Etwa der Hälfte davon tat ein Punkt oder ein Komma besser. Ein Viertel hätte ich anders gebaut, wenn ich heute neu anfangen würde. Das letzte Viertel bekam seinen Gedankenstrich zurück, weil er dort wirklich passte.
Genau das hat mich aufgehalten: der Unterschied zwischen „alle Gedankenstriche ersetzen“ und „für jeden Satz einzeln entscheiden“. Das eine ist Formatierung, das andere ist Schreiben. Ich habe mich für das Schreiben entschieden.
Was ich daraus über meinen eigenen Code lerne
Es gibt eine direkte Parallele zur Softwareentwicklung. Ich erwähne 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 von außen wie eine Kleinigkeit. Im Diff ist es eine Zeile. Für alle, die den Code danach lesen, ist es jedoch eine der lohnendsten Investitionen überhaupt. Dasselbe gilt für einen Satz, der auf den ersten Blick stimmt, beim Vorlesen aber stolpert.
Beide Entscheidungen bleiben unsichtbar, wenn sie gut getroffen sind. Sichtbar werden sie nur, wenn sie schlecht getroffen sind: als Name, der verwirrt, als Satz, der abbricht, als Gedankenstrich, der bremst.
Diese Woche gehörte den unsichtbaren Entscheidungen.
Was das mit Kundenprojekten zu tun hat
Wer eine App entwickeln lassen möchte und auf einer dieser Websites landet, liest nicht das Impressum. Er liest einen Absatz, vielleicht zwei. In dieser Zeit entscheidet er, ob die Person hinter der Website zuhört oder nur redet.
Holprige Texte geben darauf die falsche Antwort. Der Leser analysiert das nicht bewusst, aber holprige Sprache hinterlässt denselben Eindruck wie holprige Software: Irgendetwas stimmt hier nicht, ich weiß nur nicht genau, was.
Deshalb habe ich drei Commits für drei Websites gemacht und kein einziges neues Feature gebaut. Was ich sonst baue, finden Sie auf der Projektseite.
Nächste Woche ist mehr los. In Civo Cloud Manager habe ich eine Baustelle offen, die ich diese Woche bewusst nicht angefasst habe. Manchmal ist es die beste Entscheidung, eine Sache abzuschließen, bevor man die nächste beginnt.