¿Cómo maneja a los colegas que constantemente le dan resistencia?

Parece que hay una falta de confianza presente en este equipo. Para ser honesto, me parece que los colegas que 'no se resisten' podrían hacerlo por conveniencia ya que, como usted dice, no parece importarles la calidad y simplemente tomarán el camino más fácil. En ese sentido, el colega que 'se resiste' podría estar en desacuerdo con usted, y ustedes dos pueden tener algo en común en el sentido de que se preocupan por la calidad y están dispuestos a estar en desacuerdo el uno con el otro.

La 'crítica constructiva' es un proceso bidireccional; el que critica necesita poder escuchar al que está criticando para averiguar por qué hizo las cosas de esa manera. Sugiero leer los 7 Hábitos de Stephen Covey, particularmente el hábito 5: Buscar primero comprender, luego ser comprendido .

Arreglar la falta de confianza no se puede hacer de la noche a la mañana, pero aquí hay algunos consejos de lo que he descubierto que ha funcionado para los equipos en los que he estado.

Si algunos comentarios se basan en su opinión, deje en claro que este es el caso. Puede que no le guste que haya escrito su código de cierta manera, pero ¿hay algo objetivamente malo en él? En el mejor de los casos, puede sugerir que no lo habría hecho de esa manera y brindar algún razonamiento, pero eso no significa necesariamente que uno de ustedes tenga razón y el otro esté equivocado.

Si algo le parece extraño, pregunte por qué se hizo. Puede haber una razón válida, y puede que solo necesite una variable renombrada o un comentario de código para explicarlo mejor.

Pregunte qué piensan. Si ve algo que cambiaría, en lugar de dictar cómo cree que debería hacerse, diga lo que habría hecho y por qué, y pregúnteles si están de acuerdo.

Incluya comentarios positivos y negativos. Si todo lo que sucede cuando su colega empuja el código es que recibe críticas, entonces no será algo que le guste hacer, y lo abordará con una mentalidad defensiva. ¿Puedes señalar instancias en las que haya hecho algo bien? El simple hecho de reconocer una buena solución puede contribuir en gran medida a construir esa atmósfera de confianza, haciéndole saber que no solo está dispuesto a destrozar su trabajo, sino también a alentarlo y apoyarlo.

No (inadvertidamente o de otra manera) convierta los comentarios de revisión en ataques personales. Cosas como el tono y la elección de palabras pueden determinar cómo se ve un texto. Por ejemplo, compare:

"Esto no tiene sentido".

(es decir, esto es objetivamente incorrecto y eres estúpido)

Con:

"No es así como esperaba que funcionara. ¿Puedes darme un breve razonamiento?"

(es decir, no necesariamente entiendo o estoy de acuerdo con su solución, pero no digo que esté equivocado y estoy dispuesto a escuchar su explicación)

Puedo decirles que después de trabajar así por un tiempo, los equipos realmente se abren y las revisiones de código no se vuelven temibles; se convierten en una buena manera de obtener retroalimentación y para que otros detecten errores que quizás no hayas visto. Cuando alguien me señala que hay una mejor manera de hacer algo, en realidad me emociona implementarlo porque sé que será una mejora en la calidad general del código y porque sé que la persona que da la retroalimentación no es para atacarme personalmente. Espero que pueda cambiar la perspectiva dentro del equipo de estar 'correcto' y 'equivocado' a tener diferencias válidas (y valiosas) en opinión y estilo.

En primer lugar, tenga cuidado con la frase "mantenga altos estándares de codificación y un código hermoso". .

Respecto a las Normas

¿Quién decide cuáles son los estándares? Existen muchos estándares de estilo de código, y la mayoría son igualmente válidos, siempre que uno solo se use de manera consistente dentro de una base de código. Si usted es el propietario del producto, el gerente o el desarrollador senior indiscutible, entonces tal vez tenga la discreción de elegir los estándares, pero debe preestablecerlos en lugar de comenzar a tomar decisiones sobre relaciones públicas. La documentación o los archivos Léame de los proyectos deben dejar claro cuáles son los estándares que se aplican. En general, no es una regla si no está escrita.

Con respecto al 'código hermoso'

Si bien disfruto de un código hermoso, veo una señal de alerta en cualquier revisor que justifique sus comentarios con comentarios como "esto se ve feo" o "Sería más feliz si lo hiciera de otra manera". Si el código es complicado y más difícil de entender de lo necesario, ese puede ser un punto válido cuando puede proporcionar alternativas elegantes.

