Alice Mottola – Einführung ins Programmieren

Wenn Du dir einen Mentor vorstellst, der Dir das Programmieren beibringt, dann kommen einem schnell bestimmte Archetypen in den Sinn. Vielleicht denkst Du an den weisen Mönch, der seit Jahrzehnten auf „design patterns“ meditiert. Vielleicht es der erfahrene Keynote-Sprecher mit eiener Schwindel errengenden Liste von Beiträgen zu Open Source Projekten. Vielleicht auch der Typ „verrückter Wissenschaftler“, der von Dutzenden Programmiersprachen bessenen ist, von denen Du noch nie gehört hast.

Aber wenn in deinem Team keine solcher Charakter da ist und die frisch von der Schule weg Angestellen auftauchen, wer nimmt bei der Schulung das Heft in die Hand?

Natürlich Du.

Mit dem Aufstieg der Programmmier-Boot-Camps und der gesteigerten Immatrikulation in den Computerwissenschaften an den Universitäten ist der Pool an Junior-Entwicklern so groß wie nie zuvor. Aber wenn es darum geht, diese Talente auch zu pflegen, wissen viele Teams nicht, wo sie anfangen sollen. Einige Entwickler halten sich für nicht gut genug, ein Mentor zu sein, während andere sich für zu beschäftigt halten.

Was auch immer Deine anfänglichen Zweifel sein mögen, Du kannst lehren, und Du kannst es gut. Alles was Du brauchst, sind die richtigen Richtlinien und ein bisschen Struktur.

Los gehts mit der Mentor-Schützling-Beziehung

Wenn Du einen Schützling suchst, suche „jemand, der Dir etwas beibringen kann, es aber noch nicht weiß“, hat mir neulich ein Freund empfohlen, der bei RailsBridge betreut.

Das bedeutet für mich zweierlei: das erste ist, offen für verschiedene Persönlichkeitstypen zu sein. Suche jemanden, der Dir nicht ähnlich ist. Es kann verlockend sein, die Neulinge mit Dir vor 3 Jahren zu vergleichen und dann zu schlussfolgern. Aber Mentor sein ist keine Einbahnstraße – es geht nicht ums unterrichten. Es geht nicht einmal darum, dein Wissen an eine andere Person weiterzugeben. Es ist eine gegenseitige Vereinbarung, besser zu werden in dem, was ihr beide tut. Ihr werdet mehr voneinander lernen, wenn ihr verschiedene Denkweisen habt.

Das zweite ist, jemanden auszuwählen, von dem Du lernen willst. Wenn dein Schützling nicht die Person ist, mit der Du gerne in eine Code-Schlacht ziehen willst, kommst Du nicht weiter. Die Haupteigenschaft ist es, Arroganz zu vermeiden; eine arrogante Person wird eine langsamere Lernkurve haben als jemand, der Feedback gerne und dankbar annimmt.

Weil Team-Dynamik sich schnell ändert, kannst Du oft keine formale Mentor-Schützling-Beziehung mit Menschen in deinem Team aufbauen. Das bedeutet nicht, dass Du keine Gelegenheit findest, zu lehren. Achte auf die kleinen Momente, an denen Du eingreifen und helfen kannst, Du wirst als Führung gesehen und es wird mehr Gelegenheiten geben, an denen Du deine Patenschaft ausüben kannst.

Agilität ist der Schlüssel

Der Schlüssel dazu, ein guter Mentor zu sein, ist ein Konzept, mit dem Du bereits vertraut bist, weil es auch der Schlüssel zum Entwickeln guter Software und zum Lernen neuer Dinge ist. Dieser Schlüssel ist Agilität.

„Agil“ ist mittlerweile ein ziemlich aufgeladendes Wort, welches oft mehr verwirrt als klarstellt. In einem Blogpost von 2014 hat Dave Thomas, einer der ursprünglichen Unterschreiber des Agilen Manifests, seine Verwirrung gestanden. Dann erinnerte er uns daran, alles auf agile Weise zu tun:

  • Finde heraus, wo Du stehst
  • Tue einen kleinen Schritt auf dein Ziel zu
  • Passe deine Wahrnehmung auf der Grundlage deines Ziels an
  • Wiederhole das ganze

