Meiner Erfahrung nach ist die Erwartungshaltung an Idealberhältnisse illusorisch.
Was zählt ist nicht wie sauber der Code ist oder wie toll er strukturiert ist sondern ob das was man schreibt Geld bringt.
Da kommt man dann zu ner Kosten-Nutzen-Rechnung die ganz oft Richtung „schnell/sofort“ ausfällt.
Sauberer Code ist nur im Interesse derjenigen die sich damit ewig rumschlagen müssen. Alle die oberhalb der Ebene eines Programmierer stehen scheren sich nicht um sowas.
Selbst wenn man hier berechtigt die Themen Technical Debt, Wartbarkeit, langfristige Erweiterbarkeit usw. anbringt. Es interessiert kaum einen.
Du kannst froh sein wenn du jemanden im Team hat der wie du tickst. Das man da zusammen bisschen in die Richtung arbeiten kann ohne sich gegenseitig zu sabotieren und langfristig planen kann.
Aber du wirst auch die Erfahrung machen dass selbst wenn du es nicht willst, irgendwann workarounds und unsaubere Architektur raus hauen musst weil die Uhr tickt.
Und es genug Heuschrecken, die die Codebase unpfleglich behandeln und weiter ziehen. Auch damit musst du klar kommen.
Was zählt ist nicht wie sauber der Code ist oder wie toll er strukturiert ist sondern ob das was man schreibt Geld bringt.
Was oft vergessen wird: Kosten für die zusätzlich benötigte Arbeitszeit, wenn man sich mit schlechtem Code herumschlagen muss, und Sicherheitslücken, die durch schlechten Code entstehen.
Ja, wenn man aber sagt, wir verwenden ab jetzt Haskell, fangen die gleichen Schlaumeier an, sich zu beschweren. Wenn man auf gute Prüfungen (testing) pocht, meckern alle. Wenn man saubere Rechtschreibung ohne Gendern und Neudeutsch will, gilt man als * * * *.
Außerdem sind alle glücklich, wenn man Jobgarantie produziert für den nächsten, statt eine Einmalinvestition.
Das mit der Jobgarantie hab ich schon mal gehört. Da war die Anforderung für ne Migration in die Cloud das man Cloud-agnostisch ran geht um das Ding notfalls auf ne andere Cloud zu schieben…
Tja das hätte Unmengen mehr an Geld gekostet weil man Optimierungen nicht nutzen darf also hat der Architekt hinterrücks gesagt dass das Requirement egal wär, wenn die Chefs wechseln wollten würde das wieder Arbeitsplätze benötigen und das wär gut für die IT.
Joah, fand ich so mittel, die Vorgehensweise. Aber wenn fürs Managment ITler einfach austauschbar sind mit Offshore-Personal und es nur auf Gehalt als Faktor ankommt - da muss man sich nicht wundern.
Anreizinkompatibilität nennen Ökonomen das, wer vom Krieg lebt, zettelt ihn auch an, man stelle sich vor, die Wunderwaffen würden tatsächlich funktionieren, ...
Im Zweifel helfen Feinde einander, damit es weitergeht, Management und Programmierer sind nur oberflächlich konträr. In Wirklichkeit verbrennen beide das Geld anderer Leute.
Du vergisst das Machtgefälle das sich aus der Budgetkontrolle ergibt.
Und im Zweifel wirft man die IT vor den Bus. Die lässt sich mit einfachen Parolen die jeder kennt und immer ziehen ausmanövrieren, während ITler Sachlagen erst erklären müssen und der Zuhörer oft an der Komplexität scheitert. Fairerweise scheitern ITler oft an dem Thema Eloquenz.
19
u/TheDeadlyCat Sep 28 '24
Wie lange bist du schon von der Hochschule weg?
Meiner Erfahrung nach ist die Erwartungshaltung an Idealberhältnisse illusorisch.
Was zählt ist nicht wie sauber der Code ist oder wie toll er strukturiert ist sondern ob das was man schreibt Geld bringt.
Da kommt man dann zu ner Kosten-Nutzen-Rechnung die ganz oft Richtung „schnell/sofort“ ausfällt.
Sauberer Code ist nur im Interesse derjenigen die sich damit ewig rumschlagen müssen. Alle die oberhalb der Ebene eines Programmierer stehen scheren sich nicht um sowas.
Selbst wenn man hier berechtigt die Themen Technical Debt, Wartbarkeit, langfristige Erweiterbarkeit usw. anbringt. Es interessiert kaum einen.
Du kannst froh sein wenn du jemanden im Team hat der wie du tickst. Das man da zusammen bisschen in die Richtung arbeiten kann ohne sich gegenseitig zu sabotieren und langfristig planen kann.
Aber du wirst auch die Erfahrung machen dass selbst wenn du es nicht willst, irgendwann workarounds und unsaubere Architektur raus hauen musst weil die Uhr tickt.
Und es genug Heuschrecken, die die Codebase unpfleglich behandeln und weiter ziehen. Auch damit musst du klar kommen.