¿Cómo manejar a un desarrollador que se pone a la defensiva cuando se enfrenta a romper el código?

"Oye, hiciste este cambio X a esa función Y. Este cambio rompe mi código porque no tiene en cuenta Z, y Z es lo que sucede de mi lado. ¿Te parece bien que hagas K para arreglarlo?"

Necesitas hacer esto menos personal. No hay mi código y tu código . Ambos son empleados de una empresa, y esa empresa posee el código. Usted simplemente lo escribió, pero pasó la propiedad intelectual a su empleador. Asumir la propiedad es importante, pero no hable de eso de esta manera.

En su lugar, piense en todo el código como nuestro código y expréselo así. O déjalo fuera. Cuando no te enfocas en lo que hicieron, sino en cuál es el estado actual, se sentirá mucho menos como un ataque personal.

Como resultado del cambio de X a Y, esta otra funcionalidad se rompió. Le eché un vistazo y vi que también tenemos que pensar en Z.

A continuación, puede ver lo que dicen. Pueden responder con algo como "muéstrame" o "adelante y arréglalo" o "oh, no pensé en eso" y se ofrecen a arreglarlo ellos mismos.

Sin embargo, idealmente no importa quién solucione el problema. Es importante que haya un diálogo y que todos trabajen juntos para hacer que el producto en general sea estable y funcional. Tener solo una persona responsable de una parte particular del producto es peligroso en sí mismo, y este tipo de situación es una oportunidad tan buena como cualquier otra para asegurarse de que todos conozcan las otras partes del producto.

En una nota más técnica, parece que realmente desea pruebas unitarias u otra forma de prueba automatizada para al menos esa pieza de software en particular. Si hay una infraestructura general que los ejecute y muestre los resultados, será evidente si algo (¡no alguien (!), aunque por supuesto lo hay git blame) rompió las pruebas. Están allí como una red de seguridad y para que todos se den cuenta si algo sale mal.

Un beneficio adicional de tener pruebas unitarias para piezas críticas del sistema es que realmente no necesita ir y señalar que las cosas están rotas. Ya no hay policía de código . Si la cadena de herramientas se encarga de eso, nadie está dando malas noticias y hay menos malas vibraciones en el equipo, ya que hay menos espacio para discutir.

Por otro lado, también viene con la necesidad de actualizar las pruebas. Discutir los pros y los contras de eso está fuera del alcance aquí.

Lo primero es lo primero: no es inusual que el código de dependencia rompa el código descendente. Existen prácticas de desarrollo que pueden mitigar esto, como una buena especificación, documentación y pruebas. Pero esa no es la respuesta a tu pregunta.

Oye, hiciste este cambio X a esa función Y. Este cambio rompe mi código porque no tiene en cuenta Z, y Z es lo que sucede de mi lado. ¿Te parece bien hacer K para arreglarlo?

Lo que dices puede parecer una acusación, esencialmente estás diciendo "rompiste mi código", y esto pondrá a la gente a la defensiva.

Una mejor manera es mantener esto menos "rompiste mi código" y más "te importaría echar otro vistazo a X? Creo que necesita hacer K para trabajar con Z".

Por otra parte, si esta persona es un gruñón sin importar cómo te acerques a ella, debes informarle a tu jefe que tu trabajo se está retrasando por tener que arreglar el trabajo del gruñón. Nuevamente, no señale con el dedo, pero déjelo como "el trabajo en Z se retrasó por los cambios en X y necesitaba hacer K primero".

Esta es en realidad una gran oportunidad disfrazada. La mayoría de los ingenieros no aprecian lo enorme que es esto para un empleador actual o un posible empleador. A la par de las habilidades técnicas está su capacidad para colaborar con las personas, aceptar la responsabilidad por los errores, trabajar con otros a través de los suyos propios y defender sus ideas con tacto. El consenso común es que esto se demuestra mejor cuando se entrevista compartiendo una historia anecdótica. por lo general, las personas improvisan tales historias en retrospectiva, pero podría ser muy estratégico y darse cuenta de que tiene la oportunidad de escribir una gran historia aquí mismo que respondería preguntas como "¿cómo maneja los conflictos" y probablemente abra oportunidades sorprendentes en su empleador actual? .

Algo a considerar entonces son tus tácticas vs estrategia .

Táctica

Sus tácticas son los sistemas y acciones que elige para ayudar con su problema. Entonces, por ejemplo, elegir una mejor redacción que sea menos personal, elegir el momento adecuado, tener en cuenta a la audiencia/los transeúntes, ayudar a la persona a la que te diriges a salvar las apariencias o usar pruebas automáticas para detectar el error. Pasa tiempo aprendiendo y practicando buenas tácticas. Esta será su caja de herramientas que puede aprovechar para su estrategia.

estrategia

El problema al que te enfrentas es sintomático de un problema aún mayor: a esta persona realmente no le gustas. Eso es lo que estratégicamente quieres arreglar.

