Bueno, odio reventar tu burbuja, pero si es la tercera vez que esto sucede, eso casi descarta “no eres tú, son ellos”. Tu título dice que fuiste despedido por ser “indispensable” pero aparte de que eso es un oxímoron, tampoco es lo que pasó. Fuiste despedido por escribir código que tus colegas no pueden entender, lo cual es un problema crítico de rendimiento para un programador.

El buen código es código legible, es decir, código que es fácilmente comprensible, incluso para los novatos. Las situaciones en las que se necesita un código complejo y apretado que debe ser escrito y mantenido por verdaderos expertos son muy raras hoy en día y evidentemente no se trabaja para ese tipo de empresas. Lo que describes suena más como un código “elegante” que es típicamente demasiado complejo, lleno de trucos de programación esotérica y que toma años en ser descifrado y depurado. Es un fallo común para la gente que fue entrenada clásicamente y que típicamente se despierta bruscamente una vez que entra en un ambiente productivo.

No es una broma, no podría soportar que esto ocurriera por cuarta vez, me está impactando mentalmente.

Esta línea es importante, porque muestra que sientes que es hora de cambiar. Muestra que reconoces esto como un patrón, y que te gustaría que el patrón se detuviera. Ese deseo es probablemente la parte más importante de la solución. Arreglar este tipo de situaciones a menudo implica cambiar la forma en que tú, tú mismo, piensas. Es imposible que alguien haga eso por ti, así que tu deseo de cambiar será lo único que haga que el cambio ocurra.

Para algunos antecedentes, he estado en situaciones similares de “demasiado bueno para codificar para mi trabajo” antes, aunque nunca en el grado que describes. Podría curar el cáncer con metaprogramación de plantillas en C++, pero muchos con los que trabajo apenas conocen los fundamentos del Diseño Orientado a Objetos. Escribí código que abusaba de SFINAE y empujaba contra la redacción exacta de las especificaciones de C++, cuando muchos proyectos en los que trabajaba todavía usaban versiones anticuadas y de bichos de gcc. Mi enfoque fue simplemente mostrarles lo asombrosas que son estas herramientas, y todos los problemas que podría resolver. Me encantaba explicar pequeños consejos de programación a la gente, y ellos lo disfrutaban en gran medida.

¿Le suena familiar?

“Sí, pero uno debe tener un buen nivel para entender [el código de Mik] porque los componentes están desacoplados de forma inteligente”

Considere esta afirmación desde una perspectiva basada en el riesgo. Tu jefe necesita mantener las cosas en marcha, sin importar qué. Si te vas a buscar una oportunidad de trabajo increíble, tu jefe aún tiene que asegurarse de que el código se mantenga. Lo que tu compañero de trabajo acaba de decir es que, si tienen que reemplazarte, ellos necesitan encontrar un codificador muy hábil, porque cualquiera que no sea tan bueno no podrá mantenerlo. Esto es un riesgo. ¿Qué pasa si no pueden encontrar un desarrollador lo suficientemente bueno, o no pueden permitirse pagarles lo suficiente?

Puede que hayas producido lo que llamarías “buen código”, pero la definición de “buen código” es muy dependiente del contexto. Lo que es “buen código” en Google, con sus formas de pensar vanguardistas, puede ser un código muy malo para alguien que trabaja en la FAA, que está predominantemente preocupado por la fiabilidad en lugar de mantenerse al día con la vanguardia. La definición de tu jefe de “buen código” incluye la capacidad de mantenerlo en todo tipo de situaciones, incluso sin ti. Si sus compañeros de trabajo no se sienten cómodos manteniendo su código, entonces usted es de repente una responsabilidad para la empresa, porque produce un producto que no pueden mantener si decide irse a otro lugar.

Desde esta perspectiva, se puede argumentar que usted los está forzando a aceptar su definición de “buen código”. Instintivamente, esto puede parecer algo bueno, pero está lleno de dificultades, como esta forma de pensar basada en el riesgo, en la que puede que no hayas pensado.

Tenemos una frase, “poner el carro delante del caballo”. Uno de los muchos significados asociados con ella es poner el contenido que más le interesa (poder usar sus técnicas avanzadas) por encima de las fuerzas que deberían estar tirando de él hacia adelante (la comprensión de estas técnicas por parte de su compañero de trabajo). Has escrito el código en este estilo avanzado, y luego has animado a los otros desarrolladores a “ponerse al día” con este estilo. Esto puede ser efectivo, pero si algo le sucede antes de que “se pongan al día”, la empresa se encuentra de repente en peligro porque nadie puede mantener el código.

