elprogramadormediocre/chapter02.md

# Compañeros de viaje

## Programadores famosos

A lo largo de la historia de la computación ha habido personas que han demostrado increíbles capacidades a la hora de crear código. Residen en el panteón de los grandes programadores informáticos: Ada Lovelace (la primera programadora de computadoras), Dennis Ritchie (el creador del lenguaje de programación C), Rear Admiral Grace Murray Hopper (creador de COBOL y acreditado por encontrar el primer "error" (_N. del traductor: un error informático en inglés es llamado "bug" que también se puede traducir como bicho o insecto_) informático documentado) y muchos más. También tenemos desarrolladores en nuestras propias comunidades que tienen un cierto grado de notoriedad, ya sean las personas que escribieron el lenguaje de programación que usamos actualmente, las personas que mantienen el sistema operativo que usamos o alguien que saltó a la fama en nuestra comunidad preferida. Puede ser intimidante cuando nos comparamos con estas grandes personas. Después de todo, cualquier cosa en la que estemos trabajando actualmente podría no estar a la altura de lo que ellos hayan hecho. Peor aún, podemos estar trabajando en algo similar y sentir que cualquier cosa en la que estemos trabajando nunca estará a la altura de lo que estas personas han logrado. Incluso podemos ser amigos de programadores que parecen resolver las cosas mucho más rápido y de una manera más elegante que nosotros y maravillarnos de cómo parecen tener todo ese conocimiento al alcance de la mano que posiblemente no podamos entender.

## Entre bastidores frente a la actuación final

Uno de los mejores consejos que he recibido sobre compararnos con los demás es darnos cuenta de que la comparación es entre nuestra vida entre bastidores _versus_ la actuación final que ven los espectadores. La metáfora se basa en el teatro, donde los artistas saben todo lo que no está bien sobre la actuación de su propio grupo de teatro y lo comparan injustamente con la actuación final de otro grupo de teatro. Esta metáfora es útil en nuestro caso porque tendemos a comparar todas las cosas que sabemos (las largas horas de crear código improductivas, las dificultades para aprender, etc.) con el producto final de otra persona. No vemos su lucha para hacer que las cosas funcionen, o sus innumerables horas haciendo prototipos de mierda y proyectos sin terminar antes de hacer lo que admiramos. Permítete tener un lugar entre bastidores desordenado y hacer muchos ensayos, y comprende que se necesita esfuerzo y práctica para realizar una buena actuación.

## El atractivo del post-mortem

Hay una tradición en algunos proyectos de programación (especialmente en proyectos de desarrollo de juegos donde hay un final claro para el proyecto cuando se envía el producto) de hacer una autopsia del proyecto. Lo que hace la autopsia es permitir que los desarrolladores de un proyecto indiquen lo que salió bien y lo que no salió bien. Las mejores autopsias tienden a ser relatos sinceros de los éxitos y fracasos de un proyecto.

La autopsia puede ser una mirada fascinante al desarrollo de un proyecto. Me he encontrado leyendo muchas de estas en busca de información sobre el proceso de desarrollo. Pero hay una trampa sutil en la autopsia: son un recuerdo de eventos desde el punto de vista de un proyecto exitoso (o fallido). Son un recuerdo de alguien que trabajó en un proyecto que fue lo suficientemente exitoso como para que tu dediques tiempo a leer sobre los altibajos de ese proyecto. Están escritos desde una perspectiva en la que el éxito del proyecto es una conclusión inevitable (o están escritos sobre proyectos que se destacaron por cómo fallaron o no cumplieron con las expectativas de los involucrados). Puede llevar a la creencia de que en lo que estás trabajando no es tan importante como las cosas en las que están trabajando otras personas. Pero no sabemos la importancia de nuestro proyecto en tiempo real. Incluso la gente en la autopsia no sabía si su proyecto funcionaría o tendría éxito mientras trabajaban en él. Es posible que nuestros proyectos nunca vean la luz del día o que sean algo que cambie el mundo. No podemos saber el valor de aquello en lo que estamos trabajando mientras lo hacemos (aunque podemos tener una idea de si _sentimos_ que nuestro trabajo es importante o no).

