# Wie sieht für mich eine "perfekte Firma" aus?

> "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

## Persönlicher Umgang Miteinander - Diskussionskultur

* Ich wünsche mir einen positiven offenen Umgang miteinander
* Growth Mindset - Man kann aus Fehlern lernen - Fehler sind eine Chance, kein Untergang
* Wir sollten viel mehr die Möglichkeit wahr nehmen, dass etwas verbessert werden kann
* Anstatt sich herum zu ärgern, dass es nicht funktioniert und den Verantwortlichen zu finden
* Das betrifft auch wenn Fehler in existierenden Systemen gefunden wird. Dann wird irgendwas im Backend gedreht, dass es wieder funktioniert, aber selten wird das für immer behoben.
* Offener ehrlicher Umgang - Jeder sollte mal zu Wort kommen dürfen
* Keine ewigen Monologe - Jede Meinung sollte respektiert werden.
* Man sollte andere nicht vor vollendete Tatsachen stellen und sich dann ärgern, wenn man Feedback gibt sondern offen damit umgehen.
* Statt: "Jetzt muss ich es ja schon wieder ändern damit es dir passt"
* Lieber: "Oh, das habe ich nicht bedacht, gut dass du mich darauf hinweist!"

## Firmenkultur
* Regelmäßige gemeinsame Events die die Gemeinsamkeit stärken
* (2 Tage/Woche) Anwesenheit im Büro um ein besseres gemeinsames Verständnis aufzubauen (Auf Augenhöhe)

## Teamwork
* Offener Austausch zu Technologie und Vorgehen
* Uns fehlt hier die Anzahl Mitarbeiter pro Thema um hier überhaupt einen Kompromiss zu finden - keine einfache Mehrheit möglich
* Hier hätte ich lieber Konsens als individuelle Selbstverwirklichung - ich kann mich einigen, Hauptsache wir ziehen an einem gemeinsamen Strang
* Wir sind alle von einander abhängig, aber jeder arbeitet nur für sich in seinem eigenem Bereich
* Dabei haben wir Daten, Funktionen und Schnittstellen die alle betreffen:
* Das Frontend konsumiert vom Backend, Mapper und Adapter
* Das Backend konsumiert vom Mapper und Adapter
* Der Mapper konsumiert vom Adapter (und dem Backend - DB)
* Der Adapter konsumiert vom Device

## Gemeinsame Methode für den Entwicklungsvorgang
* Ein generelles Vorgehen auf das man zurückgreift - Ein Design System was das Team vertritt und einsetzt
* FP oder OOP; DDD oder BDD; Monolith oder Microservices;
* Async/Await oder Promises oder Callbacks
* Aktuell macht jeder wie er will, jeder verwendet seine eigenen Libraries und Funktionen obwohl es Überschneidungen gäbe
* Führt zu aufgeblähterem und langsamerer Software
* Es wird schwieriger Änderungen durchzuführen
* Welche Library verwendet man gemeinsam? (bwfunpro oder lodash oder ramda)
* Wenn mehr Leute die selbe Library verwenden würden, hätte man besseres gemeinsames Verständnis

## Offenheit für Veränderung -> Keine Refactorangst
* Ich rede jetzt nicht von gigantischen Änderungen die Tage dauern
* Refactoring bedeutet bestehendes kurz verbessern, damit Neues sich einfacher eingliedern lässt
* Betreiben wir kein Refactoring, wird es immer schwieriger etwas Neues in das bestehende Konstrukt einzufügen
* Das ist so als wollte man elektrische Sitzheizung, Außenspiegelheizung, und und und... aber die Lichtmaschine gibt nicht so viel her - Man muss die Stromzufuhr verbessern zuerst, bevor ich eine Einwegbatterie einbaue
* Wieso haben wir so viel Angst vor Refactoring? -> Weil jeder macht wie er mag - es gibt keinen Konsens von Tools, Methodik oder Paradigmen
* Code wird selten wiederverwendet aber trotzdem oft gelesen (Weil immerhin konsumieren wir Schnittstellen)
* Wir haben so eine Verantwortung-Schiebe Mentalität entwickelt. "Ich trau mich das gar nicht anzufassen, das soll Fabian oder Martin machen"
* Das generelle Vertrauen in den Code ist geschwächt
* Ich weiß von Code dem ich nicht vertraue, ob er funktioniert oder das tut wovon ich ausgehe. (Wundertüte)
* Ich bin auch nicht fähig oder gar befugt existierenden Code von dem ich abhänge anzupassen (Jeder baut seinen eigenen Code und verwendet nix wieder)
* Wir haben mehr oder weniger gelernt zu akzeptieren: Wenn da etwas gemacht werden muss, dann muss da jemand anders ran.
* Das Resultat: Es ist enorm nervenzehrend sich gegenseitig zu unterstützen.
* Refactoring ist so ein Tabuthema bei uns geworden, dabei wissen wir gar nicht wie richtiges Refactoring aussieht.
* Refactoring ist nicht einfach nur "Ich mach den Code so wie er mir gefällt"
* Refactoring sollte es einfacher machen, relevante Änderungen und zukünftige Änderungen durchzuführen.
* Methode: for each desired change, make the change easy (warning: this may be hard), then make the easy change
* Aktuelle Lage: Jede Änderung ist enorm kompliziert und schwierig, weil wir kein Refactoring machen.
* Bei vielen Änderungen drucksen meist alle und sagen "Puh, ich weiß gar nicht wo das rein gehören würde, das wird schwierig!"
* Wir haben schon seit Jahren nicht mehr refactored - Das System ist enorm wackelig und weit aus komplizierter als notwendig.
* Wenn wir uns für Veränderungen versperren ist das extrem blockierend.

## Ein Team das gemeinsam an einem Thema arbeiten kann.
* Man bräuchte eigentlich für jeden Themenbereich mindestens 2 Meinungen, um sich zu einigen, dass der Baustein in das System passt und von allen genutzt und verstanden werden kann
* Wir haben kaum interne Doku (Wie benutze ich dieses Modul? Wo gehört etwas hin?)
* Wir müssen bei jeder Kleinigkeit fragen wie etwas funktioniert.
* Viel Zeit vergeht damit Code zu lesen. (Dürfen ihn aber nicht anpassen oder haben Angst davor)
* Lösung: If you've already spent (wasted) significant time understanding something, why let other readers suffer and waste time if you can simplify the code?

## Offenheit für Weiterbildung
* Fabian, Suneet und Ich sind meines Wissens nach die einzigen die sich in ihrer Freizeit selbständig weiter bilden oder Interese daran haben.
* Fabian kann es sich zwar nicht leisten auf dem neuesten Trend zu sein, da sich bei ihm bereits etablierte und bekannte Systeme ein schnelleres Liefern zulässt, aber er ist etwas offener.
* Bei Klaus ist die Akzeptanz für etwas neues relativ gering (Stetigkeit) er nennt das dann disruptiv
* Suneet bringt sich immerhin in angenehmeren Kreisen ein und ist verantwortungsbewusst bei Strahinja. Hat aber Angst vor Klaus

## Informationsaustauscnh
* Klaus hatte eine Zeit lang Angst, dass seine Dokumente im gemeinsamem Confluence Space verschwinden oder irgendwo hin geschoben werden, deswegen macht er nur noch alles in seinem eigenen Space
* Verantwortlichkeit für Dokumentation - Funktioniert das wenn jeder gleich verantwortlich ist?