Equipos de depuración

Capítulo 1. El mito del programador genio

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Puesto que éste es un libro sobre los peligros sociales del desarrollo creativo, tiene sentido centrarse en la única variable sobre la que definitivamente tienes control: tú.

Las personas son intrínsecamente imperfectas. Pero antes de que puedas entender los defectos de tus compañeros de trabajo, tienes que entender los defectos de ti mismo. Vamos a pedirte que reflexiones sobre tus propias reacciones, comportamientos y actitudes y, a cambio, esperamos que obtengas una visión real de cómo convertirte en un ingeniero de software más eficiente y con más éxito. Acabarás dedicando menos energía a lidiar con los problemas relacionados con las personas y más tiempo a escribir un código excelente.

La idea fundamental de este capítulo es comprender que el desarrollo de software es un deporte de equipo. Y para tener éxito en un equipo de ingeniería -o en cualquier otra colaboración creativa- tienes que reorganizar tus comportamientos en torno a los principios básicos de humildad, respeto y confianza.

Antes de adelantarnos, empecemos por observar cómo se comportan los programadores en general.

Ayúdame a ocultar mi código

Los dos hemos hablado bastante en conferencias de programación durante los últimos diez años. Tras lanzar el servicio de código abierto Project Hosting de Google en 2006, solíamos recibir muchas preguntas y peticiones sobre el producto. A mediados de 2008, observamos una tendencia distintiva en el tipo de solicitudes que recibíamos:

¿Podéis, por favor, dar a Subversion en Google Code la capacidad de ocultar ramas específicas?

¿Podéis hacer posible la creación de proyectos de código abierto que comiencen ocultos al mundo y luego se revelen cuando estén listos?

Hola, quiero reescribir todo mi código desde cero, ¿puedes por favor borrar todo el historial?

¿Puedes detectar un tema común en estas peticiones?

La respuesta es la inseguridad. La gente tiene miedo de que los demás vean y juzguen su trabajo en curso. En cierto sentido, forma parte de la naturaleza humana: a nadie le gusta que le critiquen, sobre todo por cosas que no están acabadas. Esta actitud nos puso sobre aviso de una tendencia en el desarrollo de software. La inseguridad es en realidad el síntoma de un problema mayor.

El mito del genio

Los dos vivimos en Chicago durante la década de 1990 y fuimos testigos de la increíble racha de victorias de los Chicago Bulls en los campeonatos. Los medios de comunicación nacionales estuvieron saturados durante años de historias sobre este asombroso equipo de baloncesto. Pero, ¿en qué se centraban realmente la televisión y los periódicos? No tanto en el equipo, sino en Michael Jordan, la superestrella. Todos los jugadores del mundo querían ser MJ. Le veíamos bailar en círculos alrededor de otros jugadores. Le veíamos en anuncios de televisión. Íbamos a ver películas tontas en las que jugaba al baloncesto con personajes de dibujos animados. Era una estrella, y todos los niños de todas las canchas que practicaban baloncesto deseaban en secreto crecer y seguir su camino.

Muchos humanos tienen el instinto de encontrar y adorar ídolos. Para los ingenieros de software podrían ser Linus Torvalds, Guido Van Rossum, Bill Gates... todos ellos héroes que cambiaron el mundo con hazañas heroicas. Linus escribió Linux él solo, ¿verdad?

En realidad, lo que Linus hizo fue escribir sólo los inicios de un núcleo de prueba de concepto similar a Unix, y mostrarlo a una lista de correo electrónico. No fue un logro pequeño, y sin duda fue un logro impresionante, pero no era más que la punta del iceberg. Linux es cientos de veces mayor que eso y fue desarrollado por miles de personas inteligentes. El verdadero logro de Linus fue dirigir a esas personas y coordinar su trabajo; Linux es el brillante resultado no de su idea original, sino del trabajo colectivo de la comunidad. (Y el propio Unix no fue escrito enteramente por Ken Thompson y Dennis Ritchie, sino por un grupo de personas inteligentes de los Laboratorios Bell).

En ese mismo sentido, ¿escribió Guido Van Rossum personalmente todo Python? Ciertamente, escribió la primera versión. Pero cientos de otras personas contribuyeron a las versiones posteriores, aportando ideas, características y correcciones de errores. Steve Jobs dirigió todo un equipo que construyó el Macintosh, y aunque Bill Gates es conocido por escribir un intérprete BASIC para los primeros ordenadores domésticos, su mayor logro fue construir una empresa de éxito en torno a MS-DOS. Sin embargo, todos ellos se convirtieron en líderes y símbolos de los logros colectivos de sus comunidades. El Mito del Genio es la tendencia que tenemos los seres humanos a atribuir el éxito de un equipo a una sola persona/líder.

¿Y qué me dices de Michael Jordan?

Es la misma historia. Le idolatramos, pero lo cierto es que no ganaba todos los partidos de baloncesto él solo. Su verdadero genio estaba en la forma en que trabajaba con su equipo. El entrenador del equipo, Phil Jackson, era extremadamente inteligente -sustécnicas de entrenamiento son legendarias-: reconocía que un jugador solo nunca gana un campeonato, así que reunió a todo un "dream team" en torno a MJ. El equipo era una máquina bien engrasada, al menos tan impresionante como el propio Michael.

