¿Estás haciendo programación de pares en tu trabajo?

Sí, emparejamos la programación durante al menos la mitad del tiempo que “codificamos”, probamos, documentamos, implementamos y simplemente trabajamos. Es una excelente manera de construir relaciones, alinearse, comunicarse, aprender a comunicarse, compartir conocimiento y pasión, adaptarse a la otra persona y muchas otras cosas. No parece muy eficiente para las tareas aburridas (quiero decir que el costo de un error comercial detallado puede ser mucho menor que el costo del emparejamiento, incluidas las ventajas a veces). En pocas palabras, me alegro de haber encontrado una compañía que lo está haciendo, no espero que muchas compañías lo hagan y aconsejo a las personas que lo intenten (especialmente cuando tienden a no funcionar perfectamente con los demás, como la mayoría de los desarrolladores y la mayoría de las personas de esa perspectiva). Por lo tanto, algo bueno para probar durante unos meses.

Más allá de eso, claramente se puede aplicar a cualquier tarea que en algún momento demuestre ser “compleja”. Parte de las razones:

• Hay muchas micro-suposiciones y micro-decisiones que pueden traer una tarea compleja en una zona muerta probable (basada en suposiciones incorrectas, deseo, intuición, creencia o simplemente una decisión no adecuada, dado el contexto).
• Un par saldrá de la zona muerta más rápido, para seguir otro camino, o al menos involucrar a una tercera persona, como el cliente.
• Otra razón es que, cuando hablas, se usa más cerebro y te das cuenta de más cosas, incluso sin que la otra persona te desafíe (y sí, mucho más que con un pato de goma, o según mi experiencia, más que cuando reescribir 10 veces el mensaje a alguna lista de correo o grupo de usuarios).
• La pareja está más enfocada, las personas se desafían implícitamente entre sí para dar lo mejor de sí, estar enfocados y hacer su trabajo de una manera decente y moral.
• Tiene un espejo y abordará las cosas de manera diferente (por ejemplo, yo, como senior, encontraré una forma intuitiva de explicar lo que quiero, a un junior, y aclarar una imagen más amplia para mí).
• Una cosa nueva para experimentar. ¡Y un gran facilitador para trabajar juntos!
• Las expectativas se están negociando juntas. En caso de duda, invite a una tercera persona. Las expectativas alineadas entre 2 o 3 miembros del equipo tienen una probabilidad exponencial de ser lo que sería el consenso general. Eso es realmente eficiente.

Lo he visto una vez: entre dos desarrolladores altamente calificados, que optaron por él solos. Nunca debe ser forzado por el empleador, y mucho menos por la implementación de un “libro de texto” de “ágil” por parte del primer ministro. Funciona perfecto, cuando es natural, aunque solo el 0.0000001% de los ingenieros tiene la mentalidad de adoptarlo y aprovecharlo. Las posibilidades de que se encuentren son escasas. Sin mencionar que ambos desarrolladores necesitan tener las mismas habilidades y experiencia.

No tengo ningún problema con entrenar a un graduado universitario fuerte. Me importa la transferencia de conocimientos a los “recursos de descuento” traídos con visa y “offshore”. Y la programación de pares es completamente incorrecta para entrenar a cualquiera en la OMI.

Incluso la más mínima agenda de explotación mata instantáneamente cualquier buena idea “ágil”: ya sean las reuniones diarias de Scrum o la programación de pares de XP, dejando a los autores del “manifiesto ágil” preguntándose por qué la gente odia algo inventado por los desarrolladores y para los desarrolladores.

En comparación con las reuniones de pie con microgestión, la programación de pares es más sensible a BS, porque dura todo el día. Al igual que las reuniones / capacitaciones interminables, le roba a un ingeniero de privacidad y flexibilidad de rendimiento (tiempo libre). Uno debe tener una confianza absoluta en el empleador (es decir, el crecimiento profesional) para dedicar todo su tiempo al trabajo.

Claro, cada empleador lo posee oficialmente y exige una “atención indivisa” y un rendimiento del 110%, sin mencionar la entrega de todos sus inventos anteriores a cambio de los cheques de pago más pequeños. No comencé esa guerra. En la codiciosa TI de hoy en día que busca todas las formas de diluir su pago a través de largas horas, o usar la presión laboral del tercer mundo como una excusa para pagarle menos que la tasa del mercado, existe una paridad no oficial entre los salarios cada vez menores de la clase media y el esfuerzo que los ingenieros de software ponen en sus trabajos.

Nunca he trabajado en un lugar que promoviera la programación de pares “reales”. De hecho, nunca trabajé en un lugar que adoptara el desarrollo ágil al 100%, pero mi posición actual ha tenido la mayor aceptación en esa área. He estado incorporando métodos ágiles en mi programación durante muchos años, pero siempre tuve que, bueno, esconderse es una palabra demasiado fuerte, digamos que no enfatice fuera del equipo.

