Ensayos de software que me formaron

 (refactoringenglish.com)
74 puntos por GN⁺ 2025-10-02 | 3 comentarios | Compartir por WhatsApp
  • Aunque durante 20 años leí miles de publicaciones de blogs de software, solo unos pocos ensayos cambiaron de raíz mi forma de pensar, y aquí se presentan 10 ensayos clave, desde el "Joel Test" de Joel Spolsky hasta la defensa del JavaScript puro de Julia Evans
  • El "Joel Test" de Joel Spolsky plantea 12 preguntas para evaluar si un empleador respeta a los desarrolladores, y verifica si prioriza su tiempo y concentración mediante aspectos como control de código fuente, compilaciones diarias y corregir errores antes que nada
  • "Parse, don't validate" de Alexis King presenta una técnica para convertir datos a nuevos tipos al validarlos, mostrando que el sistema de tipos puede contribuir a mejorar la seguridad y la confiabilidad de una aplicación
  • "No Silver Bullet" de Fred Brooks distingue el trabajo de software entre complejidad esencial y complejidad accidental, y sostiene que los avances en herramientas y hardware no pueden lograr una mejora de productividad de 10x, aunque la IA introduce una variable en esa teoría
  • El ensayo de Julia Evans sobre JavaScript puro llevó a la conclusión de que ES2018 JavaScript por sí solo es suficiente incluso sin frameworks, y desde 2020 no se han integrado frameworks de JavaScript ni pasos de build en ningún proyecto

"Joel Test" de Joel Spolsky (2000)

  • Joel Spolsky es el mejor bloguero de software de todos los tiempos, y sus ensayos influyeron mucho en la forma en que el autor aborda el software
  • El "Joel Test" es un conjunto de 12 preguntas para evaluar qué tan bien un empleador invierte en su equipo de software

  • Lista de las 12 preguntas

    • ¿Usan control de código fuente?
    • ¿Pueden compilar en un solo paso?
    • ¿Hacen builds diarias?
    • ¿Tienen una base de datos de errores?
    • ¿Corrigen los errores antes de escribir código nuevo?
    • ¿Tienen un calendario actualizado?
    • ¿Tienen especificaciones?
    • ¿Los programadores cuentan con un entorno de trabajo silencioso?
    • ¿Usan las mejores herramientas que se pueden comprar con dinero?
    • ¿Tienen testers?
    • ¿Los nuevos candidatos escriben código durante la entrevista?
    • ¿Hacen pruebas de usabilidad de pasillo?

  • Mensaje central

    • Algunas preguntas han quedado desactualizadas, pero lo importante no es la pregunta en sí, sino el metapunto de la pregunta
    • Lo que Joel realmente pregunta es: ¿respetas a los desarrolladores?
    • Todas las preguntas evalúan si el empleador prioriza el tiempo y la concentración de los desarrolladores por encima de oficinas baratas y plazos de corto plazo
    • Se publicó en el punto más alto del boom puntocom, cuando los desarrolladores experimentados eran un recurso valioso, pero no todo el mundo lo entendía
    • El blog de Joel siempre presentaba a los programadores como genios raros y delicados, como personas que los empleadores debían buscar y valorar
    • A lo largo de su carrera, el autor buscó empleadores que obtuvieran puntajes altos en el Joel Test y agradece a Joel por haberle dado esa guía

