• El Open Source no se trata de ti

    Rich Hickey, creador de Clojure, escribiendo en GitHub Gist:

    Ser usuario de algo que es Open Source, no te hace merecedor de nada en absoluto. No necesitas contribuir. No tienes por qué exigir nuevas características. No te mereces la atención de otros. No significa que tus quejas tengan un valor para el producto. No te mereces esta explicación.

    Si tienes expectativas (de otros) que no están siendo cumplidas, esas expectativas son tu propia responsabilidad. Eres responsable de tus necesidades. Si quieres algo, hazlo.

    Hace un tiempo escribía sobre como ser desarrollador Open Source parecía no ser tan buena idea hoy en día. El Gist que publica Rich no es nuevo, tiene por lo menos unos 5 o 6 años, pero demuestra la tendencia hacia el burn-out que muchos administradores de proyectos Open Source hoy están reportando.

  • Cómo jugar un rol activo en tu educación continua

    Me puse a reflexionar, y me di cuenta de que, por lo menos en mi caso, durante mi proceso de formación, nunca se me inculcó la importancia de invertir en educación. Claro, se me mencionó que la educación continua era importante. Pero nunca se me dijo que una de las formas de mantenerme educado continuamente era “aventándole dinero al problema”.

    Suena raro, ¿no? Hasta parece obvio.

    Me dio curiosidad saber cuánto dinero invierten las personas en su educación al año.

    ¿Cuándo inviertes en educación al año?

    USD $500 (MXN $10,000) es también más o menos lo que había estado invirtiendo anualmente en mi educación, en promedio, hasta 2020.

    En mi caso, creo que interpreté la idea de “educación continua” como “aprende lo más que puedas de las situaciones que se te presenten”. Que es un consejo sabio, y lo aplico. Pero nunca me pasó por la cabeza que podía influenciar directamente la calidad de la educación que recibía, incrementando la cantidad de dinero que le destinaba a ello.

    Hasta que lo intenté. Dejé de buscar cantidad, y me enfoqué en calidad.

    Hoy en día prefiero mil veces tomar el toro por los cuernos y trabajar con un especialista en sesiones individuales de coaching, que comprar 10 cursos diferentes a un 95 % de descuento (tú sabes de qué plataforma hablo) — simplemente para nunca realmente darme el tiempo de ver los videos y hacer mi tarea.

    Cada uno de nosotros aprende de manera diferente. Yo encontré que me funciona mucho más tomar clases en vivo, acompañado de una cohorte de alumnos, que suscribirme a una plataforma de videos y verlos por mi cuenta. Descubrí que me funciona más comprar libros físicos y tenerlos a la mano de manera tangible, que buscar PDF gratuitos y leerlos en mi iPad.

    Muchas personas confundimos cantidad con calidad. Creemos que simplemente comprar libros, videos y suscripciones, cuenta como educación. No leer, ejecutar o participar. Comprar.

    Tener acceso a más información no es lo mismo que tener mejor educación.

    ¿Tú cuánto inviertes en tu educación al año? Y si tuvieras que duplicarlo, ¿simplemente invertirías más? ¿O invertirías más y mejor?

  • 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ú.

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.