¡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!

¡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 Nike
• La transición hacia mentalidad de producto
• Estrategias prácticas para entender usuarios
• La importancia de conocer el negocio completo
• Có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/

¡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 saludable
• Señ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 equipo
• Té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 burocracia
• Tipos de stakeholders y cómo identificarlos
• Un 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!