Entonces, ¿por qué idolatramos repetidamente al individuo de estas historias? ¿Por qué la gente compra productos respaldados por famosos? ¿Por qué queremos comprar el vestido de Michelle Obama o las zapatillas de Michael Jordan?

La celebridad es una gran parte de ello. Los humanos tenemos un instinto natural para localizar líderes y modelos de conducta, idolatrarlos e intentar imitarlos. Todos necesitamos héroes para inspirarnos, y el mundo de la programación también tiene sus héroes. El fenómeno de la "tecno-celebridad" casi se ha extendido a la mitología. Todos queremos escribir algo que cambie el mundo, como Linux, o diseñar el próximo lenguaje de programación brillante.

En el fondo, todos deseamos secretamente ser genios. La máxima fantasía friki es que se te ocurra un nuevo concepto asombroso. Te metes en tu Batcueva durante semanas o meses, trabajando como un esclavo en la implementación perfecta de tu idea. Entonces "liberas" tu software en el mundo, sorprendiendo a todos con tu genialidad. Tus colegas se asombran de tu ingenio. La gente hace cola para utilizar tu programa. La fama y la fortuna llegan de forma natural.

Pero espera: es hora de un baño de realidad. Probablemente no seas un genio.

Sin ánimo de ofender, por supuesto; estamos seguros de que eres un tipo o una tipa muy inteligente. Pero, ¿te das cuenta de lo raros que son los genios de verdad? Claro, escribes código, y esa es una habilidad complicada que probablemente te sitúe en un escalón por encima de gran parte de la población humana. Pero aunque seas un genio, resulta queeso no basta. Los genios siguen cometiendo errores, y tener ideas brillantes y habilidades de programación de élite no garantiza que tu software vaya a ser un éxito. Lo que va a hacer o deshacer tu carrera es lo bien que colabores con los demás.

Resulta que este Mito del Genio no es más que otro aspecto de nuestra inseguridad. La mayoría de los programadores temen compartir el trabajo que acaban de empezar, porque eso significa que sus compañeros verán sus errores y sabrán que el autor del código no es un genio. Citando a un programador del blog de Ben:

Sé que me pongo SERIAMENTE insegura cuando la gente mira antes de hacer algo. Como si fueran a juzgarme seriamente y pensaran que soy idiota.

Es un sentimiento muy común entre los programadores, y la reacción natural es esconderse en una cueva y trabajar, trabajar y trabajar. Nadie verá tus meteduras de pata; aún tienes la oportunidad de desvelar tu obra maestra cuando hayas terminado. Escóndete hasta que todo esté perfecto.

Otra motivación común para mantener tus cartas cerca del pecho es el miedo a que otro programador pueda coger tu idea y correr con ella antes de que tú llegues a trabajar en ella. Manteniéndola en secreto, controlas la idea .

Sabemos lo que probablemente estés pensando ahora: ¿y qué? ¿No debería permitirse a la gente trabajar como quiera?

En realidad, no. En este caso afirmamos que lo estás haciendo mal, y es un gran problema. He aquí por qué.

Ocultarse se considera perjudicial

Si te pasas todo el tiempo trabajando solo, estás aumentandoel riesgo de fracaso y engañando tu potencial de crecimiento.

En primer lugar, ¿cómo sabes siquiera si vas por buen camino?

Imagina que eres un entusiasta del diseño de bicicletas, y un día se te ocurre una idea brillante sobre una forma completamente nueva de diseñar un cambio de marchas. Pides las piezas y te pasas semanas encerrado en tu garaje intentando construir un prototipo. Cuando tu vecino -también defensor de la bicicleta- te pregunta qué pasa, decides no hablar de ello. No quieres que nadie conozca tu proyecto hasta que esté absolutamente perfecto. Pasan otros meses y tienes problemas para hacer que tu prototipo funcione correctamente. Pero como estás trabajando en secreto, es imposible pedir consejo a tus amigos con inclinaciones mecánicas.

Entonces, un día, tu vecino saca su bici del garaje con un nuevo y radical mecanismo de cambio de marchas. Resulta que ha estado construyendo algo muy parecido a tu invento, pero con la ayuda de unos amigos de la tienda de bicicletas. Llegados a este punto, estás exasperado. Le enseñas tu trabajo. Te señala que tu diseño tiene algunos fallos sencillos, que podrían haberse solucionado en la primera semana si se lo hubieras enseñado.

Hay varias lecciones que aprender aquí. Si mantienes tu gran idea oculta al mundo y te niegas a mostrar nada a nadie hasta que la implementación esté pulida, estás corriendo un gran riesgo. Es fácil cometer errores de diseño fundamentales al principio. Te arriesgas a reinventar las ruedas.¹ Y también pierdes los beneficios de la colaboración: ¿te has dado cuenta de cuánto más rápido se movió tu vecino trabajando con otros? Esta es la razón por la que la gente se sumerge en el agua antes de saltar a lo más hondo: necesitas asegurarte de que estás trabajando en lo correcto, de que lo estás haciendo correctamente y de que no se ha hecho antes. Las posibilidades de cometer un error al principio son altas. Cuantos más comentarios solicites desde el principio, más reducirás este riesgo.² Recuerda el mantra de probada eficacia de "Fracasa pronto, fracasa rápido, fracasa a menudo"; más adelante hablaremos en detalle de la importancia del fracaso.

