Por qué la codificación colaborativa es el truco profesional definitivo

Dar los primeros pasos en la programación es como aprender un idioma extranjero. Al principio, la sintaxis no tiene sentido, el vocabulario no es familiar y todo parece y suena ininteligible. Si eres como yo cuando empecé, la fluidez se siente imposible.

Te prometo que no lo es. Cuando comencé a codificar, la curva de aprendizaje me golpeó, duro. Pasé diez meses enseñándome los conceptos básicos mientras trataba de evitar los sentimientos de duda que ahora reconozco como el síndrome del impostor. No fue hasta que comencé a asistir a reuniones para principiantes que me di cuenta de cómo la codificación colaborativa abre posibilidades increíbles. Solo necesitas la comunidad adecuada de personas con las que practicar.

Para mí, esa comunidad era Founders and Coders, el bootcamp gratuito de JavaScript que me ayudó a cambiar mi carrera de redacción a codificación. Incluso ahora, menos de un año después de completar el curso, apenas puedo creer que me paguen por desarrollar software.

La codificación colaborativa tiene que ver con abordar problemas y descubrir soluciones juntos. Abarca técnicas como la programación en pareja, que varias empresas de tecnología se toman lo suficientemente en serio como para detectar durante sus procesos de entrevista. También cultiva habilidades útiles que son difíciles de aprender si todo lo que haces es programar solo en casa.

Ya sea que esté comenzando en la industria de la tecnología o tenga varios años de experiencia en su haber, la codificación colaborativa nunca deja de ser útil. En este artículo, veremos cómo estas habilidades perennes lo equipan para una carrera larga y exitosa en el desarrollo de software.

Maridaje perfecto

Mi primera experiencia con la programación en pareja fue en una reunión para principiantes llamada Coding For Everyone. Así es como funciona: las personas se emparejan, a menudo con personas que nunca han conocido, para resolver desafíos de JavaScript juntos en la misma computadora portátil. Una persona asume el papel de 'navegador' y propone el código que cree que debería escribirse. La otra persona, el 'conductor', escribe sus sugerencias en la computadora portátil y hace preguntas cuando algo no está claro. Continúa haciendo esto, intercambiando roles con frecuencia, hasta el final de la sesión de dos horas.

En teoría, era simple. En la práctica, no tanto.

Me distraía bastante tener a alguien que no conocía mirando mi pantalla mientras escribía, y me resistía a ceder el control cuando era el momento de intercambiar roles. Encontré navegar aún más complicado. Cuando una idea no puede pasar de tu cabeza a la computadora sin pasar primero por las manos de tu pareja, cada palabra que dices importa. Exigió un grado de comunicación de ambos al que simplemente no estábamos acostumbrados, y estaba seguro de que ambos aprenderíamos más si nos separáramos para trabajar por separado.

Afortunadamente, nos quedamos con eso; Fui de nuevo a la reunión la semana siguiente. Desde entonces, he pasado cientos de horas emparejando con docenas de desarrolladores y he aprendido más de lo que inicialmente pensé posible.

La programación en pareja es una forma increíblemente rápida de aprender. La magia del método, una vez que superas la incomodidad inicial, es que produce resultados inmediatos. Algunos bucles de retroalimentación, como las burbujas en el mercado de valores, pueden tardar horas, días o incluso meses en producir una corrección. La programación de pares toma minutos, si no segundos. Cuando pierde un punto y coma, dos pares de ojos pueden detectar el error más rápido que uno. ¿Necesita buscar en StackOverflow pistas sobre un mensaje de error falso? Tú y tu pareja pueden leer hilos diferentes, reduciendo a la mitad el tiempo que lleva encontrar una respuesta.

Para problemas aún más complicados, la programación mafiosa puede ser un paso más adelante. Este método requiere que una sección multifuncional de un equipo se reúna alrededor de la misma pantalla de la computadora y genere una lluvia de ideas sobre soluciones en tiempo real mientras una persona escribe.

“Todas las mentes brillantes trabajando en lo mismo, al mismo tiempo, en el mismo espacio, en la misma computadora”.

— Woody Zuill, Entrenador Agile y Entrenador de Programación Mob

Si bien puede parecer una forma ineficiente de trabajar, los defensores de la programación mafiosa como Woody Zuill dicen que en realidad puede ahorrar tiempo al eliminar la necesidad de revisiones de código individuales porque todos revisan el código en tiempo real mientras se escribe. Dejando de lado la productividad, creo que el mobbing es una forma fantástica de aprender no solo sobre el código, sino también sobre cómo otras personas abordan los problemas. Si la programación en pareja duplica la cantidad de perspectivas a las que está expuesto, la programación en masa produce aún más información.

Eso no quiere decir que el emparejamiento, o de hecho el mobbing, sea un camino de rosas. Algo con lo que luché inicialmente fue dejar mi ego a un lado para hacer preguntas que pensé que podrían sonar estúpidas. En estas situaciones, es bueno recordar que su pareja podría tener los mismos pensamientos, especialmente si ambos están comenzando.

