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

266

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?

learnjourney
fuente
26
Aprendes más de los errores que de los éxitos.
StuperUser
45
¿Puede dar un ejemplo de uno de los temas sobre los que no están de acuerdo? Sé que esta es una pregunta más teórica, y probablemente quieras evitar los debates técnicos, pero sería interesante saber de qué se ha acabado el desacuerdo.
Adam Rackis
140
Veo una bandera roja en esta publicación. Te han pedido que hagas algo tres veces. Una vez debería ser suficiente. Si no quieres hacer algo, debes convencer a tu mentor de que no es necesario. Si no puede hacer eso, entonces ciérrese la nariz y hágalo, o encuentre un nuevo trabajo.
PeterAllenWebb
66
@peterallenweb, de hecho es malo que se le pregunte 3 veces, independientemente de la calidad del consejo. Supongo que de los comentarios aquí tengo mucho que aprender en términos de trabajar en diferentes equipos. :)
learnjourney
33
Además de lo que dijo Peter: considere su punto de vista: le pide al nuevo chico que haga algo, tenga una discusión técnica, no obtenga más objeciones, y luego, una semana después, descubre que simplemente ignoró su solicitud. Y esta no es la primera vez que esto sucede. (No te preocupes demasiado, ciertamente no eres la primera persona directamente de la universidad en caer en esta trampa. Mientras estés al tanto de estos problemas y trabajes en ellos, estarás bien).
Martin,

Respuestas:

233

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.

Joel Etherton
fuente
47
@ Joel Buena respuesta, pero tenga cuidado con las preocupaciones de "descartar". Las preocupaciones siempre deben reconocerse, incluso si no son válidas, incluso si la mejor respuesta que tiene es "Entiendo su preocupación, pero en este momento tenemos que hacer X por Y". El rechazo superficial de ideas serias es un asesino de la moral y eventualmente puede destruir incluso las culturas más saludables.
Rein Henrichs
42
@Joel: Muchos puntos buenos, pero esto es un poco condescendiente: "Eso es el equivalente a ser un adolescente en términos de software". El respeto que gana un senior de los desarrolladores junior se gana al tomar consistentemente buenas decisiones, no por el simple hecho de la edad o la antigüedad.
Neil G
26
No se trata de responder cómo sabes si un desarrollador sénior es "bueno" o no. La respuesta como se indica aquí parece ser "no importa simplemente hacer lo que él dice". No digo que sea un mal consejo; Solo digo que no responde la pregunta. Por lo que vale, creo que la única respuesta correcta es que sabrás si es bueno en 5 años cuando eres un senior.
Kevin
2
@ Kevin: No puedo discutir con ese comentario, y ciertamente no puedo recomendar a un desarrollador junior ningún método para determinar una forma de responder a esa pregunta específica. A menudo, las personas mayores no pueden responder con precisión el uno del otro. Mi respuesta fue sinceramente orientada hacia algunos de los otros aspectos de la pregunta de OP que me parecieron más pertinentes que cómo detectar a un desarrollador sórdido de alto nivel.
Joel Etherton
11
Parece que la respuesta carece de esa humildad de la que hablas. Los jóvenes a menudo piensan que lo saben todo, pero ¿no comparten las personas mayores el mismo vicio? Esto es exagerado en nuestra industria: una gran parte del conocimiento que tenemos será menos relevante en unos pocos años. (ejemplo de la vida real: tengo un mentor en un proyecto mediano que dijo que deberíamos "hacer algunos botones y escribir SQL en ellos, para ahorrar tiempo". Estaba bastante impresionado cuando le mostré LINQ a Entity y asp.net página sin código )
Kobi
35

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.

jzd
fuente
29
OP: ambos son profesionales, incluso si tienen menos experiencia, por lo tanto, tenga una discusión profesional con él sobre las cosas que cuestiona. Si no está dispuesto a hablar sobre el porqué de sus instrucciones, no es un gran mentor.
DaveE
10
+1 Para "Él está más en el éxito del proyecto que tú". Que cierto es. Sé que ustedes, los desarrolladores junior, no aprecian la suerte que tienen de no tener ese tipo de estrés en ustedes, porque yo no lo hice cuando era un desarrollador junior. ¡Ahora sal de mi césped!
maple_shaft
1
También sugiero que, si sigue sus sugerencias, mantenga un documento de sus inquietudes con respecto al cambio; si se rompe más adelante, puede señalar esto para mostrar que pronosticó el error.
Daenyth
44
@DaveE: Parece que ya han tenido la discusión y el OP simplemente no tenía el contexto suficiente para entender actualmente la sabiduría de los superiores. A veces solo hay algo que puedes explicar, el resto tendrá que venir de la experiencia.
Martin York
2
@Niphra: Posible. Pero sin información más exacta, estoy más inclinado a creer que se trata de un aprendiz ingenuo que sabe menos de lo que piensa. La mayoría de los adultos mayores realmente saben lo que están haciendo (no te conviertes en un ingeniero sénior si eres estúpido, entras en la gerencia).
Martin York
24

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.

