Horas que no eran mías.
El otro día tiré horas de trabajo a la basura.
Y lo hice a propósito.
Fue probando el flujo nuevo (el programático con subagentes, del que ya te hablé por aquí). Estoy afinándolo para empezar a usarlo en mi día a día, aunque de eso te hablaré otro domingo.
La cosa es que cogí un ticket para ver cómo se portaba.
La funcionalidad parecía sencilla: exportar perfiles en bloque. Ya teníamos esto en la plataforma de uno en uno y hacía falta poder sacar cien o quinientos de golpe.
Y no me gustó el resultado.
Así que extraje los errores, apunté por dónde había fallado, lo borré todo y me puse a hacerlo otra vez desde cero.
(Bueno, yo no, lo hizo Claude :D)
¿Y sabes lo raro?
Nunca en mi vida había hecho algo parecido.
Pero cuando lo hice, no sentí dolor. Porque ese código no lo había escrito yo, lo había escrito Claude.
Porque cuando el código lo escribí yo, la cosa fue muy distinta.
Hace un tiempo me pasé una semana entera construyendo una funcionalidad. Y en la reunión con el cliente dijeron que ya no la querían.
La siguiente MR que hice después de esa reunión fue borrar todo el trabajo de una semana atrás.
Me sentó fatal.
Y es que los programadores siempre hemos tenido cierto apego al código.
Se nota en cosas pequeñas que todos experimentamos. En que te moleste que te lo refactoricen. En que ponemos mala cara cuando alguien entra a tocar nuestro módulo. Ese tipo de cosas.
Tú has sido ese compañero. Y yo también.
Era algo normal, porque el código siempre ha sido un poco como nuestro bebé. Sobre todo si era un proyecto que te habías picado desde cero.
Pero no debemos olvidar que el código es la herramienta con la que resolvemos el problema de otra persona. Ya te lo he dicho muchas veces: no nos pagan por escribir código.
Se nos suele olvidar esto, y acabamos tratándolo como si fuera el fin. Nos apegamos al código.
Ahora es un freno. Un freno muy gordo.
Porque si llevo una hora con un ticket que en realidad no he hecho yo, ¿qué importa si lo tiro?
¿Qué habré perdido realmente? Un poco del límite mensual de la suscripción y un par de clics.
Ya está. No se muere nadie.
Además, que esto es necesario si queremos ir más rápido.
Porque montar estos flujos autónomos de los que te hablo últimamente es fallar mucho. No hay atajo: lanzas, se rompe, miras por qué se rompió, cambias el sistema y vuelves a lanzar.
Llevo más de una semana metido en ese bucle. Y no me vale con que funcione: quiero que funcione sin mí.
se rompe
mirar por qué
cambiar el sistema # no el ticket
Cuanto antes falle, mejor. Cada vuelta me deja el sistema un poco más cerca.
Que es a donde quiero llegar, a la autonomía total. Y eso solo llega con output. Mucho.
Retocar a mano lo que salió mal solo me deja un ticket cerrado y un sistema igual de tonto que ayer.
Aunque evitarlo cuesta. Y yo el primero.
Los primeros tickets que pasé por el flujo salieron mal. En uno, el contrato entre el front y el back no cuadraba: cada lado esperaba algo distinto del otro.
¿Y sabes qué hice? Retocarlos a mano y seguir.
No los tiré ni saqué nada de ellos. Los dejé decentes, puse la tarea en QA y a por la siguiente.
Y eso que la lección estaba bastante clara: añadir al flujo un verificador de contratos y que aquello no pudiera repetirse.
El apego al código es lo que hace que pongas parches en lugar de mejorar el sistema.
Yo me estoy deshaciendo de él poco a poco. Porque sé que si de verdad quiero ir rápido, tengo que desapegarme del todo.
Algo para lo que cada vez tenemos menos motivos, porque piénsalo un momento: ¿de qué está hecho ese apego?
Si te dolía que te tocaran un fichero, era porque te acordabas de haberlo escrito. De la tarde entera atascado con ese problema y de la idea que se te ocurrió justo antes de dejarlo.
El apego no era al código. Era a las horas. Al esfuerzo invertido. El código solo era la prueba de que las habías echado.
Y esa prueba cada vez lleva menos horas nuestras.
Primero dejamos de escribir el código, porque lo escribe el agente y nosotros revisamos. Luego revisamos por encima, porque la mayoría de las veces sale bien. Y al final acabas abriendo una MR con cosas dentro que no has visto en tu vida.
Ya te conté que yo aprobaba planes sin leerlos enteros la mitad de las veces. Eso sigue igual. De hecho, cada vez me interesa menos revisar y más que el sistema aguante solo.
Entonces, ¿a qué nos estamos agarrando? ¿Qué apego nos queda cuando el autor ya no somos nosotros?
Pues sigue ahí. Yo lo noto, aunque ya no tenga de dónde sostenerse.
Y empiezo a pensar que la mayor fricción para soltar está en otro lado: en ser el autor. Poder señalar algo y decir «esto lo hice yo».
Eso es lo que cada vez puedo hacer menos.
O a lo mejor no se va y solo se muda de sitio.
Porque tirar aquel ticket me dio igual. Pero si alguien entrase a cambiarme el flujo que estoy montando… uf, no sé si me gustaría.
Que es exactamente el mismo apego de siempre, un piso más arriba.
Porque sé que esas horas no eran mías.
Todavía no sé si eso es bueno o si es el mismo error otra vez.
Lo que sí tengo claro es la parte práctica.
Aún me acuerdo de aquella semana entera que se fue a la basura y de lo mal que lo pasé. Ahí está la diferencia.
Así que si lo que ha salido no te vale, no lo maquilles. Saca lo que hayas aprendido por el camino y tira lo que no sirva.
Repetirlo te cuesta un par de clics y una transcripción.
Así que la próxima vez que te tiemble el dedo:
Bórralo.
Tres apuntes de la semana
Te recomiendo
El guerrero a la sombra del cerezo
Otra novela, esta ambientada en el Japón feudal, que me ha flipado. Plot twists brutales, personajes superbién construidos y, a nivel histórico, bastante fiel. Si te tira la cultura japonesa te va a parecer supercuriosa; a mí me dieron ganas de hacerme samurái y todo.
$ open amazon · El guerrero →De la comunidad
Y tú, ¿lo has borrado alguna vez?
¿Has tirado trabajo a la basura a propósito, o todavía te tiembla el dedo? Dale a responder y cuéntamelo. Lo leo todo (poquito a poco).
$ reply --to=newsletter@alpacatech.dev