¿Cómo puedo evitar esto en el futuro?

Arreglar esto puede ser algo terriblemente difícil porque implica abordar el problema de una manera diferente a la que normalmente se siente cómodo. En lugar de escribir primero el código en este estilo avanzado, y luego enseñar a tus compañeros de trabajo a pensar de esa manera, deberías darle la vuelta. Enseñe a sus compañeros de trabajo a gustar de ese estilo de codificación, y luego empiece a escribir código en ese estilo. Puede parecer al revés, pero es mucho más estable. Desde la perspectiva de un jefe, hay poco o ningún riesgo de que el equipo aprenda a codificar mejor. Una vez que codifican mejor, el estilo en el que quieren desarrollarse es de repente menos arriesgado.

Mientras tanto, tendrán que escribir código que, según sus estándares, es “menos bueno”, pero está bien. Tu código no es tu único producto aquí. Su otro producto está ayudando a enseñar a los otros desarrolladores, y el valor de eso puede fácilmente exceder el valor de escribir “código perfecto”.

Por supuesto, puede ser difícil decir cuando es seguro escribir código en el estilo que quieres escribir. Si fuera fácil de decir, ¡seguro que ya lo habrías descubierto! Una técnica poderosa que puedes usar es dejar que otros presionen por los estilos de codificación avanzados, en lugar de presionar por ti mismo. Una cosa es enseñar a alguien la diferencia entre herencia y composición. Una cosa completamente diferente es enseñarles lo suficientemente bien como para que aboguen por cambiar su base de código existente para ser más claro en su uso. El último caso realmente te hace saber que no sólo entienden el concepto, …pero que realmente lo acepten.

Un ideal para enseñar tales conceptos es no enseñar nada. Dejar que los estudiantes descubran algo, y entonces les señalas la dirección en la que el descubrimiento puede ir. Tal vez uno de ellos descubra algo claro sobre la herencia y puedas dirigirlos hacia el patrón de diseño de los Visitantes basado en lo que descubrieron. No les des simplemente un Visitante, sino que les des un sentido de dirección para que puedan salir y encontrar ellos mismos un Visitante.

Es un enfoque mucho más difícil, y ciertamente querrás encontrar un medio feliz entre eso y tu enfoque actual, pero puede ser muy gratificante. Más importante para su respuesta, puede proporcionar valor a la compañía sin el riesgo. Si usted está proporcionando valor a una empresa, y no poniendo la empresa en riesgo, usted virtualmente nunca será despedido. Y en los pocos casos en los que todavía puede ser despedido, la dirección le dará una razón para ello (como un descenso en la economía, o un cambio en la dirección de la empresa). Si lo haces muy bien, descubrirás que la gerencia, en cambio, comenzará a moldear tu camino, al igual que moldeas a tus compañeros de trabajo, y encontrarás una curiosa tendencia a haber aprendido justo la habilidad correcta justo cuando más la necesitan.

Siempre hay razones.

Un empleador anterior hizo esto con un compañero mío. Su nivel de habilidad estaba mucho más allá de nuestra habilidad. Así que lo dejaron ir.

¿Por qué tiene esto sentido?

1. Era el único que podía mantener su código
2. No era colaborador
3. No seguía los estándares de la tienda… Mientras que él estaba entregando más de lo necesario, esto no era algo bueno
4. Se necesitaban soluciones simples en lugar de complejas

Se dice tan a menudo que es casi un cliché, pero tienes que ser un “buen ajuste” para el equipo.

La codificación es sólo una parte de la ecuación. Tienes que ser amable, comunicativo, humilde hasta cierto punto, arrogante cuando sea necesario, mantener los estándares de la tienda, llevarte bien con tus compañeros de trabajo, ser accesible, y rápido para ayudar cuando sea necesario.

Todas estas habilidades suaves son importantes, y no tenerlas te causará problemas.

Un buen código es fácil de entender, incluso para los ingenieros pobres. Un consejo que recibí a menudo es “programa como si la persona que mantendrá tu código fuera un programador mediocre, y un peligroso psicópata que sabe dónde vives”.

Y es verdad. La programación demasiado inteligente es mala, porque el mantenimiento es más largo cuando no conoces el código. En el mantenimiento, a menudo tienes fuego por todas partes, miles de clientes bloqueados, y una solución más inteligente y eficiente podría muy bien mantener al mantenedor atascado por más tiempo que un tonto código tipo script lleno de repeticiones.

