Warum kollaboratives Programmieren der ultimative Karriere-Hack ist

Die ersten Schritte im Programmieren sind wie das Erlernen einer Fremdsprache. Anfangs macht die Syntax keinen Sinn, das Vokabular ist ungewohnt, und alles sieht und klingt unverständlich. Wenn Sie etwas wie ich sind, als ich anfing, fühlt es sich unmöglich an, fließend zu sprechen.

Ich verspreche, das ist es nicht. Als ich mit dem Programmieren anfing, traf mich die Lernkurve – hart. Ich verbrachte zehn Monate damit, mir die Grundlagen beizubringen, während ich versuchte, Selbstzweifel abzuwehren, die ich jetzt als Hochstapler-Syndrom erkenne. Erst als ich anfing, anfängerfreundliche Treffen zu besuchen, wurde mir klar, wie das gemeinsame Programmieren erstaunliche Möglichkeiten eröffnet. Sie brauchen nur die richtige Gemeinschaft von Menschen, mit denen Sie üben können.

Für mich war diese Community Founders and Coders, das kostenlose JavaScript-Bootcamp, das mir geholfen hat, meine Karriere vom Texten zum Programmieren zu ändern. Selbst jetzt, weniger als ein Jahr nach Abschluss des Kurses, kann ich kaum glauben, dass ich dafür bezahlt werde, Software zu entwickeln.

Beim kollaborativen Programmieren geht es darum, gemeinsam Probleme anzugehen und Lösungen zu finden. Es umfasst Techniken wie Pair Programming, die mehrere Technologieunternehmen ernst genug nehmen, um sie während ihrer Interviewprozesse zu überprüfen. Es kultiviert auch nützliche Fähigkeiten, die schwer zu erlernen sind, wenn Sie nur alleine zu Hause programmieren.

Egal, ob Sie gerade erst in der Technologiebranche anfangen oder bereits mehrere Jahre Erfahrung gesammelt haben, kollaboratives Programmieren hört nie auf, nützlich zu sein. In diesem Artikel sehen wir uns an, wie diese immergrünen Fähigkeiten Sie für eine lange und erfolgreiche Karriere in der Softwareentwicklung ausrüsten.

Perfekte Paarung

Meine erste Erfahrung mit Pair Programming machte ich bei einem Treffen für Anfänger namens Coding For Everyone. So funktioniert es: Leute tun sich zusammen, oft mit Leuten, die sie noch nie getroffen haben, um JavaScript-Herausforderungen gemeinsam am selben Laptop zu lösen. Eine Person übernimmt die Rolle des „Navigators“ und schlägt den Code vor, der ihrer Meinung nach geschrieben werden sollte. Der andere, der „Fahrer“, tippt seine Vorschläge auf den Laptop und stellt Fragen, wenn etwas unklar ist. Sie fahren damit fort und tauschen häufig die Rollen bis zum Ende der zweistündigen Sitzung.

Theoretisch war es einfach. In der Praxis nicht so sehr.

Ich fand es ziemlich ablenkend, dass jemand, den ich nicht kannte, meinen Bildschirm beobachtete, während ich tippte, und ich zögerte, die Kontrolle abzugeben, wenn es an der Zeit war, die Rollen zu tauschen. Ich fand die Navigation sogar noch schwieriger. Wenn eine Idee nicht von Ihrem Kopf in den Computer gelangen kann, ohne zuerst durch die Hände Ihres Partners zu gehen, zählt jedes Wort, das Sie sagen. Es erforderte von uns beiden ein gewisses Maß an Kommunikation, an das wir einfach nicht gewöhnt waren, und ich war mir sicher, dass wir beide mehr lernen würden, wenn wir uns aufteilen und getrennt arbeiten würden.

Glücklicherweise sind wir dabei geblieben; In der folgenden Woche ging ich wieder zum Treffen. Seitdem habe ich Hunderte von Stunden damit verbracht, mit Dutzenden von Entwicklern zusammenzuarbeiten, und ich habe mehr gelernt, als ich ursprünglich für möglich gehalten hätte.

Pair Programming ist eine unglaublich schnelle Art zu lernen. Die Magie der Methode – sobald Sie die anfängliche Unbeholfenheit überwunden haben – besteht darin, dass sie sofortige Ergebnisse liefert. Einige Rückkopplungsschleifen, wie Blasen an der Börse, können Stunden, Tage oder sogar Monate dauern, bis sie eine Korrektur bewirken. Die Paarprogrammierung dauert Minuten, wenn nicht Sekunden. Wenn Sie ein Semikolon falsch platzieren, können zwei Augenpaare den Fehler schneller erkennen als eines. Müssen Sie StackOverflow nach Hinweisen auf eine bösartige Fehlermeldung durchsuchen? Sie und Ihr Partner können jeweils unterschiedliche Threads lesen, wodurch die Zeit, die zum Finden einer Antwort benötigt wird, halbiert wird.