Compartir desde el principio no consiste sólo en evitar errores personales y conseguir que tus ideas sean examinadas. También es importante reforzar lo que llamamos el factor "autobús" de tu proyecto.

Factor autobús (sustantivo): número de personas que tienen que ser atropelladas por un autobús para que tu proyecto esté completamente condenado.

¿Hasta qué punto están dispersos los conocimientos y el saber hacer en tu proyecto? Si eres la única persona que entiende cómo funciona el código del prototipo, puede ser una buena seguridad laboral, pero también significa que el proyecto está frito si te atropella un autobús. Sin embargo, si trabajas con un amigo, habrás duplicado el factor del autobús. Y si tienes un pequeño equipo diseñando y creando prototipos juntos, las cosas son aún mejores: el proyecto no se acabará cuando desaparezca un miembro del equipo. Recuerda: puede que los miembros del equipo no sean literalmente atropellados por autobuses, pero siguen ocurriendo otros acontecimientos imprevisibles de la vida. Alguien puede casarse, tener que mudarse, dejar la empresa o tener que cuidar a un familiar enfermo. Tienes que garantizar el éxito de un proyecto en el futuro gestionando el factor autobús.

Más allá del factor del autobús, está la cuestión del ritmo general de progreso. Es fácil olvidar que trabajar solo suele ser un trabajo duro, mucho más lento de lo que la gente quiere admitir. ¿Cuánto se aprende trabajando solo? ¿A qué velocidad avanzas? La Web es un gran vertedero de opiniones e información, pero no sustituye a la experiencia humana real. Trabajar con otras personas aumenta directamente la sabiduría colectiva que hay detrás del esfuerzo. Cuando te atascas en algo absurdo, ¿cuánto tiempo pierdes sacándote a ti mismo del agujero? Piensa en lo diferente que sería la experiencia si tuvieras un par de compañeros que te miraran por encima del hombro y te dijeran -al instante- cómo has metido la pata y cómo superar el problema. Esta es exactamente la razón por la que los equipos se sientan juntos (o hacen programación por parejas) en las empresas de ingeniería de software: a menudo te encuentras con que necesitas un segundo par de ojos.

He aquí otra analogía de . Piensa en cómo trabajas con tu compilador. Cuando te sientas a escribir una gran pieza de software, ¿te pasas días escribiendo 10.000 líneas de código, y luego, cuando crees que está todo hecho y completamente perfecto, pulsas el botón "compilar" por primera vez? Por supuesto que no. ¿Te imaginas el desastre que se produciría? Los programadores trabajamos mejor en circuitos de retroalimentacióncerrados. Escribe una nueva función, compila. Añade una prueba, compila. Refactoriza algo de código, compila. Arreglamos las erratas y los errores lo antes posible después de generar el código. Queremos que el compilador esté a nuestro lado en cada pequeño paso, haciendo de compinche; algunos entornos pueden incluso compilar nuestro código mientras escribimos. Así mantenemos alta la calidad del código y nos aseguramos de que nuestro software evoluciona correctamente poco a poco.

El mismo tipo de bucle de retroalimentación rápida es necesario no sólo a nivel de código, sino también a nivel de todo el proyecto. Los proyectos ambiciosos evolucionan rápidamente y tienen que adaptarse a entornos cambiantes sobre la marcha. Los proyectos se topan con obstáculos de diseño impredecibles o peligros políticos, o simplemente descubrimos que las cosas no funcionan según lo previsto. Los requisitos cambian inesperadamente. ¿Cómo consigues ese bucle de retroalimentación para saber en el instante en que tus planes o diseños deben cambiar? Respuesta: trabajando en equipo. A menudo se cita a Eric Raymond diciendo: "Muchos ojos hacen que todos los bichos sean superficiales", pero una versión mejor podría ser: "Muchos ojos hacen que tu proyecto siga siendo relevante y esté bien encaminado" La gente que trabaja en cuevas se despierta para descubrir que, aunque su visión original puede estar completa, el mundo ha cambiado y ha hecho que el producto sea irrelevante.

Ingenieros y Oficinas

Hace veinte años, la sabiduría convencional afirmaba que, para ser productiva, una ingeniera necesitaba tener su propio despacho con una puerta que se cerrara. Se suponía que sólo así podría disponer de grandes espacios de tiempo ininterrumpidos para concentrarse a fondo en escribir montones de código.

Creemos que no sólo es innecesario que la mayoría de los ingenieros³ estar en una oficina privada, sino que es peligroso. Hoy en día, el software lo escriben equipos, no individuos, y una conexión de gran ancho de banda y fácilmente disponible con el resto de tu equipo es incluso más valiosa que tu conexión a Internet. Puedes tener todo el tiempo ininterrumpido del mundo, pero si lo utilizas para trabajar en lo que no debes, estás perdiendo el tiempo.

Desgraciadamente, parece que las empresas tecnológicas actuales han llevado el péndulo al extremo opuesto. Si entras en sus oficinas, a menudo encontrarás a los ingenieros agrupados en enormes salas -de 50a 100 personas juntas- sin ningún tipo de paredes. Esta "planta abierta" es ahora un tema de gran debate. La más mínima conversación se hace pública, y la gente acaba por no hablar por riesgo a molestar a decenas de vecinos. ¡Esto es tan malo como las oficinas privadas!

