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

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

Para algunos antecedentes, he estado en situaciones similares de "demasiado bueno codificando para mi trabajo" antes, aunque nunca en el grado que usted describe. Podría curar el cáncer con la metaprogramación de plantillas en C++, pero muchas de las personas con las que trabajo apenas conocen los conceptos básicos 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 trabajé todavía usaban versiones anticuadas y con errores de gcc. Mi enfoque fue simplemente mostrarles cuán asombrosas son estas herramientas y todos los problemas que podrían resolver. Me encantaba explicar pequeños consejos de programación a la gente, y ellos lo disfrutaban en gran medida.

¿Te suena familiar?

"Sí, pero uno debe tener un buen nivel para entender [el código de Mik] porque los componentes se desacoplan de forma inteligente".

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

Es posible que haya producido lo que llamaría "buen código", pero la definición de "buen código" depende en gran medida del contexto . Lo que es un "buen código" en Google, con sus formas de pensar innovadoras, puede ser un código muy malo para alguien que trabaja en la FAA, a quien le preocupa principalmente la confiabilidad en lugar de mantenerse al día. La definición de "buen código" de su jefe incluye la capacidad de mantenerlo en todo tipo de situaciones, incluso sin usted. Si sus compañeros de trabajo no se sienten cómodos manteniendo su código, de repente usted es una responsabilidad para la empresa, porque produce un producto que ellos no pueden mantener si decide irse a otra parte.

Desde esta perspectiva, uno puede argumentar que los está obligando a aceptar su definición de "buen código". Instintivamente, esto puede parecer algo bueno, pero está plagado de dificultades, como esta forma de pensar basada en el riesgo en la que quizás no hayas estado pensando.

Tenemos una frase, "poner el carro delante del caballo". Uno de los muchos significados asociados con esto es poner el contenido que más le importa (ser capaz de usar sus técnicas avanzadas) sobre las fuerzas que deberían impulsarlo (la comprensión de estas técnicas por parte de su compañero de trabajo). Usted escribió el código en este estilo avanzado y luego alentó a los otros desarrolladores a "ponerse al día" con este estilo. Esto puede ser eficaz, pero si le sucede algo antes de que "se pongan al día", la empresa se encuentra repentinamente en riesgo porque nadie puede mantener el código.

¿Cómo puedo evitar esto en el futuro?

Arreglar esto puede ser algo terriblemente difícil de hacer 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 sus compañeros de trabajo cómo pensar de esa manera, debe darle la vuelta. Enseñe a sus compañeros de trabajo a que les guste ese estilo de codificación y luego comience 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 quieres desarrollar es repentinamente menos arriesgado.

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

Por supuesto, puede ser difícil saber cuándo es seguro escribir código en el estilo que desea escribir. Si fuera fácil saberlo, ¡seguramente ya lo habría descubierto! Una técnica poderosa que puede usar es dejar que otros presionen los estilos de codificación avanzados, en lugar de presionarlos usted mismo. Una cosa es enseñarle a alguien la diferencia entre herencia y composición. Es algo completamente diferente enseñarles lo suficientemente bien como para que aboguen por cambiar su base de código existente para que sea más claro cuando los usa. El último caso realmente te permite saber que no solo entienden el concepto, sino que realmente lo aceptan.

Un ideal para enseñar tales conceptos es no enseñar nada. Deje que los estudiantes descubran algo y luego indíqueles la dirección en la que puede ir el descubrimiento. Tal vez uno de ellos descubra algo bueno sobre la herencia y usted pueda indicarle el patrón de diseño Visitor en función de lo que descubrió. No les des solo Visitor, sino dales un sentido de dirección para que puedan salir y encontrar a Visitor por sí mismos.

