¿Cómo saber si el consejo de un desarrollador senior es malo? [cerrado]

Recientemente, comencé mi primer trabajo como desarrollador junior y tengo un desarrollador más senior a cargo de asesorarme en esta pequeña empresa. Sin embargo, hay varias ocasiones en las que me da consejos sobre cosas con las que simplemente no puedo estar de acuerdo (va en contra de lo que aprendí en varios buenos libros sobre el tema escrito por los expertos, las preguntas que hice en algunos sitios de preguntas y respuestas también están de acuerdo conmigo) y dada nuestra apretada agenda, probablemente no tengamos tiempo para largos debates.

Hasta ahora, he estado tratando de evitar el problema escuchándolo, planteando un contrapunto basado en lo que he aprendido como buenas prácticas actuales. Vuelve a plantear su punto original (la mayoría de las veces dirá mejores prácticas, más fácil de mantener pero simplemente no fue más allá), tomo una nota (ya que no planteó un nuevo punto para contrarrestar mi contrapunto), piense en e investigue en casa, pero no haga ningún cambio (todavía no estoy convencido). Pero recientemente, se acercó a mí una vez más, vio mi código y me preguntó por qué no lo había cambiado a su sugerencia. Esta es la tercera vez en 2 a 3 semanas.

Como desarrollador junior, sé que debo respetarlo, pero al mismo tiempo no puedo estar de acuerdo con algunos de sus consejos. Sin embargo, estoy siendo presionado para hacer cambios que creo que empeorarán el proyecto. Por supuesto, como desarrollador inexperto, podría estar equivocado y su camino podría ser mejor, puede ser uno de esos casos de excepción.

Mi pregunta es: ¿qué puedo hacer para juzgar mejor si el consejo de un desarrollador senior es bueno, malo o tal vez es bueno, pero desactualizado en el contexto actual? Y si está mal / desactualizado, ¿qué tácticas puedo usar para no implementarlo a su manera a pesar de sus 'presiones' mientras mantengo el hecho de que lo respeto como senior?

Primero, como desarrollador senior, espero que los juniors que lidero en proyectos me traigan sus preocupaciones de una manera directa y directa. Si no están de acuerdo, está perfectamente bien conmigo. En algunos casos, tomaré medidas sobre sus preocupaciones. En la mayoría de los casos, sus preocupaciones se descartan y se dejan a un lado con una breve explicación del razonamiento , no por falta de respeto por el desarrollador en sí, sino por alguna otra razón, como:

1. El junior no tiene toda la información a la mano para entender la decisión tal como se tomó. En algunos casos, una pequeña explicación puede ayudar al desarrollador a superar la preocupación y lidiar con una situación irreal.
2. El junior tiene MALA información. No olvides que eres, de hecho, un junior. Eso es el equivalente a ser un adolescente en términos de software. Estoy seguro de que tienes muchas ideas geniales, pero es posible que no lo sepas todo. Creo que los desarrolladores junior más resistentes son los que creen firmemente que saben lo que es mejor para el código, la compañía, el mundo. Estos desarrolladores están mejor atendidos adquiriendo humildad.
3. La decisión de hacer algo de una manera particular se tomó por encima de la cabeza del senior. El senior todavía trabaja para alguien más al final. En realidad, puede haber una mejor manera de hacer algo, una forma más eficiente de escribir algo o un mejor software / hardware para ayudar a hacer el trabajo. Sin embargo, el negocio aún impulsa las decisiones. Los gerentes de negocios, directores, vicepresidentes, etc. a menudo toman decisiones que impactan el proceso de desarrollo. Estos están más allá del control del senior, y cuando los junior se quejan de eso, todo lo que están haciendo es aumentar el estrés del senior.
4. El senior simplemente no tiene tiempo para tenerlo en cuenta. Hay plazos, y a veces cambiar los patrones, las prácticas y los comportamientos a mitad de camino es costoso para ese plazo. Dado que es su cuello en el bloque de corte, a menudo es más importante hacer que el producto salga funcional y a tiempo que "perfectamente escrito".

Estas son solo las cosas que puedo pensar fuera de mi cabeza. Hay muchas razones por las cuales una idea, práctica, concepto puede ser descartado o descartado por alguien más alto que usted. Muchos de ellos son desagradables, pero todos se reducen al hecho de que todos somos humanos y todos tenemos opiniones. Su opinión es numéricamente superior a la suya en este momento.