Por supuesto, el código totalmente tonto es malo también. Hay un buen equilibrio a encontrar entre la tontería y la genialidad: eficiente, y aún así legible. Es más un arte que una ciencia. Es por eso que los conceptos inteligentes como la herencia múltiple generalmente no se aconseja. Incluso si se balancean.

Hay que tener en cuenta el contexto. Si trabajas en una pequeña empresa de vanguardia que contrata sólo a los mejores, probablemente puedas permitirte algunas cosas exóticas y brillantes. Si trabajas para un banco francés que sólo se basa en consultores de, errrm, calidad aleatoria (a veces tienen suerte, a veces no), y donde cada consultor tiene un dominio de millones de LOC que mantener, entonces por todos los medios hazlo lo suficientemente simple para que un mediocre lo entienda a primera vista. Sin punteros, sin herencia múltiple, sin trucos ingeniosos, etc…

Es poco probable que te despidan porque eres demasiado bueno. Supongo que eso es sólo una excusa.

Es mucho más probable que sea un problema de comportamiento, o que al jefe no le gustes por razones que no puede contarte sin crear motivos para una demanda. También es posible que seas el más caro y que ellos crean en los ETC (es decir, todos los trabajadores son iguales).

Si realmente eres tan bueno, puedes hacerte indispensable de una buena manera:

• Mentor de los programadores junior. Cuéntales las ventajas y desventajas de los diferentes enfoques y déjales que cometan sus errores en lugar de decirles qué enfoque tomar.
• Escribe un buen código que sea fácil de mantener por otras personas.
• Aboga por las mejores prácticas de manera que aumente la productividad, en oposición a el culto a la carga las mejores prácticas, que suenan bien en el papel pero matan la productividad.

Despedir a las personas indispensables es en realidad una estrategia de gestión sólida. Cuando su empresa depende de que una sola persona continúe haciendo su trabajo y nadie más en la empresa tiene sus conocimientos y/o capacidad, esto crea una enorme responsabilidad: ¿qué pasa si esa persona es atropellada por un autobús y muere (de ahí el término “factor autobús”) o simplemente elige dejar la empresa para un nuevo desafío? Ahora su empresa está atascada en una terrible situación porque nadie puede reemplazar inmediatamente al empleado indispensable y usted no tenía control sobre el tiempo!

Para prevenir esta situación, la empresa tiene dos opciones. O bien puede intentar difundir los conocimientos y/o aumentar la capacidad de los compañeros de trabajo de la persona indispensable, o bien puede quitarle la tirita de una vez despidiendo a la persona indispensable en un momento de su elección y recuperarse de la pérdida de dicho trabajador cuando esté preparado para ese proceso.

Como no siempre es práctico cerrar una gran brecha de conocimientos y sobre todo de capacidad, despedirlos puede ser la opción más lógica.

Como empleado, siempre debe intentar prevenir que se convierta en indispensable. Compartir tus conocimientos con tus colegas y asegurarte de que hay gente que puede hacer tu trabajo cuando tú no estás. Asegúrate de que tus prácticas se adaptan a los trabajadores con el nivel medio de cualificación de tu empresa. Si considera que ese nivel medio es demasiado bajo, trabaje con la dirección para tratar de aumentar ese nivel. Asegúrese de que todo lo que cree esté bien documentado y que dicha documentación sea de un nivel lo suficientemente alto como para que cualquiera de sus colegas pueda utilizarla para continuar su trabajo.

Si la única cosa en común entre las tres situaciones es usted, entonces necesita considerar que algo que está haciendo es un problema.

¿Ha hablado con sus antiguos compañeros de trabajo y les ha pedido que le critiquen? No tu código, sino tu comportamiento en la oficina. La forma en que se comunica con sus compañeros de trabajo, la forma en que se comunica con su jefe, la forma en que hace la documentación, la forma en que se comporta en las reuniones, etc.

¿Se ha puesto en la posición de su supervisor? ¿Ha pensado realmente en lo que tienen que hacer, cuáles son sus responsabilidades, qué les hace sentir bien cuando apagan la luz de la oficina y se van a casa? Hay muchos, muchos ejemplos en los que alguien escribe un código increíble desde la perspectiva de otros ingenieros de software, pero la empresa fracasa.

