Arbeits-Rant

[Frustrierter Coder]

Hallo,
Ich muss mir einfach mal irgendwo bezüglich meiner Arbeit Luft machen, weil das jetzt schon eine Weile an mir frisst.
Ich bin seit ein paar Jahren als Softwareentwickler bei einem KMU. Mein erster "richtiger" Job nach dem Studium, aber ich hatte vorher schon etwas Praxiserfahrung durch Praktikum und Studentenjobs.
Anfangs scheinbar ein Glückstreffer, weil die Firma cutting-Edge Technologie entwickelt und interessante Produkte hat, ausserdem trotz der geringen Grösse sehr international ist. Die Arbeitsatmosphäre ist entspannt, die meisten Kollegen in Ordnung und die Aufgaben eigentlich interessant.
Die Firma gibt es schon eine Weile und es gibt einen harten Kern von älteren Mitarbeitern. Ich glaube früher hat die ganze Arbeit auf Zuruf funktioniert. Jeder wusste alles, die Produkte waren übersichtlicher und Prozesse und Strukturen nicht unbedingt nötig.
Jetzt ist die Firma deutlich gewachsen und es gibt mehr und vor allem auch komplexere Produkte. Am Management hat sich leider nichts geändert. Es gibt kaum niedergeschriebene Anforderungen oder funktionierenden Prozesse, aber die Führungsebene ist ständig der Meinung dass Dinge doch ganz offensichtlich sind und jeder davon wissen müsste und überhaupt hätte man dieses und jenes doch schon vor Monaten entschieden (aber natürlich nicht aufgeschrieben und zwischendrin noch dreimal die Meinung geändert).
Der Zustand der Codebasis und der Entwicklungsumgebung ist gruselig. Furchtbar zusammen geschusterter Code, der kaum lesbar, wartbar oder testbar ist. Häufig sehr alte Tools und Paradigmen oder einfach des Fehlen davon (jeder benutzt und macht was er selbst für richtig hält).
Wir (also einige der "jüngeren" Entwickler) haben viel Energie reingesteckt die Situation zu verbessern aber das ist ein Kampf gegen Windmühlen.
Was mich am stärksten belastet ist aber, dass ich ein sehr introvertierter (nicht schüchterner) Mensch bin, der Probleme eher ruhig und sachlich bespricht, während meine Vorgesetzten extrem extrovertiert sind und selbst die banalste Diskussion zur Eskalation treiben. Der Chef hat einen Diskussionsstil wie Michel Friedman und wird dafür von allen gefürchtet. Da ich mich in solchen Diskussionen auch nicht einfach wegdrücken lasse, sind wir da schon mehrfach aneinander geraten.
Die Firma leidet an starkem Personalmangel, vor allem in der Softwareentwicklung. Hier sind in letzter Zeit immer wieder Leute gekommen und nach kurzer Zeit wieder gegangen. Falls noch einer der wichtigeren Entwickler geht (beispielsweise ich *hust*), kann das entsprechende Produkt eigentlich von niemandem mehr weiter entwickelt werden. Allerdings bezweifele ich, dass das "oben" schon wirklich realisiert wurde.

Was also tun? Wenn ich gehe zieht das wahrscheinlich gleich noch eine Kündigung nach sich (oder andersrum) und ich lasse den Laden platzen. Noch habe ich auch kein wirklich interessantes Angebot gesehen, aber *irgendwas* würde ich problemlos finden. Ich mache mir auch keine Illusionen, dass es woanders wirklich besser, höchstens anders.
Ich kann natürlich auch weiter hier bleiben und Dienst nach Vorschrift machen. Denn wenn man nicht gerade mit den Vorgesetzten diskutieren muss oder sich Gedanken über das Big Picture macht ist es eigentlich ganz gemütlich und entspannt...

[Marscel]

Gibt es nicht so etwas wie einen Abteilungs-, Entwicklungsleiter oder CTO, der zwischen dir und dem Management steht oder ist das der Friedman?

Ansonsten: Versauert dir die Situation hinreichend die Laune auf den Montag? Ja? Dann geh.

[Mortalvision]

Hört sich nach klassischem Fehler an: it-startup das cool und informell startet. Flache Hierarchie. Dann wird fett expandiert und was passiert? Die Chefs fangen das Träumen an und kümmern sich nicht mehr um Details. Höchste Zeit, eine mittlere Management-Ebene einzuführen! Das bringt dann eine U-Form Hierarchie, und stabilisiert die Firma.

Du als Mitarbeiter kannst das nicht entscheiden. Aber schreib mal auf, was ständig schief geht und deiner Meinung nach warum. Und das Legst du jede Woche dem Geschäftsführer auf den Tisch. Ändert sich nichts, schau dich schleunigst nach einem neuen Arbeitsplatz um :-)

[Mosher]

Ich arbeite auch in einem kleinen Unternehmen mit <50 Mann, wo es gewisse Defizite bei Abläufen und Prozessen gibt. Das machte sich v.a. in den letzten beiden Jahren bemerkbar, als wir personell fast um 50% gewachsen sind.
Vor allem die jungen Mitarbeiter (80% sind um die 30, der Rest "alte Hasen") machen auf Miss- und Rückstände aufmerksam, kümmern sich aber selbst darum.
Die Aussage des Geschäftsführers zu dem Thema ist sinngemäß "Ich werde jetzt meine Projekte nicht umstrukturieren, denn wenn ich aussterbe, habt ihr eh freie Hand. Ich werde mich aber auch nicht in eure Neuerungen einmischen. Wenn ihr umstrukturieren wollt, dann tut es"

