Im Laufe meiner Karriere im Ingenieurwesen und der Softwareentwicklung habe ich zahlreiche Überzeugungen und Herangehensweisen hinterfragt und neu bewertet. Wachstum im technischen Bereich zeichnet sich nicht nur durch das Erlernen neuer Technologien aus, sondern vor allem durch die Bereitschaft, eigene Meinungen zu korrigieren und sich von neuen Erkenntnissen leiten zu lassen. Vier zentrale Aspekte haben meine Sichtweise nachhaltig verändert und machen mich zu einem besseren Ingenieur – diese möchte ich im Folgenden ausführlich erläutern. Die erste grundlegende Veränderung betrifft den Umgang mit komplexen und vermeintlich verwirrenden Software-Produkten. Früher war ich der Überzeugung, dass Verwirrung oft durch fehlendes Training oder mangelndes Anwenderwissen verursacht wird. Kunden, die Schwierigkeiten mit einem Produkt hatten, wurden gelegentlich einfach auf fehlende Schulung verwiesen oder als schwierig abgestempelt.
Doch mit der Zeit hat sich mein Verständnis gewandelt: Wenn ein Kunde die Software als verwirrend empfindet, dann ist sie auch verwirrend – ganz gleich, wie technisch versiert der Nutzer ist. Eine Software, die auf den ersten Blick nicht intuitiv und klar ist, trägt die Verantwortung für diese Verwirrung selbst. Statt die Nutzer in die Pflicht zu nehmen, gilt es als Entwickler, sich der Kritik zu öffnen, sie ernst zu nehmen und das Produkt verständlicher zu gestalten. Diese Haltung fördert nicht nur die Nutzerzufriedenheit, sondern wirkt sich auch direkt auf den Erfolg eines SaaS-Produkts aus. Supportanfragen sind ein frühes Signal für größere Probleme in der Bedienbarkeit; sie sollten nicht nur abgearbeitet werden, sondern systematisch in die Weiterentwicklung einfließen. In der Praxis erfordert dies ein hohes Maß an Empathie und Besitzanspruch bezüglich der eigenen Software.
Das bedeutet, eine unternehmensweite Kultur zu etablieren, in der Feedback nicht als lästige Pflicht gesehen wird, sondern als wertvolles Gut. Ein solcher Wandel zahlt sich langfristig aus, denn er bewahrt vor Funktionalitäten, die elegant klingen, aber für den Anwender eine unnötige Hürde darstellen. Der zweite Perspektivwechsel dreht sich um den Code an sich, genauer: Wie sollte guter Code aussehen? Früher hatte ich eine romantische Vorstellung, Code sei eine Kunstform, die mit cleveren, ausgefeilten und technisch eleganten Lösungen glänzen darf. Doch das idealisierte Bild von „flottem“ und „raffiniertem“ Code musste ich revidieren. Heute bin ich davon überzeugt, dass man besser langweiligen Code schreiben sollte. langweilig zu sein bedeutet, ausdrücklich, verständlich und vor allem konventionell zu programmieren. Ein Beispiel aus der JavaScript-Welt hilft, dies zu verdeutlichen: Für das Umwandeln eines Wertes zu einem Boolean gibt es verschiedene Möglichkeiten.
Anstatt einer ausgefallenen Funktion ist der doppelte Negationsoperator (! ! ) die verbreitetste und von den meisten Entwicklern sofort verstandene Option. Dieser pragmatische Ansatz entspricht dem Zen of Python, dessen Leitprinzipien auch in anderen Sprachen Gültigkeit besitzen: explizit ist besser als implizit, einfach ist besser als komplex, und es sollte immer einen offensichtlichen Weg geben, Dinge zu tun. Codes, die schwer zu verstehen oder zu erklären sind, erzeugen langfristig technische Schulden und behindern die Zusammenarbeit im Team. Deshalb gewinnt klarer, gut lesbarer und „langweiliger“ Code enorm an Bedeutung, gerade in großen Projekten und bei Teams mit wechselnden Mitgliedern. Eine dritte wichtige Erkenntnis stellt die Frage der Architektur dar, speziell in Bezug auf Tabellen in Webapplikationen.
Zunächst war ich der Meinung, dass clientseitige Tabellen mit Such-, Sortier- und Filteroptionen für die meisten Einsatzzwecke ausreichend sind und dass man auf die aufwendige serverseitige Renderung verzichten kann. Das Prinzip YAGNI („You Aren’t Gonna Need It“) schien mir auch hier den besten Weg zu weisen. Die Realität sah jedoch anders aus. Je größer die Datenmenge wird, desto langsamer und instabiler arbeiten clientseitige Tabellen. Das gilt besonders, wenn es mehrere solcher Tabellen auf einer Seite gibt oder wenn Echtzeitdaten über Websockets verarbeitet werden müssen. Deshalb hat es sich für mich bewährt, serverseitig gerenderte, paginierte Tabellen von Anfang an einzuplanen. Zwar bedeutet das initial mehr Aufwand und engere Abstimmung zwischen Frontend und Backend, doch die Stabilität, Performance und das Nutzererlebnis profitieren massiv davon – gerade in produktiven Anwendungen mit hohem Datenvolumen und Anspruch an Skalierbarkeit.
Ein rechtzeitiges Antizipieren dieser Anforderungen erspart späteren großen Mehraufwand und trägt zur technischen Nachhaltigkeit bei. Der vierte und letzte Punkt befasst sich mit Design-Kenntnissen bei Entwicklern. Früher war ich überzeugt, dass visuelles und nutzerzentriertes Design ausschließlich die Domäne von Designern sein sollte. Entwickler sollten sich um die technische Umsetzung kümmern und nicht um die Gestaltung der Oberfläche. Dabei hatte ich unterschätzt, wie wichtig ein grundlegend gutes Verständnis von Design für die Produktqualität ist. Die Realität zeigt: Nicht alle Teams haben dauerhaften Zugang zu Designexperten. Zudem ist ein Entwickler, der über Designkenntnisse verfügt, flexibler und selbstständiger, kann rascher iterative Verbesserungen vornehmen und vermeidet unnötigen Hin- und Herwechsel mit Designern bei kleineren Anpassungen.
Ich habe selbst begonnen, mich einem täglichen Design-Challenge zu widmen, Design-Systeme kennenzulernen und grundsätzliche Regeln für Barrierefreiheit und Nutzerfreundlichkeit zu studieren. Mit der Zeit hat sich das als enormer Produktivitäts- und Qualitätsboost erwiesen. Natürlich werde ich nie ein professioneller Designer sein – das ist auch nicht nötig. Ein gutes Grundverständnis reicht, um bessere Entscheidungen zu treffen, subtile Fehler zu erkennen und eine ausgewogenere Balance zwischen Ästhetik und Funktionalität zu erzielen. Besonders in Führungsrollen und bei der Zusammenarbeit mit nicht-technischen Stakeholdern sieht man, dass ein ansprechendes UI Vertrauen schafft und die Akzeptanz von Lösungen steigert. Zusammenfassend lässt sich sagen, dass der Weg zum hervorragenden Ingenieur nicht einfach darin besteht, seine Lieblingswerkzeuge oder Lieblingsparadigmen zu verteidigen.
Vielmehr macht es die Bereitschaft aus, eigene Überzeugungen regelmäßig zu hinterfragen und neue Perspektiven zu integrieren. Die vier oben beschriebenen Erkenntnisse sind nur ein Ausschnitt dieser fortwährenden Lernreise und eine Einladung an alle Technikinteressierten, ihre Komfortzonen zu verlassen und offen für Veränderungen zu bleiben. Verwirrende Software zu besitzen und aktiv zu verbessern, langweiligen aber klaren Code zu schreiben, von Beginn an auf skalierbare und performante Architekturmuster zu setzen und ein solides Designverständnis zu entwickeln – das sind Fähigkeiten, die nicht nur technisch weiterbringen, sondern auch die Zusammenarbeit im Team und den Erfolg ganzer Produkte garantieren.