"Parse, don't validate" de Alexis King (2019)

  • Aunque es un ensayo sobre cómo aprovechar el sistema de tipos de Haskell, cambió de raíz la forma de pensar sobre software incluso sin interés en Haskell o en los sistemas de tipos
  • La técnica de Alexis puede usarse en cualquier lenguaje con tipado estático, como Go, C++ o Rust

  • Concepto clave

    • Cada vez que se validan datos, se deben convertir a un nuevo tipo
    • Ejemplo: si hay una regla que limita el nombre de usuario a un máximo de 20 caracteres alfanuméricos, la solución ingenua sería una función validateUsername(username string) error

  • Problema

    • El código es inseguro por defecto
    • Como hay que validar todos los nombres de usuario recibidos, es fácil crear por error una ruta de código que procese un nombre de usuario sin validarlo
    • Si un usuario malicioso encuentra ese error, podría insertar código malicioso en el campo de nombre de usuario o llenarlo con miles de millones de caracteres para agotar los recursos del servidor

  • Solución de Alexis

    • Usar una función parseUsername(raw string) (Username, error)
    • En el resto del codebase, usar el tipo personalizado Username en lugar de un string llamado "username"
    • La única función que puede crear un Username es parseUsername, y aplica las reglas de validación antes de devolver una instancia de Username
    • Si existe una instancia de Username, debe contener un nombre de usuario válido
    • Como toda entrada no confiable siempre es string, no se puede pasar un string a una función que espera Username

  • Impacto

    • Antes de este ensayo, se pensaba que los sistemas de tipos eran una forma curiosa de distracción para nerds de lenguajes
    • "Parse, don't validate" abrió los ojos a cuán valiosas pueden ser las capacidades del compilador para mejorar la seguridad y la confiabilidad de una aplicación

"No Silver Bullet" de Fred Brooks (1986)

  • En la universidad se leyó The Mythical Man-Month de Fred Brooks
  • Es una colección de ensayos de ingeniería de software basada en su experiencia dirigiendo el proyecto OS/360 de IBM

  • Complejidad esencial y complejidad accidental

    • Complejidad esencial: el trabajo que necesariamente debe hacerse sin importar las herramientas ni el hardware
      • Ejemplo: en un software para calcular bonos de vendedores, definir la fórmula del bono y cubrir todos los casos límite
      • Es el mismo trabajo ya sea con una supercomputadora de $5B o con un microcontrolador de $1
    • Complejidad accidental: todo lo demás
      • Manejar fugas de memoria, esperar a que compile el código, averiguar cómo usar bibliotecas de terceros
      • Cuanto mejores son las herramientas y los recursos de hardware, menos tiempo se gasta en complejidad accidental

  • Conclusión de Brooks

    • Es imposible que los avances en herramientas o hardware produzcan una mejora de 10x en la productividad del desarrollador
    • Incluso si todas las actividades accidentales se redujeran a cero tiempo, no podría lograrse esa escala de mejora a menos que representaran más de 9/10 del esfuerzo total

  • Casos de aplicación

    • A lo largo de su carrera, el autor vio a gente intentando eliminar al programador del software
    • Las plataformas no-code generan entusiasmo prometiendo a personas no programadoras todo el poder de un desarrollador web experimentado
    • El ensayo de Brooks siempre da tranquilidad al recordar que la plataforma de moda del momento no puede reemplazar a los desarrolladores
    • Las plataformas se enfocan en la complejidad accidental, no en la complejidad esencial
    • Aunque una plataforma pudiera crear mágicamente código funcional a partir de una especificación de funciones, todavía haría falta alguien que escriba esa especificación

  • Impacto de la IA

    • La IA moderna mete una llave inglesa en la teoría de Brooks
    • La IA realmente reduce la complejidad esencial
    • Si se le da a una IA una especificación incompleta o contradictoria, puede tomar prestado de especificaciones similares y llenar los huecos
    • Incluso si la IA elimina la programación conocida, el ensayo de Brooks sigue dando la esperanza de que al final todavía hará falta alguien que gestione la complejidad esencial en cualquier nivel de abstracción

