TryCatch.tv

Un proyecto no falla solo por código.
También falla por equipos mal organizados, calidad descuidada, metodologías copiadas sin contexto, despliegues manuales, poca automatización y falta de responsabilidad compartida.
En este episodio hablamos del capítulo “Proyectos pragmáticos” de El Programador Pragmático: equipos pequeños y estables, calidad compartida, automatización, pruebas continuas, entrega de valor real y orgullo profesional por el trabajo que hacemos.
La idea central: los proyectos pragmáticos no dependen de héroes, dependen de equipos que trabajan con criterio.

Muchos equipos no necesitan más procesos, necesitan mejorar los que ya tienen.
En este episodio hablamos de cómo hacer que la mejora de procesos funcione en equipos de software sin caer en burocracia: cambios pequeños, objetivos claros, pilotos, adopción del equipo, métricas y mejora continua.
La idea central: mejorar procesos no es llenar el calendario de reuniones, es reducir fricción, retrabajo y errores repetidos.

Muchos proyectos de software no fallan cuando se escribe código. Fallan antes.
En este episodio hablamos del capítulo “Antes del proyecto” de El Programador Pragmático: requisitos, restricciones, colaboración y agilidad real.
La idea central es simple: antes de programar, hay que entender el problema, validar supuestos, crear lenguaje común y diseñar para cambiar.
Porque avanzar rápido en el problema equivocado sigue siendo perder tiempo.

En este episodio diseñamos una arquitectura en Google Cloud desde cero, usando un caso práctico de una plataforma SaaS educativa.
La idea no es memorizar servicios, sino entender cómo piensa un arquitecto:
🧩 entender el problema antes del diagrama
❓ hacer preguntas correctas
⚖️ definir restricciones y trade-offs
☁️ elegir servicios de GCP con criterio
🗄️ decidir entre datos relacionales, storage y eventos
🔐 pensar seguridad, costos y observabilidad
🧠 construir un blueprint inicial sin sobrearquitectar
Porque una buena arquitectura no empieza con cajas.
Empieza con decisiones.

En este episodio muestro cómo agregué SDD a un proyecto que ya existía: el Directorio Tryckers.La idea no era empezar desde cero, sino tomar un sistema con backend, frontend, roadmap y funcionalidades existentes, y empezar a darle más dirección usando:🧱 documentación de arquitectura🗺️ roadmap técnico🧩 vertical slices📄 OpenSpec🤖 agentes para crear y revisar cambios⚙️ trazabilidad entre decisiones, código y productoEl objetivo es pasar de construir features sueltas a trabajar con más intención, contexto y orden.

Diapositivas: https://docs.google.com/presentation/d/170oyfrHaLAAyA53yqNhOSMPNJ2ecaSfr/edit?usp=drive_link&ouid=105119834577486562713&rtpof=true&sd=true