7,729 lecturas

Cómo me convertí en un desarrollador 100x: como junior

por picocreator9m2023/01/03

Demasiado Largo; Para Leer

El desarrollador 10x / rockstar es un mito. ¡Larga vida al desarrollador situacional 100x! Aprenda a mejorar sus probabilidades de convertirse en un desarrollador situacional 100 veces mayor.

featured image - Cómo me convertí en un desarrollador 100x: como junior

La idea de que un desarrollador 10x, o un desarrollador rockstar, sea mejor que cualquier otro desarrollador en todo, es un mito.

En cambio, debe esforzarse por ser un desarrollador 100x en situaciones muy específicas, un desarrollador 10x en algunas y un desarrollador 1x en tantas como sea posible. Es importante ser consciente de las áreas en las que se destaca y las áreas en las que puede necesitar trabajar.

A menos que trabaje para una gran empresa de tecnología, es probable que desempeñe múltiples funciones. Diariamente, deberá poder alternar entre desarrollo front-end, back-end y específico del lenguaje, como Java o TypeScript. Esto se debe a la naturaleza en constante cambio de nuestra industria y la gran cantidad de formas de lograr las mismas tareas, como imprimir "Hello World" en más de 400 lenguajes de programación diferentes.

Es imposible ser bueno en todo, pero es posible ser bueno en algo.

Para elaborar, me gustaría compartir una historia de hace más de una década que fue un momento que cambió mi vida y tuvo un gran impacto en mi carrera.

Cómo me convertí en un desarrollador 100x - como Junior

Trabajé con una multinacional grande y formé parte de un equipo que luchaba por mantenerse al día con la demanda.

Habían creado una aplicación web Java personalizada que miles de empleados usaban a diario, pero a medida que aumentaba la cantidad de registros que entraban y salían de los servidores SQL. Las cosas se estaban ralentizando. Ya habían actualizado el servidor SQL a sus límites y necesitaban nuevas soluciones. Una obvia era usar Memcache para almacenar en caché algunos de los resultados.

Desafortunadamente, Memcache se prohibió debido a algunos incidentes de seguridad en el pasado y la falta de HA. Los gerentes habían estado tratando de obtener la aprobación de Memcache durante más de un año, pero fracasaron. Mientras tanto, los desarrolladores libraron una batalla cuesta arriba, ya que cada 10 % de mejora se vio anulada por el doble del crecimiento de usuarios.

Aquí es donde entré y me uní.

No tenía idea de su último año de lucha y me incorporaron como desarrollador junior para ayudar a realizar algunas mejoras menores en la interfaz de usuario, mientras que los seniors se enfocaban en el rendimiento.

Sin embargo, me molestó mucho el lento rendimiento del servidor de desarrollo. Y había estado jugando con Hazelcast, una nueva biblioteca de almacenamiento en caché y agrupación de servidores basada en Java.

Lo usé como una alternativa a Memcache. Y fue capaz de ejecutarlo en la aplicación, que no tenía restricciones especiales ni requisitos de aprobación especiales, lo que eliminó todas las soluciones anteriores.

Y tenía un prototipo funcional con una demostración lista en la misma semana. Para una página en la plataforma, las llamadas a la API pasaron de más de 10 segundos a menos de un segundo. Fue un cambio de juego.

Todo el equipo se unió y, en un mes, teníamos una "solución de agrupación en clústeres que definitivamente no es Memcache" en producción.

Mientras mi director de equipo y su jefe invitaban a todos a un banquete, mi director me dijo que cuando me incorporó como un niño inteligente, nunca esperó que fuera un programador 10x o 100x que pudiera resolver sus problemas de la noche a la mañana.

Y esa afirmación me impactó mucho.

Porque yo era un impostor, nada más que un impostor con suerte.

The Lucky Imposter: ¿Quién fue un desarrollador de 0.1x?

Técnicamente, no era un desarrollador 1x o incluso 10x. Sabía menos que mis compañeros de equipo y estaba aprendiendo en el trabajo.

Mis compañeros podían hacer el front-end mejor que yo y el equipo sabía cómo optimizar SQL (¡y me enseñó, gracias!). Mi mayor crédito fue que pude hacer el equivalente de "npm install milagro" y leer su manual sobre cómo configurarlo.