Pero recuerda que a todo el mundo le gusta tener cierto grado de autonomía en su trabajo. Si cada código que revisa debe hacerse "a su manera", es posible que haya comenzado a creer (inconscientemente) que el código está destinado a complacerlo en lugar de lograr algún objetivo de la empresa y ofrecer alguna función al cliente. Por lo tanto, a menos que sea el propietario de la empresa, tenga en cuenta que "complacerle" no es el objetivo de ningún código. Además, si sus reseñas básicamente arrojan a la basura el trabajo realizado por otras personas, en primer lugar no disfrutarán haciéndolo, sino que más bien dirán "entonces hágalo usted mismo la próxima vez" (y señalo aquí que el objetivo de la el código tampoco es para entretener al codificador). En general, hasta límites razonables y siempre que se cumplan los requisitos,

Habiendo dicho todo eso, y para que quede claro, no parece un revisor irrazonable, pero partes de sus preguntas pueden generar señales de alerta si se extrapolan mucho (lo que estoy haciendo con el propósito de esta respuesta).

Con respecto al ejemplo de Wikipedia

Evite 'corregir' lo que no está mal. Es tan simple como eso. Si cumple con los requisitos, si no infringe ningún estándar escrito/establecido para el código base y si no presenta ningún error o falla de seguridad, entonces no está mal. Si degrada el rendimiento, entonces realmente debería tener métricas de rendimiento claras para mostrar y probar su punto.

Puede, y tal vez debería dar sugerencias, pero como otros mencionaron, debe marcarlas claramente como sugerencias u opiniones para que el autor del PR sepa que tiene la opción de simplemente ignorar su comentario. Trabajé en un proyecto en el que los revisores de código tenían la obligación de asignar una calificación de "relevancia" a cada comentario que hacían. Las calificaciones fueron "críticas" para cosas serias que deben corregirse de inmediato, "regulares" para cosas habituales que necesitan corrección pero tienen un impacto muy bajo, "menores" para cosas como convenciones de nombres que no tienen ningún impacto en la funcionalidad o el rendimiento, pero tenía una corrección obligatoria y finalmente "Información" para cosas que eran solo una idea para una solución alternativa o una opinión.

Si bien la gente generalmente aceptaba esas "sugerencias", el hecho de que se indicaran claramente como opcionales evitó mucho dolor que se produciría en discusiones sin sentido como "esto podría ser un poco mejor, pero también significaría una gran cantidad de reelaboración", "Si Me gustaría adoptar este estándar aquí, entonces hay 134 archivos que también deberían actualizarse", "Tengo una opinión diferente y soy el que está haciendo el código aquí", y así sucesivamente.

Con respecto al ejemplo de variables globales

Por lo que ha escrito, no puedo formar mi propia opinión sobre quién está equivocado o correcto (si es que hay alguno) en ese caso, por lo que asumiré tres casos:

1. SI tiene razón: entonces es posible que necesite comunicarse mejor y tener un punto bien establecido. Necesita enseñarle una lección a la persona, no en el sentido de "venganza", sino en el sentido de "aula". En lugar de pelear por las relaciones públicas, siéntate con él con una computadora cerca y haz una presentación que muestre objetivamente por qué está equivocado. Preferiblemente, escriba un código que demuestre que está equivocado y ejecútelo frente a él. Por ejemplo, si necesita explicar que necesita una operación de copia específica para copiar una lista en Python, luego escriba y ejecute un ejemplo como aquí , no le diga simplemente que "lo que hizo está simplemente mal ".

2. SI se equivoca: Es posible que se dé cuenta de ello durante el ejercicio de preparación de la citada presentación. Esto es genial porque has entendido un poco antes de criticar. Siempre tenga en cuenta que todo el mundo (incluido usted) comete errores. Y hay diferentes niveles de tolerancia hacia diferentes tipos de errores. Si va a afirmar públicamente que alguien está equivocado (ha mencionado relaciones públicas públicas), entonces debe estar muy seguro de que tiene razón. En caso de que no lo seas, una charla personal en la que le pidas a la persona que explique lo que ha hecho quizás sea más que suficiente para que te ilumine (o en el caso anterior, puede que ellos mismos se den cuenta de su error al tratar de explicarlo). .

3. SI ninguno de los dos está equivocado o en lo correcto: entonces están discutiendo asuntos de opinión. Pregúntese: ¿Por qué está discutiendo una cuestión de opinión? Aparentemente, no le gusta intercambiar ideas con este colega en particular, ya que espera que simplemente cumpla con sus sugerencias en lugar de tratar de aprender algo de lo que le responde. ¿Por qué importa si se hizo de la manera que él/ella prefiere en lugar de la forma en que usted prefiere? ¿Realmente tiene un impacto en otras partes del código base? Luego, señale esto, de modo que comparta la información relevante con todo el equipo para pedir una decisión que afecte más que el PR único escrito por su colega. De lo contrario, recuerda como antes no corregir lo que no está mal.