"Choices" de Joel Spolsky (2000)

  • Fue difícil elegir solo un ensayo favorito de Joel Spolsky, así que se eligieron dos
  • "Choices" trata sobre la creación de interfaces de usuario y el costo sutil de darles poder a los usuarios

  • Mensaje central

    • Cada vez que ofreces una opción, le estás pidiendo al usuario que tome una decisión
    • Eso significa que el usuario debe pensar y decidir sobre algo
    • No siempre es malo, pero en general conviene intentar minimizar la cantidad de decisiones que la gente tiene que tomar

  • Ejemplo de Windows 98

    • Joel comparte un absurdo cuadro de diálogo que aparece al buscar documentación de ayuda en Windows 98
    • Razones por las que ese cuadro de diálogo enfurecía a Joel:
      • Interrumpe al usuario cuando intenta obtener ayuda
      • Le pide tomar una decisión sin información sobre la optimización de una base de datos
      • Windows evita decidir y le pasa la carga al usuario

  • Alcance de aplicación

    • El ensayo de Joel se enfoca en interfaces gráficas de usuario, pero el autor lo considera en todos los lugares donde alguien puede encontrarse con código, incluidos la línea de comandos u otros desarrolladores que llaman funciones escritas por él
    • Pensar si se pueden tomar decisiones útiles por el usuario, al mismo tiempo que se le da control sobre lo que realmente le importa
    • El ensayo de Joel ha evitado innumerables veces trasladar al usuario decisiones que podría tomar uno mismo

Raymond Chen, "“Application compatibility layers are there for the customer, not for the program” (2010)

  • Raymond Chen es uno de los desarrolladores con más años en el equipo de Microsoft Windows
  • En su blog hay miles de historias útiles y divertidas sobre la historia de la programación en Windows

  • Caso de solicitud de un cliente

    • Solicitud de un cliente sobre el modo de compatibilidad de Windows Vista:
      • Un programa diseñado para Windows XP y Windows Server 2003 tenía dificultades en Windows Vista
      • Si se configuraba en modo de compatibilidad de Windows XP, funcionaba bien en Vista
      • Preguntaban qué cambios había que hacerle al instalador para que, al ejecutarse en Vista, corriera automáticamente en modo de compatibilidad con XP

  • La analogía de Raymond

    • "Normalmente tiro basura en la banqueta frente a la tienda de mascotas y, cada mañana cuando abre la tienda, alguien barre la basura y la tira al bote. Pero la tienda de mascotas no abre los domingos, así que el domingo la basura simplemente se queda ahí. ¿Qué tengo que hacer para que la tienda de mascotas abra también los domingos?"

  • La lección

    • La analogía es tan divertida que apenas ahora me doy cuenta de que Raymond estaba equivocado
    • Se burla del pecado de los desarrolladores que esperan que Windows no rompa sus apps después de una sola versión
    • No estoy de acuerdo con los detalles, pero los textos de Raymond son tan entretenidos y agudos que uno puede pasar por alto sus defectos
    • Gran lección sobre cómo influir en el comportamiento del usuario:
      • Si quieres inducir a los usuarios a hacer algo que te ayude, debes pensar cuidadosamente, desde su punto de vista, cuál es el camino de menor resistencia
      • Si les muestras que tirar la basura en la banqueta resuelve por completo el problema, van a seguir haciéndolo

Erik Kuefler, "Don’t Put Logic in Tests" (2014)

  • Al autor siempre le gustaron las pruebas unitarias y sentía mucho orgullo por su código de pruebas
  • Este ensayo apareció en el baño y le reveló con shock que había estado escribiendo pruebas horribles toda su carrera

  • Ejemplo de una prueba problemática

    @Test public void shouldNavigateToPhotosPage() {  
  String baseUrl = "http://plus.google.com/";;  
  Navigator nav = new Navigator(baseUrl);  
  nav.goToPhotosPage();  
  assertEquals(baseUrl + "/u/0/photos", nav.getCurrentUrl());  
}

  • Problemas detectados

    • Cuando leí el ensayo por primera vez, pensé: "¡Así es exactamente como yo escribo pruebas unitarias!"
    • ¿Por qué duplicar la cadena http://plus.google.com/ en dos lugares? Como en código de producción, crear una única fuente de verdad
    • Yo siempre agregaba funciones helper, variables y loops para eliminar duplicación en las pruebas
    • El problema es que este enfoque oculta bugs sutiles: en realidad hace assert de http://plus.google.com//u/0/photos (doble slash)

  • El descubrimiento

    • El ensayo de Erik muestra que no se debe tratar el código de pruebas como si fuera código de producción
    • Ambos tienen objetivos y restricciones completamente distintos
    • Un buen código de pruebas debe ser, ante todo, claro
    • El código de pruebas no tiene su propio código de pruebas, así que la única forma de verificar su exactitud es inspeccionándolo
    • Las pruebas deben dejar dolorosamente obvio al lector qué comportamiento están afirmando
    • Para lograr ese objetivo, se puede tolerar la duplicación a fin de reducir complejidad

