Oscar Swanros

  • El peor error que puede cometer un programador

    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.

    Netscape 6.0 finalmente está entrando en su primera versión beta pública. Nunca hubo una versión 5.0. El último lanzamiento importante, la versión 4.0, fue lanzado hace casi tres años. Tres años es un tiempo terriblemente largo en el mundo de Internet.

    Durante este tiempo, Netscape no avanzó, se quedó impotente, mientras su tajada del mercado se hacía cada vez más pequeña.

    Es un poco desvergonzado de mi parte criticarlos por esperar tanto tiempo entre lanzamientos. No lo hicieron a propósito, ¿verdad?

    Bueno, sí. Lo hicieron. Lo hicieron cometiendo el peor error estratégico que cualquier empresa de software puede cometer:

    Decidieron reescribir el código desde cero.

    Todos en algún momento fuimos ese programador que dijo que podía escribir código más limpio y escalable en un fin de semana si tan solo nos dieran la oportunidad. Y no digas que no: el programador que no dijo eso nunca fue junior.

    Pero esto es lo que quiero que tomes en cuenta: la crítica de Joel no es que la nueva versión haya tenido errores o funcionaba peor que la anterior, sino que, mientras Netscape se preocupaba por hacer un “big splash”, el resto de la industria, y su competencia, continuó iterando, avanzando y mejorando. Para cuando Netscape por fin lanzó su nueva versión “mejorada” ya era demasiado tarde.

    No para el código, ni para las buenas prácticas. Para la empresa — la estrategia del negocio. Y si el negocio no funciona, el código que escribes es irrelevante.

    Todo es más claro en retrospectiva. Puedes decir dhu, obvio sin detenerte a considerar que tal vez hoy mismo, en este momento, tú y tu empresa están tomando decisiones estratégicas para “mejorar” su producto igual que Netscape.

    Si les pasó a ellos, por supuesto que también te puede pasar a ti.

    Los programadores somos los que tenemos arranques de querer reescribir todo el código, pero la realidad es que las decisiones de ese calibre no las tomamos nosotros. Me sorprendería que un equipo de ingeniería pueda siquiera sugerir detener la operación de una empresa sin que el CEO les pregunte si su mamá los tiró de chiquitos.

    Netscape renunció a cualquier mejora potencial del producto en el momento en que decidieron dejar de iterar. ¿Por qué creyeron que reescribir todo el código era una buena estrategia de negocio? ¿De quién fue la idea? ¿Quién la aprobó?

    Los ingenieros de Mozilla decidieron a finales de octubre de 1998 desechar el código de Communicator y comenzar de nuevo desde cero utilizando el motor de renderizado Gecko que cumple con los estándares. Todos los recursos se movieron a trabajar en la versión de Netscape 6.0 usando Gecko, que algunos empleados de Netscape consideran uno de los mayores errores en la historia de la empresa.

    Ah… Para ser justos, 1998 fue un año tumultuoso para Netscape, pero bueno…

    Mi punto es que la responsabilidad de hacer que el negocio funcione no nada más es del equipo de liderazgo, sino de todos. En una empresa de software, un líder que no entiende (o no tiene ni la más mínima curiosidad de saber sobre) las implicaciones del desarrollo, y solo se dedica a dar órdenes y exigir, es tan peligroso como un programador que no entiende (o no tiene ni la más mínima curiosidad de saber) cuál es el problema que la empresa está intentando resolver, y nada más se dedica a hacer lo que el Project Manager le dijo.

    Ahora, el artículo de Joel ignora algo: a veces, la decisión estratégica correcta es reescribir la aplicación desde cero. En software, más que en cualquier otra área, no hay definitivos; todo depende del contexto.

    Por ejemplo, Siri. Todos los que tenemos un iPhone sabemos que es virtualmente inútil. Siri es un producto tan malo, que hasta ridículo se ha vuelto, y probablemente le va a costar a Apple algunos millones de dólares extra — no en desarrollo, sino en cuotas legales.

    Apple debió de haber reescrito Siri hace más de 10 años. Y aunque es muy difícil pensar que Apple vaya a tener el mismo final que Netscape (pronto, por lo menos), el producto sufre igual: nadie lo usa, y daría lo mismo que no existiera. Pero Apple, la compañía, sí tiene una reputación que está más golpeada que nunca. Lo que le tomó décadas construir, se le está yendo una respuesta incorrecta a la vez.

    En fin… el peor error que puede cometer una empresa no es reescribir el código desde cero, es hacerlo (o no) sin tomar en cuenta lo que esto significa para el negocio.

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

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

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

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

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

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

  • ¿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í.

  • Vibrando alto

    Basta con sentarte en tu computadora, abrir algún LLM y, con paciencia, decirle qué hacer. “Vibe coding.”

    Según lo que se comenta, esta forma de programar funciona bastante bien para hacer “aplicaciones para uno solo.” Los LLM todavía no son tan buenos como para entender todos los matices de desarrollar software que pueda escalar.

    Pero sí son buenos para resolver problemas específicos con código.

    Este artículo en Ars Technica tiene un punto interesante:

    “Si un LLM escribió cada línea de tu código, pero lo has revisado, probado y entendido todo, eso no es codificación de vibraciones en mi libro, eso es usar un LLM como asistente de escritura”. Vibe Coding, por el contrario, implica aceptar el código sin entender completamente cómo funciona.

    La cosa aquí es que, bajo esa definición, vibe coding no es nada nuevo. Muchos programadores llevan años — décadas — aceptando código sin entender completamente cómo funciona. Solo que, en vez de pedírselo a una IA, lo hacen con npm install en la terminal.

    Pero bueno… por lo menos con la IA no corres el riesgo de que tu aplicación (o el internet completo) se rompa por una protesta de otra persona.

    Como dije en 2021: si únicamente sabes programar, tu carrera tiene fecha de caducidad. Porque ahora ya ni siquiera tienes que correr un comando en tu terminal para obtener una solución que “funciona”, aunque no sepas cómo.

    Probablemente un LLM todavía no sea capaz de reemplazar completamente el rol de un desarrollador en una empresa. Sin embargo, mi punto es más válido que nunca: lo que te va a diferenciar ya no va a ser tu capacidad de escribir código.

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

  • Una compañía obsesionada con medir todo y tomar decisiones estrictamente basadas en datos tiene serios problemas:

     

    1. Anti-human. Measureship-driven corporations become increasingly anti-human as qualitative signals are deprecated and quantifiable efficiency and management-by-dashboard take over, often at the expense of basic common sense.

    2. Directionless. Lacking a forward-looking radar, measureship-driven corporations become confused and directionless over time. When you reflexively measure everything, what matters is rapidly buried beneath a morass of complexity, measurement theater, and bureaucracy.

    3. No New Ideas. Measureship-driven corporations struggle to innovate beyond the pursuit of incremental gains because backward-looking data must first evidence every forward-looking decision, eliminating entire categories of idea, imagination, experimentation, and innovation in the process.

    4. Lazily Value Extractive. Incrementalism and a lack of new ideas mean measureship-driven corporations are forced to pursue value-extractive tactics to grow because they lack the philosophical capacity, business systems, and imagination to do the hard work of value creation.

    Eventualmente llega un competidor que se enfoca más en la experiencia del usuario, y ya no eres relevante.

    La forma de contrarrestar esto es con buenas prácticas de liderazgo: 

    Have Empathy & Be Relentlessly Pro-Human: Where measureship believes that organizations should be led via quantitative dashboards, leadership rolls up its sleeves and focuses first on the human experience – for customers and employees. By starting from the principle of creating value for the people we serve rather than extracting it for ourselves, we can focus much more intently on innovation and the few metrics that matter rather than the many that do not.

    Elevate Qualitative Signals: Where measureship-driven corporations deprecate qualitative signals and ignore the obvious silo problems their method creates, the leadership-driven alternative elevates qualitative signals to help establish a more integrated competitive advantage. Qualitative signals provide an essential balance to the quantitative, together providing a superior understanding of the customer, their needs, wants, and desires.

    Create Narrative Driven Strategies: Human beings respond to story, narrative, and metaphor. To beat competitors stuck optimizing for the status quo, we must articulate strategies via a set of clear and compelling narratives that excite our people to change the status quo rather than optimize it. Where measureship-driven corporations manage via low-context incremental numerical uplift, leadership-driven alternatives lead via high-context, inspiring stories of the future we intend to create.

    Use Minimum Viable Metrics: While the measureship-driven organization wastes time, energy, and resources on the distracting and irrelevent measurement of everything, smart alternatives start from the position of MVM “Minimum Viable Metrics.” The idea being to identify the few measures that really matter so the organization can focus most of its energy and resources on creating value and a lot less on measuring & extracting it.

    Lead Through New Ideas: Because measureship struggles to innovate and has little capacity for new ideas, the leadership alternative is to lead through forward motion. When you are the one bringing new ideas to the table, you force measureship competitors to play catchup. Keep doing this, and they’ll never catch up because you’ve forced them into a permanent game of ‘behind the 8-Ball.’

    No podría estar más de acuerdo. Lee el artículo completo.

  • The Japanese Mind

    Acabo de terminar uno de los libros que me compré en mi viaje a Japón a inicios de mes, The Japanese Mind.

    En The Japanese Mind, Roger Davies ofrece a los occidentales una guía perspicaz para comprender los aspectos únicos de la cultura japonesa.

    Los lectores de este libro desarrollarán una comprensión integral de la sociedad japonesa y los valores fundamentales que permanecen en su fundación.

    Altamente recomendado si quieres ir a Japón, y entender un poco más de por qué las cosas son como son. 

  • Una de las personas que más tiempo lleva asistiendo a los conversatorios mensuales de Pathways, nos contó en la última edición sobre Momlancers:

    Momlancers surge cuando al convertirnos en madres, nos cuestionamos sobre: nuestra carrera, prioridades y estilo de vida. 

    Para algunas, seguir trabajando significaba hacerlo a medias, ajustando horarios y sacrificando sueños; para otras, significó dejar el trabajo por completo, enfrentándose a la incertidumbre de no saber cuándo volverían a tener una oportunidad laboral. 

    Esta es la realidad del 50% de las mujeres que se convierten en mamás, donde el mundo laboral no tiene espacio para ellas porque ser madre es incompatible con ser profesional.

    Por eso, en Momlancers queremos demostrar que las mamás también pueden ser exitosas, profesionales, talentosas y apasionadas. 

    Trabajamos junto a empresas para implementar políticas laborales flexibles, creando un ambiente donde el trabajo y la vida familiar pueden coexistir en armonía. 

    Aquí, visibilizamos y celebramos las historias de éxito donde una madre logra encontrar un lugar donde se prioriza la integración de nuestros roles, ser madre y profesional.

    Momlancers es una respuesta a la necesidad de muchas madres que buscan no tener que elegir entre su carrera y su familia, demostrando lo mucho que tienen que ofrecer, gracias a sus experiencias y habilidades únicas.

    No conocía esta iniciativa. Pero nada más de escuchar la emoción en la voz de quien nos lo compartía se me puso la piel chinita. 

    Qué chingón que haya iniciativas como esta.