Mi aporte es llevar esto a su gerente.

La retroalimentación constructiva en una revisión de código es una cosa. Llamarlo varias veces al día frente a sus compañeros es promover la intimidación.

Dile a tu jefe directamente

Está dañando mi moral. Solía ​​disfrutar del trabajo. La retroalimentación estructurada constructiva es excelente, pero llamarme varias veces al día frente a mis compañeros no es apropiado.

Tienes que ser directo. Lo que ha hecho hasta ahora es insinuar el problema y enviar señales de que su entrada no es deseada e inapropiada. Eso funcionará bien en personas razonables. Tu nuevo colega obviamente no es razonable.

Así que habla con él. Debido a que ha estado en la empresa durante casi 2 años y él es nuevo, tiene cierta posición informal para discutir esto con él y eso se duplica para alguien que acaba de ingresar a la fuerza laboral. Habla con este colega en privado y di algo como:

He notado que tienes un patrón de comentar sobre mi trabajo o criticar las decisiones que tomo. Intenté dejar en claro que estos comentarios no son deseados ni justificados, pero parece que no entendiste el mensaje. Si tiene preguntas sobre por qué hago X o por qué usamos el paquete Y, estaré feliz de responderlas, pero necesito que deje de criticar mis prácticas de codificación. No es tu lugar darme ese tipo de comentarios y es especialmente extraño viniendo de alguien que acaba de unirse a un nuevo entorno de desarrollo de software. Dado que acaba de comenzar, le recomiendo que se concentre en aprender y adoptar el tipo de prácticas y herramientas de codificación que usamos aquí. El tipo de programación en blanco y negro que te han enseñado en la universidad no Por lo general, se traduce en un entorno productivo y debe tomarse el tiempo para familiarizarse con un sistema antes de criticarlo. Tal vez no te des cuenta de esto, pero ese tipo de crítica innecesaria realmente puede dañar tu posición y reputación y es un mal hábito para adoptar en un lugar de trabajo.

Eso es mucho texto y bastante duro, por lo que sugiero elegir lo que funciona para usted y ajustar el tono según sea necesario. Pero hagas lo que hagas, no recurras a "Me gustaría que lo hicieras" o "Quizás sería mejor si". Tienes la experiencia para hablar sobre este tema y tienes una petición clara y razonable que hacer a tu colega. No suavice el mensaje ya que corre el riesgo de ocultarlo.

Después de esto, la próxima vez que haga esto, deja lo que estás haciendo y llámalo inmediatamente:

Oye, esto es de lo que acabamos de hablar. No necesito que critiques mi elección de sintaxis aquí y, como dije, necesito que te abstengas de hacer esto en el futuro. ¿Puedes hacer eso?

Puede tomar algunos intentos, pero esto debería funcionar para todos, excepto para los compañeros de trabajo más tontos. Si tiene uno de estos últimos en ese momento, debe plantearlo como un problema de rendimiento con su gerente.

Sophie, dijiste que nada funciona. En realidad, tus muy educados intentos de cambiar su comportamiento no han funcionado.

Intentaste "ignorarlo y seguir con tus asuntos, diciéndole de manera cortés pero firme, explicando por qué está equivocado, pidiéndole que se relajara y usando el humor para señalar la naturaleza ridícula de algunas de sus críticas más quisquillosas". No has hecho una cosa: No le has dicho que DETENGA. La próxima vez que venga, dígale que PARE y que se vaya. Esta persona está haciendo que no te guste tu trabajo, no hay razón para ser cortés. No te entiende cuando eres educado. No hay necesidad de discutir sus sugerencias y críticas.

No tengas miedo de herir sus sentimientos. Él está haciendo que quieras renunciar a tu trabajo, por lo que está pisoteando tus sentimientos. No tengas miedo de ser descortés. Él está haciendo que quieras renunciar a tu trabajo, eso es lo más descortés imaginable, por lo que no merece ninguna cortesía de tu parte.

Un comentario decía que esto sería actuar de manera poco profesional. No es. Tu colega te ha estado tratando de una manera que te hace querer dejar tu trabajo. Eso es absolutamente, absolutamente, poco profesional. Cualquier cosa que detenga este comportamiento sin afectar a personas ajenas o que infrinja la ley es profesional. Comenzar una confrontación no es profesional. Detenerlo es. Comenzar la confrontación sucedió hace mucho tiempo, y no fuiste tú quien la inició.

Vamos a tomar esto una pieza a la vez. Creo que tienes una valiosa oportunidad aquí.

Soy un desarrollador de software autodidacta aquí.

El tl; dr es que estoy pensando que este es su problema. Esto podría estar totalmente fuera de lugar en sus circunstancias individuales, pero definitivamente se ajusta al perfil. Parece como si él (al menos inconscientemente) estuviera resentido por el hecho de que terminaste en el mismo lugar que él sin seguir el mismo camino que él. Sus acciones, especialmente la insistencia en criticarte abiertamente cuando estás con tus compañeros de equipo , podrían ser una forma de otredad autoengrandecida en un intento de validar sus esfuerzos por tomar un camino diferente. Si es así, esto no es algo que realmente pueda arreglar por ningún otro método que no sea ser mejor en su trabajo que él. Pero eso requerirá una guerra terrestre que saqueará ciudades y costará innumerables vidas.