Soy uno de los más veteranos en mi puesto actual y, por lo tanto, ocasionalmente tenemos situaciones en las que uno de los programadores junior se ha encontrado con un problema y me siento con ellos y los ayudo a superar el problema. No estoy realmente seguro de que esto califique como “programación de pares”, ya que a menudo es más un proceso de estrategia o un proceso de tutoría (¿cuáles son las otras formas en que podrían ver el problema? ¿Están utilizando la solución correcta? ¿Por qué estoy obteniendo este mensaje de error, etc.)

Una buena configuración que tenemos es que los gerentes de proyectos (es una startup, por lo que el gerente de proyectos también es un programador) tienen un monitor adicional que refleja su monitor principal con un teclado y mouse adicionales. A menudo nos metemos en discusiones de diseño o resolvemos problemas de codificación de esta manera, donde el principal determina qué sucede en ese monitor adicional y la persona en ese monitor puede saltar con el teclado y el mouse cuando sea necesario. Esto me parece más como programación de pares, pero se hace completamente ad-hoc (y no todos tienen esta configuración, de hecho, principalmente teletrabajo) y por períodos relativamente cortos de tiempo.

Para el teletrabajo, utilizamos una aplicación para compartir pantalla (diseñada para teleconferencias) para que podamos mostrarle a otra persona lo que estamos haciendo y se les puede dar el teclado y el mouse si es necesario. Esto parece una luz de programación en pareja (el nivel de colaboración es definitivamente menor que lo que sucede como se indicó anteriormente, sin expresiones faciales, sin pizarra).

Raramente ha funcionado en situaciones en las que soy yo quien maneja el teclado y el mouse y un programador junior solo está mirando. Tiendo a avanzar demasiado rápido a través del proyecto, arreglando algo aquí, refactorizando algo allí, y tienden a confundirse o aburrirse ya que no pueden mantenerse al día con lo que está sucediendo, lo que hace que sea muy difícil para ellos tener entrada en el proceso.

Francamente, no puedo entender hacer programación de pares todo el día todos los días.

En mi carrera, la mayoría de mis puestos pasados ​​no incluían emparejamiento en absoluto, o algún emparejamiento ocasional, pero no una práctica regular.

Tradicionalmente, lo que veo suceder es esto: la persona que tiene la idea toma el teclado y el mouse y comienza a funcionar. La segunda persona se sienta allí y observa e intenta mantenerse al día. Esta es la trampa que mata la programación de pares para la mayoría de las personas. Usted tiene una persona (generalmente la más experimentada de las dos) que lidera, y la otra persona se pierde lentamente. Esto tiende a generar mucha frustración y un final bastante rápido para el emparejamiento.

Sugiero probar algo llamado “emparejamiento de estilo fuerte”, descrito en un gran artículo de blog de Llewellyn Falco: La forma en que funcionan las cosas en el mundo de Llewellyn. Piense en esto como una inversión de control para la programación de pares. La persona con la idea se convierte en el navegador, y la segunda persona es el conductor (el que tiene el teclado y el mouse). Para que se pueda escribir cualquier código, el navegador tiene que decirle al conductor qué hacer. Esto obliga al navegador a desarrollar más plenamente sus ideas para articularlas con su compañero. Funciona fenomenalmente bien y tiende a elevar el nivel de habilidad de los miembros de su equipo.

Mi compañía actual lleva la programación de pares al extremo: practicamos lo que se llama “programación de la mafia”. Ocasionalmente nos emparejamos, pero durante la gran mayoría de las veces, tenemos al menos 3 personas trabajando en una máquina. Siempre trabajamos en el paradigma de “estilo fuerte”: el controlador es un medio para escribir el código. El resto del grupo sirve como navegadores. Tomamos turnos en el teclado como controlador, y utilizamos un temporizador de código abierto multiplataforma (MobProgramming / MobTimer.Python) para mantener las cosas girando regularmente. Si tienes curiosidad, recientemente tomamos un video de un día típico de mobbing en mi edificio.

No estoy diciendo que deberías intentar acosarte … Eso no es para todos, y puede ser una gran batalla cuesta arriba. Sin embargo, si su empresa apoya el emparejamiento, le recomiendo que pruebe el emparejamiento de estilo fuerte. Si no te gusta después de una o dos semanas, siempre puedes tirarlo … Pero descubrí que la mayoría considera que este es un método mucho más útil y efectivo.

¡Mucha suerte en tus aventuras de programación!

He realizado programación de pares y programación de la mafia con una variedad de desarrolladores, nuevos y experimentados. Es genial, siempre y cuando estés haciendo algo lo suficientemente complejo. Creo que es un gran uso de tiempo y dinero para la organización, ya que mantiene el código sin silos y realmente puede mantener un gran impulso. Recomiendo leer libros / artículos o ver videos de Woody Zuill en la programación de la mafia. Tiene excelentes consejos y una larga línea de razonamiento sobre por qué funciona el emparejamiento / mobbing. Creo que lo más importante que debes recordar es ser amable y flexible. También creo que cambiar de mecanógrafa cada 15-30 minutos es esencial para tener éxito. Eso y algunas reglas simples, sin teléfonos, otras computadoras abiertas o cualquier otra distracción mientras lo hacen para que las personas se mantengan enfocadas. Una vez que te pongas en práctica, ¡puedes producir un montón de código de alta calidad y bien entendido!

