code review - div - ¿Cómo ayudar a un novato que lucha hacer un mejor trabajo?

title html5 (30)

Haga un par de programación. Ya lo sugerí y él pareció estar abierto a la idea, pero cada vez que comenzamos me inclinaba porque no estaba escribiendo lo suficientemente rápido:

Eso definitivamente no está bien. Eso probablemente no lo ayudará a pensar que tiene espacio para aprender.

No haga muchos cambios en su trabajo mientras está fuera. Eso lo hará sentir terrible. En lugar de eso, trabaje en refaccionarlo con él cuando regrese (y cueste lo que cueste evitar la tentación de asumir la tarea de teclear).

Destaca las cosas que ha hecho bien (acaba de hacer su primer cambio, es un gran logro que vale la pena celebrar), y solo una vez le has hablado de dónde puede mejorar, y lo haces mientras refuerzas las cosas buenas de él. cambio.

En el futuro, podría ser una buena idea no permitir que las personas ingresen un código que no haya sido revisado primero (según su punto 3), y solo permita que se registren los cambios una vez que se hayan resuelto todos los problemas resaltados en la revisión.

_{NÓTESE BIEN.} _{Nunca he hecho ninguna gestión, así que esto es solo describir cómo me gustaría que lidieses con esta situación si yo fuera el otro tipo.}

He sido el único desarrollador y el "desarrollador sénior" de facto en el producto estrella de mi empresa por un tiempo (una aplicación .NET WinForms, pero eso no está relacionado). Recientemente, trajeron a un desarrollador "novato" con un nuevo título en ciencias de la computación. Sin experiencia con control de fuente, pruebas de unidad, mantenimiento de software, etc.

Recientemente le asigné un pequeño pedazo de trabajo y me puse a mi disposición para recibir asistencia, solo para descubrir que su producción no era grande, tanto en términos de velocidad como de calidad. Traté de no ser demasiado torpe, así que la única guía inicial que le di es un artículo de wiki que describe la tarea que actualizo (pero él no), varios ejemplos de código sobre nuevas tecnologías (como IPC) y descompuse las tareas en varios casos de FogBugz (a los que no proporcionó estimaciones originales, tiempo real o comentario hasta que le dije lo que pondría). Rara vez hacía preguntas y, cuando lo hacía, parecía seguir mis sugerencias como si fueran requisitos, a menudo sin entenderlos e incluso cuando estaban equivocados.

Entonces ... simpatizo plenamente con su situación en la que no sabes qué hacer y tienes miedo de hacer preguntas. Sé que es mi responsabilidad hacer un mejor trabajo, pero nadie me dio ninguna orientación por lo que no tengo experiencia con lo que parece un mejor trabajo. Afortunadamente, él está de vacaciones por una semana, así que tengo algo de tiempo para pensar sobre cómo mejorar el proceso. Estos son algunos de los elementos que se me ocurren, pero estoy abierto a sugerencias y críticas:

Pregunte qué parte de la última iteración fue la más difícil. Pregunte qué parte tomó mucho más tiempo de lo que esperaba.
Haga un par de programación. Ya lo sugerí y él pareció estar abierto a la idea, pero cada vez que comenzamos me inclinaba a hacerlo porque no estaba escribiendo lo suficientemente rápido. Algo en lo que tengo que trabajar.
Haga una revisión del código antes de verificar el trabajo. (No lo hicimos esta vez debido a sus vacaciones). La revisión del código destacaría los siguientes elementos.
Requerir comentarios sobre todos los miembros públicos. (No se comenta ninguno de sus códigos).
Requiere que elimine todo el código no utilizado. (Una revisión superficial muestra que no lo hizo).
Exigirle que asigne código a cada caso de FogBugz a medida que lo completa y / o revisa los casos en los que difieren de lo que descubre durante la codificación.
Exigirle que ingrese las estimaciones originales en FogBugz y alternar la bandera de "trabajar en" para mantenerlo en la tarea.

Si bien el material de revisión del código es específico y técnico, me preocupa más su capacidad para ser un emprendedor de iniciativa propia y para pedir y obtener orientación donde la necesita. No pienso en los requisitos de FogBugz (6 y 7) como reglas duras, pero parece que tiene que seguirlos para mantenerlo encaminado.