Als Folge dessen haben wir eine ziemlich starke QM-Struktur, die auch von diversen SiGs und Arbeitskreisen weiterentwickelt wird. Die Mitglieder dieser Arbeitskreise sind eben zumeist wir jüngeren Mitarbeiter. Im Grunde ist jeder zufrieden mit dieser Regelung und die Dinge bekommen Dynamik. Es herrscht das Prinzip der Eigeninitiative und ich würde sagen: Mit großem Erfolg.
Klar binden solche Gruppen auch wertvolle Ressourcen, aber die Erfahrung hat gezeigt, dass es sich einfach lohnt. Spätestens dann, wenn das nächste Audit kommt, das nächste Zertifikat erworben werden soll, merkt man deutlich, welchen Vorteil diese QM-Struktur hat.
Kein Zittern mehr, keine Panik, keine last-minute-Hingewurschtel.
Die investierte Zeit zahlt sich also schnell wieder aus und vor allem Quereinsteiger können sehr viel schneller in laufende Projekte integriert werden. Ebenso gewinnen unsere Projektpartner Vertrauen in uns und loben uns für unsere effiziente Struktur.

Als krasses Gegenteil möchte ich hier ein kleines (ca. 20 Mitarbeiter) Unternehmen anführen, mit dem wir seit 2 Jahren zusammenarbeiten.
Dort gibt es keine erkennebare Hierarchie, die linke Hand weiß nicht, was die rechte tut.
Die Truppe besteht fast ausschließlich aus Entwicklern + einem, "der die Kohle hat" und einer Empfangsdame. Alles junge, nette, intelligente Typen, aber kaum Struktur dahinter.
Stelle ich eine Anfrage, bekomme ich von 3 Personen 3 verschiedene Aussagen und Dokumente mit 3 verschiedenen Versionsnummern. Teils wartet man 1-2 Tage auf eine definitive Aussage, während derer die Arbeit de facto still steht.
Dann soll man plötzlich am Samstag Nachmittag schnell nach sonstwohin fliegen, weil irgendwo "unerwartet" Engpässe auftreten und man dringend Support braucht. Dann steht man da, soll die hastig auf einen USB-Stick kopierte Software auf ein bestehendes System einspielen: Error.
Wieder Anruf, "ach ja, war die falsche Firmware, sorry". Usw. usf.
Ein Tag Außeneinsatz kostet ca. 1000-1500€. Das Geld könnte man sicher besser investieren, zB in zusätzliches Personal, das mal die Strukturen etwas auf Vordermann bringt.

Ich als Entwickler habe natürlich auch meinen Entwicklerstolz und eine winzige klischeehafte Abneigung gegen "BWLer-Fuzzis" und "Dampfplauderer QM-Labersäcke", aber im Laufe der Zeit wurde mir einfach klar: Man braucht diese Leute. Dringend. Aus deren Richtung muss gewisser Druck kommen, damit die Sache läuft.

Die meisten Anreize kommen natürlich nach wie vor von den Entwicklern selbst und in oben angesprochenen Arbeitsgruppen wird auch selbst ein Konzept erarbeitet und niedergeschrieben, aber der QM-Typ muss das dann noch in irgendwelche normgerechte Prozesse verpacken, in's QM-Handbuch schreiben und werbewirksam darstellen. Um solche Sachen wollen wir uns nicht kümmern, das ist dann eben das angesprochene "Dampfplaudern", aber wir sind dankbar, dass es jemand macht.
Und natürlich freuen wir uns dann gemeinsam, wenn mal wieder irgendein Audit glatt über die Bühne ging etc.

Zur Situation des TS:
Ich lese bei eurer Firma so eine gewisse "Das hat schon immer so funktioniert, wieso soll es das jetzt nicht mehr?"-Haltung raus.
Im Grunde nicht so anders, als das, was unser Senior sagt, nur mit dem Unterschied, dass er uns Jungspunden trotzdem die Freiheit lässt, selbst aktiv zu werden.
Vielleicht wäre das ja ein passendes Konzept für euch?
3-5 Leute setzen sich 1 mal die Woche für 90 Minuten zusammen und überlegen sich was.
Man kann das ja zunächst mal als einmalige Aktion planen und die Ergebnisse dann dem Chef vorlegen. Wenn man dann immer noch auf taube Ohren stößt, obwohl man sich gemeinsam sinnvolle Punkte erarbeitet hat: Geh' bitte. Du wirst dich sonst nur ärgern.

Also im Grunde das, was Mortalvision sagt, nur eben in tl;dr-Fassung ^^

[GBWolf]

Die Wahrheit ist. Wenn du gehst kommt jemand anders. ;)

[Haarmann]

Frustrierter Coder

Ihr habt zuwenig Leute und Du machst diesen überlasteten Leuten den Vorschlag mehr Leerlauf, Prozesse genannt, einzuplanen und wunderst Dich, dass deren Begeisterung für diesen Vorschlag gegen Null tendiert?

Solche Prozesse kannst in Grossbetrieben problemlos definieren - es sei denn die Leute müssen einen Leistungsgrad halten und der beinhaltet keine Prozesse...

Ich vermisste auch immer das Element - nutzlose Tätigkeit für Controller und sonstige nutzlose Menschen in der Firma. Das frass bei uns sauber 20% Arbeitszeit.

An der Uni lernt man noch Vieles, was in der Praxis nicht anwendbar ist, weil man dort unter Druck steht.

Sah man bekanntlich an den Ergebnissen der praktischen Anwendung... Gruppen, welche nach "Vorschrift" vorgingen kriegten in der Zeitvorgabe nichtmals nen Splashscreen hin - oder einfacher ausgedrückt - gar nix.
Wir verzichteten auf den Mist und hatten was vorzuweisen - der Kunde wählte - oh Wunder - unser Produkt.
Aber auch dieses musste nach einigen Jahren im Prinzip neu geschrieben werden, weil die Basis nicht mehr weiter existierte und Niemand so doof sein kann alten Code umschreiben zu wollen.

