Pourquoi le codage collaboratif est le hack de carrière ultime

Faire ses premiers pas en programmation, c'est comme apprendre une langue étrangère. Au début, la syntaxe n'a aucun sens, le vocabulaire n'est pas familier et tout semble et semble inintelligible. Si vous êtes un peu comme moi quand j'ai commencé, la fluidité semble impossible.

Je promets que non. Quand j'ai commencé à coder, la courbe d'apprentissage m'a frappé - durement. J'ai passé dix mois à m'enseigner les bases tout en essayant d'éviter des sentiments de doute que je reconnais maintenant comme le syndrome de l'imposteur. Ce n'est que lorsque j'ai commencé à participer à des rencontres conviviales pour les débutants que j'ai réalisé à quel point le codage collaboratif ouvre des possibilités incroyables. Vous avez juste besoin de la bonne communauté de personnes avec qui pratiquer.

Pour moi, cette communauté était Founders and Coders, le bootcamp JavaScript gratuit qui m'a aidé à faire passer ma carrière de la rédaction au codage. Même maintenant, moins d'un an après avoir terminé le cours, j'ai du mal à croire que je suis payé pour développer des logiciels.

Le codage collaboratif consiste à résoudre des problèmes et à découvrir des solutions ensemble. Il englobe des techniques telles que la programmation en binôme, que plusieurs entreprises technologiques prennent suffisamment au sérieux pour dépister lors de leurs processus d'entretien. Il cultive également des compétences utiles difficiles à acquérir si vous ne faites que coder seul à la maison.

Que vous débutiez dans l'industrie technologique ou que vous ayez plusieurs années d'expérience à votre actif, le codage collaboratif ne cesse d'être utile. Dans cet article, nous verrons comment ces compétences permanentes vous équiperont pour une longue et fructueuse carrière dans le développement de logiciels.

Appariement parfait

Ma première expérience de programmation en binôme a eu lieu lors d'une rencontre pour débutants appelée Coding For Everyone. Voici comment cela fonctionne : les gens s'associent, souvent avec des personnes qu'ils n'ont jamais rencontrées, pour résoudre ensemble des défis JavaScript sur le même ordinateur portable. Une personne assume le rôle du « navigateur » et propose le code qu'elle pense devoir être écrit. L'autre personne, le « chauffeur », tape ses suggestions sur l'ordinateur portable et pose des questions chaque fois que quelque chose n'est pas clair. Vous continuez à faire cela, en échangeant fréquemment les rôles, jusqu'à la fin de la session de deux heures.

En théorie, c'était simple. En pratique, pas tellement.

J'ai trouvé assez distrayant d'avoir quelqu'un que je ne connaissais pas qui regardait mon écran pendant que je tapais, et j'étais réticent à céder le contrôle quand il était temps d'échanger les rôles. J'ai trouvé la navigation encore plus délicate. Lorsqu'une idée ne peut pas passer de votre tête à l'ordinateur sans passer d'abord par les mains de votre partenaire, chaque mot que vous prononcez compte. Cela exigeait de nous deux un degré de communication auquel nous n'étions tout simplement pas habitués, et j'étais sûr que nous en apprendrions tous les deux plus si nous nous séparions pour travailler séparément.

Heureusement, nous nous en sommes tenus là; Je suis retourné à la rencontre la semaine suivante. Depuis, j'ai passé des centaines d'heures à jumeler avec des dizaines de développeurs, et j'ai appris plus que je ne le pensais initialement possible.

La programmation en binôme est un moyen incroyablement rapide d'apprendre. La magie de la méthode - une fois que vous avez surmonté la maladresse initiale - est qu'elle donne des résultats immédiats. Certaines boucles de rétroaction, comme les bulles sur le marché boursier, peuvent prendre des heures, des jours, voire des mois pour produire une correction. La programmation en binôme prend quelques minutes, voire quelques secondes. Lorsque vous égarez un point-virgule, deux paires d'yeux peuvent repérer l'erreur plus rapidement qu'une. Besoin de rechercher sur StackOverflow des indices sur un message d'erreur malveillant ? Vous et votre partenaire pouvez chacun lire différents fils de discussion, ce qui réduit de moitié le temps nécessaire pour trouver une réponse.

