Drücken Sie Enter, um das Ergebnis zu sehen oder Esc um abzubrechen.

Gute Entwickler sind schwer zu finden!

In einem Training, an dem ich letztens teilnahm, kam unter den Entwickler wieder ein Mal die Diskussion auf, dass es doch gar keine guten Entwickler gäbe und es so schwer sei, neue Mitarbeiter zu finden. Die Teilnehmer, eine Handvoll jahrelang in der Softwareentwicklung erfahrener Menschen, waren alle der Meinung, sie kriegen keine guten Leute, die Entwickler von heute wären alle nicht brauchbar.

Nach regem Kopfnicken und Zustimmung fragte doch tatsächlich einer der Anwesenden, was denn wohl die Gründe dafür seien. Diese Frage warf natürlich wiederum eine andere auf, nämlich: „Wer ist denn ein guter Entwickler bzw. welche Kriterien erfüllt dieser?“ Da es ein Training zum Thema Selbstorganisation war, haben wir uns einfach einige der Anforderungen an die jungen Bewerber genauer angesehen.

  • Zunächst möge der Junior Entwickler genug Erfahrung mitbringen. Wie soll denn der Junior Entwickler Erfahrung sammeln, wenn alle nach Junior Entwicklern mit Erfahrung suchen? Nun gut, nach diesem Einwurf erbarmte sich einer der Teilnehmer und meinte : “Ja, man kann den sicher auch einarbeiten, ist ja noch kein Meister vom Himmel gefallen“. Puhh Glück gehabt, unser Bewerber hat unsere 1. Anforderung mit Ach und Krach geschafft.
  • Der Entwickler sollte mit mehreren Tools umgehen können (es wurden so viele aufgezählt, dass der Platz auf dieser Seite dafür nicht ausreichen würde). Okay, einer kann ja nicht alles wissen, da waren wir uns alle einig. Aber zumindest die gängigsten Tools sollte der Entwickler im Schlaf beherrschen. Damit war auch der Großteil einverstanden. Vor allem sollte sich der Bewerber nur bewerben, wenn er tatsächlich die im Inserat angegebenen Tools auch beherrscht. Auch bei diesem Einwand wurde rege mit den Köpfen genickt.
  • Der Entwickler möge sich seine benötigten Informationen selbst erarbeiten. In diesem Punkt gingen wieder die Meinungen auseinander. Die einen bestärkten mit Kopfnicken, während die anderen meinten, eine gute Einarbeitung seitens eines Seniors wäre unumgänglich. Bei diesem Punkt wurde sehr schnell das Thema Wissenstransfer angesprochen und auch die Tatsache, dass Senior Entwickler ungern ihr Wissen teilen. Aber auch bei diesem Punkt waren wir uns größtenteils einig. Ein neuer Junior Entwickler könnte genau diesem Problem entgegenwirken. Wir würden einen Senior Entwickler aus dem Team zu den Bewerbungsgesprächen dazuholen, damit er auch mitbestimmen könnte, wer eingestellt wird. Da auch er derjenige ist, der den neuen Mitarbeiter einarbeiten wird.
  • Die Arbeit mit agilen Methoden wie Scrum, Kanban oder ähnlichem sollte für den Junior Entwickler selbstverständlich sein. Hier waren wir uns natürlich alle einig. Ein kompetenter Mitarbeiter, der selbstverantwortlich und selbstorganisiert arbeiten kann. Der cross-funktional arbeitet und über ein agiles Mindset verfügt. Oh ja, unser Herz ging auf bei diesem Punkt, und wir nannten noch viele weitere Punkte. Doch dann sagte einer: „Aber genau das ist der Grund, warum wir keine guten Entwickler finden.“

Was sollte das heißen? Wir waren alle doch recht verwirrt nach diesem Einwand.

Seine Theorie:
In einem agilen Umfeld sind Soft Skills gefragt. Wir erwarten uns von den Entwicklern, dass sie kommunizieren, sich mitteilen, diskutieren und Entscheidungen treffen. Doch viele Entwickler werden Entwickler, weil sie sich nicht austauschen möchten und sonst kein Interesse an Kommunikation haben. Hinzu kommt, dass sie gerne Vorgaben haben, nämlich genaue Vorgaben. Diese Vorgaben nehmen sie, gehen in ihre Kammer und coden, bis sie alles abgearbeitet haben. Doch in einem agilen Umfeld planen wir iterativ, wir lernen dazu und verbessern uns immer wieder. Diese Entwickler tun sich sehr schwer mit dieser Art des Arbeitens.