Teniendo en cuenta esos conceptos, debe continuar presentando sus inquietudes al desarrollador principal. Encuentre otro desarrollador senior que pueda completar los espacios en blanco. Muchos desarrolladores senior están donde están porque son mejores con el software que con las personas. Algunos están donde están porque sabían a quién se besaban cuando eran pasantes. Encuentre uno que realmente entienda lo que significa ser mentor de alguien y obtenga su opinión honesta. Pueden estar en desacuerdo con usted y completar los espacios en blanco que no tiene. Pueden estar de acuerdo con usted y ayudarlo a reunir su causa o mejorar su situación.

En ningún momento deberías montar ningún tipo de insurrección. Incluso si cree en su corazón que su camino es el correcto, se le ha dado una instrucción que debe seguir y debe seguirla (a menos que sea ilegal, obviamente). Si tiene problemas para seguir estas instrucciones, puede intentar razonar por qué, porque descubrirá que este patrón de comportamiento es muy frecuente en muchas compañías que producen cualquier tipo de software.

Su mejor opción es continuar haciendo su trabajo de manera ética y profesional. Obtenga el software que se le pide que complete de manera ejemplar y escape de la situación al ser promovido fuera de él. Si las promociones no llegan, tendrá muchas referencias y experiencia para buscar oportunidades en otros departamentos o empresas.

Respeto al desarrollador senior. Él está más en la línea para el éxito del proyecto que tú. Como él tiene la responsabilidad, también obtiene la autoridad. Si él dice cambiar algo, entonces hazlo.

Dicho esto, no dude en presentar sus inquietudes cuando encuentre un problema como el que ya tiene.

Por último, siéntese con él y explíquele la misma pregunta que publicó aquí. Tal vez te estás perdiendo algo grande, tal vez él se abrirá más a tus sugerencias, de cualquier manera, no lo mantengas a oscuras si crees que su consejo es malo.

Cuando esto sucede, lo que debe hacer es conversar con el desarrollador principal . Quizás él sepa algo que usted no sabe sobre el código o los requisitos técnicos / comerciales. Si es así, deberías aprenderlo.

Hazlo en privado. Puede verse como una autoridad desafiante, y tales cosas se hacen mejor uno a uno. Demuestre que está dispuesto a comprometerse y colaborar reconociendo y respetando su antigüedad, pero sea persistente para responder sus preguntas. Enfoque la situación desde un marco colaborativo, no combativo. Podrías considerar pedirle que te guíe.

Al final del día, debe equilibrar sus propias ideas (que, para ser justos, son relativamente nuevas y no probadas) con las suyas. Quizás tenga razón, pero debe hacer todo lo posible para aprender de las personas más experimentadas para poder tomar una decisión más informada. Un buen desarrollador senior agradece la oportunidad de colaborar, orientar y aprender, incluso con desarrolladores junior, y agradece que sus ideas se cuestionen de manera constructiva porque también saben que a veces están equivocadas.

La forma en que suele contar es a través de un enfoque de sentido común. Tenga en cuenta que el desarrollador senior puede saber más sobre el proyecto, pero puede que no sepa más sobre la forma correcta de hacer las cosas. Tienes que evaluar lo que te dice que hagas: te está dando malos consejos si lo que dice va en contra de lo que dicen sus mejores (es decir, personas más mayores que él; no necesariamente en tu empresa ... Estoy hablando de desarrolladores conocidos de "celebridades" que a menudo publican o escriben libros sobre la forma correcta de desarrollar software o, como mínimo, las mejores prácticas aceptadas por la industria).

Aquí hay un ejemplo de "malos consejos" de un desarrollador senior (o cualquier desarrollador): si ignoran por completo qué es el acoplamiento flojo y por qué es algo bueno, y le dicen que escriba todo el código, digamos, el código -detrás de un archivo ASPX, es obvio que el desarrollador senior no tiene ni idea y sus consejos no deben ser escuchados.

Si, por otro lado, le está diciendo cómo funciona un módulo específico en el sistema, a menudo es mejor escuchar siempre que lo que le está diciendo no escupe frente a los principios de desarrollo adecuados.

Esta es mi regla de oro: un desarrollador senior en una empresa podría ser simplemente el desarrollador con la mayor antigüedad; él podría no tener ninguna habilidad real. ¿Está diciendo cosas que van en contra de lo que dicen algunos de los desarrolladores más respetados en su campo (personas con mucha más experiencia que él y que son mucho más competentes y respetados)? Si es así, es probable que su consejo sea malo a menos que haya circunstancias muy extremas.

