¿Cómo puede lograr y mantener el flujo mientras programa la pareja?

Flow es un concepto introducido por Mihaly Csikszentmihalyi; en resumen, significa entrar en la "zona". Te sientes inmerso en tu tarea, concentrado; La tarea puede ser difícil pero desafiante al mismo tiempo. Cuando las personas alcanzan el flujo, su productividad se dispara. La programación requiere una gran cantidad de enfoque mental porque a menudo necesitamos hacer malabares con varias cosas en nuestras mentes a la vez. A muchos les gusta trabajar en un ambiente tranquilo donde pueden dirigir toda su atención a la tarea. Si se interrumpen, puede llevar varios minutos o incluso horas volver a fluir.

Entiendo que hay una práctica en desarrollo ágil y programación extrema llamada programación de pares. Significa que pone a todo el equipo de desarrollo de software en una habitación para que la comunicación sea fluida. Escribes código con tu par porque de esta manera obtienes revisiones de código instantáneas y menos errores pasan.

Siempre he tenido problemas para lograr el flujo al hacer programación de pares debido a interrupciones constantes. Estoy pensando profundamente en un problema y de repente alguien me hace una pregunta de otro par. Mi tren de pensamiento está perdido.

¿Cómo puede lograr y mantener el flujo mientras programa la pareja?

Editar: Descargo de responsabilidad: así es como yo defino "la zona": A state of extreme focus, in which one is able to understand how many intricate details connect together, regardless of whether these do so elegantly (or simply) or not.

Intento evitar este estado porque, si bien puedo producir el código correcto en la zona, a mí y a otros desarrolladores nos costará entenderlo más adelante. En pocas palabras: leer el código escrito en la zona a menudo puede requerir que el lector esté en la zona. Esa restricción es mi problema.

Hay un capítulo encantador en The Clean Coder donde el tío Bob explica persuasivamente por qué "entrar en la zona" es una idea delirantemente mala.

Aquí hay una alternativa posiblemente mejor que "entrar en la zona": piense con claridad y considere con calma y profesionalidad lo que está haciendo. Comunicar. Comparta pensamientos con su (s) pareja (s). Identifica los problemas reales. Discuta posibles soluciones. Es posible que no se sienta enfocado de manera sobrenatural, pero es probable que tome buenas decisiones y diseños accesibles.

Si usted y su pareja pueden discutir el problema sin que ambos estén extremadamente concentrados, entonces es probable que haya reducido el problema a su naturaleza más simple. Eso sugiere que podrás comprenderlo nuevamente cuando lo necesites.

Por otro lado ... Si solo necesita un poco de tiempo solo para aclarar la cabeza (todos lo hacemos a veces), tómelo. Pon tus pensamientos juntos. Primero resuelve el problema en tu cabeza.

Pero la cuestión es que si lo hace, no use ese tiempo para escribir código de producción. En cambio, juegue con código de muestra y prototipos. Intente comprender el problema, sin pensar en soluciones todavía. Una vez que tenga todo claro y escrito, discútalo con su equipo y su pareja, o incluso con el pato de goma en su escritorio. Si aún no puede articularlo, o ellos no pueden entenderlo, refine sus ideas. Una vez que haya aclarado todo eso, integre todo ese pensamiento y código de muestra en una solución real y funcional.

La programación en pareja a veces requiere períodos de aislamiento de su pareja.

Ejemplo

Están trabajando juntos en una clase en particular, y se dan cuenta de que necesitan escribir un método que requiera una reflexión profunda sobre una lógica compleja, pero que, de lo contrario, arroje un resultado mundano. Trabajan juntos para crear pruebas unitarias para ese método y difieren la escritura de ese método a un período de tiempo en el que trabajen de forma aislada. Cuando se completa el método, vuelven a estar juntos y evalúan los resultados.

Descubrí que hay una pequeña clase de problemas para los que funciona la programación de pares. Por ejemplo, si está trabajando en un producto multiplataforma y el tipo Winders ha implementado una función que requiere un código específico del sistema operativo, puede ayudar al tipo Mac a implementar la misma función en el código Mac mientras el tipo Mac conduce.

Sin embargo, en mi experiencia, la programación de pares resulta inusualmente en una pérdida neta de productividad. Muy a menudo parece que estamos pagando a dos desarrolladores para que hagan el trabajo de uno.

Sí, reduce la horrible posibilidad de que un desarrollador tome un descanso de intercambio de pila durante la jornada laboral.

En mi humilde opinión, sería más barato para aquellas compañías que quieren vigilar a sus desarrolladores simplemente emparejar a cada desarrollador con un guardia de seguridad privado para respaldar al desarrollador y golpear al desarrollador con una porra si alguna vez se ralentiza o trata de alcanzar un pico no esencial página web.

Como desarrollador que intenta ingresar a la zona, intentará aislarse lo mejor que pueda para sentirse cómodo y despejar su mente. ¿Por qué la programación de pares debería ser diferente?

Usted y su pareja deben encontrar un entorno que induzca zonas que funcione para ambos. Esto posiblemente requerirá un compromiso en algunas cosas, pero mi punto principal es que el entorno de pareja debería ser similar al solo. Apaga el mundo externo. El par está programando juntos; otros pares (otros compañeros de trabajo en general) no deberían interrumpir (excepto los problemas críticos de dejar lo que estás haciendo).

Flow es un excelente estado cuando conoce los pasos exactos para resolver un problema. es decir, pocas incógnitas desconocidas. Te sientas en un rincón tranquilo y discutes la solución. Sin embargo, la mayoría de los problemas / historias / características no son muy claras cuando comienzas a programarlas. Siempre habrá una "brecha" entre el estado final esperado y cómo su cerebro lo "planeó". Aprendes muchas cosas cuando realmente "lo haces". Tu cerebro hace malabares

• Diseño de código

• Mecanografía

• Aprender cosas nuevas sobre el dominio y el código.

Cuando programo solo, lucho por equilibrar estas cosas. Tiendo a meterme en "agujeros de conejos" donde mi falacia de costo hundido me impide dar un paso atrás y mirar el panorama general y cambiar mi diseño. También es difícil para mí hablar con un pato de goma imaginario o uno real para el caso. Después de todo, estoy en "flujo".

Sin embargo, cuando emparejo productivamente la programación, obtengo períodos alternativos de escritura seguidos de períodos de pensamiento y reflexión. Aquí es donde se revelan muchas cosas ocultas y puede surgir un diseño diferente. Si voy a una madriguera de conejos, mi pareja puede sacarme de ella. Hablar / explicarle algo a un ser humano real tiene el maravilloso efecto de aclarar tus pensamientos de alguna manera. A veces, extraño estar en el "flujo", pero creo que contribuyo mucho más a mi equipo cuando emparejo el programa que cuando programo solo. Después de toda la programación! = Escribiendo. La programación ocurre en el cerebro y una mejor programación ocurre cuando dos cerebros colaboran y se critican entre sí.