Rein Henrichs
fuente
44
+1 por tener una conversación. El desarrollador senior puede ser más capaz (y responsable) de equilibrar diferentes preocupaciones, pero debería poder explicar sus razones. Explicarte a los juniors para que puedan aprender es una gran parte de ser senior. Y si usted como junior no siente que está aprendiendo, tal vez sea hora de cambiar de trabajo.
Jaap
+1 para el mejor uno a uno. El momento del desacuerdo es a puerta cerrada. Cuando se abre la puerta y termina la discusión, no debe haber riñas, socavaciones ni quejas. No abras la puerta hasta que llegues a ese punto. Si aún no está de acuerdo, dígale a la persona mayor que tiene la intención de elevar esto a su supervisor.
Michael Riley - AKA Gunny
18

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.

Wayne Molina
fuente
Tengo que admitir que estoy realmente sorprendido de que tengo siete votos a favor (a partir de ahora) y no hay votos a favor. Yo hubiera pensado que mi actitud / pesimista tono ver / Ranty no habría sentado bien a la gente :)
Wayne Molina
En Slashdot, anunciar que esperabas ser modificado era una técnica probada y verdadera en la burla del karma.
Carson63000
Tendré que intentarlo más a menudo j / k :)
Wayne Molina
11

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.

eje de arce
fuente
11

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.

Kevin Cline
fuente
99
Ciertamente decir simplemente "necesitamos hacer las mejores prácticas de la industria" puede no ser la mejor manera de abrir una discusión. Puede haber una muy buena razón para hacer algo más que la mayoría de los demás.
77
Creo que esto es lo más cercano a una respuesta real. Un desarrollador sénior debería poder proporcionar razones convincentes de que los métodos que defiende son razonables. No podrá mejorar bajo la tutoría de alguien que no puede. Ahora, si te encuentras en tu tercera compañía y todos los desarrolladores senior de todos ellos eran idiotas en tu opinión, puede ser hora de mirar más en el espejo.
PeterAllenWebb
2
@PeterAllenWebb, "debería poder", sí, pero no necesariamente quiere discutir hora tras hora explicando en detalle por qué ha encontrado que una práctica determinada es mala para usted. Ocasionalmente, "¿por qué?" Se puede responder con "¡Porque!"
@ Thorbjørn Ravn Andersen: Estoy de acuerdo, siempre que sea ocasional.
PeterAllenWebb
11

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.

HLGEM
fuente
Aprecio su pensamiento, pero tengo miedo del futuro y especulativo, ya que puede haber situaciones más difíciles, en las que publicar en foros podría no ayudar. ¿Que debería hacer entonces?
developer123
44
Profundiza en los libros y aprende en profundidad. Internet no es la única forma de aprender. Únase a un grupo de desarrolladores locales y establezca contactos con más personas de la tercera edad que pueda asesorar.
HLGEM
Esa es buena.
developer123
9

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.

repetición
fuente
66
Como desarrollador junior, este tipo de dictadura me volvería loco. Voté en contra, lo siento.
kizzx2
9

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.
Ortigas Jarrod
fuente
Muchas gracias, sus puntos son realmente agradables y reflexivos. Vota por ti.
developer123
Gracias, he seleccionado tu respuesta, ya que combina lo mejor.
developer123
7

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.

