Les avantages et les inconvénients de la programmation par paires sur le lieu de travail

La programmation en binôme consiste en deux programmeurs travaillant ensemble sur un même poste de travail.

Formellement, un programmeur est le pilote et écrit le code. L'autre est l'observateur ou le navigateur qui examine chaque ligne de code au fur et à mesure qu'elle est saisie.

De manière informelle, ils s'assoient ensemble sur une base de code et parlent de choses et décomposent les problèmes. L'un ou l'autre peut écrire du code et aucun d'eux ne fait autre chose comme vérifier le téléphone.

La programmation en binôme est largement adoptée par certaines organisations et rejetée par d'autres. C'est toujours un sujet de débat et les gens auront leurs préférences. Nous sommes tous des humains et il y a des moments où presque tout le monde peut bénéficier de la programmation en binôme.

Pourtant, cela semble être une utilisation inefficace des ressources. Nous avons deux programmeurs. Ils pourraient tous les deux créer des fonctionnalités différentes pendant une semaine, à la fin, nous aurons deux fois plus de fonctionnalités. Mais ce n'est pas le cas et vous pourriez bien vous retrouver avec 2 ensembles de fonctionnalités à 95% qui ne peuvent pas être expédiées. La programmation conjointe peut augmenter la quantité nette de fonctionnalités réellement complètes que vous livrez.

Les avantages

Moins d'erreurs et de retenues de bogues

Nous avons tous eu des bugs difficiles et fous. Ceux-ci peuvent provenir de défauts fondamentaux dans l'ensemble de l'approche ou d'une faute de frappe, d'une installation incorrecte ou de la nécessité d'un redémarrage.

En tant qu'équipe, il y a de fortes chances que l'un de vous ait déjà commis une erreur similaire. Ou il est probable que l'un de vous connaisse quelqu'un d'autre qui a rencontré le problème. Et vous êtes plus susceptible d'allouer le bon moment à un problème avant de retourner à la planche à dessin.

Vous pouvez discuter de meilleures stratégies. C'est mieux que de garder le problème caché toute la journée sans le partager avec les autres.

Plus facile à continuer - Soutien moral

Travailler souvent en équipe peut augmenter la positivité d'un problème. Quand quelqu'un partage un problème que vous traversez, vous vous sentez moins vaincu et plus positif à l'idée d'essayer encore et encore et encore ...

Plus difficile à procrastiner

Travailler en équipe signifie que vous ne pouvez pas vous arrêter et vérifier votre e-mail, Slack ou Whatsapp pour toute distraction souhaitée.

Cela semble être une petite chose. Mais vous pouvez quadrupler le nombre d'heures qu'un codeur passe dans l'éditeur et le codage, au lieu de rester assis à un bureau à manger des heures de la journée jusqu'à l'heure de rentrer chez lui.

Meilleures pratiques partagées

Coder ensemble est un excellent moyen de partager des connaissances dans votre entreprise. Les codeurs peuvent se donner des conseils au fur et à mesure pour améliorer leur approche et augmenter leur vitesse.

Travailler ensemble peut révéler des connaissances qui ne figurent peut-être pas dans votre manuel du nouvel employé.

Embarquement plus rapide

Les nouveaux employés peuvent se mettre à jour beaucoup plus rapidement en s'associant à un membre expérimenté de l'équipe.

Identifier et réduire les mauvaises embauches

Cela peut aider à identifier les mauvaises recrues dès le début si quelqu'un n'est pas la bonne personne pour une entreprise ou a été embauché pour le mauvais rôle. Vous pouvez faire quelque chose dès le début avant de perdre le temps des deux parties.

Lors d'un entretien d'embauche, une équipe familiarisée avec la programmation en binôme sera mieux à même d'évaluer si le candidat peut programmer avec d'autres. Si le gars normal qui dirige les séances d'entretien est absent, vous pouvez être sûr que quelqu'un d'autre peut le remplacer et donner une analyse juste.

Augmenter la satisfaction des employés

Coder ensemble peut rapprocher les employés lorsqu'ils partagent leurs expériences et ont plus de sujets à aborder. Lorsque les autres comprendront ce que vous faites, vous aurez plus en commun. Cela peut affecter de nombreux domaines d'activité importants. Il peut même améliorer les sujets de conversation au déjeuner pour réduire le taux de désabonnement des employés.