Für noch kniffligere Probleme kann die Mob-Programmierung ein weiterer Schritt nach oben sein. Bei dieser Methode muss sich ein funktionsübergreifender Teil eines Teams um denselben Computerbildschirm versammeln und in Echtzeit über Lösungen nachdenken, während eine Person tippt.

„All die brillanten Köpfe, die zur selben Zeit am selben Ort am selben Computer an derselben Sache arbeiten.“

— Woody Zuill, Agile Coach und Mob Programming Trainer

Während es wie eine ineffiziente Arbeitsweise erscheinen mag, sagen Befürworter der Mob-Programmierung wie Woody Zuill, dass es tatsächlich Zeit sparen kann, indem es die Notwendigkeit individueller Codeüberprüfungen eliminiert, da jeder den Code in Echtzeit überprüft, während er geschrieben wird. Abgesehen von der Produktivität denke ich, dass Mobbing eine fantastische Möglichkeit ist, nicht nur etwas über den Code zu lernen, sondern auch darüber, wie andere Leute Probleme angehen. Wenn Pair Programming die Anzahl der Perspektiven verdoppelt, denen Sie ausgesetzt sind, liefert Mob Programming noch mehr Einblicke.

Das soll nicht heißen, dass Pairing – oder Mobbing – einfach ist. Etwas, womit ich anfangs zu kämpfen hatte, war, mein Ego beiseite zu legen, um Fragen zu stellen, von denen ich dachte, dass sie dumm klingen könnten. In solchen Situationen ist es gut, sich daran zu erinnern, dass Ihr Partner möglicherweise die gleichen Gedanken hat, besonders wenn Sie beide gerade erst anfangen.

Wenn Sie sich mit jemandem treffen, der älter ist, vielleicht bei der Arbeit, scheuen Sie sich nicht, ihm den Kopf zu zerbrechen und ihn mit Ihrer Wissbegierde zu beeindrucken. Selbst jemandem, der nur ein bisschen weiter ist als Sie, fallen vielleicht Dinge ein, die einem Älteren nicht einfallen würden. Einige meiner Lieblingspaarprogrammierer haben nur ein paar Monate mehr Erfahrung als ich, scheinen aber immer genau zu wissen, welche Fehler ich mache und wie sie mich in die richtige Richtung lenken können. Wenn diese Entwickler sagen, dass es keine dummen Fragen gibt, meinen sie das wirklich ernst. Die besten Paarprogrammierer sprechen frei, ohne fantastisch erscheinen zu müssen oder Angst zu haben, dumm auszusehen.

Pair Programming erfordert Übung, aber es lohnt sich, es zu perfektionieren. Studien zeigen, dass Programmierer, die Probleme gemeinsam lösen, tendenziell selbstbewusster, produktiver und engagierter sind. Egal, ob Sie nach Ihrem nächsten Job suchen oder neue Mitarbeiter einstellen, Pairing ist fürsorglich.

Ressourcen und weiterführende Literatur

• „Programmierrollen paaren“, Jordan Poulton, GitHub
• „Die Freundschaft, die Google groß gemacht hat“, James Somers, The New Yorker
• „Mob-Programmierung: Ein ganzheitlicher Teamansatz“, Woody Zuill, YouTube

Ingenieurs-Empathie

Als ich anfing, mir selbst JavaScript beizubringen, sah mein Code sehr nach meinem Schlafzimmerboden aus: Ich ließ es immer unordentlicher werden, bis ich keine andere Wahl hatte, als ihn aufzuräumen. Solange mein Webbrowser es verstehen konnte, war es mir egal, wie es aussah.

Erst als ich anfing, den Code anderer Leute zu überprüfen, wurde mir klar, dass ich viel mehr Empathie für die Leute zeigen musste, die meinen überprüften.

Empathie ist vielleicht das am meisten unterschätzte Werkzeug im Arsenal eines jeden Entwicklers. Das ist der Grund, warum IDEO die Nutzerforschung in den Mittelpunkt ihres Designprozesses stellt und warum Etsy seine Designer und Produktmanager auffordert, eine technische Rotation durchzuführen. Empathie entsteht, wenn wir die Möglichkeit haben zu sehen, wie unsere Arbeit andere Menschen beeinflusst. Kein Wunder, dass kollaboratives Programmieren so eine großartige Möglichkeit ist, es zu erstellen.

