¿Cómo lidiar con el código 'casi bueno' de un desarrollador junior? [cerrado]

Tengo una pregunta sobre la gestión del equipo. En este momento estoy tratando con un desarrollador junior que trabaja de forma remota desde una fábrica de codificación. El tipo está abierto a las críticas y está dispuesto a aprender, pero tengo algunas dudas sobre cuánto debo empujar algunas cosas.

En este momento, cuando algo es claro y obvio, una violación de las buenas prácticas: como la violación de SRP, los objetos de Dios, nombres sin sentido para métodos o variables; Le señalo lo que tiene que arreglar y trato de explicar por qué está mal.

Mi pregunta es: ¿cuándo me detengo? En este momento, si hay algunas violaciones menores del estilo de codificación, como nombres de variables en el idioma incorrecto (el equipo anterior mezcló español e inglés y estoy tratando de solucionarlo), o algunos problemas estructurales menores lo dejo ir y lo soluciono si Tengo tiempo libre o necesito modificar la clase problemática. Siento que esto es bueno para la moral del equipo, así que no estoy retrasando el código constantemente sobre lo que para un novato puede parecer detalles menores, lo que puede ser bastante frustrante, pero también me preocupa que ser demasiado 'blando' pueda evitar que el tipo de aprender a hacer algunas cosas.

¿Cómo equilibro la línea entre enseñar al tipo y no quemarlo con críticas constantes? Para un junior puede ser frustrante si le dices que rehaga cosas que a sus ojos están funcionando.

Si cree que el código debe repararse antes de fusionarse, haga comentarios. Preferiblemente con "por qué" para que el desarrollador pueda aprender.

Tenga en cuenta que el código se lee con mucha más frecuencia que lo escrito. Entonces, las cosas que parecen "menores" pueden ser realmente importantes (nombres de variables, por ejemplo).

Sin embargo, si se encuentra haciendo comentarios que parecen tediosos, quizás considere:

• ¿Debería su proceso de CI captar esto?
• ¿Tiene una "guía del desarrollador" clara para hacer referencia (o está todo documentado en su cabeza)?
• ¿Estos comentarios realmente contribuyen a la calidad del código?

Mucha gente sacrifica la productividad en el altar del proceso o la perfección. Ten cuidado de no hacer esto.

Intenta visitar a tu colega en persona si es posible. O usa videollamadas. Construir una relación hace que las críticas (incluso las revisiones de código) sean más fáciles de manejar.

Si encuentra que una pieza de código tiene demasiados problemas de ida y vuelta, solicite la revisión de piezas de código más pequeñas. Es más probable que los cambios incrementales eviten algunos de los problemas de diseño más significativos, porque son, por definición, más pequeños.

Pero absolutamente no fusionar cosas y luego volver y arreglarlo. Esto es pasivo agresivo y si el desarrollador te encuentra haciendo esto, matarás su moral.

Mantenga las críticas sobre el código en lugar del escritor.

Cualquier trabajo producido viene con un apego emocional inherente. Considere facilitar esto desasociando el código del escritor tanto como sea posible. La calidad del código debe establecerse consistentemente como un objetivo mutuo que ambos enfrentan juntos, en lugar de un punto de fricción entre ustedes.

Una forma de lograr esto es elegir sabiamente sus palabras. Aunque a las personas con STEM les gusta pensar que son altamente lógicas, las emociones son parte de la naturaleza humana. La palabrería utilizada puede ser la diferencia entre el dolor o los sentimientos perdonados. Decir "este nombre de función sería más coherente con las convenciones si estuviera en inglés" es preferible a "Usted escribió mal este nombre de función y debería estar en inglés". Si bien este último todavía es manso y solo parece estar bien, en comparación con el primero, sus fallas se vuelven obvias: al preparar qué decir en persona o en un correo electrónico, examine si su contexto, palabras y enfoque están en los problemas en lugar de la persona .

Lenguaje corporal

Si bien las palabras son importantes, la mayoría de la comunicación no es verbal. Preste atención al lenguaje corporal, incluso sutilezas aparentemente insignificantes, como la orientación, por ejemplo, muchas interacciones entre senior y junior ocurren cara a cara, sin embargo, un enfoque de lado a lado sería mucho más propicio para el resultado deseado.

Dar comentarios positivos honestos

Una multitud de estudios muestran que la información se aprende más rápidamente y se retiene mejor cuando premiamos el buen comportamiento en lugar de castigar los malos. A veces, simplemente observando que el rendimiento se ha mejorado con un simple "buen trabajo" o más específico "Me di cuenta últimamente de que su estilo ha estado igualando nuestros estándares a la perfección, ¡gran trabajo!" incluso complementar este reconocimiento de mejora haciendo que, a su vez, asesoren a otra persona sobre los problemas que han modificado puede marcar la diferencia para su desarrollador junior y su trabajo.

El tipo está abierto a las críticas y está dispuesto a aprender, pero tengo algunas dudas sobre cuánto debo empujar algunas cosas.