Creemos que el término medio es realmente la mejor solución. Agrupa a equipos de 6 a 12 personas en salas pequeñas (o despachos grandes), para que sea fácil (y no embarazoso) que se produzcan conversaciones espontáneas.

Por supuesto, en cualquier situación, los ingenieros individuales siguen necesitando una forma de filtrar el ruido y las interrupciones, por lo que la mayoría de los equipos que hemos visto han desarrollado una forma de comunicar que en ese momento están ocupados y que debes limitar las interrupciones. Solíamos trabajar en un equipo con un protocolo de interrupción vocal: si querías hablar, decías "punto de interrupción María", donde María era el nombre de la persona con la que querías hablar. Si Mary estaba en un punto en el que podía parar, giraba la silla y escuchaba. Si Mary estaba demasiado ocupada, diría "ack" y tú seguirías con otras cosas hasta que ella terminara con su estado de cabeza actual.

Otros equipos regalan auriculares con cancelación de ruido a los ingenieros para que les resulte más fácil lidiar con el ruido de fondo; de hecho, en muchas empresas el mero hecho de llevar auriculares es una señal habitual que significa "no me molestes a menos que sea realmente importante". Otros equipos tienen fichas o animales de peluche que los miembros del equipo colocan en su monitor para indicar que sólo se les debe interrumpir en caso de emergencia.

No nos malinterpretes: seguimos pensando que los ingenieros necesitan tiempo ininterrumpido para centrarse en escribir código, pero creemos que necesitan igualmente una conexión de gran ancho de banda y baja fricción con su equipo. Encontrar el equilibrio adecuado es un arte.

Así que todo se reduce a lo siguiente: trabajar solo es intrínsecamente más arriesgado que trabajar con otros. Aunque tengas miedo de que alguien te robe la idea o piense que eres tonto, deberías tener mucho más miedo de malgastar grandes cantidades de tu tiempo trabajando en algo equivocado.

Por desgracia, este problema de "agarrarse las ideas al pecho" no es exclusivo de la ingeniería de software, sino que está generalizado en todos los campos. Por ejemplo,se supone que la ciencia profesional consiste en el intercambio libre y abierto de información. Pero la necesidad desesperada de "publicar o perecer" y de competir por las subvenciones ha tenido exactamente el efecto contrario. Los grandes pensadores no comparten ideas. Se aferran a ellas obsesivamente, investigan en privado, ocultan todos los errores del camino y, al final, publican un artículo, haciendo creer que todo el proceso fue fácil y obvio. Y los resultados suelen ser desastrosos: duplicaron accidentalmente el trabajo de otra persona, o cometieron un error no detectado al principio, o produjeron algo que antes era interesante pero que ahora se considera inútil. La cantidad de tiempo y esfuerzo desperdiciados es trágica.

No te conviertas en otra estadística.

Todo es cuestión de equipo

Así que retrocedamos ahora y juntemos todas estas ideas.

Hemos estado insistiendo en que, en el ámbito de la programación, los artesanos solitarios son extremadamente raros, e incluso cuando existen, no realizan logros sobrehumanos en el vacío; sus logros que cambian el mundo son casi siempre el resultado de una chispa de inspiración seguida de un heroico esfuerzo de equipo.

Crear un equipo de superestrellas es el verdadero objetivo, y es diabólicamente difícil. Los mejores equipos hacen un uso brillante de sus superestrellas, pero el todo es siempre mayor que la suma de sus partes.

Pongamos esta idea en palabras más sencillas:

El desarrollo de software es un deporte de equipo.

Este concepto puede resultar difícil al principio, ya que contradice directamente nuestra fantasía interior de Genio Programador. Intenta cantarlo como un mantra.

No basta con ser brillante cuando estás solo en tu guarida de hacker. No vas a cambiar el mundo ni a deleitar a millones de usuarios de ordenadores escondiéndote y preparando tu invento secreto. Necesitas trabajar con otras personas. Comparte tu visión. Divide el trabajo. Aprende de los demás. Crea un equipo brillante.

Piensa en esto: ¿cuántos programas informáticos de éxito y de uso generalizado puedes nombrar que hayan sido escritos realmente por una sola persona? (Algunos dirán "LaTeX", pero difícilmente es "de uso generalizado", a menos que consideres que el número de personas que escriben artículos científicos es una parte estadísticamente significativa de todos los usuarios de ordenadores).

Vamos a repetir este concepto de equipo-deporte una y otra vez a lo largo del libro. Los equipos que funcionan bien son oro y la verdadera clave del éxito. Deberías aspirar a esta experiencia como sea; de eso trata este libro.

Los tres pilares

Así que la cuestión del trabajo en equipo está clara. Si el trabajo en equipo es el mejor camino para producir un gran software, ¿cómo se construye (o se encuentra) un gran equipo?

No es tan sencillo como. Para alcanzar el nirvana colaborativo, primero tienes que aprender y adoptar lo que llamamos los "tres pilares" de las habilidades sociales. Estos tres principios no sólo sirven para engrasar las ruedas de las relaciones, sino que son la base sobre la que se asientan toda interacción y colaboración sanas.

Humildad

No eres el centro del universo. No eres omnisciente ni infalible. Estás abierto a la superación personal.

Respeta

Te preocupas de verdad por las personas con las que trabajas. Los tratas como seres humanos y aprecias sus capacidades y logros.