Con respecto a las discusiones públicas de relaciones públicas

Hay un viejo adagio que dice "Alabar en público, criticar en privado". Se supone que los comentarios públicos sobre un PR son documentación, no discusión y mucho menos crítica. Los errores ocurren, y no escribir nada a ningún RP hará que parezca que no estás haciendo ningún trabajo de revisión, por lo que las revisiones de los RP son (a veces) públicas. Pero si te sientes mal por hablar en público, la otra persona también se siente mal, y no sorprende que se ponga a la defensiva. Estás criticando en público. Mi sugerencia es que si algo se complica en la revisión, debe haber escrito sus propias notas y hablar en privado con la persona, ya sea a través de una videollamada con una pantalla compartida o una sala de reuniones, luego revise sus notas, explique su puntos y llegar a acuerdos sobre lo que se debe hacer en el código. Entonces, estos acuerdos se pueden publicar como la revisión de relaciones públicas, pero preferiblemente escríbalos con la otra persona presente y acordando el contenido. Esto evita que la persona se ponga demasiado a la defensiva y separa los puntos de pelea para que sean privados, mientras que los comentarios relevantes/sencillos se pueden incluir en la revisión de relaciones públicas. Esto puede llevar mucho tiempo, pero si tomó nota de los puntos anteriores, todo esto debería valer la pena.

Con respecto a la actitud de "mientras funcione"

Sí, entiendo que esta parte es difícil. Si está en una posición gerencial, tiene mucho más poder para cambiar esta mentalidad. Si no es así, entonces necesita ayuda de la gerencia. Algunas sugerencias que pueden ayudar:

1. Los archivos tienen propietarios. Cree una regla para que cada archivo en el código base tenga un propietario. Si es necesario realizar cambios en un determinado archivo, el propietario lo hará. Si el código se rompió en ese archivo, el propietario lo arreglará. Alguien que no sea el propietario es responsable de revisarlo cada vez, el revisor debe cambiar periódicamente. Eso no significa que el propietario tiene la última palabra sobre cómo funciona el código en ese archivo, pero al menos deja en claro que las cosas mal escritas volverán a la persona que las escribió. Las revisiones siguen siendo importantes para que nadie produzca jeroglíficos para hacerse indescifrable.

2. Buen código significa personas reemplazables. Los gerentes odian tener personas insustituibles. Si el código está demasiado mal escrito hasta el punto de que solo el autor (si lo hay) lo entiende, entonces esto se convierte en una responsabilidad para el código. He oído hablar de casos de bases de código completas que básicamente mueren porque no valía la pena el esfuerzo de mantenerlas. Y esto favorece a los de bajo rendimiento en lugar de a las personas que buscan promociones. Ese es principalmente un argumento para lograr que la administración participe en la mejora de la calidad del código.

3. Considere tener un departamento de control de calidad separado. En algunas empresas (piense en ingeniería mecánica en lugar de codificación), existe un equipo de garantía de calidad cuyo trabajo es verificar el cumplimiento de los requisitos (tanto funcionales/rendimiento como requisitos de calidad y adhesión estándar). Normalmente, estos son tipos que no responden ante un gerente, sino directamente ante un director de operaciones, por lo que no pueden ser silenciados o represaliados por un gerente presionado para cumplir con una fecha límite. No crean las reglas, simplemente las hacen cumplir y verifican si se están siguiendo. Tal vez un escuadrón como este debería estar realizando revisiones en lugar de compañeros.

4. Déjalo ser.Como decía la madre María, cuando te encuentres en un momento de angustia, déjalo ser. Es posible que haya pensado que la sugerencia anterior sería demasiado abrumadora y exagerada para su empresa. Pero aquí está la noticia: tal vez sus estándares o preferencias de código también sean demasiado para su empresa. En muchas empresas, el tiempo para entregar funciones es mucho más crítico que la calidad del código. Tal vez porque si crecen lo suficiente, es posible que se deba volver a trabajar completamente en una solución más escalable, tal vez porque algún problema de rendimiento tiene un impacto muy pequeño en las ganancias y la experiencia del cliente, pero las características adicionales abrirían nuevos mercados y harían que el producto compita contra el super -caliente alternativa cara que domina el segmento. Además, la empresa puede estar teniendo dificultades para contratar desarrolladores, por lo que mantener contentos a los que tienen sin aumentar demasiado los salarios se está convirtiendo en una preocupación relevante. Todas esas son razones por las que muchas nuevas empresas tienen estándares de codificación sorprendentemente bajos, que solo mejorarán una vez que se adquiera la empresa y los nuevos accionistas contraten a algunos adultos para hacer cumplir prácticas de codificación rígidas y sostenibles. E incluso entonces, algunos compañeros tuyos preferirán dejar la empresa por otra en la que programar sea una actividad mucho menos estricta.

