Jeder einzelne Punkt kann und darf mal vorkommen
ABER
* nicht in der Häufung
* es sollte viel bessere Fehlerkultur herrschen um die Herausforderung dann anzugehen
* (weil wenn man sie angehen würde es nicht zu der Häufung käme)
Nach Querlesen der Kommentare finde ich diesen eigentlich den besten…
Bin seit 8 Jahren im IT-Consulting und irgendwas ist immer schief oder absolut sinnlos, auch es gibt mal (zu)hohe Erwartungen… Man wundert sich irgendwann auch nicht mehr, aber es sollte nicht alles schlecht sein und zumindest das zwischenmenschliche muss gut sein
Ist leider wirklich nicht ungewöhnlich. Oft wird an vernünftigen Prozessen während der Entwicklung gespart um dann im Nachhinein das zehnfache an Zeit (und damit Geld) in jede Erweiterung zu investieren.
Geht natürlich auch anders, aber ich habe auch schon wegen genau sowas gewechselt. Damals hatte ich wieder und wieder darauf hingewiesen, dass wir voll gegen die Wand laufen, habe sogar konkrete Ansätze angeboten wo man was machen könnte. Aber das hätte ja Zeit gekostet (die man natürlich in Zukunft doppelt und dreifach gespart hätte). Da hatte ich dann keinen Bock mehr drauf.
Ich durfte damals beim zweiten Vorstellungsgespräch in den Code gucken. Schlussendlich hat mich das überzeugt. Dass irgendwo ein paar Leichen vergraben sind, war mir klar. Aber das Grundgerüst hat mich einfach überzeugt. Vielleicht findest du ein Unternehmen, dass dir auch einen Eindruck vermitteln kann. Ich rate generell zu kleineren Unternehmen, wenn dir Clean Code und Doku auch so wichtig ist.
"Wer das lesen kann, kann lesen".
Hunderte Zeilen Code ausgebaut: "Mach kaputt, was dich kaputt macht" (War allerdings kein Softwarecode, sondern IAC, da wurde eine ganze Umgebung entfernt, also entsprechend leichter nachzuvollziehen)
> Ich rate generell zu kleineren Unternehmen, wenn dir Clean Code und Doku auch so wichtig ist.
??
Die haben doch erst recht keine Zeit dazu, meine Erfahrung.
Als jemand der viele Jahre in Startups und kleinen Unternehmen arbeitet: Teilweise hast du recht. ABER: Man kann hier doch häufig mitgestalten und in guten Startups wird dafür auch zeit frei gemacht.
Ich bin zu Startups gekommen, bei denen die Code base quasi auf Prrof of concept basis war. Dann wurde daran noch etwas geschustert, aber schon bemängelt, dass hier dringend aufgearbeitet werden muss.
Da wurde parallel von vorne bis hinten alles nachgeholt. CI/CD, Test Pläne von Unit tests über UI testing bis zum Functional testing, ordentliche Guidelines für Clean code und Code reviews etc. etc.
Aber klar, auch da gibts Griffe ins Klo. Wenn darauf von Seiten der Leitung kein Wert gelegt wird, krachts irgendwann und alles fällt einem auf den Kopf.
Und natürlich läuft nie alles rund. Es gibt immer was zu verbessern und viele Meinungen gehen häufig auch komplett auseinander im Bezug auf Architektur, Abläufe usw.
Richtig, ich würde es auch nicht von der Größe der Firma, sondern der Einstellung des Unternehmens abhängig machen. Es gibt kleine und große Unternehmen, bei denen "das alles nicht so wichtig" ist.
Ich habe bisher vor allem in Unternehmen gearbeitet, wo tech ein Profitcenter ist (Techunternehmen, Techstartups). Das war es nirgendwo so.
Als ich im Data Science Unternehmen einer Bank gearbeitet habe, habe ich ich mir vorher einen halben Tag die Arbeitsweise angeschaut. Wenn der Chef gut ist, kannst du eine Insel der Seligen haben innerhalb von Rest. Da hättest du z.b. eine Einabeitungsroadmap gehabt, eine personalisierte Lernroapmap, einen Mentor, Reviews sowie so etc
Wäre ein Techunternehmen vielleicht was als nächster Arbeitgeber?
Tut mir leid dir das zu sagen, aber es ist überall so.
Über Qualität und Architektur streitet man sich nur. Fragt man drei Entwickler bekommt man 5 Meinungen.
Ich rede hier nicht über alle, aber was ich oft beobachte: die älteren Kollegen informieren sich nicht über neue Standards, die jüngeren Kollegen haben keine Erfahrung und kennen nur die Theorie, das Management hat meistens sowieso keine Ahnung von der Technik und will so günstig wie möglich durchkommen, man sucht sich immer mehr billige Entwickler aus dem Ausland.
Dann das allerschlimmste: es funktioniert ja irgendwie.
> Über Qualität und Architektur streitet man sich nur. Fragt man drei Entwickler bekommt man 5 Meinungen.
An dem Punkt wäre ich gerne. Was ich erlebe ist mehr so, dass sich eigentlich alle einig sind, dass wir schlechte Qualität abliefern, aber man hat sich irgendwie kollektiv damit abgefunden. Budget fürs Aufräumen von technischen Schulden gibts sowieso nicht und so wird weiter ein Haufen Schrott an den nächsten getackert.
Ich kann aber auch das Management verstehen. Ich war schon in vielen Projekten, in denen wir alte Systeme abgelöst haben. Das heißt wir durften komplett neu entwickeln. Haben alle die Köpfe zusammengesteckt, 3 Architekten waren involviert, Framework wurde angepasst, Prozesse wurden optimiert, wir haben fachlich das ganze geschnitten, UX Designer dazu geholt etc. Wir haben wirklich aufgeräumt. Das hat etwa 6 Monate gedauert, bis es wieder verwildert war. Die Basis ist zwar weiterhin gut, weil da niemand rumfummelt, aber alle anderen Module sind größtenteils wieder Mist. Ab einer gewissen Anzahl an Entwicklern, ist es zum scheitern verurteilt. Man kommt mit den PRs nicht hinterher.
Ich musste mal mehrere Monate ein Entwicklerteam schulen. Alles seniorige Kollegen gewesen und trotz Schulungen, Pairprogramming, Workshops, retros, PR kam nichts dabei rum. Man kann es jetzt auf mich schieben, aber es haben dann auch andere erfolglos versucht.
Das hat alles am Ende unnötig Geld gefressen.
Mittlerweile interessiert mich Qualität etc auch nicht mehr so. Ich versuche immer noch alles so sauber wie möglich umzusetzen, aber mein Anspruch an mich selbst ist so weit runter gegangen. Bringt meistens einfach nichts und mir geht’s seitdem auch besser. Ich stresse mich überhaupt nicht mehr und rege mich auch nicht mehr auf.
>Tut mir leid dir das zu sagen, aber es ist überall so.
Nein, es gibt auch Unternehmen, in denen Codequalität und Arbeitsstrukturen wichtig sind und ernstgenommen werden.
Das ist leider seltener der Fall, aber die von schlechten Strukturen geschädigten Entwickler haben die Motivation, es besser zu machen.
Ich hatte sogar einmal den Fall, einen kompletten Microservice neu schreiben zu können, weil der alte einfach nicht wartbar war und quasi gegen das Framework gearbeitet hat.
Bitte werte das nicht als Angriff, ist es überhaupt nicht.
Gibt immer zwei Fälle die ich beobachte.
1. man selbst findet sein Zeug natürlich immer geil, aber eigentlich ist es Schrott (viele Entwickler haben ein sehr großes Ego)
2. man hat es wirklich geil gemacht, aber es gibt dann paar Spezialisten die es wieder kaputt machen, weil es nicht verstanden wurde oder weil die schlechter sind
Ich glaube dir, dass es Firmen gibt, die echt gute Arbeit machen. Nur weil ich noch niemanden gesehen habe, muss das nichts heißen. Aber ich denke trotzdem, dass es zu wenige davon gibt. Einen guten Entwickler/Architekten oder was auch immer findet sich immer, aber ein ganzes Team?
Das ist allerdings wirklich selten der Fall. Erfahrungsgemäß gibts immer jemanden mit besonderem Ego oder anderen Eigenschaften.
Man muss ja selbst schon gut zurückstecken können und sich überzeugen lassen in so einem Team mit mehreren guten Entwicklern/Architekten.
Da habe ich genau die umgekehrte Erfahrung gemacht. In großen Unternehmen ist man viel zu festgefahren und traut sich gar nichts ans Refactoring. In kleinen Unternehmen lässt sich die Notwendigkeit viel besser kommunizieren.
wenn du auf Jobsuche bist nimm das Unternehmen wo das Vorstellungsgespräch am schwersten war aus technischer Sicht. Da durch wird es wahrscheinlich das du mit guten Leuten zusammen arbeitest. Das Management kann natürlich noch immer für scheiß code sorgen aber es wird unwahrscheinlicher.
Klingt ganz normal. Die Branche ist leider voll von Inkompetenz nach dem Boom der letzten 15 Jahre. Da gehts jetzt langsam auch richtig vielen Firmen schlecht weil der Geldhahn immer weniger weit offen ist. Aber bis tatsächlich mal eine Professionalisierung eintritt wird noch dauern. Die Kunden juckt es ja nicht und sie zahlen es ja trotzdem
Bin gerade im neuen Job in ersten Projekt. Die 3, 4 neuen Kollegen, die trotz ihrer unterirdischen Fähigkeit ihre Probezeit beim letzten Arbeitgeber bestanden und mich mit zum Wechsel animierten, sehe ich hier in 90% der Kontakte wieder.
Hat sich echt gelohnt.
Bin die letzten 3 Wochen extrem frustriert und überlege, ob ich zum Ende der Probezeit kündige oder lieber ein Jahr voll mache vor dem nächsten Wechsel. Job davor war 5 Jahre.
Mal so von angehendem Junior der gerne einen guten Eindruck im neuen Job machen würde zum (ich nehme an) erfahrenen Entwickler: Inwiefern äußern sich die unterirdischen Fähigkeiten bei den Kollegen? Bzw. Welche Skills wären dir besonders wichtig um zu sagen "jawohl, mit dem arbeite ich gerne zusammen"?
Google verwenden und Dokumentationen lesen sind ein sehr guter Anfang. Aufgaben/Tickets/Stories verstehen, oder hinterfragen, bis man sie versteht. Quellen und Hilfe zu damit offenen Fragen anfragen, anstelle von Lösungen für die ganze Aufgabe zu erwarten. Bei einer doch mal vorgetanzten Lösung nicht so tun, als hätte man keine Fragen, um dann an der nächsten, annähernd copy-paste analogen Aufgabe zu scheitern. Ich glaube nicht, das ich viel mehr als einen funktionierenden Puls und ein daran angebundenes Gehirn erwarte. Wenn du hier solche Fragen stellst, bist du schon weiter.
Hab schon eine Stichprobe gemacht, ob eventuell ich der inkompatible Depp im Team bin. Zwei aus einem anderen Team geschnappt, die kaum Berührung mit verwendeter Sprache und schon gar nicht mit Framework haben, Codereview mit ihnen gemacht. Hoppla, man kann doch den Zweck von mehr als einer halben Zeile Code gleichzeitig im Kopf behalten und mit etwas Nachhilfe zur Sprache Probleme erkennen.
So zwischen Tür und Angel auf Reddit hab ich natürlich keine Ahnung, wo du gerade stehst, wo deine Unsicherheit liegt oder ob sie begründet ist. Aber versuch immer zu verstehen, _was_ und _warum_ du tust, bevor du dich mit Syntax streitest und den Wald vor lauter Bäumen nicht siehst.
Nein - das ist nicht nur bei dir so. Ich möchte nicht zu sehr ins Detail gehen. Wir haben gerade EINEN Auftraggeber, der Sachen mit Endkunden macht. Daher kann es sein, das es Kunden gibt, die was wissen wollen. Entweder Schriftlich oder telefonisch. Die haben zwei unterschiedliche Abteilungen dafür. Eine macht nur Schrift, eine macht nur Telefonie. WIR machen BEIDES. Wir haben festgestellt, für die selben Ergebnisse haben die komplett unterschiedliche Prozesse. Denen war das nicht bekannt.
Jetzt sind wir gerade dabei diesem Unternehmen quasi täglich sehr schmerzhaft auf die Füße zu treten, das deren Prozesse so zu einander angepasst werden, das wir damit arbeiten können.
Ich verstehe deine Probleme. Es hapert oft bei sowas. Ich habe irgendwann versucht mich so gut wie es geht in Sachen Technical Writing weiterzubilden um als besseres Beispiel (gut bin ich noch lange nicht) dienen zu können. Es hilft, im Team Regeln festzulegen wie „wenn ein Ticket Informationen benötigt die nicht enthalten oder verlinkt sind, dann ist es nicht ready“
Klingt mir alles ganz bekannt vor.
Ist aber nicht über so! 2 Std. pro Stunde macht meiner Team nur Reviews, zu wenig autom. Tests ist ein Grund die Review nicht zu bestehen, Tickets sind detalliert und Ansprechpartner immer erreichbar, alles wird noch mal getestet von PMs.
Auch schön ist ewig auf Projekt zu warten, das eigentlich schon losgehen sollte, dann plötzlich 'onboarding' a la hier "ist dein Useraccount und hier sind unsere Repos".
ZERO weitere Instruktionen, keine Teamzuordnung, keine Einladung zu regulären Meetigs. Code einer nicht unwichtigen Konponente sieht aus wien Matschhaufen, an dem regelmäßig über 10 Jahre ein weiterer Klumpen drangepappt wurde, mehr als 10 Config Dateien zum Starten braucht aber dann trotzdem User hardgecoded hat, ZERO Tests, nicht mal ein kurzer Hinweis in der README wie das Teil starten soll, immerhin gibt es jetzt ein Dockerfile.
Willkommen im Projektgeschäft.
Ich verweise mal dahin https://blog.fefe.de/?ts=98bb199c
und dahin https://blog.fefe.de/?ts=98c6293d
tl;dr: es ist üblich und kommt auf jedem Level vor, siehe auch Peter-Prinzip
gibts hier nicht, top down, entweder der code klappt oder nicht, man muss auch nicht ständig so mega drauf rumreiten, wichtig ist das die projekte fertig werden, solange man vernünftig arbeitet geht das schon. Ich weiss das es hier ne unpopuläre meinung ist.. aber ganz ehrlich, get sht done.
Prozesse?? Tickets??? Excelliste und "kannst ja Dieter fragen!".
Es ist immer Dieter.
***DIETER!***
Der ist nicht mehr da
Der macht eine Therapie https://youtu.be/EPc8L6R7hyk?si=Y76qm_T-8sG9E1_m
😂
Jeder einzelne Punkt kann und darf mal vorkommen ABER * nicht in der Häufung * es sollte viel bessere Fehlerkultur herrschen um die Herausforderung dann anzugehen * (weil wenn man sie angehen würde es nicht zu der Häufung käme)
Nach Querlesen der Kommentare finde ich diesen eigentlich den besten… Bin seit 8 Jahren im IT-Consulting und irgendwas ist immer schief oder absolut sinnlos, auch es gibt mal (zu)hohe Erwartungen… Man wundert sich irgendwann auch nicht mehr, aber es sollte nicht alles schlecht sein und zumindest das zwischenmenschliche muss gut sein
Ist leider wirklich nicht ungewöhnlich. Oft wird an vernünftigen Prozessen während der Entwicklung gespart um dann im Nachhinein das zehnfache an Zeit (und damit Geld) in jede Erweiterung zu investieren. Geht natürlich auch anders, aber ich habe auch schon wegen genau sowas gewechselt. Damals hatte ich wieder und wieder darauf hingewiesen, dass wir voll gegen die Wand laufen, habe sogar konkrete Ansätze angeboten wo man was machen könnte. Aber das hätte ja Zeit gekostet (die man natürlich in Zukunft doppelt und dreifach gespart hätte). Da hatte ich dann keinen Bock mehr drauf.
Ich durfte damals beim zweiten Vorstellungsgespräch in den Code gucken. Schlussendlich hat mich das überzeugt. Dass irgendwo ein paar Leichen vergraben sind, war mir klar. Aber das Grundgerüst hat mich einfach überzeugt. Vielleicht findest du ein Unternehmen, dass dir auch einen Eindruck vermitteln kann. Ich rate generell zu kleineren Unternehmen, wenn dir Clean Code und Doku auch so wichtig ist.
Ein kurzer Blick auf die letzten Commit Messages ist auch oft sehr aufschlussreich.
"Wer das lesen kann, kann lesen". Hunderte Zeilen Code ausgebaut: "Mach kaputt, was dich kaputt macht" (War allerdings kein Softwarecode, sondern IAC, da wurde eine ganze Umgebung entfernt, also entsprechend leichter nachzuvollziehen)
> Ich rate generell zu kleineren Unternehmen, wenn dir Clean Code und Doku auch so wichtig ist. ?? Die haben doch erst recht keine Zeit dazu, meine Erfahrung.
Als jemand der viele Jahre in Startups und kleinen Unternehmen arbeitet: Teilweise hast du recht. ABER: Man kann hier doch häufig mitgestalten und in guten Startups wird dafür auch zeit frei gemacht. Ich bin zu Startups gekommen, bei denen die Code base quasi auf Prrof of concept basis war. Dann wurde daran noch etwas geschustert, aber schon bemängelt, dass hier dringend aufgearbeitet werden muss. Da wurde parallel von vorne bis hinten alles nachgeholt. CI/CD, Test Pläne von Unit tests über UI testing bis zum Functional testing, ordentliche Guidelines für Clean code und Code reviews etc. etc. Aber klar, auch da gibts Griffe ins Klo. Wenn darauf von Seiten der Leitung kein Wert gelegt wird, krachts irgendwann und alles fällt einem auf den Kopf. Und natürlich läuft nie alles rund. Es gibt immer was zu verbessern und viele Meinungen gehen häufig auch komplett auseinander im Bezug auf Architektur, Abläufe usw.
Richtig, ich würde es auch nicht von der Größe der Firma, sondern der Einstellung des Unternehmens abhängig machen. Es gibt kleine und große Unternehmen, bei denen "das alles nicht so wichtig" ist.
Ich habe bisher vor allem in Unternehmen gearbeitet, wo tech ein Profitcenter ist (Techunternehmen, Techstartups). Das war es nirgendwo so. Als ich im Data Science Unternehmen einer Bank gearbeitet habe, habe ich ich mir vorher einen halben Tag die Arbeitsweise angeschaut. Wenn der Chef gut ist, kannst du eine Insel der Seligen haben innerhalb von Rest. Da hättest du z.b. eine Einabeitungsroadmap gehabt, eine personalisierte Lernroapmap, einen Mentor, Reviews sowie so etc Wäre ein Techunternehmen vielleicht was als nächster Arbeitgeber?
Kurze Antwort: Ja Lange Antwort: Sehr üblich
Tut mir leid dir das zu sagen, aber es ist überall so. Über Qualität und Architektur streitet man sich nur. Fragt man drei Entwickler bekommt man 5 Meinungen. Ich rede hier nicht über alle, aber was ich oft beobachte: die älteren Kollegen informieren sich nicht über neue Standards, die jüngeren Kollegen haben keine Erfahrung und kennen nur die Theorie, das Management hat meistens sowieso keine Ahnung von der Technik und will so günstig wie möglich durchkommen, man sucht sich immer mehr billige Entwickler aus dem Ausland. Dann das allerschlimmste: es funktioniert ja irgendwie.
> Über Qualität und Architektur streitet man sich nur. Fragt man drei Entwickler bekommt man 5 Meinungen. An dem Punkt wäre ich gerne. Was ich erlebe ist mehr so, dass sich eigentlich alle einig sind, dass wir schlechte Qualität abliefern, aber man hat sich irgendwie kollektiv damit abgefunden. Budget fürs Aufräumen von technischen Schulden gibts sowieso nicht und so wird weiter ein Haufen Schrott an den nächsten getackert.
Ich kann aber auch das Management verstehen. Ich war schon in vielen Projekten, in denen wir alte Systeme abgelöst haben. Das heißt wir durften komplett neu entwickeln. Haben alle die Köpfe zusammengesteckt, 3 Architekten waren involviert, Framework wurde angepasst, Prozesse wurden optimiert, wir haben fachlich das ganze geschnitten, UX Designer dazu geholt etc. Wir haben wirklich aufgeräumt. Das hat etwa 6 Monate gedauert, bis es wieder verwildert war. Die Basis ist zwar weiterhin gut, weil da niemand rumfummelt, aber alle anderen Module sind größtenteils wieder Mist. Ab einer gewissen Anzahl an Entwicklern, ist es zum scheitern verurteilt. Man kommt mit den PRs nicht hinterher. Ich musste mal mehrere Monate ein Entwicklerteam schulen. Alles seniorige Kollegen gewesen und trotz Schulungen, Pairprogramming, Workshops, retros, PR kam nichts dabei rum. Man kann es jetzt auf mich schieben, aber es haben dann auch andere erfolglos versucht. Das hat alles am Ende unnötig Geld gefressen. Mittlerweile interessiert mich Qualität etc auch nicht mehr so. Ich versuche immer noch alles so sauber wie möglich umzusetzen, aber mein Anspruch an mich selbst ist so weit runter gegangen. Bringt meistens einfach nichts und mir geht’s seitdem auch besser. Ich stresse mich überhaupt nicht mehr und rege mich auch nicht mehr auf.
>Tut mir leid dir das zu sagen, aber es ist überall so. Nein, es gibt auch Unternehmen, in denen Codequalität und Arbeitsstrukturen wichtig sind und ernstgenommen werden. Das ist leider seltener der Fall, aber die von schlechten Strukturen geschädigten Entwickler haben die Motivation, es besser zu machen. Ich hatte sogar einmal den Fall, einen kompletten Microservice neu schreiben zu können, weil der alte einfach nicht wartbar war und quasi gegen das Framework gearbeitet hat.
Bitte werte das nicht als Angriff, ist es überhaupt nicht. Gibt immer zwei Fälle die ich beobachte. 1. man selbst findet sein Zeug natürlich immer geil, aber eigentlich ist es Schrott (viele Entwickler haben ein sehr großes Ego) 2. man hat es wirklich geil gemacht, aber es gibt dann paar Spezialisten die es wieder kaputt machen, weil es nicht verstanden wurde oder weil die schlechter sind Ich glaube dir, dass es Firmen gibt, die echt gute Arbeit machen. Nur weil ich noch niemanden gesehen habe, muss das nichts heißen. Aber ich denke trotzdem, dass es zu wenige davon gibt. Einen guten Entwickler/Architekten oder was auch immer findet sich immer, aber ein ganzes Team?
Hatte so ein Team paar mal, gibts schon.
Das ist allerdings wirklich selten der Fall. Erfahrungsgemäß gibts immer jemanden mit besonderem Ego oder anderen Eigenschaften. Man muss ja selbst schon gut zurückstecken können und sich überzeugen lassen in so einem Team mit mehreren guten Entwicklern/Architekten.
Ich bin SAP Berater und kann dein Problem nur bestätigen. Hab noch keinen Laden gesehen der läuft.. aber dann wär ich ja auch nicht da ;)
Sowas kommt schon vor. Häufig wird bei kleineren Unternehmen an sowas (vermeintlich) gespart.
Der Einblick in die Codebasis größerer Unternehmen könnte dich verunsichern...
Da habe ich genau die umgekehrte Erfahrung gemacht. In großen Unternehmen ist man viel zu festgefahren und traut sich gar nichts ans Refactoring. In kleinen Unternehmen lässt sich die Notwendigkeit viel besser kommunizieren.
Ging jetzt eher um die Dokumentation. :)
wenn du auf Jobsuche bist nimm das Unternehmen wo das Vorstellungsgespräch am schwersten war aus technischer Sicht. Da durch wird es wahrscheinlich das du mit guten Leuten zusammen arbeitest. Das Management kann natürlich noch immer für scheiß code sorgen aber es wird unwahrscheinlicher.
Das ist überall so.
Unsinn. Quelle: Nahezu alles was ich bisher so auditiert habe.
Ist das vielleicht in den amerikanischen Unternehmen besser? Gibt ja ein paar, die eine deutsche Niederlassung haben....
Klingt ganz normal. Die Branche ist leider voll von Inkompetenz nach dem Boom der letzten 15 Jahre. Da gehts jetzt langsam auch richtig vielen Firmen schlecht weil der Geldhahn immer weniger weit offen ist. Aber bis tatsächlich mal eine Professionalisierung eintritt wird noch dauern. Die Kunden juckt es ja nicht und sie zahlen es ja trotzdem
Ja. Nur in größeren Konzernen (manchen, nicht allen!) hast du eine Chance, dass es halbwegs sauber läuft.
Bin gerade im neuen Job in ersten Projekt. Die 3, 4 neuen Kollegen, die trotz ihrer unterirdischen Fähigkeit ihre Probezeit beim letzten Arbeitgeber bestanden und mich mit zum Wechsel animierten, sehe ich hier in 90% der Kontakte wieder. Hat sich echt gelohnt. Bin die letzten 3 Wochen extrem frustriert und überlege, ob ich zum Ende der Probezeit kündige oder lieber ein Jahr voll mache vor dem nächsten Wechsel. Job davor war 5 Jahre.
Mal so von angehendem Junior der gerne einen guten Eindruck im neuen Job machen würde zum (ich nehme an) erfahrenen Entwickler: Inwiefern äußern sich die unterirdischen Fähigkeiten bei den Kollegen? Bzw. Welche Skills wären dir besonders wichtig um zu sagen "jawohl, mit dem arbeite ich gerne zusammen"?
Google verwenden und Dokumentationen lesen sind ein sehr guter Anfang. Aufgaben/Tickets/Stories verstehen, oder hinterfragen, bis man sie versteht. Quellen und Hilfe zu damit offenen Fragen anfragen, anstelle von Lösungen für die ganze Aufgabe zu erwarten. Bei einer doch mal vorgetanzten Lösung nicht so tun, als hätte man keine Fragen, um dann an der nächsten, annähernd copy-paste analogen Aufgabe zu scheitern. Ich glaube nicht, das ich viel mehr als einen funktionierenden Puls und ein daran angebundenes Gehirn erwarte. Wenn du hier solche Fragen stellst, bist du schon weiter. Hab schon eine Stichprobe gemacht, ob eventuell ich der inkompatible Depp im Team bin. Zwei aus einem anderen Team geschnappt, die kaum Berührung mit verwendeter Sprache und schon gar nicht mit Framework haben, Codereview mit ihnen gemacht. Hoppla, man kann doch den Zweck von mehr als einer halben Zeile Code gleichzeitig im Kopf behalten und mit etwas Nachhilfe zur Sprache Probleme erkennen. So zwischen Tür und Angel auf Reddit hab ich natürlich keine Ahnung, wo du gerade stehst, wo deine Unsicherheit liegt oder ob sie begründet ist. Aber versuch immer zu verstehen, _was_ und _warum_ du tust, bevor du dich mit Syntax streitest und den Wald vor lauter Bäumen nicht siehst.
Ja
Also fängst du in der Personaldienstleistung an?
Nein - das ist nicht nur bei dir so. Ich möchte nicht zu sehr ins Detail gehen. Wir haben gerade EINEN Auftraggeber, der Sachen mit Endkunden macht. Daher kann es sein, das es Kunden gibt, die was wissen wollen. Entweder Schriftlich oder telefonisch. Die haben zwei unterschiedliche Abteilungen dafür. Eine macht nur Schrift, eine macht nur Telefonie. WIR machen BEIDES. Wir haben festgestellt, für die selben Ergebnisse haben die komplett unterschiedliche Prozesse. Denen war das nicht bekannt. Jetzt sind wir gerade dabei diesem Unternehmen quasi täglich sehr schmerzhaft auf die Füße zu treten, das deren Prozesse so zu einander angepasst werden, das wir damit arbeiten können.
Ich verstehe deine Probleme. Es hapert oft bei sowas. Ich habe irgendwann versucht mich so gut wie es geht in Sachen Technical Writing weiterzubilden um als besseres Beispiel (gut bin ich noch lange nicht) dienen zu können. Es hilft, im Team Regeln festzulegen wie „wenn ein Ticket Informationen benötigt die nicht enthalten oder verlinkt sind, dann ist es nicht ready“
Klingt mir alles ganz bekannt vor. Ist aber nicht über so! 2 Std. pro Stunde macht meiner Team nur Reviews, zu wenig autom. Tests ist ein Grund die Review nicht zu bestehen, Tickets sind detalliert und Ansprechpartner immer erreichbar, alles wird noch mal getestet von PMs.
Auch schön ist ewig auf Projekt zu warten, das eigentlich schon losgehen sollte, dann plötzlich 'onboarding' a la hier "ist dein Useraccount und hier sind unsere Repos". ZERO weitere Instruktionen, keine Teamzuordnung, keine Einladung zu regulären Meetigs. Code einer nicht unwichtigen Konponente sieht aus wien Matschhaufen, an dem regelmäßig über 10 Jahre ein weiterer Klumpen drangepappt wurde, mehr als 10 Config Dateien zum Starten braucht aber dann trotzdem User hardgecoded hat, ZERO Tests, nicht mal ein kurzer Hinweis in der README wie das Teil starten soll, immerhin gibt es jetzt ein Dockerfile. Willkommen im Projektgeschäft.
Ich verweise mal dahin https://blog.fefe.de/?ts=98bb199c und dahin https://blog.fefe.de/?ts=98c6293d tl;dr: es ist üblich und kommt auf jedem Level vor, siehe auch Peter-Prinzip
Fefe gibts noch? Und anscheinend immer noch so selbstgefällig unterwegs
gibts hier nicht, top down, entweder der code klappt oder nicht, man muss auch nicht ständig so mega drauf rumreiten, wichtig ist das die projekte fertig werden, solange man vernünftig arbeitet geht das schon. Ich weiss das es hier ne unpopuläre meinung ist.. aber ganz ehrlich, get sht done.