Además, sé que necesito mejorar mis habilidades de mentoría / entrenamiento tanto como él necesita para mejorar sus habilidades de codificación. ¿Alguna sugerencia sobre dónde comenzar cuando el "desarrollador principal" no participó en una revisión formal del código o pasó por una sesión de programación en pareja sin hacerse cargo?

Mi impulso es actualizar las cosas que ya ha registrado, pero sé que debería guardar eso para una revisión del código. Quería que revisara el trabajo para poder comenzar a codificar la parte que utiliza lo que él registra. Entonces, ¿debería usar lo que registró aunque no creo que sea satisfactorio?

Déles trozos de trabajo individuales, bien definidos y del tamaño de un bocado.
Hágales saber por qué cada pedazo es necesario.
Comience con dos trozos, para que puedan elegir cuál trabajar a continuación. A medida que aprenden a manejar tareas múltiples, bríndeles más que eso y bríndeles prioridades y plazos difíciles para cada una. Asegúrate de que tengan buy-in; necesitan sentir que cada fecha límite es razonable.
Personalmente, tiendo a dar también a todos los nuevos desarrolladores una copia de The Pragmatic Programmer.

De vez en cuando, trato de esforzarme, se esfuerzan y simplemente no funciona. Lo que todos estarían de acuerdo es una mierda, pero estadísticamente, sucede; en algún momento, aprende cuándo cortar el cable y busca un nuevo desarrollador. Tiendo a esperar demasiado, lo que resulta en más estrés para todos los involucrados.

¡Buena pregunta y excelentes respuestas!

Otra sugerencia que agregaría es: cuando esté haciendo una programación combinada, no se apresure a corregir sus errores. Tome nota de ellos usted mismo, pero déjelo continuar y verifique si puede resolver sus propios errores / problemas. Por supuesto, brinde una mano de ayuda si le lleva demasiado tiempo (tendrá que decidir cuánto tiempo durará), pero algunas de las mejores experiencias de aprendizaje provienen de la corrección de sus propios errores.

¿Cómo está asignando las nuevas tareas de desarrollador? ¿Estás esperando que él saque las cosas de tu iteración e ir a la ciudad con ellas? Si es así, probablemente sería útil no hacer eso por el momento. Elija una tarea pequeña, algo interesante que hacer, ya sea como parte de una tarea en su iteración o como una subtarea en su iteración. Bríndele toda la información que necesitará para implementar, incluyendo el apagamiento de los métodos y (si los está usando) pruebas unitarias para asegurarse de que funcionen. Asegúrese de que todo esté escrito, y reúnase con él para repasar lo que necesita hacer.

Esté disponible diariamente para responder preguntas, si las tiene. No lo presione de inmediato sobre los plazos para esto, solo haga un seguimiento del progreso que está haciendo en la tarea.

Una vez hecho esto, repase lo que ha hecho. Sugerir los cambios que necesita hacer.

Una vez que haya pasado esto, lentamente comience a aumentar la complejidad de la tarea que está dando. Tal vez la próxima tarea aborde más de una capa o implique agregar una característica más involucrada: su entorno específico dictará esto, al igual que sus experiencias.

Definitivamente hay una curva de aprendizaje aquí. Cada persona abordará esa curva de forma diferente, su trabajo es (a) mantenerlo en esa curva y (b) recomendar hacia arriba si va a poder mantener el ritmo en absoluto.

¿Quieres llevarlo a tus estándares profesionales? Estupendo. Necesitas enseñarle qué son. Desde el punto de vista de la tutoría, no descarte todas las reglas al mismo tiempo. Trabaja uno nuevo todos los días. Con el tiempo llegará allí o se deshará de él.

Una cosa que falta en su lista son las revisiones de código. Sí, debería revisar todo su código, pero ... También debería revisar todo su código. El aprendizaje va en ambas direcciones de esa manera. Lo hará sentir como parte del equipo.

Aprecio tus esfuerzos para ser un buen mentor. Aquí está mi 2 centavos. Una vez tuve un Sr. Desarrollador que utilizó estimaciones solo para comprobar si los desarrolladores están usando un enfoque correcto para una función (sin presión de tiempo). Definitivamente sabes que algo está mal si el desarrollador estima 10 horas para algo que podría hacerse en, por ejemplo, 2 horas.

