Dos estrategias

1. socrático . Hable sobre el código con su compañero de trabajo y pídale una explicación sobre las partes confusas. Tienes que "hacerte el tonto" con tacto, que es una habilidad necesaria para un buen codificador de todos modos. Haga preguntas que causen autorrevelación como "¿Es esa una forma rápida de hacer subconsultas?", "¿Cómo realiza un seguimiento de todos estos nombres de variables breves y similares?", "¿Podríamos usar una función de ayuda para reemplazar estos tres ¿repetir partes?", etc. El truco consiste en "engañarlos" haciéndoles creer que tenían la idea de cómo mejorarlo, lo que luego recompensas con declaraciones como "sí, eso sería muy bueno/rápido/claro".

2. humor _ La crítica se puede esconder detrás del sarcasmo y las bromas. Los nombres tontos y las analogías son embrague. "¿Puedes darle a estos vars nombres más significativos? No todos somos Johnny Mnemonic como tú", "¿Tu tecla de tabulación está rota?", "¡Santa repetición, Batman!", etc. Si obviamente estás bromeando, puedes hacerlo más fácilmente. salirse con la suya con la crítica, siempre que sea bastante indirecta. Agregue algo de autodesprecio también, p. ej.: "Oh, odio este tipo de rutinas de adaptador, siempre me hicieron parecer un novato cuando ese anidamiento complicado tenía una excepción no controlada, así que ahora aplano la cola antes de entregarle el devolución de llamada por...". Asegúrese de no probar esto frente a otros trabajadores, eso podría ser intimidante con los aspectos sociales además del forraje entrante.

No importa qué tan suavemente brindes las malas noticias, espera algo a la defensiva y una reacción violenta. Los programadores son inseguros porque todo su trabajo se centra en tomar decisiones, por lo que se exponen cientos o miles de veces en el desarrollo de cualquier aplicación. Sé amable y conciliador y prepárate para ofrecer cosas como "No es el fin del mundo", "He visto cosas peores", etc., si es necesario.

Espera otro error. Según tu historia, sucederá. Luego pídele ayuda, pídele que te explique qué hizo, cómo y por qué, porque no entiendes el error.

Luego, explícale tu opinión y muéstrale lo que crees que debería haber hecho. Hazlo con respeto y no olvides que el estilo del código es personal y que tú lo hubieras hecho de otra manera no significa que tu manera sea mejor (aunque lo sea, él no lo creerá).

Pregunte si puede trabajar con ellos por un corto tiempo. Quiere mostrarles algo con lo que tiene dificultades y quiere trabajar con ellos y su código, para que juntos puedan llegar a una solución. (En otras palabras, no está criticando su código por adelantado, sino pidiéndoles ayuda).

Luego haga un poco de programación en pareja, mostrándoles lo que necesita hacer, y cuando toque algún código que le cause dolor, explíquele el dolor. Dígales lo que le parece que sería una buena solución y pregúnteles si ven razones por las que su solución tiene problemas.

Aborde esto como un problema de equipo para resolver, y no como algo en lo que tiene la solución, sino en lo que necesita su ayuda para llegar a una solución con la que ambos puedan vivir. Esté abierto a las razones por las que codifican de la manera en que lo hacen, lo que les facilitará estar abiertos a ver sus problemas.

Al final, pueden cambiar. O puedes cambiar. O tal vez nada cambie. Pero se comunicará mejor (siempre que siempre los escuche), y será más fácil hacer sugerencias y trabajar juntos cuando lo hayan hecho antes.

Una cosa a tener en cuenta: el hecho de que esté en una organización grande y lenta para adoptar cosas, no significa que su equipo tenga que ser lento para adoptar. Trabajo en una gran organización que no tiene revisiones de código formales (y probablemente no las tendrá durante al menos varios años más)... pero logré convencer a nuestro jefe de que hiciera revisiones de código solo para nuestro equipo. Es posible que desee comenzar a hablar con su jefe para ver si puede configurar un proceso de revisión improvisado solo para su área.

¿En cuanto a manejar las cosas ahora? El primer paso es obtener una lectura de cómo el compañero de trabajo interpretará la crítica. Tengo un compañero de trabajo que se niega rotundamente a cambiar. Y no me molesto en enviarle comentarios sobre el código, sería completamente inútil. Pero a otro de mis compañeros de trabajo le encanta mejorar sus habilidades, y no lo dudaría.

Además, esta es mi recomendación general: hágalo informal e incluya las cosas buenas que notó (tenga en cuenta que los comentarios positivos son más importantes que los negativos; odiaría que dejaran de hacer las cosas buenas, ¿verdad?) Por ejemplo, aquí hay un correo electrónico que podría enviarle a ese segundo compañero de trabajo.

John,

Hola, estaba buscando errores y encontré algunas cosas en Something.cs

En primer lugar, los nombres de sus funciones son increíbles : me permiten saber exactamente lo que estaban haciendo y redujo bastante mi tiempo de búsqueda de errores. Lo mismo con los nombres de las variables, para el caso.

