Comment pouvez-vous atteindre et maintenir le flux lors de la programmation en binôme?

Flow est un concept introduit par Mihaly Csikszentmihalyi; en bref, cela signifie entrer dans la "zone". Vous vous sentez immergé dans votre tâche, concentré; la tâche peut être difficile mais difficile en même temps. Lorsque les gens atteignent un débit, leur productivité augmente. La programmation nécessite une grande concentration mentale, car nous devons souvent jongler avec plusieurs choses à la fois. Beaucoup aiment travailler dans un environnement calme où ils peuvent concentrer toute leur attention sur la tâche. S'ils sont interrompus, il peut s'écouler plusieurs minutes, voire plusieurs heures, pour retrouver le flux.

Je comprends qu'il existe une pratique en développement agile et en programmation extrême appelée programmation par paires. Cela signifie que vous mettez toute l'équipe de développement logiciel dans une seule pièce afin que la communication soit transparente. Vous écrivez du code avec votre paire, car vous obtenez ainsi des révisions instantanées du code et moins de bogues.

J'ai toujours eu des problèmes pour atteindre le flux lors de la programmation de paires en raison d'interruptions constantes. Je pense profondément à un problème, puis tout à coup, quelqu'un me pose une question d'une autre paire. Mon train de pensée est perdu.

Comment pouvez-vous atteindre et maintenir le flux lors de la programmation en binôme?

Edit: Disclaimer - Voici comment je définis "la zone": A state of extreme focus, in which one is able to understand how many intricate details connect together, regardless of whether these do so elegantly (or simply) or not.

J'essaie d'éviter cet état car, même si je peux produire du code correct dans la zone, moi et d'autres développeurs auront du mal à le comprendre plus tard. Pour faire court: la lecture de code qui a été écrit dans la zone peut souvent nécessiter que le lecteur soit dans la zone. Cette contrainte est mon problème.

Il y a un joli chapitre sur The Clean Coder où Oncle Bob explique de façon convaincante pourquoi "entrer dans la zone" est une mauvaise idée délirante.

Voici une alternative peut-être meilleure que «entrer dans la zone»: réfléchissez bien et considérez calmement et professionnellement ce que vous faites. Communiquer. Partagez vos pensées avec vos partenaires. Identifiez les vrais problèmes. Discutez des solutions possibles. Vous ne vous sentez peut-être pas surnaturellement concentré, mais vous êtes susceptible de prendre de bonnes décisions et des conceptions accessibles.

Si vous et votre partenaire pouvez discuter du problème sans que vous soyez tous deux extrêmement concentrés, il est probable que vous ayez résolu le problème à sa nature plus simple. Cela suggère que vous pourrez le comprendre à nouveau chaque fois que vous en aurez besoin.

D'un autre côté ... Si vous avez juste besoin d'un peu de temps seul pour vous redresser la tête (nous le faisons tous parfois), prenez-le. Obtenez vos pensées ensemble. Résolvez d'abord le problème dans votre tête.

Mais le fait est que si vous le faites - n'utilisez pas ce temps pour écrire du code de production. Au lieu de cela, jouez avec des exemples de code et des prototypes. Essayez de comprendre le problème, sans penser à des solutions pour l'instant. Une fois que tout est clair et écrit, discutez-en avec votre équipe et votre partenaire de paire, ou même le canard en caoutchouc sur votre bureau. Si vous ne parvenez toujours pas à l'articuler ou qu'ils ne le comprennent pas, affinez vos idées. Une fois que vous avez tout compris, intégrez toute cette pensée et cet exemple de code dans une vraie solution de travail.

La programmation en binôme nécessite parfois des périodes d'isolement de votre partenaire.

Exemple

Vous travaillez ensemble sur une classe particulière et vous vous rendez compte que vous devez écrire une méthode qui nécessite une réflexion approfondie sur une logique complexe, mais renvoie sinon un résultat banal. Vous travaillez ensemble sur la création de tests unitaires pour cette méthode, et reportez l'écriture de cette méthode à une période de temps pendant laquelle vous travaillez de manière isolée. Une fois la méthode terminée, vous vous remettez en équipe et évaluez les résultats.

J'ai découvert qu'il existe une petite classe de problèmes pour lesquels la programmation par paires fonctionne. Par exemple, si vous travaillez sur un produit multiplateforme et que le gars Winders a implémenté une fonctionnalité qui nécessite un code spécifique au système d'exploitation, il peut aider le gars Mac à implémenter la même fonctionnalité sur le code Mac pendant que le gars Mac conduit.

Cependant, selon mon expérience, la programmation par paire entraîne une perte de productivité nette. On a si souvent l'impression que nous payons deux développeurs pour faire le travail d'un seul.

Oui, cela réduit la possibilité horrible qu'un développeur puisse prendre une pause d'échange de pile pendant la journée de travail.

À mon humble avis, il serait moins cher pour les entreprises qui souhaitent contrôler leurs développeurs de jumeler chaque développeur avec un agent de sécurité privé pour se tenir derrière le développeur et frapper le développeur avec une matraque s'il ralentit ou essaie de culminer à un niveau non essentiel. page Web.

En tant que développeur tentant de pénétrer dans la zone, vous tenterez de vous isoler du mieux que vous pourrez pour vous sentir à l'aise et vider votre esprit. Pourquoi la programmation par paires devrait-elle être différente?

Vous et votre partenaire devriez trouver un environnement induisant une zone qui fonctionne pour vous deux. Cela nécessitera peut-être un compromis sur certaines choses, mais mon point principal est que l'environnement de la paire devrait être similaire au solo. Éteignez le monde extérieur. La paire programme ensemble; les autres paires (les autres collègues en général) ne devraient pas interrompre (à l'exception des problèmes critiques, abandonner ce que vous faites).

Le flux est un excellent état lorsque vous connaissez les étapes exactes pour résoudre un problème. c'est-à-dire quelques inconnues inconnues. Vous vous asseyez dans un coin calme et martelez la solution. Cependant, la plupart des problèmes / histoires / fonctionnalités ne sont pas très clairs lorsque vous commencez à les programmer. Il y aura toujours un "écart" entre l'état final attendu et la façon dont votre cerveau l'a "planifié". Vous apprenez beaucoup de choses lorsque vous "le faites". Votre cerveau jongle

• Conception du code

• Dactylographie

• Apprendre de nouvelles choses sur le domaine et le code

Quand je programme seul, j'ai du mal à équilibrer ces choses. J'ai tendance à entrer dans des «trous de lapin» où mon erreur de coût irrécupérable m'empêche de prendre du recul et de regarder la situation dans son ensemble et de changer ma conception. Il est également difficile pour moi de parler à un canard en caoutchouc imaginaire ou à un vrai d'ailleurs. Je suis après tout en "flow".

Cependant, lorsque je suis productivement en programmation par paires, j'obtiens des périodes de frappe alternées suivies de périodes de réflexion et de réflexion. C'est là que beaucoup de choses cachées se révèlent et qu'un design différent peut émerger. Si je vais dans un terrier de lapin, mon partenaire de jumelage peut m'en sortir. Parler / expliquer quelque chose à un véritable être humain a ce merveilleux effet de rendre vos pensées plus claires d'une manière ou d'une autre. Parfois, ça me manque d'être dans le "flow", mais je pense que je contribue beaucoup plus à mon équipe lorsque je fais du programme en binôme que lorsque je programme en solo. Après toute programmation! = Taper. La programmation se fait dans le cerveau et une meilleure programmation se produit lorsque deux cerveaux collaborent et se critiquent mutuellement.