Si te encuentras emparejado con alguien de mayor rango, tal vez en el trabajo, no tengas miedo de tocar su cerebro e impresionarlo con tu curiosidad. Incluso alguien que está un poco más adelantado de lo que usted podría pensar en cosas que no se le ocurrirían a alguien de mayor rango. Algunos de mis programadores favoritos solo tienen unos meses más de experiencia que yo, pero siempre parecen saber exactamente qué errores estoy a punto de cometer y cómo guiarme en la dirección correcta. Cuando estos desarrolladores dicen que no existen las preguntas tontas, lo dicen en serio. Los mejores programadores en pareja hablan con libertad, sin necesidad de parecer fantásticos ni miedo a parecer tontos.

La programación en pareja requiere práctica, pero vale la pena perfeccionarla. Los estudios muestran que los programadores que se emparejan para resolver problemas tienden a ser más seguros, productivos y comprometidos con su trabajo. Ya sea que esté buscando su próximo trabajo o esté incorporando nuevos empleados, el emparejamiento es solidario.

Recursos y lecturas adicionales

• "Roles de programación de pares", Jordan Poulton, GitHub
• “La amistad que hizo grande a Google”, James Somers, The New Yorker
• “Programación de la mafia: un enfoque de equipo completo”, Woody Zuill, YouTube

Empatía de ingeniería

Cuando comencé a enseñarme JavaScript, mi código se parecía mucho al piso de mi habitación: lo dejaba más y más desordenado hasta que no tuve más remedio que ordenarlo. Mientras mi navegador web pudiera entenderlo, no me importaba cómo se veía.

No fue hasta que comencé a revisar el código de otras personas que me di cuenta de que necesitaba mostrar mucha más empatía por las personas que revisaban el mío.

La empatía podría ser la herramienta más subestimada en el arsenal de cualquier desarrollador. Es la razón por la que IDEO pone la investigación de los usuarios en el centro de su proceso de diseño y por la que Etsy les pide a sus diseñadores y gerentes de producto que hagan una rotación de ingeniería. La empatía surge cuando tenemos la oportunidad de ver cómo nuestro trabajo impacta a otras personas. No es de extrañar que la codificación colaborativa sea una excelente manera de desarrollarla.

La revisión del código entre pares, el acto de verificar el código de los demás en busca de errores, nos llama a ejercer la empatía. Como revisor, es importante reconocer que alguien ha realizado un esfuerzo considerable para escribir el código que está a punto de criticar. Por lo tanto, trate de evitar el uso de frases que puedan implicar un juicio o trivializar su trabajo. Cuando hace referencia a su código, desea mostrarles las funciones y líneas específicas sobre las que tiene preguntas, y sugerir cómo podrían refactorizarlo. Compartir recursos de aprendizaje también puede ser más útil que dar de comer una solución. Algunos de los comentarios más útiles que he recibido de las revisiones de código han llegado en forma de artículos educativos, videos e incluso recomendaciones de podcasts.

Escribir una buena documentación para su código también es muy útil. Un acto tan simple como crear un archivo Léame con instrucciones de instalación claras muestra empatía por cualquier persona que necesite trabajar con su código. El fundador de GitHub, Tom Preston-Werner, aboga por un enfoque de desarrollo basado en Léame primero.

“Una implementación perfecta de la especificación incorrecta no vale nada. Por el mismo principio, una biblioteca bellamente diseñada sin documentación también es casi inútil. Si su software resuelve el problema equivocado o nadie puede descubrir cómo usarlo, algo muy malo está pasando”.

— Tom Preston-Werner, fundador de GitHub

También hablé con fundadores de tecnología que tratan la documentación como una parte esencial de una incorporación exitosa. Un CTO dijo que si un desarrollador junior tiene dificultades para alcanzar un nivel de productividad dentro de los seis meses posteriores a unirse a su equipo, indica que la base de código no está lo suficientemente bien documentada. Solo toma unos segundos agregar un comentario explicativo a una función compleja que ha escrito, pero podría ahorrarle horas de esfuerzo a la próxima persona que se una a su equipo.

Recursos y lecturas adicionales

• "Sobre la empatía y las solicitudes de incorporación de cambios", Slack Engineering, Medium
• "Desarrollo impulsado por Léame", Tom Preston-Werner, GitHub
• "Lo que Google aprendió de su búsqueda para construir el equipo perfecto", Charles Duhigg, The New York Times Magazine

Logro ágil

Desde los millones de horas-hombre que se dedican a hacer películas CGI hasta los intensos crujidos de desarrollo que conducen a los lanzamientos de videojuegos de gran presupuesto, los logros técnicos imponentes requieren una cantidad de esfuerzo alucinante. La primera vez que vi el código base de mi empleador actual, me quedé anonadado por la enormidad de todo. ¿Cómo diablos alguien construyó esto?

