Skills

Baue einen schmalen Pfad, der jede Schicht durchquert und läuft, bevor du irgendeine Schicht vollständig baust — eine Integration, die nie ausgeführt wurde, ist eine Vermutung.

Ein Kriterium, das nach der Implementierung geschrieben wird, beschreibt die Implementierung. Schreibe zuerst die fehlschlagende Prüfung, sieh sie scheitern, dann baue.

Eine Einstellung, die erfolgreich speichert und bis zum Neustart nichts ändert, ist schlimmer als eine, die fehlschlägt. Sag, wann sie greift, und leite das davon ab, wo sie gelesen wird.

Rechne gegen ein Budget unterhalb des echten Fensters, und zähle die Tool-Schemas mit, die du bei jedem Schritt erneut mitschickst — sie sind der Boden, den Compaction nicht erreicht.

Eine Retry-Schleife, die ihre Feedback-Variable überschreibt, zeigt Versuch 3 nur den Fehlschlag von Versuch 2 — also leitet sie wieder den Patch her, den Versuch 1 schon probiert hat.

Nimm die Signatur aus der installierten Version, nicht aus dem Gedächtnis — eine plausible API ist von einer echten nicht zu unterscheiden, bis sie läuft.

Alles, was von Hand aus einer anderen Datei kopiert wurde, ist genau einmal richtig. Wenn es generierbar ist, generiere es — und lass den Build scheitern, sobald die Kopie veraltet.

Ein Generator, der abstürzt, sagt dir, dass er gescheitert ist; einer, der plausible Ausgabe liefert, sagt dir nichts. Prüfe, was er gefunden hat, nie dass er gelaufen ist.

Ein Regressionstest, den du nie hast scheitern sehen, ist eine Vermutung. Mach den Code wieder kaputt und sieh zu, wie er rot wird, bevor du ihn committest.

Eine Diagnose ist eine Behauptung über eine Maschine, die du nicht ausgeführt hast. Reproduziere den Fehler erst mit einem kurzen Befehl — besonders dann, wenn die Diagnose von jemand anderem kam.

Führe den Verifikationsbefehl des Projekts wörtlich aus — gleicher Scope, gleiche Flags. Die fast identische Variante, die du improvisierst, lügt in beide Richtungen.

Eine Klasse, die im Test von Hand zusammengebaut wird, beweist, dass die Klasse funktioniert, nicht dass irgendetwas sie erreicht — decke den Pfad ab, den die Produktion tatsächlich nimmt.

Wenn eine Prüfung beim falschen Ziel anschlägt, macht der Fix sie schwächer. Halte den Fehlalarm im selben Commit als Test fest, sonst erodiert die Regel still.

Bevor du eine Aufgabe als erledigt meldest, führe die Prüfung aus, die fehlschlagen würde, wenn sie es nicht wäre — eine Erklärung ist keine Behebung.

Eine Rate ohne ihren Nenner und ihre Zusammensetzung führt in die Irre, während jede Ziffer stimmt — nenne n, und nenne, wie viel des Zählers bereits bekanntes Rauschen ist.

Ein Ranking, das aus einem Teil des Systems entsteht, liest sich als Ranking des Systems — schreibe Umfang und Ausschlüsse neben die Befunde, nicht dahinter.

Wenn zwei deiner eigenen Messungen um einen Abstand auseinandergehen, den kein Mechanismus erzeugen könnte, liegt der Defekt im Instrument. Prüfe das Harness, bevor du Theorie darauf aufbaust.

Eine Zahl und ihr Vorbehalt müssen ein Artefakt sein. Zwei Absätze driften auseinander; eine Komponente kann das nicht.

Veröffentliche das Experiment, das gescheitert ist, bewahre das überholte unverändert auf und würfle nie neu, um Signifikanz zu erreichen. Die Verzerrung liegt in der Auswahl, nicht in der Zahl.

Eine Prüfung, die nach dem eingeführt wird, was sie schützt, ist eine Prüfung, die jemand zum Ausliefern abschaltet. Schließe sie, solange es nichts zu blockieren gibt.

Ein Gate, das auflistet, was zu prüfen ist, ist fail-open — die Seite, an die niemand gedacht hat, ist die, die bricht. Liste stattdessen die Ausnahmen auf, jede mit einer schriftlichen Begründung, und der Standard wird Fehlschlag.

Ein leerer Screen, Tab oder eine leere Kategorie ist ein Versprechen, das das Produkt nicht hält. Blende sie aus, bis sie Inhalt hat, oder baue sie noch nicht.

Ein Warnhinweis nach der Handlung, die er betrifft, kommt an, wenn die lesende Person längst entschieden hat. Setze ihn darüber und mache ihn unabweisbar, wenn es darauf ankommt.