Dentro del marco metodológico de "Extreme Programming", una de las herramientas más utilizadas es el "Pair Programming".

Aunque por su nombre podemos entender que es el hecho de que dos personas programen en pareja, esta práctica va más allá de eso. Lo que buscamos es tener una validación a pares del código que se desarrolla, para ello, lo que buscaremos será exponer y rebotar ideas con la persona que nos acompañe en dicha sesión.

El hecho de tomar decisiones técnicas entre dos personas tiene ciertas implicaciones positivas sobre los equipos de desarrollo, como son:

• Un conocimiento distribuido.
• Se reduce la sensación de propiedad o autoría.
• Una solución consensuada de mayor excelencia.
• Fortalece los vínculos personales y la sensación de equipo.
• Permite que el equipo crezca a mayor velocidad en cuanto a conocimiento y experiencia.
• La inversión de tiempo se recupera rápidamente, ya que se invierte menos tiempo en corrección de errores ya que estos se introducen en menor medida.

Existen distintas variantes acerca de cómo o cuándo hacer "pairing", por lo que la experiencia de trabajar en pareja es algo muy personal y dependerá de las personas que conformen la dupla.

⚠️ Cuando ambas personas son nuevas en esta técnica y dada la ausencia de un mediador, puede costar encontrar el punto de sinergia, llegando incluso a ser frustrante, por lo que podría ser recomendable empezar este tipo de prácticas en sesiones donde si exista un facilitador, como puede ser en "Mob Programming".

Los roles

En una sesión de pairing existen dos roles bien diferenciados: el "Driver" y el "Navigator". Sin embargo, el cómo se comporta cada uno dependerá de la pareja y los acuerdos a los que estos lleguen. A continuación, daré un punto de vista personal de cómo a mí me ha funcionado durante estos años y el como mejor disfruto de esta experiencia.

• Driver: Es la persona encargada de controlar el teclado. El "Driver" es el responsable de plasmar en código las decisiones que se han consensuado previamente en la pareja. Sin embargo, la forma de ejecutarlo es algo personal. Mientras escribe el código, el "Driver" debe transmitir al "Navigator" qué es lo que está buscando con ese código, ayudando a que la persona que observa entienda los pensamientos que se están tratando de plasmar. Esto ayudará bastante al "Driver" a entrar en estado de flujo. El "Driver" debe buscar esa validación de lo que está haciendo y poder debatir sobre ello con el "Navigator" cuando lo vea pertinente.

• Navigator: Es la persona encargada de observar y anotar. El "Navigator" debe entender en todo momento qué está tratando de plasmar el "Driver" y apuntar aquellas cosas con las que discrepe, que le llamen la atención o causen inquietud, incluso posibles mejoras a realizar. Esta información se debe transmitir antes de que el "Driver" tome el teclado y después de que el "Driver" suelte el mismo, buscando mantener el estado de flujo el mayor tiempo posible. Habrá ocasiones en las que el "Navigator" deba interrumpir para ayudar al "Driver" para desatascar situaciones, encauzar la sesión cuando se divaga o para rebotar ideas que crea que pueden ser críticas. La persona que desempeña este rol tiende a perder la concentración, por lo que requerirá de una buena comunicación con el "Driver" para que este pueda ayudar a dinamizar la sesión.

Los roles pueden rotar en cualquier momento, pero esto debe ser consensuado entre la pareja, por ejemplo, cambiar de rol durante pomodoros de 50-10, o haciendo ping-pong TDD. Esta última funciona bastante bien cuando al "Navigator" le cuesta mantener el foco.

💡 En Ping-Pong TDD se rota de rol de tal forma que una persona escribe el test, lo deja en rojo y pasa el teclado a su pareja. La persona que toma el rol de "Driver" implementa el código necesario para que el test pase a verde, escribe el siguiente test y pasa a ser "Navigator" nuevamente. Es importante que los tests tengan una alta granularidad para que la experiencia sea positiva.

El factor tiempo