En el lugar de trabajo, especialmente en un equipo, está más allá de su control que tenga una relación personal con cada uno de sus compañeros de equipo. Tal vez no le gustes a alguien y no te gusten ellos, qué lástima, te ves obligado a tener una relación por estar en un equipo. Es su elección si esas relaciones son buenas o malas. Puedes elegir poner esfuerzo en otras personas o no. El verdadero crecimiento profesional se produce cuando va más allá de pensar en sí mismo como un simple descifrador de códigos (lo que lleva a problemas de arrogancia del código), sino como un miembro funcional de un equipo, y quiere demostrar que, con usted en un equipo, ese equipo es mayor que la suma de sus partes. Eso significa una gran conciencia relacional.

La decisión estratégica es preguntarse cómo quiere que sea esa relación. ¿Es posible? ¿Qué falta o qué desafíos podrían dificultar la relación? ¿Qué necesitas hacer para que eso suceda? Por ejemplo, muchos problemas de relación se reducen a la confianza. Entonces, una estrategia sería mostrarle a este desarrollador que estás pensando en sus intereses y no solo en los tuyos, y llevar tu relación al punto en que esta persona confíe en ti. No seas un estoico sabelotodo, eso no pone a la gente de tu lado aunque tengas razón y estés justificado. La estrategia es darse cuenta de que quiere que la gente esté de su lado y pensar cómo sucede eso. Qué funciona y qué no. También es importante darse cuenta de que una estrategia exitosa a menudo requiere paciencia.

Lo bueno de esto es que, si desarrolla una relación realmente sólida con este desarrollador senior, las tácticas que lo llevaron allí se vuelven mucho menos necesarias y es más fácil ser más eficiente y exitoso en su trabajo. Una buena estrategia puede llevarte a una buena relación, y con una buena relación te resultará mucho más fácil lograr tus objetivos. Así que piensa en trabajar en tu relación con esta persona cuando no haya ningún problema, y ​​eso hará que sea más fácil cuando surjan problemas como este.

¿Cómo debo comunicarle que vengo con buenos medios, pero también le hago entender (y aceptar) que él es quien debe hacer los cambios necesarios para arreglar el código/módulo roto?

Será mejor que se asegure de que su jefe/equipo esté de acuerdo en que así es como debe manejarse. Idealmente, en un entorno de codificación, hay algún tipo de sistema de prueba automatizado, por lo que si el código que se intenta verificar se rompe, se rechaza hasta que se soluciona. Por lo general, esto lo hace la persona que lo cambió. Todos deben enorgullecerse de su trabajo, que viene con un nivel de responsabilidad de querer arreglar las cosas que se rompen.

Su jefe puede sentir que es una pérdida de tiempo que los desarrolladores senior corrijan cada pequeño error que introducen en el sistema. Piensan que esa tarea se deja para los desarrolladores junior; No estoy de acuerdo con esto. Tienes que averiguar cómo se supone que funciona esto.

Mi enfoque para este tipo de problema es garantizar que haya suficiente metodología y herramientas para que el problema sea técnico y no personal.

Por ejemplo, asegúrese de tener compilaciones automatizadas y pruebas de humo. Si estos se rompen, tenga la regla de que el que rompe debe proporcionar comida en la próxima reunión del equipo.

A veces, las personas desafiarán audazmente el statu quo en una búsqueda egoísta del progreso personal. En cierto modo, esto es normal. Es empresarial en el mejor de los casos. El individuo avanza en un marco que se lo permite. Entonces, cambia el marco. Ese tipo de personas no se frustrarán, progresarán de diferentes maneras. Entonces, como gerente, su objetivo es aprovechar ese espíritu y dirigirlo de una manera que sea positiva para el equipo y los objetivos.

Parte de esa estrategia de aprovechar la voluntad es asegurarse de que las personas aún sientan un sentido de propiedad. La respuesta más popular aquí hasta el momento aboga por una filosofía de renuncia a la propiedad. Creo que esto puede ser contraproducente. Deje que las personas se apropien apasionadamente de su área. Pero asegúrate de que no traspasen las de los demás.

Esta pregunta probablemente depende en gran medida de la cultura de la empresa.

Hay empresas en las que "no se cometen errores". O más bien, no se le permite hablar de ellos, y un gerente que se entera de que alguien cometió un error, "observará a esa persona de cerca".

En esa situación, revela el problema a esa persona personalmente de manera que el gerente solo se entera si es absolutamente necesario, diciéndole exactamente lo que quiere que haga o arregle, después de que haya intentado solucionarlo usted mismo. (Ofc. también debes correr, banderas rojas yada yada). También debes decirles que es entre tú y ellos y que eres genial.

En cualquier empresa en funcionamiento, debe asegurarse de que su divulgación no suene como una acusación.

