language agnostic - Cómo guiar a un programador junior

language-agnostic (12)

Aquí estaría mi lista corta:

Programación de pares: esto es útil para muchas cosas, como reforzar varias ideas y prácticas. Acostumbrarse a Resharper es mucho más fácil cuando te emparejas con alguien que lo usa a menudo.

Charlas 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 que se realiza inmediatamente o puede ser elementos filosóficos abstractos que pueden ayudar a que el juego de alguien suba un escalón o dos. 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.

Por lo tanto, 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.

¿Alguien tiene alguna sugerencia sobre cómo ser mentor de un programador junior? Si has sido mentor de alguien, ¿sigues algún proceso o es bastante informal?

Si te han enseñado en el pasado, ¿qué tipo de cosas te parecieron más útiles?

Como tenía que explicar por qué quería cooperar (además de necesitar el dinero) durante mi entrevista, mi gerente se aseguró de que mi primer proyecto me permitiera trabajar en lo que había identificado como áreas débiles: muy poca experiencia en Linux (elegí un El equipo de I + D solo para Linux me obligaría a aprender), no conocía un editor de texto útil (realmente quería aprender Vim) y cómo aprender otro lenguaje de programación (un enfoque muy diferente al aprendizaje de un idioma a medida que aprende a programar) . Me dijo que me pagaban para estudiar por un tiempo.

Aprendo mejor leyendo libros, así que después de reírme de Unix for Dummies (¡no! No era el único que pensaba que esto era oscuro y nudito a veces) comencé con Unix en Nutshell y Sobell''s Practical Guide to Linux Commands . 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 ahora que hubiera sido maravilloso reunirme con alguien todos los días o dos para la revisión del código, como dijo Kamikaze Mercenary.

Durante una pasantía con una compañía 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 las que la tutoría funcionó tan bien:

Creíble : el mentor tenía más de 8 años de experiencia y un historial consumado al que recurrir para dirigir y entrenar. Había pasado por diferentes desafíos, trabajó en diferentes entornos, por lo que tenía una gran perspectiva.
Genuino : el supervisor alentó la tutoría, pero no tan formal como para convertirla en un ejercicio de control. El mentor quería ser mentor y quería que alguien aprendiera de él.
Pasión : al mentor le encantó el campo en el que estaba, los problemas que estaba resolviendo y las tecnologías que estaba usando. Cuando estuve bajo su protección, descubrí que esto es contagioso.
Sharp y Articulate : el mentor enfocó los problemas de manera crítica y los enmarcó concisamente. No hubo mucha confusión en nuestras discusiones; llegamos a la raíz del asunto y él me dirigió en sabios cursos de solución de problemas y acción.
Significativo : el trabajo que estaba haciendo con el mentor fue un trabajo significativo, no solo un ejercicio para mantener ocupado o aumentar en un conjunto de habilidades. Al trabajar en conjunto en una tarea que ayudó tangiblemente a la organización, eso ayudó a centrar mi interés y legitimar el proceso de tutoría.

En mi experiencia al ser mentor de alguien, es muy importante que el mentoree realmente quiera aprender más.

Nunca lo hagas 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 puesto de trabajo había un tipo muy paciente que siempre me ayudaría a resolver mi problema inmediato y luego me enseñó un importante principio subyacente. Me encantó esto porque me ayudaría a ser productivo mientras me enseñaba cómo ser un mejor programador.

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ódigos. Estas tareas fueron fáciles de completar, así que tuve 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.

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.

Intente separar entre 30-60 minutos por 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 tu mentor y en su lugar ver si alguien más tiene un horario que lo permita. El objetivo de la tutoría es ayudar activamente al desarrollo profesional del alumno, y no aprenderán mucho si no se les brinda la atención y la orientación adecuadas.

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 pistas para que descubran el problema. Esto es más que dar la respuesta de, "Solo saca esta línea de código", sugiere que miren lo que hay allí y que sea todo necesario.

Recomiendo 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 forma, 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.

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 empezamos a ser entrenados juntos, en un estilo similar a la programación de pares , 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 "todo lo que sabe, escúchame". Cuando recibimos sugerencias, él escucharía y pensaría con nosotros si eran buenas o no. o dar su punto de vista 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 sentarse allí ''tomando órdenes de alguien que probablemente sabe qué hacer mejor que usted.

En resumen:

Deje que el programador junior trabaje (en su mayoría) solo para estudiar los materiales disponibles, dele una lista de cosas TODO menores como buscar información o crear pequeños demos.
Revise el trabajo que ha hecho regularmente y avísele si hay mejores maneras de hacer las cosas. También señale los elementos que realmente hizo bien, de esa forma los recordará para más adelante.
Permita que trabaje en un proyecto real y enséñelo trabajando en el mismo proyecto, brindándole consejos cuando tenga preguntas.
El esfuerzo tiene que venir de ambas direcciones: anímalo a hacer preguntas, a desafiar ''la forma en que se hace actualmente''. Hágale preguntas sobre cómo él piensa que debería hacerse y dígale también su opinión.
Haz que sea ''agradable'': no dejes que parezca que estás dando órdenes.

Yo 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!