Pero noté que tienes un bucle en la función GetPermissions() que no sale correctamente si el usuario está en VPN. ¿Podría echar un vistazo a cómo escribió ese ciclo while(), especialmente la parte en la que regresa en lugar de interrumpirse en algunas de las condiciones? ¿Quizás el código del bucle se está volviendo lo suficientemente complicado como para justificar dividirlo en su propia función?

--Kevin

Mantén las cosas objetivas y libres de juicios.

No se haga el tonto, no trate de usar el humor, simplemente discuta los hechos objetivos sin hacer ningún tipo de juicio.

Si se trata de un error que está arreglando, algo como

Hola X, estaba buscando la solución al error #123 y creo que la encontré, ¿te importaría echarle un vistazo juntos?

Si la respuesta es alguna variante de "No quiero" , déjelo en paz y espere que las prácticas formales de revisión del código se implementen pronto.

Si la respuesta es afirmativa, una vez más simplemente discuta los hechos sin ningún juicio:

Si leí este código correctamente, aquí comenzamos la barra haciendo burbujear el zumbido. Estoy pensando que cuando foo es X y la barra es Y, esto podría causar el resultado que vemos en el error. ¿Estás de acuerdo?

Esto mantiene las cosas abiertas. La respuesta podría ser que tu forma de pensar fue realmente incorrecta y que en realidad no encontraste la causa del error, o que las cosas pueden ser más complicadas de lo que pensabas. También hace que sea muy fácil para la otra parte estar de acuerdo con usted y comenzar a hablar sobre la solución en lugar de insistir en el problema.

Para problemas generales de código, la plantilla es similar.

Hola X, estaba trabajando en la característica n.° 123 y encontré el código para Y, ¿te importaría si lo miramos juntos?

y

En este momento estamos llenando el bar con el zumbido burbujeante. Me preocupa que [insertar preocupación aquí], ¿crees que sería mejor si nurblemos el blurble en su lugar?

Si la diferencia entre su solución y su solución es simplemente estilística, no hay pautas de estilo de código acordadas que la solución actual viole, y la solución actual no causa ningún problema, simplemente déjelo pasar. Eso no significa que siempre deba dejarlo pasar si el código es difícil de leer. "Tenía problemas para interpretar este fragmento de código, me preocupa que esto se convierta en un problema en el futuro durante el mantenimiento" es una preocupación válida.

Trabaje con su gerente para instituir un proceso de revisión de código formal . Existen muchas aplicaciones de software gratuitas, o puede crearlas como parte del proceso de solicitud de incorporación de cambios al usar git.

Al hacer una revisión de código, no seas pedante . No se fije en detalles pequeños y triviales como los espacios en blanco o la alineación. Debe utilizar un formateador de código automático que se activa cuando el código se guarda en el ID o como parte de un enlace de confirmación previa. Esto también incluye Linters con correcciones automáticas (por ejemplo, si está usando comillas mixtas, debería convertirlas automáticamente todas al mismo tipo. Reduzca el estrés de sus desarrolladores para memorizar todo)

Anime a su equipo a hacer más programación entre pares o sesiones de código de "observación". Se puede aprender mucho simplemente observando cómo algunos usan la terminal como nuevos comandos y técnicas. Permítales interrumpir y hacer preguntas como "¿qué es joe?" o ¿cómo obtuvo su registro de git para mostrar eso?

Aproveche esto como una oportunidad para recorrer juntos el proceso de pensamiento crítico. Como caminar a través de los pasos que sigue para resolver un problema.

No sea condescendiente : la mayoría de los desarrolladores ya tienen el síndrome del impostor, regañarlos y menospreciarlos solo lo refuerza y ​​desmotiva a su compañero de trabajo.

Celebre las pequeñas victorias : puede sonar estúpido o inmerecido, pero felicite a sus compañeros de trabajo regularmente por los pequeños logros y reconozca cómo son una parte importante del equipo. Puede decir "pero solo felicito a las personas cuando realmente lo merecen o la gente pensará que es falso". Numerosos estudios en teoría de la gestión muestran todo lo contrario, la productividad aumenta y las personas hacen un esfuerzo adicional para cumplir con sus requisitos.

Piensa como un mentor, no como un maestro. Piense en cómo podemos mejorar a este compañero de trabajo como un equipo con ese miembro. Esté dispuesto a ser una fuente de información o una referencia. Indique el número de línea de la documentación que deberían estar mirando. Muéstreles cómo pueden aprender a ser mejores (blogs que lea, comparta publicaciones de reddit, videos de tutoriales o libros de O'reilly que haya encontrado realmente valiosos para leer). Puede parecer pedante, pero siéntese con ellos y muéstreles pacientemente cómo sigue su proceso de pensamiento para buscar problemas en Google. Inicie una "lista de los mejores libros de programación" en toda la oficina y haga que su gerente los compre y los tenga en una biblioteca de la oficina. Defina prácticas de codificación claras a las que se adhiere su oficina.

Cuando todo lo demás falla, encuentra un nuevo trabajo. Tal vez sea un reflejo de su entorno de trabajo y de que lo ha superado y puede ser hora de que busque nuevos trabajos. Si sientes que eres la persona más inteligente de la habitación, es hora de encontrar una nueva habitación.