Er glaubte tatsächlich, dass die fehlenden Soft Skills, die im agilen Umfeld erwartet werden, bei vielen Entwicklern nicht vorhanden wären, und dass dies der Grund dafür wäre, warum sich so schwer gute Entwickler finden ließen.

Und auf diese Ausführung hin gab es erneut reges Kopfnicken.

  • StephanR

    Tja, wo soll ich anfangen mit meinem Kommentar?

    Zunächst einmal möchte ich mit einem Mythos aufräumen: so einen Blödsinn wie „Junior-“ oder „Seniorentwickler“ gibt es nicht. So etwas kann es in dem hochdynamischen Umfeld der Softwareentwicklung gar nicht geben. Es mag Entwickler geben, die in bestimmten Technologien oder Programmiersprachen über Jahre hinweg mehr Know-How aufgebaut haben als in anderen Technologien oder Programmiersprachen. Sobald man aber einen vermeintlichen „Senior-„Entwickler beispielsweise mit einem neuen Programmierparadigma konfrontiert, fängt dieser ziemlich weit unten wieder neu an – im Gegenteil: häufig ist da sein bestehendes Wissen, die Betriebsblindheit, sogar hinderlich. Ich als Trainer und Berater erlebe das ständig, wenn Entwickler mit jahrelanger Erfahrung aus der prozeduralen Welt plötzlich mit objekt-orientierten Paradigmen konfrontiert werden, oder OO-Leute mit funktionaler Programmierung.

    Darüber hinaus mache ich der agilen Bewegung auch Vorwürfe, eine nicht unwesentliche Mitschuld an der Misere zu haben. Bitte nicht falsch verstehen: ich bin ein großer Befürworter agiler Methoden. Ein kurzer Blick in den Scrum-Guide reicht aber aus, um festzustellen, dass man es anscheinend mit dem agilen Prinzip „Kontinuierliche Aufmerksamkeit auf technische Exzellenz und gutes Design fördert Agilität im Projekt“ nicht so richtig Ernst meint. Der Begriff „Software“ kommt ja im Scrum-Guide noch nicht einmal vor, man spricht ganz abstrakt von einem Produkt. Daraus folgt auch, dass man nicht genau sagen kann, welches Skill-Set die Entwickler haben müssen. Die Agilisten fokussieren auf Rollen, Sprints, Retrospektiven, und andere agile Folklore. Ich möchte aber mal das blöde Gesicht eines agilen Beraters sehen, wenn ich auf diesen zugehen und ihn fragen würde, ob wir nicht mal 1 Stunde pairen wollen, um gemeinsam eine TDD-Code-Kata durchzuführen.

    Was macht einen guten Softwareentwickler aus? Ich denke, das die Software Craftsmanship Bewegung darauf eine gute Antwort parat hat. Es geht um ein Mindset, und nicht um das Beherrschen tausender Tools (Nur zur Erinnerung: „individuen und Interaktionen…“). Es geht um die Bereitschaft zur kontinuierlichen Weiterentwicklung. Es geht darum, nicht nur funktionierende Software abzuliefern, wie es das agile Manifest fordert (Funktionieren kann auch ein Haufen crap), sondern auch handwerklich exzellent gefertigte Software. Und ein guter Softwareentwickler kann auch mit Nachdruck „Nein“ zu Dingen sagen, die ein inkompetenter Manager verlangt, die aber unmöglich zu realisieren sind.

    Leider, und das ist wahr, fehlt es in unserer Branche an solchen Menschen.

    • Ich stimme Ihnen in dem Punkt, dass es „Junior“ und „Senior“ Entwickler nicht gibt voll zu. Ich gehe sogar noch einen Schritt weiter und würde diese Aussage – vorsichtig generalisiert – auf alle Branchen ausweiten. Bei Entwicklungsteams bin ich der Meinung, dass man zuerst nach einem „cultural fit“, also jemandem der von der Persönlichkeit ins Team passt, suchen sollte. Technisches Grundverständnis und zumindest eine Grundausbildung und Lernfähigkeit sollte der Bewerber mitbringen. Ich habe in meiner beruflichen Laufbahn sehr selten mit Unternehmen zu tun gehabt, die tatsächlich Experten benötigen. Das meiste kann und muss man einem neuen Mitarbeiter – egal welchen Alters und fast unabhängig der Vorerfahrung, „on the job“ beibringen.

      Ich möchte gerne noch Ihren Punkt bezüglich des Zussamenhangs von Scrum (bzw. anderen agilen Vorgehensweisen) und der Softwareentwicklung, respektive den Anforderungen an Entwickler. aufgreifen. Für mich hat Scrum nicht grundlegend und unbedingt etwas mit der Entwicklung von Software zu tun. Sie können, nach meinen Erfahrung, agile Entwicklung in vielen anderen Bereichen einsetzen, in denen es schlussendlich um die Entwicklung oder Verbesserung eines bestehenden Produkts geht. Scrum ist per se ein Framework zur Organisation eines Entwicklungsprozess. Als Framework stellt es einen Rahmen bereit, den man beliebig ausfüllen kann, um so für die bestehende Organisation ein realistisches und sinnvolles Vorgehen zu finden. Aus diesem Grund wäre es für mich auch kontraproduktiv direkt im Scrum-Guide sofort eine Bindung zur Softwareentwicklung herzustellen.

      Ich habe im realen Einsatz mit „Feindkontakt“ eher die Beobachtung gemacht, dass „Kontinuierliche Aufmerksamkeit auf technische Exzellenz und gutes Design fördert Agilität im Projekt“ von Scrum zwar als Grundbedingung von jedem Mitspieler gefordert wird, aber von den meisten Organisationen (egal, ob Unternehmen, Teams oder Abteilungen), sehr schnell „abgewürgt“ wird. Technische Exzellenz – gutes Design ist darin für mich inbegriffen – kostet Zeit. Zeit, die man in die Ausbildung der Mitarbeiter und die Umsetzung investieren muss. Wie wir alle, die auf die eine oder andere Weise in der „agilen Beratung“ tätig sind, wissen, gilt: Zeit ist Geld. Und hier wird der direkte Nutzen nicht sofort offensichtlich, wodurch man hier gerne spart.

      Zu guter letzt will ich mich dem „blöden Gesicht eines agilen Beraters“ widmen, wenn sie von ihm ein TDD-Code-Kata einfordern. Ich selbst bin seit einigen Jahren in diesem Bereich tätig. Davor und währenddessen habe ich privat, wie beruflich Software entwickelt – und glaube das auch relativ gut gemacht zu haben. Nebenbei gehört ständige fachbezogene Weiterbildung dazu. Daher können Sie mit mir gerne TDD-Code-Katas durchführen. Das liegt jedoch eher daran, dass ich mich als Coach und agiler Befürworter für Teams, die Software erzeugen sehe. Ein agiler Berater muss für mich nicht grundsätzlich viel Ahnung von Softwareentwicklung haben. Will er jedoch Software-Teams beraten, dann wäre ihm das angeraten. Sie würden doch auch keinen Finanzberater dafür bezahlen Sie in Bauangelegenheiten zu beraten. Brauchen Sie jedoch finanzielle Beratung für ein Bauprojekt, dann sollten Sie einen Finanzberater, der auf die Baubranche spezialisiert ist zu Rate ziehen. Was ich damit sagen will: Agile Berater arbeiten – aus meiner Sicht – vorrangig in der Organisations- und Managementberatung. Sollten sie dazu eingesetzt werden auch Softwareentwickler im Bereich der Entwicklungspraktiken zu coachen, dann sollte man sich auch Berater holen, die dieses Wissen in ihrem Portfolio haben.

  • Edwin

    Das Bild des stummen Nerd, der sich im Keller verschanzt bis er fertig ist, ist überholt. In unserer letzten Bewergunsrunde haben wir 160 Bewerbungen gesichtet. Bei vielen Vorstellungsgesprächen war ich dabei und es ist mir keiner dieser Nerds über den Weg gelaufen.

    • Jochen Bünnagel

      Wie schon Joel Spolski vor Jahren erkannte: In Ihrer Bewerbungsrunde haben Sie keinen Top-Entwickler gesehen, weil sich Top-Entwickler so gut wie nie um einen Job bewerben. Sie haben nämlich schon einen, meist bei einem Arbeitgeber der weiß, was er an ihnen hat und sie entsprechend behandelt.

  • Patrick Koglin

    Hallo!

    Spannender Beitrag. Vor allem die Schluss-Esenz die mir doch etwas unlauter hängen bleibt. Fehlende Soft Skills als größtes Hindernis? Ich weiß noch nicht so recht.

    „Hinzu kommt, dass sie gerne Vorgaben haben, nämlich genaue Vorgaben“ – Hm – ein Aspekt über den man Stunden sprechen könnte. Ein Austausch wäre sicher spannend.

    Mich würde interessieren an welchen Ansatzpunkten sich das gezeigt hat. Was sind denn diese Soft Skills die man erwartet? Wo stehen die? Wie könnte ich diese (er-)lernen?

    Ich glaube das ich noch in keiner Stellenbeschreibung von diesen Skills gelesen habe. :) Dort fordern die Unternehmen solche Dinge wie .NET 3.5, .NET 4.0, Microsoft SQL Server, WCF, WPF, WinForms, Java, Mocks und Stubs, MongoDB, Serviceorientierte Architekturen, Design pattern, usw. usf.

    Somit kommen wir also sehr schnell in eine Schuldangelegenheit. Sind es diese Nerdigen Entwickler oder diese bösen HR-Menschen die die Stellenprofile erstellen? Weder noch. Denn irgendwo sind des beide, alle und es geht nicht um Schuld.

    Und zusätzlich mag ich folgenden Artikel verlinken der sich ebenfalls dem Thema widmet (ohne diesen Artikel gekannt zu haben, also unabhängig von dieser Annäherung)
    http://www.agile-is-limit.de/die-frage-nach-dem-warum-oder-was-ist-ein-guter-entwickler/

    Lg
    Patrick Koglin

  • Luner

    Es hat mal einer gesagt “ you can’t be agile if your code sucks“. Ich glaube, das ist korrekt. Customer collaboration over following a plan, inspect & adapt das alles impliziert doch mehr oder weniger schnelle Bewegung. Das geht aber nicht wenn man einen Rucksack mit technischen Schulden mit sich rumträgt oder eben zunehmend komplexere Technologie nicht richtig versteht/anwenden kann.

    Software Engineering mag ein commodity – weil weltweit verfügbare Dienstleistung – geworden sein, die man teilweise zu günstigen Preisen einkaufen kann. Irgend ein dummes Stück Software kann man tatsächlich günstig im Ostblock oder fernen Osten produzieren lassen.

    In zunehmend kompetitiven Märkten ist es aber viel entscheidender welche Produktivität Ihr Entwicklungsstaff hat. Wie viel Handlungskompetenz bringen Ihre Entwickler mit – sind die überhaupt Willens und in der Lage Probleme, Features eben Technik – übergreifend zu lösen ?

    Für mich ist ein guter und moderner Softwareentwickler einer der eine gewisse technische Expertise hat – in einem oder mehreren Bereichen. Der aber auch eine Breite an Kompetenzen mitbringt (T-shaped people). Ein moderner Entwickler kann von sich aus auf andere, non techies zugehen und mit minimalen & pragmatischen organisatorischen Massnahmen Probleme übergreifend lösen. Ein moderner Softwareentwickler ist jemand der auch mal Leute zusammenbringt und auf Basis seiner Expertise technisch komplexe Zusammenhänge im Kern einfach erklären kann. Ob dann einer Programmiersprache X oder Y gut beherrscht…..einerseits ist das zwar eine gute Grundvoraussetzung, aber viel wichtiger als die Skills ist doch die Einstellung („attitude“). Mit Passion, Ehrgeiz, Willen, Interesse kann man auch als halb – talentierter Entwickler praktisch jede Technologie meistern. Entscheidend sind aber diese Softskills.