A veces se dejaba caer en mi escritorio (no micro administrar) para comprobar si las cosas están bien y dar algunos consejos nuevos o mejores ideas si me golpean. Sentí que su enfoque creaba más confianza en mí y me convertía en un mejor programador. Definitivamente diría que estos "dropbys ocasionales con controles sutiles" son más potentes y ágiles que las revisiones semanales de un código porque cuanto más tiempo pasa un programador Jr. sin mucha pista, más rápido pierde la confianza. Mantenerlo simple al comienzo ayudará a los recién llegados a adaptarse más rápido.

Aquí está mi punto de vista Por favor, corríjanme si me equivoco ... Como principiante, el estudiante espera un cierto nivel de entrenamiento ... Esto es así porque él habría escuchado que sus amigos están siendo entrenados en otras compañías y están teniendo un mejor desempeño. ..... En este caso, necesitas hacerle sentir que la web es su única guía ... Y necesitas ayudarlo un poco y entender algunas cosas ... Porque a la salida de la universidad es un poco difícil Digest herramientas de repositorio, marcos y otras cosas ... Ya que él no está entrenado en esto ahora y lo pusieron en un proyecto directamente, es difícil para él entender las cosas ..... Darle algo de tiempo y hacerle entender las cosas. ... hasta que se dé cuenta de que es responsable, entonces creo que las cosas se harán más suaves ........

Aquí hay algunos consejos de la forma en que esto se maneja en Japón.

En primer lugar, pídale que configure su entorno de trabajo (le dé una semana para hacerlo), luego dígale quién es quién y déle una lista de las direcciones postales de sus compañeros de trabajo. 1 semana no lo presionará mucho, y logrará algo tangible en sus primeros 5 días

En su primer viernes, saque al recién llegado con el equipo para tomar unas copas, go-carts o disneyland (está a una hora de distancia). Depende de tus gustos y de lo que el nuevo commer prefiera. Esto lo ayudará a entender al equipo, y los verá interactuando a nivel personal, y lo ayudará a sentirse como parte de la familia. De esta manera, él se sentirá mucho más seguro acerca de acercarse a otros en busca de ayuda.

Luego haga que haga una codificación básica durante 2-3 semanas. Dígale que diga 5 asignaciones realmente pequeñas por día en su primera semana. Cosas básicas de nivel de zumbido. Y haga una revisión del código al final de cada día.

Durante su segunda y tercera semana, pídale que trabaje en un proyecto de juguete (con una fecha límite real). En el mismo campo que su trabajo futuro, pero no forma parte del proyecto real. De esta manera, tiene una caja de arena para trabajar sin miedo a romper el trabajo de otras personas. Revise el código con él dos veces por semana. Y que presente su trabajo al equipo una vez que haya terminado. Esto le dará una confianza inestimable.

Ahora, después de sus primeras 3 semanas de entrenamiento básico, tome una copa o diviértase con el equipo nuevamente.

Él ha aprobado el rito de iniciación (muy importante desde el punto de vista psicológico).

Ahora ponlo a trabajar en el proyecto real, pero dale una semana para leer el código y hacer preguntas. A mediados de semana y al final de las reuniones de configuración de la semana para que pueda hacerle preguntas al equipo, sin sentir que tiene que interrumpir a nadie.

Ahora que tienes un recién llegado feliz, inquisitivo y seguro, haz todo lo que los demás sugieren aquí :)

Aquí se ofrecen muchos consejos excelentes, y podría ser difícil impartir toda esta información directamente a su empleado. ¿Has considerado introducirlo en y dejarle leer esta pregunta y sus respuestas? Por supuesto, primero debe hablar con él, para que las críticas que identifique no sean una sorpresa dolorosa.

Veo varios beneficios para este enfoque:

Él puede involucrarse en , que es una excelente manera de mejorar su estilo de programación y aprender las cuerdas
Él puede ver las cosas desde tu punto de vista
Él puede ver todos los consejos de primera mano, y saber que todos hemos estado allí antes
Le abrirá la puerta a una relación empleador / empleado muy sincera y por adelantado