Peer Code Review – der Vorgang, den Code des anderen auf Fehler zu überprüfen – fordert uns auf, Empathie zu üben. Als Rezensent ist es wichtig zu erkennen, dass jemand erhebliche Anstrengungen unternommen hat, um den Code zu schreiben, den Sie gerade kritisieren werden. Versuchen Sie daher, Formulierungen zu vermeiden, die ein Urteil implizieren oder ihre Arbeit trivialisieren könnten. Wenn Sie sich auf ihren Code beziehen, möchten Sie ihnen die spezifischen Funktionen und Zeilen zeigen, zu denen Sie Fragen haben, und vorschlagen, wie sie ihn umgestalten könnten. Das Teilen von Lernressourcen kann auch hilfreicher sein, als eine Lösung mit dem Löffel zu füttern. Einige der nützlichsten Rückmeldungen, die ich von Code-Reviews erhalten habe, kamen in Form von Lehrartikeln, Videos und sogar Podcast-Empfehlungen.

Das Schreiben einer guten Dokumentation für Ihren Code ist ebenfalls ein langer Weg. Eine so einfache Handlung wie das Erstellen einer Readme mit klaren Installationsanweisungen zeigt Empathie für alle, die mit Ihrem Code arbeiten müssen. GitHub-Gründer Tom Preston-Werner befürwortet einen Readme-First-Ansatz für die Entwicklung.

„Eine perfekte Umsetzung der falschen Spezifikation ist wertlos. Nach dem gleichen Prinzip ist auch eine wunderschön gestaltete Bibliothek ohne Dokumentation so gut wie wertlos. Wenn Ihre Software das falsche Problem löst oder niemand herausfinden kann, wie man sie benutzt, ist etwas sehr Schlimmes im Gange.“

— Tom Preston-Werner, GitHub-Gründer

Ich habe auch mit Tech-Gründern gesprochen, die die Dokumentation als wesentlichen Bestandteil eines erfolgreichen Onboardings betrachten. Ein CTO sagte, wenn ein Junior-Entwickler innerhalb von sechs Monaten nach seinem Eintritt in sein Team Schwierigkeiten hat, ein Produktivitätsniveau zu erreichen, deutet dies darauf hin, dass die Codebasis nicht gut genug dokumentiert ist. Es dauert nur wenige Sekunden, einer komplexen Funktion, die Sie geschrieben haben, einen erklärenden Kommentar hinzuzufügen, aber es kann der nächsten Person, die Ihrem Team beitritt, Stunden an Mühe ersparen.

Ressourcen und weiterführende Literatur

• „Über Empathie und Pull-Requests“, Slack Engineering, Medium
• „Readme Driven Development“, Tom Preston-Werner, GitHub
• „Was Google bei seiner Suche nach dem perfekten Team gelernt hat“, Charles Duhigg, The New York Times Magazine

Agile Leistung

Von den Millionen von Arbeitsstunden, die in die Erstellung von CGI-Filmen fließen, bis hin zu den intensiven Entwicklungsschwierigkeiten, die zur Veröffentlichung von Videospielen mit großem Budget führen, erfordern gewaltige technische Errungenschaften eine unglaubliche Menge an Aufwand. Als ich die Codebasis meines derzeitigen Arbeitgebers zum ersten Mal sah, war ich überwältigt von der Ungeheuerlichkeit des Ganzen. Wie um alles in der Welt hat das jemand gebaut ?

Die Antwort ist, dass jeder mit dem richtigen Rahmen für die Zusammenarbeit viel mehr bauen kann als jeder andere. In Unternehmen, die kollaboratives Programmieren fördern, entsteht die Software nicht aus den Bemühungen eines einsamen Genies. Stattdessen gibt es Möglichkeiten der Zusammenarbeit, die großartigen Teams helfen, großartige Arbeit zu leisten. Entwickler bei Founders and Coders praktizieren eine beliebte Softwareentwicklungsmethodik, die als „Agile“ bekannt ist, und meiner Erfahrung nach bringt sie das „Funktionale“ in funktionsübergreifende Entwicklungsteams.

Ganze Bücher wurden über Agile geschrieben, aber hier ist eine Zusammenfassung der Kernkonzepte:

• Ein Produktentwicklungsteam zerlegt große Arbeitspakete in kleine Einheiten, die als „User Stories“ bezeichnet werden, priorisiert sie und liefert sie in zweiwöchigen Zyklen, die als „Sprints“ bezeichnet werden.
• Solange das Projekt andauert, wiederholen sich die Zyklen, und neue Produktanforderungen werden in einen Aufgabenstau für zukünftige Sprints eingespeist.
• Das Team hält tägliche Standup-Meetings ab, um ihre Fortschritte zu besprechen und Blockaden zu beseitigen.
• Der Prozess ist sowohl inkrementell als auch iterativ: Die Software wird in Teilen erstellt und geliefert und in aufeinanderfolgenden Sprints verfeinert.