Una autopsia también tiene el beneficio de la retrospectiva. Las decisiones que eran claras y definitivas en ese momento podrían no tener mucho sentido cuando se las compara con los datos obtenidos más adelante en la vida útil del proyecto. También hay un problema con la "memoria selectiva" en la que es posible que algo no se recuerde con la misma claridad o se combine con otros eventos. Declaraciones confiadas como "Sabíamos que esto no habría funcionado" en realidad podrían haber sido "No estábamos seguros de si esto funcionaría, así que probamos varias cosas. Todas no funcionaron". Debes considerar a cualquiera que escriba sobre su pasado como un narrador poco confiable. Cierto, pueden ser los mejores y más informados narradores que tenemos, pero no tienen una perspectiva objetiva de lo que sea que estaban creando. Tienen sus propios prejuicios y razones para las historias que presentan en una autopsia. Trate una autopsia como trataría una autobiografía de una persona famosa: una fuente primaria con una agenda para mostrar el tema de la mejor manera posible.

No hay nada de malo en leer una autopsia sobre un proyecto, podemos aprender mucho sobre cómo se ejecuta un proyecto (o no se debe ejecutar) y qué peligros debemos tener en cuenta si seguimos un camino similar, pero hay que comprender que estás leyendo un informe (ya sea de una persona o de un equipo de personas). Tienen la perspectiva de alguien profundamente involucrado en el conflicto. Estás mirando sus recuerdos de tácticas, no la estrategia general que los trajo al lugar.

## Clasificación de programadores

Hay muchas medidas que la gente usa para clasificar a los programadores. Es probable que hayas visto que estas medidas se manifiestan de diferentes maneras: sitios de competencia, números de _commits_ en un proyecto, medidas de productividad, tiempo para entregar el código y los buenos sentimientos viscerales que podamos sentir, como se hacía antiguamente. Nos lo hacemos a nosotros mismos y a los demás. Comparamos nuestro trabajo con el trabajo de nuestros compañeros y gente que admiramos, pero eso puede llevarnos a hacer comparaciones que no son objetivas o no se basan en todos los datos. Puedo compararme con personas que hacen programación de bajo nivel y encontrar que no estoy a la altura en ese ámbito. No importa que no haya hecho mucha programación de bajo nivel, la comparación es válida. O puedo compararme con personas que fueron asesoradas por programadores cuyos nombres son legendarios en su campo. Encontraré brechas entre mi conocimiento y el de ellos, porque no tuve acceso a esos mentores (o peor aún: no aproveché los mentores a los que podría haber accedido. ¡Ups!). Comparaciones como estas no ayudan y nos llevan a castigarnos por no ser otra persona. Nuestra evaluación de nuestros proyectos e historia nos da la conclusión de que no somos esa otra persona, ni podríamos ser nunca esa otra persona.

El mayor problema con la clasificación de programadores (o en cualquier caso, clasificación de cualquier cosa) es que los sistemas de clasificación están basados en una serie de criterios. No hay un estándar real para clasificar programadores. Los sitios donde se clasifica y puntúa programadores en base a un número de problemas resueltos o la dificultad de los problemas resueltos solo han determinado que hay una serie de programadores que realmente disfrutan resolviendo esa clase de problemas. También han reunido a un grupo de programadores que dedicarán tiempo y esfuerzo a resolver estos problemas y serán competitivos mientras los resuelven. Nos dice poco sobre las habilidades del programador fuera de esa materia.

También hay otras medidas para clasificar a los programadores. Una medida clásica es revisar cuántas líneas de código usó un programador para resolver un problema (esto a veces se denomina "código de golf", donde cuanto menor sea el número de líneas de código, mejor será la solución). Podemos argumentar cómo de "limpia" es la solución (limpia es otro término algo nebuloso y poco concreto). Podemos determinar la "notación Big O", una notación utilizada para describir el rendimiento o la complejidad de los algoritmos que utilizó un programador en su código. Podemos hacer una prueba de _estrés_ o de esfuerzo del código para determinar cómo de bien se adapta el código a diversas circunstancias. Podemos contar la cantidad de ciclos que requiere un código en particular para ejecutarse y compararlo con un código similar. Muy poco de esto nos dice algo sobre un programador en particular. Lo que sí nos dice es que el programador tiene experiencia que lo lleva a esa solución en particular. Nos dice que el programador ha visto este tipo de problemas antes y se preocupó lo suficiente por el problema como para pensar lo suficiente sobre cómo hacer una mejor solución. Aprendemos que el programador dedicó tiempo y energía a practicar este tipo de problemas. Lo que no nos muestra es una medida general de las habilidades o capacidades del programador. Es similar al cuento apócrifo de un profesor brillante. Este profesor era un genio absoluto en su campo y era una de las personas a las que acudir para obtener respuestas sobre su tema, pero a pesar de su brillantez, no sabía cómo cambiar un neumático en un automóvil. ¿Significa eso que el profesor no era tan brillante como la gente decía que era? Difícilmente. Significa que el profesor pasó más tiempo pensando en su profesión que pensando en cambiar neumáticos. Lo mismo es cierto también para los programadores. Si un programador pasa la mayor parte de su tiempo resolviendo un conjunto particular de problemas, eventualmente se volverá experto en ese tipo de problemas. Pero si ese programador se atasca con un tipo diferente de problemas, eso no descarta sus habilidades generales, simplemente señala las áreas en las que podrían querer trabajar.