Es un enfoque mucho más difícil, y seguramente querrá encontrar un término medio entre eso y su enfoque actual, pero puede ser muy gratificante. Más importante para su respuesta, puede proporcionar valor a la empresa sin el riesgo. Si proporciona valor a una empresa y no la pone en riesgo, prácticamente nunca lo despedirán. Y en los pocos casos en los que aún puede ser despedido, la gerencia le proporcionará una razón (como una recesión en la economía o un cambio en la dirección de la empresa). Si lo hace muy bien, descubrirá que la gerencia comenzará a dar forma a su camino, tal como usted da forma a sus compañeros de trabajo, y encontrará una curiosa tendencia a que usted haya aprendido la habilidad adecuada justo cuando más la necesitan . .

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 te despidieron por ser "indispensable" pero además de ser un oxímoron, tampoco es lo que pasó. Lo despidieron por escribir código que sus colegas no pueden entender, lo cual es un problema crítico de rendimiento para un programador.

Un buen código es un código legible , es decir, un código fácilmente comprensible, incluso para los novatos . Las situaciones en las que necesita un código escrito complejo y estricto que debe ser escrito y mantenido por verdaderos expertos son muy raras en estos días y, evidentemente, no estaba trabajando para ese tipo de empresas. Lo que describe suena más como un código "elegante" que suele ser demasiado complejo, está lleno de trucos de programación esotéricos y lleva mucho tiempo descubrirlo y depurarlo. Es una falla común para las personas que recibieron una formación clásica y, por lo general, se encuentran con un duro despertar una vez que ingresan a un entorno productivo.

Siempre hay razones.

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

¿Por qué esto tiene sentido?

1. Él era el único que podía mantener su código.
2. no era colaborativo
3. No siguió los estándares de la tienda.
4. Si bien estaba entregando más de lo necesario, esto no era algo bueno.
5. 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 solo una parte de la ecuación. Debe ser afable, comunicativo, humilde hasta cierto punto, arrogante cuando sea necesario, cumplir con los estándares comerciales, llevarse bien con sus compañeros de trabajo, ser accesible y rápido para ayudar cuando sea necesario.

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

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

Y es verdad. La programación demasiado inteligente es mala, porque el mantenimiento es más largo cuando no conoce el código . En el mantenimiento, a menudo hay fuego en 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 código tonto tipo script lleno de repeticiones.

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

Hay que tener en cuenta el contexto. Si trabaja en una pequeña empresa de vanguardia que contrata solo a los mejores, probablemente pueda permitirse algunas cosas exóticas y brillantes. Si trabaja para un banco francés que depende solo de consultores de, errrm, calidad aleatoria (a veces tienen suerte, a veces no), y donde cada consultor tiene un dominio de millones de LOC para mantener, entonces, por supuesto, hágalo lo suficientemente simple. para que un mediocre lo entienda a primera vista. Sin punteros, sin herencia múltiple, sin trucos inteligentes, etc...

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

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

Si realmente eres tan bueno, puedes hacerte indispensable en el buen sentido:

• Mentor a los programadores junior. Dígales los beneficios y los inconvenientes de los diferentes enfoques y déjelos cometer sus errores en lugar de decirles qué enfoque tomar.
• Escriba un buen código que sea fácil de mantener por otras personas.
• Abogue por las mejores prácticas de manera que aumenten la productividad, a diferencia de las mejores prácticas de culto de carga , que suenan bien en el papel pero matan la productividad.

Despedir a personas indispensables es en realidad una buena estrategia de gestión. 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 habilidades, esto crea una gran responsabilidad: ¿qué pasa si esa persona es atropellada por un autobús y muere (de ahí el término 'autobús')? factor') o simplemente decide dejar la empresa para enfrentarse a un nuevo reto? ¡ Ahora su empresa está atrapada en una situación terrible porque nadie puede reemplazar de inmediato al empleado indispensable y no tenía control sobre el tiempo!

Para prevenir esta situación, la empresa tiene dos opciones. O pueden intentar difundir el conocimiento y/o aumentar la capacidad de los compañeros de trabajo de la persona indispensable, o pueden quitar la curita de una sola vez despidiendo a la persona indispensable en el momento que elijan 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 en el conocimiento y especialmente en la habilidad, despedirlos puede ser la opción más lógica.

Como empleado, siempre debe intentar evitar volverse indispensable. Comparte tus conocimientos con tus compañeros y asegúrate de que haya personas que puedan hacer tu trabajo cuando tú no estés. Asegúrese de que sus prácticas se adecuen a los trabajadores con el nivel de habilidad promedio en su empresa. Si cree que el nivel promedio es demasiado bajo, trabaje con la administració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 usarla para continuar con su trabajo.