Una cuestión muy común es "¿Cuánto tiempo debería hacer "pairing" al día?" Lo cierto es que es una respuesta muy personal y que dependerá de múltiples factores, más humanos que técnicos.

Es importante entender que es una parte muy humana, habrá días donde, por motivos personales ni siquiera sea aconsejable que hagas "pairing", porque tu estado no te lo permite ese día, y más que buscar un entorno colaborativo y de crecimiento, lo que se van a crear son fricciones.

Por otra parte, tener un rechazo constante a esta práctica, no es positivo para las personas que sí disfrutan con ella. No hablamos solo de satisfacción personal, sino del sentimiento de desempeño óptimo del trabajo.

Lo que es innegable es que es una práctica altamente demandante y que requiere mucha disciplina, concentración y habilidades blandas, por lo que mantener estas sesiones durante jornadas de 8 h puede ser agotador y contraproducente en ciertos casos.

Personalmente, pienso que es algo que se debe dar de forma natural, hay personas que disfrutan de largos e intensos debates durante horas, mientras otras personas se sienten más cómodas en la brevedad y la certeza de los puntos a tratar. He tenido sesiones de 8 horas constantes durante días que he disfrutado especialmente, al igual que he tenido sesiones de 2 horas que he rogado que terminasen.

Otro factor que debemos tener en cuenta es la carga de trabajo o las responsabilidades de las personas que se encuentran en la sesión. Mientras que hay personas que dedican su tiempo plenamente al desarrollo, otras deben compaginarlo con responder mensajes, dar soporte o simplemente tienen unos horarios personales que les implica ausentarse durante ciertas horas. Es por ello que lo mejor es acordar la distribución del tiempo en pareja, llegar a consensos e iterarlos con el tiempo en base a las necesidades de cada uno.

Lo que sí es primordial es que el tiempo que dediquemos a hacer "pairing" debe ser exclusivo para ello, tanto por respeto al trabajo como a la otra persona.

El espacio

La práctica del "Pair Programming" nació cuando el trabajo en remoto aún no estaba en auge, por lo que es algo que, con el paso del tiempo se ha tenido que ir redefiniendo.

Para poder entender el contexto actual, es importante conocer los comienzos y los porqués de ellos. En sus comienzos, la idea era que dos personas trabajasen frente a la misma pantalla, con un mismo teclado, es decir, solamente una persona podría escribir al mismo tiempo. Un detalle importante era la elección del material. Ambas personas debían sentirse cómodas con ese teclado y conocer el sistema operativo y herramientas con las que se desarrolla. La elección de un dispositivo con el que una de las dos personas no se sienta cómoda podría influir en que no entrase en estado de flujo.

Durante estas sesiones se buscaba crear un ambiente de debate distendido en el cual se reflexionaba sobre el código y se planteaban posibles soluciones. Es por ello que el hecho de tener música relajante o café no era algo extraño. Para que la conversación se desenvuelva de forma natural, es importante que el ruido ambiente sea el menor posible, y que de la misma forma la conversación no moleste a otras personas del equipo trabajando en la misma sala.

Si llevamos estas ideas a un entorno remoto, podemos observar cómo hay barreras que ya no son relevantes, como puede ser la elección del teclado o el sistema operativo ya que cada persona trabaja con su propio material. Sin embargo esto puede dificultar otras facetas como puede ser que mientras el "Driver" escribe, el "Navigator" se vea tentado a escribir en otras partes del proyecto en simultáneo. Aunque está claro que la intención es de ayudar, esto desvirtúa la práctica y puede llegar a ser contraproducente.

Por otro lado, el espacio de trabajo dista ligeramente, aunque no queda exento de puntualizaciones. La elección del material con el que nos comunicamos sí que pasa a ser una pieza crucial. El uso de un micrófono que transmita la voz de forma clara y elimine posibles ruidos, el poder ver la cara de la otra persona e interpretar sus reacciones faciales (tanto positivas como negativas), es algo que facilita la comunicación y mejora sustancialmente la experiencia.