Confía en

Crees que los demás son competentes y harán lo correcto, y te parece bien dejarles conducir cuando sea apropiado.⁴

Juntos, nos referimos a estos principios como TRH. Lo pronunciamos como "corazón" y no como "herir", porque se trata de disminuirel dolor y no de herir a las personas. De hecho, nuestra tesis principal se basa directamente en estos pilares:

Casi todos los conflictos sociales pueden deberse, en última instancia, a una falta de humildad, respeto o confianza.

Puede sonar inverosímil al principio, pero inténtalo. Piensa en alguna situación social desagradable o incómoda de tu vida en este momento. En el nivel más básico, ¿está todo el mundo siendo adecuadamente humilde? ¿Se respetan realmente los unos a los otros? ¿Hay confianza mutua?

Creemos que estos principios son tan importantes que incluso hemos estructurado este libro en torno a ellos.

Este libro empieza contigo: consiguiendo que aceptes la TRH e interiorices realmente lo que significa poner la TRH en el centro de tus interacciones. De eso trata este primer capítulo. A partir de ahí, creamos círculos de influencia cada vez más amplios.

En el Capítulo 2 tratamos el reto de crear un equipo basado en los tres pilares. Crear una cultura de equipo es el siguiente paso crítico hacia el éxito: es el "dream team" del que hemos hablado antes.

A continuación, examinamos a las personas que interactúan con tu equipo a diario, pero que pueden no formar parte de la cultura central del equipo. Puede tratarse de compañeros de trabajo de otros equipos, o simplemente de voluntarios que se ofrecen a ayudar en tu proyecto. Muchos de ellos no sólo no tienen en cuenta la TRH, sino que pueden ser francamente venenosos. Aprender a defender a tu equipo de ellos es lo primero. Sin embargo, quitarles los colmillos y absorberlos en tu cultura debería ser el objetivo final. Es una forma estupenda de ampliar un equipo.

La mayoría de los equipos trabajan dentro de una empresa más grande, y este entorno a menudo puede ser un impedimento tan grande como las personas venenosas. Aprender a sortear estos obstáculos organizativos puede ser la diferencia entre lanzar un producto y conseguir que ese mismo producto sea cancelado.

Por último, tenemos en cuenta a los usuarios de tu software. A veces olvidamos que existen, pero son el alma de tu proyecto. Sin usuarios, tu software no tiene razón de ser. Los mismos principios de la TRH que prosperan en tu equipo pueden y deben aplicarse a la forma en que interactúas con tus usuarios, y los beneficios que se cosechan son tremendos.

Detengámonos un momento.

Cuando cogiste este libro, probablemente no estabas pensando en apuntarte a una especie de grupo de apoyo semanal. Sentimos empatía. Tratar con problemas sociales puede ser difícil. Las personas son desordenadas, impredecibles y a menudo resulta molesto relacionarse con ellas. En lugar de dedicar energía a analizar las situaciones sociales y hacer movimientos estratégicos, resulta tentador descartar todo el esfuerzo. Es mucho más fácil salir con un compilador predecible, ¿no? ¿Para qué molestarse en lo social?

He aquí una cita de una famosa conferencia de Richard Hamming en :⁵

Tomándome la molestia de contar chistes a las secretarias y siendo un poco simpático, conseguí una ayuda de secretaría magnífica. Por ejemplo, una vez, por alguna estúpida razón, todos los servicios de reproducción de Murray Hill estaban ocupados. No me preguntes cómo, pero lo estaban. Yo quería que me hicieran algo. Mi secretaria llamó a alguien de Holmdel, se subió al coche de la empresa, hizo el viaje de una hora, lo reprodujo y volvió. Fue una recompensa por las veces que me había esforzado en animarla, contarle chistes y ser simpático; fue ese pequeño trabajo extra que luego me compensó. Al darte cuenta de que tienes que utilizar el sistema y estudiar cómo conseguir que el sistema haga tu trabajo, aprendes a adaptar el sistema a tus deseos.

La moraleja es la siguiente: no subestimes el poder del juego social. No se trata de engañar o manipular a la gente; se trata de crear relaciones para conseguir cosas, y las relaciones siempre duran más que los proyectos.

La THS en la práctica

Toda esta prédica sobre la humildad, el respeto y la confianza suena a material para sermones. Bajemos de las nubes y pensemos en cómo aplicar estas ideas en situaciones de la vida real. Buscamos sugerencias prácticas, así que vamos a examinar una lista de comportamientos y ejemplos concretos con los que puedes empezar. Muchos de ellos pueden parecer obvios al principio, pero en cuanto empieces a pensar en ellos te darás cuenta de la frecuencia con la que tú (y tus compañeros) sois culpables deno seguirlos.

Pierde el ego

Vale, ésta es una forma más sencilla de decirle a alguien que no tiene lahumildad suficiente para perder los papeles. Nadie quiere trabajar con alguien que se comporta constantemente como si fuera la persona más importante de la sala. Aunque sepas que eres la persona más sabia de la discusión, no se lo eches en cara a la gente. Por ejemplo, ¿sientes siempre la necesidad de tener la primera o la última palabra en cada tema? ¿Sientes la necesidad de comentar cada detalle de una propuesta o discusión? ¿O conoces a alguien que haga estas cosas?

