← Volver a novedades
poteto@poteto

y otro post interesante al que siempre vuelvo desde que @tomocchino me lo compartió

also another interesting post i always come back to ever since @tomocchino shared it with me https://engineering.fb.com/2011/04/18/uncategorized/thoughts-on-software-quality/
Publicación
Ver en X ↗𝕏 Compartir
poteto
Los codebases siempre han tenido slop. Siempre lo hemos aceptado porque el código rara vez necesita ser perfecto, salvo en software crítico "duro" (por ejemplo, embebido). swe es una forma de ingeniería muy particular, porque muchas veces estás construyendo algo que evoluciona constantemente y que es casi orgánico: cambian los gustos de los usuarios, evolucionan tus modelos mentales y las features van y vienen. La verdad, yo y mucha gente que lleva años programando éramos al principio (tipo en 2024) escépticos de que los agentes escribieran código de producción. "¿Y todo el slop que va a entrar a nuestro hermoso codebase?". Pues antes ya teníamos slop humano, ¡y un montón! Si somos honestos, la mayoría llama slop al "código que no escribí yo". La realidad es que el 99% de la gente (me incluyo) ni siquiera sabe cómo se ve el Good Code, mucho menos escribirlo. Yo propongo que Good Code es: • correcto • sin bugs • rápido y eficiente en costo al ejecutarse Escribir Good Code de verdad siempre ha sido carísimo y dificilísimo, porque durante mucho tiempo (quizá @bendlang lo cambie) el código no era algo que pudieras garantizar de forma barata y formal con estas 3 propiedades. Por eso escribir software difícil es mucho más caro y complicado: según el caso, quizá solo tengas una oportunidad y tengas que acertar desde el principio. Pero la gran mayoría del software que usamos no necesita ser Good Code para darle valor a los usuarios. De hecho, ¡es muy probable que la mayoría del software que usamos no sea formalmente verificable! Aceptamos algunos bugs a cambio de velocidad y avance, así que dependemos de tests y o11y y adoptamos un enfoque más incremental. ¡Eso es bueno! Los agentes nos ayudan a ir más rápido y, si estás abierto a la idea, pueden ayudarnos a escribir mejor código. No será Good Code (eso sigue siendo caro), pero probablemente sea mucho mejor en promedio y a escala. El nuevo oficio de swe es descubrir cómo hacer esto. ¡Ahora es tu trabajo! Si tu productividad con y sin agentes no es muy distinta, estás haciendo algo mal. Pero no es tarde para adoptarlo y usarlo como oportunidad para aprender todo un nuevo árbol de habilidades.
poteto
tldr todo el código es basura
poteto
poteto
salvo el mío, claro
poteto
y otro post interesante al que siempre vuelvo desde que @tomocchino me lo compartió
← Volver a novedades