Debemos tener en cuenta que, cuando nos comunicamos por escrito, solamente se transmite un 25% de la información deseada. Cuando lo hacemos mediante llamada, se añaden factores como el ritmo, o la entonación del mensaje, rondando cerca del 50% de la información que queremos transmitir (a esto se le conoce como comunicación paraverbal), mientras que una videollamada la información se complementa con la postura corporal, el movimiento de las manos, siendo capaces de transmitir con certeza casi el 75% del mensaje (lenguaje no verbal).

“El componente verbal es un 35% y más del 65% es comunicación no verbal” - Albert Mehrabian

La actitud

Cuando se hace "Pair programming" es inevitable que una de las dos partes se exponga más que la otra. Esto se debe a que las personas se sienten evaluadas, tienen miedo a equivocarse o les cuesta transmitir las ideas que tienen en mente de forma clara. Por ello, muchas personas rechazan esta práctica, prefiriendo mantenerse en una zona de confort.

Para poder mitigar esta situación, es muy importante crear un espacio seguro entre las personas. Para ello la comunicación es clave, debemos ser asertivos y empatizar con las personas con las que trabajamos. Facilitar un ambiente distendido donde las personas se sientan libres de transmitir sus ideas es crucial, y es precisamente el beneficio de esta práctica. Si una de las personas no puede comunicar sus ideas, estamos desaprovechando la oportunidad.

Por otro lado, comprender que los errores son algo positivo es crucial. Nadie debe ser o sentirse juzgado por un error, de hecho, es el espacio idóneo para equivocarse. Aprender en confianza y prevenir errores en la fase de desarrollo es una de las virtudes de este tipo de prácticas.

Por ello, podemos concluir con que las personas que ejercen esta práctica deben tener una actitud positiva, comprensiva y empática hacia la otra.

Rotaciones

Además de rotar entre el rol de "Driver" y "Navigator", es importante que los miembros de la pareja roten con otras personas por varios motivos:

• El conocimiento no queda entre esas dos personas, sino que se hace extensible a todo el equipo. Cuando las personas rotan y se encuentran en medio de una tarea, una de las dos se debe quedar, mientras que la nueva persona recibe contexto de lo que se estaba haciendo.
• Se pierde apego al código (que no a la calidad). El código pasa de ser de propiedad individual o de la pareja a un ámbito global de equipo, por lo que la responsabilidad se reparte entre todos los miembros.
• Se minimizan las fricciones. Cuando dos personas no encajan a nivel personal, pensar que se va a pasar largos periodos de tiempo trabajando juntas puede ser frustrante. El tener rotaciones de 2-3 días permite que las relaciones personales no se estanquen y que por el contrario, se puedan trabajar de forma iterativa.

Qué no es

Hasta ahora hemos descrito muchas de las características que representan el "Pair Programming", los beneficios que aporta y algunas técnicas. Podemos llegar a pensar que se trata de una solución a muchos de nuestros problemas, y lo cierto es que lo es, aunque no sea una navaja suiza.

Debemos entender que hay escenarios donde esta forma de trabajar no encaja, o donde su desempeño no soluciona las necesidades del trabajo, por ello debemos tener en cuenta ciertos aspectos:

• Hacer "pairing" no es un Dogma. Aunque hemos dado pautas sobre cómo realizarlo correctamente, existe un factor humano personal muy grande que va a determinar pequeños detalles acerca de cómo desempeñamos esta tarea. Esta práctica debe ser algo flexible y que nunca se dará de la misma forma ya que depende de la relación de las personas implicadas.
• Hacer "pairing" no implica ir más rápido. Buscamos el validar ideas y ser reflexivos, por lo que la velocidad a la hora de generar código no es algo que vayamos a conseguir. Sin embargo, sí que a lo largo de la vida de un producto, se reducen los tiempos de desarrollo, debido a que las decisiones en conjunto implican mayor conocimiento por parte del equipo, menor introducción de bugs y generalmente un mejor diseño que permite escalar. En definitiva, pasaremos menos tiempo arreglando código que si las personas trabajasen de manera individual.
• Hacer "pairing" no es "mentoring". Podría sonar sensato el plantear la posibilidad de mentorizar a alguien mientras se escribe código en conjunto, pero existe un detalle por el que se desvirtúa el objetivo principal: "Si estás mentorizando a alguien, no estás rebotando tus ideas, sino que las estás transmitiendo de forma unidireccional". Por lo tanto, a pesar de que dos personas compartan el mismo teclado, no se podría decir que estamos aplicando esta forma de trabajo.