Julia Evans, “A little bit of plain Javascript can do a lot” (2020)

  • Como ingeniero de software, entré al mundo web vergonzosamente tarde
  • Durante los primeros 10 años de mi carrera solo escribí código para apps de escritorio y servidores backend
  • Hasta 2017 no le presté atención a HTML ni a JavaScript

  • Malentendido sobre los frameworks

    • Cuando empecé a aprender frontend en serio, tenía la impresión de que JavaScript era un lenguaje desastroso hecho en 10 días y que su comportamiento variaba mucho entre navegadores
    • Para escribir apps web, necesitabas algo moderno y sofisticado que te protegiera de toda la bilis y los defectos de JavaScript
    • Probé frameworks web populares como Angular, React y Vue
    • Aprendí bastante de Vue, pero aun así seguía perdiendo muchísimo tiempo en problemas de dependencias y trampas del framework
    • Incluso después de todo lo que estos frameworks frontend hicieron para arreglar JavaScript, programar para la web seguía siendo terrible

  • Lo que me hizo ver el ensayo de Julia

    • Me di cuenta de que estaba tan convencido de que JavaScript necesitaba ser arreglado que nunca le di una oportunidad
    • Estaba trabajando en un prototipo de TinyPilot y planeaba implementar la interfaz web con Vue
    • El ensayo de Julia me inspiró a ver hasta dónde podía llegar con JavaScript puro
    • Sin frameworks, sin librerías wrapper, sin pasos de build, sin Node.js, solo JavaScript común (ES2018)
    • Seguí esperando toparme con un problema que me obligara a pasarme a un framework o a un builder, pero nunca ocurrió
    • Hubo algunas trampas relacionadas con WebComponents, pero nada comparado con el dolor que sufrí con Vue y Angular

  • La libertad de no usar frameworks

    • Me encanta liberarme de los frameworks
    • Cuando hay un error en runtime, el stack trace no es una pesadilla de código minificado, transformado y tree-shaken
    • Es depurar mi código tal como lo escribí
    • Mis prejuicios sobre JavaScript estaban equivocados
    • El JavaScript moderno es bastante bueno y ha absorbido muchas ideas de las librerías wrapper, así que ya no hacen falta wrappers
    • Los navegadores se pusieron las pilas para garantizar un comportamiento consistente entre plataformas y dispositivos
    • Desde 2020 no he integrado frameworks de JavaScript ni pasos de build en ningún proyecto nuevo, y no he mirado atrás
    • Con JavaScript puro obtienes el 90% de las ventajas de un framework con solo el 5% de los dolores de cabeza

Dan McKinley, “Choose Boring Technology” (2015)

  • Es un ensayo raro de incluir en esta lista porque en realidad nunca lo he leído
  • La gente citaba este ensayo y, una vez que entendí la idea, me pareció tan intuitiva que no sentí necesidad de leerlo

  • Idea central

    • Al arrancar un proyecto nuevo, existe la tentación de usar tecnología de punta que está dando mucho de qué hablar
    • Google anunció una nueva base de datos que escala hasta exabytes, es 40% más rápida que Postgres y cuesta 20% menos
    • Parecería tonto usar Postgres cuando esa alternativa nueva y sexy está ahí mismo
    • En realidad, las tecnologías nuevas tienen bugs y debilidades, pero todavía no son evidentes
    • Cuando te topas con eso, te quedas perdido
    • Postgres tiene sus problemas, pero después de 30 años de experiencia en el mundo real, tiene soluciones comprobadas para casi cualquier problema que probablemente enfrentes

  • El concepto de tokens de innovación

    • Dan reconoce que a veces sí hay que usar tecnología nueva, pero solo de forma estratégica y en cantidad limitada
    • Todo negocio recibe tres "tokens de innovación" para gastar
    • Si quieres esa base de datos nueva y llamativa, tienes que gastar uno de esos tokens
    • El ensayo de Dan encaja de forma natural con el de Julia
    • Ojalá hubiera leído cualquiera de los dos antes de desperdiciar tanto tiempo con frameworks frontend