Averigüe sus motivaciones y razones y vea si esto es compatible con ellos.

Fundamentalmente, la prioridad de muchos empleados es mantener contento al jefe, especialmente por hoy. Ese es su primer y principal objetivo y es casi seguro que estará en lo más alto para el resto. Sin duda, está en lo más alto de las prioridades.

Si está en una empresa donde las personas son evaluadas principalmente por la cantidad de funciones que produce, no hay razón para que una persona se moleste en solucionar los problemas de calidad del código, ya que la recompensa es por las funciones de envío. Esto es especialmente cierto si hay alguien que lo está molestando por la característica que la quiere en producción.

El hecho de que tal comportamiento sea la norma me dice que es un lugar de trabajo muy orientado a los resultados, hasta el punto de que el desarrollo se trata como una caja negra y mientras los desarrolladores hagan su magia, todos están satisfechos.

A menudo, no hay mucho que pueda hacer, ya que está luchando contra la directiva principal de mantener contenta a la gerencia. He sido ese desarrollador que empujaba el código incorrecto, ya que alguien lo quería rápido y, en mi opinión, rechazarlo era una molestia sin sentido. Aprobé un código incorrecto después de que otro desarrollador intentó evitar que ese mismo código fuera a producción y el desarrollador me pidió que le diera el visto bueno en su lugar. Teniendo en cuenta lo que la gerencia quería y priorizaba, no podrías haber alterado mi comportamiento (podrías alterar mi comportamiento aparente, pero eso solo significaría que estaría en connivencia con los otros desarrolladores para evitarte).

La dirección consideraba que el desarrollador que intentaba evitar el código incorrecto en producción era lento e improductivo.

TL; DR: la calidad del código claramente no es importante para la administración aquí, por lo que probablemente no pueda solucionarlo, ya que a los desarrolladores no les importará.

Responderé a la pregunta general "¿colegas que constantemente le dan resistencia?" y no comentar los ejemplos precisos dados. He tenido la misma situación en el pasado, así que intentaré explicar lo que funcionó para mí. Mis consejos son:

• No te lo tomes personalmente. Su colega probablemente tenga el mismo comportamiento con otras personas.
• No dejes de escribir comentarios si algo está definitivamente mal: un aspecto de las relaciones públicas es que puedes mirar hacia atrás para obtener información más adelante. Si surgen problemas en el futuro y ya los había señalado durante la fase de revisión, entonces no será su problema. Si su colega se negó a corregirlo, ese será su problema.
• No creas que puedes cambiarlo: esta es realmente la personalidad de ciertas personas.
• Si llegas a elegir tus proyectos/tareas: trata de evitarlo. Las discusiones y discusiones no son malas como tales si permiten avanzar. Sin embargo, algunas personas tienden a tratar de imponer su opinión todo el tiempo: la gente no disfruta trabajar con ellos de todos modos y evitará tener que colaborar con ellos.

La mayoría de la gente no es así, no pierdas la esperanza :).

He aquí una idea para ayudar a trabajar en la relación que tiene con este colega.

Siéntense juntos lejos del día a día (cafetería, banco al aire libre/parque), tomen dos notas post-it y dos marcadores Sharpie. Si les das un rotulador y un post-it, usas el otro conjunto. Diga "Quería verificar cómo estamos trabajando tú y yo. Me gustaría que ambos escribiéramos un número de diez sobre qué tan bien creemos que se está desempeñando nuestra relación laboral". Un "10" es "no podría ser mejor, clase mundial, deberíamos escribir un libro", un "5" es "hacemos lo suficiente para salir adelante" y un "1" es "lo único en lo que estamos de acuerdo". on es el logo en nuestro recibo de pago".

Pídales que escriban su número, como usted escribe el suyo. Cuenta 3-2-1 y luego revélalos entre sí simultáneamente. Este momento será bastante cautivador y, a menudo, bastante divertido: la risa les hará bien a ambos. Luego, discuta por qué cada uno usó los números que usó y qué le impidió usar "10". Será importante que usted se haga cargo de su parte del lío para demostrar que reconoce que su relación de trabajo es una creación conjunta y que ambos juegan un papel en lo que está sucediendo entre ustedes.