Variantes

Existen otras modalidades como el "Mob Programming" o el "Ensemble Programming", en las cuales el número de participantes aumenta, por lo que ciertos puntos mencionados sufren ciertas variaciones, como son los roles, introduciendo otros, la duración de las sesiones, o incluso potenciando ciertos beneficios mencionados al principio. Todo esto dependerá también de cómo se faciliten estas sesiones.

Cuestiones sobre:

La IA

En la actualidad, existen herramientas como Copilot con las que podemos programar y debatir sobre soluciones de código como si se tratase de nuestro "Navigator". Sin embargo, debemos ser conscientes que para que esta conversación se dé al mismo nivel que con una persona, debemos saber usar la herramienta de forma adecuada, proveyendo a la misma de acuerdos de equipo, contexto del producto, particularidades del mismo... por lo que no resulta una tarea sencilla.

Incluso la escritura del "Prompt" que proveemos a dicha herramienta es algo que puede ser contrastado con el "Navigator", por lo que considero que el uso de estas no tiene por qué ser excluyente de estas formas de trabajo.

El uso de Pull Request

Muchos equipos consideran que el uso de Pull Request (PR) es totalmente innecesario cuando se practica "Pair Programming" ya que el objetivo de estas es que otras personas revisen el código desarrollado y lo validen, previo a ser mezclado con otra rama de código. Visto así, esa revisión ya se está dando al trabajar en parejas, por lo que no es descabellado reducir estos cuellos de botella y optimizar el trabajo.

Ahora bien, esta visión es bastante simplista, ya que estamos perdiendo de vista el contexto del equipo donde se adoptan estas prácticas. ¿Cuánto tiempo pasan las PR en revisión? ¿Cuál es el nivel de experiencia del equipo? ¿Cuánto contexto sobre el desarrollo queremos que se tenga? No debemos dar por sentado que el código ya ha sido revisado sin más. Habrá situaciones donde las PR tengan más sentido que en otras, por lo que es responsabilidad de cada equipo definir estos acuerdos.

Practicar Pair Programming siendo junior

Podríamos llegar a pensar, que teniendo poca experiencia, no eres la persona adecuada para rebotar ideas o validar las de alguien que lleva más años trabajando. Nada más alejado de la realidad. Lo cierto es que los años de experiencia no es más que un número. Las ideas, el innovar, las ganas de mejorar, la perspectiva del desconocimiento son factores cruciales a la hora de desarrollar.

Cuando una persona lleva mucho tiempo haciendo algo es normal asumir malos hábitos o entrar en automatismos, cómo si de una cadena de producción se tratase. El poder contrastar estas ideas con otras personas, hará que la persona con más años rompa con estas dinámicas que resultan contraproducentes para el desarrollo y conseguirán que tú, como persona con menos experiencia puedas nutrirte de toda ella.

Conclusión

El "Pair Programming" es una práctica de desarrollo que nos permite trabajar con el código contrastando ideas y apoyando la toma de decisiones de forma consensuada, lo que aporta robustez y excelencia al código.

Esta práctica no es un dogma y, dado el factor humano, el desempeño variará ligeramente dependiendo de las personas. No se debe perder de vista cuál es el objetivo de este para no desvirtuar la práctica.

En ocasiones, este ejercicio puede ir más allá del código, llegando incluso a escribir correos en conjunto, redactar documentación o realizar diagramas. Es muy sencillo entrar en este tipo de dinámicas cuando las personas crean buenas sinergias y no resultan para nada contraproducentes.