No; el enfoque que sugiero es usar su buena reputación con su gerencia y su aparente entusiasmo por encontrar fallas en los demás para posicionarse como alguien que está interesado en la perspectiva a largo plazo de su empresa en lugar de "ganar" el día. peleas de hoy con un neófito sabelotodo.

En el proceso, deberá ceder a algunas de las cosas que él exige, pero como desarrollador autodidacta, ya sabe que deberá continuar el camino para obtener una comprensión sólida de su oficio para saber qué cosas vale la pena comprometer, qué cosas son intransigentes y cómo saber qué curso de acción te da lo que quieres.

Entonces... ¿qué es lo que quieres?

• ¿Quiere que las cosas sean "como eran" antes de que se uniera a la empresa?
• ¿Quieres demostrarle a la gerencia que eres material de gestión?
• ¿Quieres que te respete como a un compañero?

• ¿Quieres que te respete como superior?

  1. Ese barco probablemente haya zarpado.
  2. Posible.
  3. Posible.
  4. Posible.

Me pregunto si alguien tiene un consejo sobre cómo manejar a un compañero de trabajo (con aproximadamente 1 mes de experiencia en mi lugar de trabajo en comparación con mis 18 meses) que aprovecha todas las oportunidades posibles para criticar insistentemente mi trabajo en cada paso del proceso, desde las opciones de software paquetes hasta si poner espacios entre un signo igual y una asignación variable (no bromeo).

Estas son críticas constructivas potencialmente válidas de la calidad y la mantenibilidad del código. Hay componentes de software que se pueden aprovechar para aumentar la productividad. Pero dudo que un desarrollador con tan poca experiencia como él tenga una perspectiva experiencial lo suficientemente profunda como para adoptar una postura de línea dura a favor o en contra del uso del código de otra persona, por lo que cualquier valor en su mensaje parece quedar en el camino por su propia acción. Dejaré que xkcd hable por mí sobre cómo me siento acerca de manejar la presentación de cosas a otras personas...

... Si él no está tomando ese tipo de tacto con su discusión de " cosas de las que usted no sabe ", entonces realmente necesita discutir sus modales con su equipo de gestión.

Esto sucede en algún lugar entre varias veces a la semana a varias veces al día. Ocurre de forma cada vez más regular, y cada vez más frente a colegas que comienzan a tratarme de manera diferente por eso.

Esa es la parte que hace que su enfoque sea tan irrazonable, pero también lo que presenta la posibilidad de valor más intrigante para ti. Está siendo visible sobre sus 'ataques'. No lo confrontaría en absoluto sobre esto y, en cambio, consultaría con la gerencia para explicar la situación y me apoyaría en ellos para obtener consejos sobre cómo puede responder de una manera a su enfoque involuntario que demuestra

1. su compromiso de encontrar una manera de coexistir productivamente en la empresa
2. sus cualidades de liderazgo. ( arriesgado si sientes que aún no estás preparado para la tarea )

Hay evidencia objetiva de que soy, de hecho, bueno en mi trabajo. Esta semana recibí un aumento de sueldo del 18%. Cada revisión de desempeño que he recibido ha sido estelar, y la gerencia me sugiere con frecuencia para roles de liderazgo.

Felicidades. Eso significa que está manteniendo contentas a las personas adecuadas con su trabajo.

Sin embargo, como la mayoría de los codificadores, si alguien observa mi trabajo con suficiente atención, por supuesto que se pueden hacer críticas constructivas. Normalmente disfruto el intercambio/revisión de código y lo veo como una oportunidad de aprendizaje productiva.

Bien. Mantén esta perspectiva, aunque no tenga tacto con su presentación. Trate de atravesar su enfoque descarado y vea si hay un valor real detrás de sus declaraciones. Siempre respondía a sus desafíos con reflexivos "¿por qué?" en lugar de un despido sumario debido a su tono. Pero tenga cuidado de exigir respuestas sólidas; preguntar un simple "por qué" a algo mundano y simple podría percibirse como que no conoce los requisitos básicos de su trabajo. Es por eso que ni siquiera lo contrataría hasta una conversación sobre esto con la gerencia.

1. Esto demostraría fácilmente que estás dispuesto a escuchar.
2. Esto demostraría fácilmente que está buscando una buena razón para hacer lo que sugiere.
3. Esta sería una manera fácil de extraer esa educación pagada de su cerebro.
4. Cuando lo llevan a su equipo de gestión, tiene sustancia de qué hablar: "No fue convincente"; " bueno... él podría haber tenido una buena respuesta de por qué debería escucharlo, pero no pude escucharla a través de su rudeza " .

De cualquier forma que lo mires, preguntarle "por qué" se siente de la forma en que se siente puede volverse ventajoso para ti. Despedirlo sumariamente no hace más que crear un ambiente que trabaje a su favor.

Lo que sucedió durante el último mes desde que comenzó mi nuevo compañero de trabajo es algo completamente diferente. He probado múltiples estrategias para lidiar con esto: ignorarlo y seguir con mis asuntos, explicarle de manera cortés pero firme por qué esta persona está equivocada, pedirle a esta persona que se tranquilice y usar el humor para señalar la naturaleza ridícula de algunas de las cosas más insignificantes. -Críticas quisquillosas. NADA FUNCIONA.