Totalmente esperando downvotes / desacuerdos para un punto de vista extremadamente parcial.

Puede ser difícil comprender el punto de vista del desarrollador senior, y sí, puede estar liderando las cosas por el camino equivocado, sin embargo, cuando se trata de proyectos grandes, la consistencia es más importante.

Tener 50 desarrolladores que sigan sus propios estilos de codificación, estándares, metodologías y patrones de diseño sería un caos total. Si las cosas se hacen mal, siempre es mejor estar consistentemente equivocado que muchos tipos diferentes de mal y algunas cosas que se hicieron bien.

Cuando llega el momento de realizar tareas de mantenimiento, agregar funciones o corregir lo que está "mal", es mucho más fácil si los problemas con el diseño existente se conocen por adelantado.

Es bueno estar respetuosamente en desacuerdo, pero al final es mejor que te pongas en línea. Cualquiera en un equipo que se vuelve pícaro no es visto como un jugador de equipo.

Si la persona mayor no puede darle buenas razones por las que ignora las mejores prácticas de la industria, entonces no pierda su tiempo allí. Nunca avanzarás porque eres demasiado amenazante y, de todos modos, ¿quieres pasar tiempo manteniendo un montón de códigos incorrectos?

La mayoría de los desarrolladores dejan de leer cuando dejan la universidad. No lo has hecho, así que ya estás en el 10% superior. Hay muchas oportunidades en estos días. Si no hay un mercado laboral en tu ciudad, busca una ciudad mejor.

Wow, es una oportunidad maravillosa para que brille y muestre sus habilidades. Al principio de mi carrera, tenía a alguien que era mi supervisor y no podía tomar una decisión, ninguna decisión, por lo que aproveché esa oportunidad para aprender cómo hacer el trabajo del siguiente nivel superior. Me consiguió promovido. Deberías hacer lo mismo.

Como desarrollador senior, este tipo de selección pasiva agresiva de liendres me volvería loco y, después de confrontarme, me llevaría a darle una mala crítica. La solución perfecta es aquella con la que el equipo puede vivir juntos.

En cuanto al estilo, esto debe ser dictado por su guía de estilo y las mejores prácticas determinadas por su origen. Si eres un apasionado, discute, pero una vez que se tome una decisión, vive con ella y trabaja con los límites del equipo en el que estás.

Estás en una situación no tan buena pero, como señaló HLGEM, puedes convertir estas posiciones en bendiciones disfrazadas. Su pregunta es multifacética, así que la abordaré en partes.

Sospecho que no lo sabe. Al mismo tiempo, él trata de mostrarme que la arrogancia puede ser para que no recurra mucho a él para preguntas.

Esto bien podría ser cierto. Hay una avalancha de desarrolladores que han estado en la industria durante décadas y no son líderes de software capaces, desde el punto de vista del desarrollo o la tutoría (hay una diferencia). La experiencia proviene de abordar nuevos desafíos y probar nuevas ideas y aprender nuevas habilidades, pero la mayoría de los programadores pasan sus vidas en un ala de The Corporate Office, trabajando en The Payroll Application con sus fieles herramientas Visual Basic y Java, sin ver nunca el mundo corriendo por su oficina fría y gris.

No hay nada de malo en esto . Para muchos desarrolladores, esto es todo lo que siempre quisieron y están perfectamente satisfechos con la situación; sin embargo, no es una situación ideal para fomentar una futura generación de programadores, y mucho menos para los desarrolladores líderes.

La bravuconería y la arrogancia pueden ser un mecanismo de defensa, tratando de cubrir las insuficiencias. ¿Cómo lo manejas? No lo enfrentes de frente: si tu liderazgo es incompetente y el jefe no está dispuesto a rectificar la situación, entonces tendrás que vivir con eso . Eso no significa darse la vuelta y morir, pero no puedes obligar a alguien a ser un buen líder.

Sin embargo, solo revisa mi código, y la mayoría de sus comentarios están relacionados con las pautas de codificación

Esto es lo que me hace pensar que tienes razón en que él puede no ser un buen programador. Eso no quiere decir que no sea un mejor programador que usted en este momento (al menos tendrá más experiencia y exposición de estar en la industria durante tanto tiempo), pero de nuevo, eso no se traduce en ser un plomo efectivo Las pautas están muy bien, pero son secundarias a la función, efectividad y eficiencia del código.

