TechLecturas

¡Hola hola hola hola! ¡Bienvenidos y bienvenidas una semana más a TechLecturas!

En el episodio de hoy seguimos con A Philosophy Of Software Design, y debatimos el capítulo 4: "Los módulos deberían ser profundos". Podréis encontrar cosas tan interesantes como:

• A qué nos referimos cuando hablamos de la "profundidad" de un módulo
• Por qué las mejores interfaces son las que no existen
• Un ejemplo (más) de que seguir Clean Code a ciegas no siempre es bueno

(Además, como bonus, podréis escuchar a uno de nosotros cantando una canción ganadora de un Oscar. Si queréis saber cuál, tenéis que escuchar el capítulo)

Lo primero: PERDÓOOON POR EL AUDIO. Se nos fue el pistón un par de veces, no nos muteamos a tiempo y festival del ruido.

Ahora sí, ¡capítulo 3! Que el código funcione no es suficiente.

Hoy hablamos de dos formas de programar. Y spoiler: solo una de ellas te va a salvar el cuello a largo plazo.

La primera es la programación táctica, ese modo en el que entras cuando hay un deadline que no perdona, un bug que está petando producción o simplemente necesitas sacar algo ya. No piensas en el diseño, no piensas en el futuro. Simplemente necesitas que funcione.

La alternativa es la programación estratégica. Y aquí Ousterhout te pide un cambio de mentalidad: tu objetivo no es que el código funcione. Tu objetivo es que el código sea bueno y que funcione. Pensar como un inversor, no como un bombero.

¿Cuánto tiempo hay que invertir? John lo cuantifica. Y te va a sorprender.

Y esto aplica también a las startups, aunque suene contra intuitivo. Facebook lo aprendió a las malas, cambiando su famoso "move fast and break things" por "move fast with solid infrastructure". Nosotros daremos nuestro punto de vista al respecto.

Buenaaaaasss

Hacemos doblete esta vez con los dos primeros capítulos del libro:

• Introducción
• La 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.

¡Hemos vuelto! ¡Año nuevo, libro nuevo!

Efectivamente, TechLecturas está de vuelta una semana más, y qué mejor forma de estrenar el año... ¡que con un libro nuevo! Empezamos "A Philosophy of Software Design", de John Ousterhout: un libro con el que dejamos de lado las soft skills y el mundo del management para centrarnos en los fundamentos del software y de cómo diseñarlo bien

En este capítulo os comentamos qué esperar de A Philosophy of Software Design (APOSD para los amigos), y nuestras primeras impresiones. ¡No dudéis en hacernos llegar vuestros comentarios, y esperamos que os guste!

Referencias:

• Google Group sobre el libro: https://groups.google.com/g/software-design-book

¡Hola hola hola hola! Os pensábais que ya os habíais librado de nosotros, ¡pero no! Santa Claus ha llegado a TechLecturas un poco antes de lo previsto, y ha venido con... ¡un capítulo extra sobre The Software Engineer's Guidebook!

Tal y como ya hicimos con The Making of a Manager, hemos querido cerrar el libro con un capítulo de conclusión, en el que comentamos nuestras impresiones sobre el libro, qué cosas nos han gustado y qué cosas no, así como nuestra experiencia personal con el podcast y cómo ha ido cambiando a medida que pasaban los capítulos.

Por último, revelamos cuál será el próximo libro que leeremos en el podcast, y compartiremos un poco más de detalle sobre el proceso que seguimos para tomar la decisión (y sobre los libros que hemos descartado por el camino)

Con esto, esta vez sí, cerramos un 2025 en el que no podemos más que estar agradecidos por todo el apoyo y el cariño recibidos. ¡Nos vemos en 2026 con más y mejores TechLecturas!

Formulario de feedback: https://forms.gle/DzT21eeN12Mc4XjS7

Bueno, finalmente ha llegado el momento: capítulo 26 y último de The Software Engineer's Guidebook. Ha sido un largo y entretenido viaje, ¡pero ya hemos llegado al final!