Oder wie der Scrum-Guide es ausdrückt: „untersuchen und anpassen“. Untersuchen und anpassen und sind wichtige Eigenschaften für einen guten Mentor. Wenn Du Dir nicht die Zeit nimmst, nach deinem Schützlingen zu schauen und ihre Sorgen, Mühen und Erfolge anzuhören, kannst Du deinen Erfolg nicht messen.

Um Agilität als Mentor einzusetzen, braucht es Fingerspitzengefühl, Kreativität und gute Kommunikations-Fähigkeiten. Man braucht außerdem die Voraussicht, wonach der Schützling streben sollte und die Rückschau, was der Schützling bereits erreicht hat.

Um einen Rahmen etablieren, in dem man den Fortschritt deiner Schützlinge messen kann, sollte man drei Phasen definieren, die jedes neue Team-Mitglied in einer bestimmten Form durchläuft. Die erste Phase ist totale Neuheit und ständige Entdeckung, die zweite eine Übergangsphase mit klarem Entwicklungsverlauf und die dritte die selbst-laufende Kompetenz. In allen drei Phasen ist Aglität aber immer noch das wichtigste Werkzeug.

Phase 1 – Etwas Respekt bitte
Am allerersten Tag solltest Du dich mit dem Schützling unterhalten um genau herauszufinden, auf welchem Level er sich befindet und was seine Erfahrungen bisher sind. Diese Unterhaltung hat zwei Gründe. Zuerst einmal entsteht ein bidirektionaler Diskurs, eine kommunikative Beziehung die den agilen Ansatz unterstützen wird. Zweitens gibt es Dir einen Anhaltspunkt zu entscheiden, welche Aufgaben dein Schützling zuerst bekommt. Der Start mit einer direkten Kommunikation kann einen unglaublichen Haufen Verwirrung und Zeitverschwendung verhindern.

So genanntes Pair-Programming sollte an dieser Stelle verpflichentend sein. Es ist mit Abstand die beste Methode, einen neuen Entwickler schnell arbeitsfähig zu machen, besonders, wenn ihr eine große oder komplizierte Code Base habt. Ein kürzlich erschienener Artikel von Sarah Mei enthält ein paar gute Punkte, wie man Pair Programming effektiv umsetzt, aber der auffälligste ist: „Fass‘ die Tastatur nicht (oft) an!“ Stell Fragen, beanworte Fragen mit noch mehr Fragen. Je ähnlicher euer Level ist, je schwieriger ist es, „auf dem Rücksitz“ zu sitzen, denn oft musst auch Du die Dinge noch selbst herausfinden. Aber jedesmal wenn Du das Gefühl hast, Du musst Dich nach vorne rempeln und das Problem lösen, lass es! Dein Schützling wird durch den Sokratischen Stil viel effektiver lernen.

Denk daran, dass Du nicht nur ein technischer Guide bist. Am Anfang ist der Erwerb von technischen Fähigkeiten nicht der wichtigste Punkt auf der Liste eines Junior Developers – auch wenn diese das jetzt überrascht. Sie werden mit sozialen Puzzles konfrontiert und Prozess-Eigenheiten, die jeder andere als selbstverständlich sieht. Beseitige diese Verwirrungen rund um die Arbeit, so dass Dein Schützling keine Probleme hat, sich auf die Arbeit selbst zu konzentrieren.

So begierig Du auch sein magst, Dinge in Bewegung zu halten, stelle sicher, dass Du auch über deine eigenen Grenzen ehrlich bist. Denke über Phrasen wie „Ich verstehe das auch nicht“, „Ich brauche eine Pause“, „Ich kann Dir gerade nicht helfen, frag‘ mal Oleg“ nach. Jede davon ist Musik in den Ohren eines Anfängers. Je ehrlicher Du bist, wann und wie Du und andere helfen können, je realistischer wird die Aussicht deines Schützlings. Und eine realistische Aussicht führt zu guten Entscheidungen.

