
Hosted by Judlup · ES

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 mantenibleIdea 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 claridadIdea 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.

La mayoría usa concurrencia sin entender qué puede romper.En este episodio, basado en el capítulo 6 de El Programador Pragmático, hablamos sobre concurrencia, paralelismo, estado compartido, bloqueos, transacciones, actores, programación reactiva y arquitecturas basadas en eventos.La idea central es simple:los sistemas reales no funcionan como una lista de instrucciones una debajo de otra.Mientras más usuarios, procesos, APIs, bases de datos y servicios interactúan al mismo tiempo, más importante se vuelve diseñar pensando en concurrencia, desacoplamiento y coordinación.En este video veremos:Qué diferencia hay entre concurrencia y paralelismoPor qué pensar de forma secuencial limita el diseñoQué problemas aparecen con estados compartidosCómo funcionan los bloqueos y las transaccionesQué aportan los modelos de actoresCómo las pizarras, Kafka y los event streams ayudan a desacoplar sistemasPor qué la concurrencia es una decisión de arquitectura, no solo de códigoSi estás construyendo sistemas modernos, este tema no es opcional.

No eres senior por saber más.En este episodio hablamos de lo que realmente define el seniority en desarrollo de software:No es código, es criterioNo es ejecución, es impactoNo es experiencia, es cómo piensasSi sientes que estás estancado o quieres crecer más rápido en tu carrera, este episodio te va a cambiar el enfoque.