Si lo único en común entre las tres situaciones eres tú, entonces debes considerar que algo que estás haciendo es un problema.

¿Has hablado con tus antiguos compañeros de trabajo y les has pedido que te critiquen? No tu código, sino tu comportamiento en la oficina. La forma en que te comunicas con tus compañeros de trabajo, la forma en que te comunicas con tu jefe, la forma en que haces la documentación, cómo te comportas en las reuniones, etc.

¿Se ha puesto en el lugar de su supervisor? ¿Realmente pensaron en lo que tienen que hacer, cuáles son sus responsabilidades, qué los 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ú". También de tus comentarios de que "pasaste mucho tiempo explicando conceptos" y "criticar es parte de mi trabajo como ingeniero"... Estoy pensando que te gusta dar consejos y tus consejos simplemente no son apreciados por tu compañeros de equipo

Esto puede deberse a lo que está diciendo o a la forma en que lo está diciendo, probablemente por ambas cosas.

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

Mi consejo para ti es que no seas la cola que trata de mover al perro. Mantenga la cabeza baja, deje de decirle a la gente cómo codificar , siga las instrucciones, trabaje bien con los demás, escriba código mantenible. Y así no te despedirán.

También tomo nota con interés de este revelador comentario de su gerente:

"¿Pero es realmente bueno como él finge?"

Lo que esto le está diciendo es que su gerente no confía en usted , su gerente piensa que no es auténtico y piensa que es arrogante y/o tiene una mayor consideración por su propia capacidad de lo que realmente tiene. Las relaciones dependen de la confianza para sobrevivir. Tome nota aquí que su problema no es un problema técnico. Su problema tiene muy poco que ver con la calidad de su código. Lo que tienes es un problema con la forma en que te relacionas con tus compañeros y tu jefe.

La gente no suele ser despedida por ser indispensable ( por qué la gente es despedida ); Esa es una afirmación ridícula. El artículo al que hace referencia claramente califica que "fuego" no significa necesariamente dejarlos ir, sino hacerlos no indispensables (moviéndolos, obligándolos a no involucrarse en un proyecto en particular, etc.)

Si bien la sobrecalificación a veces no hará que lo contraten, rara vez lo despedirán. Los buenos empleados son muy difíciles de encontrar; Ninguna compañía razonable se va a deshacer de uno porque es demasiado bueno (a menos que solo trabajes para un imbécil, entonces te están haciendo un favor).

Las personas SÍ son despedidas porque PIENSAN que son indispensables y mejores que sus compañeros y, por lo tanto, se niegan a hacer los cambios que deben hacerse en el hombre en el espejo para que funcione bien en un equipo. ( despedido por mala actitud )

Si está construyendo un puente con un grupo de nativos y saca una computadora portátil mientras el resto ata la cuerda, puede ser más inteligente o más educado, pero se ha convertido en un detrimento para el equipo y el problema es USTED.

Si realmente eres tan bueno como te haces ver, serías lo suficientemente inteligente como para ajustar tus propias acciones para hacer posible el EQUIPO más productivo en lugar de impulsar dogmáticamente tu propia agenda (lo que probablemente estés haciendo). Si estuvieras haciendo eso, probablemente tendrías un trabajo por mucho tiempo.

Como alguien que participa regularmente en el proceso de contratación, prefiero a alguien que sea bueno y agradable antes que a alguien que sea excelente y que sea un posible cáncer en cualquier momento.

Todo programa es una comunicación con dos audiencias: un compilador o intérprete que lo hará ejecutar, y unos humanos que lo han leído y entendido. Es posible que te estés comunicando muy bien con el compilador y aún estés escribiendo un código incorrecto porque los otros humanos involucrados no pueden entenderlo fácilmente.

Por lo general, un equipo de programación tiene un conjunto de lenguajes, marcos, técnicas, etc. que todos en el equipo conocen. Los nuevos empleados a los que les faltan algunas de esas piezas las absorben rápidamente porque cualquiera en el equipo puede explicárselas.

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

