No sabia que por estar en @platzi tengo acceso a Figma Professional con cuenta de estudiante 🤯💥

Los developers deberían escribir sus propios tickets Y lo digo por tu propio bien, porque vos no queréis un ticket mal escrito o con poco sentido que te ponga a dar vueltas por todo el código y a adivinar lo que tenéis que hacer. Los Product Owners o Product Managers NO deberían escribir tus tickets técnicos. La razón es simple, no tienen ni idea del código que hay que tocar ni pueden estimar el esfuerzo real que implica cada tarea. ¿Quién sabe exactamente qué clases modificar, qué tablas crear o qué librerías probar? Exacto, vos, el developer. Claro, hay PM/PO muy técnicos que podrían hacerlo, pero honestamente, ese no es su trabajo principal ni el mejor uso de su tiempo. Lo que sí deben hacer los Product Owners es comunicar claramente el PROBLEMA y el VALOR que esperan recibir en cada sprint y sobre todo asegurarse bien que el equipo realmente entendió. Pueden usar documentos, videos, diagramas, llamadas de shaping, sesiones, tickets generales... lo que sea más efectivo para transmitir esa visión. Veamos un ejemplo, estamos creando una funcionalidad para manejar imágenes: * Sprint 1: Quiero una pantalla simple con una tabla de imágenes de X endpoint. * Sprint 2: Necesito que esa tabla tenga vista de lista, de grid y paginación. * Sprint 3: Los usuarios deben poder buscar imágenes usando keywords y metadatos. * Sprint 4: Agregar un botón "Browse" para subir imágenes desde el sistema de archivos. * Sprint 5: Implementar un indicador de carga con animación durante la subida. * Sprint 6: Permitir drag and drop de imágenes individuales. * Sprint 7: Habilitar drag and drop de carpetas completas de imágenes. El PM no te está diciendo "usa el componente X para la paginación" ni "implementa la clase Y". Está definiendo el valor incremental que el negocio necesita obtener. Las tareas técnicas específicas para lograr ese valor tenéis que escribirlas vos, el developer y el team lead. Si un developer me dice que no sabe escribir tareas, tenemos un problema serio. Porque significa una de dos cosas: 1️⃣ o no entendió lo que tiene que hacer (problema de comunicación) 2️⃣ no quiere asumir esa responsabilidad (problema de actitud) Ser developer no se trata solo de escribir código (sorry que te hicieron creer eso). Se trata de resolver problemas. Y para resolver problemas, primero hay que entenderlos y luego definir los pasos para solucionarlos. Eso es exactamente lo que son los tickets. Y si no te dieron suficiente contexto, ¡pregunta! No te quedes esperando a que te digan exactamente qué hacer. Bueno, puedes hacerlo... pero sinceramente, ¿es eso lo que quieres para tu carrera? Los equipos deben ser autogestionados. Un verdadero developer entiende un problema y define lo que necesita hacer para resolverlo. No necesita que alguien le diga "instala la libreria axios" o "cambia el color allá". Eso deberías saberlo tú. La próxima vez que esperes que tu PM te escriba tickets detallados, pregúntate si estás actuando como un verdadero developer o como alguien que solo quiere que le digan qué teclas presionar. PD. A los que me vengan a hablar de Scrum los invito a leer sobre Shape Up.

TypeScript a Go: ¿Por qué no Rust? 🤔 Microsoft ha decidido portar TypeScript a Go, ¡y la comunidad tiene opiniones divididas! 😲 Mientras que la promesa de una compilación 10 veces más rápida emociona a muchos, algunos se preguntan por qué no se optó por Rust. 🤔