[noid]

Die Wahrheit ist. Wenn du gehst kommt jemand anders. ;)

Das ist richtig.

Aber die genannten Probleme sind aus meiner Sicht wohl in _jeder_ Firma _irgendwann_ vorhanden. Die einzige Lösung ist quasi "junge" - oder besser mental flexible - Leute in leitenden Positionen zu bekommen. Das müsste eigentlich von der Firma her kommen, bzw. sollte man schauen was denn die Firma mit einem vorhat.
Nur so kann man moderne Entwicklungsmethoden einbringen.

Aber wie sagte mein Kollege so schön? "Maybe all the easy software is being written." Bei uns sind in den letzten 10Jahren die Systeme gewaltig in Anforderungen und Komplexität expandiert. Bei einigen Personen ist aber nichts davon angekommen.

PS: http://www.stepstone.de/stellenangebote--ENTWICKLUNGSINGENIEUR-m-w-MANNHEIM-John-Deere-GmbH-Co-KG--3487777-inline.html?&cs=true&ssaPOP=1&ssaPOR=1

https://jobs.ingenieurkarriere.de/job/6014026/entwicklungsingenieur-m-w-/

usw.
Gerne auch Fragen per PN an mich. ;)

[00-Schneider]

Ich kann natürlich auch weiter hier bleiben und Dienst nach Vorschrift machen. Denn wenn man nicht gerade mit den Vorgesetzten diskutieren muss oder sich Gedanken über das Big Picture macht ist es eigentlich ganz gemütlich und entspannt...


This. DnV machen und sich in der Zwischenzeit was Anderes suchen. Nicht kündigen, bevor du nichts Neues hast. Vielleicht auch mal einen gelben Schein einreichen um auszuspannen und den Kopf frei zu bekommen.

[PHuV]

Aber die genannten Probleme sind aus meiner Sicht wohl in _jeder_ Firma _irgendwann_ vorhanden. Die einzige Lösung ist quasi "junge" - oder besser mental flexible - Leute in leitenden Positionen zu bekommen. Das müsste eigentlich von der Firma her kommen, bzw. sollte man schauen was denn die Firma mit einem vorhat.
Nur so kann man moderne Entwicklungsmethoden einbringen.
Da muß ich widersprechen. Gerade unsere Firma hat viele "alte" Hasen, die erfolgreich überall da eingesetzt werden, wo die Jungen das Ruder haben und pures Entwicklerchaos herrscht, um das Chaos zu strukturieren und zu organisieren.

Aus meiner Sicht sind solche Probleme immer hausgemacht, weil man zugunsten guter Planung und Organisation einfach immer an der falschen Stelle Geld einspart. Gerade "agile" Softwareentwicklung im größeren Rahmen ist einfach meiner Meinung nach die dümmste Idee überhaupt. Das hat bisher nirgendwo so funktioniert, wie die Leute sich das dachten.

[noid]

Da muß ich widersprechen. Gerade unsere Firma hat viele "alte" Hasen, die erfolgreich überall da eingesetzt werden, wo die Jungen das Ruder haben und pures Entwicklerchaos herrscht, um das Chaos zu strukturieren und zu organisieren.

Aus meiner Sicht sind solche Probleme immer hausgemacht, weil man zugunsten guter Planung und Organisation einfach immer an der falschen Stelle Geld einspart.

Jain, halten wir einfach fest: die Alten mögen Planung bringen, die Neuen die Technik. Wobei das alt und neu eher auf Betriebszugehörigkeit bezogen ist, und nichts mit dem wirklichen Alter zu tun hat. Es gibt auch genug Entwickler, die neue Techniken/Methoden mitbringen. Jemand der seit 10Jahren das Gleiche macht ist da meistens im Nachteil.

[(del676)]

Was also tun?

Du hast 3 Optionen.
1.) weiterhin Coder bleiben und Miszstaender anklagen. Versuchen die Situation zu aendern. Damit erscheinst du in der Sicht der Manager als unzufriedener Mitarbeiter. Helfen wird es ziemlich sicher nichts.

2.) du kannst dich den Managern als Zwischenschicht aufdraengen. Sprich Teamlead fuer Programmierer. Wenn die Manager drauf anspringen, wirst du die Situation auch verbessern koennen. Allerdings wirst du noch viel mehr arbeiten muessen als zuvor. Denn du wirst nicht nur Teamlead machen, sondern jede Menge weiter programmieren, bzw versuchen andere soweit zu bringen es selbst gleich richtig zu machen.

3.) du machst deine Arbeit 8h am Tag, und fertig. Was intressierts dich, was die Chefs machen? Solange am Ende des Monats die Kohle rueberwaechst, kannst du doch auch Smilie Icons in mspaint malen, wenn sie es wuenschen.


Bis ich 28 war, habe ich Option 1 versucht. Jetzt bin ich bei Option 3, und sehr gluecklich (und mein Konto auch).

Option 2 habe ich selbst nie ausprobiert, sehe sie aber an Arbeitskollegen. Wenn du nicht gerade einen latenten Hang zum Managerposten und Workaholic hast, lass die Finger davon!

[PHuV]

Jain, halten wir einfach fest: die Alten mögen Planung bringen, die Neuen die Technik.
Auch nur ein JAIN. ;)

Was hat sich - rein in der Softwareentwicklung - in den letzten Jahren geändert? Gar nichts oder wenig. In C/C++ und Java, Scripte wie Perl, Python und Co. wird nach wie vor so programmiert wie viele Jahre davor. Sicher mit paar Anpassungen und neueren APIs, Libs etc. Das Grundprinzip ist gleich geblieben.

