WARUM ein guter Softwareentwickler nicht immer gut ist!

In der Softwareentwicklung gibt es einen gefährlichen Trend, den viele vielleicht bereits erlebt haben: Der „Chuck Norris“ Entwickler. Dieses Video beleuchtet die Risiken, die auftreten, wenn ein einzelner Entwickler mit zu viel Verantwortung betraut wird.

- Eine wahre Geschichte: Ich teile meine persönliche Erfahrung bei einem Arbeitgeber, der sich entschied, fast alles auf meine Schultern zu laden. Was hätte schief gehen können?

- Der „Chuck Norris“ Entwickler: Erfahrt, warum es nicht nur stressig, sondern auch gefährlich ist, wenn ein Entwickler alle Zügel in der Hand hält.

- Die falsche Art zu wachsen: Wie Teams ihre eigenen Fortschritte gefährden, indem sie die Balance der Verantwortung vernachlässigen.

- Das Risiko für Unternehmen: Ein Einblick in die potenziellen Katastrophen, die Unternehmen erwarten könnten, wenn sie zu sehr auf einzelne "Superhelden" setzen.

- Das tragische Ende: Das Ende eines Projekts, das ohne mich zusammenbrach.

Für alle Softwareentwickler, Softwarearchitekten, DevOps Engineers und Entscheidungsträger: Dieses Video ist ein Muss, um zu verstehen, wie man ein ausgewogenes und effizientes Entwicklungsteam aufbaut. Vermeidet die Fallstricke und lernt aus den Fehlern anderer, um eure Projekte erfolgreich zu machen.

## Kapitel
[00:00] Einleitung: Das Risiko zu großer Verantwortung.
[01:11] Mein Abenteuer: Alles auf eine Karte.
[03:27] „Chuck Norris“ Entwickler: Wenn Helden gefährlich werden.
[04:09] Falsches Teamwachstum: Balance der Verantwortung.
[06:04] Risiko für Unternehmen: Der Albtraum jedes CTOs.
[10:00] Das Ende: Projekt-Kollaps ohne mich.

▬ Über diesen Kanal ▬▬▬▬▬▬▬▬▬▬▬▬

Seit vielen Jahren arbeite ich als Consultant, Coach und Trainer für professionelle Softwareentwicklung mit den Schwerpunkten Softwarequalität, Softwarearchitektur sowie Prozessmanagement. Auf meinem Kanal möchte ich Euch mein Wissen und meine langjährige Erfahrung in diesen Bereichen vermitteln - natürlich kostenlos. Dabei versuche ich stets Euch das Wissen so zu vermitteln, dass Ihr damit direkt in der Praxis loslegen könnt und das ganze immer mit guten Portion Humor. Lernen soll ja schließlich Spaß machen :)

▬ Empfohlene Videos ▬▬▬▬▬▬▬▬▬▬▬▬

▬ Wichtige Links ▬▬▬▬▬▬▬▬▬▬▬▬

▬ Social Media ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

[timmkrause]

Chuck Norris kann Interfaces instanziieren.

[FCHFlo]

Chuck Norris codet nicht nach Test-Driven Development, Tests passen sich seinem Code an.

[FCHFlo]

Chuck Norris praktiziert keine Retrospektiven. Er weiß bereits, was gut gelaufen ist, denn er war dafür verantwortlich.

[cinematiX.flights]

- 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.

[FCHFlo]

Chuck Norris' User Stories benötigen keine Akzeptanzkriterien. Die Stories akzeptieren einfach Chuck Norris.

[i.o.]

Chuck Norris kann Strg+Alt+Delete mit einem Finger drücken.

[MrPopel]

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

[daschmitzi]

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.

[AndreasJacob]

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 (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 Ich sehe da durchaus einige Parallelen.

[yogilein]

Bei Chuck Norris failed nie ein Test, sie laufen aus Respekt....ebenso wie sein Code.

[ministerstein]

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..

[DJoneone]

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.

[DarKOscillator]

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...

[heinrich]

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...

[VitalijMik]

Aussage vom Unternehmen: "wir haben flache Hierarchien"
Realität bei der Arbeit: "Du machst alles alleine und bist alleine für alles verantwortlich" :D

[stefansgorzaly]

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.

[FaeRhanX]

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.

[i.o.]

Chuck Norris kann eine Email ohne Internet verschicken.

[joergfoerster]

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?)

[andreweinert]

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.