Bueno, mereces una medalla por dedicar tanto tiempo a este problema.

Sugeriría estas cosas:

Haz que lea Code Complete .
- Trátelo como un programador senior, pero revise cada paso que da hasta que vea buenos resultados.
- No asumas o no aprenderá. Deja que cometa errores, pero luego haz que lo arregle.
- Él siempre debe hacer estimaciones. Luego haz que reconozca cuándo su estimación es incorrecta.
- Siempre anímalo a pensar . Los estudiantes de CS recientes apenas piensan; codifican como robots.

Déle algunas reglas básicas, como: nunca escriba el mismo código dos veces, y si lo hace, verifique su diseño, etc.

También recuerde que tiene miedo de usted tanto como él quiere aprender de usted. Es posible que haya olvidado cosas que está aprendiendo, por lo que debe presionarlo para que haga preguntas y asegurarse de que no se sienta estúpido al hacerlo.

¡En seis meses estará bien y listo! (salir y buscar un trabajo mejor remunerado :-))

Ciertamente dejaría caer los requisitos de estimación de tiempo.

Es casi imposible que un novato no tenga experiencia con las tecnologías a mano, que no tenga experiencia con el desarrollo en general, ni que el sistema ayude a desarrollar estimaciones razonables. Él necesita entrenamiento y experiencia en el mundo "real" incluso antes de que sea sensato.

Comenzaría a implementar el desarrollo impulsado por pruebas. Luego, podría darle una lista de requisitos, o si se siente realmente bien, una lista de pruebas para escribir y luego dejar que la rompa.

También eliminaría el "Requerir comentarios sobre todos los miembros públicos". porque probablemente esté tratando de pensar en algo inteligente para decir en los comentarios en lugar de en la codificación. Muy pronto comenzarás a tener comentarios sobre tus miembros públicos que dicen algo cuando el código hace algo más.

Creo que la programación de los pares también tiende a fallar en estos casos. Necesitas más pares (alguien más en el mismo nivel) para hacer la programación de pares ya que terminarás dándole lecciones de codificación. Con la programación de pares, ambas personas deberían obtener un beneficio.

Como ingeniero informático (e ingeniero junior) que pronto será ingeniero, puedo simpatizar con el novato.

Una de las cosas más importantes para aclararle es que no se meterá en problemas (o será despedido) por cometer errores desde el principio. Anímalo a intentarlo, incluso si no cree que su código sea perfecto.

En mi primer trabajo, mis tareas tomaron mucho más tiempo de lo que quería porque tenía miedo de extrañar algo o cometer un simple error que me haría parecer un idiota, así que pasé más tiempo revisando para asegurarme de que todo lo que hacía era correcto .

En muy raras ocasiones un grado en ciencias de la computación realmente se ocupa de tareas de programación del mundo real como control de fuente, seguimiento de fallas, gestión de proyectos (propia) o incluso programación más allá de lo básico. Probablemente le dé miedo estar en su primer trabajo. Una cosa que preocupa es su velocidad lenta de tipeo, que indica una falta de programación de confianza (una gran preocupación, pero que se puede superar si tiene la idea correcta), o que hizo CS porque estaba pensando en el dinero, no en eso se requiere habilidad (mayor preocupación que indica un período de prueba fallido).

Aliéntelo a diseñar soluciones lógicamente en papel primero: vea cómo funcionan sus procesos de pensamiento sin el estrés de codificar realmente con usted mirando.

Nunca tome el control del teclado cuando se está programando un par; de lo contrario, esta es una buena idea. También déjalo participar de tu programación también.

Pregúntale acerca de las herramientas que estás usando y su experiencia previa. Si no hay ninguno, podría ser mejor entrenarlo hasta que tenga confianza.

En primer lugar, debe leer un tutorial completo del idioma que se utiliza y un buen libro de software como ''Code Complete''. Otro aspecto importante es que tiene que saber de qué se trata el trabajo, por qué está haciendo el trabajo y qué es el panorama general allí. entonces debe tener la impresión de que puede preguntar cualquier cosa y también buscarla él mismo.

Esta es una pregunta difícil y no habrá una sola respuesta "correcta", pero aquí algunos comentarios y sugerencias:

Entonces, ¿debería usar lo que registró aunque no creo que sea satisfactorio?

Definitivamente no, en mi humilde opinión. Primero debe hacer una revisión juntos. De lo contrario, ¿cómo va a creerte que el código no es satisfactorio si lo estás usando?

Requerir comentarios sobre todos los miembros públicos. (No se comenta ninguno de sus códigos).

Eso debería ser simple. No hay excusa para ningún comentario. Si sigues una convención de codificación, muéstrale esta convención. Si no, tal vez es hora de escribir uno pequeño. Puede incorporar esto en las revisiones del código también.

Una cosa que veo que falta en tus ideas es preguntarle qué cree que puede hacer él o qué puedes hacer para que sea más fácil para los dos. ¿Cree que su código es satisfactorio? etc. Quizás te sorprenda lo que tiene que decir.

Esto es de naturaleza muy general y se puede usar con otras sugerencias sobre aspectos específicos.

Si bien esto puede sonar obvio, confronte a la persona (de una manera agradable, pero con suficiente franqueza para iluminar). Primero, pregúnteles si desean participar y compartir ideas sobre la mejora, (esto va en ambos sentidos) si no lo hacen, ya terminaron. Si lo hacen, estás en el lado positivo, SABES lo que ves, hazles saber francamente lo que observas y pregúntales si desean comentarios específicos sobre cada una de esas áreas. SIEMPRE hágales saber que todo el mundo comenzó desde el principio y que esta industria SIEMPRE trata de aprender, trate de encontrar algo positivo que ELLOS puedan compartir con USTED desde el principio, encontrará que esto pondrá el énfasis en "compartir y comunicarse" y no ¡estilo dictatorial y autocrático y también puedes aprender cosas!

Tenga en cuenta siempre que la apertura de la comunicación es el objetivo real aquí, que a su vez conduce a la mejora del estado de calidad del producto y el rendimiento que desea. Y esta es una industria con una gran cantidad de tipos de personalidad donde esto es un desafío.

Felicitaciones por su actitud hacia la tutoría. ¡El simple hecho de que preguntes si lo estás haciendo bien y cómo podrías hacerlo mejor significa que lo estás haciendo bien!
Creo que el problema es que puedes estar en 2 situaciones:
1) él / ella solo necesita tiempo y orientación para entender qué es el juego, pero llegará allí
2) él / ella no es un jugador de equipo, y no le importa.
Obviamente, si estás en una situación (2), la tutoría no ayudará. Si este es el caso, tu mejor estrategia es limitar el daño que la persona puede hacer e intentar sacarlo del equipo. Pero no harás eso sin darle una oportunidad a la persona, que es lo que estás haciendo.
Se han dado muchos buenos consejos. Asumiendo que estás trabajando con alguien a quien puedes servir de mentor, mis 2 consejos generales son:
1) ayudar a la persona a comprender lo que se espera de él / ella. Dele tareas pequeñas a la persona, diga lo que buscará (duplicación de código ...), y mire juntos una vez completados estos. Sea alentador, pero respete las reglas: si estuvo de acuerdo en que una cosa tenía que hacerse y no se hizo, no la deje pasar, esto es una falta de respeto hacia el equipo. No corrija el código, envíe el código nuevamente para corregirlo si algo no se ha hecho como se acordó. Esto lo ayudará a encaminarse, y si repetidamente ocurren los mismos problemas, lo siento pero tiene un peso muerto en su equipo.
2) construir confianza. La universidad debería dar una buena comprensión de la teoría, pero generalmente es una preparación deficiente para trabajar en equipo, en grandes piezas de software. Haz que la persona entienda que los compromisos deficientes impactan a todo el equipo. Haga que entienda que hacer preguntas es bueno y que todos cometen errores. Encontré la programación de pares ideal para esto, porque muestra que nadie es un dios (¡pero nunca se haga cargo del teclado!). Pídale a la persona que evalúe qué hicieron bien y dónde tuvieron problemas con una característica, y cuénteles su evaluación de lo que era bueno y no tan bueno, o dónde se observa una mejoría. También para alentar las preguntas, también haga preguntas, si puede, o piense en un problema en el que esté trabajando.