Was dazugekommen ist, sind so Themen wie Big Data und Big Data Analytics , ESB mit den diversen Technologien, es werden immer mehr NoSQL-Datenbanken eingesetzt. Und da stecken so wohl Neue und Alte drin. Die neue Generation bekommt das in der Uni mit, die Alten dann eben im Doing on the job in der praktischen Realisierung.

Generell sollte man immer gesund und gut durchmischen.
Du hast 3 Optionen.
:
Bis ich 28 war, habe ich Option 1 versucht. Jetzt bin ich bei Option 3, und sehr gluecklich (und mein Konto auch).

Option 2 habe ich selbst nie ausprobiert, sehe sie aber an Arbeitskollegen. Wenn du nicht gerade einen latenten Hang zum Managerposten und Workaholic hast, lass die Finger davon!
So sind auch meine Erfahrungen. In vielen Fällen wollen und können die Leute gar nicht optimieren. Also warum vergebene Liebesmüh reinstecken in etwas, was nur aufreibt. Ich optimiere und helfe da, wo es erwünscht und auch entsprechend gewürdigt wird, und bei den anderen Dingen mache ich einfach nur 3.

[Trap]

Gerade "agile" Softwareentwicklung im größeren Rahmen ist einfach meiner Meinung nach die dümmste Idee überhaupt. Das hat bisher nirgendwo so funktioniert, wie die Leute sich das dachten.
Kennst du http://agilemanifesto.org/iso/de/principles.html ? Ich hab die Erfahrung gemacht, dass "agile Softwareentwicklung" meistens allem davon widerspricht. Man schreibt das Buzzword drauf, aber macht etwas anderes und wundert sich, dass es nicht funktioniert.

Meistens scheitert es schon daran, dass man nicht mal weiß wo der Wettbewerbsvorteil durch die zu entwickelnde Software herkommen soll, sondern nur irgendjemand sein persönliches Traumschloss mit dem zugeteilten Budget baut.

Natürlich braucht man eine gewisse Planung in Großprojekten, sonst baut man BER in Software nach ;D. Dass man nicht planen soll, steht im agile manifesto auch nicht drin.

[RMC]

3.) du machst deine Arbeit 8h am Tag, und fertig. Was intressierts dich, was die Chefs machen? Solange am Ende des Monats die Kohle rueberwaechst, kannst du doch auch Smilie Icons in mspaint malen, wenn sie es wuenschen.

Ist eine Option, aber macht das wirklich glücklich, so eine Dienst-nach-Vorschrift-um-18:00-ist Schluss-mir-egal Einstellung?

Ich kann verstehen wenn der Frustrierte Coder frustriert ist wenn man ihn nicht hört und sich trotz Engagements einfach nichts weiterbewegt. Dann kann man in Option 3 verfallen, klar...aber das kanns doch auch nicht gewesen sein im Job. Wo ist denn da die Perspektive?

[noid]

Auch nur ein JAIN. ;)

Was hat sich - rein in der Softwareentwicklung - in den letzten Jahren geändert? Gar nichts oder wenig. In C/C++ und Java, Scripte wie Perl, Python und Co. wird nach wie vor so programmiert wie viele Jahre davor. Sicher mit paar Anpassungen und neueren APIs, Libs etc. Das Grundprinzip ist gleich geblieben.

Was dazugekommen ist, sind so Themen wie Big Data und Big Data Analytics , ESB mit den diversen Technologien, es werden immer mehr NoSQL-Datenbanken eingesetzt. Und da stecken so wohl Neue und Alte drin. Die neue Generation bekommt das in der Uni mit, die Alten dann eben im Doing on the job in der praktischen Realisierung.

Generell sollte man immer gesund und gut durchmischen.

So sind auch meine Erfahrungen. In vielen Fällen wollen und können die Leute gar nicht optimieren. Also warum vergebene Liebesmüh reinstecken in etwas, was nur aufreibt. Ich optimiere und helfe da, wo es erwünscht und auch entsprechend gewürdigt wird, und bei den anderen Dingen mache ich einfach nur 3.

