grandios. Tester im Team mit Chuck Norris testen zu 90% manual end to end (weil man keine definierten ID, namen und attribute hat), und 10% Unit Tests ohne Dokumentation der Anforderungsabdeckung.
- Chuck Norris braucht keine Software. Der PC macht aus Angst von alleine alles was er will. - Alle Listen, die Chuck Norris deklariert, sind unendlich. - Technische Schulden bezahlt man bei Chuck Norris. - Chuck Norris schreibt Code, der sich selbst optimiert. - Chuck Norris kann unendliche Rekursionsfunktionen schreiben... und sie zurückkehren lassen.
Ich hatte mal im Team ein Chuck-Norris Softwareentwickler - das Managment/Marketing hat ihn als Held gefeiert weil er zu allem ja und Amen gesagt hat "Kann ich, mach ich, sofort". Dabei war es die absolute Katastrophe. Die Feuer sind gelöscht, aber die Scherben muss ich noch nach Jahren auffegen. Ja, er ist nicht mehr da.....puh.
@@hiemieshey9624 Er hatte irgendwann gekündigt, dann hat der Entwicklungsleiter gekündigt, der ein Fan von ihm war. Ich fege die letzten Jahre die Scherben auf als einfacher Senior/Lead. Aber ich bin immer noch da, und halte so die Leute hier am Kacken. Beim Feuer löschen habe ich nun freie Hand bekommen, und kann Belebungs- und Löschmassnahmen durchführen/erarbieten. Muss aber nicht alles alleine machen. Ich bin der Erste, der hier Architektur-Richtlinien für Code eingeführt hatte, davor gab es sowas nicht, alles gewachsener Code über Jahrzehnte.
Mein Projektmanagement-Lehrer hat einmal von zwei System-Admins erzählt, welche den Aufbau der IT-Infastruktur des Unternehmens bewusst nicht oder nur minimal dokumentiert haben. So waren sie unkündbar, weil auch das gesamte Wissen über den Aufbau der Infrastruktur verschwunden wäre, hätte man sie gekündigt.
Wundere mich bis heute, dass manche Unternehmen sowas akzeptieren. Als ich meine Ausbildung zum FIAE gemacht habe, war ich auch in so einem Unternehmen, wo in der Entwicklung nichts dokumentiert war - mit etwas Glück gab es mal zwei, drei Zeilen Kommentar im Code, wenn nicht ersichtlich war, was da gerade gemacht wird.
@@RevCodeoder anders herum und für die Dokumentationserstellung war Captain Obvious verantwortlich. // Increment I by one I++; Bis zu // Processes the object function process(Object o, String s, Object v, Integer i, int j, int k, int i2, ...) Dankeschön. -_-
Es ist immer gut mal über den Tellerrand zu schauen. Viele Probleme der Softwareentwicklung, gibt es auch in anderen Branchen. Für mich wäre es interessant, wenn du die heutigen agilen Software-Entwicklungs-Management-Strategien (wie z.B. Scrum) in einem Video in Relation zu Management-Strategien in anderen Bereichen setzen könntest. Als erstes fällt mir der Bereich Luftfahrt ein, mit den Themen CRM (Crew Ressource Management) und FOR-DEC (Facts-Options-Riscs-Decission-Execution-Check). Ich sehe da durchaus einige Parallelen.
Genau das haben wir im Unternehmen auch gerade für einen Teilbereich unseres Produkts. Andere Entwickler zögern sehr oder trauen sich gar nicht an den Code, weil der Bereich viel Verantwortung mit sich trägt und sich keiner so wirklich gut mit dem Code auskennt. Jetzt hatte die Person mal Urlaub und es ist ein Fehler aufgetreten in dem Teilbereich des Produkts. Da standen wir dann..
Ein gutes Gefühl, ob man im Unternehmen bzw. im Team einen Chuck Norris hat bekommt man in der Urlaubszeit. Wenn bereits 1-2 Wochen Abwesenheit einer Person zum Problem werden, sollte man dem definitiv Aufmerksamkeit schenken und reagieren.
Aussage vom Unternehmen: "wir haben flache Hierarchien" Realität bei der Arbeit: "Du machst alles alleine und bist alleine für alles verantwortlich" :D
Kann es im Chuck-Norris-Verse auch einen "guten" Chuck Norris geben der Architektur dokumentiert, fachliche Tests schreibt und versucht Kollegen einzubinden, versucht z.B. Pair-Programming anzuregen um KnowHow zu transferieren, versucht gemeinsame Reviews anzubieten, versucht sich entbehrlich zu machen und einfach wenig Resonanz findet und oft keine motivierten Abnehmer für Verantwortung über das Produkt findet?
Ja, kann es meiner meinung nach. Würde mich nämlich selbst so beschreiben. Am Ende liegt es aber an den Kollegen, die Informationen aufnehmen wollen oder nicht, oder nicht mehr aufnehmen können.
@@markuskruger1889 was ich am agilem Ansatz der mündlichen Weitergabe häufig kritisiere, ist dass man tws halbinfos bekommt, tws falschinfos, und von dem was richtig war, merkt man sich wenns gut geht die Hälfte (für einen oder 2 Monate, falls man es kaum braucht, zb irgendeine fachliche Niescheninfo). Wenn das mit 2 Leuten so machst, wärst schon effektiver es einfach einmal schriftlich zu Dokumentieren.
Gibt es, definitiv. Leider habe ich bisher immer die Erfahrung machen müssen, dass diese "positive"-Chuck-Norris irgendwann demotiviert aufgeben, weil einfach zu häufig gegen Sturheit und ähnliches gekämpft werden muss.
chuck norris braucht weder man noch lan, er denkt und es kommt. Wenn er denkt, dass du ein Arschtritt kassieren solltest, dann bekommst du einen indem z.b dir eineLaterne auf den Arsch fehlt, oder deine Freundin dir einen Arschtritt verpasst. Er ist also hochgradig flexibel@@rpitit
Chuck Norris hat keine Probleme UI's zu erstellen, die erstellen sich in seiner Anwesenheit von selbst. / Chuck Norris lernt nicht von einer KI, die KI lernt von Chuck Norris. / Leerzeichen im Code sind nur deswegen vorhanden weil Chuck Norris auf Pause gedrückt hat.
Bei meinem Ex-Arbeitgeber war ich genau in der Rolle. Als ich dann gehen wollte, hat man groß von Übergabe usw. geredet und nichts ist passiert. Die neuen Entwickler hatten auch null Interesse daran. Ende vom Lied ist, dass ich als Freelancer noch unterstütze, es aber immer noch kein Konzept gibt, das Know How ins Haus zu holen. Als ich mich dann mal 2,5 Woche geweigert habe zu arbeiten, hatten sie ein Problem. Der Support konnte keine Fragen beantworten und die Projekttermine mussten verschoben werden. Ich bin gespannt ob man jetzt was draus gelernt hat oder es so weiter geht.
Habe als Werkstudent so einen Fall beobachten können. Da ist auch jemand aus dem Unternehmen ausgeschieden (viele Jahre bevor ich als Werkstudent kurzzeitig dort gearbeitet habe) und bei einem Termin war dann ein Freiberufler am Start. Im Nachhinein erfahren, dass er die gesamte Infrastruktur aufgezogen hat und nur er die Details kennt. Das lief dort seit Jahren schon so und wird wohl heute noch so laufen. Konnte ich im ersten Moment nicht glauben und dachte das wäre übertrieben... Der hat sich dumm und dämlich verdient. Genieß es haha
Mhh also bei uns nennt man das dann "Consultant" oder "Full Stack". Die Kunden werden beraten und das Projekt wird dann auch alleine umgesetzt bis zum Ende. Wenn man Glück hat, hat man noch einen Projektleiter an der Seite, der aber mehr oder weniger nur Termine plant (oder planen kann), weil für alles andere das Knowhow fehlt. Klar sind keine Produkte sondern Projekte..aber das Projekt ist nach der Umsetzung ja nicht vorbei. Nur der Projektleiter ist halt raus und man hat zusätzlich dann das nächste Projekt an der Backe. Die nächsten Ideen hat der erste Kunde aber ganz sicher schon ;) Arbeiten als Dienstleister halt...
Deshalb sollten an jedem Kundenprojekt mindestens 2 Entwickler dran sein. Allein für Merge-Requests, Review /QA und um Wissen zu teilen und auch damit Urlaubsvertretung etc. Zu sichern. Leider wird aus Ressourcengründen gerade in kleinen Unternehmen und Teams auf so ein 4-Augenprinzip und Doku etc. verzichtet. Der einzige Vorteil einer Chuck-Norris Rolle ist wie du sagst für den Entwickler. Wird unkündbar und kann sich alles rausnehmen was er will (Gehalt etc.). Für die eigene Karriere an sich nicht schlecht sich unverzichtbar zu machen, aber fürs Unternehmen, als auch für das eigene Burnout-Risiko nicht vorteilhaft wenn man alles kann und für alles Verantwortung hat
Zudem besteht dann die Gefahr, dass man sich selbst auf diesem Posten ausruht und nicht weiterbildet, weil es keinen Anlass dazu gibt und niemand mehr Ahnung hat. Dann ist man unkündbar, traut sich vll. aber auch selbst nicht, sich auf etwas Neues einzulassen, weil man viel verpasst hat.
@@nitroventich würde dem fast zustimmen. Ich möchte mich fortbilden, aber es ist kein Geld da. Und ich habe ein schlechtes Gewissen zu fehlen, denn ich bin Einzelkämpfer: 4 Medizin-SW, alles mind zweisprachige GUI, Gebrauchsanleitung, Installationsanleitung, Release Notes etc schreiben und übersetzen. Unit Test, Deployment, usw.
@@nitrovent ja, wer sich auf so ne Arbeitsweise einlässt, kann erstmal alles neulerernen, wenn er woanders anfängt. und neu gelerntes einüben ist einfacher als falsch geübtes umlernen.
Ich finde man kann ja erstmal keine Dokumentation verlangen und schnell einen Monolithen auf den Markt bringen, um das Potential zu testen, Erfahrungen zu sammeln. Dann muss man aber als Management auch bereit sein alles "wegzuschmeißen" und Budget für eine neue bessere Version bereit halten
Chuck Norris kann aber auch die Firma verlassen, weil er einfach keine Lust mehr hat, alles alleine machen zu müssen. Keinen hat, mit dem er mal diskutieren könnte. Vielleicht möchte er sogar sein Wissen weitergeben. Wär ja möglich...
Ich bin so ein unfreiwilliger Chuck Norris, der Ende des Monats weg ist. Bis letzte Woche im Urlaub gewesen, trotzdem zwei Anrufe bekommen. Zu einem anderen Problem konnte ich vor dem Urlaub kein Feedback mehr geben, ich habe Zweifel, dass das ohne mich gelöst wurde. Montag krank gemeldet und trotzdem einen Anruf wegen einem kritischen Problem bekommen. Gestern hat ein Kollege mich noch kontaktiert um dwn Plan zu einem Feature aufzustellen anstatt dass die Leute sich darauf einstellen dass ich sehr bald nicht mehr da bin, habe also nicht darauf reagiert. Der Hauptunterschied zwischen mir und den anderen würde ich die Problemlösungsfähigkeiten nennen und sowas ist sehr schwer weiterzugeben, wenn Leute einfach nicht selbst über Probleme bis zum Ende nachdenken möchten, weil das teilweise einfach Erfahrung und Übung ist. Du kannst versuchen Leute abzuweisen, damit sie Dinge alleine versuchen zu lösen, allerdings klammern sich manche bis zum bitteren Ende an einen Chuck Norris. Bin gespannt wie die gleichen Leute demnächst ohne mich klar kommen.
Die Anforderungen an ein Projekt kommen ja im Laufe der Zeit und verändern sich. Kurzfristig erscheint es effizient, bewährten Code möglichst wenig anzutasten. Im Laufe der Zeit entsteht dann die schlechte Architektur. Hinterher kommen dann die schlauen Berater und schlagen eine Architektur vor, die ihnen verständlich ist. Es kann dann wirklich das Beste sein, das Projekt neu aufzusetzen. (Warum bietet die Automobilindustrie keine Umbausätze auf das neueste Modell an?)
ich bin ein "chuck norris" & das absurdeste ist, dass ich extrem dagegen ankämpfen muss, dass ich kein chuck norris mehr bin. Eigentlich müssten das doch alle wollen, dass ich verantwortungen/Aufgaben abgebe bzw. teile, sodass ein ausfall meinerseits in ordnung ist. Aber jedes mal wenn ich dieses thema anspreche wird dafür gekämpft, dass wir es "erstmal so lassen & uns später darum kümmern" ... wenn es so bleibt, werde ich das unternehmen auch verlassen
Hier ist auch so ein Ex Chuck Norris. Ich bin jahrelang immer wieder zum Chef und habe ihm erklärt, dass ich dringend Unterstützung im Team benötige und bekam Auszubildende zur Seite gestellt, die ich dann auch noch ausbilden durfte. Zusätzlich noch ein paar Studenten und einen frischen Quereinsteiger. Mir war das Risiko bewusst und am Ende musste ich kündigen, weil sich nichts geändert hat, meine Aufgabenanzahl stetig stieg und das Gehalt sowieso nicht dazu passte. Mittlerweile arbeite ich als Selbständiger manchmal mit meinem alten AG zusammen und einige des Teams sind auch noch da. Aber es kam kein Senior nach und die Architektur ist mittlerweile total versaut (spicke manchmal in den Code).
Ich hoffe Ihr hattet keinen Chuck Norris Entwickler und Ihr habt alle große Fragezeichen in den Augen und habt den Chuck Norris PO mit großen Katzenaugen angeschaut
das Dilemma kann noch so ausgehen, dass Chuck Norris zum Manager befördert wird und er in der Position im Grunde so weiter macht. Hier meine „Witz“, wenn es doch nur nicht so oft Realität wäre *seufz* - Chuck Norris checkt seinen Code nicht ein. Der Master Branch ist auf seinem Rechner.
Ist zwar witzig dargestellt, aber ich war oft so was ähnliches im QM. Wenn aber immer mehr Aufgaben aus allen möglichen Gründen auf eine Person konzentriert werden geht das ne Zeit. Jedoch in meinem Fall hat das nicht nur für die Firma böse geendet, es hat einen Einfluss darauf gehabt, das ich eine retrograde Depression entwickelt habe.
Da erkenne ich doch glatt eine Menge parallelen zu dem aktuellen Projekt wo ich bin. Ich hatte damals auch gewechselt, weil ich mir eigentlich diesen Wissenstransfer erhofft hatte. Der ist aber nie zu Stande gekommen. Mal von fehlender Dokumentation nicht zu reden. Kenne leider keine Witze :D Aber ich finde die bereits erwähnten sehr gut. :D
In meinem letzten job ist der lead chuck norris langsam aus dem team ausgeschieden und hat riesen wissenslücken zurück gelassen. Die projektleitung ist in paniknverfallen weil die entwicklung plötzlich langsamer vorwärts ging....
Das liegt meiner Erfahrung nach nicht am chuck norris sondern daran, dass die anderen Entwickler jetzt auch mal was leisten müssen und sich nicht mehr hinter den Leistungen von Chuck Norris verstecken können.
Ja, auch ich finde mich in dieser Beschreibung wieder. Mitarbeiter und auch der Chef haben praktisch nur mich angerufen, weil die beiden Kollegen eh keine Lösung gefunde haben.... egal ob ich in Feierabend oder Krank oder im Urlaub war. Ein Kollege war besonders schlecht und hat mir unter dem Strich mehr arbeit gemacht als geholfen. Ich bat... bettelte darum ihn zu entlassen. No Chance. Als Ausgleich für die entgangene Freizeit wollte ich eine 4 Tage Woche... bei vollem Stundenausgleich! Nur wenige Monate, dann wurde die wieder abgeschafft. Und wie Hr. Tielke habe ich dann irgendwann die Entscheidung getroffen, das ich das nicht mehr mit mir selber vereinbaren kann, und habe gekündigt. Noch heute, 12 Jahre später, läuft größtenteils die betriebsbereit hinterlassene Lager- und ERP Software, nur das jetzt 14 Leute den Job machen, welchen ich die ersten 4 Jahre oder so als Chuck Norris mit einem Hardware-techniker zusammen abgewickelt habe. Dank? Klagen von dem Flughafen... äh... dem Landefeld... Bist Du auch Chuck Norris, und Deine Firma unterstützt Dich nicht? Mach schnell einen Schuh... Sehr schnell!! Was besseres als den Tod findet man noch überall, vor allem außerhalb von Kassel :-)
Man sollte meinen, daß bereits während Ausbildung bzw. Studium, jeder den Größenunterschied von Zusammenarbeit (Teamwork) und Einzelarbeit (Einzelkämpfertum) verstanden haben sollte, egal welcher Aspekt (Projektumfang, Qualtätskriterien, Projektablauf usw.) betrachtet wird.
Wissensverteilung fällt leider halt auch nicht immer auf fruchtbaren Boden. Ist vielleicht eine Generationensache, aber versuch heute mal, jüngere Kollegen mit der Linux-Konsole bekannt zu machen, damit sie auch in der Build- und Deployment-Pipeline Hand anlegen können. In der heutigen Klickibunti-Welt halten viele das auch gar nicht mehr für nötig. Besondere Lorbeeren bekommt man fürs Abarbeiten technischer Schuld auch nicht, man handelt sich eher Probleme und einen langfristigen Klotz am Bein ein. Fängt aber schon vornedran beim Erlernen von Build-Tools wie Maven an. Wird in der Windows-Welt sicher ähnlich sein.
Tja, es sterben halt langsam die Leute aus, die bei der Entstehung von Linux und PC-Technologie selbst dabei waren. Es ist extrem harte Arbeit, sich in den Urschleim einzuarbeiten, über dem inzwischen schon hunderte Schichten sedimentierter Software-Ebenen aufgewachsen sind. IT-Archäologie
Ich denke was brauchen wir? - Ein cooles Team, habt Spaß bei dem was ihr tut - verliert aber die Professionalität nicht. - Einen PO - der euch die Anforderungen erklärt und euch Fragen zu Domaine beantwortet. - Einen SM - der euch und alle beteiligten Erst nimmt, nehmt ihr ihn auch ernst. Die Retro ist euer Meeting - Ihr werdet gehört - Ein Management welches den Weg GEMEINSAM geht der Weg nur Viele Grüße und danke David für deine Videos
Chuck Norris schreibt keine Software, er kompiliert seine Gedanken direkt in ausführbaren Code. Sein Code benötigt keine Tests, denn er ist fehlerfrei. Die Entwickler-Community verehrt Chuck Norris als den "Ultimativen Debugger", denn wenn er ein Bug findet, erscheint es vor ihm und fleht um Vergebung. Chuck Norris gibt keine Code-Reviews, er gibt Code-Verbesserungen, weil alles, was er berührt, automatisch besser wird.
Chuck Norris möchte halt nicht bei der nächsten Umstrukturierung auf der Straße sitzen, weil er leicht ersetzbar geworden ist durch die ordentliche dokumentierte Wissensweitergabe.
Kluge Unternehmen wissen einen Mitarbeiter zu schätzen, der nicht nur Kreativ ist, sondern auch Wissen verbreitet. Das ist zumindest meine Erfahrung. Angst muss nur der haben, der eigentlich unfähig ist, aber einmal einen Glückstreffer gelandet hat.
@@alexich963 Unternehmen mögen vor allem gute Handelsbilanzen und Quartalsabschlüsse. Wenn Andere Mitarbeiter leicht eingearbeitet werden können, und junge Bewerber geringere Gehaltsforderungen haben, dann sieht die Sache betriebswirtschaftlich anders aus. Der Mitarbeiter wird ersetzbarerer. Dass er versucht sich in einer schwer ersetzbaren Expertenstellung zu positionieren ist nachvollziehbar.
@@vast634 für so ein Unternehmen habe ich auch schon gearbeitet. Und das viel zu lange. Zu meinem Glück habe ich jetzt einen sozialen Arbeitgeber gefunden. Hier wird wissen grundsätzlich geteilt. Ich lerne jeden Tag von meinen Kollegen und bringe mein Wissen diesbezüglich auch ein. Bei Aufträgen schaut der Geschäftsführer nicht nur auf den finanziellen Mehrwert, sondern auch darauf, welches Know-How der Firma die Abarbeitung bringt. Und welch ein Wunder, die Geschäftszahlen passen auch!
@@vast634 Und wenn die Jüngeren nicht das bringen, was der "Chuck Norris" gebracht hat, hat Chuck Norris eben nicht gut genug dokumentiert, damit die Jüngeren dem folgen können.
Hat jemand Tipps, wie ich meinen Arbeitgeber im Laufe der Zeit davon überzeugen kann, mehr Ressourcen ins Unternehmen zu holen und die Prozesse anzupassen, damit ich nicht mehr Chuck Norris bin? Erst vor Kurzem habe ich drei Tage gebraucht, um ihn davon zu überzeugen, die Unternehmensstruktur von einer Entwicklungsgruppe in ein Entwicklungsteam umzustellen. Und der Prozess wird noch einige Monate brauchen.
Keine Chance. Sind denn die Entwickler teamfähig? Du kannst zwar Entwickler in ein Team zwingen. Der ist dann eine Randfigur und macht einfach seinen Job alleine weiter. Die Frage ist, ob es etwas bringt. Sind denn die Teams für eine Software verantwortlich? Oder sind das zusammengewürfelte Teams. Beim 2.ten Ansatz kannst Du das vergessen. Ich habe da einige Anekdoten: - Ein auseinander ziehen von CAD und CIM, weil unbedingt jemand Teamchef werden wollte. Einige Zeit später wollte man dann eine Treibergruppe gründen neben den Teams, um das wieder gerade zu ziehen. - Teammitglieder, die rein fachlich keinen überlapp haben, damit die dann irgendwann sich ersetzen können. Bspw ein Produktionsmonitor in verschiedenen Produktionsbereichen (DB, Barcode, Multithreading, FrondEnd Controls, BI), Treiberentwicklung (mathematisch, algorithmisch), diverse Tools und Bibliotheken (Barcode Service), Optimierung usw. Das kann man nicht mit 5 Entwicklern betreuen. - Entwickler, die aus verschiedenen Teams an denselben Produkt arbeiten sollen. Ging auch schief, weil die Teamchefs sich nicht absprachen. Das war auch allen bis auf dem Entwickler, der das Produkt betreute, recht. Das waren so einige Highlights. Am besten war dann noch, dass man agile Entwicklung bei zusammengewürfelten Teams einführen wollte. Was soll das bringen. Da hat man dann ein Refinement, was eine Stunde dauert, aber für jemanden nach 5 Minuten fertig ist. Oder eine Reflektion, wenn man eh alleine seinen Bereich betreut.
Ergänzend: - Es werden dann auch alle x Jahre die Teams neu zusammen gewürfelt, weil man immer n Entwickler in einem Team haben muss. Teams müssen etwa die gleiche Größe haben (+/- einen Entwickler), damit Teamchefs bei der Bezahlung nicht meckern. - Die Teamchefs sind eigentlich immer noch Entwickler und müssen irgendwas fürs Controlling ausfüllen, um die Zahlen einzuhalten. Der andere Kram Team Building, Meeting, Urlaubsplanung usw sind sekundär. - Am besten ist dann noch, dass diese Controlling arbeiten von einem Teamchef für andere Teams gemacht werden und andere Teamchefs keine Lust darauf haben und diese arbeiten nur unregelmäßig machen. Aber dann alle Teamchefs eine gerügt werden. Absoluter quatsch. Mag sein, dass es bei dir anders werden wird. Aber einfach Teams bilden, ist sicher nicht zweckgemäß. Die ganze Nummer muss ohne Teamchefs auskommen. Teams müssen sich selber organisieren. Es ist auch die Teamgröße egal, gut zu viele Entwickler sind auch nicht gut, aber es reichen auch mal 2 oder 3 Entwickler in einem Team. Zudem müssen die Entwickler das wollen. Wenn jemand keine Lust auf Teams hat, dann wird das nichts.
Ich habe mir vor kurzem erst so ein Projekt angesehen, wird im wesentlichen von einer einzigen Person betreut, eben ein Chuck Norris Entwickler. Einzelkämpfer. Macht auch 2nd level support. Dokumentationen? Fehlanzeige. Ich habe ein bisschen Angst dort einzusteigen. aber andererseits gibt es für mich persönlich sonst keine anderen Herausforderungen derzeit… leider!
Wenn die Person irgendwo doch ein Teamplayer ist, dann kann sowas auch ne Chance sein. Ohne vorher mit dem anderen Entwickler deine Aufgaben zu besprechen, würde ich aber nicht anfangen.
Vollkommen richtig@@Askunics es haben sich jedoch tatsächlich andere Möglichkeiten zwischenzeitlich eröffnet, welche einer Zusammenarbeit mit einem Chuck Norris Entwickler deutlich zu bevorzugen sind.
Kein Entwickler kann in Java ein System.exit(0); mit catch abfangen? - Doch! Chuck Norris kann. Dieser Witz entstand vor vielen Jahren, als einer meiner damaligen Azubis gefragt hat, ob man mit Catch ein System.exit(0) abfangen könne, und einer der Senior-Kollegen nur trocken sagte "Chuck Norris kann."
Dafür kann der Entwickler nichts, wenn der AG nur wenige/keine Devs einstellt. Das hat der AG zu verantworten. Der Dev kann und sollte sein Bestes geben, mehr geht aber nicht. Code ist komplex.
Chuck Norris kennt alle Excel-Funktionen. Chuck Norris kann jede Tastaturkombination mit einem einzigen Handkantenschlag eingeben. Chuck Norris kann mit einer deutschen Tastatur chinesische Schriftzeichen schreiben. Chuck Norris ist an jedem PC automatisch Administrator. Chuck Norris braucht sich keine Passwörter zu merken, denn "Chuck Norris" ist das Universalpasswort und es traut sich keiner ausser ihm selbst, es einzugeben. Chuck Norris braucht keine Maus, denn jeder Computer gehorcht seiner Mimik. Chuck Norris hat auch ohne Router überall WLAN. Bei Chuck Norris sagt die Wikipedia immer die Wahrheit. Chuck Norris kann alle Computerprogramme nutzen, ohne den Nutzungsbedingungen zuzustimmen.
Ich habe leider das Problem, dass ich ein Chuck Norris als Programmadmin bin. Die Kollegen, mit denen ich zusammenarbeite sind aber größtenteils ihrer Zeit in Projekten tätig und keiner kann die Programmiersprache. Ich fürchte, wenn meine Addins nicht mehr funktionieren, werden sie eher verworfen als weiterentwickelt.
Chuck Norris wollte programmieren lernen, ihm war Brainfuck aber zu einfach, also hat er eine neue Sprache entwickelt, die nur aus 1 und 1 besteht, denn er kennt keine 0.
The Rabbit Hole: "Chuck Norris kann nicht besser sein als Chuck Norris" 😂 boah, jetzt sind meine Synapsen durchgeschmorrt. Das ist vergleichbar wie bei mir damals in der Logistik. Als Azubi gehste in eine Abteilung wo du was lernen willst, bekommst eine "5 Minuten Einführung", des LMS und kriegst nen feuchten Händedruck. Wenn du dann was fragen willst: "hab keine zeit", war der standardspruch. 😂
der trick ist, ein fauler chuck norris zu sein: man *könnte* alles tun, aber wenn delegation möglich ist, tut man es und stellt nur die qualität sicher
Год назад
Chuck Norris benutzt nicht Chat-GPT - Chat-GPT ist eine minderwertiges Modell von Chuck Norris.
Puhh auch hier wieder so viele parallelen zum Job :( Ich würde den Chucks wohlwollend nur selten Bösartigkeit unterstellen. Man wächst halt in die Rolle rein und bis zu einem gewissen grade ist das ja auch schmeichelhaft wenn jeder um das eigene Wissen buhlt. Meiner Erfahrung nach ist das ausschlaggebende Problem aber oft Führungsschwäche. (Chuck Norris dürfte nur selten der weisungsbefugte Chef sein) Dort sitzen dann Leute die sich viel zu wenig auskennen und Dinge nicht bewerten können(natürlich muss der Chef nicht jede Codeecke kennen...aber einen groben Überblick und Grundverständnis sollte schon da sein) Chuck "löst" dann alle Probleme und el Chefe kapiert überhaupt nicht welche Probleme daraus entstehen. MMn ein ganz schöne Führungsproblem und ausruhen au fden sich selbst organisierenden Teams. Das können und sollen Teams in gewissen Grenzen ja machen, aber irgendwie wird das oft Missverstanden und Chef lehnt sich zurück und es gilt laissez faire
Doku erstellen. Ou ja. Könnt mir nix schöneres vorstellen. Hatten wir gerade. Oben beschreibste was gemacht wurde und weiter unten bewschreibste den ganzen Spaß nochmal. Dann soll da aber was anderes stehen. Ich komm mit dem ding nicht wirklich klar.
Chuck Norris kann Interfaces instanziieren.
... und abstrakte Klassen auch ;)
Chuck Norris codet nicht nach Test-Driven Development, Tests passen sich seinem Code an.
Auch sehr geil! :D
Läuft wohl gerade wieder mit FC Hansa, gell?
grandios. Tester im Team mit Chuck Norris testen zu 90% manual end to end (weil man keine definierten ID, namen und attribute hat), und 10% Unit Tests ohne Dokumentation der Anforderungsabdeckung.
Chuck Norris Driven Development
CDD = Chuck-Driven Development
- Chuck Norris braucht keine Software. Der PC macht aus Angst von alleine alles was er will.
- Alle Listen, die Chuck Norris deklariert, sind unendlich.
- Technische Schulden bezahlt man bei Chuck Norris.
- Chuck Norris schreibt Code, der sich selbst optimiert.
- Chuck Norris kann unendliche Rekursionsfunktionen schreiben... und sie zurückkehren lassen.
😂😂😂
Sehr lustig :-) klasse
chuck norris muss weder schreiben, noch sagen er denkt und es wird!
Chuck Norris macht keine Refactorings. Er starrt die technischen Schulden an und sie sammeln sich von alleine auf.
Chuck Norris praktiziert keine Retrospektiven. Er weiß bereits, was gut gelaufen ist, denn er war dafür verantwortlich.
Chuck Norris' User Stories benötigen keine Akzeptanzkriterien. Die Stories akzeptieren einfach Chuck Norris.
Chuck Norris kann Strg+Alt+Delete mit einem Finger drücken.
Das kann ich allerdings auch 😆
:))
Ich hatte mal im Team ein Chuck-Norris Softwareentwickler - das Managment/Marketing hat ihn als Held gefeiert weil er zu allem ja und Amen gesagt hat "Kann ich, mach ich, sofort". Dabei war es die absolute Katastrophe. Die Feuer sind gelöscht, aber die Scherben muss ich noch nach Jahren auffegen. Ja, er ist nicht mehr da.....puh.
@@hiemieshey9624 Er hatte irgendwann gekündigt, dann hat der Entwicklungsleiter gekündigt, der ein Fan von ihm war. Ich fege die letzten Jahre die Scherben auf als einfacher Senior/Lead. Aber ich bin immer noch da, und halte so die Leute hier am Kacken. Beim Feuer löschen habe ich nun freie Hand bekommen, und kann Belebungs- und Löschmassnahmen durchführen/erarbieten. Muss aber nicht alles alleine machen. Ich bin der Erste, der hier Architektur-Richtlinien für Code eingeführt hatte, davor gab es sowas nicht, alles gewachsener Code über Jahrzehnte.
Ich denke das ist nichts besonderes. Die Entwickler die kündigen sind immer die, die sche*sse entwickelt haben. 😅
Stimmt. Ein CN wird ja gefördert und im Gegenzug sagt er eher Ja als ein Team. Guter Punkt.
Bist du der neue CN, denn du räumst jetzt auf. 😅
@@myopinion1309 Yo, in der Domain codiere ich nun alleine. Sonst ist niemand da...
Mein Projektmanagement-Lehrer hat einmal von zwei System-Admins erzählt, welche den Aufbau der IT-Infastruktur des Unternehmens bewusst nicht oder nur minimal dokumentiert haben. So waren sie unkündbar, weil auch das gesamte Wissen über den Aufbau der Infrastruktur verschwunden wäre, hätte man sie gekündigt.
Wundere mich bis heute, dass manche Unternehmen sowas akzeptieren. Als ich meine Ausbildung zum FIAE gemacht habe, war ich auch in so einem Unternehmen, wo in der Entwicklung nichts dokumentiert war - mit etwas Glück gab es mal zwei, drei Zeilen Kommentar im Code, wenn nicht ersichtlich war, was da gerade gemacht wird.
@@RevCodeoder anders herum und für die Dokumentationserstellung war Captain Obvious verantwortlich.
// Increment I by one
I++;
Bis zu
// Processes the object
function process(Object o, String s, Object v, Integer i, int j, int k, int i2, ...)
Dankeschön. -_-
Es ist immer gut mal über den Tellerrand zu schauen. Viele Probleme der Softwareentwicklung, gibt es auch in anderen Branchen. Für mich wäre es interessant, wenn du die heutigen agilen Software-Entwicklungs-Management-Strategien (wie z.B. Scrum) in einem Video in Relation zu Management-Strategien in anderen Bereichen setzen könntest. Als erstes fällt mir der Bereich Luftfahrt ein, mit den Themen CRM (Crew Ressource Management) und FOR-DEC (Facts-Options-Riscs-Decission-Execution-Check). Ich sehe da durchaus einige Parallelen.
Genau das haben wir im Unternehmen auch gerade für einen Teilbereich unseres Produkts. Andere Entwickler zögern sehr oder trauen sich gar nicht an den Code, weil der Bereich viel Verantwortung mit sich trägt und sich keiner so wirklich gut mit dem Code auskennt. Jetzt hatte die Person mal Urlaub und es ist ein Fehler aufgetreten in dem Teilbereich des Produkts. Da standen wir dann..
Bei Chuck Norris failed nie ein Test, sie laufen aus Respekt....ebenso wie sein Code.
Ein gutes Gefühl, ob man im Unternehmen bzw. im Team einen Chuck Norris hat bekommt man in der Urlaubszeit. Wenn bereits 1-2 Wochen Abwesenheit einer Person zum Problem werden, sollte man dem definitiv Aufmerksamkeit schenken und reagieren.
Aus Arbeitnehmersicht ist es ganz gut, wenn man das Unternehmen etwas an den Eiern hat
Sehr gut zusammengefasst. Exakt so erlebt.
Aussage vom Unternehmen: "wir haben flache Hierarchien"
Realität bei der Arbeit: "Du machst alles alleine und bist alleine für alles verantwortlich" :D
so isses 🤣🤣
...du bekommst auf deinem Gebiet immer mehr Verantwortung ohne wirklich aufzusteigen.
Kann es im Chuck-Norris-Verse auch einen "guten" Chuck Norris geben der Architektur dokumentiert, fachliche Tests schreibt und versucht Kollegen einzubinden,
versucht z.B. Pair-Programming anzuregen um KnowHow zu transferieren, versucht gemeinsame Reviews anzubieten, versucht sich entbehrlich zu machen und einfach wenig Resonanz findet und oft keine motivierten Abnehmer für Verantwortung über das Produkt findet?
Ja, kann es meiner meinung nach. Würde mich nämlich selbst so beschreiben. Am Ende liegt es aber an den Kollegen, die Informationen aufnehmen wollen oder nicht, oder nicht mehr aufnehmen können.
@@markuskruger1889 was ich am agilem Ansatz der mündlichen Weitergabe häufig kritisiere, ist dass man tws halbinfos bekommt, tws falschinfos, und von dem was richtig war, merkt man sich wenns gut geht die Hälfte (für einen oder 2 Monate, falls man es kaum braucht, zb irgendeine fachliche Niescheninfo). Wenn das mit 2 Leuten so machst, wärst schon effektiver es einfach einmal schriftlich zu Dokumentieren.
@@certaindeath7776 ich dokumentieren und wir zeichnen unsere wissensmeetings auf ☝️
Gibt es, definitiv. Leider habe ich bisher immer die Erfahrung machen müssen, dass diese "positive"-Chuck-Norris irgendwann demotiviert aufgeben, weil einfach zu häufig gegen Sturheit und ähnliches gekämpft werden muss.
Chuck Norris kann eine Email ohne Internet verschicken.
chuck norris braucht weder man noch lan, er denkt und es kommt. Wenn er denkt, dass du ein Arschtritt kassieren solltest, dann bekommst du einen indem z.b dir eineLaterne auf den Arsch fehlt, oder deine Freundin dir einen Arschtritt verpasst. Er ist also hochgradig flexibel@@rpitit
Chuck Norris kann das Internet per Email verschicken.
Chuck Norris hat keine Probleme UI's zu erstellen, die erstellen sich in seiner Anwesenheit von selbst. / Chuck Norris lernt nicht von einer KI, die KI lernt von Chuck Norris. / Leerzeichen im Code sind nur deswegen vorhanden weil Chuck Norris auf Pause gedrückt hat.
Bei meinem Ex-Arbeitgeber war ich genau in der Rolle. Als ich dann gehen wollte, hat man groß von Übergabe usw. geredet und nichts ist passiert. Die neuen Entwickler hatten auch null Interesse daran.
Ende vom Lied ist, dass ich als Freelancer noch unterstütze, es aber immer noch kein Konzept gibt, das Know How ins Haus zu holen. Als ich mich dann mal 2,5 Woche geweigert habe zu arbeiten, hatten sie ein Problem. Der Support konnte keine Fragen beantworten und die Projekttermine mussten verschoben werden.
Ich bin gespannt ob man jetzt was draus gelernt hat oder es so weiter geht.
Ist doch genial. Bisschen Inflationsausgleich auf deine Rechnungen und win:win 😊 Lass dich wertschätzen ❤
es geht natürlich so weiter und hey, nimm es eindach mit
Habe als Werkstudent so einen Fall beobachten können. Da ist auch jemand aus dem Unternehmen ausgeschieden (viele Jahre bevor ich als Werkstudent kurzzeitig dort gearbeitet habe) und bei einem Termin war dann ein Freiberufler am Start. Im Nachhinein erfahren, dass er die gesamte Infrastruktur aufgezogen hat und nur er die Details kennt. Das lief dort seit Jahren schon so und wird wohl heute noch so laufen. Konnte ich im ersten Moment nicht glauben und dachte das wäre übertrieben...
Der hat sich dumm und dämlich verdient. Genieß es haha
Mhh also bei uns nennt man das dann "Consultant" oder "Full Stack". Die Kunden werden beraten und das Projekt wird dann auch alleine umgesetzt bis zum Ende. Wenn man Glück hat, hat man noch einen Projektleiter an der Seite, der aber mehr oder weniger nur Termine plant (oder planen kann), weil für alles andere das Knowhow fehlt. Klar sind keine Produkte sondern Projekte..aber das Projekt ist nach der Umsetzung ja nicht vorbei. Nur der Projektleiter ist halt raus und man hat zusätzlich dann das nächste Projekt an der Backe. Die nächsten Ideen hat der erste Kunde aber ganz sicher schon ;) Arbeiten als Dienstleister halt...
Deshalb sollten an jedem Kundenprojekt mindestens 2 Entwickler dran sein. Allein für Merge-Requests, Review /QA und um Wissen zu teilen und auch damit Urlaubsvertretung etc. Zu sichern. Leider wird aus Ressourcengründen gerade in kleinen Unternehmen und Teams auf so ein 4-Augenprinzip und Doku etc. verzichtet. Der einzige Vorteil einer Chuck-Norris Rolle ist wie du sagst für den Entwickler. Wird unkündbar und kann sich alles rausnehmen was er will (Gehalt etc.). Für die eigene Karriere an sich nicht schlecht sich unverzichtbar zu machen, aber fürs Unternehmen, als auch für das eigene Burnout-Risiko nicht vorteilhaft wenn man alles kann und für alles Verantwortung hat
Zudem besteht dann die Gefahr, dass man sich selbst auf diesem Posten ausruht und nicht weiterbildet, weil es keinen Anlass dazu gibt und niemand mehr Ahnung hat. Dann ist man unkündbar, traut sich vll. aber auch selbst nicht, sich auf etwas Neues einzulassen, weil man viel verpasst hat.
@@nitroventich würde dem fast zustimmen. Ich möchte mich fortbilden, aber es ist kein Geld da. Und ich habe ein schlechtes Gewissen zu fehlen, denn ich bin Einzelkämpfer: 4 Medizin-SW, alles mind zweisprachige GUI, Gebrauchsanleitung, Installationsanleitung, Release Notes etc schreiben und übersetzen. Unit Test, Deployment, usw.
@@nitrovent ja, wer sich auf so ne Arbeitsweise einlässt, kann erstmal alles neulerernen, wenn er woanders anfängt.
und neu gelerntes einüben ist einfacher als falsch geübtes umlernen.
Das Problem ist meiner Meinung nach nicht der Softwareentwickler, der nicht dokumentiert, sondern das Management, dass keine Dokumentation einfordert.
oder dem Mitarbeiter keine Zeit zum dokumentieren einräumt.
Naja, ein wenig Eigenverantwortung hat noch nie geschadet
Ich finde man kann ja erstmal keine Dokumentation verlangen und schnell einen Monolithen auf den Markt bringen, um das Potential zu testen, Erfahrungen zu sammeln. Dann muss man aber als Management auch bereit sein alles "wegzuschmeißen" und Budget für eine neue bessere Version bereit halten
So etwas nennt man bei der Geldanlage "Klumpenrisiko".
Chuck Norris kann aber auch die Firma verlassen, weil er einfach keine Lust mehr hat, alles alleine machen zu müssen. Keinen hat, mit dem er mal diskutieren könnte. Vielleicht möchte er sogar sein Wissen weitergeben. Wär ja möglich...
Ich bin so ein unfreiwilliger Chuck Norris, der Ende des Monats weg ist. Bis letzte Woche im Urlaub gewesen, trotzdem zwei Anrufe bekommen. Zu einem anderen Problem konnte ich vor dem Urlaub kein Feedback mehr geben, ich habe Zweifel, dass das ohne mich gelöst wurde. Montag krank gemeldet und trotzdem einen Anruf wegen einem kritischen Problem bekommen. Gestern hat ein Kollege mich noch kontaktiert um dwn Plan zu einem Feature aufzustellen anstatt dass die Leute sich darauf einstellen dass ich sehr bald nicht mehr da bin, habe also nicht darauf reagiert. Der Hauptunterschied zwischen mir und den anderen würde ich die Problemlösungsfähigkeiten nennen und sowas ist sehr schwer weiterzugeben, wenn Leute einfach nicht selbst über Probleme bis zum Ende nachdenken möchten, weil das teilweise einfach Erfahrung und Übung ist. Du kannst versuchen Leute abzuweisen, damit sie Dinge alleine versuchen zu lösen, allerdings klammern sich manche bis zum bitteren Ende an einen Chuck Norris. Bin gespannt wie die gleichen Leute demnächst ohne mich klar kommen.
Wieviele Tests schreibt Chuck Norris zu seiner Software?
Alle
Chuck Norris brauch keine Tests schreiben, der Code macht das selbst.
Die Anforderungen an ein Projekt kommen ja im Laufe der Zeit und verändern sich. Kurzfristig erscheint es effizient, bewährten Code möglichst wenig anzutasten. Im Laufe der Zeit entsteht dann die schlechte Architektur. Hinterher kommen dann die schlauen Berater und schlagen eine Architektur vor, die ihnen verständlich ist. Es kann dann wirklich das Beste sein, das Projekt neu aufzusetzen. (Warum bietet die Automobilindustrie keine Umbausätze auf das neueste Modell an?)
ich bin ein "chuck norris" & das absurdeste ist, dass ich extrem dagegen ankämpfen muss, dass ich kein chuck norris mehr bin. Eigentlich müssten das doch alle wollen, dass ich verantwortungen/Aufgaben abgebe bzw. teile, sodass ein ausfall meinerseits in ordnung ist. Aber jedes mal wenn ich dieses thema anspreche wird dafür gekämpft, dass wir es "erstmal so lassen & uns später darum kümmern" ... wenn es so bleibt, werde ich das unternehmen auch verlassen
Chuck Norris braucht keine Daily Stand-ups. Die Tasks rennen vor Angst von selbst zu ihm und berichten ihren Fortschritt.
(Chatgpt)
Hier ist auch so ein Ex Chuck Norris. Ich bin jahrelang immer wieder zum Chef und habe ihm erklärt, dass ich dringend Unterstützung im Team benötige und bekam Auszubildende zur Seite gestellt, die ich dann auch noch ausbilden durfte. Zusätzlich noch ein paar Studenten und einen frischen Quereinsteiger.
Mir war das Risiko bewusst und am Ende musste ich kündigen, weil sich nichts geändert hat, meine Aufgabenanzahl stetig stieg und das Gehalt sowieso nicht dazu passte.
Mittlerweile arbeite ich als Selbständiger manchmal mit meinem alten AG zusammen und einige des Teams sind auch noch da. Aber es kam kein Senior nach und die Architektur ist mittlerweile total versaut (spicke manchmal in den Code).
Chuck Norris braucht kein "CATCH" in seinen Code schreiben, er fängt die "EXCEPTIONS" selbst.
wenn Chuck Norris Exceptions schmeißt, kann niemand sie fangen
@@mepipe7705
Wenn der PO Chuck Norris um etwas bittet ist es kein Feature sondern Gnade.
Ich hoffe Ihr hattet keinen Chuck Norris Entwickler und Ihr habt alle große Fragezeichen in den Augen und habt den Chuck Norris PO mit großen Katzenaugen angeschaut
Chuck Norris würde nie gegen eine Katze mit großen rollenden Augen was sagen können
Chuck Norris programmiert das User-Interface in Maschinensprache.
Chuck Norris can compile syntax errors.
Chuck Norris weiß immer, wie man ein Array deklariert. Ohne googlen!
Chuck Norris programmiert Java ohne Semikolons.
hab ich auch probiert, hat nicht geklappt 🤣🤣 Aber es gibt ja zum Glück Python ^^
Chuck Norris braucht kein Team, was er nicht schafft wird auch nicht gebrauch!
chuck norris muss nix schaffen , er braucht gar nix
das Dilemma kann noch so ausgehen, dass Chuck Norris zum Manager befördert wird und er in der Position im Grunde so weiter macht.
Hier meine „Witz“, wenn es doch nur nicht so oft Realität wäre *seufz*
- Chuck Norris checkt seinen Code nicht ein. Der Master Branch ist auf seinem Rechner.
Ist zwar witzig dargestellt, aber ich war oft so was ähnliches im QM. Wenn aber immer mehr Aufgaben aus allen möglichen Gründen auf eine Person konzentriert werden geht das ne Zeit. Jedoch in meinem Fall hat das nicht nur für die Firma böse geendet, es hat einen Einfluss darauf gehabt, das ich eine retrograde Depression entwickelt habe.
Da erkenne ich doch glatt eine Menge parallelen zu dem aktuellen Projekt wo ich bin. Ich hatte damals auch gewechselt, weil ich mir eigentlich diesen Wissenstransfer erhofft hatte. Der ist aber nie zu Stande gekommen. Mal von fehlender Dokumentation nicht zu reden.
Kenne leider keine Witze :D Aber ich finde die bereits erwähnten sehr gut. :D
In meinem letzten job ist der lead chuck norris langsam aus dem team ausgeschieden und hat riesen wissenslücken zurück gelassen. Die projektleitung ist in paniknverfallen weil die entwicklung plötzlich langsamer vorwärts ging....
Das liegt meiner Erfahrung nach nicht am chuck norris sondern daran, dass die anderen Entwickler jetzt auch mal was leisten müssen und sich nicht mehr hinter den Leistungen von Chuck Norris verstecken können.
Chuck Norris testet in Production - und failt nie
The function of leadership is to produce more leaders, not more followers - Ralph Nadar
Ja, auch ich finde mich in dieser Beschreibung wieder. Mitarbeiter und auch der Chef haben praktisch nur mich angerufen, weil die beiden Kollegen eh keine Lösung gefunde haben.... egal ob ich in Feierabend oder Krank oder im Urlaub war. Ein Kollege war besonders schlecht und hat mir unter dem Strich mehr arbeit gemacht als geholfen. Ich bat... bettelte darum ihn zu entlassen. No Chance. Als Ausgleich für die entgangene Freizeit wollte ich eine 4 Tage Woche... bei vollem Stundenausgleich! Nur wenige Monate, dann wurde die wieder abgeschafft. Und wie Hr. Tielke habe ich dann irgendwann die Entscheidung getroffen, das ich das nicht mehr mit mir selber vereinbaren kann, und habe gekündigt. Noch heute, 12 Jahre später, läuft größtenteils die betriebsbereit hinterlassene Lager- und ERP Software, nur das jetzt 14 Leute den Job machen, welchen ich die ersten 4 Jahre oder so als Chuck Norris mit einem Hardware-techniker zusammen abgewickelt habe. Dank? Klagen von dem Flughafen... äh... dem Landefeld... Bist Du auch Chuck Norris, und Deine Firma unterstützt Dich nicht? Mach schnell einen Schuh... Sehr schnell!! Was besseres als den Tod findet man noch überall, vor allem außerhalb von Kassel :-)
Man sollte meinen, daß bereits während Ausbildung bzw. Studium, jeder den Größenunterschied von Zusammenarbeit (Teamwork) und Einzelarbeit (Einzelkämpfertum) verstanden haben sollte, egal welcher Aspekt (Projektumfang, Qualtätskriterien, Projektablauf usw.) betrachtet wird.
Wissensverteilung fällt leider halt auch nicht immer auf fruchtbaren Boden. Ist vielleicht eine Generationensache, aber versuch heute mal, jüngere Kollegen mit der Linux-Konsole bekannt zu machen, damit sie auch in der Build- und Deployment-Pipeline Hand anlegen können. In der heutigen Klickibunti-Welt halten viele das auch gar nicht mehr für nötig. Besondere Lorbeeren bekommt man fürs Abarbeiten technischer Schuld auch nicht, man handelt sich eher Probleme und einen langfristigen Klotz am Bein ein. Fängt aber schon vornedran beim Erlernen von Build-Tools wie Maven an. Wird in der Windows-Welt sicher ähnlich sein.
Tja, es sterben halt langsam die Leute aus, die bei der Entstehung von Linux und PC-Technologie selbst dabei waren. Es ist extrem harte Arbeit, sich in den Urschleim einzuarbeiten, über dem inzwischen schon hunderte Schichten sedimentierter Software-Ebenen aufgewachsen sind. IT-Archäologie
Ich denke was brauchen wir?
- Ein cooles Team, habt Spaß bei dem was ihr tut - verliert aber die Professionalität nicht.
- Einen PO - der euch die Anforderungen erklärt und euch Fragen zu Domaine beantwortet.
- Einen SM - der euch und alle beteiligten Erst nimmt, nehmt ihr ihn auch ernst. Die Retro ist euer Meeting - Ihr werdet gehört
- Ein Management welches den Weg
GEMEINSAM geht der Weg nur
Viele Grüße und danke David für deine Videos
Ist es nicht wichtig, dass es für jeden Bereich immer 2 bis 3 Menschen gibt
Chuck norris: der Sprint dauert 15 Minuten, und die Retro ist ein Roundhouse Kick!
Chuck Norris schreibt keine Software, er kompiliert seine Gedanken direkt in ausführbaren Code. Sein Code benötigt keine Tests, denn er ist fehlerfrei. Die Entwickler-Community verehrt Chuck Norris als den "Ultimativen Debugger", denn wenn er ein Bug findet, erscheint es vor ihm und fleht um Vergebung. Chuck Norris gibt keine Code-Reviews, er gibt Code-Verbesserungen, weil alles, was er berührt, automatisch besser wird.
Der Debugger löst Runtime Exceptions selber, der Debugger hat angst Sie zu zeigen
Chuck Norris möchte halt nicht bei der nächsten Umstrukturierung auf der Straße sitzen, weil er leicht ersetzbar geworden ist durch die ordentliche dokumentierte Wissensweitergabe.
Kluge Unternehmen wissen einen Mitarbeiter zu schätzen, der nicht nur Kreativ ist, sondern auch Wissen verbreitet. Das ist zumindest meine Erfahrung. Angst muss nur der haben, der eigentlich unfähig ist, aber einmal einen Glückstreffer gelandet hat.
@@alexich963 Unternehmen mögen vor allem gute Handelsbilanzen und Quartalsabschlüsse. Wenn Andere Mitarbeiter leicht eingearbeitet werden können, und junge Bewerber geringere Gehaltsforderungen haben, dann sieht die Sache betriebswirtschaftlich anders aus.
Der Mitarbeiter wird ersetzbarerer. Dass er versucht sich in einer schwer ersetzbaren Expertenstellung zu positionieren ist nachvollziehbar.
@@vast634 für so ein Unternehmen habe ich auch schon gearbeitet. Und das viel zu lange. Zu meinem Glück habe ich jetzt einen sozialen Arbeitgeber gefunden. Hier wird wissen grundsätzlich geteilt. Ich lerne jeden Tag von meinen Kollegen und bringe mein Wissen diesbezüglich auch ein. Bei Aufträgen schaut der Geschäftsführer nicht nur auf den finanziellen Mehrwert, sondern auch darauf, welches Know-How der Firma die Abarbeitung bringt. Und welch ein Wunder, die Geschäftszahlen passen auch!
@@vast634 Und wenn die Jüngeren nicht das bringen, was der "Chuck Norris" gebracht hat, hat Chuck Norris eben nicht gut genug dokumentiert, damit die Jüngeren dem folgen können.
Chuck Norris liefert Features in der geschätzten Zeit.
Hat jemand Tipps, wie ich meinen Arbeitgeber im Laufe der Zeit davon überzeugen kann, mehr Ressourcen ins Unternehmen zu holen und die Prozesse anzupassen, damit ich nicht mehr Chuck Norris bin?
Erst vor Kurzem habe ich drei Tage gebraucht, um ihn davon zu überzeugen, die Unternehmensstruktur von einer Entwicklungsgruppe in ein Entwicklungsteam umzustellen. Und der Prozess wird noch einige Monate brauchen.
Keine Chance. Sind denn die Entwickler teamfähig? Du kannst zwar Entwickler in ein Team zwingen. Der ist dann eine Randfigur und macht einfach seinen Job alleine weiter. Die Frage ist, ob es etwas bringt. Sind denn die Teams für eine Software verantwortlich? Oder sind das zusammengewürfelte Teams. Beim 2.ten Ansatz kannst Du das vergessen. Ich habe da einige Anekdoten:
- Ein auseinander ziehen von CAD und CIM, weil unbedingt jemand Teamchef werden wollte. Einige Zeit später wollte man dann eine Treibergruppe gründen neben den Teams, um das wieder gerade zu ziehen.
- Teammitglieder, die rein fachlich keinen überlapp haben, damit die dann irgendwann sich ersetzen können. Bspw ein Produktionsmonitor in verschiedenen Produktionsbereichen (DB, Barcode, Multithreading, FrondEnd Controls, BI), Treiberentwicklung (mathematisch, algorithmisch), diverse Tools und Bibliotheken (Barcode Service), Optimierung usw. Das kann man nicht mit 5 Entwicklern betreuen.
- Entwickler, die aus verschiedenen Teams an denselben Produkt arbeiten sollen. Ging auch schief, weil die Teamchefs sich nicht absprachen. Das war auch allen bis auf dem Entwickler, der das Produkt betreute, recht.
Das waren so einige Highlights. Am besten war dann noch, dass man agile Entwicklung bei zusammengewürfelten Teams einführen wollte. Was soll das bringen. Da hat man dann ein Refinement, was eine Stunde dauert, aber für jemanden nach 5 Minuten fertig ist. Oder eine Reflektion, wenn man eh alleine seinen Bereich betreut.
Ergänzend:
- Es werden dann auch alle x Jahre die Teams neu zusammen gewürfelt, weil man immer n Entwickler in einem Team haben muss. Teams müssen etwa die gleiche Größe haben (+/- einen Entwickler), damit Teamchefs bei der Bezahlung nicht meckern.
- Die Teamchefs sind eigentlich immer noch Entwickler und müssen irgendwas fürs Controlling ausfüllen, um die Zahlen einzuhalten. Der andere Kram Team Building, Meeting, Urlaubsplanung usw sind sekundär.
- Am besten ist dann noch, dass diese Controlling arbeiten von einem Teamchef für andere Teams gemacht werden und andere Teamchefs keine Lust darauf haben und diese arbeiten nur unregelmäßig machen. Aber dann alle Teamchefs eine gerügt werden. Absoluter quatsch.
Mag sein, dass es bei dir anders werden wird. Aber einfach Teams bilden, ist sicher nicht zweckgemäß. Die ganze Nummer muss ohne Teamchefs auskommen. Teams müssen sich selber organisieren. Es ist auch die Teamgröße egal, gut zu viele Entwickler sind auch nicht gut, aber es reichen auch mal 2 oder 3 Entwickler in einem Team. Zudem müssen die Entwickler das wollen. Wenn jemand keine Lust auf Teams hat, dann wird das nichts.
Ich habe mir vor kurzem erst so ein Projekt angesehen, wird im wesentlichen von einer einzigen Person betreut, eben ein Chuck Norris Entwickler. Einzelkämpfer. Macht auch 2nd level support. Dokumentationen? Fehlanzeige. Ich habe ein bisschen Angst dort einzusteigen. aber andererseits gibt es für mich persönlich sonst keine anderen Herausforderungen derzeit… leider!
Wenn die Person irgendwo doch ein Teamplayer ist, dann kann sowas auch ne Chance sein. Ohne vorher mit dem anderen Entwickler deine Aufgaben zu besprechen, würde ich aber nicht anfangen.
Vollkommen richtig@@Askunics es haben sich jedoch tatsächlich andere Möglichkeiten zwischenzeitlich eröffnet, welche einer Zusammenarbeit mit einem Chuck Norris Entwickler deutlich zu bevorzugen sind.
Es gibt Kollegen. die sich überschätzen. Manche davon sind Programmierer.
Kein Entwickler kann in Java ein System.exit(0); mit catch abfangen? - Doch! Chuck Norris kann.
Dieser Witz entstand vor vielen Jahren, als einer meiner damaligen Azubis gefragt hat, ob man mit Catch ein System.exit(0) abfangen könne, und einer der Senior-Kollegen nur trocken sagte "Chuck Norris kann."
Dafür kann der Entwickler nichts, wenn der AG nur wenige/keine Devs einstellt. Das hat der AG zu verantworten. Der Dev kann und sollte sein Bestes geben, mehr geht aber nicht. Code ist komplex.
-> Chuck Noris kann Alt + F4 ohne Konsequenzen drücken ... mit einem Finger
-> Chuck Noris Codet nicht, der Code schreibt sich von selbst.
Chuck Norris kennt alle Excel-Funktionen. Chuck Norris kann jede Tastaturkombination mit einem einzigen Handkantenschlag eingeben. Chuck Norris kann mit einer deutschen Tastatur chinesische Schriftzeichen schreiben. Chuck Norris ist an jedem PC automatisch Administrator. Chuck Norris braucht sich keine Passwörter zu merken, denn "Chuck Norris" ist das Universalpasswort und es traut sich keiner ausser ihm selbst, es einzugeben. Chuck Norris braucht keine Maus, denn jeder Computer gehorcht seiner Mimik. Chuck Norris hat auch ohne Router überall WLAN. Bei Chuck Norris sagt die Wikipedia immer die Wahrheit. Chuck Norris kann alle Computerprogramme nutzen, ohne den Nutzungsbedingungen zuzustimmen.
Waoh. Ich bin auch ein Chuck Norris... Danke für das Video, ich werden mich morgen direkt an der Code Lesbarkeit und Dokumentation machen.
Bin auch so einer. Eine Dokumentation habe ich schon angelegt, werde aber nochmal mehr Zeit und Aufwand investieren, um sie auf Vordermann zu bringen.
Ich habe leider das Problem, dass ich ein Chuck Norris als Programmadmin bin. Die Kollegen, mit denen ich zusammenarbeite sind aber größtenteils ihrer Zeit in Projekten tätig und keiner kann die Programmiersprache. Ich fürchte, wenn meine Addins nicht mehr funktionieren, werden sie eher verworfen als weiterentwickelt.
Chuck Norris bekomme keine Null-Pointer-Exception. Den keine Exception traut sich auf Chuck Norris zu zeigen :-)
Chuck Norris kennt keinen Stack Overflow, denn er benutzt keinen Stack!
😂😂😂
Chuck Norris fragt nicht ChatGPT, ChatGPT fragt Chuck Norris
stimmt
Chuck Norris wollte programmieren lernen, ihm war Brainfuck aber zu einfach, also hat er eine neue Sprache entwickelt, die nur aus 1 und 1 besteht, denn er kennt keine 0.
The Rabbit Hole: "Chuck Norris kann nicht besser sein als Chuck Norris" 😂 boah, jetzt sind meine Synapsen durchgeschmorrt.
Das ist vergleichbar wie bei mir damals in der Logistik. Als Azubi gehste in eine Abteilung wo du was lernen willst, bekommst eine "5 Minuten Einführung", des LMS und kriegst nen feuchten Händedruck. Wenn du dann was fragen willst: "hab keine zeit", war der standardspruch. 😂
Chuck Norris kann durch 0 teilen.
der trick ist, ein fauler chuck norris zu sein: man *könnte* alles tun, aber wenn delegation möglich ist, tut man es und stellt nur die qualität sicher
Chuck Norris benutzt nicht Chat-GPT - Chat-GPT ist eine minderwertiges Modell von Chuck Norris.
Puhh auch hier wieder so viele parallelen zum Job :(
Ich würde den Chucks wohlwollend nur selten Bösartigkeit unterstellen. Man wächst halt in die Rolle rein und bis zu einem gewissen grade ist das ja auch schmeichelhaft wenn jeder um das eigene Wissen buhlt.
Meiner Erfahrung nach ist das ausschlaggebende Problem aber oft Führungsschwäche. (Chuck Norris dürfte nur selten der weisungsbefugte Chef sein) Dort sitzen dann Leute die sich viel zu wenig auskennen und Dinge nicht bewerten können(natürlich muss der Chef nicht jede Codeecke kennen...aber einen groben Überblick und Grundverständnis sollte schon da sein)
Chuck "löst" dann alle Probleme und el Chefe kapiert überhaupt nicht welche Probleme daraus entstehen. MMn ein ganz schöne Führungsproblem und ausruhen au fden sich selbst organisierenden Teams. Das können und sollen Teams in gewissen Grenzen ja machen, aber irgendwie wird das oft Missverstanden und Chef lehnt sich zurück und es gilt laissez faire
Chuck Norris Software ist fehlerfrei. Immer.
Chuck Norris programmiert nicht.
Der Comuter macht aus Angst was Chuck sagt
Doku erstellen. Ou ja. Könnt mir nix schöneres vorstellen. Hatten wir gerade. Oben beschreibste was gemacht wurde und weiter unten bewschreibste den ganzen Spaß nochmal. Dann soll da aber was anderes stehen. Ich komm mit dem ding nicht wirklich klar.
👊🏽😂