Miré tu perfil, dice “tu código debería ser más limpio que tú mismo”. También de tus comentarios de que “pasaste mucho tiempo explicando conceptos”, y “criticar es parte de mi trabajo como ingeniero”… Pienso que te gusta dar consejos y que tus consejos simplemente no son apreciados por tus compañeros de equipo.

Esto puede ser debido a lo que dices, o a la forma en que lo dices, probablemente algo de ambas cosas.

Escribir un código productivo y mantenible no hará que te despidan. Serás despedido si no te puedes llevar bien con el equipo. Este es tu problema, no (como te lo imaginas) tu código es demasiado bueno. Su código puede ser muy bueno, pero es MUCHO más probable que se trate de un problema de choque de personalidades.

Mi consejo para usted, es que no sea la cola que trata de menear al perro. Mantén tu cabeza abajo, deja de decirle a la gente como codificar, sigue la dirección, trabaja bien con los demás, escribe un código mantenible. Y así no te despedirán.

También tomo nota con interés de este revelador comentario de tu jefe:

“¿Pero es realmente bueno como pretende?”

Lo que esto te dice es que tu jefe no confía en ti, tu jefe piensa que eres inauténtico y que eres arrogante y/o tienes una mayor consideración por tu propia capacidad de la que realmente tienes. Las relaciones dependen de la confianza para sobrevivir. Toma nota de que tu problema es no un problema técnico. Tu problema tiene muy poco que ver con la calidad de tu código. Lo que tienes es un problema con la forma en que te relacionas con tus colegas y tu gerente.

No se despide a menudo a la gente por ser indispensable (por qué se despide a la gente). Es una afirmación ridícula. El artículo al que se refiere califica claramente que “fuego” no significa necesariamente dejarlos ir, sino más bien hacerlos no indispensables (moviéndolos, forzándolos a no involucrarse en un proyecto en particular, etc.)

Mientras que el exceso de calificación a veces no hace que te contraten – también raramente hace que te despidan. Los buenos empleados son muy difíciles de encontrar; ninguna empresa razonable se va a deshacer de uno porque sea demasiado bueno (a menos que trabajes para un idiota - entonces te están haciendo un favor).

La gente SÍ es despedida porque PIENSAN que son indispensables y mejores que sus compañeros y por lo tanto se niegan a hacer los cambios que hay que hacer al hombre del espejo para funcionar bien en un equipo. despedido por mala actitud)

Si estás construyendo un puente con un grupo de nativos y sacas un portátil mientras el resto está atando la cuerda - puedes ser más inteligente o más educado pero te has convertido en un detrimento para el equipo y el problema eres TÚ.

Si eres realmente tan grande como te haces pasar, serías lo suficientemente inteligente para ajustar tus propias acciones para hacer el EQUIPO más productivo posible frente a empujar dogmáticamente tu propia agenda (lo cual probablemente estás haciendo). Si lo hicieras, probablemente tendrías un trabajo durante mucho tiempo.

Como alguien que está regularmente involucrado en el proceso de contratación, tomaré a alguien que es bueno y agradable por encima de alguien que es genial y un potencial cáncer cualquier día.

Cada programa es una comunicación con dos audiencias: un compilador o intérprete que lo hará ejecutar, y algunos humanos que lo han leído y entendido. Puede que se esté comunicando extremadamente bien con el compilador, y que siga escribiendo un código malo porque no puede ser fácilmente entendido por los otros humanos involucrados.

Típicamente, un equipo de programación tiene un conjunto de lenguajes, marcos, técnicas, etc. que son conocidos por todos en el equipo. Los nuevos contratados a los que les faltan algunas de esas piezas las absorben rápidamente porque cualquiera en el equipo puede explicarlas.

Usar algo fuera de ese conjunto tiene un costo para el empleador. Por ejemplo, suponga que usted es el único programador del grupo que está familiarizado con el marco X, y que todos los demás están familiarizados con un marco más antiguo, el Y, que se utiliza para algún código existente y que es casi tan bueno como el X.

Utilizar el marco X sería un error, a menos que sea mucho mejor que el Y que la dirección esté de acuerdo en que los beneficios técnicos de su uso son suficientes para justificar el esfuerzo de formación para que todos se familiaricen con el X.

Una técnica que podría utilizar es hacer que su código sea revisado por algunas de las personas menos experimentadas que necesitan poder leerlo. Vea lo que tienen que preguntar, y considere cómo podría reescribir esas piezas para que les quede más claro. Cuanto más trate la falta de comprensión de su código como un defecto en el código, no en los lectores, mejor será la retroalimentación que obtendrá.