Noche oscura
fuente
11
@maple_shaft: ¿qué tipo de equipo eres si el código (y todos los que lo mantienen) tienen que sufrir para proteger los sentimientos de los desarrolladores senior?
Jaap
1
@Jaap, en primer lugar estoy hablando de un líder tecnológico o líder de proyecto, esto no necesariamente tiene que ser un desarrollador senior. En segundo lugar, no se trata de sus sentimientos, se trata de avanzar hacia un objetivo común como grupo. El líder debe tener cierta apariencia de control sobre su grupo, independientemente de si está equivocado. El líder es el que se responsabiliza por el código defectuoso que se publica, las características incompletas y los plazos incumplidos, por lo que si es un tonto, sufrirá. Si la empresa no reconoce que es un tonto, la empresa sufrirá.
maple_shaft
2
Si ya le han dicho que lo cambie, ha fallado la revisión del código. Solo tratar de volver a enviarlo significa que se le informará que esto ya ha fallado.
Martin York
2
@darknight, suponiendo que este no sea un problema pequeño, cambiar los paradigmas en una base de código existente podría tener algunas graves repercusiones. Lo que me viene a la mente cuando pienso en este tipo de debates es la estructura de la base de datos. Cambios como ese ciertamente no serán apreciados.
Morgan Herlocker
1
Esto solo se aplica a unidades de trabajo muy pequeñas. Digamos que trabajó durante dos semanas y el código es rechazado. ¿Cómo obtendrá fondos para esas dos semanas?
7

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.

Blrfl
fuente
7

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.

Morgan Herlocker
fuente
6

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.

Jim Crandall
fuente
4

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.

Tim Meers
fuente
3

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?

ThomasW
fuente
55
La mayoría de los gerentes no tendrán mucha paciencia para un desarrollador junior que desafía todo. Si el tuyo lo hace, sacrifica un pollo en honor a Cthulhu, ¡porque has encontrado un gran jefe! De lo contrario, prepárate para comparar precios hasta que encuentres uno.
2

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.

Steven A. Lowe
fuente
2

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.

Amar Jarubula
fuente
Gracias a usted, HLGEM y Jarrod por señalar las partes positivas.
developer123
1

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.

BBlake
fuente
1

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.

Dimitrios Mistriotis
fuente
55
Casi nunca hay una razón válida para ignorar las mejores prácticas de la industria, excepto la ignorancia y / o la falta de voluntad para hacerlo bien. Son "mejores" prácticas por una razón, y las personas que las inventan son diez veces más inteligentes e incluso más avanzadas que el desarrollador principal que las ignora o desconoce.
Wayne Molina
@Wayne M: Bien dicho.
Jim G.
66
@Wayne, aún necesita entender por qué son las mejores prácticas. Si dice ciegamente "esta es la mejor práctica, ¡tenemos que hacerlo!" sin saber por qué, no eres mejor tú mismo.
Diría que Wayne dejó suficiente espacio en su respuesta para la refutación de Andersen.
C Johnson
@ Thorbjørn Ravn Andersen, @learnjourney - De todos los comentarios y respuestas, el comentario de Thorbjørn es probablemente el consejo más crítico y relevante. Debe comprender los problemas que una mejor práctica determinada estaba tratando de prevenir o resolver; de lo contrario, nunca sabrá si esos problemas aún se aplican. En resumen, debe comprender por qué es una mejor práctica. Así es como sugiere alternativas: al iluminar los problemas que resolvió la mejor práctica. Como dijo el merovingio de Matrix, "Sin" Por qué "no tienes nada".
Thomas
1

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.

Rob P.
fuente
17
-1: 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. : Nunca trabajarás para mí. No contrato 'Sí, hombres'. Quiero que mis informes directos ofrezcan críticas constructivas cuando estoy a punto de tomar una decisión subóptima. Si no valorara su opinión, no los habría contratado en primer lugar.
Jim G.
77
No estoy de acuerdo con este sentimiento. Primero, si quieres ser promovido, debes demostrar que eres capaz y estás dispuesto a asumir las responsabilidades de un puesto de alto nivel, por lo que mantener la cabeza baja no es bueno para tu carrera a largo plazo. En segundo lugar, no creo en el enfoque del trabajo "por encima de mi salario". Todos están allí para que la empresa tenga éxito (si no lo es, ya no tienes trabajo), por lo que si ves una mejor manera de hacer algo, por encima de tu salario o no, deberías señalarlo. A veces, un nuevo empleado puede hacer buenas sugerencias porque tienen una nueva perspectiva.
Cercerilla
66
Tiene que estar de acuerdo con @Jim G. Tener la actitud de ser un "Smithers" es lo peor que puede hacer; pensar que su gerente siempre tiene la razón es algo terrible porque a menudo no lo están. También esté de acuerdo con @CodeninjaTim: un nuevo empleado a menudo tiene mejores sugerencias porque no tienen la misma visión que los muchachos a largo plazo, por lo que es menos probable que solo sigan el "status quo"
Wayne Molina
44
@ Jim G: Parece que el OP ya ha expresado su preocupación "Esta es la tercera vez en 2 a 3 semanas". - No puedo imaginar que quieras contratar a alguien que, después de expresar su opinión y explicarte que A es mejor que B (incluso si no está de acuerdo), se niega a hacer el cambio. En ese momento, realmente no está "trabajando para ti".
Rob P.
3
@Wayne M: no estoy abogando porque creemos que nuestros gerentes siempre tienen la razón. Sugerí plantear sus preocupaciones de manera apropiada. Pero después de que le dijeran que hiciera algo 3 veces durante unas pocas semanas, OP no lo está manejando correctamente. Por supuesto, exprese sus inquietudes, pero tenga en cuenta que está EMPLEADO (a menos que no lo esté, entonces ignórelo). Usted acordó trabajar para otra persona a cambio de algún nivel de compensación. El hecho de que tengas un jefe implica una expectativa de que hagas lo que te dicen, dentro de lo razonable. Bien o mal, eso es para lo que te has registrado como empleado
Rob P.
1

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.