Terence Eden, “I’ve locked myself out of my digital life” (2022)

  • Terence Eden es un bloguero tecnológico ameno y ecléctico
  • Escribe varios textos nuevos cada semana, pero el que más impacto tuvo fue “Me dejé fuera de mi propia vida digital”

  • Escenario de desastre

    • Simula qué pasaría si un rayo cayera sobre la casa de Terence y destruyera todas sus pertenencias
    • Guarda en el administrador de contraseñas las contraseñas de todo
    • Si todos los dispositivos son destruidos, ya no puede acceder al administrador de contraseñas
    • No podía reemplazarlo con passkeys de hardware porque esas también estaban en su casa

  • Revelación

    • El autor sentía que sus datos estaban bastante seguros porque guardaba todo en unidades redundantes y tenía respaldos externos en tres continentes con dos proveedores
    • El texto de Terence lo hizo pensar en muchas amenazas creíbles que podrían eliminar todos los dispositivos al mismo tiempo: incendios, inundaciones, sobretensiones eléctricas, investigaciones criminales
    • Como todos los datos están cifrados con contraseñas que están en su cabeza, también se suman a la lista la amnesia, la incapacidad y la muerte

  • El problema de los servicios en línea

    • Los servicios en línea son frágiles cuando se trata de ayudar a los usuarios a recuperarse de un desastre
    • Usa varios servicios que asumen que es imposible perder el teléfono, sin mencionar la cuenta de correo y todos los dispositivos digitales que posee

  • Impacto

    • Desde que leyó el ensayo de Terence, piensa más en qué servicios y dispositivos son importantes, y en cómo podría recuperarse en el escenario que Terence describe
    • Cuando compró su siguiente laptop, la configuró en una biblioteca para probar si podía recuperar el acceso a su administrador de contraseñas y a sus cuentas importantes sin usar los dispositivos que tenía en casa
    • Todavía podría mejorar mucho más su preparación ante desastres digitales, pero el texto de Terence sigue resonando en su cabeza cada vez que piensa en cómo asegurar sus dispositivos y datos
    • ¿Qué pasaría si de pronto todo fuera destruido?

Bonus: “parsing user input” de Brad Fitzpatrick (2009)

  • Técnicamente no es un ensayo, pero sigue pensando constantemente en una cita de una entrevista sobre software
  • Leyó Coders at Work como resultado de la elogiosa reseña que Joel Spolsky hizo en 2009
  • Es una colección de entrevistas con programadores exitosos

  • La cita de Brad Fitzpatrick

    • Brad Fitzpatrick, fundador de LiveJournal y Memcached, aparece como uno de los entrevistados
    • En ese momento tenía 28 años, era el programador más joven del libro y también el más malhablado y divertido
    • Ante una pregunta sobre ética en la ingeniería de software, lanzó una apasionada defensa de la validación de entrada:
      • “Quisiera pedir que todo el mundo permitiera de manera consistente escribir espacios o guiones en los formularios de tarjetas de crédito. Las computadoras son buenas para quitar esas cosas. No me digan cómo debo formatear mis números.”

  • Aplicación

    • Cada vez que intenta pegar un número de teléfono en un formulario web, recuerda esa cita
    • Se queja cuando no se permiten paréntesis o espacios, o peor aún, cuando por culpa de los paréntesis el sistema recorta el número y luego se queja de que no se permiten paréntesis
    • Cada vez que crea un campo de entrada en software y piensa en caracteres inesperados, escucha a Brad Fitzpatrick decir: “Las computadoras son buenas para quitar esas cosas”

Lecturas relacionadas

3 comentarios

 
shakespeares 2025-10-07

Es gracias a la historia que existe el presente.
 