Mi lectura en esto es que estabas destinado a este tratamiento desde el primer día en el trabajo. Dijiste que fuiste contratado porque tienes habilidades que nadie más en la organización tiene (TypeScript, Node). Y ahora que te has esforzado por producir una solución elegante, experta y compleja sola, nadie entiende lo que has hecho, y por lo tanto eres visto como un pasivo por la dirección.

Si todo esto es cierto, realmente no hay otra manera de que esto pudiera haber resultado.

En mi opinión, el problema es estructural, no personal, y por lo tanto la culpa recae en la situación y el proceso, no en la persona:

• La organización contrató a una sola persona con un conjunto de habilidades completamente diferentes a las de todos los demás, y a un nivel avanzado de esas habilidades, para realizar una función crítica. Esto garantiza que, _ si se desempeña bien_, será el único que entienda el código que es crítico para la misión de la organización. (Es completamente irrazonable esperar que un recurso de nivel superior produzca un código que instantáneamente tenga sentido para las personas que no conocen el lenguaje utilizado)
• La organización no lo sometió al proceso de revisión del código regularmente. Si lo hubieran hecho, tu código habría sido rechazado hasta que lo pusieras en conformidad con sus estándares de legibilidad. Dado que usted es el único contribuyente al código, con su propio estilo y utilizando una pila tecnológica diferente, está virtualmente garantizado que con el tiempo el código será cada vez menos comprensible para los demás. La única manera de prevenir esto sería pedir a otros que revisen el código fuera de proceso, constantemente, posiblemente lanzando acusaciones de estar desperdiciando el tiempo de los demás. La falta de un proceso de revisión de código, por lo tanto, te lleva al fracaso.

Tengo experiencias similares en mis antecedentes. Fui contratado una vez para llenar un vacío de habilidades. Nadie más en la compañía tenía una habilidad que necesitara repentinamente. Hice bien mi trabajo y después de unos meses comenzó el conflicto. Yo era el único que podía trabajar con ciertos componentes de la aplicación. Me convertí en un cuello de botella a medida que se acumulaba el trabajo que sólo yo podía hacer. Un día me dejaron de lado cuando la compañía decidió reemplazar todo lo que había producido con un código completamente nuevo, hecho a su manera. Mi orgullo fue herido en ese momento, pero en retrospectiva, fue la decisión correcta para la compañía. Después de un tiempo más, llegó el momento de seguir adelante, y lo hice.

Si esto te suena familiar, tal vez es hora de que sigas adelante. Tal vez la gerencia incluso te reasigne a otra cosa si continúan valorando tus habilidades. O si puedes soportarlo, tal vez puedas ayudar a reescribir todo lo que has hecho en la pila de tecnología estándar de la empresa. Si eso no es posible, vete. De cualquier manera, tu código probablemente está en camino al basurero. Eso es probablemente lo correcto para ellos, si nadie más lo entiende. Y de cualquier manera es la consecuencia natural de sus elecciones.

Asegúrate de que en tu próximo trabajo, otros en tu equipo estén aplicando básicamente las mismas habilidades que tú, y especialmente que tengan un proceso de revisión de código. Cuando te pidan que cambies tu código de cierta manera, hazlo. No consideres el código entregado hasta que haya pasado la revisión del código y tus compañeros le dirán a la gerencia (si se les pide), sí el código es bueno. Entonces no hay ningún problema. Está perfectamente bien hacer preguntas sobre cosas como esta en una entrevista técnica; lo he hecho muchas veces. Esperemos que este otro desarrollador que estudió tu código te dé una buena referencia.

Como nota al pie de página, si eres al menos parcialmente responsable de tus circunstancias de trabajar solo, sin la aprobación de otros miembros del equipo, entonces mereces al menos algo de la responsabilidad del resultado también. (¿Presionaste por el uso de TypeScript / Node cuando otros querían usar algo más? ¿Utilizaste la biblioteca o la técnica más nueva y genial aunque algo más básico hubiera funcionado bien? También he sido culpable de esto una o dos veces). Si es así, asegúrate de tomar una lección de este resultado. Pero si no, lleva esta experiencia a tu siguiente posición con la cabeza en alto.

