• Video: El costo de especializarte

    Otro clip tomado de la participación que tuve en The Dojo, el canal de mi amigo Héctor, hace unos meses. En este, hablo sobre lo que tuve que sacrificar para especializarme como desarrollador de iOS, y las implicaciones que eso tuvo en mi vida. El artículo de Paul Graham que menciono se llama Bus ticket theory of genius.

  • Incrementa el valor de tu documentación con arte ASCII

    Aquí hay otro ejemplo de cómo la documentación aumenta el valor de tu código. John Regehr recopiló imágenes de cómo en algunos proyectos de código abierto se usa arte ASCII para explicar el código de manera más clara.

    En su artículo, escribe:

    Las personas tienden a ser visuales: usamos imágenes para entender problemas. Los lenguajes de programación más populares, por el contrario, operan en un espacio completamente abstracto, dejando una gran brecha entre programa e imagen.

    Un ejemplo tomado del compilador de Swift:

    Puedes utilizar apps como Mondraw para crear este tipo de documentación. Recuerda el Triángulo de la Documentación de Código, y que agregar documentación no es una admisión de que no fuiste lo suficientemente inteligente para escribir “buen” código.

     

  • El Triángulo de la Documentación de Código

    Hace un tiempo propuse que deberías escribir código que se documente solo, y luego agregarle documentación. En el artículo original, escribí:

    La idea de que “tu código debería de documentarse solo” no es un get out of jail free card para no documentar tu código. Las ocasiones en tu carrera profesional donde escribir documentación no agrega valor a tu trabajo son muy pocas. Tan pocas, de hecho, que no se me viene ninguna a la mente. ¿Tal vez cuando estás trabajando en un proyecto propio? Pero hasta Damian Conway dijo que “la documentación es una carta de amor que le escribes a tu yo del futuro”.

    Hoy me encontré una idea que aumenta mi punto: El Triángulo de la Documentación de Código.

    Documentación de Código:¿Qué, cómo, por qué?
    Documentación de Código:¿Qué, cómo, por qué?

    Este modelo mental nos dice que toda pieza de código está documentada en 3 dimensiones distintas, cada una respondiendo una pregunta muy particular.

    • ¿Qué?: Tu código, en sí, explica lo que estás haciendo.
    • ¿Por qué?: Los comentarios que le agregas a tu código, explican tu proceso de toma de decisiones y la razón de tus soluciones.
    • ¿Cómo?: El contexto dentro del cual estás desarrollando tu programa; la descripción original del problema.

    Si te enfocas en escribir código que “se documente solo”, en un futuro no sabrás por qué llegaste a esa solución, ni cómo esa solución es apropiada para el problema original.

    Recuerda, agregar documentación a tu código (en forma de comentarios, glosarios, RFCs, pruebas, etc.), no es una admisión que no fuiste lo suficientemente inteligente para escribir “buen” código, sino un acto de compasión. Demuestra tu interés porque la siguiente persona que modifique tu código pueda enfocarse en agregar valor al proyecto — y, muy probablemente, esa siguiente persona vas a ser tú.

  • GitHub Copilot ahora disponible de manera general

    Hace un par de días, GitHub anunció que Copilot está ahora disponible de manera general.

    Cualquier persona, hoy puede pagar $10 USD mensualmente por un compañero de pair programming creado con inteligencia artificial.

    Buen momento para recordar lo que escribí hace casi exactamente un año:

    Con el aspecto técnico resuelto (parcialmente) por inteligencias artificiales, las discusiones técnicas dejarán de ser la parte más importante del desarrollo. Los “programadores” ahora se dedicarán a tener discusiones sobre la ética y seguridad del código generado por la computadora. Las tareas técnicas serán resueltas, en su mayoría, gracias a la ley de Moore. Desarrollar software ya no se tratará de programar.

    Aún habrá trabajos para escribir código, pero requerirán una alta especialización. Las personas que sigan escribiendo código lo harán para crear la infraestructura que soportará al resto del ecosistema: compiladores, IA, generadores de código, redes, etc.

    Si estás en la industria del software y piensas que tu único trabajo es programar, heads up. Le acaban de poner fecha de caducidad a tu carrera. Y tienes de dos: o te pones a refinar tus soft skills, o comienzas a especializarte en tecnologías fundamentales.

  • Comunicación: la diferencia entre tener privacidad, y guardar secretos

    El término “comunicación” es tan amplio y dependiente del contexto del trabajo y la industria en la que uno se desempeña, que muchas organizaciones deciden simplemente no ponerle mucha atención. Adoptan una mentalidad de que “lo que importa es que las cosas se hagan, pero no importa cómo.”

    Adam Thomas escribió brillantemente al respecto (traducido por mí):

    La cultura de comunicación de tu empresa tiene un gran impacto en el resto de tu negocio. Cultivar una atmósfera de confianza es esencial para el éxito. El nivel de confianza que las personas en tu organización depositan en sus líderes y en ellos mismos, afecta la productividad, la salud de tus compañeros y la retención a largo plazo del equipo.

    En su artículo, Adam menciona que existen principalmente dos tipos de empresas: las que quieren hacer las cosas en privado, y las que quieren hacer las cosas en secreto. La diferencia es sutil, pero el diablo está en los detalles.

    Cualquier información que se comparta llamadas, mensajes directos o canales privados se pierde en el limbo. Esto le resta visibilidad al equipo, se pierde la trazabilidad del proceso de toma de decisiones, y en muy poco tiempo, la confianza del equipo se ve mermada por esta opacidad.

    A muchos líderes les cuesta trabajo ver más allá de la meta puntual que tienen en frente, e ignoran las consecuencias de fomentar una cultura de comunicación que hace que los miembros del equipo se sientan asediados, estresados e inseguros.

    Personalmente, estoy consciente de estos problemas y lo fácil que es caer en una situación donde el comportamiento por defecto es ocultar información. En mis equipos procuramos que cualquier llamada que tengamos con otros miembros quede resumida en un mensaje donde se listen los acuerdos a los que se llegaron. También, usamos canales de Slack públicos por defecto, y todos tenemos la expectativa de mover cualquier pregunta que nos hagan por DM a un canal público.

Ayudo a personas que trabajan con software a mejorar sus carreras profesionales.

Los miembros tienen acceso a Pathways, pueden comentar en las publicaciones, interactuar con la comunidad, y muchos otros beneficios. Conoce más.

Agrégame a tu lector RSS, o suscríbete a mi newsletter para recibir los nuevos artículos que publique.