Was sich verändert hat? Klar, die Sprach ist gleich - aber die Programmiermuster schon. Je nachdem wie man eingestiegen ist, ist es für manche Person schwer umzusteigen. Weswegen die technischen Lösungen dann oft eine hohe "technical debt" haben.
Das fängt schon bei Kleinigkeiten wie continuos integration und tests an. Die Notwendigkeit und die Vorteile sind stellenweise schwer an den Programmierer zu bringen. Auch beim Thema debugging fragt man sich wie einige Softwareentwickler überhaupt vorwärts kommen. ;(

Klar, die Sprach ist an sich die gleich. Aber ob ich eine Software plane oder zusammenfrickel ist schon ein Unterschied.

[Trap]

Ist eine Option, aber macht das wirklich glücklich, so eine Dienst-nach-Vorschrift-um-18:00-ist Schluss-mir-egal Einstellung?
Dysfunktionale Organisation ist so verbreitet, dass man auch mit Jobwechsel keine gute Aussicht auf Besserung hat. Wem es wichtig ist, dass Entscheidung im sichtbaren Umfeld sinnvoll getroffen werden, der muss selber die Entscheidungen treffen, dann sieht man die Fehler nicht mehr :biggrin:.

Bei den direkten Chefs gibt es mit Wechsel des Arbeitgebers zumindest eine Chance - deshalb auch der Spruch "people quit their bosses, not their jobs".

[Frustrierter Coder]

Gibt es nicht so etwas wie einen Abteilungs-, Entwicklungsleiter oder CTO, der zwischen dir und dem Management steht oder ist das der Friedman?
Ja, es gibt eben den Leiter der Softwareabteilung, aber der hat zusammen mit dem Chef die Firma aufgebaut und ich sehe ihn da nicht wirklich als Mittelsmann. Außerdem liegt es ja gerade in seiner Verantwortung dafür zu sorgen, dass die Entwickler vernünftig arbeiten können und innerhalb der Abteilung gewisse Standards und Prozesse eingehalten werden.
Leider passiert da nichts weiter. Er betreibt Management auf Zuruf, verteilt unklare Aufgaben und versucht selbst noch möglichst viel zu Programmieren.
Er ist auch für die Einstellung neuer Softwareentwickler zuständig. Die Stellenanzeige ist inzwischen schon mehrere Jahre alt, enthält jede Menge Unsinn und ist schlichtweg irreführend. Ich habe ihn schon mehrfach darauf angesprochen und jedes mal hieß es sinngemäß "Oh, das steht da noch? Ja, das müssten wir mal ändern...". Und ich habe auch mitbekommen, dass manche Bewerbungen wochen- und monatelang liegen geblieben sind.

Ansonsten: Versauert dir die Situation hinreichend die Laune auf den Montag? Ja? Dann geh.
Ich sage mal so: wenn ich eine Weile in Ruhe arbeiten kann, bin ich sehr zufrieden. Aber alle paar Wochen kommt wieder so ein Punkt, meistens aufgrund einer furchtbaren Diskussion, wo ich am liebsten das Handtuch werfen würde.


Zur Situation des TS:
Ich lese bei eurer Firma so eine gewisse "Das hat schon immer so funktioniert, wieso soll es das jetzt nicht mehr?"-Haltung raus.
Ja, das ist sicherlich die Haltung. Ich glaube die Leute haben schlichtweg keine Vorstellung wie produktiv man in einer vernünftigen Umgebung arbeiten kann. Sie haben ja außer ihrer eigenen Firma und ihrem ganzen selbstgestrickten Zeug auch noch nichts anderes gesehen.
Wir haben einen neuen Kollegen, der aus einer anderen Firma zu uns gekommen ist. Der jammert ständig rum wie mühselig alles ist und das Aufgaben, für die er sonst eine Stunde gebraucht hätte, bei uns schnell einen ganzen Tag schlucken.

Im Grunde nicht so anders, als das, was unser Senior sagt, nur mit dem Unterschied, dass er uns Jungspunden trotzdem die Freiheit lässt, selbst aktiv zu werden.
Vielleicht wäre das ja ein passendes Konzept für euch?
3-5 Leute setzen sich 1 mal die Woche für 90 Minuten zusammen und überlegen sich was.
So etwas versuchen wir und wir haben schon einige Fortschritte gemacht. Aber das frisst natürlich jede Menge Zeit und Energie die wir eigentlich für die Entwicklung brauchen. Und man merkt immer wieder, dass diese Verbesserungen nicht wirklich angenommen werden.
Wie haben beispielsweise massive Qualitätsprobleme in der Codebasis und häufig kommen wir mit Aufgaben kaum voran, weil wir ständig Fehler in schon etliche Jahre altem Code finden. Als Konsequenz versuchen wir für neuen Code Unit Tests zu schreiben, was sich auch gut bewährt hat. Aber das bleibt letztendlich unser Privatvergnügen, da wir die Testbarkeit von Code eben auch nicht gegenüber anderen Entwicklern durchsetzen können. Ganz toll wird es dann, wenn der Leiter an unserem Code mitarbeitet und sein Zeug einfach ohne Unit Tests baut - und man ständig hinter ihm aufräumen muss.

Und 5 Leute wären ja schon die halbe Abteilung ;-)
Die Wahrheit ist. Wenn du gehst kommt jemand anders. ;)
Die Firma hat massive Probleme Entwickler zu finden. Andere Abteilungen sind gewachsen, wir nicht. Stattdessen sind immer wieder Leute gekommen und gegangen. Immer wieder monatelanger Einarbeitungsaufwand - für nichts. Teils wurden auch wirklich schlechte Leute eingestellt, die dem Rest nur Arbeit gemacht haben.
Einige Mitarbeiter haben sich auch intern versetzen lassen.

Frustrierter Coder

Ihr habt zuwenig Leute und Du machst diesen überlasteten Leuten den Vorschlag mehr Leerlauf, Prozesse genannt, einzuplanen und wunderst Dich, dass deren Begeisterung für diesen Vorschlag gegen Null tendiert?
Ich verstehe natürlich das Problem. Man hat schon zu viel zu tun und will sich nicht noch mit Restrukturierungsaufgaben aufhalten. Aber je länger man wartet, desto schlimmer wird es. Es gab immer wieder Punkte, an denen uns irgendwas zu sehr genervt hat. Dann hat sich jemand 2-3 Tage hingesetzt und das Problem zu lösen und das hat allen das Leben erleichtert. Und genau so sollte es laufen, iterativ eine Baustelle nach der anderen zumachen.
Wenn ich von Prozessen spreche, dann meine ich auch keine Bürokratie wie in einem Großkonzern. Aber im Moment gibt es so gut wie nichts. Kaum Dokumente in denen irgendwas festgehalten ist, keine regelmäßigen Meetings um alle auf den gleichen Stand zu bringen und jegliche angestrebte Releasedates sind quasi bedeutungslos.
Leerlauf haben wir im Moment aus anderen Gründen ständig.
Beispielsweise benutzen wir Versionsverwaltung, aber ohne Branches. Möchte man einen Teil seiner Arbeit committen oder ein anderes Feature reinziehen, holt man sich regelmäßig irgendwelches anderes halbgares Zeug rein, was man gar nicht wollte. Und dann ist man wieder Stunden damit beschäftigt, die Fehler zu finden.