¿Qué debo hacer en tal situación?

Le informé a mi gerente sobre esta situación y le solicité que cambiara mi liderazgo, aunque siempre me dice "sí", pero no toma ninguna medida seria.

¿Ha enumerado todos estos puntos específicos al gerente y con ejemplos específicos para respaldarlo? Si simplemente se dirigió a él y le dijo: "Necesito una nueva pista", no lo tomará en serio y lo percibirá como un "problema interpersonal" en lugar de un problema técnico. La reacción de muchos jefes en esta situación es ignorarlo con la esperanza de que "funcione".

Aquí hay algunas sugerencias.

1. No se enoje con su situación : la prueba de fuego, aunque no es divertida, le enseña algunas habilidades críticas de investigación para más adelante en su carrera.
2. Empieza a impulsar tu liderazgo para estar más involucrado. Haz esto con cuidado y respeto . Continúe presionando y sea persistente hasta que se rinda (esto realmente funciona para muchas situaciones en la vida).
3. Si su liderazgo no se involucra, vea si hay otros que puedan ayudarlo. A menos que trabaje en una tienda especializada que solo se preocupa por las horas de ordeño, a su empresa no le importará que otro desarrollador con más experiencia le muestre algunas cuerdas y revise su código.
4. Comienza a estar atento a un nuevo trabajo. No diría que está en una situación de "debe irse", pero no dañaría su carrera estar en un lugar que tome su desarrollo como programador más en serio.

Si tiene una mejor manera de resolver un problema en particular, simplemente HÁGALO .

Deje que su código / solución sea su mejor argumento. De lo contrario, atenerse a lo que le han dicho.

Caso en punto

cuando era un joven tenía una situación en la que una sección particular de código no era lo mejor que podía ser. En lugar de solo debatir sobre ello, simplemente lo mejoré ENTONCES, mostré los resultados a mi superior. Lo aceptó, porque el código siempre es el rey.

Por supuesto, como desarrollador inexperto, podría estar equivocado y su forma podría ser mejor, así que mi pregunta es qué formas puedo hacer para juzgar mejor si un consejo de desarrollador senior es bueno o malo / desactualizado.

Puedes convertirte en un desarrollador experimentado. Hasta que haga eso, estará mal equipado para juzgar si su intuición como junior era correcta o no, y para entonces no importará.

Mientras tanto, lea la respuesta de Joel Etherton.

Sugeriría encarecidamente no intentar "no implementarlo a su manera".

Hasta ahora, parece que has hecho lo correcto. Fuiste humilde y sacaste un contrapunto. No podría decir por su pregunta si simplemente no estuvo de acuerdo con su método, o si no estuvo de acuerdo y presentó una alternativa. Sin embargo, siempre ofrezca una alternativa clara y pensada cuando intente derribar el enfoque de otra persona . Como él puede ver, tienes una buena idea que podría funcionar, y él tiene una idea que sí funciona.

En cualquier posición, nos vemos obligados a hacer cosas subóptimas todo el tiempo. Si realmente no te gusta, entonces puedes hacer lo que hiciste y mencionarlo. Después de eso, es el camino del jefe o la carretera. En el lado positivo, está aislado de gran parte del riesgo de malas decisiones como junior.

Elige tus batallas. Si está hablando de una hora de trabajo, tendrá que cambiar su código a veces hasta que suba. La próxima vez que obtenga un proyecto grande, pregunte con anticipación la oportunidad de presentar sus ideas antes de comenzar. Dedique algo de tiempo extra y haga una demostración o prototipo increíble.

Sorprendentemente, lo que he hecho es dejar de preguntar. Cuando me dan otra opción, simplemente me desvío y lo hago a su manera, pero le agrego mi propio estilo. Úselo como una experiencia de aprendizaje para desarrollar sus habilidades y aún así calmar su necesidad de mantener la vieja escuela.

Al final, no todos los desarrolladores senior prestan atención a las nuevas formas de hacer las cosas. A veces tienen formas de la vieja escuela que eran geniales para el idioma que comenzaron hace 20 años, pero que se consideran hacky o "huelen mal" en el mundo de hoy.