Empuja todo lo que puedas. Si el tipo está aprendiendo, y es su trabajo revisar su código, ambos tienen mucho que ganar si hace un buen trabajo.

Eso significará menos código para que lo revise en el futuro y posiblemente le dé a su equipo un objetivo de contratación.

Además, si te detienes, no estás ayudando, sino condescendiente.

Solo por el hecho de que publicaste tu pregunta aquí, preguntando si estás haciendo demasiado, ya me indica que no necesitas este consejo específico, pero para otros, aquí viene: solo recuerda que presionar duro no significa siendo un idiota

Ser un mentor no es una tarea fácil. También tendrá que darle algo de espacio para que cometa algunos errores y los corrija por sí mismo, solo asegúrese de que lo haga en algún lugar que no haga daño real.

Según su descripción, lo dejaría en: "esto es bueno. Hay algunas cosas que habría hecho de manera diferente, pero no son muy importantes".

Como parece comprender, las críticas tienen un costo y si dedica mucho tiempo a detalles insignificantes, se convierte en un problema de moral. Idealmente, todos los estándares de codificación se comprueban automáticamente y no puede compilar a menos que los siga. Esto es un gran ahorro de tiempo y le permite ponerse manos a la obra. Si reserva sus críticas para "cosas que importan", su consejo tendrá mucho más impacto y será visto como un mentor valioso. Es realmente crucial distinguir entre cosas que no son buenas y cosas que no son exactamente como lo harías.

Creo en el concepto del momento de enseñanza . Si el desarrollador tiene suficiente capacidad mental, podría pedirle detalles sobre lo que haría de manera diferente. (S) podría no hacerlo y eso está bien. Las personas se agotan y al principio de una carrera puede llevar mucha energía mental lograr cosas que parecen simples más adelante.

Consideraría aceptar su trabajo cuando sea aceptable, no perfecto. Y luego, la siguiente tarea es después de una discusión para refactorizarla inmediatamente haciendo todos los cambios pequeños pero importantes que desee.

Entonces, cuando se acepta el trabajo por primera vez, su mensaje es que no fue malo, y algunos lugares lo habrían aceptado como lo suficientemente bueno, pero no lugares donde le gustaría estar como desarrollador junior que quiere aprender su oficio correctamente.

Entonces no dices "Rechazo tu trabajo porque no es lo suficientemente bueno". Usted dice (a) "Acepto su trabajo porque es lo suficientemente bueno", y luego (b) "Pero lo quiero mejor".

Pregunta bastante abierta, pero aquí hay un par de ideas.

1. Revisiones por pares (por el desarrollador junior)

   La mejor manera para que alguien aprenda la forma "correcta" es ver a otros hacerlo. ¿Todos sus desarrolladores realizan revisiones de código? Puede que no sea una mala idea dejar que su desarrollador junior las realice también (aunque también debe requerir al menos una revisión de un desarrollador senior). De esa forma verá buenos codificadores en acción, además observará que hay comentarios de revisión dirigidos a ingenieros que no sean él mismo, lo que significa que no es personal.

2. Comentarios tempranos / Revisiones de tareas

   Permita que el desarrollador participe en su propio desglose de tareas. Haga que registre su diseño previsto en las notas de la tarea y envíe una "revisión de código" sin conjunto de cambios y solo la tarea. De esa manera, puede revisar su plan antes de que haya escrito una sola línea de código. Una vez que su tarea ha sido revisada, puede comenzar a codificar (después de lo cual enviará otra revisión de código). Esto evita la situación desmoralizadora en la que el desarrollador ha escrito un montón de cosas y tienes que decirle que lo reescriba.

Si el código viola objetivamente un estándar escrito e inequívoco, creo que deberías seguir presionando hasta que se solucionen todos los problemas. Claro, puede ser un poco molesto para el desarrollador las primeras confirmaciones, pero es mejor que aprendan las pautas más pronto que tarde.

Además, si permite algunas infracciones de los estándares aquí y allá, sentarán un mal precedente: consulte la teoría de ventanas rotas . Además, es mucho más fácil recordar seguir los estándares si ya se aplica de manera consistente a la base de código. Así que realmente, todos ganan, incluidos los desarrolladores junior en cuestión.

No creo que la moral sea un gran problema siempre que se escriba el estándar de codificación. Solo si entra en un territorio más "subjetivo, lo habría hecho de manera diferente", entonces debería preocuparse, ya que el enfoque de los desarrolladores podría ser igual de válido.

Considere la posibilidad de adoptar un flujo de trabajo de revisión de código, donde los desarrolladores publiquen sus compromisos propuestos en una herramienta como Github Pull Requests o Phabricator Diffusion y obtengan la aprobación de sus pares antes de aterrizar sus cambios en la rama maestra compartida.

