¿Quién es un "ingeniero 10x"?

¿Es alguien que escribe miles de líneas de código todos los días? ¿Es alguien que impulsa las nuevas características del producto durante la noche mientras está fuertemente cafeinado? Además, ¿por qué esta idea de un "ingeniero 10x" empuja a más personas a experimentar el síndrome del impostor en el lugar de trabajo?

En este artículo, desacreditaremos el mito del "ingeniero 10x" y hablaremos sobre el infame síndrome del impostor.

(Para obtener más ideas sobre el "Ingeniero 10x", consulte el artículo anterior de Codementor con el fundador de Moz, Rand Fishkin esta página.)

El hilo de Twitter

Me encontré con un Hilo de Twitter el otro día lo que realmente me intrigó. Este hilo habló sobre cómo se supone que es un "ingeniero 10x". 🤔

Así es como comenzó:

Lo que me intrigó aún más fue ver cuántos ingenieros experimentados, expertos en desarrolladores de Google, líderes de ingeniería y otros profesionales en Twitter se estaban entusiasmando con la idea de un "ingeniero 10x", de acuerdo con este hilo en particular.

Veamos por qué, echemos un vistazo más de cerca a los 11 puntos hechos en este hilo de Twitter y discutamos por qué la idea de un "ingeniero 10x" podría tener efectos nocivos para empleadores y empleados. También voy a hablar sobre algunas conclusiones clave en este artículo.

Aviso: Este artículo solo contiene mis puntos de vista sobre el "Ingeniero 10x" y de ninguna manera pretende faltarle el respeto a nadie ni a sus puntos de vista.

Se toman muchas decisiones importantes en las reuniones. Como ingeniero, es importante estar en un equipo multifuncional, donde no solo interactúas con otros ingenieros, sino que también hablas con diseñadores, desarrolladores de backend, gerentes de productos y otras partes interesadas de la empresa. Esto le permite tener una mejor idea del producto en el que está trabajando y la dirección en la que se dirige.

No veo por qué esto se ve como algo negativo. Un ingeniero debe tener un buen conocimiento del producto. Definitivamente no se recomienda simplemente empujar miles de líneas de código y llamarlo por día.

Sé que todo el mundo odia las reuniones, pero eso no significa que no sean productivas. 👨‍💻

Lo que aprendiste : Asistir a las reuniones. No todos serán productivos, pero para los que lo son, aprenderá mucho de las personas en otros departamentos de la compañía. Toma todo y absorbe todo lo que puedas.

Potencialmente, esto podría dar a "10x ingenieros" una excusa para no llegar a tiempo. Personalmente trabajo hasta las 2 de la mañana, pero duermo 6 horas y estoy en la oficina a las 10 de la mañana. Además, me encanta trabajar con otras personas. Aprendo mucho de personas con más experiencia laboral que yo.

Si bien es tentador que algunos ingenieros necesiten algo de privacidad cuando trabajan, no significa todo el Los ingenieros son así. Si eso tuvieron En el caso, tendríamos muchas oficinas vacías durante el día. 🤷‍♂️

Lo que aprendiste : Estar abierto a aprender cosas de sus colegas es algo que nadie en un lugar de trabajo debería descuidar. No te limites a tu escritorio en la oficina. Trate de llegar a tiempo, pero lo más importante, mantenga un buen equilibrio entre trabajo y sueño. La codificación nocturna no es buena para usted si no cumple con sus requisitos personales de sueño.

Para empezar, ¿qué tiene que ver el fondo de pantalla de mi computadora portátil con algo? Así es como se ve la pantalla de inicio en mi computadora portátil en este momento:

Además, las teclas que están desgastadas en mi computadora portátil son Control y Tab audio, debido a la función de cambio de pestaña en macOS y Chrome, que utilizo con frecuencia en Google para obtener respuestas cuando me encuentro con un desafío de codificación. (Soy un ingeniero 1x. 😉)

Lo que aprendiste : Configura tus dispositivos y optimízalos para su proveedor Máxima productividad. Ignora todas las demás normas y el "deberías usar esto" y "¿por qué no estás usando esto?" sugerencias Tome buenos consejos, pero al final del día, descubra qué funciona mejor para Usted.

La mayoría de los ingenieros que conozco confían en sus habilidades de resolución de problemas y habilidades de "pensar en sus pies", en lugar de depender de su poder de memoria. Este Tweet implica que 10x ingenieros tienen un poder de memoria increíble.

Cuando QA sí alertándolos de un problema, los ingenieros suelen resolver el problema utilizando sus habilidades y el conocimiento que tienen de la base de código. Algunos problemas pueden llevar horas, otros pueden llevar días. Pero no todos los problemas se pueden solucionar en horas; simplemente no es factible en la vida real.