Phase 2: Herausforderung angenommen
Mit einer soliden, kommunikativen Beziehung ausgestattet, wird der Schützling schnell aus der Blümchenwiese herauswachsen. Du weisst, dass Du in Phase 2 bist, wenn er/sie direkt weiß, was bei einem Ticket getan werden muss, ohne dass er/sie genau weiß, wie. Dann beginnt der Spaß und es wird Zeit, ein bisschen Wettbewerb einzubringen.

Was auch immer Du tust, schieb nicht einfach alles an deinen Schützling weiter. Untersuche und passe an, wähle Aufgaben aus, die darauf aufbauen, was dein Schützling bisher getan hat. Wenn möglich, versuche eine Art Story mit den Aufgaben aufzubauen. Etwas im nächsten Ticket könnte einen Aspekt des vorherigen vertiefen oder verstärken. Oder Du erzählst die Geschichte eines einzigen Requests, von der UI zur Datenbank und wieder zurück.

Wenn Du deinem Schützling Aufgaben zuweist, die die ziemlich einfach aussehen, nutze es als Gelegenheit, sie mit einem pessimistischen Blick auf den Code sehen zu lassen. Was würde ein NULL-Input bewirken? Öffnet das Angriffsvektoren? Könnte man eine andere Komponente refactoren um diese Änderung einfacher zu machen? Decken die Testfälle den ganzen neuen Code ab? Selbst wenn Dein Schützling entscheidet, dass der Code wasserdicht ist (was er niemals ist), werden Sie ihre Programmier-Fähigkeiten üben, wenn Sie Deine Fragen beantworten.

Wenn Du deinen Schützling in jedem Zug forderst, vergiss nicht, die vielen Gelegenheiten zu nutzen, sie zu ermutigen. Eine Aufgabe, die für Dich eine Routineangelegenheit ist, fühlt sich für deinen Schützling vielleicht wie ein Triumph an, wenn Sie also etwas beenden, gratuliere ihnen und unterschätze niemals die Kraft eines einfachen „Gut gemacht.“

Phase 3: Das Aufnahme-Spiel
Dein engültiges Ziel ist es, deinen Schützling in eine produktives, beitragendes Team-Mitglied zu verwandeln – einen gleichwertigen. Mit genug Zeit und Übung werden sie das vielleicht auch mal. Aber warum so lange warten? Es gibt einen besseren, schnelleren Weg. Wenn dein Schützling bereit ist, kannst Du den Übergang mit einem Werkzeug, dass so alt ist, wie Menschheit, beschleunigen: die Aufnahme.

Egal wer Du bist oder wo Du herkommst kennst Du das eine oder andere Aufnahme-Ritual. Joseph Campbell hat es als eines der Hauptbestandteile der Heldenreise beschrieben, das zu Grunde liegende Muster wird von Sagen über alle Welt geteilt. Von der altertümlichen Mythologie bis in die Hauptstützen der Popkultur wie Star Wars und Fight Club haben Aufnahmerituale viele verschiedene Formen angenommen. Der Rahmen dafür ist immer der Gleiche: eine qualvolle Probe die, wenn Sie überstanden wird, den Probanden auf ein neues und höreres Level der Erkenntnis bringt.

Aufnahmen sind nicht nur was für Helden aus Sagen. Es ist ein mächtiges Werkzeug für eine Umwandlung in jedem Kontext. Wenn Du der Meinung bist, dein Schützling ist bereit, einen großen Schritt zu gehen, weise ihm eine Aufgabe zu, die ein bisschen zu komplex scheint, ein bisschen außerhalb dem Bereich dessen, was er bisher gemacht hat, aber gerade schwierig genug, um die Verwandlung in ein gleichwertiges, unabhängiges Teammitglied zu beschleunigen.