La mayoría de las respuestas trataron su mensaje desde el punto de vista de si su código era legible o no o tan bueno como usted dice que es. Pero esta situación puede ocurrir y ocurre en todos los ámbitos de la vida. Acepté un trabajo en el Strip de Las Vegas como distribuidor y vendedor de pisos de 21. Mis técnicas y velocidad estaban tan adelantadas al resto de su personal que la gente asignada a vigilarme no podía mantener el ritmo. En otras palabras, no podían seguir mis decisiones. Dado que grandes cantidades de dinero estaban siendo transadas en minutos, a menudo se sentían confundidos y me reportaban a su superior diciendo que había cometido un error. Siempre reivindicaría mis acciones a esa persona pero la actitud de desconfianza hacia mí se profundizaba.

Mi ego y yo sospechamos que el suyo no vio las señales de advertencia y de hecho me deleité en mi superioridad, vertiéndola por así decirlo. Me despidieron y perdí un puesto muy bien pagado.

La lección es simple, debes bajar al nivel de los demás. Si sólo sacan 15 manos por hora y tú sacas 100, no estás inspirando elogios. Estás inspirando celos e incluso odio. Si tu orgullo no puede hacer esto, debes encontrar otra forma de ganarte la vida porque todos los lugares son esencialmente iguales. La gente es gente, no puedes cambiarla. Finalmente me instalé en otras líneas de trabajo donde yo también era mediocre y por lo tanto no me destacaba. Espero que puedas resolver esto a tu favor.

Decidí actualizar mi comentario con una respuesta:

Documenta tu código muy bien.

La documentación adecuada del código convierte las malas experiencias en las que un dev dev devoto junior golpea su cabeza contra una pared incomprensible durante horas en potenciales experiencias de aprendizaje.

Es posible que simplemente no seas tan bueno como crees que eres, pero en aras de la civilidad, asumiré que sabes cómo escribir la cantidad correcta de código complejo para reducir la complejidad y los requisitos de tiempo de toda la base de código en un orden de magnitud. El hecho de que esto sea posible toma a muchos idiotas por sorpresa. Lo encuentran una proposición incrédula, y la única manera de convencerlos es mostrándoles.

Pero eso requiere delicadeza, coraje y autocontrol. Hay que concentrarse en tres cosas antes que en las demás: demostrar que no eres una amenaza, hacer que los idiotas parezcan inteligentes y no dejar que un solo idiota se dé cuenta de que sabes que es un idiota. Si no puedes hacer estas tres cosas, fallarás, y será tu culpa. El pragmatismo es una necesidad, y no hay lugar para el orgullo.

Aunque no puedo recomendar este enfoque para todos, lo que siempre me ha funcionado es ignorar a veces lo que los idiotas hostiles me dicen que haga. En su lugar, encuentro maneras de hacer lo que quiero, producir el mejor software para el que muchos de ellos han visto el código en muy poco tiempo, y lo presento de tal manera que sus jefes los recompensan con brillantes elogios. A pesar de que no han tenido nada que ver en su creación. Incluso cuando se opusieron activamente a él.

¿Es correcto? ¿No debería recibir todo el crédito por mi trabajo? ¿Debería realmente tener que bailar alrededor de los sentimientos de todos? Irrelevante. Esta es la realidad. Si no me adapto a ella, entonces yo soy el idiota.

Hay mucha gente inteligente que piensa que los desarrolladores altamente calificados son irremplazables y por eso los quieren. Pero has visto las otras respuestas a tu pregunta - la mayoría de los gerentes no quieren lidiar con los problemas de un equipo con niveles de habilidad muy variados, y no tienen la opción de ir puramente de alta habilidad. Tampoco están necesariamente equivocados, los problemas son reales, y los beneficios de un código de alta calidad que está más allá de las habilidades de la mayoría de las personas que pueden contratar se reducen en gran medida.

Si eres tan bueno como dices que eres, entonces no encajas en tu trabajo. Suena como si debiera esforzarse por trabajar en un lugar donde pueda aprender de sus compañeros de trabajo y éstos puedan entender su código.

Si ha perdido algunos trabajos debido a esto, entonces va a quedar bastante mal ante RRHH, reclutadores y gerentes. Con suerte, podrás conectarte a un trabajo conociendo a desarrolladores con un nivel de habilidad similar que puedan dar fe de que el problema realmente es que tu nivel de habilidad es demasiado alto.

