• Seth Godin publica su post número 10,000

    Seth Godin:

    Give or take. It’s hard to get the exact count through the sands of time. But it’s at least 10,000 blog posts as of today.

    That’s 25 years, once or twice a day.

    Back of the envelope, that’s about 2 billion blog post views.

    I’ve written and edited every post myself, hence the typos. 3,000,000 words so far.

    I’m certain I couldn’t have done it all at once, and that I probably would have hesitated to sign up for a streak like this.

    The thing is, most of all, I’m grateful.

    Patrón. 🫡

  • ¿Importa el estado emocional en el que escribiste el código?

    En la última edición de amc queue abordan esta pregunta:

    Es cierto que el código puede decirte mucho sobre un programador, incluida su edad, el lenguaje en el que escribe con más frecuencia y su estado emocional cuando se escribió el código. Si dudas de mí, vuelve atrás y mira tu propio código y piensa en cómo te sentiste cuando lo escribiste.

    Al final de cuentas, el código es únicamente un medio para expresar una idea.

    El código, como la prosa, tiene estilo, color y sutileza, si somos lo suficientemente sensibles como para percibirlo. Cuando abras una función y empieces a leer, intenta pensar no solo: “¿Qué hace esto?” Pero también, “¿Cómo me siento al leer este código?” ¿Te enoja, te pone triste, feliz o algo más? Saber cómo te hace sentir el código te preparará mejor para entenderlo porque tendrás una pista importante en la mente del autor anterior. Y, como KV ha señalado muchas veces, el código está destinado a comunicar nuestras intenciones a otros humanos.

    100 %.

  • Un consejo sensato sobre cómo adaptarte al panorama cambiante de la IA

    Matan Abudy en su blog:

    Sí, los modelos de IA están mejorando cada semana, a veces todos los días. Hay algunos grandes avances. Pero lo que más importa es cómo usas la IA y cómo aprovechar al máximo un modelo determinado para tus necesidades.

    La programación, por ejemplo. Vale la pena invertir en aprender a codificar con LLM, ya que es muy desafiante (algunas buenas lecturas de Simon Willison y David Crawshaw). Eso es mucho más importante que decir: “¡Usa el nuevo Claude! Es increíble”, mientras que alguien más responde: “¿En serio? Claude ni siquiera tiene una ventana de contexto de 1M. Comparado con el nuevo Gemini, no es nada”.

    Aprende a usar las herramientas para tu trabajo. Haz el trabajo. Evalúa de vez en cuando. Repite.

  • Tobi Lutke, CEO de Shopify, publicó en Twitter el memo que mandó a su empresa. Muchas cosas interesantes, pero lo que más me llamó la atención fue el último punto:

    Antes de pedir más personal y recursos, los equipos deben demostrar por qué no pueden hacer lo que quieren hacer usando Al. ¿Cómo sería esta área si los agentes autónomos de Al ya fueran parte del equipo? Esta pregunta puede conducir a discusiones y proyectos realmente divertidos.

    No está diciendo que ya no van a contratar personas. Pero sí está diciendo que los equipos van a tener un poco más de fricción antes de decidir contratar a alguien para resolver un problema.

    Es una estrategia bastante sencilla, pero elegante: para cambiar el comportamiento de alguien, lo único que tienes que hacer es poner los incentivos adecuados. Si quieres que alguien deje de hacer algo, haces que ese algo sea más difícil. Y poco a poco cambiará el comportamiento.

    Si bien esto es interesante para la discusión sobre el impacto de la IA en la industria, también es prudente tomarlo con un granito de sal. Este es el CEO que hace unos años quiso duplicar su plantilla de ingenieros, nada más para recortarla fuertemente después.

  • El peor error que puede cometer un programador

    Esta mañana publiqué la última edición de mi newsletter:

    Ayer hace exactamente 25 años, Joel Spolsky publicó un famoso artículo que se volvió casi inmediatamente religión para toda una generación de programadores: Things You Should Never Do, Part I. 

    Joel explica el peor error que puede cometer un programador: reescribir su aplicación desde cero.

    Revisamos el contexto en el que Joel dio este consejo, y si realmente es todo lo que tienes que considerar. 

  • No importa qué estudies, tu carrera no está garantizada

    Acabo de terminar The Uncontrolability of the World de Hartmut Rosa. Este es uno de los mejores pasajes que he leído en mucho tiempo:

    En contraste con una situación en la que uno tenía tal vez solo una docena o dos ocupaciones calificadas para elegir, cada una vinculada a una vida y una trayectoria profesional claras: aprender en una panadería significaba convertirse en panadero, la formación como mecánico llevó a una carrera presumiblemente de por vida en ese campo hasta que uno se jubiló a los 65 años, y así sí, hoy en día es prácticamente imposible incluso hacer un seguimiento de todos los programas de formación profesional a nuestra disposición, y mucho menos predecir cómo podría ser nuestra vida profesional. Una trayectoria profesional predecible que podríamos planificar y al menos moldearnos parcialmente se ha convertido en un viaje errático e incontrolable. Y, a pesar de la imprevisibilidad e incontrolabilidad de nuestras circunstancias, todavía somos responsables de los resultados que se supone que hemos podido predecir, lo que da lugar a ansiedad.

    Todo el libro me voló la cabeza. 100 % recomendado.

  • Slim y sus herederos controlan casi el 15 % del valor de la BMV

    Inusual perfil de Carlos Slim en Bloomberg (link en español):

    Hoy Slim y sus herederos controlan cerca de 300 empresas. Seis de ellas, América Móvil, Grupo Carso, Grupo Financiero Inbursa, Telesites, Frisco e Ideal, cotizan en bolsa y representan cerca del 15% del valor bursátil del país.

    Solo 6 empresas son casi el 15 % de la Bolsa Mexicana de Valores. No se si habla muy bien de Slim, o muy mal de la BMV.

  • Lo que realmente quisiera hacer un developer en un día normal vs. lo que tiene que hacer

    En la última edición de newsletter de DX, Abi Noda analiza los resultados de un estudio de Microsoft, donde comparan las diferencias entre cómo los desarrolladores quisieran usar su tiempo, vs. lo que realmente sucede:

    El estudio encontró diferencias significativas entre cómo los desarrolladores realmente pasan su tiempo frente a cómo les gustaría. En sus semanas de trabajo reales, los desarrolladores dedican la mayor parte del tiempo a:

    • Comunicación y reuniones (12%)
    • Codificación (11%)
    • Depuración (9%)
    • Arquitectura y diseño de sistemas (6%)
    • Reseñas de códigos (5%)

    En sus semanas de trabajo ideales, los desarrolladores preferirían asignar su tiempo principalmente a:

    • Codificación (20%)
    • Arquitectura y diseño de sistemas (15%)

    Las mayores brechas se encontraron en la comunicación (esto incluye reuniones), abordando los tickets de soporte al cliente y seguridad y cumplimiento, donde los desarrolladores quieren pasar menos tiempo. Por el contrario, los desarrolladores quieren dedicar más tiempo a la codificación, la arquitectura y el diseño de nuevos sistemas y el aprendizaje de nuevas tecnologías, mientras mantienen una distribución más equilibrada en las actividades restantes.

    Cero sorpresas. Un programador quiere programar. Pero como dije anteriormente, creo que la industria está requiriendo que las personas que trabajamos en software hagamos más que saber escribir código:

    Yo también conozco programadores con 20 años de experiencia que están siendo rechazados por el mercado laboral. Y te puedo asegurar que no es porque sean malos programando: es porque no tienen las habilidades que el mercado está pidiendo.

    Es porque en esos 20 años que tienen trabajando, no se preocuparon por desarrollar ninguna otra habilidad además de programar.

    Cuando la empresa tiene máquinas textiles que pueden hacer más, más rápido, a menos costo, tu maestría en manejo de hilo y aguja es completamente irrelevante.

    Abi cierra con las tareas que más quieren automatizar algunos desarrolladores (que tampoco es ninguna sorpresa):

    Cuando se les preguntó qué tareas les gustaría más automatizar, las principales respuestas de los desarrolladores fueron:

    • Documentación (creación, actualización y mantenimiento de la documentación)
    • Configuración/mantenimiento del entorno (configuración de entornos de desarrollo)
    • Pruebas (autoría, ejecución y monitoreo de pruebas)
    • Seguimiento de tareas y gestión de backlog
    • Seguridad y compliance

    Todas estas son tareas que pueden (y deberían de) ser automatizadas en cualquier empresa de tecnología, en medida de lo posible.

    Pero observa que en esta lista no está “entender el negocio”, “llegar a acuerdos con los stakeholders”, o “dar feedback constructivo”. Y no están porque no se pueden automatizar. Sin embargo, todas esas son actividades que los desarrolladores encuestados citaron como cosas que les gustaría hacer menos.

    No hay peor ciego que el que no quiere ver, dicen. Puedes leer el whitepaper de Microsoft para que saques tus propias conclusiones.

  • NaNoWriMo deja de operar, entre otras cosas, por su postura con respecto a la IA

    James Folta

    En un correo electrónico, la organización sin fines de lucro anunció que están terminando las cosas para siempre. NaNoWriMo, que significa, para los no iniciados, el Mes Nacional de la Escritura de Novelas, fue fundada en 1999 como facilitador de desafíos y programas de escritura; el evento de marquesina es el sprint titular de noviembre para escribir 50.000 palabras en 30 días. Pero parece que una combinación de factores ha impactado la capacidad de las organizaciones para mantenerse a flote, a pesar de una gran y dedicada comunidad global de escritores.

    Aparentemente, no se pudieron recuperar después de algunos escándalos; primero sobre el comportamiento del staff y, más recientemente, sobre su postura con respecto al uso del AI:

    […] No quieren descartar la IA, porque “condenar categóricamente la IA sería ignorar los problemas clasistas y apleístas que rodean el uso de la tecnología, y que las preguntas sobre el uso de la IA se unen a las cuestiones sobre el privilegio”. Desde su perspectiva, la IA permite a todos escribir a pesar de las diferencias en las habilidades financieras, las diferencias en la capacidad física y mental, y las diferencias en el acceso a los recursos.

    Esto fue en septiembre del año pasado, y parece que desde entonces la comunidad de escritores se volteó en su contra y no se pudieron recuperar.

    Más evidencia de que la IA puede ayudar a terminar con organizaciones, independientemente de si la usan o no.

  • G-BOAG vuela por primera vez en 21 años: LHR → JFK en 3:33 horas

    Puedes ver el replay del vuelo en FlightRadar.

    En Instagram publiqué las fotos de cuando me pude subir al Concorde que tienen en el Intrepid Museum en Nueva York.

  • El 20 de mayo sale un nuevo libro sobre Sam Altman

    A propósito de mi post anterior, el 20 de mayo sale un nuevo libro sobre Sam Altman: The Optimist: Sam Altman, OpenAI, and the Race to Invent the Future. Esta es uno de mis géneros de libros favorites, y por supuesto, mi preorden está hecha.

    El WSJ publicó un extracto, con la historia detrás del episodio donde Altman fue despedido como CEO de la empresa.

  • Otro ejemplo más de la importancia de saber contar una historia

    ¿Cómo le ofreces perspectivas diferentes a alguien que cree que ya sabe todo lo que tiene que saber sobre un tema? 

    Ira Glass, leyenda de la radio en EEUU, citado por Steve Oney en Literary Hub:

    “El principal problema que tienes al hacer una historia sobre cualquiera de los grandes temas emocionales de nuestro tiempo, si las elecciones fueron robadas, si la vacuna funciona, qué pensar de Donald Trump, el cambio climático, es que todos ya saben lo que piensan. Si empiezas cualquier historia, todo el mundo dice: “Sí, sí, lo sé”. Hay un enorme obstáculo que superar para que la gente escuche incluso más allá de los primeros treinta y cinco segundos. ¿Qué haces? Al tener personajes, escenas y momentos sorprendentes y simplemente dejar que la cosa se desarrolle, puedes atrapar a las personas en la vida de las personas que estás documentando. Y luego seguirán escuchando para escuchar cómo funcionan las cosas”.

    Si la técnica funciona para hablar de política, vacunas y cambio climático, me atrevería a apostar que también funciona para tus propuestas técnicas.

  • Vibrando alto

    Acabo de publicar una nueva edición de mi newsletter. Hablo sobre el nacimiento del “Vibe Coding”, y por qué no es algo realmente nuevo.

    Regístrate aquí.

  • No es feedback, es…

    Eric Barker, en su post “How to become an expert at anything”:

    It’s not “feedback”; it’s a forensic investigation into your incompetence. Find a mentor.

    :chef-kiss:

  • Una red social hecha con Claude Code

    Craig Mod, en su newsletter,, comparte que recientemente creó y lanzó una red social (?) para sus suscriptores, usando Claude Code:

    Durante mucho tiempo, mi gusto por el software ha superado mi capacidad de ejecutar (principalmente en función de horas al día), pero ahora con herramientas como Claude Code, estoy descubriendo que la ejecución y el gusto se alinean de maneras asombrosas. No es exagerado decir que usar Claude Code para construir The Good Place (y también un montón de otras pequeñas herramientas y proyectos) es una de las experiencias informáticas más sorprendentes de mi vida. Es difícil articular cuán empoderamiento absoluto es una herramienta como Claude Code (emparejada con software maleable, software abierto, sistemas abiertos (es decir, no iOS/iPadOS)) para alguien como yo: alguien con una sólida formación técnica que puede guiar el LLM, sabe qué preguntas hacer y sabe cómo evitar que salga por tangentes extrañas. (Es como trabajar con un niño de ocho años que tiene mil años de conocimiento).

    Hoy en día, saber el aspecto técnico de lo que quieres hacer te ayuda a ser mucho más eficiente al utilizar un LLM para resolver un problema. Eventualmente no va a ser así.