Eine effektive Aufnahme für einen Software-Entwickler sollte drei Qualitäten haben:

  1. Es sollte auch für jemanden mit mehr Erfahrung kein triviales Problem sein.
  2. Es erfordert Kommunikation mit Senior-Level-Kollegen. Idealerweise sollte der Schützling dabei Einsichten in die Faktoren bekommen, die in diese technischen Entscheidungen einfließen. Neugestalten einer UI-Komponente, Modifizierung der Deployment-Architektur oder das Aufbauen einer neuen Caching-Strategie sind gute Kandidaten für diese Erfahrung.
  3. Es gibt einen sichtbaren, am besten messbaren Wert. Das könnte ein neues Frontend-Feature sein oder ein Graph, der eine Verringerung der Seitenladezeit zeigt, aber idealerweise sollte der Schützling auf eine sichtbare Verbesserung zeigen können und sagen: „Dafür bin ich verantwortlich“.

Meistens sind solche Aufnahmen eher zufällig, eine natürliche Folge von steigender Erfahrung und Verantwortung. Aber wenn Du bewusst eine Aufnahme für deinen Schützling anstößt, brauchst Du ihm/ihr das nicht sagen. Du solltest es ganz sicher nicht tun. Zeige dem Schützling, dass Du an ihn glaubst, indem Du ihn wie jeden anderen Entwickler behandelst.

Wenn die Aufnahme erfolgreich war, wird Dein Schützling ein gleichwertiges Mitglied – wenn auch eines, das noch viel zu lernen hat. Er/Sie werden ihren eigenen Fortschritt ohne großes Händchenhalten machen und Pair-Sessions werden sich deutlich kollaborativer anfühlen als instruktiv. Nach diesem Übergang kannst Du einen großen Schritt zurück machen, aber leiten und herausfordern, wenn nötig. Schließlich ist, wie Robert Anton Wilson gesagt hat, die Aufnahme ein nie endendes Ritual.

Patenschaften befördern das ganze Team

Als ich in mein Team kam, war ich der einzige Junior Developer. Mittlerweile hat sich das verschoben und fast die bei uns sind Junior Developers.

Ich habe aus erster Hand gesehen, wie dieser Wandel unsere Dynamik verbessert hat. Erfahrene Entwickler stellen Fragen an die Junioren, motivieren sie, ihr Wissen zu verfeinern – und die Junioren fragen zurück. Anstelle von ein paar guten Kommunikatoren, an denen das Training hängenbleibt, sind alle damit Beschäftigt ihre Fähigkeiten dauerhaft aktiv auszutauschen. Wo es früher ein paar einsame Individuen gab, gibt es jetzt einen gemeinsamen Geist von Zusammenarbeit und Spaß. Bereitschaft zu lernen und anzupassen wurde ein Kernwert unsers gesamten Teams.

Es hat auch unsere Codequalität sichtbar verbessert. Frische Augen sind großartig dabei, Anti-Patterns, Style-Probleme und verwirrenden Code zu identifizieren. Mit einem gesunden Mix von Anfängern sind wir besser geworden, unsere technische Schuld zu begleichen und neue Features zu entwickeln und der neue Code ist einfach zusammenzuführen und zu warten. Ohne diese Mentor-Beziehungen wären diese Verbesserungen niemals eingetreten.

Software-Entwickler können sich glücklich schätzen, in einer Industrie zu arbeiten, in der Werkzeuge und Prozesse für die Zusammenarbeit gut definiert und beliebt sind. Aber um das Agile Manifest zu paraphrasieren, es sind die Menschen und Interaktionen, die über Wohl und Wehe eines Produkts entscheiden. Mentoren sind eine mächtige Interaktion die, wenn sie richtig ausgeführt wird, die Teamqualität im Code aber auch im Miteinander auf eine neue Stufe hebt und das Fundament für eine erfolgreichere Organisation bildet.

 


Dieser Artikel ist eine Übersetzung von Alice Mottolas Artikel “Initiation to Code”, erschienen bei A List Apart. Die Übersetzung wurde nach bestem Wissen und Gewissen angefertigt und versucht, möglichst nah am Original zu bleiben.

Translated with the permission of A List Apart and the author[s].

Veröffentlicht von

Ich bin Entwickler und Consultant bei Intera und erstelle nebenberuflich kleine Websites für kleine Unternehmen und Privatpersonen. Ich bin Open Source Fan und Blogger.

Portfolio . Blog . twitter . github

Kommentare sind geschlossen.