Por último, tengo que añadir que deberías hacer todo lo posible para evaluar honestamente si tu nivel de habilidad es realmente tan alto. Suena como si hubiera evidencia de que lo es, pero la mayoría de la gente cree que son mejores de lo que son. También muchos desarrolladores pasan por una etapa en la que se vuelven muy buenos en un enfoque, pero no siempre ponen todo junto en una solución global óptima, y aún así les falta flexibilidad. Por ejemplo, a veces puede ser mejor ir con una solución inferior que sabes que las personas que tienes pueden mantener, si sabes que no pueden mantener una más sofisticada, y no es probable que contraten a nadie más que pueda hacerlo.

Para abordar la pregunta específicamente,

¿Cómo puedo evitar esto en el futuro?

• Encuentra un capítulo local de Toastmasters, participa activamente, y gana los logros. Algo que parece tan obvio como la retroalimentación, esperamos que sea apreciado y afilado como una de sus habilidades más valoradas.

• Practica siendo el estudiante en vez del experto. ¿Has visto esta charla de Jon Skeet sobre lo básico ? ¿Puedes imaginarte cuánto más entendimiento se puede lograr si todos nosotros hacemos una documentación como esta, beneficiaría a todos, en todos los niveles de un equipo!

• Un equipo no es un individuo. Su equipo crecerá y mejorará colectivamente. Tienes que ayudar. No es un equipo si cada miembro es una célula que va en diferentes direcciones (por ejemplo, tú más alto, y el miembro más nuevo estancado). Las reuniones de 2 horas son un buen comienzo. Yo añadiría, además, la rotación de parejas de N días. Esto es 1:1, cuando tú regalas a tus compañeros de equipo Y ellos regalan a ti. En tu caso, inclínate hacia el rol de navegante, y deja que tu compañero maneje. Practiquen no escribir el código, por extraño que suene.

• Voluntario en un Meetup and Hack-a-thons local. Puede obligarte a destilar tu código porque el propósito es colaborar, y no construir una red de energía tolerante a las fallas, ¿cierto?

• En cada uno de estos ejercicios, prueba este concepto: liderazgo sirviendo. ¿Cómo puedes hacer una tarea o lograr algo para ayudar a las necesidades de otro miembro del equipo?

• Como se ha señalado, contribuye a los proyectos de código abierto para obtener más ángulos sobre tu código. Pueden confirmar que eres brillante, pero también pueden reforzar las sugerencias que estás escuchando de tu jefe actual. En el mejor de los casos, alguna revisión te dará una nueva idea.

• Encuentra un ingeniero que sea mejor que tú. No es mejorarte a ti mismo ser el más inteligente de la sala. Hay una cita (mi búsqueda en Google se divide entre Olgivy/Ford/Sorkin) que dice: “No puedes aprender más si te rodeas de malos talentos”.

Asumiré que su descripción de la situación es como usted dice. No puedo decir que haya tenido esta experiencia exacta pero hay aspectos de esto que me son familiares.

Usted dice que esta es una “gran” compañía. No sé cómo es en Francia, pero a menudo las grandes empresas no valoran las habilidades de los desarrolladores internos, especialmente si no son empresas centradas en la tecnología. Atribuyo esto principalmente al hecho de que los gerentes de estas empresas a menudo no tienen formación técnica o se alejan del desarrollo porque nunca fueron tan buenos en ello.

También hay un aspecto histórico de los vendedores que venden herramientas que se supone que eliminan la necesidad de desarrolladores con talento. Incluso si su equipo no está usando una de estas cosas horribles, hay una posibilidad de que la dirección de la empresa haya sido adoctrinada en una noción anti-intelectual de los equipos de desarrollo. De hecho, he tenido un gerente que me dijo a la cara que yo era lo suficientemente inteligente como para construir una solución determinada, pero que nadie más sería capaz de mantenerla, por lo que necesitábamos comprar algo (shelfware.) Así que creo que esto puede suceder.

Puede que tengas que buscar un tipo de empresa diferente. Una que valore a los desarrolladores altamente cualificados. Sin embargo, es posible que tengas que lidiar con el hecho de no ser el mejor desarrollador allí. Si fueras un aspirante a chef, probablemente no estarías feliz trabajando en McDonald’s. No necesitan chefs. Necesitan que la gente siga una receta. Usted puede ser material de chef y esta empresa (y otras similares) es McDonald’s. La pregunta que debe hacerse es por qué no lo ha hecho todavía.

¿Cómo puedo evitar esto en el futuro?

No trabajes con nadie a menos que estés razonablemente seguro de que su estándar de codificación coincide con el tuyo. Lo que significa rechazar cualquier trabajo si nadie de los siguientes aplica:

• Te hacen preguntas de programación durante su proceso de entrevista
• Tienen ejercicios de programación de pares
• Piden una muestra de código y están de acuerdo con ella
• Puedes ver algo del código que han producido

¿Cómo puedo evitar esto en el presente?

Esto ha sido cubierto por otras respuestas.

Si eres así de mejor, llega a su nivel y lentamente enséñales a ser mejores programadores. La primera vez que tuve que dirigir a un interno casi borré todo el código que produjo. Estaba literalmente furioso cuando vi lo que se ha cometido (afortunadamente no tuve ningún testigo :P )_.

Hay que fomentar la programación por pares, las revisiones de código. Siéntese con otro programador e intente programar juntos durante 2 o 3 horas. Dejar caer conceptos que pueden ser demasiado difíciles de explicar (nuevas características avanzadas de Java 8 por ejemplo), y explicar los que son más fáciles (herencia).

A veces, cuando se habla con otros, hay que “tontear” para no ofender a la gente. Especialmente si estás muy por encima de los demás con los que trabajas, es probable que se ofendan cuando hablas de consejos y hechos que probablemente deberían saber, pero no lo hicieron.

Diría que comentes tu trabajo muy bien, para que la gente que lo compruebe pueda entenderlo. Incluso podrías necesitar “justificar” por qué eliges ese método de codificación en lugar de otro diferente dentro de tus comentarios. Puede que seas el mejor codificador, pero si estás dentro de un equipo, tienes que trabajar como un equipo.

Si trabajar como un equipo significa trabajar con una mano a la espalda, (con esto me refiero a seguir su preferencia de codificación), entonces hazlo. Al menos así podrán leerlo, entenderlo, y el equipo en sí mismo estará mejor (aunque eso signifique que estés gritando por dentro).

Casi en cualquier lugar que vayas donde seas parte de un equipo tendrás pautas sobre cómo quieren que se codifiquen las cosas, y tienes que seguir estas pautas.

No podemos depender de él a largo plazo

Ese es el mayor problema. No quieren depender de ti, pero te contrataron porque en realidad dependen de ti.

Puedes tranquilizar a la dirección con:

• De todas formas no estás pensando en ir a otro sitio, así que pueden contar contigo a largo plazo.

Creo que tengo problemas para mantener mi habilidad en uso, así que creo que por fin encuentro un lugar de trabajo que puedo disfrutar durante mucho tiempo

• Estás dispuesto a proporcionar entrenamiento a otros miembros del equipo para proporcionar más valor al equipo.

He notado que el código de otros no está realmente actualizado con las técnicas de desarrollo de software de vanguardia, no es un problema, puedo dejar de usar esas técnicas por completo, sin embargo sería beneficioso que todos comenzaran a usar esas técnicas gradualmente para mejorar el rendimiento del equipo. Puedo ayudar con eso.

• Se le pidió que implementara las características XY, ya que las características enviadas dentro del tiempo requerían su habilidad, las cosas podrían haberse hecho de diferentes maneras pero en mucho más tiempo y con el riesgo de errores adicionales.

¿Puedo tener algo de tiempo extra para terminar las siguientes características? Realmente trabajé duro para hacer las cosas bien, logré hacerlo pero me temo que no todo el mundo puede entenderlo, en su lugar quiero tomarme un tiempo para hacer las cosas comprensibles para los demás.

Sé honesto, si alguna afirmación no se aplica (no lo hago ahora en lo que trabajaste), no mientas, nunca.

Si te van a despedir, entonces no dependen realmente de ti de verdad. De todos modos, al menos dos personas del equipo entienden tu trabajo: Tú y tu compañero de trabajo. Y es probable que más gente pueda entenderlo en el futuro. Básicamente, no eres un cuello de botella en tu equipo, sin embargo, temen que puedas llegar a serlo más adelante. De todas formas, deberían invertir algo de tiempo en el entrenamiento.

Lee * El Vagón, el Mirlo y el Saab **. Debería resonar con usted._

He tenido problemas similares en el pasado; he aprendido algunas cosas sobre cómo hacer frente, pero ambos hemos estado usando un trapeador y un cubo para tratar de limpiar la salida de una manguera de incendios.

No estoy aquí sugiriendo que merezca un diagnóstico de salud mental DSM-V, pero sí sugiero que podría estar bien aconsejado para encontrar un buen consejero y trabajar en el comportamiento no amenazante y las habilidades sociales. También podría leer * Teoría de las mentes alienígenas **.