Code istKommunikation.
Gute Software entsteht nicht nur durch Syntax, Frameworks und Skill. Sie entsteht, wenn Menschen klar denken, ehrlich kommunizieren und Verantwortung für gemeinsame Entscheidungen übernehmen.
Klarheit ist hilfreicher als Gefälligkeit.
Zusammenarbeit wird schwierig, wenn jeder zu allem Ja sagt. Genauso schwierig wird sie, wenn ein Nein ohne Erklärung kommt. Professionell ist beides: zustimmen können und Grenzen klar kommunizieren können.
„Ja, das kann ich machen.“
Wenn Umfang, Ziel und Konsequenzen klar sind.
„Ja, irgendwie geht das schon.“
Wenn du bereits weißt, dass daraus technische Schulden oder falsche Erwartungen entstehen.
„Nein, so würde ich es nicht bauen.“
Wenn du erklären kannst, warum – und eine bessere Alternative mitbringst.
„Nein.“
Ohne Kontext, Erklärung oder Bereitschaft, gemeinsam eine Lösung zu finden.
Skill bringt dich ins Projekt.Mentalität hält das Projekt gesund.
Ein technisch starker Entwickler kann ein Projekt trotzdem schwierig machen. Gute Zusammenarbeit braucht Offenheit, Verlässlichkeit, Lernbereitschaft und die Fähigkeit, Probleme anzusprechen, bevor sie groß werden.
Klar kommunizieren
Probleme früh ansprechen. Erwartungen konkret machen. Entscheidungen verständlich begründen.
Lesbaren Code schreiben
Code wird viel häufiger gelesen als geschrieben. Gute Namen und klare Strukturen sparen Teamzeit.
Mitdenken statt nur umsetzen
Nicht jede Anforderung ist automatisch die beste Lösung. Gute Entwickler fragen nach dem Warum.
Verantwortung teilen
Ein Projekt funktioniert besser, wenn Wissen nicht in einzelnen Köpfen oder Dateien verschwindet.
Prinzipien sind kein Selbstzweck.
SOLID bedeutet nicht, jedes kleine Projekt mit zehn Schichten Abstraktion zu überziehen. Die Prinzipien helfen dabei, Änderungen, Abhängigkeiten und Verantwortung bewusst zu strukturieren.
Single Responsibility
Eine Komponente, Klasse oder Funktion sollte einen klaren Grund haben, sich zu ändern.
Open / Closed
Guter Code lässt sich erweitern, ohne dass du ständig bestehendes Verhalten zerlegen musst.
Liskov Substitution
Abstraktionen sollten austauschbar bleiben, ohne überraschende Seiteneffekte zu erzeugen.
Interface Segregation
Kleine, klare Schnittstellen sind meist besser als große Verträge, die niemand vollständig braucht.
Dependency Inversion
Kernlogik sollte nicht unnötig an konkrete Details gekoppelt sein.
Nicht einfach Features abhaken.Sondern gemeinsam gute Entscheidungen treffen.
Ich möchte verstehen, was das eigentliche Ziel ist. Ich sage, wenn ich etwas anders sehe. Ich erkläre Entscheidungen. Und ich möchte Code hinterlassen, den man morgen noch verstehen und weiterentwickeln kann.
Gute Software ist nie wirklich „fertig“.
Anforderungen ändern sich. Teams verändern sich. Wissen wächst. Deshalb sollte Code so gebaut sein, dass Veränderung möglich bleibt.