¿Te suena lo de ser el "solucionador" oficial de la oficina?
Seguro que sabes de lo que te hablo. Ese sentimiento de orgullo un tanto masoquista que te entra cuando alguien del equipo dice: "Esto es un marrón increíble, que lo mire Roberto que él siempre nos saca las castañas del fuego". Durante muchísimos años, yo me alimentaba de eso. Pensaba que ser un buen desarrollador, y sobre todo un buen compañero, consistía en tener la bandeja de entrada de peticiones siempre abierta y responder con un rotundo "claro, cuenta con ello" a cualquier cambio de última hora, bug crítico (que luego no lo era tanto) o funcionalidad inventada en una reunión de viernes por la tarde.
Creía, de forma bastante ingenua, que decir que sí a todo me hacía imprescindible. Que me daba un aura de eficiencia y compromiso que nadie más tenía. Pero lo que no veía es que, mientras acumulaba esos "síes" como si fueran medallas, estaba cavando un pozo de agotamiento y frustración que casi me hace tirar la toalla en esta profesión que tanto amo. Y no solo eso: mi código estaba empezando a dar pena. Cuando intentas complacer a todo el mundo, acabas no haciendo nada realmente bien.
El día que mi cerebro dijo "hasta aquí"
Recuerdo perfectamente el momento en que todo cambió. Estábamos en medio de un lanzamiento importante para un cliente de los que no perdonan ni una. Mi lista de tareas era ya de por sí inmanejable, pero seguí aceptando pequeños ajustes "rápidos" de diseño, cambios en la lógica de validación que el Project Manager acababa de soñar y un par de refactorizaciones que, según un compañero, "no llevarían más de diez minutos".
Eran las diez de la noche de un jueves. Estaba delante de mi editor, con los ojos como platos, intentando entender por qué una función que yo mismo había escrito hacía dos horas no funcionaba. Me di cuenta de que no solo estaba cansado físicamente, sino que mentalmente me había convertido en un procesador colapsado. Mi capacidad de análisis crítico había desaparecido por completo. Había dicho que sí a tantas cosas que ya no sabía cuál era la prioridad real. Al final, entregamos algo que funcionaba a duras penas, lleno de parches y con una deuda técnica que nos perseguiría durante meses. Ese fin de semana, en lugar de descansar, solo podía pensar en lo mucho que odiaba el proyecto y, por extensión, mi trabajo.
¿Por qué me parece tan importante aprender a decir que no?
Después de ese episodio, tuve una conversación muy honesta conmigo mismo (y con mi almohada). Me di cuenta de que mi incapacidad para poner límites no era una virtud, sino una debilidad. Cuando dices "sí" a un cambio de última hora sin evaluar el impacto, estás siendo irresponsable. Estás poniendo en riesgo la estabilidad del sistema y la calidad del producto final. Ser un profesional no es hacer todo lo que te piden, sino saber qué es lo correcto para el proyecto.
Empecé a entender que la gente no me respetaba más por decir siempre que sí. Al contrario, me veían como el recurso fácil, el camino de menor resistencia. Si alguien necesitaba algo rápido y sucio, venían a mí. Si alguien quería un análisis serio y una implementación robusta, buscaban a otros que sabían defender sus tiempos y sus procesos. Esa realización me dolió, pero fue el motor del cambio. Entendí que mi valor como desarrollador no reside en mi velocidad para parchear, sino en mi capacidad para construir soluciones sostenibles.
Lo que he aprendido en este proceso de "rehabilitación"
El primer "no" que solté fue aterrador. Fue ante una petición de añadir un filtro complejo en un dashboard cuando ya estábamos en fase de cierre de sprint. Recuerdo que se me aceleró el pulso. Pero lo hice de forma constructiva: "Entiendo que este filtro es útil, pero añadirlo ahora mismo pone en riesgo la estabilidad de lo que ya hemos probado. Podemos meterlo en el siguiente sprint con el tiempo que se merece". ¿Y sabes qué pasó? Nada malo. El Project Manager asintió, anotó la tarea para más adelante y me dio las gracias por el aviso.
He aprendido un par de cosas fundamentales desde entonces. Primero, que un "no" a tiempo es en realidad un "sí" a la calidad. Al rechazar una tarea extra, estoy asegurando que las tareas que ya tengo en la mesa se terminen con el rigor necesario. Segundo, que la transparencia genera confianza. Ahora, cuando alguien me pide algo, mi respuesta suele ser: "Déjame analizar el impacto y te digo si encaja en el cronograma actual". Esto me da espacio para pensar y demuestra que me tomo mi trabajo en serio.
Curiosamente, mi relación con el equipo mejoró drásticamente. Al dejar de ser el "chico de los recados técnicos", empecé a participar más en las decisiones de arquitectura. Mis opiniones empezaron a tener más peso porque la gente sabía que, si yo decía que algo se podía hacer, era porque realmente era viable y seguro. Me convertí en un referente de criterio, no solo de ejecución.
Reflexiones finales
Si estás leyendo esto y te sientes identificado, si sientes ese nudo en el estómago cada vez que te llega una notificación de Slack con un "¿tienes un hueco para una cosita rápida?", mi consejo es simple: empieza poco a poco. No hace falta que mañana seas un muro infranqueable, pero empieza a cuestionar las peticiones que te llegan. Pregunta por el impacto, pide prioridades claras y, sobre todo, valora tu propio tiempo y salud mental.
Al final del día, el código que escribimos es un reflejo de nuestro estado mental. Un desarrollador agotado y resentido escribe código que, tarde o temprano, alguien tendrá que arreglar. Poner límites no te hace menos compañero, te hace mejor profesional. Y créeme, una vez que das el paso y ves que el mundo no se acaba por decir que algo no se puede hacer ahora mismo, la libertad que sientes es increíble. Ahora disfruto mucho más de mi trabajo, mis entregas son mucho más sólidas y, lo más importante, vuelvo a dormir tranquilo por las noches sin repasar mentalmente los commits de última hora que nunca debí subir.