Ten en cuenta que "ser humilde" no es lo mismo que decir que hay que ser un completo felpudo: la confianza en uno mismo no tiene nada de malo. Simplemente no parezcas un sabelotodo. Mejor aún, piensa en apostar por un ego "colectivo"; en lugar de preocuparte por si eres increíble personalmente, intenta crear un sentimiento de logro de equipo y orgullo de grupo. Por ejemplo, la Fundación para el Software Apache tiene una larga historia de creación de comunidades en torno a proyectos de software; estas comunidades tienen identidades increíblemente fuertes y rechazan a las personas más preocupadas por la autopromoción.

El ego se manifiesta de muchas maneras, y muchas veces puede entorpecer tu productividad y ralentizarte. He aquí otra gran historia de la conferencia de Hamming que ilustra perfectamente este punto:

John Tukey casi siempre vestía de forma muy informal. Entraba en un despacho importante y pasaba mucho tiempo antes de que el otro se diera cuenta de que se trataba de un hombre de primera clase y que más le valía escuchar. Durante mucho tiempo John ha tenido que superar este tipo de hostilidad. ¡Es un esfuerzo inútil! No he dicho que debas conformarte; he dicho: "La apariencia de conformarse te lleva muy lejos". Si eliges hacer valer tu ego de cualquier manera, "voy a hacerlo a mi manera", pagas un pequeño precio constante a lo largo de toda tu carrera profesional. Y esto, a lo largo de toda una vida, supone una enorme cantidad de problemas innecesarios. [...] Al darte cuenta de que tienes que utilizar el sistema y estudiar cómo conseguir que el sistema haga tu trabajo, aprendes a adaptar el sistema a tus deseos. O puedes luchar contra él de forma constante, como una pequeña guerra no declarada, durante toda tu vida.

Aprende a Repartir y a Manejar las Críticas

Joe empezó un nuevo trabajo como programador. Tras su primera semana, empezó a indagar en el código base. Como le importaba lo que estaba pasando, empezó a interrogar amablemente a otros compañeros de equipo sobre sus contribuciones. Envió sencillas revisiones del código por correo electrónico, preguntando amablemente sobre los supuestos de diseño o señalando los lugares donde se podía mejorar la lógica. Al cabo de un par de semanas le citaron en el despacho de su director. "¿Cuál es el problema?" preguntó Joe. "¿He hecho algo mal?" El director parecía preocupado: "Hemos recibido muchas quejas sobre tu comportamiento, Joe. Al parecer, has sido muy duro con tus compañeros de equipo, criticándoles a diestro y siniestro. Están molestos. Tienes que bajar el tono". Joe estaba totalmente desconcertado. En una cultura fuerte basada en la HRT, las revisiones de código de Joe deberían haber sido bien recibidas y apreciadas por sus compañeros. En este caso, sin embargo, Joe debería haber sido más sensible a la inseguridad generalizada del equipo y haber utilizado medios más sutiles para introducir las revisiones de código en la cultura.

Las críticas casi nunca son personales en un entorno profesional de ingeniería de software: suelen formar parte del proceso de creación de un producto mejor. El truco está en asegurarte de que tú (y los que te rodean) entendéis la diferencia entre la crítica constructiva de la producción creativa de alguien y los ataques rotundos contra el carácter de alguien. Lo segundo es inútil, mezquino y casi imposible de aplicar. La primera siempre es útil y orienta sobre cómo mejorar. Y lo que es más importante, está impregnada de respeto: la persona que hace la crítica constructiva se preocupa de verdad por la otra persona y quiere que mejore ella misma o su trabajo. Aprende a respetar a tus compañeros y a hacer críticas constructivas con educación. Si realmente respetas a alguien, te sentirás motivado para elegir frases con tacto y útiles, una habilidad que se adquiere con mucha práctica.

En el otro lado de la conversación, también tienes que aprender a aceptar las críticas. Esto significa no sólo ser humilde sobre tus habilidades, sino confiar en que la otra persona tiene en mente tus mejores intereses (¡y los de tu proyecto!) y no piensa realmente que eres idiota. La programación es una habilidad como cualquier otra. Mejora con la práctica. Si un compañero te señalara formas de mejorar tus malabarismos, ¿lo tomarías como un ataque a tu carácter y a tu valor como ser humano? Esperamos que no. Del mismo modo,tu autoestima no debería estar relacionada con el código que escribes, ni con ningún proyecto creativo que construyas. Para repetirlo: tú no eres tu código. Repítelo una y otra vez. No eres lo que creas. No sólo tienes que creértelo tú, sino hacer que tus compañeros de trabajo también lo crean.

Por ejemplo, si tienes un colaborador inseguro, esto es lo que nodebes decir: "Tío, te has equivocado totalmente en el flujo de control de ese método. Deberías utilizar el patrón de código estándar xyzzy como todo el mundo". Este comentario está lleno de antipatrones: le estás diciendo a alguien que está "equivocado" (¡como si el mundo fuera blanco o negro!), exigiéndole que cambie algo y acusándole de crear algo que va en contra de lo que hacen todos los demás (haciéndole sentir estúpido). La respuesta va a ser excesivamente emocional, viniendo de alguien puesto a la defensiva.