Usar el marco X sería un error, a menos que sea mucho mejor que Y que la gerencia esté de acuerdo en que las ganancias técnicas de usarlo son suficientes para justificar el esfuerzo de capacitación para que todos se familiaricen con X.

Una técnica que podría usar 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 sean más claras para ellos. Cuanto más trate la falta de comprensión de su código como un defecto en el código, no en los lectores, mejores serán los comentarios que obtendrá.

Decidí actualizar mi comentario a una respuesta:

Documenta muy bien tu código.

La documentación adecuada del código convierte las malas experiencias en las que un desarrollador junior se golpea la cabeza contra una pared incomprensible durante horas en posibles experiencias de aprendizaje.

La mayoría de las respuestas trataron su publicación desde el punto de vista de si su código era legible o no, o si era tan bueno como dice que es. Pero esta situación puede suceder y sucede en todos los ámbitos de la vida. Acepté un trabajo en Las Vegas Strip como distribuidor de 21 y empleado de piso. Mis técnicas y velocidad estaban tan por delante del resto de su personal que las personas asignadas para vigilarme no podían seguir el ritmo. En otras palabras, no podían seguir mis decisiones. Como se estaban transaccionando grandes cantidades de dinero en cuestión de minutos, a menudo se sentían confundidos y me informaban a su superior alegando que había cometido un error. Siempre reivindicaría mis acciones ante esa persona pero la actitud de desconfianza hacia mí se profundizó.

Mi ego y sospecho que el tuyo no vieron las señales de advertencia y, de hecho, me deleité con mi superioridad, derramándola, por así decirlo. Me despidieron y perdí un puesto muy bien remunerado.

La lección es simple, debes bajar al nivel de los demás. Si solo reparten 15 manos por hora y tú repartes 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. Las personas son personas, no puedes cambiarlas. Eventualmente me adapté a otras líneas de trabajo en las que también era mediocre y, por lo tanto, no me destacaba. Espero que puedas solucionar esto a tu favor.

Mi lectura sobre esto es que estaba destinado a este tratamiento desde el primer día en el trabajo. Dijiste que te contrataron porque tienes habilidades que nadie más en la organización tiene (TypeScript, Node). Y ahora que se ha esforzado para producir una solución compleja, elegante y elaborada por expertos , nadie entiende lo que ha hecho y, por lo tanto, la gerencia lo ve como una responsabilidad .

Si todo esto es cierto, realmente no hay otra forma en que esto podría haber resultado.

A mi modo de ver, el problema es estructural, no personal, y por tanto la culpa es de la situación y del proceso, no de la persona:

• La organización contrató a una sola persona con un conjunto de habilidades completamente diferente al de los demás, y en 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 comprende el código que es fundamental para la misión de la organización. (Es completamente irrazonable esperar que un recurso de alto nivel produzca un código que instantáneamente tenga sentido para las personas que no conocen el idioma utilizado).
• La organización no lo sometió regularmente al proceso de revisión del código. Si lo hubieran hecho, su código habría sido rechazado hasta que cumpliera con sus estándares de legibilidad. Dado que usted es el único colaborador del código, con su propio estilo y utilizando una pila de tecnología diferente, está prácticamente garantizado que, con el tiempo, el código será cada vez menos comprensible para los demás. La única forma de evitar esto sería pedir a otros que revisen el código fuera del proceso, constantemente, posiblemente generando acusaciones de hacer perder el tiempo a los demás. La falta de un proceso de revisión de código lo prepara para el fracaso.

Tengo experiencias similares en mi fondo. Me contrataron una vez para llenar un vacío de habilidades. Nadie más en la empresa tenía una habilidad que de repente necesitaban. 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 solo yo podía hacer. Un día me dejaron de lado porque 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 empresa. Después de un tiempo más, llegó el momento de seguir adelante, y lo hice.