Las revisiones de códigos y la programación de pares (¡déjalo escribir!) Son definitivamente una buena idea y un excelente momento para impartir tu estilo de codificación preferido / revisar las características del idioma con las que no esté tan familiarizado / cambiar todas sus combinaciones de teclas. También debe aprovechar estas oportunidades para realizar recorridos por su base de código para mostrarle clases útiles o patrones que se relacionan con lo que está trabajando.

También le sugiero que tenga conversaciones de whiteboard con él cuando asigne nuevas características / errores. Intente hacerle preguntas sobre cómo satisfaría los diversos requisitos o si cree que faltan requisitos / no requisitos. Haga un punto para que él proponga la mayor cantidad de diseño posible, incluso si ya ha pensado en un buen diseño. De esta forma, puede medir su capacidad para pensar de forma independiente y, al mismo tiempo, proporcionar orientación sobre el diseño, y se sentirá más cómodo con el proceso.

Lo que estás haciendo es excelente y has reconocido los puntos en los que tú mismo necesitas mejorar.

Mi proceso es tratar de mantener a los recién llegados lo más motivados posible. Actualmente tengo un colega al que doy pequeños cuestionarios y tareas "divertidas" que ella puede hacer en su tiempo libre para mantenerla motivada. Cuando trabajo en proyectos reales, le pido que inicie su propia sucursal y le diga que busque oro y le asegure que "no puede romper nada". Una vez que esté completo, me hará saber que la tarea establecida está completa y luego realizaré una revisión del código, haciendo sugerencias o mostrándole maneras alternativas de lograr la tarea establecida, esto a menudo se hace de forma conjunta.

Creo que es una muy mala idea quitarle el teclado a alguien, mientras que pueden ser lentos, debes entender que se puede sentir como degradante.

Por lo que he dicho, lo mejor que puedo hacer es mantenerlos entusiastas y hambrientos de desafíos, esto motivará y fomentará mejores prácticas.

Si descubre que no proporcionan resultados suficientes, debería solicitarles que actualicen su código y asegurarse de que el código esté documentado lo suficiente (y no exagerado como a veces es el caso).

Trátelos como un amigo que siempre alentará y que recorrerán un largo camino.

Me gustaría que esta persona solo hiciera cosas muy limitadas y bien definidas por un tiempo. Por ejemplo, pídales que implementen algunos métodos en clases que ya haya definido y para las cuales ya haya implementado pruebas unitarias.

Una vez que puedan hacer una cosa muy limitada de forma aceptable, muévalos a otro tipo de tarea. Después de un tiempo, podrán 5 cosas bien, luego 10, y así sucesivamente.

Tengo que preguntar: ¿cuál fue su participación en el proceso de contratación de esta persona? ¿Los entrevistaste? ¿Le permitieron registrar una opinión sobre el nivel de habilidad del alquiler?

Para un equipo de desarrollo de dos personas, evitaría contratar a cualquiera de los miembros del equipo directamente fuera de la escuela. Simplemente no hay suficiente holgura en un equipo tan pequeño para soportar la cantidad de aprendizaje en el trabajo que necesitarán.

Mi sugerencia es preguntarle cómo cree que está. Si él piensa que está haciendo algo increíble y que es lo mejor del universo, entonces es posible que tengas un problema mayor. Por otro lado, si cree que se está recuperando, puede que no sea tan malo intentar mostrarle algunas de las cuerdas. Sugiero darle tareas más pequeñas y revisar partes de lo que escribe para que no esté tan equivocado que es una maravilla que haya llegado a ese punto.

Otra parte de esto es la cuestión de qué tipo de relación existe entre usted y el nuevo tipo. ¿Eres su jefe, un compañero de trabajo o algo más? Sospecho que si tiene una charla con él sobre algunas cosas, puede ayudar a aclarar las cosas. Recuerdo que en mi primer trabajo tuve que tener una mano pequeña para superar una prueba inicial por asignación de fuego. Si puede, trate de tener un par de veces al día donde hay una especie de check-in en términos de dónde está y qué está haciendo.

Muchos buenos puntos aquí, así que solo añadiré un poco.