Una forma mejor de decir lo mismo podría ser: "Oye, me confunde el flujo de control en esta sección de aquí. Me pregunto si el patrón de código xyzzy podría hacerlo más claro y fácil de mantener". Fíjate en que estás utilizando la humildad para que la pregunta se refiera a ti, no a él. Él no está equivocado; tú sólo tienes problemas para entender el código. La sugerencia se ofrece simplemente como una forma de aclarar las cosas para el pobrecito de ti, y posiblemente de ayudar a los objetivos de sostenibilidad a largo plazo del proyecto. Tampoco estás exigiendo nada: estás dando a tu colaborador la posibilidad de rechazar pacíficamente la sugerencia. La discusión se mantiene en el ámbito del propio código y no trata sobre el valor o las habilidades de codificación de nadie.

Fracasa rápido e itera

Hay una leyenda urbana muy conocida (y tópica) en el mundo empresarial sobre un directivo que comete un error y pierde la impresionante cantidad de 10 millones de dólares. Al día siguiente, va abatido a la oficina y empieza a recoger su mesa, y cuando recibe la inevitable llamada de "el director general quiere verte en su despacho", entra a trompicones en el despacho del director general y le desliza silenciosamente un papel por la mesa.

"¿Qué es esto?", pregunta el director general.

"Mi dimisión", dice el ejecutivo. "Supongo que me has llamado para despedirme".

"¿Despedirte?", responde el director general, incrédulo. "¿Por qué iba a despedirte? Acabo de gastarme 10 millones de dólaresen formarte ".⁶

Es una historia extrema, sin duda, pero el director general de esta historia comprende que despedir al ejecutivo no desharía la pérdida de 10 millones de dólares, y la agravaría al perder a un valioso ejecutivo del que puedes estar completamente seguro de que no volverá a cometer ese tipo de error.

En Google, uno de nuestros lemas favoritos es "El fracaso es una opción". Está ampliamente reconocido que si no fracasas de vez en cuando, no estás siendo lo suficientemente innovador o asumiendo suficientes riesgos. El fracaso se considera una oportunidad de oro para aprender y mejorar para la próxima vez. De hecho, a menudo se cita a Thomas Edison diciendo: "Si encuentro 10.000 maneras de que algo no funcione, no he fracasado". No me desanimo, porque cada intento erróneo descartado es otro paso adelante".

En Google X -la división que trabaja en "moonshots" como Google Glass y los coches autoconducidos- el fracaso está deliberadamente integrado en su sistema de incentivos. A la gente se le ocurren ideas locas y se anima activamente a los compañeros de trabajo a derribarlas lo antes posible. Se recompensa a los individuos (¡e incluso se compite!) para ver cuántas ideas pueden refutar o invalidar en un periodo de tiempo determinado. Cuando un concepto es realmente incapaz de ser refutado en una pizarra por todos los compañeros, sólo entonces pasa a prototipo temprano.

La clave para aprender de tus errores es documentar tus fracasos. Redacta "autopsias", como se suelen llamar en nuestro negocio. Ten especial cuidado de que el documento postmortem no sea sólo una inútil lista de disculpas o excusas, pues ése no es su propósito. Un postmortem adecuado debe contener siempre una explicación de lo que se aprendió y de lo que va a cambiar como resultado de la experiencia de aprendizaje. Luego asegúrate de ponerlo en un lugar fácil de encontrar y de llevar a cabo realmente los cambios propuestos. Recuerda que documentar adecuadamente los fracasos también facilita que otras personas (presentes y futuras) sepan lo que ocurrió y eviten repetir la historia. No borres tus huellas: ¡ilumínalas como una pista de aterrizaje para quienes te sigan!

Una buena autopsia debe incluir lo siguiente:

• Breve resumen

• Una cronología del suceso, desde el descubrimiento hasta la resolución, pasando por la investigación

• La causa principal del suceso

• Evaluación de impactos y daños

• Un conjunto de acciones para solucionar el problema inmediatamente

• Un conjunto de acciones para evitar que el suceso se repita

• Lecciones aprendidas

Deja tiempo para aprender

Cindy era una superestrella: una ingeniera de software que realmente dominaba su especialidad. La ascendieron a jefa técnica, vio aumentar sus responsabilidades y aceptó el reto. En poco tiempo, se convirtió en mentora de todos los que la rodeaban y les enseñaba el oficio. Hablaba en conferencias sobre su tema y muy pronto acabó a cargo de varios equipos. Le encantaba ser siempre la "experta". Sin embargo, empezó a aburrirse. En algún momento dejó de aprender cosas nuevas. La novedad de ser la experta más sabia y experimentada de la sala empezó a agotarse. A pesar de todos los signos externos de maestría y éxito, le faltaba algo. Un día se puso a trabajar y se dio cuenta de que el campo que había elegido ya no era tan relevante; la gente había cambiado a otros temas de interés. ¿En qué se había equivocado?

Admitámoslo: es divertido ser la persona con más conocimientos de la sala, y ser mentor de otros puede ser increíblemente gratificante. El problema es que una vez que alcanzas un máximo local en tu equipo, dejas de aprender. Y cuando dejas de aprender, te aburres. O accidentalmente te quedas obsoleto. Es muy fácil volverse adicto a ser un protagonista; pero sólo renunciando un poco al ego podrás cambiar de dirección y exponerte a cosas nuevas. De nuevo, se trata de aumentar la humildad y estar dispuesto a aprender tanto como a enseñar. Sal de tu zona de confort de vez en cuando; busca una pecera con peces más grandes que tú y supera los retos que te propongan. A la larga serás mucho más feliz.