Lo que aprendiste : Conozca bien su código base, pero no se presione demasiado para saber cada línea de código Te familiarizarás más con el tiempo. La corrección de errores y errores también es algo que mejorará con el tiempo.

No tendríamos ingenieros de front-end, ingenieros de UX o alguien que se especialice en convertir buenos diseños en código de interfaz de usuario si todos los "10x ingenieros" fueran ingenieros completos. Claro, los ingenieros completos son geniales, y conozco a algunos de ellos que son expertos en múltiples cosas en un producto, pero esta idea de un "ingeniero 10x" rara vez hace algún trabajo de interfaz de usuario no funciona en ninguna organización.

El trabajo de UI es igual de importante y viene con sus propios desafíos.

Lo que aprendiste : Si eres un ingeniero de pila completa, entonces eso es fantástico. Trabaja en todas las cosas en las que te encanta trabajar. Si eres un ingeniero front-end, eso también es increíble. Concéntrese en sus habilidades de codificación de UI y sea excelente en eso. Depende de Usted tanto si quiere ser especialista en un conjunto particular de habilidades, como si desea experimentar y trabajar con múltiples conjuntos de habilidades.

La idea de que uno podría convertir "pensamiento" en "código" podría desmotivar a los ingenieros junior, que recién están comenzando en sus campos. Este es exactamente el tipo de presión que los ingenieros deben evitar imponerse.

Además, si bien es una buena habilidad poder desarrollar características del producto rápidamente, también es importante recordar que este tipo de habilidad se perfeccionó durante años de trabajo como ingeniero. La idea de "tomar mucho café y desarrollarme esta función en cuatro a seis horas" es una forma tóxica de presionar a los ingenieros para que hagan el trabajo más rápido.

Además, ¡demasiada cafeína es mala para tu salud! 🙅‍♂️

Lo que aprendiste : No le harás ningún favor a nadie si te cafeinas y te quemas; eso solo ralentiza tu productividad. Divida la tarea de construir la función en partes más pequeñas, hable con su gerente y establezca algunas expectativas reales sobre la fecha límite de la función del producto. Hacer esto no solo aumenta la cantidad de respeto que las personas tienen por ti en el lugar de trabajo, sino que también asegura que no establezcas expectativas poco realistas en los plazos.

Todo el propósito de tener documentación sobre algo is para que los ingenieros lo vean. No importa si son junior, intermedios o senior, cada ingeniero revisa la documentación de vez en cuando. Confiar completamente en el poder de la memoria nunca es una buena idea.

Lo que aprendiste : Eres un ingeniero humano. Definitivamente no eres un ingeniero robot. No necesita tener ninguna documentación memorizada. Puedes buscar cosas en Internet, porque te aseguro que eso es lo que hacen incluso los ingenieros más experimentados. Pero como ingeniero, siempre es una buena idea saber cómo formular la pregunta para su problema, en lugar de simplemente memorizar la solución a su problema. Saber cómo y qué preguntar y recibirás respuestas.

Este Tweet tiene algunos buenos puntos. Es importante aprender nuevos marcos e idiomas, pero la parte donde los "10 ingenieros" hacen eso "por delante de todos en la empresa" podría generar negatividad en el lugar de trabajo.

En cambio, si hay un nuevo marco que algunos ingenieros deben aprender en la organización, y este supuesto "ingeniero 10x" ya lo ha aprendido, es deber del "ingeniero 10x" establecer un taller o un hackathon donde / ella ayuda a capacitar a otros colegas en el aprendizaje del marco.

Después de todo, qué ingeniero no amar un hackathon? 😉

Lo que aprendiste : Continúe y aprenda ese nuevo marco o lenguaje del que todos hablan, pero sea humilde y procure ayudar a capacitar a las personas que son nuevas en él.

Este Tweet me lleva de vuelta al mismo punto que hice para el # 8. Su trabajo como ingeniero no es solo empujar miles de líneas de código. Debes poder comunicarte bien con tu equipo. Pero no es una gran idea promover el mal trabajo en equipo al insinuar que un "10x Engineer" es un ejército de un solo hombre.

Te aseguro que ese no es el caso. Cualquier buen producto en cualquier gran organización se construye con un buen equipo de personas. Estas personas tienen un gran trabajo en equipo y química entre ellos.

Además, si los "10x ingenieros" son "malos entrevistadores", entonces eso demuestra que son malos en la comunicación y en la presentación.