Si esto te suena familiar, tal vez sea hora de que sigas adelante. Tal vez la gerencia incluso lo reasignará a otra cosa si continúan valorando sus habilidades. O si puede soportarlo, tal vez pueda ayudar a reescribir todo lo que ha hecho en la pila de tecnología estándar corporativa. Si eso no es posible, solo vete. De cualquier manera, su código probablemente esté en camino a la basura. Eso es probablemente lo correcto para ellos, si nadie más lo entiende. Y de todos modos es la consecuencia natural de sus elecciones.

Asegúrese de que en su próximo trabajo, otros en su equipo estén aplicando básicamente las mismas habilidades que usted, 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 considere el código entregado hasta que haya pasado la revisión del código y sus compañeros le dirán a la gerencia (si se les pregunta), sí, el código es bueno. Entonces no hay problema. Está perfectamente bien hacer preguntas sobre cosas como esta en una entrevista técnica; Lo he hecho muchas veces. Con suerte, este otro desarrollador que estudió su código le dará una buena referencia.

Como nota al pie, si usted es al menos parcialmente responsable de sus circunstancias de trabajar solo, sin la aceptación de otros miembros del equipo, entonces también merece al menos parte de la responsabilidad por el resultado. (¿Presionó por usar TypeScript/Node cuando otros querían usar otra cosa? ¿Usó la biblioteca o 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úrese de sacar una lección de este resultado. Pero si no, lleva esta experiencia a tu siguiente puesto con la frente en alto.

Es posible que simplemente no sea tan bueno como cree que es, pero por civismo, asumiré que sabe cómo escribir la cantidad correcta de código complejo para reducir la complejidad y los requisitos de tiempo de todo el código base en un orden de magnitud. El hecho de que esto sea posible toma a muchos idiotas por sorpresa. Les resulta una proposición incrédula, y la única manera de convencerlos es mostrándoselos.

Pero eso requiere delicadeza, coraje y autocontrol. Debes concentrarte en tres cosas antes que en las demás: demostrar que no eres una amenaza, hacer que los idiotas parezcan inteligentes y nunca dejar que un solo idiota se dé cuenta de que sabes que es un idiota. Si no puede decidirse a hacer estas tres cosas, fracasará y será su culpa. El pragmatismo es imprescindible 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 formas de hacer lo que quiero hacer, 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 recompensen con elogios entusiastas. A pesar de que no jugaron ningún papel en su creación. Incluso cuando se opusieron activamente.

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

Hay mucha gente inteligente que piensa que los desarrolladores altamente calificados son insustituibles y es por eso que los quieres . Pero ha visto las otras respuestas a su 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 volverse puramente de alta habilidad. Tampoco están necesariamente equivocados, los problemas son reales y los beneficios del 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 considerablemente.

Si eres tan bueno como dices que eres, entonces no encajas con tu trabajo. Parece que debería esforzarse por trabajar en un lugar donde pueda aprender de sus compañeros de trabajo y sus compañeros de trabajo puedan entender su código.

Si ha perdido algunos trabajos debido a esto, se verá bastante mal ante RRHH, reclutadores y gerentes. Con suerte, puede establecer contactos en un trabajo reuniéndose con desarrolladores de un nivel de habilidad similar que puedan garantizar que el problema realmente es que su nivel de habilidad es demasiado alto.

Finalmente, debo agregar que debe hacer todo lo posible para evaluar honestamente si su nivel de habilidad es realmente tan alto. Parece que hay evidencia de que lo es, pero la mayoría de las personas creen que son mejores de lo que son. Además, muchos desarrolladores pasan por una etapa en la que se vuelven muy buenos en un enfoque, pero aún no siempre ponen todo junto en una solución globalmente óptima, y ​​todavía les falta flexibilidad. Por ejemplo, a veces puede ser mejor ir con una solución inferior que sabe que la gente que tiene puede mantener, si sabe que no pueden mantener una más sofisticada, y no es probable que contraten a nadie más que pueda.

Para abordar la pregunta específicamente,

¿Cómo puedo evitar esto en el futuro?

• Encuentre un capítulo local de Toastmasters, participe activamente y obtenga los logros. Algo que parece tan obvio como la retroalimentación, con suerte será apreciado y perfeccionado en una de sus habilidades más valiosas.

• Practique ser el estudiante en lugar del experto. ¿Has visto esta charla de Jon Skeet sobre los conceptos básicos ? ¿Puedes imaginar cuánto más comprensión se puede lograr si todos nosotros hiciéramos 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, usted sube y el miembro más nuevo se estanca). Reuniones de 2 horas es un buen comienzo. Agregaría además de eso, la rotación de emparejamiento de N días. Esta es 1:1 vez que le regalas a tus compañeros de equipo Y ellos te lo regalan a ti. En su caso, inclínese hacia el rol de navegante y deje que su pareja maneje. Practique no escribir el código, por extraño que suene.

