Además, también discutimos sobre - Por qué las mejores interfaces son las que no existen - Varios ejemplos (más) de que seguir Clean Code a ciegas no siempre es bueno Todo esto y mucho más, ¡ya disponible en vuestra plataforma de podcast preferida! open.spotify.com/episode/3rR…

Los capítulos anteriores hablaban sobre cómo hacer código bien. Hoy nos centramos en la importancia de *agruparlo* bien Vemos a qué se refiere John cuando habla de la "profundidad" de los módulos, y por qué es muy importante tenerla en cuenta al organizar tu código

Solo una cosa podría mejorar un lunes. Y esa cosa ha llegado: ¡Nuevo episodio de TechLecturas! Hoy bajamos hasta lo más hondo para hablar sobre la profundidad de los módulos. ¡Acompañadnos!

Como siempre, cualquier feedback es más que bienvenido. ¡Esperemos que os guste!Facebook lo aprendió a las malas, cambiando su famoso "move fast and break things" por "move fast with solid infrastructure".

¿Y esto aplica a startups? Pues... sí. Y no. Facebook lo aprendió a las malas, cambiando su famoso "move fast and break things" por "move fast with solid infrastructure". Pero igual no sería Facebook si no lo hubiera hecho así.

La segunda: la programación estratégica. Que funcione, Y ADEMÁS, que encaje bien, que sea mantenible, que en el futuro esto no te vaya a pegar un bocao. Juanito se pone en modo Warren Buffet para decirnos que hay que invertir tiempo en el código. ¿Cuánto? Lo discutiremos

Hablaremos de dos formas de programar. La primera, la programación táctica. El sacar a saco. Arreglar sin pensar. Hacer la ñapa más grande aún. Y su máxima expresión: El tornado táctico

Como de costumbre, lo primerico, el link open.spotify.com/episode/4uR…

¡Caaaaaapítulo 3 ya publicado! Esta vez Juanito, Alex y Jose hablan de: "Que el código funcione no es suficiente"

¡Nada más! Esperemos que os guste, cualquier feedback (chupito), ¡comentadnos!

"A veces un enfoque con más líneas de código es en realidad más simple, porque reduce la carga cognitiva" Menos código no necesariamente implica menos complejidad. Empieza el Robert vs John😆

John nos da 3 señales de que tu código es más complejo de lo que debería: - Cambias algo pequeño y tienes que tocar 20 ficheros - Para hacer cualquier tarea necesitas conocer medio sistema - No sabes lo que no sabes… hasta que hay un bug

Hablaremos bastante de la complejidad en software y cómo no la crea un gran error. La crean mil pequeñas decisiones que nadie tomó en serio. John lo llama deuda técnica incremental. Nosotros, "total, es solo una cosita"

Lo primero es lo primero, aquí el link: open.spotify.com/episode/6y7…

Los lunes son menos lunes con... ¡UN NUEVO EPISODIO DE TECHLECTURAS! ¿Qué tiene en común un edificio con ventanas rotas y un sistema de software mal diseñado? Hoy, en los dos primeros capítulos del libro "A Philosophy of Software Design" te lo contamos👇

¡No dudéis en hacernos llegar vuestros comentarios, y esperamos que os guste!

¿De qué hablaremos? Pues en este capítulo de introducción os comentamos qué esperar de A Philosophy of Software Design (APOSD para los amigos), y nuestras primeras impresiones

Que, por cierto, la primera "U" del apellido de John es más importante de lo que parece. Ya veréis, ya Aquí el enlace del capi: open.spotify.com/episode/4fO…

Hola hola hola hola holaaaaaaaaaa Volvemos este 2026 y ya sabéis lo que dicen, año nuevo, libro nuevo así que empezamos "A philosophy of software design" del bueno de John Ousterhout