Esto puede sonar como una forma horrible de seguir adelante, y lo es. Pero también he aprendido mucho de la forma en que mis personas mayores hacen las cosas. Pero esto es realmente solo mi opinión. Al final, debes ser feliz en tu trabajo y mantener las distracciones y la tensión a un nivel bajo. Y al no oponerse a las cosas, verá que el estrés disminuye.

No confíes en las personas mayores debido a su antigüedad. Desafíe a la autoridad tan a menudo como sea posible. Una autoridad competente debería poder responder de manera convincente a cualquier pregunta. Eso es lo que lo convierte en una autoridad en primer lugar, ¿no?

El hecho de que alguien tenga creencias supersticiosas durante toda su vida no significa que tenga razón. Recuerde, en la edad media la gente creía que la tierra era plana y algunos de esos asnos justos incluso se sentían justificados al matar a los escépticos. Resultó que los que dudaban tenían razón. Demasiado para malas críticas.

Nunca temas a una mala crítica. ¿Confiarías en un ciego que juzga el color?

buenas respuestas anteriores, agregaría que una respuesta como "mejores prácticas" o "más fácil de mantener" es una oportunidad para aprender algo . Usted dice: "¿Puede darme un ejemplo de por qué esa manera es mejor para que pueda entender la diferencia?" o "¿En qué situaciones sería más fácil de mantener de esta forma que en otra, para que pueda aprender a planificar de esa manera?"

Si la persona mayor tiene razón, darle un ejemplo será fácil. Si es un loro ... dale una galleta para detener el graznido y haz lo que creas que es mejor. Hasta que se ordene lo contrario.

Si el rol del senior es ser mentor, él explicará por qué cuando se le pregunte.

Como HLGEM y Jarrod dijeron antes, esto es realmente una bendición disfrazada. Ambas respuestas son geniales y quiero agregar algunos puntos.

Como su cliente potencial no está en su dominio, puede tomar algunas de las decisiones importantes para su parte de la aplicación, ya que su cliente potencial no sabe mucho sobre middleware. También tiene un cierre con su gerente sobre cómo debe funcionar la aplicación, qué quieren los usuarios del producto y cómo su gerente querría abordar una situación que le presenta el equipo del producto. Dime cuántas personas obtendrán ese tipo de conocimiento en una aplicación.

Cuando esté en un equipo grande, seguramente contará con la ayuda de sus compañeros de equipo y / o su líder, pero no tendrá el conocimiento de cómo piensa su gerente o el equipo del producto porque ese tipo de cosas generalmente pasan por su liderazgo y pueden ser algunos desarrolladores senior en un equipo. Estoy de acuerdo en que los proyectos de una persona son un poco difíciles de llevar, pero si el otro lado de la moneda es tan bueno, ¿por qué perder una oportunidad? Aprenda lo que puede aprender, disfrute mientras pueda y, si se pone demasiado difícil, convenza a su gerente como lo dijo Jarrod o encuentre un nuevo trabajo / proyecto dependiendo de la situación.

Vas a tratar con personas así toda tu carrera. Y habrá muchos con quienes no estará de acuerdo sobre el mejor enfoque para cualquier problema de codificación. Lo mejor que creo que me ha funcionado a lo largo de los años es que si continúan presionando sobre un problema, sea sincero con ellos y dígales que ha considerado su solución entre las diversas soluciones posibles y que sintió que la solución es se decidió por el mejor enfoque en esta situación.

Ahora, si eliges en contra de sus consejos cada vez, entonces ocasionalmente puede que tengas que ceder y usar sus "consejos" de vez en cuando solo para suavizar algunas plumas con volantes. Siempre y cuando no sientan que estás rechazando su opinión cada vez, eso ayudará mucho a mantener la paz entre ustedes.

Considere también que son desarrolladores senior y que han trabajado en ese entorno durante más tiempo que usted. La codificación de la vida real a menudo no coincide con las mejores prácticas o los estándares aceptados por la comunidad. Puede haber una razón por la que te recomendaron que hagas algo de cierta manera que no pueden articular completamente. Por lo tanto, incluso si no está de acuerdo con ellos, asegúrese de no ignorar sus consejos sin más, basándose únicamente en el hecho de que cree que su solución es mejor.

Se trata de equilibrio. Y no solo el equilibrio de codificación, sino el equilibrio del equipo. Muchos proyectos han fallado no porque los desarrolladores no fueran capaces de hacerlo, sino porque no pudieron encontrar formas de trabajar juntos de manera amigable.

