He estado haciendo pairing toda mi vida como desarrollador, de una manera estructurada, ortodoxa o informal. Siempre prefiero trabajar con un colega en lugar de trabajar solo. Pero he visto muchas organizaciones en las que los desarrolladores huyen de la práctica de trabajar juntos de esa manera.

El pair programming no es solo para casos complicados o para enseñar a alguien, sino que es una técnica de trabajo aplicable en el día a día.

Las opiniones a menudo no están bien fundamentadas. Y, cuando se pregunta  a los desarrolladores por qué no les gusta trabajar de ese modo, aparecen tres respuestas comunes: "Es una pérdida de tiempo" (lo que realmente quieren decir es que no tengo tiempo para hacerlo), "Es solo un dev trabajando , y un dev mirando "(no puedo codificar mirando) o" no me gusta "(prefiero escuchar música mientras trabajo).

Así que vayamos paso a paso a los conceptos erróneos más comunes de la programación por pares y por qué a mí me funciona:

¿Qué es la programación por pares?

Pair Programming es una técnica que involucra dos roles: driver y navigator.
El driver utiliza el teclado y tiene una forma de pensar TÁCTICA, resolviendo el problema actual escribiendo el código. Para hacer eso, NECESITAN decir en voz alta cada línea de código escrito. Están hablando continuamente. Explicando lo que están haciendo y, tal vez, incluso por qué lo están haciendo.

Por otro lado, el navigator está pensando estratégicamente, mirando el panorama general, lo que vendrá después, cuál es el impacto en el sistema, cuándo fue la última confirmación, cómo están los edge cases en el sistema, qué pasa con estas otras librerías ... El navigator escucha al driver, pero también le hace preguntas, piensa en alternativas y proporciona feedback.
Y se intercambian los roles a menudo.

La regla es, "para que algo pase de su cabeza al ordenador, DEBE pasar por la OTRA persona".

¿Por qué deberíamos hacer una programación por pares?

Una pregunta más fácil de responder utilizando mayéutica socrática.
Es una conversación que me encanta tener con personas que ya utilizan pair programming, pero que se resisten a utilizarla con frecuencia. Entonces, cuando empezamos a plantear preguntas para desarrollar el pensamiento, generalmente terminamos en la misma conclusión:

• Hay un incremento en la calidad del código. Dos personas mirando, pensando y hablando sobre el código, hacen que el código sea mejor, con menos errores. Sí, tiene un compilador de código más rápido en su colega. Hay una larga conversación aquí sobre "¿necesitamos revisiones por pares si estamos haciendo programación por pares?" y si bien esta pregunta puede crear otra publicación , la respuesta corta es: No, no es así.
  
  
• Código más homogéneo. A medida que hay más personas involucradas, las soluciones están más alineadas y el estilo del código también. Es más fácil seguir los estándares del código si dos personas están comprobando su trabajo mutuamente.
  
  
• Más intercambio de conocimientos. Este es claro; más gente está involucrada, más gente lo sabe. Por lo tanto, menos bus factor, menos riesgos y  desarrolladores están más comprometidos con el producto porque lo conocen más.

• Foco. Seamos realistas, vivimos en un mundo lleno de distracciones, notificaciones, pings, correos electrónicos urgentes no tan urgentes, etc. Pero, ¿revisas tus notificaciones cuando alguien está sentado contigo en una conversación ???  Estás concentrado en tu pair y en el código, y nada más. Además, recuerda que es más fácil que alguien en la oficina interrumpa a una persona sola que dos personas que trabajan juntas.
  
  
• Ciclos de feedback más cortos. Y de esto se trata Agile; tener ciclos lo más cortos posible, para que podamos hacer bien las cosas correctas. Alguien a tu lado te está dando una feedback instantáneo, ¿acaso alguna otra técnica permite hacerlo más rápido? 

Todos estos beneficios se aplicarán a medio-largo plazo en el proyecto, por lo que debo admitir que no siempre se percibe el valor a corto plazo, (irony_mode = on) pero solo estamos tocando este sistema por un par de meses más. , ¿correcto? (iron_mode = desactivado)

Entonces, cada segundo que no hacemos pair programming nuestro código tiene menos calidad, es menos homogéneo, el conocimiento fluye menos y necesitamos hacer un mayor esfuerzo para compartirlo, podemos distraernos más a menudo y los ciclos de feedback son más largos.

¿Existen diferentes escenarios de programación por pares?

He identificado estos cuatro escenarios comunes, según el conocimiento del sistema del driver y el navigator.

Uno de los errores más grandes que he visto en muchos equipos es usar la programación por pares para sumar a un nuevo miembro del equipo y poner al nuevo miembro del equipo como navigator en el par. En mi opinión, esto es extremadamente ineficaz. Un nuevo miembro del equipo, que no conoce el sistema, no puede tener el enfoque estratégico del problema. El nuevo miembro del equipo debe mostrar una personalidad fuerte para hablar y decir cuando no entienden algo, el proceso termina en un navigator silencioso, con poco conocimiento del sistema y un driver que habla cada vez menos y solo escribe para escribir código cada vez más rápido para cumplir con una fecha límite inminente, mientras arrastra a ese nuevo miembro del equipo. Esto genera una experiencia de training muy negativa. Si quiere enseñar, establece el training y la aceleración como objetivo, y deja que el nuevo miembro del equipo sea el driver.

¿Por qué muchas personas no recurren al pair programming?

No se trata de código. No es una habilidad técnica. Repito, no se trata de código. Profundicemos en ello: 