2.) du kannst dich den Managern als Zwischenschicht aufdraengen. Sprich Teamlead fuer Programmierer.
Es gibt schon so eine Rolle auf Produktebene. Aber das ist dann nur die technische Leitung für das jeweilige Produkt und Leute haben letztendlich auch keine Macht Dinge zu ändern, die über den eigenen Code hinausgehen.

[Frustrierter Coder]

Auch nur ein JAIN. ;)

Was hat sich - rein in der Softwareentwicklung - in den letzten Jahren geändert?
Also wenn du mit "in den letzten Jahren" die letzten 15-20 Jahre meinst - eine Menge.
Anno dazumal hat man noch viel in C geschrieben, was heute in C++ umbesetzt wird. Vieles was damals C++ war ist heute Java oder C# und das imho aus gutem Grund. Statt Fat Clients ist vieles Web-basiert. Es liegen Welten zwischen den heutigen und damaligen Entwicklungsumgebungen.
Aber wenn man natürlich immer noch C-mit-Klassen im Editor zusammen hackt, makefiles von Hand strickt, kaum Bibliotheken verwendet und sich von CVS nicht lösen kann, hat man meiner Meinung nach einfach den Anschluss verpasst.

[Morale]

Wo ist denn da die Perspektive?
Wie viele Menschen arbeiten im öD? ;)

btw 18 Uhr, da hat man doch schon 1-3 Überstunden.
DnV ist Ende nach Arbeitszeit, gut wenn man erst um kurz vor 10 Uhr kommt...

[Mosher]

Was sich verändert hat? Klar, die Sprach ist gleich - aber die Programmiermuster schon. Je nachdem wie man eingestiegen ist, ist es für manche Person schwer umzusteigen. Weswegen die technischen Lösungen dann oft eine hohe "technical debt" haben.
Das fängt schon bei Kleinigkeiten wie continuos integration und tests an. Die Notwendigkeit und die Vorteile sind stellenweise schwer an den Programmierer zu bringen. Auch beim Thema debugging fragt man sich wie einige Softwareentwickler überhaupt vorwärts kommen. ;(

Klar, die Sprach ist an sich die gleich. Aber ob ich eine Software plane oder zusammenfrickel ist schon ein Unterschied.
Zudem vermute ich, dass es dem TS nicht unbedingt nur um diese technischen Aspekte ging, sondern einfahc um fehlende Prozesse.
Also irgendwas in der Kette Anforderung-Planung-Entwurf-Design-Umsetzung-Review-Relase scheint zu haken, nehme ich an.

Das kann schon sowas simples wie Dateinamenkonventionen sein, oder die Bennenung von Zweigen und Ästen. Rein formelle Dinge, die bei kleinen Projekten tatsächlich keine Rolle spielen, bei größeren allerdings den Unterschied zwischen Erfolg und Misserfolg ausmachen.

Beispiel jetzt aus der Elektronikentwicklung:

Eine Zeit lang hatte jeder seine Privatbibliothek an Bauteilen für Schaltplan und Platinenlayout. Schön und gut, jeder richtet sich ein, wie er sich am wohlsten fühlt. Nach und nach wurde dieses System aber auf eine Datenbankbibliothek umgestellt, so dass jedes Bauteil, das von einem Mitarbeiter angelegt wird, in dieser Datenbank landet und fortan für jeden zugänglich ist. Der Chef verwendet nach wie vor seine Privatlib., da er keinen Bock hat, sich in das neue System einzuarbeiten, lässt aber uns die Freiheit, diese Bibliothek zu pflegen und zu erweitern. Teil des Prozesses ist, dass jedes einzelne Bauteil - und sei es ein hundsordinärer SMD-Widerstand - nach dem 4-Augen-Prinzip überprüft und schließlich freigegeben wird.

Hört sich pingelig und zeitaufwendig an, lohnt sich aber auf lange Sicht enorm.

Beim Softwareteil ist es ähnlich. Da gibt es ganz klare Strukturen, wann und wie ein Modul freigegeben wird und dabei geht es noch nicht mal um technische Aspekte, sondern erstmal nur um Ordnung und Struktur. Klar, viele Programmierer neigen dazu, irgendwie ihr eigenes Süppchen zu kochen und ihren eigenen "Stil" zu pflegen und auf technischer Seite dürfen sie das auch, so lange sie sich bei der Entwicklung an den Prozess halten.

Fehlen solche Prozesse, hat wieder jeder irgendwo seine eigenen Schnipsel herumliegen, es gibt vielleicht kurz vor knapp mal ein Review, wo dann festgestellt wird, dass man sich schon seit 2-3 Versionen vom Kundenwunsch entfernt hat. Ich finde, jeder sollte sowas mal direkt erleben und dann noch mal entscheiden, ob solche strengen Prozesse wirklich überflüssig sind.

[RMC]

Wie viele Menschen arbeiten im öD? ;)

btw 18 Uhr, da hat man doch schon 1-3 Überstunden.
DnV ist Ende nach Arbeitszeit, gut wenn man erst um kurz vor 10 Uhr kommt...

9 to 5 oder 10 bis 18 Uhr, sind doch nur Hausnummern. Du weißt doch worum es geht ;)

Im öffentlichen Dienst, ja das muss man mögen. Wenn man keine Perspektiven will, geht man dorthin. Aber wir haben hier ein KMU in der Privatwirtschaft und einen Frustrierten, der offenbar noch einiges vor hat und die Wurschtigkeit (noch) nicht siegen lassen will.

[(del676)]

aber das kanns doch auch nicht gewesen sein im Job. Wo ist denn da die Perspektive?