Me gustaría proporcionar algunas cosas de mi experiencia personal, que deberían considerarse como una respuesta complementaria a una publicada aquí por jzd ...

1. Pregúntale a otro desarrollador senior,
2. Investigue por su cuenta.

En una cita profesional, se suponía que debía ser asesorado por alguien mayor. Sabía algunas cosas, pero honestamente no tanto, desafortunadamente no lo sabía, por lo que estaba muy seguro de sus respuestas. De alguna manera sentí que lo que dijo estaba mal. Tenía algunas pruebas cuando las cosas que hizo estaban en contra de las mejores prácticas mencionadas en la certificación MS que tomé :-). Después de eso, comencé a preguntar a otras personas que trabajaban en otras compañías (stackexchange no estaba funcionando en ese momento) y comencé a leer blogs para comparar respuestas.

Sería genial si estuviera equivocado, porque simplemente cambiaría mi comportamiento, pero no lo estaba.

He notado algo en los últimos años, casi todas las empresas en las que estoy, con casi todos los proyectos en los que trabajo, con casi todos los nuevos empleados (independientemente del nivel de habilidad / experiencia) quieren hacer algo 'diferente'.

Pueden ser los estándares de codificación o la arquitectura general o el lenguaje o la metodología. Pero siempre es algo. Muchas veces, solo está diciendo lo obvio: '¿No deberían documentar mejor las cosas para nuestros usuarios finales?'

Mi consejo para ti es que no seas ese tipo .

Algún día, serás un tipo de alto nivel que es contratado y pagado para tomar esas decisiones. Cuando llegue ese día, ¡adelante! Hasta ese día, date cuenta de cuál es tu posición. Tengo un jefe, en lo que a mí respecta, todo mi trabajo es hacer feliz a mi jefe. No es para adivinar decisiones tomadas fuera de mi salario. Si realmente no está seguro, hable con su jefe / supervisor e infórmese.

En términos generales, sin embargo, es mucho mejor tener a todos a bordo con un enfoque desactualizado que la mitad del equipo que sigue el enfoque desactualizado, 1 / 4to del equipo siguiendo un nuevo enfoque y 1 / 4to del equipo tratando de desarrollar una vanguardia , nuevo enfoque.

Hay una corriente subterránea en todo esto que creo que debería ser clara: no seas combativo . Preserva tu relación con él. Es genial tomar su consejo con un grano de sal y validarlo en libros y en sitios como estos, pero no lo ataque. Si es un desarrollador senior y ha pasado por muchos proyectos, no es un idiota, y hay mucho que aprender de él. Como parece que ya lo has hecho, expresa tu deseo de entender su punto de vista. Incluso si estás seguro de que está equivocado y tienes razón, acepta la posibilidad de lo contrario (parece que ya entiendes esto). Trata de dejar en claro que estás discutiendo porque quieres entender mejor su punto de vista, no porque estés tratando de demostrar que está equivocado.

Si no te responde de inmediato cuando le haces una pregunta, o si su respuesta es vaga y / o inútil, no asumas que te está volviendo loco. Como ya se mencionó aquí, puede estar ocupado y / o estresado.

También es genial ser paciente. Mantenga una lista de cosas en su cabeza que cree que deberían hacerse de manera diferente y preséntelas en el momento adecuado. Asegúrese de tener una justificación para la sugerencia además de "es la mejor práctica". Y tenga cuidado de hacer las cosas bien y no cometer errores, para que tenga credibilidad cuando presente sus argumentos más adelante.

Hasta ahora he estado tratando de evitar el problema escuchándolo, planteando un contrapunto, él vuelve a plantear su punto original (la mayoría de las veces dirá mejores prácticas, más fácil de mantener pero simplemente no fue más allá), yo. .. pensar en ello en casa, pero ... todavía no estoy convencido. Pero recientemente él ... vio mi código y me preguntó por qué no lo he cambiado a su sugerencia. Esta es la tercera vez en 2 a 3 semanas.

(Ligeramente editado para las acciones).

Esta parte me concierne. Una forma de ver si estás en lo correcto o no es entender lo que está diciendo. Lo que leí (con mi propio historial, otros pueden ser diferentes) es un desarrollador junior que no entiende lo que dice el mentor y no pide una aclaración. Una forma de resolverlo es pedirle que aclare: ¿cómo es esta una mejor práctica que esa? ¿O por qué es más fácil de mantener que nuestro código? Si no sabes sus respuestas a esto, realmente no sabes si está dando buenos consejos o no.