Soy un gran admirador de las revisiones de código, pero cuando se trata de un codificador novato, la cantidad de "problemas" que encuentra en el código puede ser abrumadora. Tiendo a revisar el código y luego revisar las notas con el otro desarrollador. Tengo mucho cuidado de separar los problemas reales y la "mierda pedante" (que etiqueto y pongo al final, es decir, no hay comentarios aquí, el estilo de denominación es incorrecto, encuentra un mejor nombre para esto, etc.).

También estar dispuesto a hacer la extraña compensación. La ciudadanía es importante, por lo que si el novato agrega un nombre de clase que solo está bien, pero puede pensar en uno mucho mejor, considérelo para que guarden su nombre y sientan que son "dueños" de una parte del sistema.

Ah, y si está revisando su código HIS, haga que revise el suyo también. ;)

No hace mucho tiempo que era un novato, y recuerdo cómo se siente y las cosas que me ayudan y las cosas que no me gustaban demasiado.

Consejos:

No lo pongas en un proyecto donde él es el único programador de ese proyecto. Póngalo bajo un desarrollador líder y asígnele tareas pequeñas que se pueden completar en un corto período de tiempo. Será más fácil para él estimar algo que podría tomar 16 horas de trabajo en lugar de algo que podría llevar 80 horas. En este momento, probablemente tenga miedo de dar estimaciones porque no quiere darle una "respuesta incorrecta". Teme que te diga 32 horas cuando esperabas 8 o algo así. jaja, siempre tuve miedo de eso.
Revisar el código antes del check in es bueno, pero que él mismo solucione los problemas. Si haces cambios significativos en su código para él, puede hacerlo sentir mal.
No recomendaría la programación de pares. Siempre quise darme cuenta por mi cuenta de esa manera cuando lo hago bien, obtengo todo el mérito. Pero más bien esté disponible para él en cualquier momento para que pueda hacer preguntas. Estar en la misma sala con los otros codificadores del proyecto es muy importante, especialmente para un programador novato. La programación de pares puede ser buena más adelante, pero como novato, me gustaría trabajar por mi cuenta.
Saber cuándo hacer preguntas es una habilidad en sí misma en mi opinión. No quieres molestar demasiado al tipo que está detrás de ti, pero de nuevo no quieres buscar en google durante medio día y terminas girando ruedas todo el día cuando el tipo que está detrás de ti sabe el contestador de inmediato. Anímelo a buscar respuestas por su cuenta, pero no tema pedir ayuda si no puede encontrarla fácilmente.
Definitivamente necesita aprender a comentar el código. Revisar el código de otras personas le enseñará la importancia de eso. Él tiene que aprender a escribir "código de auto documentación". El "Qué" debería documentarse automáticamente utilizando buenos nombres de variables y técnicas de codificación bien pensadas y fáciles de leer. A veces, los comentarios son necesarios para decir que el código "Por qué" está escrito de cierta manera.
Hacerlo hacer revisiones de código es bueno. Tal vez te emparejes con él y tú y él puedan revisar el código de otra persona con él.
No tome el teclado con demasiada frecuencia. Por un minuto está bien, pero si él es un programador, mejor aprenda a escribir lo más pronto posible, y la práctica es la única forma.
Como alguien más mencionado anteriormente, le encantará saber que está haciendo un buen trabajo, así que ¡asegúrate de decirle cuándo ves algo que él hizo y te gusta!

Parece que los problemas del chico nuevo podrían detectarse demasiado tarde en el proceso.

Además de revisar su trabajo en curso y el código que ha escrito, enfatice el análisis y la planificación inicial. Al darle una tarea, haga que esboce la definición del problema, los algoritmos y el calendario en una pizarra. Discuta con él largamente y solucione cualquier problema que vea en esa etapa, en lugar de esperar hasta que haya pasado el tiempo y el daño esté hecho.

Según mi experiencia, cuanto antes se detecta un problema, más rápido y más barato es solucionarlo.

Se ha dicho casi todo lo que se necesita decir, muchos buenos consejos.

