Guter Geschmack im Engineering ist etwas anderes als Können [Übersetzung]

Die Aussage ist, dass „guter Geschmack“ im Software Engineering nicht die Vorliebe für einen bestimmten Tech-Stack bedeutet, sondern die Fähigkeit, flexibel die Engineering-Werte auszuwählen, die am besten zur jeweiligen Projektsituation passen.

Geschmack ist etwas anderes als Können

• Technischer Geschmack ist wie ein kulinarischer Geschmackssinn ein vom Können unabhängiges Empfinden. Er zeigt sich in der Fähigkeit, auch ohne selbst besonders gut Code schreiben zu können, zu unterscheiden: „Dieser Code sieht gut aus / gefällt mir nicht“ oder „Diese Designentscheidung gefällt mir / ist fragwürdig“.
• Entscheidungen wie for-Schleife vs. map/filter sind kein Ausdruck absoluter technischer Überlegenheit, sondern lediglich Unterschiede im Geschmack, je nachdem, welche Werte man höher gewichtet (Lesbarkeit, Einfachheit, Performance usw.). Engineers urteilen letztlich nach dem Set an Werten, das sie selbst am wichtigsten finden.

Engineering-Geschmack = Priorisierung von Werten

• Die meisten Entscheidungen im Software Engineering sind Trade-offs zwischen Werten wie Performance, Lesbarkeit, Korrektheit, Flexibilität, Skalierbarkeit, Resilienz, Portabilität und Entwicklungsgeschwindigkeit; nur selten ist eine Seite immer eindeutig die absolut richtige Wahl.
• Der Geschmack eines Engineers wird dadurch definiert, welche dieser Werte wie stark priorisiert werden. Wer zum Beispiel Geschwindigkeit und Korrektheit höher bewertet als Entwicklungsgeschwindigkeit, greift eher zu Rust oder zu einer bestimmten Cloud; wer Resilienz höher gewichtet als Geschwindigkeit, entscheidet sich natürlicherweise eher für Dinge wie verteilte Multi-Region-Setups.

Schlechter Geschmack: unflexible Verehrung von „Best Practices“

• Schlechter Geschmack zeigt sich darin, dass jemand Werte bevorzugt, die nicht zum aktuellen Projekt passen, und trotzdem Methoden, von denen er glaubt, dass sie früher funktioniert haben (formale Verifikation, Rewrite in einer bestimmten Sprache, übertriebenes Multi-Region-Setup, komplexe Metaprogrammierung usw.), unabhängig vom Kontext durchdrückt.
• Solche Menschen rechtfertigen ihre Wahl mit absoluten Maßstäben wie „Das ist eben Best Practice“. Das kann in speziellen Situationen gut funktionieren, führt aber bei verändertem Kontext Teams in die falsche Richtung — wie ein Kompass, der plötzlich falsch zeigt.

Guter Geschmack: passende Wertwahl und Flexibilität im Kontext

• Guter Geschmack ist die Fähigkeit, innerhalb eines konkreten Problems sowie organisatorischer und geschäftlicher Einschränkungen richtig zu wählen, welche Werte man priorisiert und welche man opfert. Deshalb lässt er sich durch einfache Fragen-Antworten oder Theorietests nur schwer messen und zeigt sich erst in Design und Ergebnissen realer Projekte.
• Erst wenn man über mehrere Projekte hinweg wiederholt beobachtet, dass Projekte mit Designentscheidungen, denen man zugestimmt hat, gut verlaufen, während Projekte mit Entscheidungen, denen man nicht zugestimmt hat, Schwierigkeiten erleben, kann man prüfen, ob der eigene Geschmack in diesem Kontext richtig oder falsch lag.

Wie man guten Geschmack entwickelt

• Guter Geschmack entsteht laut dieser Sichtweise nicht durch eine einzige richtige Antwort oder ein Lehrbuch, sondern baut sich langsam auf, indem man viele verschiedene Projekttypen erlebt und dabei immer wieder bewusst reflektiert: „Wo lief es reibungslos, wo wurde es mühsam?“ und „Welche Wertentscheidungen sind uns später auf die Füße gefallen?“
• Entscheidend ist Flexibilität: Statt eine bestimmte Sprache, ein bestimmtes Pattern oder eine bestimmte Architektur als absolute Regel zu behandeln, sollte man offen für neue Domänen und den Geschmack von Kolleginnen und Kollegen bleiben, verschiedene Perspektiven und Sprachen ausprobieren und den eigenen Grundgeschmack laufend aktualisieren.