Le codage peut être une poursuite solitaire lorsque vous êtes seul derrière un ordinateur et que vous devez produire des fonctionnalités. Réduire toute aliénation dans une entreprise est important. C'est l'une des raisons pour lesquelles je suggérerais d'avoir un système de programmation en binôme pour les start-ups en démarrage ainsi que pour les grandes entreprises.

Problèmes - Lorsque le couplage tourne mal

La programmation en binôme peut gâcher les choses et nécessite une approche sensée.

N'en faites pas trop (ou ne le faites pas)

Forcer les gens à passer toute la journée ensemble n'est pas sensé et ils pourraient bien finir par se détester.

Les rafales de 1,5 à 2,5 heures fonctionnent généralement mieux. Moins est trop court et c'est une perte de temps.

Récompense contribution partagée

Si vous avez donné des délais importants à deux programmeurs et que vous en attribuez un pour aider l'autre dans sa tâche, vous vous dirigez vers un désastre potentiel. Lorsque vous examinez qui a terminé ses tâches et que l'on a l'impression de ne rien faire, les mesures personnelles en souffrent. Mentalement, c'est mauvais. Mais s'il est lié à un système de récompense, vous vous tirez une balle dans le pied. En tant que Scrum Master, vous devez vous assurer de tenir compte du jumelage et d'attribuer les tâches de manière équitable.

Codeurs fatigués

Plus de café et de jumelage n'est pas toujours la réponse. Lorsque vous êtes fatigué et stressé, vous ne communiquez peut-être pas correctement.

Cela peut entraîner plus de problèmes dans le code et entre eux. Certaines personnes ont de meilleures performances de cette façon et d'autres pas, donc vous pouvez prendre un risque.

Code complexe - Jumeler ou discuter

Pour un code plus complexe, cela peut être une distraction d'essayer de s'associer. Parfois, s'asseoir et expliquer le problème peut être plus bénéfique.

S'asseoir formellement ensemble et écrire du code ligne par ligne pourrait en fait être distrayant.

d'autres pensées

Mais qu'en est-il des travailleurs à distance?

Les employés travaillant à distance peuvent associer le programme à des outils de partage d'écran en ligne. J'ai débogué du code d'amis à Bruxelles alors que j'étais assis dans un café au Kazakhstan. Croyez-moi, c'est possible.

N'importe quelle preuve?

Ce sont des reflets de mes expériences. J'ai perçu ces avantages en travaillant avec diverses entreprises et différents bootcamps.

En tant que scientifique, j'accepte que je n'ai jamais fait d'essai en double aveugle sur les avantages. Bien sûr, cela n'a jamais été une priorité assez grande par rapport à simplement faire avancer les choses.

Mais j'adorerais une étude avec plus de 100 participants travaillant sur le même ensemble de problèmes. Un groupe de 50 pourrait travailler par deux et l'autre groupe pourrait travailler en solo. J'aimerais voir ce qui se passe. Ce pourrait être une belle étude pour tous les professeurs d'informatique.

Conclusion

Comme vous pouvez le voir, je suis fan de la programmation en binôme. Certains codeurs ne pensent pas que ce soit une utilisation efficace de leur temps. Si vous êtes manager, c'est à vous d'évaluer la situation et de tirer le meilleur parti de votre équipe. Quoi qu'il en soit, c'est certainement quelque chose que toutes les entreprises devraient parfois autoriser.

Il devrait être mis en œuvre de manière dynamique plutôt que appliqué. Tout boot-camp devrait l'intégrer à son cours pour créer un codeur complet.

Nous l'utilisons souvent dans ma propre agence de développement, de la résolution de nos problèmes les plus difficiles à l'intégration de nouveaux employés. C'est un processus que nous aimons utiliser pour améliorer les performances et les connaissances dans toute l'entreprise. Bien sûr, nous ne l'appliquons pas toute la journée et tous les jours! Mais nous l'aimons et nous le gardons.

Comme le dit le vieil adage: « Un problème partagé est un problème divisé par deux. "

Je dirige un podcast sur l'état d'esprit de croissance et la start-up technologique. Si cela vous a plu, vous en apprendrez plus en vous abonnant.

Si vous avez utilisé la programmation par paires, j'aimerais avoir votre avis à ce sujet. Quelles pratiques ou astuces utilisez-vous pour décider quand vous associer ou non?