Als chronischer Tüftler, dessen Solo-Hobbyprojekte oft dem „Feature Creep“ erliegen, weiß ich, wie einfach es ist, Zeit damit zu verschwenden, Dinge zu bauen, die niemand jemals benutzt. Ich finde es toll, wie Agile Sie dazu zwingt, User Stories zu priorisieren, damit sich das gesamte Team auf die Bereitstellung von Funktionen konzentrieren kann, die Ihren Benutzern wirklich wichtig sind. Es ist motivierend zu wissen, dass Sie alle das gemeinsame Ziel verfolgen, ein Produkt oder eine Dienstleistung zu entwickeln, die auch nach der Arbeit daran Bestand haben wird.

Das Aufteilen von Aufgaben in kleine User Stories ist auch eine großartige Möglichkeit, Programmiersitzungen zeitlich zu koppeln. Ganz gleich, wie tief Sie sich in der Zone befinden, das Beenden der Arbeit an einem wichtigen Feature ist immer eine schöne Erinnerung daran, sich von Ihren Schreibtischen zu entfernen und eine Pause einzulegen. Agile verleiht kollaborativem Programmieren dort Struktur, wo sie sonst fehlen könnte.

In der Zwischenzeit geben Ihnen tägliche Standups die Freiheit, über alles zu sprechen, was Sie zurückhält, und Sprint-Rückblicke bieten Raum, um wichtige Erfolge zu teilen und festzustellen, wo sich das Team verbessern kann. Diese Zeremonien fördern ein Gefühl der Zusammenarbeit und Verantwortlichkeit und helfen uns, gemeinsam mehr zu lernen, als wir es alleine könnten.

All diese agilen Prinzipien in die Praxis umzusetzen, kann eine Herausforderung sein, insbesondere wenn niemand in einem Team an diese Arbeitsweise gewöhnt ist. Bei Founders and Coders brauchen die meisten Studenten eine Weile, um sich daran zu gewöhnen, täglich Standups zu machen. Nach 18 Wochen projektbasierter Praxis stellen Sie jedoch fest, dass sich Ihre Prozesse und Kommunikationsfähigkeiten enorm verbessern. Wenn Sie Ihre erste Kundenarbeit übernehmen, haben Sie ein viel klareres mentales Modell dafür entwickelt, wie Sie an die Entwicklung einer Full-Stack-Webanwendung in einem Team herangehen.

Der beste Weg, Agilität zu lernen, besteht darin, interessante Projekte mit anderen Leuten aufzubauen. Die Teilnahme an Hackathons ist eine hervorragende Möglichkeit, mit potenziellen Mitarbeitern in Kontakt zu treten. Viele Open-Source-Projekte machen ihre Kanban-Projektboards öffentlich, sodass Sie sehen können, an welchen GitHub-Problemen verschiedene Mitwirkende arbeiten. Mehrere willkommene Beiträge von Anfängern, und Sie können sich häufig selbst offenen Problemen zuweisen und mit dem Erheben von Pull-Anforderungen beginnen.

Da die meisten Technologieunternehmen irgendeine Form von Agile abonnieren, ist es nicht ungewöhnlich, dass Arbeitgeber in Vorstellungsgesprächen danach fragen. Jede Erfahrung, die Sie haben, kann Sie von anderen Bewerbern abheben, die vielleicht noch nie gemeinsam programmiert haben, geschweige denn mit Blick auf Agile.

Ressourcen und weiterführende Literatur

• „Was ist Agilität?“, Steve Denning, Forbes
• „Embracing Agile“, Darrell K. Rigby, Jeff Sutherland, Hirotaka Takeuchi, Harvard Business Review
• „Fantastische First-Pull-Request-Möglichkeiten“, Shmavon Gazanchyan, Deloitte Digital

Empfehlungen für Remote Collaborative Coding Tools

In den letzten Jahren haben sich Remote-Working-Tools so weit entwickelt, dass prominente Unternehmen wie Gatsby und Zapier jetzt „Remote First“ sind. Es bleibt abzuwarten, ob sich dies zu einem Trend entwickeln wird, aber man kann mit Sicherheit sagen, dass Remote-Entwicklungsteams hier bleiben werden.

In diesem Sinne sind hier einige Tools, die Ihnen und Ihrem Team helfen können, aus der Ferne gemeinsam zu programmieren:

Wenn Sie eines von der Lektüre dieses Artikels mitnehmen, möchte ich, dass Teamplayer einzelne Mitwirkende übertrumpfen. In einem Bereich, in dem es anscheinend jede zweite Woche ein heißes neues Framework zu meistern gibt, altern unsere technischen Fähigkeiten auf eine Weise, die unsere Soft Skills nicht tun. Das Ergebnis ist, dass Entwickler, die gut mit anderen Menschen zusammenarbeiten können, immer feststellen werden, dass ihre Fähigkeiten gefragt sind. Kollaboratives Programmieren ist nicht nur eine effektive Art zu lernen; Es ist eine begehrte Fähigkeit, die jeder mit genügend Übung und Geduld entwickeln kann.