En retrospectiva, hubo muchos problemas que había esquivado por suerte.

Política (que bloqueó Memcache en primer lugar)
Caso de uso (no teníamos seguridad de contención de escritura, lo que significa que si ocurren 2 ediciones en el mismo ms, el caché se actualizará mal. Afortunadamente, esto rara vez sucede)
Estabilidad (v1 de Hazelcast se bloquea como loco, afortunadamente, el servidor API fue diseñado para implementarse en modo HA, por lo que esto fue una molestia para el equipo de infraestructura en el peor de los casos)
Seguridad (Tener un puerto abierto para todos los datos en el servidor API en un clúster fue una mala idea de mi parte y un error muy pequeño hasta que otro senior, afortunadamente, leyó los documentos sobre cómo asegurarlo)
Pila de idiomas (si el servidor estuviera en Python, .NET, C# o Ruby, no tendría idea de cómo incluir un caché de clúster local)

Tuve la suerte de tener un puñado de ponis de un solo truco, lo que me hizo 100 veces mayor en las situaciones correctas. Lo cual solo fue posible gracias al trabajo fundamental realizado por el resto del equipo.

También tuve suerte de que mis gerentes y jefes me permitieran elegir los problemas que quería solucionar, ya que me aceleraron y me enviaron a varios equipos para "solucionar sus problemas". Mientras me permite maximizar mi relación suerte-impacto y repetir los "milagros".

Con la experiencia, también me di cuenta de lo contrario: soy lento en el desarrollo de front-end. Esto era lo que originalmente se suponía que debía hacer antes de que me aceleraran como ingeniero 10x y me hizo reflexionar mucho a lo largo de los años. Como podría haber sido el camino en el que me habría quedado atrapado.

También me llamó la atención que, en retrospectiva, haber "dominado" avellana y varias otras tecnologías. Cuánto habría fallado para otros equipos, incluso en la misma organización, si no fuera por la situación única y las garantías que deberían haber sido acreditadas al resto del equipo.

Tuve suerte, como junior, en todo caso.

Esta es la razón por la cual los desarrolladores senior tienden a ser 10 veces más desarrolladores junior

Una vez que miramos más allá de las generalizaciones de la ingeniería, queda claro que todos tienen sus habilidades, que pueden variar de 100x a 0,1x.

A lo largo de los años, mientras me movía entre muchos equipos y proyectos, finalmente me convertí en un desarrollador "senior". Durante este tiempo, me di cuenta de que las personas mayores generalmente tienen más habilidades y saben en qué son buenos y malos. Pueden informar de manera proactiva a sus gerentes y priorizar las tareas en consecuencia. Esto no significa que saben cómo hacerlo todo, sino que saben qué no hacer.

Los jóvenes, por otro lado, luchan con esto ya que carecen de la experiencia para saber en qué son buenos o malos. No hay una manera fácil de averiguar esto que no sea simplemente "probar".

Una vez que se entiende esto, se hace evidente que se trata de maximizar la cantidad de cosas que sabe que puede hacer bien y de manera confiable. También se trata de maximizar tu factor de suerte cuando se trata de que te asignen tareas y asegurarte de que no te quedes estancado con las cosas en las que eres malo.

En cierto modo, para los jóvenes, su progreso dependerá en gran medida de la alineación de su suerte y conjunto de habilidades. Las personas mayores tenían más control (pero no total) sobre cómo dirigir su progreso.

En este caso: La suerte no es binaria. Puede aumentar la cantidad de situaciones que se alinean con usted.

Cómo maximizar la suerte de tu situación en 100x y 10x

Para todos, pero especialmente para los jóvenes y los que recién comienzan, lo mejor que pueden hacer es seguir probando cosas nuevas en tecnología y explorando. Esto te ayudará a descubrir en qué eres bueno y en qué eres malo.

Para aquellos que tienen una mejor idea de en qué son buenos, el siguiente paso es ampliar el número de situaciones en las que pueden rendir al máximo. Esto implica cierta práctica e investigación de tecnologías adyacentes a las que ya conocen. Una vez que seas bueno en algo, asegúrate de poseerlo para que tus gerentes y jefes sepan que esto es lo que deben darte. Esto aumentará las posibilidades de alcanzar esas situaciones de 10x o 100x con más frecuencia.

Encuentra al menos una cosa en la que seas bueno, incluso si es algo muy pequeño y limitado. Construye a partir de ahí. (Algunos ejemplos notables incluyen expresiones regulares y configuración de paquete web).

Para las personas mayores, si aún no lo ha hecho, comience a mirar más allá de los aspectos técnicos del desarrollo. Esto no significa que tenga que pasar a la administración. Pero con su conocimiento técnico único, puede desempeñar un papel más activo en la comprensión del caso de uso comercial o del usuario. Esto le permitirá optimizar con sus gerentes para garantizar tasas de éxito de 10x o 100x para usted y su equipo.

Para aquellos que están buscando trabajo, si saben que son buenos en algo, incluso si es 10 veces mayor, investiguen un poco y profundicen en su búsqueda de trabajo. Trate de encontrar una startup bien financiada o una multinacional que esté enfrentando dificultades exactamente en lo que usted es bueno. Si bien esto puede ser difícil de lograr e implica algo de trabajo en red, si se ubica en el lugar y momento correctos, maximizará el impacto tanto para usted como para la empresa involucrada.

Todas estas son cosas que puedes hacer lentamente con el tiempo para mejorar el factor suerte. Y brinde esa experiencia 10 veces más consistente.

Un saludo especial para leer el artículo de swyx sobre cómo crear suerte: swyx.io/create-luck

Como CTO y líder de equipo hoy en día, esto aún se mantiene: 10x es un mito: todos son 100x y 0.1x

Algunos pueden pensar que el CTO de una herramienta de prueba de UI como Uilicious.com sería bueno con las tecnologías front-end. Sin embargo, esto está lejos de la verdad. Nuestro empleado nuevo o junior promedio en la empresa suele ser más rápido que yo, el CTO, cuando se trata de escribir componentes front-end con marcos front-end modernos como Vue.js o React.

Esto ha cambiado mi perspectiva como líder/gerente de equipo. Me mostró cuán tóxico y malo es el mito del ingeniero 10x. Es una simplificación excesiva de las etiquetas y la generalización de situaciones muy singulares. Es un concepto erróneo tóxico que debe corregirse.

Casi todos los mitos de los ingenieros de startups 10x, cuando se analizan más a fondo, resultan tener un individuo con conocimientos únicos en el lugar y momento correctos. Y pudo evitar las tareas en las que estaban 0.1x.

En mi caso, se centró en la infraestructura sobre el desarrollo front-end. Donde, en cambio, tengo otros miembros del equipo que son 1000 veces mejores en el desarrollo de interfaz.

Esta es una realización importante como gerente porque, por cada individuo que es 100x en una tarea, hay una tarea que los hace 0.1x a medida que se atascan en un sumidero de tiempo. Se trata de entender y reconocer en qué es cada individuo 100x y en qué es 0.1x.

Si bien esto suena muy sencillo, esto es significativamente más difícil en la práctica.

Hay muchas cosas que un líder de equipo o desarrollador no sabrá hasta que lo haya probado antes. O se les da el tiempo y la oportunidad para perfeccionar y dominar las habilidades involucradas en esas situaciones específicas. También hay muchas cosas, especialmente las nuevas tecnologías, en las que nadie es bueno, y se trata de tomar riesgos y oportunidades.

El trabajo del líder del equipo es organizar las tareas en consecuencia para satisfacer mejor las necesidades de todos. Y si eso no es posible, también se trata de comprender que incluso si alguien no puede estar 100 veces en su situación ahora, potencialmente puede estar en otro lugar en otros equipos.

Y depende de cada desarrollador individual, descubrir en qué son buenos y malos, y comunicarlo a su equipo en consecuencia.

Así que a muerte con el Mito del Ingeniero 10x, Viva el Ingeniero 100x en situaciones específicas

PD: Si no has hecho ningún propósito de año nuevo. ¡Quizás aumentar tu área de superficie de suerte podría serlo!

~ 🖖 larga vida y prosperidad

Eugene Cheah: CTO de uilicious.com

Publicado originalmente en: https://substack.tech-talk-cto.com/p/dev-to-cto-how-do-i-become-a-10x

Créditos de imagen