GN⁺ 2025-10-02
Opiniones en Hacker News

  • Después de leer el artículo "I've locked myself out of my digital life", sentí que expresaba muy bien una preocupación que yo tenía pero me costaba explicar
    En el mundo analógico probablemente podría convencer a otra persona de quién soy, verificar mi identidad y recuperar acceso a mi cuenta, pero frente a los algoritmos implacables del mundo digital, si no tienes credenciales no sirve de nada suplicar
    Ni siquiera la empresa de mi servicio de gestor de contraseñas tiene permiso para acceder a mis contraseñas
    Ni siquiera existe alguien a quien convencer, y al final el código es la ley
    Creo que todo el mundo debería entender este problema antes de defender que se elimine la atención presencial de todos los procesos
    En el artículo suena como una situación poco común, pero perfectamente puede pasar en un desastre natural o en un robo
    Artículo relacionado: https://shkspr.mobi/blog/2022/06/ive-locked-myself-out-of-my-digital-life/

    • No creo que en realidad haya mucha gente a favor de este tipo de automatización extrema o de reducir al mínimo la interacción cara a cara
      Y este problema no es exclusivo de la IA; el software basado en reglas también tiene el mismo defecto
      En la Unión Europea (UE), la ley garantiza el derecho a apelar cualquier decisión ante un ser humano

  • Grug Brained Developer es un texto que siempre se me quedó en la cabeza, aunque no estaba en la lista
    Puede ser que más que cambiarme la forma de pensar, simplemente se me quedó grabado porque ya estaba de acuerdo con lo que decía
    Referencia: https://grugbrain.dev/

    • De todo eso, me encantó la parte de "encerrar por fin al demonio de la complejidad en un cristal debidamente corregido es la mejor sensación"

    • Soy bilingüe y el inglés es mi segundo idioma, así que los textos con el estilo de grug brain me resultan bastante difíciles de leer y entender
      Ni siquiera sé qué significa la palabra "grug"
      Aun así, sigo disfrutando mucho ese blog

  • No estoy de acuerdo con la conclusión sobre "No Silver Bullet" de Fred Brooks
    No comparto la idea de que la IA reciente haya reducido la complejidad esencial al punto de refutar la tesis de Brooks
    La IA puede completar automáticamente especificaciones incompletas o contradictorias tomando como referencia casos parecidos, pero la complejidad esencial sigue sin resolverse lo suficiente ni siquiera con IA, y creo que seguirá siendo imposible hacerlo por completo
    Mi análisis detallado al respecto está aquí: https://smartmic.bearblog.dev/no-ai-silver-bullet/

    • Gracias por leerlo y por compartir mi texto
      Como mencionaste en tu explicación, coincido en que los LLM no pueden eliminar por completo la complejidad esencial
      Pero sí creo que pueden reducirla hasta cierto punto
      Como ejemplo concreto, le pedí a Claude 4.1 Opus que definiera un lenguaje específico de dominio para generar imágenes por computadora
      Yo solo le di los requisitos y dejé ambiguos varios detalles, y el LLM redactó la especificación
      En un caso así, creo que sí se puede afirmar que el LLM redujo la complejidad esencial
      Yo mismo podría definirlo desde cero con alta calidad, pero si lo que entrega el LLM ya es suficientemente bueno, hay menos motivo para invertir esfuerzo adicional en mejorarlo
      Originalmente yo sentía poca necesidad de los LLM porque programo mejor y además disfruto hacerlo, pero al usarlos vi que absorben una parte importante de la complejidad esencial en tareas donde no vale la pena gastar mi tiempo y energía
      Ejemplo: https://kagi.com/assistant/1b8324a2-ae54-4a1b-9c69-51d76fc5c7d1

    • La complejidad que la IA reduce al final es solo la carga cognitiva de quien escribe el código
      La "complejidad no esencial" de la que hablaba Brooks sigue estando casi toda en el código mismo
      Como resultado, esa carga se le transfiere a la persona que luego tiene que leerlo
      Es como ponerse un exoesqueleto para subir un objeto pesado a un estante y después pedirle a un compañero que lo pinte bonito

  • En mi opinión, el ensayo "Parse, don't validate" ya es un clásico
    Y la frase "Don't put logic in tests" me cuesta más aceptarla
    En el ejemplo, el problema surge porque se debería usar un tipo URI en vez de una cadena, y yo pienso que el código de pruebas también debería considerarse código de producción, ya que influye en el éxito o fracaso del despliegue
    De cualquier forma, este tipo de discusiones valen totalmente la pena revisarlas y pensar si aplican a tu caso

    • A mí también me sorprende que "Parse, don't validate" no sea más conocido
      En mi entorno casi todos usan Go, Python o C++, así que parece ser famoso solo del lado de los lenguajes funcionales
      Creo que la crítica al ejemplo de "Don't put logic in tests" es válida
      Tal vez podrían cambiar el ejemplo por uno mejor, pero la idea importante es que hasta una simple concatenación de cadenas puede agregar complejidad a una prueba y hacer que se escape un bug

    • En lo personal, me atrae la filosofía de no meter demasiada lógica en las pruebas
      He tenido varias experiencias con falsos positivos causados por bugs en el código de pruebas, y eso me volvió desconfiado con este tema
      No creo que uno deba sentir la necesidad de escribir "pruebas para las pruebas"
      En la práctica esto no era muy común, pero últimamente el problema ha empeorado porque se está volviendo tendencia el código de pruebas mediocre escrito por LLM, independientemente de esa filosofía

  • Recomiendo el material de investigación y revisión de Nancy Leveson sobre el accidente de Therac-25

  • Para mí, uno de mis textos favoritos en este campo es "The Parable of the Two Programmers" de Neil W. Rickert
    Es una historia que resume de forma concisa la vida y los desafíos de los programadores
    https://c00kiemon5ter.github.io/code/philosophy/2011/10/30/Tale-of-two-Programmers.html

    • Conozco bien a Neil porque durante años interactué con él con frecuencia en el grupo de noticias de Usenet comp.ai.philosophy
      El tono y el contenido del texto son totalmente su estilo

    • Este texto es realmente excelente

  • En mi caso, este artículo fue un punto de inflexión
    https://stevemcconnell.com/articles/software-quality-at-top-speed/

    McConnell no es tan conocido por aquí

    • ¡Gracias por compartirlo!
      Es la primera vez que leo este texto, pero al comienzo de mi carrera leí Code Complete y me impresionó muchísimo
      Lo seguí teniendo en el librero y cada vez que lo releía unas cuantas veces pensaba: "¡Esto es realmente buenísimo! Tengo que volver a leerlo algún día"
      Hacía tiempo que no sabía nada de McConnell, así que me llamaba la atención que mientras otros autores de su misma generación, como Kent Beck, Martin Fowler y Ward Cunningham, siguieron escribiendo aunque perdieron popularidad después de los 2000, McConnell en cambio hubiera estado tan callado
      Me sorprendió un poco enterarme de que dejó el software y se cambió a la asesoría financiera
      https://raindogllc.com/steve-mcconnell-investment-advisor/

  • No es estrictamente un ensayo de software, pero la entrada de blog "Ban on Imports" de Gilad Bracha cambió por completo mi forma de ver los sistemas de módulos
    Subraya que import/export equivale prácticamente a estado global, y por eso arrastra todos los mismos problemas del estado global
    Desde entonces valoro mucho más el concepto de inyección de dependencias
    https://gbracha.blogspot.com/2009/06/ban-on-imports.html

  • Puede que no sea fácil clasificarlo estrictamente como ensayo de software, pero "Don't Call Yourself A Programmer, And Other Career Advice" de Patrick McKenzie es una verdadera mina de oro
    https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/

  • Como alguien muy interesado en los lenguajes de programación, el texto "slumming with basic programmers" es uno de los que más se me quedó en la cabeza
    https://prog21.dadgum.com/21.html
 
secret3056 2025-10-02

Coincido totalmente con lo de parsear la entrada del usuario.
¿En qué clase de entorno trabajan tantos programadores que desarrollan la función para ingresar un número de teléfono alternativo, que le tienen tanto miedo a llamar replace() dos veces sobre una cadena?