TryCatch.tv

En este episodio hablamos sobre lo ocurrido durante el terremoto del 10 de agosto de 2026 en Colombia, partiendo de la experiencia personal, los reportes que se conocían durante la transmisión y los testimonios de personas en distintas ciudades.
Más allá de las cifras, la conversación se centra en preparación, infraestructura, comunicaciones, sistemas de alerta, resiliencia y uso de la tecnología durante una emergencia.
También revisamos cómo herramientas digitales pueden ayudar a ubicar personas, compartir información y coordinar respuestas, pero con una idea clave: en una emergencia, la velocidad de la información nunca debería estar por encima de su confiabilidad.
La reflexión central: no podemos decidir cuándo ocurre un terremoto, pero sí podemos decidir qué tan preparados estamos cuando sucede.

En este episodio seguimos con la lectura de Código Sostenible, capítulo 5: Principio de menor sorpresa.
Hablamos de por qué el código debería comportarse siempre de la forma en que otra persona espera, sin efectos secundarios ocultos, retornos inconsistentes ni abstracciones que obliguen al equipo a desconfiar.
También analizamos métodos que mienten sobre lo que hacen, comentarios que intentan justificar diseños confusos, monkey patching y la diferencia entre ocultar secretos de implementación y esconder consecuencias inesperadas.
La idea central: el buen diseño puede ocultar cómo funciona internamente, pero nunca debería ocultar qué provoca.

En este episodio configuramos Kaddo desde cero en el Directorio Trycker, un proyecto open source existente, pre-IA y compuesto por varios repositorios.
Vemos cómo definir un repositorio core, mapear frontend y backend como módulos, reconstruir el conocimiento del sistema y preparar contexto para que los agentes no trabajen de forma aislada.
También desarrollamos un work item de extremo a extremo para agregar la fecha de cumpleaños al perfil, cubriendo producto, privacidad, datos, backend, contrato, frontend, pruebas y actualización del conocimiento.
La idea central: la IA puede leer todos tus repositorios y aun así no entender el producto; el contexto es lo que convierte archivos separados en un sistema.

En este episodio seguimos con la lectura de Código Sostenible, capítulo 4: Técnicas para elegir nombres.
Hablamos de por qué nombrar bien no es un detalle estético, sino una decisión de diseño que afecta cómo el equipo entiende, mantiene y evoluciona el software.
Vimos heurísticas para elegir mejores nombres: que sean fáciles de pronunciar, que no incluyan ruido técnico innecesario, que eviten comodines como Helper, Manager o Utils, que formen frases naturales, que respeten el lenguaje del negocio y que se apoyen en el contexto correcto.
La idea central: un buen nombre reduce la necesidad de explicar; un mal nombre obliga al equipo a adivinar.

En este episodio analizamos el caso de Holberton y la discusión alrededor de programas de formación en tecnología que prometen estudiar ahora y pagar después.
El objetivo no es hacer un linchamiento, sino entender el problema de fondo: qué pasa cuando la promesa de entrar a tech se mezcla con deuda, expectativas laborales, pagarés, contratos difíciles de entender y publicidad agresiva.
También hablamos de la responsabilidad de las instituciones que venden educación, la responsabilidad de quienes firman este tipo de acuerdos y la realidad del mercado tech: aprender programación puede abrir oportunidades, pero no garantiza empleo automático.
La idea central: la educación tech puede cambiar vidas, pero nadie debería hipotecar su futuro por una promesa mal explicada.