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

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

Tenga en cuenta que el código se lee mucho más a menudo que escrito. Así que las cosas que parecen "menores" en realidad pueden ser realmente importantes (nombres de variables, por ejemplo).

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

• ¿Debería el proceso de su CI capturarlos?
• ¿Tiene una clara "guía para desarrolladores" para consultar (o está todo documentado en su cabeza)?
• ¿Estos comentarios contribuyen realmente 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.

Trate de visitar a su colega en persona si es posible. O utilizar videollamadas. La construcción de una relación hace que las críticas (incluso las revisiones de códigos) sean más fáciles de gestionar.

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

Pero, absolutamente, no fusiona cosas y luego vuelve y arréglalas. Esto es pasivo agresivo y si el desarrollador te encuentra haciendo esto, matarás su moral.

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

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

Una forma de lograr esto es elegir sabiamente tus palabras. Aunque a los individuos STEM les gusta pensar que son altamente lógicos, las emociones son parte de la naturaleza humana. La verborrea utilizada puede ser la diferencia entre sentimientos heridos o salvados. 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 el nombre de esta función y debería estar en inglés". Si bien el último aún es dócil 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 problemas en lugar de la persona .

Lenguaje corporal

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

Da comentarios positivos y honestos

Una multitud de estudios muestran que la información se aprende más rápidamente y se conserva mejor cuando recompensamos el buen comportamiento en lugar de castigar a los malos. A veces, simplemente notando que el rendimiento se ha mejorado con un simple "buen trabajo" o un más específico "Me di cuenta últimamente de que su estilo ha estado haciendo coincidir nuestros estándares con una camiseta, ¡excelente trabajo!" incluso complementando este reconocimiento de mejora al hacer que ellos, a su vez, asesorar a alguien más sobre los problemas que han enmendado pueden marcar la diferencia para su desarrollador junior y su trabajo.

  

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

Empuja todo lo que puedas. Si el chico 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 revises en el futuro, y posiblemente le des a tu equipo un objetivo de contratación.

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

Solo por el hecho de que publicaste tu pregunta aquí, preguntándote si estás haciendo demasiado, ya me has dicho que no necesitas este consejo específico, pero para otros, aquí viene: solo recuerda que empujar con fuerza no no significa ser un imbécil.

Ser un mentor no es una tarea fácil. También tendrás que darle algo de espacio para que cometa algunos errores y corregirlos por su cuenta, solo asegúrate de que lo hará en algún lugar que no cause un 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 los pequeños detalles, se convierte en un problema moral. Idealmente, todos los estándares de codificación se verifican automáticamente y usted no puede compilar a menos que los esté siguiendo. Este es un gran ahorro de tiempo y le permite ponerse a trabajar. Si reserva sus críticas para 'cosas que importan', su consejo tendrá mucho más impacto y será visto como un valioso mentor. Es realmente crucial distinguir entre cosas que no son buenas y cosas que no son exactamente la forma en que 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) no podría y eso está bien. Las personas se agotan y al comienzo de la 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 los lugares donde querría estar como desarrollador junior que desea aprender su comerciar adecuadamente

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 algunas ideas.

1. Revisiones por pares (por el desarrollador junior)

   La mejor manera para que alguien aprenda la manera "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 también los realice (aunque también debería requerir al menos una revisión de un desarrollador senior). De esa manera verá a los buenos programadores 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

   Permitir que el desarrollador participe en su propio desglose de tareas. Pídale que registre el diseño previsto en las notas de la tarea y envíe una "revisión de código" sin cambios y solo la tarea. De esa manera usted puede revisar su plan antes de que él 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 de desmoralización en la que el desarrollador ha escrito un montón de cosas y tienes que decirle que lo vuelva a escribir.

Si el código infringe de manera objetiva un estándar no ambiguo y escrito, entonces creo que debería seguir presionando hasta que se resuelva cada problema. Claro, podría ser un poco molesto para el desarrollador las primeras confirmaciones, pero también podrían aprender las pautas más pronto que tarde.

Además, si permite algunas infracciones de las normas aquí y allá, sentará un mal precedente. Consulte teoría de las ventanas rotas . Además, es mucho más fácil recordar seguir las normas si ya se aplica de manera consistente al código base. 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 se vuelve más subjetivo "bueno, I lo habría hecho de manera diferente" -territorio, 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 compañeros antes de aterrizar sus cambios en la rama maestra compartida.

De esta manera, en lugar de criticar o pedir retroactivamente a alguien que rehaga lo que ya está hecho, el trabajo simplemente no está hecho hasta que pase la revisión por pares. El proceso de ida y vuelta con compañeros es una parte tan importante del proceso de ingeniería del software como el proceso de ida y vuelta con el compilador.

Puede publicar sus inquietudes como comentarios en líneas particulares y tener discusiones unidas sobre ellas. Él puede hacer lo mismo con su código. La discusión se centra en los cambios específicos propuestos en el código, y no en el desempeño o la competencia de alguien en general.

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

  

No estoy presionando 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" podría impedir que el chico aprenda cómo hacer algo. cosas.

Estas son posibilidades reales y preocupaciones válidas. Pregunte al desarrollador cómo se sienten al respecto.

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

Si ve una 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 puede aprobarlo. Al decir algo como: "En el futuro, tal vez intente evitar los nombres de métodos como este a favor de algo como descripttiveMethodName" documente su opinión sin forzarlos a cambiarlos o bloquear su desarrollo.

Ahora saben su preferencia, y si intentan mejorar, es de esperar que se den cuenta de esta situación en el futuro. También deja la puerta abierta para que realmente la cambien en ese momento, en caso de que estén de acuerdo con usted y la vean lo suficientemente crítica.

  

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

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

Tengo curiosidad, ¿qué quiere 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á lanzando código sin haber pasado por un proceso de diseño adecuado. Esto es un fracaso de su parte, como administrador y desarrollador senior, de proporcionar orientación y enseñar buenos hábitos de desarrollo de software. Puede evitar que se escriba el código incorrecto en primer lugar si primero trabaja en conjunto 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 deba reajustar su flujo de trabajo. Parece que actualmente está esperando que él le entregue productos. Lo que necesita es una colaboración más estrecha, para que pueda proporcionar 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 la programación por pares, a través de compartir la pantalla con un canal de audio.

Todo esto requerirá un mayor esfuerzo por tu parte, pero probablemente valdrá la pena, considerando la relación problemática que tienes actualmente.

Si se trata de una violación de los estándares de codificación, muéstrele dónde está para que 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 utilice su tiempo libre para corregir los errores. Esta persona debe corregir sus propios errores para que no los vuelva a cometer.

Dígales siempre lo que hicieron bien y cómo pueden mejorar la próxima vez. Siempre podemos mejorar en alguna área. La retroalimentación es fundamental para ser mejor en cualquier cosa.

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

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