Nunca lo he hecho. Conocí a un tipo joven cuyo equipo lo hizo, y hablé con él un poco sobre eso, y él lo juró, así que no lo golpearía sin intentarlo.

Aunque sospecho que me daría ganas de arrancarme el pelo, porque aprendí que uso las computadoras mucho más rápido que la mayoría de las personas, incluida la gran mayoría de mis compañeros, y ver a otras personas usarlas tan lentamente me da una migraña. .

Cuando tengo que ver a un programador escribir lentamente lo incorrecto y no darme cuenta hasta que hayan terminado porque son cazadores y picoteadores, me dan ganas de golpear una pared.

Nunca he visto la programación de pares utilizada en ninguno de mis lugares de trabajo: los grupos en Microsoft, Amazon, Google y Oracle son más relevantes para los lectores aquí.

He hablado con algunas personas que usaron programación de pares, generalmente en el primer año o dos de su carrera. Su respuesta fue generalmente positiva. Sería interesante escuchar la impresión de ingenieros superiores que han realizado programación de pares.

No sistemáticamente Paso gran parte de mi tiempo programando solo. Cuando trabajo directamente con mis colegas, generalmente hacemos matemáticas o planificación de alto nivel; nuestra herramienta de colaboración preferida es la pizarra, no la computadora.

Paro programas ocasionalmente y cuando lo hago es increíblemente útil. Un par adicional de ojos realmente puede superar las dificultades técnicas, y la programación de pares es una de las mejores formas de enseñar o aprender. Y a veces solo tengo ganas de trabajar con alguien más por un tiempo.

Pero no es algo que quisiera hacer todo el tiempo . Se necesita mucha energía y la dinámica hace que sea difícil detenerse y pensar o salir en tangentes extrañas. Requiere demasiado enfoque. Esto puede ser excelente para algunas personas y algunos proyectos, pero no siempre funciona para mí, especialmente porque tengo la suerte de estar haciendo un trabajo de investigación relativamente abierto.

Según los estándares de las compañías de las que he oído hablar (Pivotal me viene a la mente) Básicamente no estoy haciendo programación de pares. Y estoy bien con eso.

Hacemos con frecuencia en el lugar donde trabajo. Diseñamos y fabricamos dispositivos embebidos y los ingenieros que escriben software comúnmente trabajan con otro en su proyecto. Funciona bien para detectar errores y tener más de una mente viendo cómo se puede hacer algo.

Igual que Vladislav Zorov. Formalmente no, ad-hoc sí.

No hay una política con respecto a la programación de pares ni nada, y cuando sucede algo como la programación de pares es bastante raro, pero, por ejemplo, algunas personas estaban trabajando recientemente en un gran refactor de nuestras bibliotecas centrales por consideraciones multiplataforma y esencialmente hicieron programación de pares durante ese refactor.

No en este Trabajo a distancia para mi trabajo diario y contrato para mi trabajo nocturno.

Hacemos revisiones de código todo el tiempo, pero no hay programación de pares.

Tampoco creo que la programación de pares sea de gran valor en la mayoría de los casos. Para cosas complejas y para tratar de resolver grandes problemas, he llevado al equipo a una sala y he lanzado código en un monitor para colaboración, pero esto es raro.

Como parte de una rutina normal, creo que la programación de pares es una pérdida de tiempo y esfuerzo, además de capacitar a nuevos desarrolladores, nuestro intento conjunto de resolver problemas complicados.

Si. Hago mucho “real” programación de pares en el trabajo. Es bueno emparejarse con alguien que es talentoso y paciente para explicar partes y piezas; Sin embargo, este no es el caso la mayor parte del tiempo.

Tengo mala experiencia en el emparejamiento con desarrolladores que siempre quieren tomar el control total del teclado, y a veces ni siquiera sé lo que están haciendo y dónde están, por lo que descubro que no aprendo mucho del emparejamiento.

Así que supongo que realmente depende de la actitud de la persona con la que te emparejas.

Si. Pero de ninguna manera es obligatorio. Emparejamos el programa porque nos gusta. La retroalimentación de un desarrollador a otro es muy útil. La programación de pares no se nos impone, pero tenemos un trabajo en equipo tan bueno que simplemente sucede de forma natural. Tenemos un tipo que es mejor en bases de datos, uno que es mejor en JavaScript y yo que es mejor en back-end y ASP / Razor. Todos somos desarrolladores full stack.

Aprovechamos los conocimientos de los demás en la programación de pares, nadie intenta uno al otro, lo que fomenta la programación de pares en primer lugar. Admito que si no tuviéramos este tipo de química, entonces puedo ver cómo la programación de pares sería más un obstáculo y un amplificador.

En última instancia, siempre que la programación de pares no sea algo terrible que se imponga, entonces es algo bueno.

No oficialmente, solo de manera ad-hoc para las transferencias de conocimiento y cuando es hora de integrar el código (es bastante increíble tener a la persona que escribió el programa de pares de módulos con usted cuando comienza a usarlo).