El Paradójico Ascenso del Desarrollador: Más Seniority, Menos Código

Quiero hablar de algo que a todos nos pasa o nos va a pasar en algún momento de nuestra carrera: la paradoja de que, mientras más seniority tenés, menos código escribís. A medida que agarrás más experiencia, tus responsabilidades crecen exponencialmente y, curiosamente, terminás notando que tus propias tareas te toman mucho más tiempo que antes.

¿Por qué pasa esto? Porque ya no podés estar solo enfocado en la tarea en sí.

De “Creador” a “Multiplicador”

Cuando sos Junior, tu valor se mide principalmente por cuánto código metés en producción. Sos un generador. Pero a medida que vas avanzando, te empezás a convertir en un multiplicador.

Esto significa que surgen problemas en otros lados y sos vos el que tiene que estar ahí con la prioridad máxima. Tu mayor impacto pasa a ser destrabar a cinco de tus compañeros, hacer buenas code reviews, o evitar que el equipo le dedique dos semanas a una arquitectura incorrecta. Como Senior, una hora tuya estructurando una solución vale más que diez horas tirando líneas sin pensar.

El Costo del “Context-Switch” y el “Síndrome del Impostor”

A este nivel, tu calendario pasa de tener bloques limpios de 4 horas ininterrumpidas (el famoso Maker’s Schedule) a estar completamente fragmentado para atender un problema en producción o entrar a reuniones (el Manager’s Schedule). El costo de cambiar de contexto constantemente es altísimo, por lo cual tu velocidad individual baja.

A veces esto te genera hasta culpa o un “Síndrome del impostor”. Llegás al viernes, ves que hiciste apenas dos commits en la semana y sentís que no trabajaste. Pero en realidad destrabaste un release clave y evitaste una caída importante del sistema. Tu trabajo ya no se mide por peso de commits.

Pensar antes de teclear (Un consejo para los Juniors)

Además de las interrupciones, hay otro factor por el cual el Senior escribe menos: piensa mucho más antes de meter código.

Este es uno de los mejores consejos para cualquier Junior: es mejor pensar y planificar un poco más antes de arrancar a codear, en lugar de apurarse para sentir la adrenalina de avanzar rápido, solo para darse cuenta tres días después de que la solución elegida no resolvía realmente el problema o no escalaba. Diseñar antes de teclear siempre paga dividendos.

Ingeniería de Expectativas y el Arte de dar ETAs

Finalmente, parte esencial del Seniority es aprender la habilidad de estimar y gestionar los tiempos. Aprender a dar ETAs es crucial. Es mil veces mejor dar un ETA realista (y hasta un poco más largo) para asegurarte de cumplirlo, que tirar un ETA corto para quedar bien y fallar en la entrega.

Acá entra el famoso “colchón de tiempo”. Siempre tenés que tener un margen de maniobra. Estos colchones no existen por pereza, existen por los llamados unknown unknowns (las cosas que no sabés que no sabés): un bug oscuro en una librería, la caída de una API de terceros, problemas con los entornos.

Levantá la mano sin miedo: Si a pesar del colchón ves que no vas a llegar al ETA, avisá con tiempo. No hay que tener miedo ni vergüenza de decir que una task no se puede hacer como se pensaba o que va a llevar mucho más tiempo. Es preferible levantar la mano temprano porque te permite accionar de otra manera urgente (te pueden asignar ayuda, se negocia el alcance, o simplemente se avisa al cliente para acomodar la fecha).

Esconderse y no decir nada hasta que sea tarde te deja contra las cuerdas. Siempre recordá: para un product manager o un cliente, es mil veces mejor escuchar una mala noticia hoy con tiempo para maniobrar, que la misma mala noticia quince minutos antes del deadline.