Publicidad en podcasts en: 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óduloPor qué las mejores interfaces son las que no existenUn 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ó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.

¡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 curiosidadTécnicas para aprenderConsejos para estar al día con la industriaNo 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á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/

¡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 resilienciaBuenas prácticas para monitorizar mediante logs y métricasPor 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 sirvenHerramientas 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 dependienteEl 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-inCompliance 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/blackhttps://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 influenciaTrabajar 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!

¡Volvemos! Esta vez empezamos la parte 5 en la que ya somos Staff+ (cómo avanzamos en nuestra carrera eh) y empezaremos con el capítulo 21 que se titula "Understanding The Business", entendiendo el negosi. ¿Qué veremos aquí? La diferencia fundamental entre niveles senior y staff+Los conceptos clave (North Stars, KPIs, OKRs) con el ejemplo memorable de NikeLa transición hacia mentalidad de productoEstrategias prácticas para entender usuariosLa importancia de conocer el negocio completoCómo mantenerse informado de la industria Enlaces https://slack.engineering/applying-product-thinking-to-slacks-internal-compute-platform/ https://www.moderntreasury.com/journal/accounting-for-developers-part-i https://personalmba.com/ https://www.linkedin.com/pulse/nike-epic-saga-value-destruction-massimo-giunco-llplf/

¡Hola hola! Volvemos con el capítulo 20, esta vez para explorar cómo crear y mantener equipos saludables desde nuestra posición de Tech Lead. En el episodio de hoy hablaremos sobre: Las características clave de un equipo saludableSeñales de alerta cuando un equipo se está yendo al garete (y cómo romper esos círculos viciosos)El temido "brillante gilipollas" y cómo lidiar con manzanas podridas en el equipoTécnicas para mejorar las dinámicas de equipo y fortalecer relaciones con otros teams Además, tendremos anécdotas sobre managers desbordados y sobre por qué debes documentar comportamientos problemáticos. ¡Hay también una pregunta bonus! Estamos llegando al final del libro y queremos saber qué os gustaría que leyéramos después. ¿Más contenido técnico? ¿Management? ¡Dejadnos vuestras sugerencias!

Volvemos! En este episodio hablamos de cómo, como tech lead, puedes influir directamente en la estructura de tu equipo o, al menos entender bien qué está pasando. Exploramos la diferencia entre roles y títulos, y por qué es clave identificar los roles explícitos e implícitos dentro del equipo.Hablamos de procesos: cuándo ponerlos, cuándo quitarlos, y cómo usarlos como herramienta (y no como fin).Por último, profundizamos en una de las grandes responsabilidades del tech lead: proteger el foco del equipo. Cómo priorizar, evitar distracciones innecesarias y gestionar cambios de dirección sin perder el rumbo.Bonus: la charla de Alex https://www.youtube.com/watch?v=WquuMkebeH4&pp=ygUZYWxleCBnYXNjb24gdDNjaGZlc3QgMjAyNQ%3D%3D

¡Hola hola de nuevo! Volvemos una semana más a la sección del Tech Lead, esta vez para hablar de la gestión de stakeholders (o "partes interesadas" en castellano) Veremos cosas tan interesantes como: Por qué no tienes que ver la gestión de stakeholders como burocraciaTipos de stakeholders y cómo identificarlosUn tip increíble para conocer stakeholders nuevos de la mejor manera posible Como siempre, ¡esperemos que disfrutéis el capítulo! ¡No dudéis en hacernos llegar vuestros comentarios!

¡Muy buenas una semana más! Hoy nuestra lectura nos lleva a hablar de desplegar a producción: procesos, herramientas, cosas a tener en cuenta... Más concretamente, hoy Gergely (y nuestras anécdotas) hablan sobre: Los dos extremos (cambiar el código directamente vía SSH; o tener un proceso con entornos de test, QA, etc), y todas las posibilidades que hay en medioCómo son los procesos de deploy en Facebook (y por qué no son tan complejos como imaginas)Historias exclusivas sobre los procesos de despliegue en Amazon, contados desde la perspectiva de Alex desde dentroHerramientas para protegernos y detectar errores a tiempoCómo elegir el approach que más nos conviene