Was denn sonst?
Ich gehe arbeiten, damit ich Geld bekomme.
Damit ich ein Dach ueberm Kopf habe, damit ich Essen habe, damit ich Hobbies ausueben kann.
Natuerlich kannst dich jetzt in die Arbeit reinsteigern, und am Ende dann ein paar 100er mehr verdienen. Aber wofuer?
Fuer weniger Freizeit und zu Lasten der Gesundheit? Nein Danke!

[RMC]

Natuerlich kannst dich jetzt in die Arbeit reinsteigern, und am Ende dann ein paar 100er mehr verdienen. Aber wofuer?

Muss nicht unbedingt wegen der Kohle sein, aber einfach deshalb um etwas bewirken zu wollen. Wegen dem Gefühl, dass das Projekt deswegen ein Erfolg wurde, weil man selbst _nicht_ sich wie die anderen einen faulen Lenz gemacht hat. Wegen der Anerkennung, Selbstverwirklichung - da wären wir bei Maslow, denn wir haben bei den meisten IT Jobs ja nicht unbedingt nur die Grundversorgung im Hinterkopf. Das Privileg haben viele leider nicht, aber Softwareentwickler nagen jetzt nicht unbedingt am Hungertuch.

[(del676)]

Wer sagt denn, dass Dienst nach Vorschrift ein fauler Lenz ist? Sonst noch alles gesund bei dir?

Anerkennung? Selberverwirklichung? Im Buero? Bei der Arbeit?
Nein Danke!

Und was soll das eigentlich heissen? Anerkennung? Von wem, deinem Vorgesetzten? Gibt dir das persoenlich echt was?
Waer ja nicht so, als waer jeder 0815 Angestellte ein Elon Musk. :rolleyes:

[RMC]

Wer sagt denn, dass Dienst nach Vorschrift ein fauler Lenz ist?

Nennen wir es halt eine "ruhige Kugel schieben". Du warst auch sehr plakativ wenns um deine Smilies ging.

In der IT die ich als Softwareentwickler kenne, wird bei den Gehältern normal etwas mehr erwartet als Dienst nach Vorschrift. Das ist jetzt kein Plädoyer für Crunchtime und Überstunden, ganz sicher nicht.

Trotzdem gibts solche, die sich dahinterklemmen und das Quäntchen extra leisten und die Dinge am Laufen halten. Und dann gibts jene, die nur das machen was man ihnen sagt auf Punkt und Strich, nicht mehr nicht weniger.

Und was soll das eigentlich heissen? Anerkennung? Von wem, deinem Vorgesetzten? Gibt dir das persoenlich echt was?

zB das, oder von Kunden. Wenn man weiß, dass Kunden das Feature besonders gefällt welches man selbst designed und umgesetzt hat, dann gibt das für manche dem eigenen Tun mehr Sinn und können darin aufgehen oder sich auch Verwirklichen. Ist nun wirklich nicht so schwer zu verstehen.

[Mosher]

Wer sagt denn, dass Dienst nach Vorschrift ein fauler Lenz ist? Sonst noch alles gesund bei dir?

Anerkennung? Selberverwirklichung? Im Buero? Bei der Arbeit?
Nein Danke!

Ok, dann siehst du es halt nicht so, na und?

Ich liebe meine Arbeit, fühle mich dort sau wohl und habe tatsächlich Spaß an dem, was ich tue. Da ich meine Überstunden ausbezahlt bekomme, bzw. abfeiern kann, macht es mir auch nichts aus, mit anderen tapferen Mitstreitern ab und zu länger im Büro zu bleiben und anschließend noch ein Bier trinken zu gehen, wenn man mal wieder ein Projekt abgeschlossen hat.

Mich freut es sehr, Teil eines Teams zu sein, mit dem ich menschlich und fachlich gut auskomme (Das ist normalerweise sehr schwierig für mich, weshalb ich die jetzige Firma als absoluten Glückstreffer bezeichne), mit dem ich gemeinsam Erfolge feiern kann und jeden Tag was zu lachen habe.
Und schon sitzt man nicht nur seine 40 Stunden ab, sondern freut sich sogar manchmal regelrecht auf die Arbeit. Wenn dann auch noch die Bezahlung stimmt (die sicherlich etwas niedriger ist, als bei Großkonzernen in der Branche, aber immer noch sehr gut), was kann man sich dann eigentlich noch besseres wünschen?

Für mich wäre es jedenfalls der Untergang, müsste ich in einer Firma arbeiten, bei der ich eigentlich nur meine Zeit absitze. Ich meine, wenn ich schon quasi 1/3 meines Lebens im Büro verbringe, dann soll es mir gefälligst auch taugen und nicht nur meinen Kontostand erhöhen.

Ich weiß, das sieht jeder anders, aber ich kann es einfach nicht verstehen, wie man es schlechtreden kann, wenn einer Spaß an seinem Job hat und sich mit seiner Aufgabe identifizieren kann. Entweder es ist sowas wie Neid, Ignoranz oder man hat einfach noch nie die Erfahrung gemacht, dass es auch anders gehen kann.

Und dann gäbe es noch Leute wie MW, die diesen Leistungsgedanken wohl nie verstehen werden und für die jeder, der mal 5 Minuten länger bleibt, gleich eine dumme Arbeitsdrohne ist.

[myMind]

Du hast 3 Optionen.
1.) weiterhin Coder bleiben und Miszstaender anklagen. Versuchen die Situation zu aendern. Damit erscheinst du in der Sicht der Manager als unzufriedener Mitarbeiter. Helfen wird es ziemlich sicher nichts.
Davon würde ich auch dringend abraten. Wenn Du nur noch als notorischer Nörgler und Bremser wahrgenommen wirst - auch wenn dir nichts ferner liegt - dann kannst Du gar nichts mehr ändern.