Solo agregaría una cosa: puede que no se dé cuenta completamente del alcance de su trabajo, que la estimación, las pruebas escritas, el seguimiento de errores, etc., en realidad son parte de la tarea y son totalmente su responsabilidad. Tal vez una charla sin confrontaciones en la que explícitamente deja esto en claro -y dejar en claro que necesita ser autodirigido- podría despejar la confusión sobre lo que se espera de él.

Puntos sobresalientes por tratar tan duro de hacer lo correcto.

Tal vez debería desarrollar una "lista de verificación" de los estándares de codificación aceptables para su empresa. Por ejemplo, podría incluir algunas cosas como esta:

Todos los métodos están documentados y siguen C # / Java / standards. Puede hacer cumplir esto proporcionando enlaces relevantes a esos estándares para que sepa dónde buscar.
Cada método es claro y eficiente. Esto es un poco subjetivo, pero es un elemento de la lista de verificación que le da puntos para hablar con él mientras revisa su código, y lo ayudará a ver dónde necesita mejorar.
Cada método arroja las excepciones adecuadas. Si define excepciones personalizadas en sus diseños (una buena práctica en general), asegúrese de que los esté utilizando correctamente.
No hay redundancia de código. Asegúrese de que el código común se tenga en cuenta en los métodos de ayuda, etc.
Las tecnologías se usan correctamente. Por ejemplo, si lo ves escribiendo un método de "subcadena" para una cadena, debería saber utilizar el método de subcadena en la clase de cadena en lugar de reinventar la rueda.

El punto es que, al tener una lista de verificación / cuadro de mando, le da una manera de revisar su código un poco más subjetivamente y le da valiosos comentarios sobre cómo mejorar.

Y creo que te ayudará a "mantener las manos fuera del teclado" :).

Buena suerte.

Tengo un problema similar en mi trabajo en este momento. Estoy haciendo lo siguiente

Enviándole correos electrónicos con enlaces a videos útiles en línea (por ejemplo, el código de limpieza de Google).
Peer revisando todo lo que hace.
Recientemente comencé a asegurarme de que comenta los métodos y las clases con sus responsabilidades antes de comenzar a codificar, para ayudarlo a pensar qué es lo que intenta hacer y para garantizar que cada método y clase solo tengan la responsabilidad.
Ofreciéndole libros para leer (por ejemplo, Código completo sentado en mi estante)
Ofreciendo complementos y no decepcionándolo, y donde tengo que señalar cómo algo está mal, ser constructivo. Todos éramos jóvenes y experimentados una vez ...

Usted mencionó FogBugz. Si está utilizando EBS, pedirle estimaciones debería resolverse en un plazo no tan largo. Me gustaría agregar mi voto a la opción "darle pequeñas piezas de trabajo discreto".

Tuve un desarrollador que realmente tuvo problemas para mantenerse al día con los requisitos y evitar agregar funciones de "bonificación". Sé que no es exactamente el mismo problema, pero creo que la solución podría ayudar. Nos juntamos durante 15 minutos cada dos horas para revisar lo que él había hecho, cómo lo había hecho, qué planeaba hacer a continuación y cómo planeaba hacerlo. Funcionó muy rápido y después de un pequeño número de semanas pudimos comenzar a extender los intervalos a cuatro horas, luego a diario y, finalmente, después de cada tarea de varios días.

Creo que lo principal es que, como han dicho otros, eres consciente de que hay un problema en ambos lados y aquí estoy buscando ayuda para abordar ambos lados :-)

No le presiones con el tiempo.
Divida las tareas tanto como sea posible - de hecho descomponga las cosas en los pasos más pequeños que pueda imaginar
No espere que le dé estimados de tiempo útiles
ASEGÚRESE DE HABER REVISADO EL CÓDIGO. Revisa el código y da buenos comentarios.

Anímalo cuando puedas.

Felicitaciones a ti por querer ser tu mentor.

Los niños que salen de la escuela no tienen habilidades útiles de desarrollo grupal y nunca tuvieron que trabajar en el código que debía mantenerse. Este es un gran paso, pero uno que debe y puede superarse dentro de un mes o menos.

El problema principal es establecer expectativas para el trabajo que va a producir. Si él sabe que se le controlará todo y que usted es consecuente con la calidad, entonces eventualmente debería hacer cola.

Si no lo hace, hay otros problemas que debe resolver.

Buena suerte