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

95

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.

Zalomon
fuente
77
¿Cuánto tiempo has pasado asegurándote de que él sepa cuáles son tus expectativas?
Blrfl
13
@gnat Creo que no es el mismo caso, mi problema no es que estemos excediendo las estimaciones o exagerando el código. De hecho, estamos adelantados. Mi pregunta es cómo equilibrar la línea entre enseñar al chico y no quemarlo con críticas constantes, para un joven puede ser frustrante si le dices que rehaga cosas que a sus ojos están funcionando.
Zalomon
44
Edité esto para hacerlo más sobre el tema. Creo que esto también es diferente de la pregunta duplicada vinculada.
enderland
3
Algunas cosas que he intentado ayudan con esto: programación de pares: obtenga una idea de cómo trabaja y piensa y quizás lo exponga a sus procesos de pensamiento a medida que avanza en su código. Encuentra las tareas en las que es bueno: a veces obtendrás mejores resultados arrojándole un montón de pequeños errores frente a trabajos de gran tamaño. Diseños tecnológicos: dale la primera oportunidad de diseñar software sin tocar el código. Esto le permite pensar sobre la estructura y el proceso frente a agachar la cabeza y producir código. Por último, buena suerte. A veces se necesita más persistencia de lo esperado, pero vale la pena si se vuelve productivo.
Sandy Chapman

Respuestas:

84

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.

Enderland
fuente
65
@ 9000 es sorprendente la frecuencia con la gente está frustrada por la gente que no contribuyen de acuerdo con sus normas, cuando esas normas no están documentados en cualquier lugar, incluso ...
enderland
32
Los nombres de las variables son completamente importantes para describir la intención del código; nombres de método / función, aún más. Obtener los nombres correctos no es perfeccionismo inútil, es necesario para la mantenibilidad.
9000
99
@Zalomon Definitivamente se lo menciono a él; más, conviértalo en una discusión. Como desarrollador junior, trabajé con algunos desarrolladores senior diferentes. Mi mejor experiencia fue con un desarrollador que me habló de todas sus recomendaciones, incluso las "pequeñas", como un nombre ligeramente mejor para una variable. No solo aprendí mucho de él, sino que me sentí tan bien que estaba escuchando mis procesos de pensamiento e incluyéndome en la discusión, me hizo querer que revisara mi código más para poder aprender más. (continuación)
dj18
66
@Zalomon (continuación) Por otro lado, un desarrollador senior que hizo cambios a mis espaldas (incluso si le dices después, todavía está a sus espaldas) fue totalmente desmoralizador: me hizo sentir que estaba trabajando con un autócrata que yo tuvo que descubrir cómo complacer.
dj18
66
Mi (pequeña) experiencia en la tutoría de desarrolladores junior muestra que vale la pena hacer que un desarrollador piense mucho sobre el nombre propio y exprese el propósito de los datos en el nombre de la variable. Ayuda al desarrollador a comprender realmente lo que está haciendo su código, de una manera mucho menos ondulada de lo que están acostumbrados. A veces los lleva a encontrar errores lógicos en el código involucrado, o simplemente mejores formas de expresar las cosas. (Lo mismo funciona para mí; la diferencia es que tengo la disciplina internalizada, gracias a los estrictos revisores de código que tuve en el pasado.)
9000
19

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.

Ligado
fuente
2
En cuanto al verborrea: cuando tiene que usar un pronombre personal, simplemente elegir "nosotros" en lugar de "usted" también despersonaliza la crítica, en mi experiencia en ambos lados de la revisión del código.
Josh Caswell
6

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.

Machado
fuente
5

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.

JimmyJames
fuente
Una de las formas de evitar ciclos interminables de revisiones de código es hacer pequeños cambios. Ninguna solicitud de extracción es ridículamente pequeña si hace un cambio beneficioso (hice mi parte de relaciones públicas de 1 carácter). Cuanto más pequeño, mejor. Corta sin piedad el alcance de los boletos entregados a los desarrolladores junior, y manténlos haciendo las cosas. Una vez que son buenos en todo el proceso de lectura-comprensión-código-prueba-revisión-implementación, el alcance puede aumentar.
9000
1
No creo que sea una buena idea decirle al desarrollador "no son muy importantes" si son lo suficientemente importantes como para que el OP regrese y cambie más tarde.
enderland
3
@enderland En mi experiencia, no existe el código perfecto. Siempre puedes mejorarlo más tarde, así que eso no es realmente relevante aquí. El OP dice que estas son cosas para "arreglarlo si tengo tiempo libre". Hay dos tipos de problemas. Cosas que deben arreglarse y cosas que no necesitan arreglarse. Este último puede o no ser reparado y suena como si cayeran en esa categoría. Es un llamado de juicio en algún nivel, pero creo que si, como desarrollador experimentado, no estás seguro de que valga la pena llamarlo como un cambio obligatorio, probablemente no lo sea.
JimmyJames
5

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".

gnasher729
fuente
3
O "(b) Y sé que puedes hacerlo mejor". Si él pregunta "enséñame", sabes que está en el camino correcto. :)
Machado
1
En mi posición anterior, usamos Stash / BitBucket como nuestra herramienta de revisión de código. Tenía la opción de bloquear una solicitud de extracción configurando una tarea pendiente o rechazando directamente la solicitud de extracción. Solo los usaría para los cambios necesarios. Si hubiera un cambio cosmético (p. Ej., Menor legibilidad del código, mejor estructura de datos, refactorización), lo señalaría con sugerencias, pero no agregaría una tarea de bloqueo, hágalo si tiene tiempo. Esto también evita la falta de plazos por problemas menores.
Hand-E-Food
4

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.

John Wu
fuente
3
Me gusta la idea de la revisión por pares, por el momento solo somos dos de nosotros en el equipo, pero puedo hacer que revise mi código. Si puede entender lo que hago y encontrar algunas inconsistencias, puede ser útil, tanto por la calidad del código como por su moral. Me ayudó cuando estaba aprendiendo a ver que no era el único que cometía errores +1
Zalomon
2

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.

JacquesB
fuente
2

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.

closeparen
fuente
1

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.

Kevin Krumwiede
fuente
De hecho, me dijo que se sentía tonto. Estoy tratando de mantener las críticas en el lado positivo y le dije que estaba contento con su trabajo, también le expliqué que tenía este tipo de dudas cuando estaba comenzando, pero debo asumir que algunos de los comentarios sobre darle para mejorar su trabajo está saliendo mal.
Zalomon
2
Explique que no malgastará su tiempo criticando su código cuidadosamente si no espera que valga la pena que se convierta en un mejor programador. Y sé escrupuloso al distinguir entre "necesitas arreglar esto para que el código sea aceptable" y "aquí hay algo que puedes hacer aún mejor la próxima vez". Proporcionar grandes cantidades de crítica perspicaz y precisa es el mayor regalo que puede hacer a un programador junior. De lo contrario, se convierte en un peor programador. La crítica debería comenzar a disminuir. Solo tiene que cometer cada error una vez, tal vez dos veces, y solo hay tantos errores.
David Schwartz
1

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.

zak
fuente
0

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.

200_success
fuente
-1

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.

acitio
fuente
-1

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.
BartoszKP
fuente
Me encantaría saber qué hay de malo en mi publicación. Un voto negativo es un signo comprensible de desacuerdo, ¿pero eliminar votos?
BartoszKP