Volver a programar después de liderar equipos: lo que nadie te dice
Volver a programar después de liderar equipos: lo que nadie te dice
Durante los últimos años, mi día a día ha estado lleno de reuniones, llenar formatos de Excel, seguimiento a proyectos, resolución de incidentes y toma de decisiones técnicas; sin contar la lucha constante para que el equipo esté en armonía y la mediación de conflictos. Cada vez paso menos tiempo frente a un editor de código y estoy cada vez más lejos de la implementación directa.
Si has pasado por algo parecido, probablemente conoces esa sensación incómoda: la de preguntarte si, al dejar de programar todos los días, sigues siendo realmente una persona “técnica’’. Ese pensamiento en mi cabeza es algo que me ha hecho sentir insegura y frustrada algunas veces.
Y es curioso, porque muchas veces ese juicio no viene de afuera, sino de una voz interna que cuestiona constantemente si somos suficientes. Como dijo Friedrich Nietzsche:
“…el peor enemigo que puedes encontrarte serás siempre tú mismo; a ti mismo te acechas tú en las cavernas y en los bosques”.
Este post nace precisamente de ese diálogo interno, y de la necesidad de ponerlo en palabras para entenderlo mejor.
El mito de que si no programas, ya no eres ‘‘técnico’’
Existe una idea muy extendida en tecnología: si no estás escribiendo código constantemente, te quedas atrás. Y aunque hay una parte de verdad —la práctica importa—, también es una visión incompleta.
Liderar equipos técnicos, diseñar soluciones, resolver incidentes reales y tomar decisiones de arquitectura también es trabajo técnico. No se ve igual, no se mide en commits, pero tiene impacto directo en los sistemas y en el negocio.
El problema no es dejar de programar. El problema es dejar de aprender o dejar de cuestionarse.
Lo que sí se oxida… y lo que no
Ser líder de un equipo es algo que no estuve buscando, fue una propuesta que llegó sola mientras yo solo intentaba dar lo mejor de mí y ayudar al equipo en base a lo que había aprendido y el conocimiento que hasta ese momento había adquirido del negocio. Después de llevar varios años más cerca del liderazgo que del código, he notado algo muy claro.
Se oxidan:
La sintaxis exacta.
La velocidad escribiendo código.
El dominio de frameworks específicos.
Pero no se oxidan:
La lógica.
La capacidad de análisis.
El criterio técnico.
La comprensión de problemas reales.
La conexión entre negocio y tecnología.
Y esa diferencia es importante, porque define cómo volver.
Por qué decidí volver al código
No volví por nostalgia ni por miedo. Volví por decisión.
Quiero volver a programar porque:
quiero construir soluciones completas,
quiero vender y ejecutar ideas sin depender siempre de terceros,
quiero mantenerme vigente técnicamente,
y, sinceramente, porque disfruto programar.
No se trata de competir con perfiles junior ni de aprender todas las tecnologías de moda. Se trata de volver con contexto.
Cómo voy a hacerlo (sin volverme loca)
No tengo un plan de estudiar ocho horas al día (seamos realistas, no tengo todo ese tiempo) ni de aprender todo lo nuevo que ha salido.
Mi enfoque es simple:
un stack claro,
proyectos reales,
poco tiempo pero constante,
y documentación honesta del proceso.
Parte de este proceso será trabajar en proyectos reales, nacidos de necesidades concretas, que me obliguen a tomar decisiones técnicas y no solo a seguir tutoriales.
Los proyectos que vienen
En lugar de aprender de forma abstracta, voy a trabajar en proyectos reales, con problemas cotidianos, decisiones técnicas y errores incluidos. La idea es construir, equivocarme, ajustar y documentar el proceso aquí, con total honestidad.
Para cerrar
Esto no es empezar de cero. Es volver con más contexto, más criterio y menos prisa.
Este blog es parte de ese proceso: aprender, construir y compartir lo que sí funciona en el mundo real.
Si estás en un punto parecido, quizás este camino también te sirva.
Vane — Backend, sistemas reales y liderazgo técnico
Documentando el regreso al desarrollo