Así que... aquí es donde el "él dijo/ella dijo" puede considerarse parcialmente. El resultado que pareces estar buscando es "déjame en paz" y el resultado que él parece estar buscando es "que tú cambies". No ha declarado si tiene justificación para exigir que lo dejen en paz y no tenemos suficientes detalles para saber si tiene razón para esperar que cambie.

Ambos parecen estar muy al principio de sus carreras, por lo que la única declaración no controvertida que siento que puedo hacer es que usted necesita mejorar mucho en su oficio y él necesita mejorar mucho en su oficio.

Al final del día, ese aumento del 18% que mencionaste y la consideración para puestos gerenciales debe verse como una validación de que estás siguiendo el camino que tu cliente quiere para ti; sin embargo, definitivamente no debes dejar que se te suba a la cabeza que esto polariza sus posiciones en "Tienes razón y él está siendo mezquino". Eso sería notoriamente exagerar tu mano... solo decir eso como una palabra de advertencia. Es fácil pensar que tales cosas proporcionan rango para sacar, cuando en realidad no lo son. Son signos de evidencia de que tiene un historial de hacer un buen trabajo. No cambie ese historial.

Si estuviera en su lugar, definitivamente discutiría esto con la gerencia y me posicionaría de tal manera que esta sea una oportunidad para enfrentar el desafío de una persona difícil; sin embargo, tenga cuidado de enmarcarlo con condiciones no binarias. Querrá tomar en serio algunas de sus críticas sin sentido, pero solo hágalo después de preparar la lista de cosas que hará con su equipo de gestión. De lo contrario, su voluntad de modificar sus comportamientos por el bien de su equipo no tendrá visibilidad y él simplemente estará en posición de "corregir comportamientos incorrectos".

Su rechazo a sus críticas parece deberse más a su enfoque que a la esencia de sus declaraciones (que son razones subjetivamente válidas para ignorarlo), pero a menos que la gerencia lo vea de esta manera, corre el riesgo de parecer obstinado.

Solo un escupitajo sobre algo que puede ser la fruta más baja para usted que veo es preguntarse si sus recomendaciones violan los estándares de codificación de su equipo. Si encuentra que no tiene estándares de codificación definidospuede acercarse a su gerencia con la idea de definirlos y luego supervisar las reuniones del equipo donde probablemente tendrá un montón de cosas que decir sobre cómo debe hacer las cosas el equipo y puede moderar entre los otros miembros del equipo. Este enfoque tiene los beneficios de permitirle expresar su opinión, usted demuestra un liderazgo reflexivo y su equipo puede decidir como grupo cuáles serán los estándares. Esto redirige su energía lejos de confrontarte directamente por cosas con las que no está de acuerdo y lo convierte en algo relacionado con el equipo. ...Asegúrese de que la gerencia sepa que es su idea abordar el tema de esta manera.

Casi siempre tendrá que encontrar formas de trabajar con personas difíciles, a menos que progrese a una posición en la que tenga el control de su fuerza laboral.

Es casi seguro que no podrás cambiarlo; debe manipular su exceso de entusiasmo en encontrar fallas en los demás para mejorarse a sí mismo y a los ojos de su equipo de gestión.

Las circunstancias de dónde y cuándo lo hace pueden dictar su respuesta.

Si se trata de una revisión de código real, deberá ser más cortés. Tenga listo un conjunto de respuestas para las críticas más comunes que reflejen los estándares de su propia organización. Si el estándar de codificación es usar una tabulación para sangrar y él quiere usar espacios, entonces golpéalo por violar los estándares en sus sugerencias. Algunas personas nuevas quieren aplicar los estándares que aprendieron en otros lugares y olvidan que cada lugar tiene su propia forma de hacer negocios. Si no hay un estándar (y la forma en que hace las cosas es consistente con la forma en que otros desarrolladores hacen las cosas), entonces dígale que su comentario es irrelevante y que se concentre en problemas reales.

Si te llama la atención sobre cosas por las que no critica a otros desarrolladores y ellos también hacen lo mismo, entonces pregúntale cuál es su problema de que objeta cosas en tu código que no objeta en el código de otros. Sea lo suficientemente fuerte en su objeción en este caso de que lo trate como una cobra que podría morderlo en cualquier momento. Te ha escogido como presa fácil si no hace las mismas críticas a los demás. Demuéstrale que está equivocado en eso.

Y para las revisiones de código, este es un punto clave. Cuando haga un punto válido, acéptelo con gracia e impleméntelo. Si objetas todo lo que dice, te ves mal. Pero si aceptas bien las cosas válidas, entonces se ve estúpido por empujar las cosas no válidas.

Si comienza esto de la nada o solo cuando otras personas entran en el rango de audición, entonces apáguelo con algo como:

• Eso es irrelevante para la discusión en cuestión.
• Esto no es de tu incumbencia
• Ese no es el estándar actual.
• no trabajo para ti
• No sabía que eras el dios de la codificación que dicta las cosas. ¿Me puede mostrar el correo electrónico donde se le asignó esa responsabilidad? (El sarcasmo hace maravillas a veces)
• ¿Podemos volver al tema relevante como... (Ayuda si menciona algo en lo que necesita mejorar en este punto)
• Ya se decidió ir en esta dirección y no vamos a revisarlo en este punto (bueno para cuando critica el software/método que usa para un problema en lugar de las cosas delicadas).
• Eso es incorrecto.

Si tiene compañeros de trabajo en los que puede confiar como aliados, hágalos participar para cerrarlo también. Si dice que esta no es una crítica válida y luego una o más personas saltan a la discusión y están de acuerdo con usted, eso fortalece su caso.

Tengo ganas de tener que agregar mis 5 bolígrafos también.

Dado que, según su descripción, siento que absolutamente podría ser ese tipo, primero le diré lo que asumo que está mal con su enfoque y, además, le daré un consejo que incluso podría ayudarlo a comprender su intenciones reales, en caso de que sus intenciones sean de hecho de la misma fuente que las mías.

Entonces, antes que nada, no puedo comparar su conocimiento profesional con el tuyo. Pero asumo que tu presentación de ti mismo aquí también está sesgada.

Entonces, ¿qué pasa si usted puede ser un poco demasiado confiado con sus propias habilidades? Todo lo que leí hasta ahora lo que intentaste fue:

He probado múltiples estrategias para lidiar con esto: ignorarlo y seguir con mis asuntos, explicarle de manera cortés pero firme por qué esta persona está equivocada, pedirle a esta persona que se tranquilice y usar el humor para señalar la naturaleza ridícula de algunas de las cosas más insignificantes. -Críticas quisquillosas.

Todo esto implica que se está equivocando o incluso está devaluando sus pensamientos. Pero, ¿y si en realidad estuvieras equivocado? ¿O tal vez ninguno de ustedes dos está equivocado y ambos esperan que el otro tenga diferentes expectativas de la discusión que en realidad tienen?

Ahora déjame decirte cuál podría ser el caso, ya que esto es a lo que me enfrento con poca frecuencia:

Estoy desarrollando en C y en algún momento incluso me di cuenta de que me resulta agradable leer documentos estándar para especificaciones como lenguajes de programación, por lo que tengo un pasatiempo para aprender el lenguaje por sus definiciones. Algunos de ellos son útiles. Algunos de ellos son sólo para casos específicos. Algunos de ellos son simplemente estúpidos, pero siguen siendo partes que, estrictamente hablando, definen el idioma. Especialmente, las reglas diseñadas para casos especiales generalmente son simplemente solucionadas por los compiladores para que nadie tenga que preocuparse por eso. Pero el hecho de que su compilador funcione en torno a la posible falta de conocimiento de los usuarios no significa que sea correcto, solo porque funciona.

Realmente me gusta ilustrar a otros con mis esfuerzos que pongo en aprender C conforme a ISO/IEC como sea posible y es divertido para mí hacerlo. A veces, cuando reviso el código de otros, les notifico que algo no se ajusta estrictamente a C. Y aquí generalmente surgieron 2 situaciones, una de ellas realmente disfruto, mientras que la otra situación fue ¹ un poco desagradable para mí.

Así que la primera opción que suele pasar:

• la otra persona comenzó a preguntar sobre el impacto y las razones por las que esto debería estar mal, y surgió una discusión donde ambos terminamos los argumentos con un punto en el que yo estaba satisfecho de haber podido decir, el código es así nada diferente de lo que yo había hecho, pero es uno de los ajustes desagradables de bordercase que en otras ocasiones podría invalidar el código y la otra persona agradece la charla y mi esfuerzo para mejorar su conocimiento.

y el segundo es:

• La persona se siente ofendida, simplemente comienza a defenderse pidiéndome una prueba de que está equivocada, ya que lo que hace es trabajar y hacer el trabajo. Si bien aquí podría probarlo fácilmente, simplemente me retracto, ya que no es mi intención exponerlos por estar equivocados y lo que tuve que aprender como se señaló anteriormente, en esa situación ya no hay posibilidad de explicar "Oye, solo estoy intentando para ayudar", ya que sería una excusa para exponerlos de todos modos.

Tal vez simplemente no está en el punto en que había aprendido todavía, que a algunas personas simplemente no les gusta mejorar su conocimiento en ocasiones espontáneas. Y siendo dejado de lado eres o no eres una de esas personas, recuerda que si fuera conmigo con quien estuvieras hablando, hubiera sido un gesto amistoso y sin ofender en absoluto.

También, especialmente su ejemplo sobre el espacio omitido entre el operador igual y los operandos, me hace sentir un poco ofendido, pero estoy seguro de que no tenía malas intenciones aquí.

Por ejemplo, nunca había visto a nadie que se defendiera de mi consejo de colocar un espacio allí, e incluso si seguían omitiéndolo, lo modificaba cada vez que tenía que revisar su código (¡y eso tampoco es broma!).

Aquí quiero añadir otro ejemplo:

Estoy trabajando en una pequeña empresa nueva que en realidad está creciendo en tamaño. Obviamente, al principio no había políticas de codificación. Nuestro CEO hace algunos meses me encargó la creación de dichas políticas, ya que soy especialmente consciente de las expresiones reservadas, los signos y las palabras clave del lenguaje C. Así que lo hice, lo presenté y fue aprobado. Pero, sin embargo, a nadie le importa, y nuestro CEO no se molesta en hacerlo cumplir, aunque todavía tenía sus razones para encomendarme y aprobar mi diseño, no hay mucho que pueda hacer al respecto, excepto recordárselo a otros. . Así que, por supuesto, podría levantarme y decir " ¡Escuchen, muchachos! ¿Conocen las políticas que diseñé? Espero que las respeten estrictamente de ahora en adelante y corregiré su código para que se ajuste a él si aún no les importa".". Nuestro CEO probablemente incluso apoyaría ese movimiento, pero... Vamos, ¿qué idiota me vería para mi futuro en esa empresa? Así que sigo recordándolos si veo que rompen la política en pero no es mi trabajo imponerlo, así que aunque me duele un poco ver que mi propio trabajo no es respetado de esa manera, no hay mucho que pueda hacer contra eso, excepto siendo el tipo quisquilloso que de vez en cuando reprende "por no respetar sus supuestas políticas".

Así que esa pequeña historia de mi actitud de todo el día para ayudarlo a comprender mejor su punto y por qué podría estar actuando como actúa.

TL y DR:

Entonces, ¿Cuál es la conclusión?

Le aconsejo que trate de comprender sus motivaciones, teniendo en cuenta mi visión de las situaciones que me sucedieron en mi vida laboral.

La forma en que escribió el OP es de una manera que le permite aparecer, ya que asume que lo está haciendo con intenciones malas/egoístas.

Pero para resolver su problema, primero debe intentar averiguar si ese es realmente el caso. Si te dice la próxima vez que te equivocas, pregúntale cómo resolvería esto de una mejor manera, trata de entender sus preocupaciones y probablemente verás, si realmente solo quiere demostrar su superioridad o quiere hacer intercambio profesional.

Si este último es el caso, supongo que cambiará tu opinión sobre él de todos modos.

Y si el primero debería ser el caso ... Bueno, no tengo nada que agregar lo que ninguna de las otras respuestas ya aconsejó.

¹ y realmente pasé momentos difíciles para aprender a manejar esa situación, y aunque siento que lo estoy haciendo bastante bien, todavía me siento inseguro cuando esto sucede.

A veces, los nuevos empleados tienen muy buenas ideas. Y a veces solo quieren que todos comiencen a trabajar repentinamente de la manera que mejor les funcione.

No importa cuán buenas o malas sean sus ideas, esto puede ser muy disruptivo. Y, como ves, puede ser extremadamente desmoralizador para los demás.

Usted o su gerente deben hablar con esta persona y explicarle que es el nuevo y que todos tienen trabajo que hacer. Si bien aprecia su entusiasmo y está interesado en sugerencias para mejorar sus procesos, estilo de codificación, etc., es demasiado y demasiado disruptivo.

Si tiene un estilo de codificación escrito y no lo está siguiendo, está equivocado. Pero si no tiene un estilo de codificación escrito o está siguiendo el estilo escrito actual, entonces tiene razón. Nadie debería ser quisquilloso con el estilo. Si quieren escribir un documento de estilo para que el equipo lo considere, está bien. Si quieren escribir un correo electrónico sugiriendo que una opción de estilo es mejor que otra, está bien. Pero si no tienes reglas de estilo, entonces no las tienes. No pueden hacer cumplir una regla inexistente.

Es posible que obtenga una serie de excelentes sugerencias de este nuevo empleado. Pero no puede ser todo a la vez y no puede hacerse de manera negativa.

Con suerte, la empresa lo valorará lo suficiente como para que su gerente logre bajar el tono si usted no puede hacerlo. Desafortunadamente, mis experiencias con personas que quieren cambiar todo y criticar a todos no han sido buenas. Esto es especialmente cierto para las personas con experiencia limitada. Es posible que tengan que perder uno o dos trabajos para saber que la empresa para la que trabajan no funcionará de la manera que ellos personalmente prefieren.

Parece que los quisquillosos de este compañero de trabajo son de la variedad "espacios o pestañas", donde, en su mayor parte, sus preferencias son principalmente cosméticas, en lugar de una cuestión de mantenimiento a largo plazo.

Mi regla general es a menudo: ¿es necesaria esta decisión de estilo para garantizar que la refactorización de buscar y reemplazar funcione con un clic de un botón, y este bloque de código, y el estilo en el que está escrito, dependen en gran medida de múltiples segmentos de la base de código? Si respondió "sí" a ambas preguntas, entonces las preocupaciones de sus compañeros de trabajo pueden ser bastante válidas. De lo contrario, y especialmente si los quisquillosos se interponen en el camino de proporcionar valor real, debe informar sin ambigüedades al compañero de trabajo que sus preferencias están frenando el progreso y que deben guardarse sus preferencias si no pasan una métrica básica. Con suerte, un estándar establecido puede evitar que situaciones como estas vuelvan a surgir, o al menos con la frecuencia molesta que ha descrito.

Sin embargo, como Paparazzi dijo claramente, cualquier problema persistente con un compañero de trabajo que no pueda resolver usted mismo debe consultar a su gerente. Ese es su trabajo.

