Voy a dar mi opinión acerca de usar esta técnica para tratar de reclutar a alguien para un equipo de ingeniería de software que hace producto o para ser contractor.

Pero antes, voy a recordar qué es esta técnica. Basicamente, poner a dos personas a resolver un problema, con un solo ordenador. Tenemos dos figuras, el driver y el navigator. Estos son los deberes que deben cumplir.

Conductor:
-Escribe el código según la especificación del navegador.
-Escucha atentamente las instrucciones de los navegantes
-Haga preguntas donde haya falta de claridad
-Ofrecer soluciones alternativas si no está de acuerdo con el navegador
-En caso de desacuerdo, déjelo en manos del navegante. Si su idea falla, fracasa rápidamente y sigue adelante.
-Asegúrate de que el código esté limpio
-Posee la computadora / teclado
-Ignorar problemas más importantes y centrarse en la tarea en cuestión
-Confíe en el navegador: en última instancia, el navegador tiene la última palabra en lo que está escrito
-Estás escribiendo el código

Navegador:
-Dicta el código que se va a escribir – el ‘qué’
-Comunica claramente qué código escribir
-Explica ‘por qué’ han elegido la solución particular a este problema.
-Compruebe si hay errores de sintaxis / tipo mientras el controlador conduce
-Ser la red de seguridad para el conductor
-Asegúrese de que el conductor se apegue a la pequeña tarea en cuestión
-Esbozar y anotar tareas / problemas de alto nivel
-Revisión de código en curso
-Presta atención
-Espere hasta que se complete la tarea para que surjan problemas de diseño / refactorización

Ambos:
-Participa activamente en la programación
-Apunte a un flujo óptimo – evite tratar de ser ‘correcto’
-Acepta tu papel
-Interviene si tu pareja está callada
-Saber cuándo renunciar / robar el teclado
-¡Comunica, comunica, COMUNICA!
-Sincronice con frecuencia para asegurarse de que está en la misma página
-No acapares el teclado
Choca esos cinco cada vez que pasa una prueba
-Siga las mejores prácticas para TDD
-Intercambiar roles con frecuencia

Vale? básicamente uno le dice al otro que debe escribir y si el otro no está de acuerdo, se trata de llegar a un consenso para escribir el mejor código posible a la primera, sin necesidad de tener que hacer revisión de pares por un tercero. Hasta ahí, más o menos de acuerdo, con mis pegas.

Esto puede funcionar si para hacer una prueba, el que te examina hace de driver y deja al navegante escribir lo que crea conveniente, pero si el driver ya te dice de primeras que, por poner un ejemplo, no puedes usar objetos, solo puedes usar primitivas, o lo que sea, primero estás faltando al respeto a la persona porque estás imponiendo de manera absurda tu voluntad, no estás llegando a un acuerdo, te aprovechas de tu posición para imponer tu voluntad. Es anticientífico en definitiva. Si haces eso, el navigator siente que tiene que adivinar el código que tienes que escribir, anulando por completo la confianza y la experiencia acumulada. Llegaba un momento en que el entrevistador driver escribía el código en el test sin que yo le dijera absolutamente nada, anonadado como estaba ante la mala intención y ganas de quedar por encima que mostraba el entrevistador. Al final, el entrevistador hizo en dos horas, una implementación de una clase Set limitada a 10 objetos que usaba un Array para mantener la información. Y no pude ni expresar mi opinión acerca de la perdida de tiempo y de la calidad del código que salió.

Algo que si quieres hacer un poco más especial, como que quieres guardar objetos en un conjunto en orden de aparición o en orden natural, o si quieres una estructura basada en multhilo para aprovechar el paralelismo u otro tipo de conjunto tan especial como que se te pueda ocurrir, las posibilidades las da la imaginación, al final sólo necesitas que esa clase tenga como atributo privado una estructura u otra, como un hashmap, un treemap, concurrenthashmap, etc…

En fin, es obvio que la finalidad de la prueba no era producir una implementación genial de un conjunto, si no medir si soy capaz de trabajar en equipo haciendo pairing. Es obvio que si el driver impone su voluntad y no deja que el navegante pueda dar su opinión, pues te quedas en que el único que aporta es el driver y el navegante siente que no ha hecho nada, no ha podido aportar nada y su opinión y experiencia se mal usa. No me gustó. Primero por motivos de eficiencia, por la calidad del código, segundo porque fue estresante, me sentí como volver al primer año de universidad cuando no sabias absolutamente nada, porque tratabas de adivinar el pensamiento del profesor, hasta que por fin comprendes donde quieres llegar. Y por último, no es justo para tratar de probar la capacidad del ingeniero al que quieres fichar. Quieres quedar por encima del postulante, no quieres comprobar nada. Quieres poder decirle a la empresa que te contrata que eres imprescindible, quieres quitar competencia. Absurdo. Quiero ayudar, quiero participar, nada más.

Mucho más interesante para hacer pairing y tdd, es una situación en la que uno escribe el test, el otro escribe la clase de producción, para luego cambiar los papeles. Se intercambian ideas acerca de la implementación de cada uno, se refactoriza lo que haya que refactorizar, se aprende uno del otro y se avanza con rapidez a otro caso de uso. Con rapidez y agilidad, produciendo código de calidad porque damos una revisión de pares muy rápida, sin necesidad de ser dogmático acerca de que uno solo puede tener el teclado y solo mi opinión es la correcta.

La finalidad de hacer pairing es producir código de calidad que pase por revisión de pares, de manera que varias personas se sientan dueños del código y se sientan más responsables del código producido, no vaya a ser que uno de los dos decida irse a otro lugar porque de repente recibe una mega oferta económica imposible de rechazar. Estas cosas pasan, lo sé, lo he visto. Se trata de justificar también ante el empleador, que dos ingenieros que ganan, por decir una cifra, 100k al año, pueden producir un código que haría una persona que gane mas de 200k. De esta manera, el empleador está malgastando dinero, garantizado.

Tiene sentido hacer pairing como el que yo pasé en la prueba cuando juntas a un programador junior junto con un senior. El junior aprenderá del senior. Cuando juntas a dos programadores experimentados, uno de los dos se aburrirá y se estresará. Sentirá que está perdiendo el tiempo. Garantizado. Si juntas a dos programadores experimentados y no tomas en cuenta para nada lo que opina el otro, al final desconectará, y se perderá así el sentido de pertenencia entre dos y la revisión de pares.

En fin, ha sido una experiencia mala, espero no volverme a encontrar en una situación así, porque realmente quería aportar a este proyecto y a causa del pensamiento dogmático y cuadriculado de seguir a rajatabla una serie de reglas en las que el entrevistador se extralimita, siento que me he perdido una magnífica oportunidad de avanzar y seguir aprendiendo.

El pensamiento dogmático es anticientífico, totalmente contrario a la libertad de pensamiento y antiproductivo. Seguir las reglas de manera dogmática impide que puedas cuestionar su motivación.

Al final, hice una implementación para preparar la prueba, en la que aprendí como es la implementación real de un conjunto en el JDK, que hacer para extender el comportamiento matemático de un conjunto, y al final me quedo que gracias a esta prueba, pude bucear en las entrañas y comprender las motivaciones de los ingenieros del JDK. No tuve necesidad de reinventar la rueda, pero adquirí el know how necesario por si tuviera que crear una rueda hecha de adamantium. Al final me quedo con eso y a otra cosa, mariposa.

Alonso.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s