La parte que realmente me preocupa es que te ha pedido que lo cambies varias veces, y tú no lo has hecho. Aquí hay una forma en que podría verse desde su lado: él le pide que haga el cambio, le pregunta por qué, le da una razón (válida, en su opinión), y se niega a hacer el cambio. No pides una aclaración, por lo que él supone que entiendes la razón, y eres demasiado flojo o demasiado terco para cambiarlo; ninguno de los dos es algo bueno para que un desarrollador senior piense en ti. Confía en mí, es mucho mejor hacer preguntas que obtener una reputación de esta manera.

Algunas reflexiones:

1 / ¿Funciona? ¿Es su forma de trabajar o no? ¿Es la razón objetiva por la cual su camino sería inferior?

Por razón objetiva, quiero decir algo que se puede medir sin ambigüedad (rendimiento, errores, longitud del código ...) Si sus soluciones funcionan y no hay una métrica objetiva que indique que es una solución pobre, hágalo a su manera. Su camino es mejor ... porque probablemente sea más consistente con el resto de la base de código y porque le será más fácil usar / reutilizar su trabajo. Puede que no te guste, pero de eso no se trata, ¿verdad?

Si no funciona o tiene un rendimiento inferior en las métricas importantes, impleméntelo, compare su solución con la suya, luego dígale que lo ha intentado a su manera, pero que no puede lograr que funcione bien (proporcione las métricas) y pregúntele si cometió un error en su implementación o si existe un requisito que desconoce

Los programadores de 2 / Star dicen ... ¿Por qué les importa? Encontrará programadores famosos profundamente en desacuerdo entre sí en muchos temas fundamentales, tales como planificación, diseño, OOP vs procedimiento, pruebas unitarias, manejo de excepciones, control de fuente, y así sucesivamente.

Si la única diferencia en la capacidad de trabajo entre 2 soluciones es quién lo favorece, omítala. Podría beneficiarse del entrenamiento mental requerido al trabajar en un paradigma que no le gusta

Basado en la idea de que solo debe recibir consejos de las personas con las que quiere ser, la respuesta es que el consejo principal es bueno si quiere ser como él / ella.

La mayoría de mis problemas los he solucionado publicando en foros y obteniendo respuestas de otros, y he estado sobreviviendo por alrededor de 1 año así.

¿Qué debo hacer en tal situación?

Para ser sincero, así es como son muchos trabajos técnicos. Debe ser un emprendedor que pueda resolver problemas difíciles por sí mismo (con la ayuda de Internet y sus habitantes) si es necesario.

Desde el punto de vista de obtener revisiones de código y obtener ayuda con los diseños arquitectónicos, incluso cuando he tenido buenos gerentes, nunca he tenido mucha revisión de código más allá de "las variables estáticas deben tener el prefijo s_".

Aproveche la oportunidad de aprender y aprender a aprender; esas serán habilidades que puedes usar en el futuro.

Si piensa por un segundo que la gerencia no comprende cuán capaz es REALMENTE para hacer el trabajo, entonces probablemente esté equivocado. La gerencia probablemente también comprende que su liderazgo en este momento sería completamente inútil si lo reemplazara y se hiciera cargo de su trabajo.

Las razones REALES por las que no te han reubicado son porque a pesar de todos los desafíos que les presentas, sigues siendo la mejor persona para el trabajo. Obviamente valoran demasiado su trabajo como para arriesgarse a entregárselo a nadie más.

No subestimes la inteligencia de la gerencia ...

Son mucho más inteligentes de lo que la mayoría de los desarrolladores les dan crédito. No entendí esto hasta que comencé a administrar. Probablemente también sean conscientes de cuán inútil es realmente su plomo, pero probablemente no tengan poder para abordar ese problema.

Permítame pintarle una imagen, el líder A con 5 años de experiencia en la empresa es incompetente. El gerente lo sabe, le recomienda a su gerente superior que despida al líder A. El gerente superior le pregunta por qué no fue tratado hace años si es tan incompetente. El gerente se ve mal ahora, especialmente porque el Líder A tiene un salario inflado que se estaba pagando sin ningún beneficio ...

Aquí hay otro escenario potencial, el Líder A es amigo cercano de alguien importante. Él es demasiado caliente políticamente para asumir,

