br11k.dev:

Podrías pensar que la Ingeniería consiste en crear sistemas complejos.

No es así.

Si miras la charla de Rich Hickey entenderás por qué. Los mejores ingenieros reducen la complejidad. Los mejores programadores encuentran un grifo viejo, oxidado y que gotea, y lo cierran.

¿Qué pasa cuando un grifo gotea? Se forma un charco de agua. Y tu primera intuición es trapear el suelo. Y si nunca levantas la vista y te preguntas "¿por qué demonios estoy trapeando esto todos los días?", puede que nunca descubras que había un grifo instalado hace 10 años.

Y quien instaló este grifo puso en su commit de git "es un MVP, los detalles están en el ticket ABC-123 del gestor de errores". El gestor de errores desapareció, esa persona ya no trabaja allí y tú eres el arqueólogo que acaba de descubrir esto.

Entonces, ¿qué haces? ¿Construir encima de ese grifo oxidado que gotea?

No, por favor, no lo hagas. Detente. Es genuinamente algo bueno que hayas encontrado el grifo y debes documentarlo inmediatamente como una especificación. Este es el problema que debes al menos reconocer que existe porque ya se "filtra" en tu sistema.

Ya he linkeado a una charla de Rich Hickey antes. Así te conviertes en Staff engineer:

Lo que quiero mostrar es que la complejidad es una elección. La simplicidad también es una elección. Y los ingenieros construyen relaciones semánticas entre lo que el producto debe hacer y lo que el sistema acotado real —el código— hace.

Y sí, siempre es más fácil añadir más nodos de grafo sobre un grafo "monolítico" existente con 1,000,000 de líneas de código.

Pero los mejores ingenieros que he visto no hacen eso. Se dedican a excavar ese grafo de complejidad y descifran cómo despedazarlo y sustituirlo por una solución más simple.

Y una vez que te des cuenta de esto, te convertirás al menos en un ingeniero de nivel Staff. Porque ahora, amigos míos, veréis dónde están los grifos que gotean y cómo exactamente producen complejidad y trabajo que nadie necesita hacer, una vez que simplemente arreglas la "fuente" de tus problemas.

No trapees el suelo. Arregla el maldito grifo que gotea.

El paso después de Senior no es convertirte en Manager:

En la empresa correcta, una vez que eres Senior, convertirte en manager no es “lo que sigue”.

Pero aquí hay algo que tienes que considerar: mientras más creces en tu carrera como contribuidor individual, menos se mide tu impacto en líneas de código. Habilitar a otros desarrolladores, aportar valor a otros equipos y áreas de negocio, dar visibilidad a problemas. Todas estas son competencias clave que vas a tener que desarrollar, sí o sí. Todas ellas, van a requerir que le pongas atención, de alguna u otra manera, a tus Soft Skills y a tus habilidades de colaboración con otras personas.

Está bien que no te guste (o te cague) la gente. No todas las personas somos sociales por naturaleza.

Pero la oportunidad de mejorar tu carrera ahí está. Si no quieres convertirte en manager, no tienes que hacerlo.

Lo que sí tienes que hacer, es asegurarte de estar en la empresa correcta para seguir creciendo sin tener que tomar tareas administrativas. Y trabajar en tus Soft Skills.