Pour des problèmes encore plus délicats, la programmation mob peut être une étape supplémentaire. Cette méthode nécessite qu'une section interfonctionnelle d'une équipe se rassemble autour du même écran d'ordinateur et réfléchisse à des solutions en temps réel pendant qu'une personne tape.

"Tous les esprits brillants travaillent sur la même chose, en même temps, dans le même espace, sur le même ordinateur."

— Woody Zuill, coach agile et formateur en programmation mob

Bien que cela puisse sembler être une façon inefficace de travailler, les partisans de la programmation populaire tels que Woody Zuill affirment qu'elle peut en fait gagner du temps en éliminant le besoin de révisions de code individuelles, car tout le monde examine le code en temps réel au fur et à mesure de son écriture. La productivité mise à part, je pense que le mobbing est un moyen fantastique d'apprendre non seulement sur le code, mais aussi sur la façon dont les autres abordent les problèmes. Si la programmation en binôme double le nombre de perspectives auxquelles vous êtes exposé, la programmation en foule donne encore plus d'informations.

Cela ne veut pas dire que l'appariement – ​​ou même le mobbing – est une navigation simple. Quelque chose avec lequel j'ai eu du mal au début était de mettre mon ego de côté pour poser des questions que je pensais pouvoir sembler stupides. Dans ces situations, il est bon de se rappeler que votre partenaire pourrait avoir les mêmes pensées, surtout si vous débutez tous les deux.

Si vous vous retrouvez en couple avec quelqu'un de plus expérimenté, peut-être au travail, n'ayez pas peur de piocher son cerveau et de l'impressionner par votre curiosité. Même quelqu'un qui n'est qu'un peu plus avancé que vous pourrait penser à des choses qui ne viendraient pas à l'esprit d'une personne plus âgée. Certains de mes programmeurs en binôme préférés n'ont que quelques mois d'expérience de plus que moi, mais ils semblent toujours savoir exactement quelles erreurs je suis sur le point de commettre et comment m'orienter dans la bonne direction. Lorsque ces développeurs disent qu'il n'y a pas de question idiote, ils le pensent vraiment. Les meilleurs programmeurs en binôme parlent librement, sans avoir besoin d'avoir l'air fantastique ou la peur d'avoir l'air stupide.

La programmation en binôme demande de la pratique, mais elle vaut la peine d'être perfectionnée. Des études montrent que les programmeurs qui s'associent pour résoudre des problèmes ont tendance à être plus confiants, productifs et engagés dans leur travail. Que vous recherchiez votre prochain emploi ou que vous embauchiez de nouvelles recrues, le jumelage est attentionné.

Ressources et lectures complémentaires

• "Paire de rôles de programmation", Jordan Poulton, GitHub
• "L'amitié qui a rendu Google énorme", James Somers, The New Yorker
• "Programmation Mob : une approche d'équipe complète", Woody Zuill, YouTube

Ingénierie Empathie

Quand j'ai commencé à apprendre JavaScript, mon code ressemblait beaucoup au sol de ma chambre : je le laissais devenir de plus en plus désordonné jusqu'à ce que je n'aie plus d'autre choix que de le ranger. Tant que mon navigateur Web pouvait le comprendre, je me fichais de son apparence.

Ce n'est que lorsque j'ai commencé à réviser le code des autres que j'ai réalisé que je devais montrer beaucoup plus d'empathie pour les personnes qui révisaient le mien.

L'empathie est peut-être l'outil le plus sous-estimé de l'arsenal de tout développeur. C'est la raison pour laquelle IDEO place la recherche utilisateur au centre de son processus de conception, et pourquoi Etsy demande à ses designers et chefs de produit d'effectuer une rotation d'ingénierie. L'empathie émerge lorsque nous avons l'opportunité de voir comment notre travail impacte les autres. Pas étonnant que le codage collaboratif soit un si bon moyen de le construire.