Aún debe asegurarse de decirles exactamente lo que quiere de ellos y por qué no puede hacerlo usted mismo (porque si puede arreglarlo, entonces por qué se queja, arréglelo rápidamente y siga adelante, no lo hicieron). No lo hacen para crear trabajo para ti, tuvieron que solucionar su propio problema).

También asegúrese de que su gerente o líder del proyecto esté al tanto y haya dado su aprobación para que lo arreglen.

No pueden decidir qué hacer con su propio tiempo y obtener el trabajo asignado por su gerente/líder de proyecto.

Llegar y hablar sobre un error en un ticket que debería estar hecho ahora, sin hacer esas cosas antes de eso y abordarlas directamente creará estrés y la impresión de que desea que trabajen a tiempo cuando están asignados a otra cosa. o en su tiempo libre.

La mayoría de los conflictos o problemas con las personas se deben a problemas subyacentes del proceso. Ese es ciertamente el caso aquí.

Usted, sus colegas, su empresa y, lo que es peor, sus clientes finales son todos víctimas de procesos fallidos que deberían implementarse para administrar la calidad y la integridad de su código combinado.

Pensar y actuar desde esa perspectiva es clave para resolver los problemas de calidad subyacentes que condujeron directamente a los problemas que está experimentando. También es la clave para encontrar puntos en común con sus colegas (p. ej., le resultará fácil ponerse de acuerdo sobre los problemas del proceso que le causan todo el dolor).

Si bien es probable que solo quiera hacer el trabajo y progresar en su carrera, si se percibe que busca superar a los compañeros de trabajo más experimentados, dañará su relación laboral con aquellos que están mejor posicionados para ayudarlo. .

Mi consejo sería proponer una solución, ya sea en detalle (como una solicitud de extracción, por ejemplo) o un resumen del enfoque general que propondría como solución. Llévale esto a la persona cuyo código consideres roto y pídele su opinión. Y lo más importante escuchar la respuesta .

Esto le presenta al compañero de trabajo, a quien quizás acaba de interrumpir, una solución, en lugar de un problema y, por lo tanto, trabajo adicional. Es probable que no solo aprenda algo de la respuesta que obtenga, sino que también se lo verá como alguien útil y que trabaja en equipo.

Como otros han sugerido, debe despersonalizar esto. Debería haber una propiedad colectiva del código. Menos de "¡rompiste mis cambios!" y más como "¿cómo podemos hacer que ambos cambios funcionen bien juntos?"

También es posible que desee considerar si hay margen para mejorar la comunicación durante las reuniones diarias (si las tiene, o sugiera presentarlas si no), de modo que, en general, haya más conciencia de en qué está trabajando la gente y, por lo tanto, menos posibilidad de conflicto o rompiendo cambios.

Proporcionar el nivel adecuado de detalle en las standups es complicado, pero si sus colegas no conocen el área amplia del código en el que está trabajando, es posible que desee considerar brindar un poco más de detalle.

Algo más a tener en cuenta: como desarrollador más joven pero con menos experiencia, es muy posible que pueda codificar más rápido que sus colegas más experimentados (¡un cerebro más joven y más agudo es una ventaja real a veces!), sin embargo, también debe reconocer que sus colegas de mayor rango tienen la ventaja con la experiencia y pueden ser más considerados en su enfoque, en función de sus años de experiencia. De hecho, la mayoría de los proyectos de desarrollo se parecen más a maratones que a carreras de 100 metros. Los mejores equipos se basan en todos los niveles de experiencia.

¿Cómo debo comunicarle que vengo con buenas intenciones, pero también hacerle entender (y aceptar) que él es quien debe hacer los cambios necesarios para arreglar el código/módulo roto?

Estoy de acuerdo con mucho de lo que ya se ha dicho. Diferentes personas interpretan el mismo mensaje de diferentes maneras, y lo que una persona percibe como una comunicación completamente normal y efectiva, otra persona lo encuentra irritante o intimidante, por las razones que sean. Es probable que esa persona esté comunicando (implícitamente) que encuentra desagradable tu estilo. Prueba algo más la próxima vez. Intente cambiar la configuración: atrápelo en la fuente de agua en lugar de en su asiento. Siéntate a su lado antes de comenzar la conversación, en lugar de pararte frente a él. Pruebe diferentes enfoques: use su sentido común.

Y una cosa más que puedo sugerir, trata de equilibrar tu comunicación con él. Si es sensible a que usted le señale sus errores, encuentre oportunidades para felicitarlo (sinceramente) por sus diseños inteligentes o su ejecución efectiva; eso ayuda mucho a la mayoría de las personas.

La forma más fácil de manejarlo es no manejarlo. Deje que el desarrollador discuta con una prueba fallida en su lugar. Pregúnteles cómo se supone que funciona el código y luego cree una prueba a su alrededor. Entrégueles la prueba y dígales que falla.