Hay un tramo de la carrera técnica que no figura en ninguna descripción de puesto. No empieza el día en que uno deja de programar, porque ese día no llega: se sigue escribiendo código, y además se empieza a decidir la arquitectura que otros van a usar durante los próximos años. Visto desde fuera es una ampliación de alcance. Visto desde dentro se parece más a fallar dos veces en lugar de una.
En la reunión de arquitectura pienso en el componente que no estoy terminando. Delante del editor pienso en la decisión estructural que dejé a medias por la mañana. No hay ningún momento del día en que la sensación sea de estar donde toca al cien por cien.
Escribo esto porque me lo plantean a menudo perfiles senior que acaban de entrar en ese tramo, y porque la respuesta habitual, organizarse mejor y bloquear la agenda, no describe el problema. El problema no es de calendario.
Lo que cambia no es el puesto, es el criterio
El título cambia de un día para otro. El cambio real tarda mucho más, y no consiste en aprender a dibujar diagramas ni en dominar un vocabulario nuevo. Consiste en reconstruir el criterio interno con el que uno decide si ha hecho bien su trabajo.
Ese criterio se formó durante años en un oficio con reglas propias. Un desarrollador de interfaz sabe que el día ha ido bien porque el componente funciona, la prueba pasa, el diff está revisado y el contraste cumple. Son señales que llegan el mismo día y no admiten discusión. Cuando el trabajo pasa a ser decidir qué componentes existen, qué contrato ofrecen y qué queda fuera del sistema, ninguna de esas señales sirve, y todavía no hay otras en su lugar.
Ese hueco es el tramo intermedio. No es que las dos cosas se estén haciendo mal: es que la vara de medir de un oficio se está aplicando al otro.
El desfase es de latencia, no de nivel
Escribir código tiene un ciclo de realimentación de minutos. La prueba pasa o no pasa, el layout encaja o se rompe, la revisión llega esa misma tarde. Una decisión de arquitectura no tiene nada equivalente. Cuando defino la superficie de API de un componente, la evidencia de si acerté no aparece en esa iteración; aparece cuando llega el tercer consumidor con un caso de uso que no había previsto, y eso ocurre meses después. Entre una cosa y la otra no hay con qué medirse.
Por eso la incomodidad de ese tramo no informa sobre la capacidad de quien la siente. Informa de la distancia entre la velocidad a la que ha cambiado el rol y la velocidad a la que puede actualizarse el criterio, que necesita repetir la misma clase de decisión varias veces hasta que deje de parecer una excepción. Necesita ver, un año después, que el componente que se diseñó aguantó el cambio para el que se diseñó. Eso es tiempo de vuelo, y no hay forma de adelantarlo leyendo.
El error de lectura viene después: si al terminar el día no hay nada verificable, se concluye que no se ha hecho nada. Es la misma conclusión que sacaría un compilador con un lenguaje que no entiende.
Señales adelantadas para no esperar seis meses
Aceptar que la evidencia tarda no obliga a trabajar a ciegas durante ese intervalo. En un sistema de diseño hay indicadores que se mueven antes que el veredicto definitivo y que sirven de aproximación razonable.
El primero es cuántos consumidores han tenido que sobrescribir estilos de un componente en lugar de usarlo tal cual. El segundo es cuántas excepciones se piden por iteración, y sobre qué componentes se concentran. El tercero es cuántas veces se repite la misma pregunta en el canal de soporte del sistema, porque una pregunta repetida señala casi siempre un contrato mal nombrado. Y el cuarto, el que más rápido avisa: si las peticiones piden props nuevas o piden composición. Cuando alguien copia el componente en su repositorio en lugar de consumirlo, la decisión ya ha fallado, y eso se ve semanas después, no trimestres.
Ninguno de esos cuatro números demuestra que una arquitectura sea correcta. Acortan el ciclo lo suficiente para que el criterio tenga con qué entrenarse mientras llega la evidencia buena, que sigue tardando lo que tarda.
Cómo reparto la semana y qué me cuesta
Durante un tiempo intenté sostener los dos oficios con la forma de trabajar del anterior: mantener la propiedad de una línea de funcionalidad, para seguir teniendo las manos en el código, y colocar la arquitectura en los huecos que dejara. Esa opción tiene un argumento a favor que sigo considerando el más fuerte de todos: el contacto diario con el código de producción es la única fuente honesta de información sobre si el sistema estorba o ayuda.
La descarté por su coste. Cuando la persona que decide la arquitectura está en la ruta crítica de una entrega, las decisiones estructurales se aplazan hasta que dejan de ser decisiones. Llegan tarde, cuando ya hay tres implementaciones que las contradicen, y lo que se firma entonces no es una decisión sino la justificación de lo que otros ya construyeron.
Lo que hago ahora es distinto. El código que escribo es prototipo y revisión, y nunca entrega comprometida con una fecha. Prototipo para validar una decisión antes de proponerla: escribir un componente dos veces, con y sin la prop en discusión, cuesta media jornada y ahorra una reunión de una hora que se habría resuelto por intuición. Y reviso para no perder de vista qué se está construyendo encima del sistema. Ninguna de las dos cosas bloquea a nadie si esa semana la arquitectura se come tres días.
El coste de este reparto es real y conviene decirlo: pierdo la clase de conocimiento que solo da mantener código en producción durante meses, el que avisa de que una decisión es incómoda antes de poder explicar por qué. Lo compenso con revisiones y emparejándome una vez por iteración con quien sí mantiene ese código. Lo compenso solo en parte.
El reparto se sostiene en un equipo de interfaz con varios consumidores del sistema y con alguien capaz de terminar lo que yo prototipo. En un equipo de tres personas donde el arquitecto es además quien entrega, no vale: allí la única mitigación que me ha funcionado es reducir el número de decisiones estructurales abiertas a la vez, aunque eso signifique dejar zonas del sistema sin criterio durante una temporada, declarado y por escrito.
Cuándo deja de sentirse así
No tengo una fecha, y desconfío de quien la dé. Lo que sí cambia es la pregunta que uno se hace. Dejé de preguntarme por qué seguía sintiéndolo y empecé a mirar dos cifras: cuántas de las decisiones de arquitectura que tomé hace seis meses siguen en pie sin excepciones, y cuánto tardo en resolver una decisión del mismo tipo comparada con la primera vez que me tocó.
Cuando esas dos cifras se mueven en la dirección correcta, la incomodidad sigue ahí un tiempo más. La diferencia es que a partir de ese punto ya no describe el trabajo: describe una costumbre de medir que todavía no se ha actualizado.