Señor jefferson
fuente
1

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.

Caleb Huitt - cjhuitt
fuente
Pedí una aclaración, pero la respuesta que siempre recibí es "es una mejor práctica" o algo parecido antes de que volviera a hacer sus propias cosas. En mi opinión, es una cosa decir que es una buena o mejor práctica, pero lo que quería saber es "por qué" es mejor, lo cual no ha podido explicarme, pero insistir es mejor y como es un senior Debería confiar en él. Aún así, es malo de mi parte no cambiar a pesar de que me hayan preguntado 3 veces al respecto.
learnjourney
@learnjourney: Estoy de acuerdo en que probablemente haya un problema si preguntas por qué y no obtienes respuestas. Todavía recomendaría que se mantenga al tanto de lo que puede parecer desde el otro lado, pero si este desarrollador senior no puede ayudarlo, busque otro y ponga el problema delante de ellos, con solo lo básico ", dijo <razón>, ¿Puedes explicar cómo se aplica eso aquí? ", y no hay recriminación. Si eso no funciona, entonces buscaría algunas de las otras respuestas que dicen hacer el cambio de todos modos, pero tenga a mano su versión y sus razones. Asegúrate de aprender de cualquier manera.
Caleb Huitt - cjhuitt
1

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

Sylverdrag
fuente
1

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.

Alejandro
fuente
1

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.


fuente
Sí, eso es lo único optimista que veo en mi situación.
developer123
1

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.

eje de arce
fuente
Gracias por la respuesta y por incorporar el lado administrativo del pensamiento y sus puntos de vista. Vota por ti.
developer123
0

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.

usuario2528
fuente
1
Re: "tal vez alguien estará en desacuerdo sobre los solteros conmigo en un comentario" - No estoy de acuerdo contigo; o) Pero aceptemos estar en desacuerdo
JW01
0

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 .

Adam Gent
fuente
-1: tan ridículo. // El quid de su opinión "controvertida" se basa en el hecho de que el OP está atrapado en minucias o trivialidades. ¡No lo sabes! Tome la pregunta al pie de la letra.
Jim G.
La mayoría de la programación es minuciosa Jim G. Y por experiencia (soy un desarrollador senior) hay muchas otras BS involucradas en tener razón . Casi siempre hay una imagen más grande. Y las personas más altas responden a una imagen más grande (ver su actualización), no a "pero mi diseño está más desacoplado". Como el OP no dio un ejemplo, tuve que tomar algunas libertades.
Adam Gent
0

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.

Matt Wilko
fuente
55
-1: ¿Por qué perder más de 2 años trabajando para un senior n00b?
Jim G.
@ Jim: cambiar de trabajo después de 6 meses no se ve bien en tu CV. Si te mudas a otro lugar y la persona mayor es aún peor, ¡el efecto en tu CV es exponencialmente malo! También puede aprender a darse cuenta de que no todo lo que dijeron era incorrecto o al menos había una razón para hacerlo de esa manera.
Matt Wilko
1
@ Jim - Aunque estoy de acuerdo en la práctica, Matt tiene un punto; la gente es estúpida y el trabajo constante en busca de un ambiente adecuado puede lastimarte (puedo hablar por experiencia en este caso). Depende exactamente de cuál sea el consejo, ya sea que no sea óptimo (por ejemplo, no podemos hacer TDD o usar un contenedor de IoC) o simplemente incorrecto (por ejemplo, no sé qué es una interfaz o por qué alguna vez usaría una en programación). El primero está bien para "aguantar", el último es donde huyes gritando porque el mayor es un idiota (espero que tenga esos términos correctos ... siempre me confunden)
Wayne Molina
0

[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.

BIBD
fuente