Metodologías 2
Pair programming (de a dos es mejor)
Aunque no lo creas hay una práctica común en el mundo de la programación que consiste en dos personas trabajando en un sólo computador. A esta práctica se le conoce como pair programming y tiene numerosas ventajas dependiendo de la situación.
Más Disciplina. Emparejando correctamente es más probable que hagan “lo que se debe hacer” en lugar de tomar largos descansos.
Mejor código. Trabajando en parejas es menos probable producir malos diseños ya que su inmersión tiende a diseñar con mayor calidad.
Flujo de trabajo constante. Bajo la metodología de pair programming el flujo de trabajo distinto al trabajar solo. En parejas el flujo de trabajo se recupera más rápidamente: un programador pregunta al otro “¿por dónde quedamos?“. Las parejas son más resistentes a las interrupciones ya que un desarrollador se ocupa de la interrupción mientras el otro continúa trabajando.
Y finalmente hay una virtud muy útil cuando se trabaja de forma maratónica, ya sea porque se acerca un plazo de entrega o se está una competencia y es la resistencia a la fatiga, los programadores estamos acostumbrados a trabajar muchas horas seguidas, pero durante los periodos finales cometemos muchos más errores que cuando estamos descansados, en ese caso pair programming sirve para que uno de los miembros revise los detalles menores (errores que introduciremos) mientras el otro trabaja en el big picture.
¿ Cuando no ocupar la metodología de Pair PRogramming?
Como en todas las estructuras de trabajo no hay balas de plata ni formulas mágicas, en ciertas ocasiones el trabajo de un programador puede ser relativamente mecánico, en ese caso y cuando los errores no son críticos, el pair programming es una práctica que no es muy útil, puesto que hay dos personas haciendo el trabajo de una sola, lo que puede ser visto como un desperdicio de tiempo en la empresa.
Tampoco es aconsejable obligar a dos personas que no se relacionan bien a trabajar en conjunto, el pair programming requiere que dos personas pueden comunicarse bien, una debe liderar el proceso y la otra lo sigue, pero esos roles son dinámicos a lo largo de la jornada y también es común que ambos intercambien de asientos durante el proceso.
Explícale a un idiota
Les presento al startup monkey, este es mi compañero de programación y me acompaña desde que empecé a emprender, normalmente está colgando en la pared al lado mío pero cuando no se me ocurre como resolver un problema le cedo mi asiento y le explico lo que estoy haciendo, ¿ridículo cierto?
Esta práctica es famosa en la industria de la programación, se llama explícale a un idiota y consiste en explicarle a alguien más lo que estás haciendo, esta persona no tiene porque ser necesariamente idiota, basta con que esté presente.
Lamentablemente no siempre tenemos a alguien disponible e incluso teniendo a alguien al lado no es buena practica estar interrumpiendo a los compañeros programadores. En ese caso es cuando se vuelve útil contar con un peluche, figura de acción, amigo imaginario, mascota, da igual que sea real o virtual, pero tiene que ser algo o alguien que te permita contarle tu problema paso a paso de forma de hacer explícito tu razonamiento.
La importancia de hacer explícito tu razonamiento es que los problemas complejos de resolver en el ámbito de la programación muy rara vez son del tipo del te faltó un punto y coma, normalmente suceden por errores lógicos , y la lógica al igual que las ideas en tu cabeza cuadran perfecto, pero cuando la pones en papel te das cuenta que no tiene sentido.
Explícale a un idiota es el método de debugging por excelencia
La próxima vez que te enfrentes a un error que no logres encontrar en tu código prueba esta metodología, hacerlo con un peluche es particularmente funcional puesto que te vas a sentir muy ridículo haciéndolo y por lo mismo te vas a relajar lo que te va a hacer más fácil encontrar tus errores.