Aprende a ser paciente

Hace años, Fitz estaba escribiendo una herramienta para convertir repositorios CVS a Subversion (y más tarde, a Git) y, debido a los caprichos de CVS, seguía descubriendo fallos extraños. Como su viejo amigo y compañero de trabajo Karl conocía CVS a la perfección, él y Karl decidieron que debían trabajar juntos para solucionar esos fallos.

Surgió un problema cuando empezaron a programar juntos por parejas: Fitz era un ingeniero ascendente que se conformaba con sumergirse en la mugre y abrirse camino probando muchas cosas rápidamente y pasando por alto los detalles. Karl, sin embargo, era un ingeniero descendente que quería conocer todo el terreno y bucear en la implementación de casi todos los métodos de la pila de llamadas antes de proceder a abordar el fallo. Esto provocó algunos conflictos interpersonales épicos, desacuerdos y alguna que otra discusión acalorada. Llegó un punto en el que los dos simplemente no podían programar juntos por parejas: era demasiado frustrante para ambos.

Dicho esto, ambos tenían una larga historia de confianza y respeto mutuo. Esto, combinado con la paciencia, les ayudó a elaborar un nuevo método de colaboración. Se sentaban juntos ante el ordenador, identificaban el fallo, se dividían y atacaban el problema desde dos direcciones a la vez (de arriba abajo y de abajo arriba), para luego volver juntos y reunirse en el centro con sus conclusiones. Su paciencia y su voluntad de improvisar nuevos estilos de trabajo no sólo salvaron el proyecto, sino también la amistad.

Ábrete a la influencia

Cuanto más abierto estés a la influencia, más capaz serás de influir; cuanto más vulnerable seas, más fuerte parecerás. Estas afirmaciones parecen contradicciones extrañas. Pero todo el mundo puede pensar en alguien con quien ha trabajado que es simplemente enloquecedoramente testarudo. Por mucho que intenten persuadirle, se atrinchera aún más. ¿Qué les ocurre finalmente a estos miembros del equipo? Según nuestra experiencia, acaban siendo "rodeados" como un obstáculo que todo el mundo da por sentado. La gente deja de escuchar sus opiniones u objeciones. Desde luego, no quieres que eso te ocurra a ti, así que mantén esta idea en la cabeza: no pasa nada porque otra persona te haga cambiar de opinión. Elige tus batallas con cuidado. Recuerda que para que te escuchen bien, primero tienes que escuchar a los demás. En el caso de ser influenciado, esta escucha debe tener lugar antes de que hayas clavado una estaca en el suelo o declarado firmemente que has decidido algo: si cambias constantemente de opinión, la gente pensará que eres indeciso.

En cuanto al tema de la vulnerabilidad, esto también parece un poco extraño al principio. Si alguien admitiera que ignora el tema que se está tratando o que no sabe cómo resolver un problema, ¿qué tipo de credibilidad tendría en un grupo? La vulnerabilidad es una muestra de debilidad, y eso destruye la confianza, ¿no?

No es cierto. Admitir que has cometido un error o que simplemente estás fuera de tu liga es una forma de aumentar tu estatus a largo plazo. De hecho, engloba toda la TRH: es una muestra externa dehumildad, se trata de rendir cuentas y asumir responsabilidades, es una señal de que confías en las opiniones de los demás y, a cambio, la gente acaba respetando tu honestidad y fortaleza. A veces lo mejor que puedes hacer es decir: "No lo sé".

Piensa en los políticos profesionales: son famosos por no admitir nunca sus errores o su ignorancia, incluso cuando es evidente que están equivocados o desconocen un tema. Y por eso la mayoría de la gente no cree ni una palabra de lo que dicen los políticos. Este comportamiento existe principalmente porque los políticos son constantemente atacados por sus oponentes. Sin embargo, cuando escribes software, no es necesario vivir en un constante estado de defensa: tus compañeros son colaboradores, no competidores.

Próximos pasos

Si has llegado hasta aquí, estás en el buen camino para dominar el arte de "jugar bien con los demás". Tienes que empezar por examinar y meditar sobre tus propios comportamientos. Una vez que hayas incorporado estas estrategias a tu vida diaria, descubrirás que la colaboración será mucho más natural y tu productividad en ingeniería empezará a aumentar notablemente.

Los cambios importantes empiezan contigo y luego se extienden a los demás. En el próximo capítulo, hablaremos de cómo crear una cultura de TRH dentro de tu equipo inmediato.

¹ Literalmente, si eres, de hecho, diseñador de bicicletas.

² Debemos tener en cuenta que a veces es peligroso recibir demasiadas opiniones demasiado pronto en el proceso, pero eso lo trataremos en un capítulo posterior.

³ Sin embargo, reconocemos que los introvertidos serios probablemente necesiten más paz, tranquilidad y tiempo a solas que la mayoría de la gente y pueden beneficiarse de un entorno más tranquilo, si no es su propia oficina.

⁴ Esto es increíblemente difícil si te has quemado en el pasado delegando en personas incompetentes.

⁵ "Tú y tu investigación ", http://bit.ly/hamming_paper

⁶ En la Red se pueden encontrar una docena de variantes de esta leyenda, atribuidas a distintos directivos famosos.