¿Alguien tiene alguna sugerencia sobre cómo orientar a un programador junior? Si has sido mentor de alguien, ¿sigues algún proceso o es bastante informal?Cómo guiar a un programador junior
Si has sido mentoreado en el pasado, ¿qué tipo de cosas te parecieron más útiles?
Trate de reservar entre 30-60 minutos al día para revisar su código juntos. Si no puede hacer esto, intente reunirse para revisar su código cada vez que cometen un código, a menos que sea muy básico. Pídales que expliquen por qué eligieron el enfoque que tomaron en lugar de los demás. Un proceso como este ayuda a establecer una gran relación, así como a estimular al estudiante a pensar por sí mismo y ser capaz de defender sus decisiones. El alumno no solo termina contactando con alguien de confianza, sino que también notará una mejora en su calidad de código y lógica casi de inmediato.
Editar: Además, si no puede dedicar tanto tiempo a la co-revisión con su junior, entonces probablemente no debería ser tutora y en su lugar ver si alguien más tiene un horario que lo permita. El objetivo de la tutoría es ayudar activamente en el desarrollo profesional del alumno, y no aprenderán mucho si no se les brinda la atención y la orientación adecuadas.
¡Respuesta asombrosa! – traditional
Sería el junior, supongo :) Creo que valoraría un enfoque informal. Probablemente dependa mucho de los personajes de usted y de su aprendiz, pero yo diría que aprende mejor si no tiene egos en el camino. Rompe el hielo, asegúrate de que haya comentarios en ambas direcciones. Cosas como la revisión del código (en ambos sentidos?) Y la programación ocasional de pares pueden funcionar, y si hay una buena coincidencia, ¡puede ser muy divertido también!
He sido mentor de varios jóvenes antes que yo. Mi enfoque varió ligeramente en función de la persona basada un poco en cómo aprendieron.
En resumen, les di a los jóvenes proyectos pequeños y autónomos cuando pude y les di un tiempo relativamente fijo para completar la tarea. Una vez que se completara la tarea, revisaría su enfoque, código y solución e introduciría sugerencias para mejoras o una mejor manera de manejar el problema. Creo que de esta manera no se sienten abrumados de ser parte de un proyecto mucho más grande.
Espero que esto ayude un poco.
Tuve la oportunidad de trabajar como interno (uno de dos) en una pequeña empresa de software y tuve la oportunidad de trabajar en un proyecto "casi nuevo" que tenían. Me hicieron configurar todo lo que necesitaban y me dieron una introducción sobre el proyecto en realidad (cosas básicas como cuáles eran los requisitos, etc.).
Al principio teníamos que hacer tareas menores, como investigar cosas importantes para el proyecto (nos habían dado una lista de temas). Esto fue, creo, para ver cuánto podíamos manejar nosotros mismos, ya que las cosas que necesitábamos buscar e investigar no eran tan triviales y nos tomó unas buenas 2 semanas más o menos (contando los demos básicos que tuvimos que crear para ello) . Esa fase de prueba realmente se hizo realmente sin mucho 'coaching'.
Sin embargo, después de ese período podríamos trabajar en el proyecto mismo. Este fue también el momento en que comenzamos a entrenarnos juntos, en un estilo similar al pair programming, excepto que éramos tres (2 pasantes y 1 'entrenador').
Aprendimos mucho de él, pero fue de manera informal, y él no actuó como el tipo de "el que todo lo sabe, escúchame". Cuando recibimos sugerencias, él escucharía y pensaría con nosotros si eran buenas o no. o dar su opinión sobre por qué una idea no debería hacerse de esa manera ...Ahora que lo pienso, él nos alentó activamente a hacer sugerencias y a pensar en mejores formas de hacer las cosas, en lugar de simplemente estar ahí 'tomando órdenes' de alguien que probablemente sabe qué hacer mejor que usted.
Así que en resumen:
Esto es bueno. Uno de los problemas que he observado en la tutoría es que hay personas que corren con la pelota y otras que no. Actualmente soy de la opinión de que necesitas más corredores de bolas para tener éxito. – EvilTeach
Recomendaría comenzar a dar partes de las asignaciones reales que tiene y hacer todo lo posible para poder usar su código. En otras palabras, adiestralo como un reemplazo para ti.
De esta manera se comprometerá a asignar tiempo para trabajar con junior y podrá ver la "vida real". Al trabajar en asignaciones reales y escuchar comentarios vivos, podrá obtener p para acelerar bastante rápido.
El inconveniente de este enfoque es que es posible que tenga un enfoque demasiado limitado en su proyecto en particular. Así que asegúrese de mostrar al alumno posibles alternativas y alentar el análisis de intercambios para ampliar su horizonte profesional.
Hace un par de años trabajé para una empresa pequeña, donde el primer día me dieron una lista de pequeñas tareas para completar: hacer algunos pequeños cambios en el código, encontrar y corregir un pequeño error en el proyecto. Realmente me ayudó a hacer las preguntas correctas de mi mentor y a familiarizarme con el entorno, la base de código. Estas tareas fueron fáciles de completar, así que tenía un poco de confianza en mí mismo, antes de pasar a las tareas más grandes.
Esta forma de tutoría realmente funcionó muy bien conmigo, así que estoy planeando hacer lo mismo con nuestro nuevo colega.
Durante una pasantía con una empresa grande que tenía mucha informática interna, me emparejaron con un mentor. La práctica definitivamente ayudó al desarrollo de mi carrera, tanto en términos de habilidades técnicas como comerciales. Estas son algunas de las razones por la tutoría funcionó tan bien:
Porque tenía que explicar qué me querían para co-op (además de necesitar el dinero) durante mi entrevista, mi manager hecho de que mi primer proyecto me permitió trabajar en lo que me había identificado como áreas débiles: muy poca experiencia en Linux (elegí un equipo D de Linux solo R & D, así que me vería obligado a aprender), sin conocer un editor de texto útil (realmente quería aprender Vim), y cómo aprender otro lenguaje de programación (enfoque muy diferente que aprender un idioma mientras aprendes a programar). Me dijo que me pagaban para estudiar por un tiempo.
aprendo mejor por la lectura de libros, así que después de reír sobre Unix para los maniquíes (yay! Yo no era el único que pensaba que esto era oscura y knuckleheaded veces) Empecé con Unix en una cáscara de nuez y Sobell de Guía práctica para los comandos de Linux. Después de eso, imprimí la documentación de Vim y comencé a revisarla. Luego revisé un par de libros sobre Python, el lenguaje de mi primer proyecto. Me dieron todo el tiempo que necesitaba para sentirme cómodo con estas cosas (que era el problema real, como ahora entiendo) y luego comencé a agregar funcionalidad al proyecto de una cooperativa anterior.
Me doy cuenta de que hubiera sido maravilloso reunirme con alguien todos los días o dos para la revisión del código, como dijo Kamikaze Mercenary.
Aquí sería mi pequeña lista:
programación Par - Esto es útil para muchas cosas, como refuerzo de diversas ideas y prácticas. Acostumbrarse a Resharper es mucho más fácil cuando te emparejas con alguien que lo usa a menudo.
Chats informales - Aquí es donde íbamos a tomar una copa, salir para que alguien tomara una pausa para fumar, ir a almorzar juntos, etc. Mientras se encuentra lejos de los escritorios, la discusión puede estar relacionada con el trabajo realizado inmediatamente o puede ser material filosófico abstracto que puede ayudar a que alguien juegue un poco más allá. Hablar de varias tecnologías futuras o cambios en lo que viene puede ser emocionante y ayudar a formar vínculos también.
Comentarios y sugerencias: esto es lo que ocurrió en ambos casos anteriores. Libros como "Cómo ganar amigos e influir sobre las personas" de Dale Carnegie pueden ayudar a comprender varias dinámicas de relaciones humanas, que si bien suena bastante técnico, realmente se trata de cómo motivar a otra persona de varias maneras. Un punto clave aquí es saber cómo dejar un rastro de migas de pan para recoger algunas prácticas, como dar pistas tras pistas sobre algo en lugar de simplemente dar la respuesta. He tenido varios maestros de Matemáticas que tenían un don para esto por cómo desarrollé algo de esta habilidad.
Así que parte de esto es simplemente motivar a la otra persona y tratar de guiarlos, ya que cuando alguien se da cuenta de algo por sí mismo puede ser una experiencia fortalecedora e iluminadora. El, "¡lo hice! ¡Es correcto, moi, tu verdad!" una especie de diálogo interno es bastante bueno cuando sucede.
En mi experiencia al ser mentor de alguien, es muy importante que el mentoree realmente quiera aprender más.
Nunca alimente con cuchara. En su lugar, apúntelos hacia las cosas de valor y pídales que utilicen la nueva información que están aprendiendo en los proyectos que están utilizando. El conocimiento es inútil si no se pone en práctica. Así que aliente a su mentoree a codificar, codificar, codificar.
En mi primer empleo había realmente paciente tipo que siempre me ayudaría a resolver mi problema inmediato, y luego me enseñó algún principio subyacente importante. Me encantó esto porque me ayudaría a ser productivo mientras me enseñaba cómo ser un mejor programador.
Pregúnteles qué intentarían a continuación para completar la tarea. Esto puede dar una idea de dónde, desde la categoría "No sé qué hacer" hasta "Bueno, probaría esto, pero ..." están en términos de tener su propia idea que puede ser útil para un punto de partida .
Eche un vistazo rápido a lo que quieren hacer y ofrezca sugerencias para que descubran el problema. Esto es más que dar la respuesta de: "Simplemente saque esta línea de código", sugiera que miren lo que hay allí y todo es necesario
más útil: un periódico enrollado –
@Steven A. Lowe: Usted trajo tantos recuerdos de cuando entrené a mis perros. :) –