2.) du kannst dich den Managern als Zwischenschicht aufdraengen. Sprich Teamlead fuer Programmierer. Wenn die Manager drauf anspringen, wirst du die Situation auch verbessern koennen. Allerdings wirst du noch viel mehr arbeiten muessen als zuvor. Denn du wirst nicht nur Teamlead machen, sondern jede Menge weiter programmieren, bzw versuchen andere soweit zu bringen es selbst gleich richtig zu machen.
Das macht nur ein sehr dummer Teamleiter. Ein vernünftiger Teamleiter sucht sich gute Leute, hält sich beim Programmieren komplett heraus, sorgt dafür dass Probleme aus dem Weg geschaft werden und stellt die Teamleistung gegenüber anderen positiv dar. Leider hat der Teamleiter von Frustrierter Coder das so überhaupt nicht begriffen.

Aus meiner Sicht sollte sich jeder ITler/Informatiker immer mal wieder die Frage stellen, ob er den Schritt in die Leitungsfunktionen möchte und wenn ja, dann auch konsequent den Schritt tun. Nichts ist schlimmer als eine Führungspersonal, das nicht führt, sondern meint die Arbeit des Teams machen zu müssen.

3.) du machst deine Arbeit 8h am Tag, und fertig. Was intressierts dich, was die Chefs machen? Solange am Ende des Monats die Kohle rueberwaechst, kannst du doch auch Smilie Icons in mspaint malen, wenn sie es wuenschen.
Wenn das am Ende bedeutet, dass man nur noch Misserfolge hat, wäre das nichts für mich. Oder alternativ einen Job machen der praktisch gar keine Auswirkungen hat? Langweilig. Ich könnte mit der Einstellung morgens nicht aufstehen. Auf der anderen Seite finde ich es richtig, wenn nach 8h dann eben auch Schluss ist. Es ist ein ganz trauriges deutsches Kapitel, dass man hierzulande häufig Engagement mit langen Arbeitszeiten gleich setzt.


Man kann eigentlich kaum einen pauschalen Ratschlag geben. Ein Konfrontationskurs ist jedenfalls selten gut.

Menschen mit leitender Funktion strotzen oft vor Selbstverliebtheit, gefühlter Unfehlbarkeit und leiden unter der Wahnvorstellung allein durch Worte selbst physikalische Gesetze außer Kraft setzen zu können. Ohne diesen unerschütterlichen Glauben könnten sie in ihrer Position auch nicht überleben. Das ist für Frustrierter Coda offenbar noch überraschend. Die traurige Nachricht ist, dass es an den "Friedmännern" dieser Welt definitiv keinen Mangel gibt. Auf der anderen Seite unterliegen auch sie einer ganzen Reihen von Sachzwängen. Das muss man verstehen, ist aber natürlich keine Entschludigung.

Was bedeuten Änderungsvorschläge aus Sicht des Managers?
- Untergrabung der Autorität - wurde nicht von ihm erfunden
- Kritik an den in der Vergangenheit erreichten Leistungen
- Unabwägbare Risiken durch schlecht einschätzbare Änderungen
- Mehrkosten

Die Führungskraft hat vermutlich auch ein Bild von dir (https://lh3.googleusercontent.com/-gRXpwT6i1ho/TkL8Hq3vd8I/AAAAAAAAiEI/WqeegTl_0mU/TechSeenByTech.png) mit der sie in die Diskussion hineingeht.

Eine gute Möglichkeit ist es, Verbesserungsideen zusammen zu entwickeln, selbst auf das Risiko hin am Ende nicht genau da zu landen, wo man eigentlich hinwollte. Also weniger "Ich habe eine Idee. OK für dich?" sondern mehr "Ich habe ein Problem. Kannst Du mir helfen? Dies und jenes habe ich angedacht. Weiß aber nicht weiter."
Die Besprechung am besten mit deinem Team / deinen Kollegen durchführen, die vorher in Einzelgesprächen in der Kaffeeküche oder beim Essen schon einmal positiv den Änderungen gegenüber Eingestellt worden sind.

Und ich würde langsam vorgehen, Schritt für Schritt. Immer nur genau ein Thema. Am besten mit einem Buzzword. Danach dann darstellen, was sich durch die letzte Maßnahme verbessert hat, um Vertrauen aufzubauen. Änderungen brauchen Zeit, denn sie müssen auch in den Köpfen stattfinden. Darum: Reden, reden, reden - bis es überall angekommen ist und auch von deinen Kollegen unterstützt wird.

Es gibt aber letztlich kein Rezept, wie man positive Veränderungen erwirkt. Hilfreich sind auf jeden Fall gute persönliche Beziehungen und eine starke Position, z.B. durch gute bisherige Arbeit. Was im Berufsleben nach meiner Erfahrung erstaunlich wenig Hilft, sind Argumente. Da gibt es häufig Befindlichkeiten die mehr zählen.

[HajottV]

Was im Berufsleben nach meiner Erfahrung erstaunlich wenig Hilft, sind Argumente. Da gibt es häufig Befindlichkeiten die mehr zählen.

Jau, verwirr' den armen Produktmanager, Teamleider bloß nie mit Fakten! Das können die gar nicht ab. Das ist eine sehr bittere Erkenntnis, die quasi jeder Entwickler macht. :frown:

[Mosher]

Kommt darauf an. Wir haben hier solche und solche Teamleiter. Die einen sind sehr techniknah, die anderen fast nur noch auf's Business beschränkt.

Entsprechend sind die Leute auch für unterschiedliche Argumente empfänglich und dann hat eh jeder seine eigene Persönlichkeit. Menschenkenntnis hilft da enorm ^^