L'examen du code par les pairs - le fait de vérifier le code de l'autre pour les erreurs - nous invite à faire preuve d'empathie. En tant que réviseur, il est important de reconnaître que quelqu'un a déployé des efforts considérables pour écrire le code que vous êtes sur le point de critiquer. En tant que tel, essayez d'éviter d'utiliser des phrases qui pourraient impliquer un jugement ou banaliser leur travail. Lorsque vous vous référez à leur code, vous souhaitez leur montrer les fonctions et les lignes spécifiques sur lesquelles vous avez des questions et suggérer comment ils pourraient le refactoriser. Partager des ressources d'apprentissage peut également être plus utile que de proposer une solution à la cuillère. Certains des commentaires les plus utiles que j'ai reçus des révisions de code se présentent sous la forme d'articles éducatifs, de vidéos et même de recommandations de podcast.

Rédaction d'une bonne documentation pour votre code va également un long chemin. Un acte aussi simple que de créer un fichier Lisez-moi avec des instructions d'installation claires montre de l'empathie pour quiconque a besoin de travailler avec votre code. Le fondateur de GitHub, Tom Preston-Werner, préconise une approche de développement axée sur le readme first.

« Une mise en œuvre parfaite de la mauvaise spécification est sans valeur. Selon le même principe, une bibliothèque magnifiquement conçue sans documentation est également sacrément sans valeur. Si votre logiciel résout le mauvais problème ou si personne ne sait comment l'utiliser, il se passe quelque chose de très grave.

— Tom Preston-Werner, fondateur de GitHub

J'ai également parlé avec des fondateurs de technologies qui considèrent la documentation comme un élément essentiel d'une intégration réussie. Un CTO a déclaré que si un développeur junior a du mal à atteindre un niveau de productivité dans les six mois suivant son arrivée dans son équipe, cela indique que la base de code n'est pas suffisamment documentée. Cela ne prend que quelques secondes pour ajouter un commentaire explicatif à une fonction complexe que vous avez écrite, mais cela pourrait épargner des heures d'efforts à la prochaine personne qui rejoindra votre équipe.

Ressources et lectures complémentaires

• "Sur les demandes d'empathie et d'attraction", Slack Engineering, Medium
• "Développement piloté par Lisez-moi", Tom Preston-Werner, GitHub
• "Ce que Google a appris de sa quête pour créer l'équipe parfaite", Charles Duhigg, The New York Times Magazine

Réalisation agile

Des millions d'heures de travail nécessaires à la réalisation de films CGI aux intenses difficultés de développement menant aux sorties de jeux vidéo à gros budget, les réalisations techniques imposantes nécessitent des efforts époustouflants. La première fois que j'ai vu la base de code de mon employeur actuel, j'ai été terrassé par l'énormité de tout cela. Comment diable a-t-on construit ça ?

La réponse est que tout le monde peut construire beaucoup plus que n'importe qui , étant donné le bon cadre de collaboration. Dans les entreprises qui encouragent le codage collaboratif, le logiciel n'émerge pas des efforts d'un génie solitaire. Au lieu de cela, il existe des façons de travailler ensemble qui aident les grandes équipes à faire un travail incroyable. Les développeurs de Founders and Coders pratiquent une méthodologie de développement logiciel populaire connue sous le nom d'"Agile", et d'après mon expérience, elle place le "fonctionnel" dans des équipes de développement interfonctionnelles.

Des livres entiers ont été écrits sur Agile, mais voici un résumé des concepts de base :

• Une équipe de développement de produits décompose de gros travaux en petites unités appelées « user stories », les hiérarchise et les livre en cycles de deux semaines appelés « sprints ».
• Tant que le projet se poursuit, les cycles se répètent et les nouvelles exigences de produit sont introduites dans un arriéré de tâches pour les futurs sprints.
• L'équipe tient des réunions quotidiennes pour discuter de leurs progrès et traiter les éventuels bloqueurs.
• Le processus est à la fois incrémental et itératif : le logiciel est construit et livré en morceaux et affiné en sprints successifs.