De esta manera, en lugar de criticar retroactivamente o pedirle a alguien que vuelva a hacer lo que ya está hecho, el trabajo aún no está terminado hasta que pase la revisión por pares. El ir y venir con los compañeros es tan parte del proceso de ingeniería del software como el ir y venir con el compilador.

Puede publicar sus inquietudes como comentarios en líneas particulares y entablar debates sobre ellas. Él puede hacer lo mismo con tu código. La discusión se mantiene enfocada en los cambios de código específicos propuestos, y no en el desempeño o competencia de alguien en general.

Incluso los brillantes ingenieros superiores de mi empresa están agradecidos cuando las revisiones de códigos detectan errores tipográficos o los obligan a aclarar las cosas. Es totalmente normal que los nuevos empleados requieran más rondas de iteración. Con el tiempo, comienzas a resolver reflexivamente el tipo de problemas que sabes atraerán comentarios antes de publicar un diferencial. Obtener un mayor porcentaje de sus diferencias aceptadas en el primer intento es cómo sabe que está mejorando.

No estoy retrasando el código constantemente sobre lo que para un novato puede parecer detalles menores, lo que puede ser bastante frustrante, pero también me preocupa que ser demasiado 'blando' pueda evitar que el tipo aprenda a hacer algunas cosas.

Estas son posibilidades reales y preocupaciones válidas. Pregúntele al desarrollador cómo se siente al respecto.

Suponiendo que tiene alguna solicitud de extracción o flujo de trabajo de revisión de código, y parece que sí, recomendaría señalar cosas que son "no críticas" o "preferidas".

Si ve un RP en un estado similar al que está describiendo, con algunos problemas estilísticos menores o necesita una refactorización no crítica, deje un comentario, pero también siéntase libre de aprobarlo. Al decir algo como "en el futuro, tal vez intente evitar nombres de métodos como este en favor de algo como descriptiveMethodName" documenta su opinión sin obligarlos a cambiarlo o bloquear su desarrollo.

Ahora conocen su preferencia, y si están tratando de mejorar, con suerte notarán tal situación en el futuro. También deja la puerta abierta para que la cambien en ese momento, en caso de que estén de acuerdo con usted y lo consideren lo suficientemente crítico.

Estoy tratando con un desarrollador junior que trabaja de forma remota desde una fábrica de codificación.

Desafortunadamente, esa no es una situación ideal: un programador avanzado a cargo de un programador novato, con separación geográfica. No es sorprendente que haya cierta tensión, pero la disparidad puede mitigarse.

Tengo curiosidad, ¿qué quieres decir con "fábrica de codificación"? Esa terminología, para mí, indica una actitud preocupante que puede estar exacerbando algunos de los problemas de gestión que ha mencionado.

... violación de SRP, objetos de Dios, nombres no significativos para métodos o variables; Le señalo lo que tiene que arreglar y trato de explicar por qué está mal.

El problema, creo, es que su desarrollador junior está arrojando código sin haber pasado por un proceso de diseño adecuado. Este es un fracaso de su parte, como gerente y desarrollador senior, para proporcionar orientación y enseñar buenos hábitos de desarrollo de software. En primer lugar, puede evitar que se escriba un código incorrecto si primero trabajan juntos para dibujar un esquema. Eso sería preferible a criticar y reescribir el código después de que se haya producido, tanto en términos de eficiencia como de moral.

Probablemente necesite reajustar su flujo de trabajo. Parece que actualmente está esperando que le entregue productos. Lo que necesita es una colaboración más estrecha, para que pueda brindar orientación en cada paso del desarrollo. Hable sobre el diseño y la interfaz antes de que comience la codificación. Mientras se realiza la codificación, realice controles más frecuentes para detectar problemas antes. Si es posible, intente programar los pares, compartiendo la pantalla con un canal de audio.

Todo esto requerirá más esfuerzo de tu parte, pero probablemente valdrá la pena, teniendo en cuenta la relación problemática que tienes actualmente.

Si es una violación de los estándares de codificación, muéstrele dónde está para que lo sepa. Si tiene que seguir mostrándole el mismo error, es posible que tenga un problema con alguien que no puede cumplir con las reglas o se niega a hacerlo. No use su tiempo libre para corregir los errores. Esta persona debe corregir sus propios errores para no volver a cometerlos.

Siempre dígales lo que hicieron bien y cómo pueden mejorar la próxima vez. Siempre podemos mejorar en alguna área. La retroalimentación es crítica para mejorar en cualquier cosa.

Otra idea para lidiar con "demasiadas críticas" es hacer una tarea usted mismo de vez en cuando, y dejar que un desarrollador junior haga una revisión de código por usted. Esto tiene al menos dos ventajas:

• pueden aprender cómo deben hacerse las cosas.
• en los casos en que existen múltiples soluciones buenas o nombres de variables, acepto sugerencias de enfoques diferentes pero (¿casi?) igualmente buenos. Cuando reparo mi código debido al comentario de alguien, le muestro a las personas que son respetados y las críticas siempre se refieren solo al código, independientemente de quién sea el autor.