¿Has considerado la posibilidad de que tu compañero de trabajo pueda tener puntos válidos?

Me voy a centrar en: "... hasta si poner espacios entre un signo igual y una asignación variable (no bromeo)".

En mis años como desarrollador, he criticado a otros por:

• Uso inconsistente del espaciado.
• Usar espacios para sangrar en lugar de tabulaciones.
• CAPITALIZACIÓN de nombres de variables.
• Nombres de funciones mal escritos.

Todos estos son problemas completamente cosméticos. He aquí por qué creo que son importantes:

• Cuando un archivo es editado por una persona, luego por una segunda, de vuelta a la primera, etc., el sistema de control de fuente recopila las "diferencias" entre los archivos. Si los dos desarrolladores no están de acuerdo sobre cómo usar los espacios en blanco, estas diferencias estarán llenas de cambios de espacios en blanco sin sentido, lo que dificultará encontrar los cambios reales. Cada equipo debe decidir las reglas sobre cómo usar los espacios en blanco y cumplirlas.
• En Java, la convención es usar ALL_CAPS para variables constantes (finales estáticas) de nivel de clase y camelCase para otras variables y funciones. La mayoría de los otros idiomas tienen convenciones similares. Si usa mayúsculas no estándar, las personas pueden confundirse con el uso de la variable y asumir que una variable es estática final, cuando no lo es. Esto puede conducir a errores sutiles.
• Una vez escribí una función que se suponía que anularía una función en una superclase, pero el otro programador usó una ortografía inexplicable, por lo que mi nueva función era solo una función nueva, no una anulación (esto fue antes de que @Override fuera común). Error muy sutil cuya corrección llevó mucho tiempo e involucró muchas palabrotas.

Todavía eres un programador nuevo y tu compañero de trabajo es más nuevo. Pero es posible que haya aprendido buenos hábitos de un profesor con mucha experiencia, alguien que ha pasado por problemas causados ​​por problemas "cosméticos" y que entiende lo importantes que pueden ser.

Por otro lado, queda la posibilidad de que tu compañero de trabajo simplemente no tenga la razón. Lo que estás describiendo suena como un tipo de " mansplaining ": un hombre criticará a una mujer por cosas triviales no porque realmente piense que ella está equivocada, sino por la necesidad de dominarla. Lamentablemente, este tipo de cosas es común en la industria tecnológica. Si esta es tu situación, las formas de lidiar con ella podrían ser un poco más complicadas. Buscar ayuda de compañeros de trabajo o de la gerencia puede ser inútil, ya que otros hombres a menudo tienden a hacer la vista gorda ante tal comportamiento.

Lo que recomiendo: No ignores las críticas. En cualquier caso, eso no ayudará en el asunto. Comprometerse. Si la crítica es sobre el espaciado o algún otro aspecto del estilo de codificación, busque o genere una guía de estilo de codificación. Cada equipo de desarrolladores debería tener uno. (Sonarqube ofrece verificaciones automatizadas de estilo de codificación que son muy buenas, incluso si no estoy de acuerdo en dónde colocan llaves abiertas).

Si su código se ajusta a la guía de estilo, entonces cualquier quisquilloso en esos puntos puede rechazarse señalando la guía. (Sin una guía escrita , la crítica puede vacilar tanto que no puede ganar). Aprender a apegarse a las convenciones de uso de mayúsculas puede llevar tiempo, pero vale la pena. Si tiene dificultad para deletrear (algunas personas muy inteligentes tienen problemas para deletrear), la práctica le ayudará.

Si cree que el problema es más del tipo "mansplaining", entonces le recomendaría buscar (en casa, en su computadora personal) artículos sobre cómo lidiar con mansplaining. Hay muchas mujeres en la industria del software que han existido durante mucho tiempo y que tienen consejos muy útiles. No soy uno de ellos, así que probablemente no pueda ser de mucha ayuda.

Hay diferentes prácticas de codificación, y no es cierto que alguien con un mes de XP no pueda corregir a alguien con 18 meses de XP, pero la cuestión es que podría mencionar estas cosas en la sesión cuando usted u otros codificadores están hablando de codificación. estilos, tenemos una sesión en la que algunos miembros senior nos informan sobre las mejores prácticas y los jóvenes también participan en eso, a veces con buenos puntos válidos, debe sugerirle que traiga estas cosas en dicha sesión para que casi todos puedan dar su opinión sobre esto, en lugar de elegir esto de vez en cuando, ya que se vuelve irritante responder y explicar cada cosa tonta durante el desarrollo.

Hable con él y dígale que mencione sus ideas de mejores prácticas durante dicha sesión en lugar de criticar los detalles, al menos no se sentirá completamente ignorado (si acertó en algo).

Una contramedida eficiente es mejorar su propio trabajo lo suficiente como para que no pueda encontrar suficientes problemas reales para continuar.

Esto no lo detendrá, lo entiendo. Pero, aún tratando de verter las críticas a cántaros, comenzará a cometer errores y se volverá vulnerable.

Entonces debería poder demostrar (en público, con todos escuchando) que esta u otra crítica es infundada y en realidad muestra la incompetencia del crítico mismo. Una o dos de esas pérdidas en público deberían hacerlo mucho más tranquilo.

