TechLecturas

TechLecturas

Club de lectura sobre software y tecnología donde charlamos sobre algunos de los libros más importantes de nuestro sector. Formado por Alex Gascón (@AlexGasconB) y José Noguera (@joselkan), dos apasionados de la tecnología con experiencia en compañías como AWS, Red Hat o Stripe. Actualmente leyendo: The Software Engineer's Guidebook, de Gergely Orosz

  1. MAR 2

    A Philosophy of Software Design - Capítulos 1 y 2

    Buenaaaaasss Hacemos doblete esta vez con los dos primeros capítulos del libro: IntroducciónLa naturaleza de la complejidad¿De qué hablaremos? John Ousterhout abre el libro con una declaración de amor al software: programar es una de las actividades más creativas de la historia humana. Sin fricción física, sin límites del mundo real. Si lo puedes visualizar, lo puedes construir. Pero hay un enemigo silencioso: la complejidad. Y no nace de un gran error, sino de mil pequeñas decisiones que nadie tomó en serio. John la define como todo aquello que hace un sistema difícil de entender y modificar. Y se manifiesta de tres formas: Amplificación del cambio: tocas algo pequeño y tienes que modificar veinte sitios distintos.Carga cognitiva: para hacer cualquier cosa, primero necesitas tener media base de código en la cabeza.Unknown unknowns: ni siquiera sabes lo que no sabes. Y solo lo descubres cuando aparece el bug.Las causas raíz son dos: las dependencias —cuando nada puede entenderse de forma aislada— y la oscuridad —cuando la información importante no es obvia—. ¿Una variable que se llama tiempo? ¿En segundos? ¿Minutos? ¿Horas? Eso es oscuridad. Y lo más peligroso de todo: la complejidad es incremental. Nadie la crea de golpe. Se acumula. Cada pequeña concesión parece inocente, pero sumadas te inundan. La solución que propone John es casi filosófica: tolerancia cero. Como la teoría de la ventana rota. Si dejas que se acumule, acelera. Si la contienes desde el principio, el sistema se mantiene sano.

    33 min
  2. 09/28/2025

    The Software Engineer's Guidebook - 25 - Software Architecture

    ¡Casi último capítulo! Esta vez estamos hablaremos de Arquitectura Software: Simplicidad ante todo: Por qué en Uber no usaban UML ni herramientas complicadas - solo pizarra, cajas y flechas. La buena arquitectura no viene de herramientas "fancy" sino de decisiones pragmáticas1-way doors vs 2-way doors: El framework de Amazon para categorizar decisiones - desde cambios reversibles (A/B tests, linters) hasta compromisos mayores (cloud provider, arquitectura completa)Deuda de arquitectura y radio de explosión: Los costes ocultos de las malas decisiones arquitectónicas y cómo medir el impacto real de tus cambios (spoiler: deprecar APIs públicas no es lo mismo que refactorizar código interno)Arquitectura alineada con negocio: Por qué la arquitectura existe para servir al negocio, no al revés. Cuándo una arquitectura "mala" puede estar bien y cómo aprovechar cambios de negocio para mejorar la técnica"Bueno" mejor que "perfecto": La obsesión por la arquitectura perfecta puede cerrarte puertas futuras. Better done than perfect, pero sabiendo qué es "suficientemente bueno"Tipos de arquitectos: Desde el teórico en su "torre de marfil" hasta la "máquina de programar" - por qué los mejores equipos combinan ambos perfiles con respeto mutuo Enlaces: https://www.oreilly.com/library/view/foundations-of-scalable/9781098106058/https://www.oreilly.com/library/view/designing-data-intensive-applications/9781491903063/

    59 min

About

Club de lectura sobre software y tecnología donde charlamos sobre algunos de los libros más importantes de nuestro sector. Formado por Alex Gascón (@AlexGasconB) y José Noguera (@joselkan), dos apasionados de la tecnología con experiencia en compañías como AWS, Red Hat o Stripe. Actualmente leyendo: The Software Engineer's Guidebook, de Gergely Orosz

You Might Also Like