エピソード
-
En este episodio hablamos de cómo cambia una arquitectura en Google Cloud cuando una startup empieza a crecer.
Partimos desde un MVP y revisamos cómo evolucionan las decisiones técnicas al pasar por distintas etapas: 100 usuarios, 1.000 usuarios, 50.000 usuarios y hasta 1 millón de usuarios.
La idea no es explicar servicios de forma aislada, sino entender cuándo aparecen y por qué: Cloud Run, Cloud SQL, Memorystore, Cloud Load Balancing, Cloud CDN, Pub/Sub y BigQuery.
La idea central: una buena arquitectura no nace gigante; evoluciona cuando el problema lo exige.
-
En este episodio implementamos Kaddo en Kiorem como un proyecto pre-IA: un producto que ya existe, tiene código, reglas, módulos y decisiones importantes, pero todavía necesita una capa de conocimiento estructurada para trabajar mejor con agentes de IA.
Vemos cómo Kaddo ayuda a capturar contexto de negocio, producto, tecnología y delivery; cómo preparar el proyecto para que la IA no trabaje a ciegas; cómo usar agentes, MCP y grafo de conocimiento; y cómo refinar un work item con criterios de aceptación, ownership y preguntas abiertas.
La idea central: antes de pedirle código a la IA, hay que darle memoria del proyecto.
-
エピソードを見逃しましたか？
-
En este episodio seguimos con la lectura de Código Sostenible, capítulo 3: Fundamentos.
Hablamos de por qué diseñar para un futuro imaginario puede volver el código más complejo, menos claro y más difícil de mantener. También analizamos la trampa de crear soluciones demasiado genéricas, reutilización prematura, tests como base de calidad, tests sostenibles, abstracciones con sentido e intencionalidad explícita.
La idea central: el código más preparado para el futuro no es el que intenta adivinarlo, sino el que deja claro el presente.
-
En este episodio hablamos de una idea clave: los cursos enseñan conceptos, pero producción enseña consecuencias.
Analizamos aprendizajes reales de arquitectura mobile: por qué la arquitectura perfecta no siempre sobrevive a deadlines, legacy, cambios de negocio, presión de stakeholders, crashes, performance y equipos reales.
También hablamos de arquitectura práctica, sobreingeniería, observabilidad, comunicación, decisiones bajo restricciones y refactorización incremental.
La idea central: la arquitectura no se mide por lo elegante que se ve, sino por qué tan bien ayuda al equipo a entregar, mantener y evolucionar el producto.
-
En este episodio presento Kiorem.com, una plataforma para organizar información importante de vida, legado y emergencia.
La idea nace de un problema real: muchas veces las familias no saben dónde están documentos, cuentas, pólizas, instrucciones, mensajes o información clave cuando más la necesitan.
Durante la transmisión muestro el problema, la propuesta de valor, el flujo principal, el alcance del MVP, la demo de la plataforma, decisiones de seguridad y la estrategia de beta cerrada para early adopters.
Kiorem no busca reemplazar procesos legales; busca que lo importante no se pierda cuando más se necesita.
-
En este episodio seguimos con la lectura de Código Sostenible y hablamos de refactorización.
La idea central es que el código limpio no suele aparecer al primer intento: se construye con pequeñas mejoras constantes, mejorando nombres, intención, legibilidad y estructura sin cambiar el comportamiento del sistema.
También hablamos de por qué los tests son la red de seguridad para refactorizar con confianza, qué son los code smells y por qué las herramientas ayudan, pero nunca reemplazan el criterio del equipo.
-
Iniciamos la lectura de Código Sostenible hablando de una idea clave: que el código funcione hoy no significa que sea fácil de mantener mañana.
En este episodio hablamos de código escrito para humanos, complejidad accidental, degeneración del software, pruebas automatizadas, sostenibilidad económica y la importancia de poner a las personas primero.
La idea central: el código sostenible no es solo código bonito; es código que un equipo puede entender, cambiar y mantener sin miedo.
-
En este episodio presento Kaddo, una herramienta basada en Knowledge Driven Development para preparar proyectos de software antes de trabajar con agentes de IA.
La idea central es simple: muchas veces la IA no falla por falta de capacidad, sino porque no entiende el contexto del proyecto.
Vemos cómo Kaddo estructura conocimiento del negocio, producto, tecnología y delivery; cómo usa CLI, agentes, work items, grafo de conocimiento y MCP para que humanos y agentes trabajen con más claridad.
-
En este episodio resolvemos dudas reales de la comunidad sobre cómo conseguir el primer trabajo en tecnología.
Hablamos de CV, LinkedIn, portafolio, proyectos, entrevistas, estrategia de búsqueda laboral y cómo mostrar mejor el valor de lo que sabes.
También hicimos el sorteo de libros donados de Guía completa: cómo conseguir el primer trabajo en tecnología, leyendo algunas respuestas de la comunidad.
La idea central: no basta con saber, también hay que saber mostrarlo.
-
Terminamos de leer El Programador Pragmático en comunidad y ahora viene una nueva decisión: elegir el siguiente libro.
En este episodio revisamos varias opciones para continuar la lectura en TryCatch.tv:
Código SostenibleThe SaaS PlaybookLearning Domain-Driven DesignThe Software Architect ElevatorLa idea no era escoger solo el libro más famoso, sino elegir cuál puede aportar más a esta etapa de la comunidad.
Porque leer en comunidad no se trata solo de avanzar páginas, sino de abrir mejores conversaciones.
-
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 sobrearquitectarPorque 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
-
En este episodio hablamos de una idea clave de seniority: los mejores developers no son los que escriben más código, sino los que entienden cuándo no escribirlo.
Menos código puede significar menos bugs, menos mantenimiento, menos complejidad y mejores decisiones de diseño.
La diferencia no está en producir más líneas, sino en simplificar mejor.
-
Serverless promete simplicidad, escalabilidad y menos operación.
Pero cuando el sistema empieza a crecer, aparecen problemas que no siempre se ven en el diagrama:
💸 costos invisibles🔁 retries peligrosos🗄️ malas decisiones en Firestore🥶 cold starts🌐 egress inesperado📊 falta de FinOps y controlEn este episodio hablamos de cómo una arquitectura técnicamente correcta puede convertirse en un problema financiero y operacional si no existe criterio arquitectónico.
-
Tu código puede funcionar… y aun así estar mal.
En este video hablamos de una idea clave: programar no es solo escribir líneas de código hasta que algo compile. Es entender el problema, el sistema, el contexto y las consecuencias de cada decisión.
Vemos:
- por qué hacer que algo funcione no siempre es suficiente
- qué significa escribir código con intención
- cómo detectar señales de mal diseño
- por qué programar por casualidad es peligroso
- cómo las pruebas, la refactorización y el criterio ayudan a construir software mantenible
Idea clave:
el código no solo debe funcionar hoy; debe poder entenderse, probarse y cambiarse mañana.
#programacion #software #desarrolladores #codigo #tech
-
Saber mucho no te consigue trabajo si nadie entiende el valor que puedes aportar.
En este video hablamos de uno de los errores más comunes al buscar oportunidades en tecnología: acumular cursos, tecnologías y proyectos… pero no saber convertir eso en una narrativa clara.
Vemos:
- por qué muchos CVs no generan entrevistas
- cómo evitar que tu perfil parezca una lista de tecnologías
- por qué algunos proyectos no comunican impacto
- cómo explicar mejor lo que sabes en entrevistas, LinkedIn y portafolio
- un framework simple para contar tu experiencia con más claridad
Idea clave:
no gana quien más sabe, gana quien logra demostrar mejor el valor de lo que sabe.
#programacion #empleabilidad #desarrolladores #tecnologia #linkedin
-
En este episodio hablamos de Cloud Run vs GKE y de cómo decidir entre serverless y Kubernetes sin caer en sobrearquitectura.
Vemos los trade-offs reales: velocidad, control, costo, operación, cold start y complejidad.
La idea central: arquitectura no es usar lo más poderoso, es elegir lo más adecuado para el problema.
- もっと表示する