Pair programming es una habilidad social. Se trata de comunicación y relaciones. Y nosotros, desarrolladores, no estamos capacitados en la universidad o en la escuela secundaria específicamente en habilidades sociales. Entonces, ¿funciona solo si eres una persona extrovertida y social por naturaleza con buenas dotes de comunicación? No, no necesitas tener este caracter. Los introvertidos y las personas menos sociales también pueden ser excelentes practicando pair programming. No va a se difícil SÓLO por el único motivo de que no eres un animal social por naturaleza, es difícil para TODOS, pero vale la pena.

Lo bueno es que es una habilidad, y por lo tanto, como con cualquier habilidad, puedes aprender a hacerlo mejor. Deja que comparta algunos de los learnings que obtuve durante mi tiempo haciendo pair programming:

Lo que se debe y no se debe hacer en la programación por parejas

Empezad por poneros de acuerdo sobre el entorno y el ecosistema de trabajo. El espacio físico, la configuración IDE, todo.

Hay personas que odian cuando alguien toca la pantalla, y luego hay monstruos a los que les encanta señalar la pantalla y dejar sus huellas dactilares. Soy uno de esos monstruos. Hay personas a las que les gustan varias pestañas en el IDE, y a otras personas solo les gusta una pestaña por pantalla. Además, en tiempos de pandemia, hay personas más sensibles a que otras personas toquen el mouse o el teclado. Así que hagamos que funcione, hablemos con anticipación y acordemos cómo nos gusta trabajar. Si es necesario, recurrir a un teclado doble, un mouse..lo que sea.

Pero no se trata solo del espacio físico, también debe ponerse de acuerdo sobre los estándares de codificación, los principios a utilizar, etc. Necesitáis acordar el terreno común y el objetivo, pero lo más importante; necesitáis aclarar qué entendéis por "mejor". A veces discutimos mucho sobre qué solución es "mejor", sin definir qué significa eso. Mi mejor consejo al respecto es aclararlo. En ese escenario, ¿es mejor buscar legibilidad? ¿rendimiento? ¿reutilización? ¿seguir los principios? ¿utilizar estándares? Pase lo que pase, antes de empezar a discutir sobre el código, defina cuál es el objetivo y qué significa "mejor".

Cuando habléis de código, sed explícitos y comunicaos en exceso. No permitáis  que las suposiciones arruinen la conversación.

Y, como cualquier pareja en la vida, es mejor si le prestas atención a la otra persona y le muestras empatía, escúchala. Ser claro, empático, asertivo, respetuoso hace que todo sea más fácil. Recuerda, esto no es una guerra, no es una pelea, no hay forma de que ganes si vas solo, porque estás compartiendo algo con otra persona y los dos queréis el mismo resultado. Por lo tanto: deja espacio, acepta enfoques diferentes y concéntrate en construir la relación. Escucha los comentarios y acepta las correcciones, pero sobretodo no olvides aportar tú también.  

Truco 1: los buenos compañeros están abiertos a probar el enfoque de la otra persona.
Truco 2: proporciona feedback, pero también comentarios positivos y tantos cumplidos como puedas. Si la otra persona está haciendo las cosas bien, ¡díselo! A todos nos gusta escuchar que estamos haciendo las cosas bien. Sé amable y simpático, sin parecer condescendiente.

Entonces, como puedes imaginar, ser consciente de todo esto y pasar horas en el día es ... agotador. Entonces, necesitamos tomar descansos frecuentes. No lo dudes, para a menudo. Ve a tomar un café, habla de la última película que viste o lo que sea. Pero no dejes que tu cuerpo y tu mente caigan en un cortocircuito. Es más dañino de lo que piensas. ¿Qué piensas si estás haciendo algo con alguien que SIENTES que no te está prestando atención?

Aunque probablemente el peor comportamiento sea traicionar la confianza de tu pareja, cambiando el código. Si aceptas abordar el código de alguna manera, no lo cambies sin la aprobación de tu compañero. Lo peor es cuando vas al baño y cuando vuelves todo es diferente porque “creo que fue la mejor manera de hacerlo”. Es una traición. Estás rompiendo la primera y única regla. No hagas eso.

Pair programming también se trata de nuestros sentimientos, somos humanos y debemos ser conscientes de cómo se sienten los demás. Además, debemos ser conscientes de nuestros propios sentimientos, podríamos tener un mal día debido a un atasco de tráfico o porque nuestro bebé está enfermo. Así que sé abierto, comparte y sé consciente de cómo estás reaccionando. No se trata de una reacción negativa, sino de lo que haces en los próximos 5 segundos. Si tengo una mala reacción y la dejo ahí, entonces pensarás una cosa (probablemente mala) de mí, pero si en los próximos segundos me disculpo y explico mi reacción, probablemente pensarás diferente sobre mí.

Conclusion

Recuerda, cuando te inicias en el pair programming, te sientes extraño, agotado y es un proceso que requiere disciplina. Así es, y eso que sientes le pasa a todo el mundo al principio. Simplemente relájate y continúa adelante.

A veces tenemos miedo de que nos perciban como malos desarrolladores o simplemente nos gusta que se nos perciba como los mejores. Recuerda: no te preocupes por pair programming, no es tan bueno como crees, ni tan malo como temes. Todos aprendemos de los demás y todos damos algo a los demás. No olvides en qué escenario te encuentras.

Al final se trata solo de ser una buena persona.

No expreses superioridad, ni te retraigas; no te quedes en silencio, codificando solo. A todos nos gusta tener el teclado, así que cámbialo a menudo y deja que todos se diviertan. No intentes ganar, o hacer que la situación sea todo o nada, ni te quejes continuamente. Solo sé amable.

PD: ¿Qué pasa con pair programming en remoto? Tendremos otra publicación sobre ello, pero ALERTA DE SPOILER: es lo mismo :-P