• Ofrécete como voluntario en un Meetup local y Hack-a-thons. Puede obligarlo a destilar su código porque el propósito es colaborar y no construir una red de servicios públicos de energía tolerante a fallas, ¿verdad?

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

• Como se señaló, contribuya a proyectos de código abierto para obtener más ángulos sobre su 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 le dará una nueva idea.

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

TL; DR: encuentre un lugar de trabajo más apropiado y sea honesto acerca de las habilidades que aún tiene que aprender.

Me suenas como el estilo de desarrollador de "artesanía de software": interesado en las mejores prácticas, y siempre encontrando y siguiendo buenas formas de hacer las cosas en el código. Tal vez sería más feliz en un entorno donde otros desarrolladores están más interesados ​​en ese tipo de cosas, y hay muchos lugares de trabajo de este tipo.

Sin embargo, algunas de las cosas que ha dicho dan la impresión de que a veces piensa que hay una única "mejor manera" de hacer las cosas en el código que siempre debe seguirse. Tal vez me equivoque en eso, pero si no me equivoco, entonces posiblemente tenga algo que aprender cuando se trata de explorar los pros y los contras de opciones alternativas y encontrar la forma que represente el mejor equilibrio para el negocio. De hecho, diré que definitivamente necesitas mejorar allí, ¡porque todos lo hacemos!

Voy a asumir que tu descripción de la situación es como dices. No puedo decir que haya tenido esta experiencia exacta, pero hay aspectos de esto que me son familiares.

Usted dice que esta es una empresa 'grande'. No sé cómo es en Francia, pero a menudo las empresas más grandes 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 tales empresas a menudo no tienen antecedentes técnicos o se alejaron del desarrollo porque nunca fueron tan buenos en eso.

También hay un aspecto histórico de proveedores que venden herramientas que se supone que eliminan la necesidad de desarrolladores talentosos. Incluso si su equipo no está usando una de estas cosas horribles, existe la posibilidad de que la gerencia de la empresa haya sido adoctrinada en una noción antiintelectual de los equipos de desarrollo. De hecho, un gerente me dijo en mi cara que era lo suficientemente inteligente como para crear una solución determinada, pero nadie más podría mantenerla, por lo que necesitábamos comprar algo (vajilla). Así que creo que esto puede suceder. .

Es posible que deba buscar otro tipo de empresa. Uno que valora a los desarrolladores altamente calificados. Sin embargo, es posible que tenga que lidiar con no ser el mejor desarrollador allí. Si fueras un aspirante a chef, probablemente no estarías feliz trabajando en McDonald's. No necesitan cocineros. 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 ya.

Algunas veces, cuando hablas con otros, tienes que "hacer el tonto" para no ofender a la gente. Especialmente si está muy por encima de los demás con los que trabaja, es probable que se ofendan cuando habla sobre consejos y hechos que probablemente deberían saber, pero no lo hicieron.

Diría que comentes muy bien tu trabajo, para que la gente que lo revise pueda entenderlo. Es posible que incluso deba "justificar" por qué elige ese método de codificación en lugar de uno diferente dentro de sus comentarios. Puede que seas el mejor programador, pero si estás dentro de un equipo, tienes que trabajar en equipo.

Si trabajar en equipo significa trabajar con una mano detrás de la espalda (con esto me refiero a seguir su preferencia de codificación), entonces hágalo. Al menos entonces pueden leerlo, entenderlo y el equipo mismo está mejor (incluso si eso significa que estás gritando por dentro).

Casi cualquier lugar al que vaya donde sea parte de un equipo tendrá pautas sobre cómo quieren que se codifiquen las cosas, y debe seguir estas pautas.