Lo que aprendiste : Si está trabajando con alguien que necesita su ayuda, debe ser capaz de ser su mentor. Una vez más, esto se relaciona con la idea de mejorar el equipo en su conjunto, en lugar de hacerlo todo usted mismo. Tómese el tiempo para discutir ideas con todos en su equipo y, le prometo, le devolverá el dinero a tiempo.

Si bien es una idea fantástica escribir código bien estructurado, no puede saber cómo podría evolucionar su código. Es posible que haya un nuevo marco de trabajo que deba usar que podría cambiar toda la estructura de su código. Estoy a favor de escribir código de calidad, pero no estoy seguro de cuánto estoy de acuerdo con saber exactamente cómo El código tiene que evolucionar.

En otra nota, escribir un documento de diseño bien detallado es una necesidad absoluta si su equipo planea expandirse y contratar más ingenieros. Facilita la experiencia de incorporación para nuevos ingenieros.

Lo que aprendiste : Escriba código de calidad, tenga un buen modelo mental de la estructura general de su código, pero esté preparado para incorporar nuevos marcos y tecnologías en su base de código existente. También asegúrese de escribir una buena documentación para su código para que los nuevos ingenieros que eventualmente trabajarán en el producto no tengan ningún problema en la comprensión del código.

Los ingenieros expertos, la mayoría de las veces, son los que buscan trabajo o se mudan de la empresa. ¿Por qué? Esto podría ser por cualquiera de las siguientes razones:

• Su trabajo actual no es lo suficientemente desafiante y quieren explorar nuevos desafíos en otras organizaciones que puedan ayudarlos a crecer como ingenieros.
• No están contentos con la forma en que están siendo compensados ​​por sus habilidades y están buscando paquetes de salarios más altos que reflejen sus habilidades.
• Pueden encontrar tóxicos en el lugar de trabajo actual, es decir, pueden tener un jefe que quiere que sean un "10x Engineer" 😉

Además, si eres un gerente de contratación y te encuentras con un ingeniero al que no le gustan las reuniones, la capacitación o cualquier cosa que tenga que ver con ayudar a su equipo, corre en la dirección opuesta. Esta es una señal de una persona con intereses personales tan profundos que sus habilidades no beneficiarán a nadie aparte de sí mismas a largo plazo.

Pero bajo ninguna circunstancia debe "aferrarse a ellos" o "celebrarlos". 🙅‍♂️

Lo que aprendiste : Si eres feliz en tu organización actual, eso es fantástico, pero si alguna de las razones mencionadas anteriormente parece resonar con usted, sugeriría buscar trabajo y encontrar un trabajo donde sea más feliz y esté más satisfecho. Encuentre el trabajo adecuado para usted, participe en reuniones y capacitación, y crezca como ingeniero mientras ayuda a su equipo a crecer con usted.

Ahora que he hablado sobre este hilo particular de Twitter, pasemos a otro problema que muchos ingenieros enfrentan al menos una vez en sus carreras.

El temido "síndrome del impostor"

Si es un ingeniero junior y acaba de comenzar su nuevo cargo en su empresa, estoy seguro de que algunos de los siguientes pensamientos podrían haberle corroído en algún momento:

• "No soy lo suficientemente bueno."
• "¡Fui contratado por accidente!"
• "¿Cómo voy a ser tan bueno como mis colegas aquí?"

¿Adivina qué? También me sentí así en mi primer papel de ingeniero, y no estás solo. De hecho, los estudios muestran que incluso los ingenieros superiores se han sentido así, ¡incluso después de muchos años de experiencia! Impactante, ¿no es así?

Ahora, no estoy seguro de por qué la mayoría de los ingenieros, incluido yo mismo, sentimos de esta manera, pero sí sé cómo lo estoy abordando. La solución es bastante simple: no te obsesiones si te contrataron por accidente o si eres lo suficientemente bueno para el trabajo. Deja que la persona que te contrató haga eso.

Lo que esto significa en palabras más simples: si te contrataron para el trabajo, eres lo suficientemente bueno para el trabajo. No hay absolutamente ninguna necesidad de reflexionar sobre si fue "contratado accidentalmente". El gerente de contratación vio algo en ti que le gustó y decidió que estabas en forma para el puesto, punto.

Mantente enfocado en hacer bien tu trabajo, y lo harás genial. Hay mucho espacio para aprender cuando eres nuevo en tu campo de trabajo, especialmente cuando trabajas con ingenieros que tienen más experiencia en el campo.

Sin embargo, esto no debería ser una puerta de entrada para la duda, sino que debería verse como una oportunidad para desarrollar sus habilidades en su nuevo rol.

"Si eres la persona más inteligente en la habitación, probablemente estés en la habitación equivocada".

Fuente: https://www.codementor.io/blog/10x-Engineer-Not-Necessary-7do0ivvl3r