En tant que bricoleur chronique dont les projets de passe-temps en solo succombent souvent au «fluage des fonctionnalités», je sais à quel point il est facile de perdre du temps à construire des choses que personne n'utilise jamais. J'aime la façon dont Agile vous oblige à hiérarchiser les user stories afin que toute l'équipe puisse se concentrer sur la fourniture de fonctionnalités qui intéressent réellement vos utilisateurs. C'est motivant de savoir que vous êtes tous unis autour de l'objectif commun de créer un produit ou un service qui continuera à avoir une vie une fois que vous aurez fini de travailler dessus.

Le fractionnement des tâches en petites histoires d'utilisateurs s'avère également être un excellent moyen de chronométrer les sessions de programmation par paires. Peu importe à quel point vous vous trouvez dans la zone, terminer le travail sur une fonctionnalité clé est toujours un bon rappel de vous éloigner de votre bureau et de faire une pause. Agile donne une structure au codage collaboratif là où il pourrait autrement faire défaut.

Pendant ce temps, les standups quotidiens vous donnent la liberté de parler de tout ce qui vous retient, et les rétrospectives de sprint offrent un espace pour partager les victoires clés et identifier où l'équipe pourrait s'améliorer. Ces cérémonies favorisent un sentiment de collaboration et de responsabilité, et nous aident à apprendre plus ensemble que nous ne pourrions le faire par nous-mêmes.

Mettre tous ces principes Agile en pratique peut être difficile, surtout lorsque personne dans une équipe n'est habitué à cette façon de travailler. Chez Founders and Coders, il faut un certain temps à la plupart des étudiants pour prendre l'habitude de faire des standups quotidiens. Cependant, après 18 semaines de pratique basée sur des projets, vous constatez que vos processus et vos compétences en communication s'améliorent énormément. Au moment où vous entreprenez votre premier travail client, vous avez formé un modèle mental beaucoup plus clair de la façon d'aborder la création d'une application Web complète en équipe.

La meilleure façon d'apprendre Agile est de construire des projets intéressants avec d'autres personnes. Participer à des hackathons est un excellent moyen de se connecter avec des collaborateurs potentiels. De nombreux projets open source rendent publics leurs tableaux de projets kanban, ce qui vous permet de voir sur quels problèmes GitHub travaillent les différents contributeurs. Plusieurs contributions bienvenues de débutants, et vous pouvez souvent vous affecter à des problèmes ouverts et commencer à soulever des demandes d'extraction.

Étant donné que la plupart des entreprises technologiques souscrivent à une forme d'Agile, il n'est pas rare que les employeurs posent des questions à ce sujet lors des entretiens. Toute expérience que vous avez peut vous distinguer des autres candidats qui n'ont peut-être jamais codé en collaboration, et encore moins avec Agile à l'esprit.

Ressources et lectures complémentaires

• "Qu'est-ce que l'agilité ?", Steve Denning, Forbes
• « Adopter Agile », Darrell K. Rigby, Jeff Sutherland, Hirotaka Takeuchi, Harvard Business Review
• "Opportunités impressionnantes de première demande d'extraction", Shmavon Gazanchyan, Deloitte Digital

Recommandations de l'outil de codage collaboratif à distance

Au cours des dernières années, les outils de travail à distance ont progressé au point que des entreprises de premier plan comme Gatsby et Zapier sont désormais « à distance d'abord ». Bien qu'il reste à voir si cela deviendra une tendance, il est prudent de dire que les équipes de développement à distance sont là pour rester.

Dans cet esprit, voici quelques outils qui peuvent vous aider, vous et votre équipe, à coder de manière collaborative à distance :

Si vous retirez une chose de la lecture de cet article, je veux que ce soit que les joueurs d'équipe l'emportent sur les contributeurs individuels. Dans un domaine où il semble y avoir un nouveau cadre à maîtriser toutes les deux semaines, nos compétences techniques vieillissent d'une manière que nos compétences non techniques ne vieillissent pas. Le résultat est que les développeurs qui peuvent bien travailler avec d'autres personnes trouveront toujours leurs capacités recherchées. Le codage collaboratif n'est pas seulement un moyen efficace d'apprendre ; c'est un ensemble de compétences recherchées que n'importe qui peut développer avec suffisamment de pratique et de patience.