¿Cómo puedo evitar esto en el futuro?

No trabaje con nadie a menos que esté razonablemente seguro de que su estándar de codificación coincide con el suyo. Lo que significa rechazar cualquier trabajo si no se aplica ninguno de los siguientes:

• Te hacen preguntas de programación durante su proceso de entrevista.
• Tienen ejercicios de programación entre pares.
• Piden una muestra de código y están de acuerdo con eso.
• Puedes ver parte 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, ponte a su nivel y enséñales poco a poco a ser mejores programadores. La primera vez que tuve que administrar a un interno, casi borré todo el código que produjo. Estaba literalmente furioso cuando vi lo que se había cometido (afortunadamente no tuve testigos: P) .

Debe alentar la programación entre pares, las revisiones de código. Siéntese con otro programador e intente codificar juntos durante 2 o 3 horas. Elimine los conceptos que pueden ser demasiado difíciles de explicar (nuevas funciones avanzadas de Java 8, por ejemplo) y explique los que son más fáciles (herencia).

Suenas como si fueras un programador lo suficientemente bueno como para poder adaptarte a muchas situaciones. Mire cómo codifican los demás y actúe en consecuencia. De vez en cuando, pregunte si puede probar diferentes formas y asegúrese de que no esté demasiado lejos de lo que todos los demás pueden comprender.

Normalmente no daría este consejo, pero este problema parece seguirte dondequiera que vayas, así que deja de luchar hasta que puedas encontrar un trabajo en el que no sea un problema. Puede considerar involucrarse en un proyecto en el que hay una pequeña cantidad de otros desarrolladores a los que podría ayudar a traer para que no parezca que es solo usted quien programa de manera tan "anormal".

Es una pena que otros no valoren tu trabajo o no quieran aprender de él si ese es el caso. Deja de golpearte la cabeza contra la pared. Quién sabe, surgirá algún proyecto/tarea en la que tú eres la única esperanza de que funcione. A nadie le importará cuán complicado es su código a largo plazo si lo hace funcionar cuando nadie más puede hacerlo.

No podemos depender de él a largo plazo.

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

Puede silenciar a la administración con:

• De todos modos, no está pensando en irse a otro lado, por lo que pueden contar con usted a largo plazo.

Creo que estoy desafiado con problemas que mantienen mi habilidad en uso, así que creo que finalmente encuentro un lugar de trabajo que puedo disfrutar por mucho tiempo.

• Está dispuesto a brindar capacitación a otros miembros del equipo para brindar más valor al equipo.

Me di cuenta de 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 si todos comienzan a usar esas técnicas gradualmente para mejorar el rendimiento del equipo. Yo puedo ayudar con eso.

• Se le solicitó que implementara las funciones XY, ya que las funciones 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 próximas funciones? Realmente trabajé duro para hacer las cosas correctamente, lo logré, pero me temo que no todos pueden entender eso. En cambio, quiero tomarme un tiempo para hacer que las cosas sean comprensibles para los demás.

Sea honesto, si alguna declaración no se aplica (no sé ahora en qué trabajó), no mienta, nunca.

Si te van a despedir, entonces no dependen realmente de ti. De todos modos, al menos 2 personas en el equipo entienden tu trabajo: tú y tu compañero de trabajo. Y es probable que más personas puedan entenderlo en el futuro. Básicamente, no eres un cuello de botella en tu equipo, sin embargo, temen que puedas convertirte en él más tarde. Deberían invertir algo de tiempo en la formación de todos modos.

Lea El vagón, el mirlo y el Saab . Debería resonar contigo.

He tenido problemas similares en el pasado; Aprendí algunas cosas sobre cómo hacer policía, pero ambos hemos estado usando un trapeador y un balde para tratar de limpiar la salida de una manguera contra incendios.

No estoy sugiriendo aquí que merezca un diagnóstico de salud mental según el DSM-V, pero sugiero que le recomendamos que busque un buen consejero y trabaje en el comportamiento no amenazante y las habilidades sociales. También puede leer Teoría de las mentes alienígenas .