## Midiendo el rendimiento del programador

También hay una tendencia a medir la productividad del programador por cuántas contribuciones puede hacer el programador a un proyecto. Bajo ciertos sistemas de control de versiones, estos se denominan _commits_. Enumeran un conjunto de cambios que el programador desea realizar en el código. En una era en la que existen sitios para escribir código de manera colaborativa y social como Github o Gitlab, podemos revisar fácilmente los _commits_ que están realizando otros programadores. Dado que podemos medir la cantidad de _commits_, podemos usar esta medida para sentir que no estamos generando la misma cantidad y frecuencia de _commits_ que otros programadores. Y a diferencia de las medidas de antaño (líneas de código en particular, que mide cuántas líneas de código añade un programador a un programa), podemos revisar la calidad de sus _commits_ con un proyecto. Puede ser desalentador ver una gran cantidad de trabajo de calidad realizado por nuestros compañeros. También puede ser fuente de frustración y sentimientos de insuficiencia. Nos preguntamos "¿Por qué no puedo ser tan productivo o contribuir como esta otra persona?"

Es incluso todavía más frustrante cuando otras personas utilizan estas medidas para judgar la productividad y las contribuciones con código. Podemos encontrarnos siendo criticados por nuestros resultados (o la falta de estos).

Los _commits_ y las líneas de código son las medidas más visibles de la productividad al crear código, pero no muestran mucho sobre la práctica real de la programación. No podemos medir la cantidad de tiempo que dedicamos a pensar en el problema con solo mirar un _commit_. No vemos las montañas de material de referencia que usó el programador para encontrar una solución y ciertamente no sabemos si este _commit_ es el resultado de una tarde de trabajo o de muchos días de trabajo (a menos que se hagan _commits_ con más frecuencia). Incluso podríamos descubrir que esta persona está actuando como el punto central de una organización y está integrando el trabajo de varias personas en sus _commits_.

Medirnos a nosotros mismos basándonos en la cantidad de la producción de otras personas es fácil y muy seductor pero no es útil para hacerse una idea de cómo mejorar nosotros mismos en nuestra tarea de crear código (a no ser que sea "generando más _commits_"). Esa forma de pensar puede llevarnos a creer que no estamos dedicando el tiempo suficiente a la "programación real" y provocar exceso de trabajo, estrés y agotamiento.

## Compañeros de viaje

Hay momentos en los que es útil compararnos con otros programadores. A veces podemos aprender sobre nuevas tecnologías o nuevas metodologías mirando el trabajo de otras personas, pero es fácil caer en la trampa de pensar que porque no estamos al nivel de otros programadores somos de alguna manera inferiores a ellos. En lugar de ver a otros programadores como competencia, deberíamos verlos como compañeros. Todos estamos en esta profesión trabajando para mejorar nuestros respectivos proyectos. Con el software libre y de código abierto tenemos una oportunidad única de ver cómo otras personas hacen su trabajo en público. Podemos aprender del código de otros de la misma manera que los científicos pueden mirar los artículos de otros científicos para ver qué funcionó (y pueden mejorar la validez del artículo con una réplica y repetición). Ningún programador está completamente aislado del trabajo de los demás. (Es raro que un programador haya creado el código de todo su entorno de programación desde cero sin el trabajo de otras personas). Todas las personas aprendemos unas de otras, pero en lugar de intimidarnos por el trabajo de otras, podemos desarmarlo y aprender de él. Si tenemos suerte, podemos aprovechar la oportunidad para preguntarles cómo funciona el código y por qué eligieron escribir el código de esa manera.