Además, verifique si el trabajo del compañero de trabajo es realmente impecable. Muy a menudo, estas personas establecen requisitos diferentes y mucho más relajados para sí mismos. Encontrar y discutir abiertamente algún problema técnico de tu parte puede funcionar mucho mejor que intentar defenderte de las críticas.

PD: no intentes responder con sarcasmo, esto puede volverse en tu contra con relativa facilidad.

Tu pregunta

Me pregunto si alguien tiene un consejo sobre cómo manejar a un compañero de trabajo (con aproximadamente 1 mes de experiencia en mi lugar de trabajo en comparación con mis 18 meses) que aprovecha cada oportunidad posible para criticar insistentemente mi trabajo en cada paso del proceso.

Luego sigues diciendo

Este es el trabajo de mis sueños. Durante los últimos 17 meses antes de que comenzara, me despertaba todos los días emocionado de ir a trabajar. Ahora ya es bastante malo que esté considerando seriamente dejar de fumar.

¿Quizás lo que busca no es tanto una forma de tratar con su compañero de trabajo como disfrutar de nuevo del trabajo de sus sueños? Tal vez no. De cualquier manera, hay dos opciones:

1. pueden cambiar algo
2. puedes cambiar algo
3. Ninguna de las anteriores

1. ¿Pueden cambiar algo?

Hablando objetivamente, a las personas les cuesta mucho cambiar, independientemente de lo bien informadas que estén. Piense en cuántas personas dejan de fumar porque su médico les advierte sobre el cáncer de pulmón, y esa es una situación en la que potencialmente podrían morir . Piénsalo. Alguien les está diciendo que podrían morir si no cambian, y aún así no lo hacen.

Entonces, ¿cuáles son las posibilidades de que su compañero de trabajo cambie solo para su beneficio?

Incluso si fueran a cambiar por tu bien, no hay una forma clara de que puedas forzar ese cambio en ellos.

2. ¿Puedes cambiar algo?

A mi modo de ver, ya has probado lo que yo llamaría la opción realista (diciéndole por qué está objetivamente equivocado). Hay dos opciones más (que puedo ver) y ambas son igualmente válidas.

Tu: El pesimista

Asumiendo que tu compañero de trabajo no cambia, y no cambiará nunca , y tú no cambias de trabajo: ¿Es posible que mantengas este trabajo, que se convierta nuevamente en el trabajo de tus sueños, independientemente de tu colega? Si la respuesta es sí y ve un camino claro hacia eso, siga ese camino sin descanso. Si no puede ver la ruta, eche un vistazo al párrafo a continuación y vea si eso ayuda. Si la respuesta es absolutamente no , piensa en dejarlo. Te lo prometo, hay más de un trabajo soñado. A veces tenemos que dejar ir las cosas buenas de nuestra vida y esperar encontrar algo aún mejor.

Tu: El optimista

¿Has probado a estar de acuerdo con él? Independientemente de si estás de acuerdo o no. Por un momento, entra en su mundo donde asumes que realmente estás equivocado. Quédese allí y señale las cosas que cree que se perdió. Ejemplo:

Él: "Olvidaste poner un espacio aquí"

Tú: "¿Sabes qué? Tienes razón. Y olvidé hacerlo aquí también. Gracias. ¿Puedes hacer una revisión del código de este parche para ver si hay más opciones estilísticas que podría mejorar?"

Lo que esto hace es absolverte de cualquier responsabilidad de tratar con él. Lidiar con él no es tu trabajo. Tu trabajo es escribir código y ser lo mejor que puedas en él.

Después de todo, para citarte:

Sin embargo, como la mayoría de los codificadores, si alguien observa mi trabajo con suficiente atención, por supuesto que se pueden hacer críticas constructivas. Normalmente disfruto el intercambio/revisión de código y lo veo como una oportunidad de aprendizaje productiva.

Disfrutas de la revisión del intercambio de códigos . Lo ves como una oportunidad de aprendizaje . Aproveche esta oportunidad para aprender de él, aunque sea objetivamente incorrecto. No lo tome a ciegas, haga preguntas como

Ah, OK. Veo que has señalado esto varias veces en mi código. ¿Dónde puedo leer más sobre esto?

Este le devuelve el balón. ¿Puede respaldar sus críticas con hechos reales/mejores prácticas? ¿Puede ser un compañero de trabajo útil? Ser útil significa superar las críticas y ayudar a tu compañero de trabajo a mejorar.

3. Nada cambia

Asumamos que él no cambia y tú no cambias, en términos de tus interacciones. Rebobinemos un poco en tu pregunta:

Hay evidencia objetiva de que soy, de hecho, bueno en mi trabajo. Esta semana recibí un aumento de sueldo del 18%. Cada revisión de desempeño que he recibido ha sido estelar, y la gerencia me sugiere con frecuencia para roles de liderazgo.