De cualquier manera, con un error de larga duración como ese, es más fácil para las grandes organizaciones barrer a las personas incompetentes debajo de la alfombra, darles un trabajo ocupado y un poder falso que sea apropiado para sus años de "experiencia" donde no pueden hacer MUCHO daño . Desafortunadamente, muchas organizaciones prefieren hacer esto y luego lidiar con los problemas.

Por supuesto, la razón de esto es que el gerente de este tipo de organización siempre está mejor a corto plazo para tratar con el mal talento de esta manera que para abordar los problemas a largo plazo que este tipo de personas pueden traer a la organización.

Entonces, si bien es miope y potencialmente poco ético, debe admitir que es un poco más inteligente de lo que muchos desarrolladores realmente dan crédito.

ughh ahhh Esta pregunta me recuerda muchas cosas. Primero, diré que no podría llevarme bien con uno de los gerentes en mi último lugar de trabajo. No fue un problema de personalidad. Fue un problema de comunicación. Dije XYZ y ese gerente específico interrumpiría lo que estaba diciendo como ABC. No podría comunicarme bien a menos que haya trabajado con ese gerente por más de un año.

Este fin de semana pasado. Un chico discutió / no estuvo de acuerdo conmigo sobre los solteros. Dije que no son buenos y que NUNCA deben usarse y no hay absolutamente ninguna razón para usarlos. Lo vinculé a http://www.gmannickg.com/?p=24 y el artículo más detallado se vincula aUnos días después de la discusión. El día de otro programador (DudeB) menciona que solo usa singletons cuando es apropiado (a lo que agregué 'nunca'). DudeB no dijo nada al respecto, pero DudeB dijo que DudeB estaba en un proyecto que tenía contención de memoria porque todos los hilos estaban accediendo al singleton. Después de mencionar esto, mostrar el artículo y mencionar la contención de la memoria, el tipo con el que discutí dijo que tendremos que estar de acuerdo en no estar de acuerdo con lo que acepté porque no me gusta hablar de singletons (pero estoy escribiendo este d'oh)

El punto es A veces podrías estar completamente equivocado como este tipo (tal vez alguien no esté de acuerdo sobre los solteros conmigo en un comentario). En mi situación con mi gerente, que era mi programador senior, acabo de hacer lo que me pidieron explícitamente y nunca más volví a tomar en serio la calidad en ese lugar de trabajo. Hice lo que prefiero hacer cuando me lo permitieron, pero siempre hice lo que me pidieron, pero si no estuviera de acuerdo, lo mencionaría al menos una vez.

Tengo una opinión completamente diferente / controvertida sobre esto.

Muchas veces las personas pierden la pista del objetivo final, que para la mayoría de las industrias se trata de maximizar las ganancias y minimizar las pérdidas. Sé que esto suena despiadado (de ahí los puntos negativos), pero la experiencia y la sagacidad importan muy poco si no va a producir resultados.

Las personas pueden quedar atrapadas con cosas extremadamente indirectas para discutir que tienen muy poco impacto en los resultados directos de la empresa.

Si cree que tiene razón sobre algo, su mejor opción es mostrar cómo eso producirá mejores resultados medibles .

Inicialmente, trataría de resistir, al final del día, la resistencia al senior probablemente sea inútil al menos hasta que ganes más experiencia y respeto. Use esto como una experiencia de aprendizaje y dentro de más de 2 años si todavía siente lo mismo: muévase a otra compañía. Es entonces cuando puede usar una combinación de sus buenas ideas y las de sus adultos mayores para impresionar a su nuevo empleador. Por supuesto, puede comenzar a darse cuenta de algunas de las razones de lo que percibió como malas decisiones al principio de su carrera y en algún momento puede tener un desarrollador junior trabajando para usted.

[Repost: porque de alguna manera creé una segunda cuenta aquí]

Pero recientemente, se acercó a mí una vez más, vio mi código y me preguntó por qué no lo había cambiado a su sugerencia .

Debe tener claro si se trata de sugerencias u órdenes / instrucciones / directivas / lo que sea.

Sugerencia = Creo que es mejor hacerlo de esta manera; Pero es tu elección.

Orden / etc. = Quiero que se haga de esta manera; Y es mi elección.

Si realmente es una sugerencia, haga lo que desee y deje que su código permanezca. Si es una orden (y este mentor tiene autoridad sobre usted de esta manera), haga lo que le dicen.