Es valioso hacer preguntas a nuestros compañeros programadores. Tendemos a pasar por alto hacer preguntas por miedo a que vamos a hacer algo obvio o hacer una pregunta que nos haga sentir incómodos por preguntar. Hacer preguntas es muy útil cuando no entendemos qué está pasando con una idea o una pieza de código en particular. Hay programadores a los que no les importa responder preguntas, y espero que los encuentres. De acuerdo, hay algunos programadores que están muy ocupados y es posible que no tengan el tiempo o la predisposición para responder preguntas, pero si realmente estamos atascados y hemos agotado todas las demás vías, tal vez podamos hacerles preguntas que no requieran mucho de su tiempo y esfuerzo. Incluso pueden estar agradecidos por la pregunta porque les da una idea de una perspectiva que de otro modo no tendrían. Cuando hacemos preguntas iniciamos un intercambio de ideas en ambas direcciones.

Hacer preguntas es todo un arte y puede ser frustrante cuando las personas no responden nuestras preguntas o nos responden con otras preguntas o sugerencias que son menos que útiles. Esto se manifiesta en intercambios donde la persona A pregunta: "Me gustaría saber cómo hacer X" y las personas B y C responden "Yo en su lugar haría Y". Es frustrante cuando la gente no responde a nuestras preguntas de manera directa. También es fácil verse envuelto en intercambios con la gente sobre los méritos de hacer Y donde Y fue sugerido por otra persona que no tiene nada que ver con la pregunta original sobre X. Pero si volvemos a enmarcar la experiencia como "esta persona está tratando de ayudarme, tal vez haya algo en esta recomendación que pueda ser útil", entonces podemos tener una mejor conversación. Quizás lo que estamos preguntando no es la mejor manera de hacer algo y hacer una pausa para escuchar puede ayudarnos a comprender mejor por qué hicieron su sugerencia.

El sacar nuestros egos de la pregunta nos permite estar más abiertos a las respuestas que recibimos. Cuando las personas no entienden nuestra pregunta, es fácil tomarla como algo personal y protestar pensando "no me entienden" o "no me escuchan". Al abstraernos de la pregunta nos permite tomar la respuesta proporcionada "tal cual" y nos da la capacidad de cambiar la pregunta según sea necesario para obtener mejores respuestas.

Por supuesto, hay personas que no responderán pensando en lo mejor para ti y solo están interesadas en imponerte su propia visión del mundo. En lugar de responder a tu pregunta, cuestionan por qué estás haciendo eso y en su lugar sugieren que deberías usar su metodología. Puede requerir mucha energía enfrentarse con estas personas y decirles "no, realmente tenía la intención de aprender más sobre X". Me gustaría tener buenas respuestas sobre cómo manejar a este tipo de personas. Muchas de estas personas sienten que cualquier cosa que estén haciendo es el único camino correcto y aquellas personas que se desvían de su camino elegido son anatema para su mundo. Mi mejor sugerencia es agradecerles su tiempo y pedir ayuda a alguien más. Tal vez puedan ser útiles en el futuro cuando tenga preguntas sobre lo que sea que sea parte de su agenda, pero por ahora conviene ser lo más amable posible y desearles lo mejor en su viaje de programación. Los espacios tecnológicos tienen mucha gente que ha estado trabajando con computadoras durante mucho tiempo y se ha formado opiniones sólidas sobre sus herramientas y tecnologías. Mi esperanza es que puedas encontrar a los que también son amables y están dispuestos a compartir lo que saben y no acosarte con sus creencias arraigadas. Con el tiempo, también formarás tus propias creencias sobre lo que funciona y lo que no funciona y transmitirás ese conocimiento a los demás. Reconocer a las personas que están ahí para ayudar a educar y a las que están ahí para hacer proselitismo es parte de nuestro proceso de crecimiento.

Si vemos a otros programadores como compañeros de viaje en esta travesía, como colegas en nuestra práctica a la hora de crear código, entonces nos daremos cuenta que estamos en esto todos juntos. Incluso alguien con muchos más años de experiencia que nosotros es tu colega. Tienes conocimientos y experiencia que ellos no tendrán y ellos tienen experiencias y conocimientos que tu no tienes. Si nos despojamos de las barreras del estatus que percibimos y de la meritocracia de esas personas podremos entendernos mejor aprender unos de otros.

El viaje para llegar a ser un programador mejor es largo y duro. Necesitamos los mejores compañeros que podamos encontrar para ayudarnos en este viaje. Necesitamos algo más que únicamente compañeros que tengan muy buenos conocimientos técnicos, también necesitamos compañeros con los que podamos hablar cuando la jornada termina. Necesitamos compañeros con los que podamos sentarnos alrededor de la fogata proverbial e imaginaria donde juntos podamos reír y compadecernos de nuestras luchas.