Entonces eres bueno en tu trabajo y reconoces que hay espacio para mejorar. Sus superiores incluso lo sugieren para roles de liderazgo. Si de hecho lo ves como un quisquilloso y crees que sus sugerencias no son importantes, ¿por qué te afecta hasta el punto de que no disfrutas del trabajo de tus sueños? Después de todo, eres objetivamente bueno en tu trabajo. Hay una desconexión aquí. O lo que está diciendo no es válido, y no deberías preocuparte por eso, incluso si te molesta al respecto. O lo que está diciendo es cierto además de que eres bueno en tu trabajo, en cuyo caso deberías preocuparte por ello.

Buena suerte, espero que encuentres la alegría de volver a trabajar. Todo el mundo merece tener eso :)

Editar: no relacionado pero importante: los pequeños detalles del tipo "espacios frente a pestañas" deben ser atendidos por un bot de cordura/anzuelos previos a la confirmación que revisan sus confirmaciones incluso antes de que se hagan públicas. Mire los ganchos de confirmación previa de git aquí . Sugiera que su equipo haga uno para verificaciones de estilo, porque la automatización supera a los desarrolladores que expresan opiniones sobre el estilo.

Sé que esto ya tiene muchas respuestas y aunque la respuesta de Zaibais toca esto, quería agregar una breve sugerencia que funcionó para mí (y EN mí) en el pasado.

Algunas personas tienen dificultades para guardarse sus "buenas ideas". Sé que muchas personas no entienden por qué me opongo cuando las personas separan sus variables de sus asignaciones con tabulaciones para que puedan hacer una lista bonita, todas alineadas en la misma tabulación. Si quieres dejar de ser quisquilloso, solo escúchame y entiéndeme. No me importa mucho si sigues haciendo lo que haces (he trabajado en esto), pero no puedo evitar tratar de ayudarte si veo una forma en que puedes hacer las cosas mejor. No te dejaré andar con espinacas en los dientes después del almuerzo; Diré algo.

¿Ha tratado de fingir que no es una crítica y que es solo una sugerencia útil? A veces, si dices "Oh, ¿por qué crees que eso es importante/debería hacerse de esa manera?" puede convertir la crítica en una discusión donde puede demostrar que sabe lo que hace y tiene razones para hacer las cosas de la manera en que las hace. Cuando empiezas a discutir y escuchar, te conectas. Las personas que no son sociópatas tienen más dificultades para derribar a las personas con las que tienen una conexión. Quién sabe, podrían ser el yin de tu yang y el equipo estará mejor si ustedes se equilibran entre sí.

Esto puede ser demasiado difícil para ti dependiendo de lo tensa que esté la situación, pero he dado la vuelta a una situación similar enviando un correo electrónico simplemente apreciando una buena calidad de la persona. "Sharon, realmente aprecio que hables cuando ves algo que crees que podría hacerse mejor. Puede que no siempre esté de acuerdo contigo, pero respeto que estés constantemente cuidando al equipo". O algo así: tiene que ser sincero, lo que lo hace difícil si tienes muchos malos sentimientos hacia alguien.

He estado en la industria por un tiempo. Así es como funcionan algunos desarrolladores.

La próxima vez dile que estás muy ocupado y que debe escribir una carta y que la leerás cuando tengas tiempo. Eventualmente recibirá el mensaje.

Voy a abordar esto desde un enfoque un poco diferente.

La falla está en el hecho de que ustedes (dos) están siendo malos desarrolladores de equipos. No hay un yo en el equipo, y si bien este tipo puede estar actuando de manera incorrecta, tiene 100% razón en el hecho de que estas decisiones son "a nivel de equipo" y debe tener alguna participación en ellas.

opciones de paquetes de software hasta poner espacios entre un signo igual y una asignación variable (no bromeo).

Linting su código es importante. espacio o no espacio es una cuestión seria de estilo de código que fallará en algunas métricas. La mejor respuesta aquí es tener una guía de estilo que pueda señalar que diga no poner espacios o poner espacios. Si lo haces de una manera algunas veces y de otras maneras otras veces. Entonces eres un "mal desarrollador" y tiene todo el derecho de criticarte. Lo más probable es que a ti te gusten los espacios y a él no (o al revés). Tener una guía de estilo soluciona esto en unos 30 segundos. Por supuesto que tienes que apegarte a él, y eso puede ser una mierda mientras te adaptas. Casi todos los lenguajes de programación que he visto tienen una guía de estilo que simplemente puedes "usar". La mayoría, si no todos, vienen con herramientas para ayudarlo a hacer cumplir esa guía.

Lo mismo con los paquetes (más bien paquetes de código o cadena de herramientas), debe haber un buen conjunto predefinido de lo que está bien. Cuando necesite algo que no esté en la "lista aprobada", entonces es hora de una reunión de equipo. EL EQUIPO debe elegir qué herramientas se utilizan en todo el equipo. No vas al azar en una dirección mientras tu compañero de equipo va en otra.

La versión corta es que ambos están equivocados. No debería ser tan insistente y deberías incluirlo en estas decisiones. Deberías estar hablando de estas cosas antes de que él tenga la oportunidad de criticarlas. Ahora estás en un equipo y necesitas actuar como tal. Tal vez por tu experiencia eres el QB. Pero no llegarás a ningún lado si tu línea hace una jugada mientras tú haces otra. Hablen, comuníquense, trabajen juntos y DEJEN de tomar decisiones a nivel de equipo por su cuenta.