En este capítulo de conclusión, Gergely cierra por todo lo alto hablándonos de la importancia del aprendizaje, con temas como:

• La importancia de mantener la curiosidad
• Técnicas para aprender
• Consejos para estar al día con la industria
• No olvidarse de descansar

Como siempre, ¡no dudéis en hacernos llegar vuestros comentarios! ¡Esperamos que lo disfrutéis!

¡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áticas

• 1-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/

¡Hola hola hola una vez más! No se nos ocurre mejor forma de afrontar la vuelta de Septiembre que aprendiendo más con Gergely

Hoy nos toca hablar de sistemas resilientes y todo lo que les rodea. Podréis encontrar perlas como:

• De qué te preocupas cuando te preocupas por la resiliencia
• Buenas prácticas para monitorizar mediante logs y métricas
• Por qué son tan problemáticas las alertas silenciosas como las ruidosas (y cómo evaluar cómo es la nuestra)
• Cómo gestionar oncall e incidentes para que no os fastidien la vida

Además, los enlaces que os prometemos durante el capítulo:

• Core Web Vitals: https://support.google.com/webmasters/answer/9205520?hl=en

• F-score https://en.wikipedia.org/wiki/F-score 

• SLI SLO SLA: https://cloud.google.com/blog/products/devops-sre/sre-fundamentals-slis-slas-and-slos

• Little Bobby Tables https://xkcd.com/327/

Como siempre, ¡no dudéis en hacernos llegar vuestros comentarios y sugerencias! ¡Y recordad que estamos buscando el próximo libro, avisadnos si tenéis alguna petición!

¡Volvemos a la carga!

• Cómo programar siendo Staff Engineer: Bloquea tiempo dedicado, haz pair programming y predica con el ejemplo - tu código será el estándar que siga todo el equipo (¡con gran poder viene gran responsabilidad!)
• Procesos universales que funcionan: Definition of done, guías de estilo forzadas por CI, post-commit reviews, y la importancia de limpiar experimentos y feature flags que ya no sirven
• Herramientas para la eficiencia: Services catalog, búsqueda de código avanzada, developer portals (como Backstage de Spotify), entornos de desarrollo en la nube y cómo usar IA sin volverse dependiente
• El eterno dilema: Buy vs Build vs Adopt: Cuándo construir, cuándo comprar (spoiler: 25k/año son 3 meses de salario de un ingeniero) y cómo evitar el vendor lock-in
• Compliance y privacidad no son opcionales: GDPR, HIPAA, PCI DSS - tu industria tiene sus regulaciones, y prepararse para auditorías puede llevar meses (como le pasó a Uber)
• Desarrollo seguro desde el principio: OWASP, gestión de dependencias, pentesting regular y por qué necesitas involucrar al security engineer (1 por cada 100 devs) desde la planificación de proyectos

Enlaces

• https://rubocop.org/
• https://docs.astral.sh/ruff/
• https://github.com/psf/black
• https://youtu.be/y8OnoxKotPQ?si=qSk4LMYcW4ov2-jt

¡Aquí estamos otra vez! Hoy comentamos el capítulo 22 del libro, "Colaboración"

En este episodio hablamos de lo único más difícil que escribir código cuando eres Staff+ Engineer: trabajar con gente. Tendremos algunos temas tan interesantes como:

• La diferencia entre politiqueo e influencia
• Trabajar con managers y con otros Staff+
• La importancia de ayudar a los demás

Os dejamos también algunos de los enlaces que hemos comentado a lo largo del capítulo

• 5-15s: https://lethain.com/weekly-updates/ y https://eugeneyan.com/writing/15-5/
• "You can't sit out of office politics": https://hbr.org/2021/07/you-cant-sit-out-office-politics

¡Esperamos que lo disfrutéis! ¡Y recordad que estamos buscando candidatos para el siguiente libro a leer, no dudéis en mandarnos vuestras sugerencias!