La respuesta es que todo el mundo puede construir mucho más que nadie , con el marco de colaboración adecuado. En las empresas que fomentan la codificación colaborativa, el software no surge de los esfuerzos de un genio solitario. En cambio, hay formas de trabajar juntos que ayudan a los grandes equipos a hacer un trabajo increíble. Los desarrolladores de Founders and Coders practican una metodología popular de desarrollo de software conocida como 'Agile' y, según mi experiencia, coloca lo 'funcional' en equipos de desarrollo multifuncionales.

Se han escrito libros completos sobre Agile, pero aquí hay un resumen de los conceptos básicos:

• Un equipo de desarrollo de productos divide grandes piezas de trabajo en pequeñas unidades llamadas "historias de usuarios", las prioriza y las entrega en ciclos de dos semanas llamados "sprints".
• Mientras el proyecto continúa, los ciclos se repiten y los nuevos requisitos del producto se incorporan a una acumulación de tareas para futuros sprints.
• El equipo realiza reuniones diarias de pie para discutir su progreso y abordar cualquier bloqueo.
• El proceso es tanto incremental como iterativo: el software se crea y entrega en partes y se refina en sprints sucesivos.

Como un manitas crónico cuyos proyectos de pasatiempos en solitario a menudo sucumben a la 'función progresiva', sé lo fácil que es perder el tiempo construyendo las cosas que nadie usa nunca. Me encanta la forma en que Agile lo obliga a priorizar las historias de los usuarios para que todo el equipo pueda concentrarse en brindar funciones que realmente les interesan a sus usuarios. Es motivador saber que todos están unidos en torno al objetivo común de crear un producto o servicio que seguirá teniendo vida después de que termine de trabajar en él.

Dividir las tareas en pequeñas historias de usuario también resulta ser una excelente manera de sincronizar las sesiones de programación en pares. No importa qué tan profundo se encuentre en la zona, terminar el trabajo en una característica clave siempre es un buen recordatorio para alejarse de sus escritorios y tomar un descanso. Agile brinda estructura a la codificación colaborativa donde de otro modo podría faltar.

Mientras tanto, los standups diarios te dan la libertad de hablar sobre cualquier cosa que te esté frenando, y las retrospectivas de sprint brindan espacio para compartir victorias clave y señalar dónde podría mejorar el equipo. Estas ceremonias fomentan un sentido de colaboración y responsabilidad, y nos ayudan a aprender más juntos de lo que podríamos aprender solos.

Poner en práctica todos estos principios ágiles puede ser un desafío, especialmente cuando nadie en un equipo está acostumbrado a esta forma de trabajar. En Founders and Coders, a la mayoría de los estudiantes les toma un tiempo adquirir el hábito de hacer standups diarios. Sin embargo, después de 18 semanas de práctica basada en proyectos, descubre que sus procesos y habilidades de comunicación mejoran enormemente. Para cuando asuma su primer trabajo con el cliente, habrá formado un modelo mental mucho más claro de cómo abordar la creación de una aplicación web de pila completa en un equipo.

La mejor manera de aprender Agile es construir proyectos interesantes con otras personas. Asistir a hackatones es una excelente manera de conectarse con posibles colaboradores. Muchos proyectos de código abierto hacen públicos sus tableros de proyectos kanban, para que pueda ver en qué problemas de GitHub están trabajando los diferentes colaboradores. Varias contribuciones bienvenidas de principiantes y, a menudo, puede asignarse a problemas abiertos y comenzar a generar solicitudes de extracción.

Dado que la mayoría de las empresas de tecnología se suscriben a alguna forma de Agile, no es raro que los empleadores pregunten al respecto en las entrevistas. Cualquier experiencia que tenga puede diferenciarlo de otros solicitantes que quizás nunca hayan codificado en colaboración, y mucho menos con Agile en mente.

Recursos y lecturas adicionales

• “¿Qué es Agile?”, Steve Denning, Forbes
• "Adoptando Agile", Darrell K. Rigby, Jeff Sutherland, Hirotaka Takeuchi, Harvard Business Review
• "Impresionantes oportunidades de primera solicitud de extracción", Shmavon Gazanchyan, Deloitte Digital

Recomendaciones de la herramienta de codificación colaborativa remota

En los últimos años, las herramientas de trabajo remoto han avanzado hasta el punto de que empresas destacadas como Gatsby y Zapier ahora son "primero remoto". Si bien queda por ver si esto se convertirá en una tendencia, es seguro decir que los equipos de desarrollo remoto llegaron para quedarse.

Con ese espíritu, aquí hay algunas herramientas que pueden ayudarlo a usted y a su equipo a codificar en colaboración desde lejos:

Si le quita algo a la lectura de este artículo, quiero que sea que los jugadores de equipo superan a los contribuyentes individuales. En un campo en el que parece haber un nuevo marco atractivo para dominar cada dos semanas, nuestras habilidades técnicas envejecen de una manera que no lo hacen nuestras habilidades interpersonales. El resultado es que los desarrolladores que pueden trabajar bien con otras personas siempre encontrarán demanda de sus habilidades. La codificación colaborativa no es solo una forma efectiva de aprender; es un conjunto de habilidades buscado que cualquiera puede desarrollar con suficiente práctica y paciencia.