Me acabo de enterar de que mañana recibiré a un estudiante de secundaria que está interesado en el software. Me tomo estas cosas bastante en serio: recuerdo que tenía esa edad y me dijeron que de repente tomara decisiones que literalmente darían forma al resto de mi vida sin ninguna experiencia para juzgar esas decisiones, sin saber qué consejo debería tomar o ignorar. Tuve un momento difícil y entré sabiendo exactamente lo que quería hacer.
De todos modos, estarán aquí durante la primera mitad del día. Supongo que el cuestionario que traen tomará 10 minutos, y estoy luchando un poco sobre cómo mostrarles lo que hago sin decir "bueno, solo siéntate aquí y mira mientras escribo un texto colorido". Realmente me gustaría involucrarlos o mantenerlos comprometidos, pero para un trabajo como el de ingeniería de software no puedo darles exactamente el timón si (comprensiblemente) no tienen idea de lo que están viendo.
¿Alguien tiene algún consejo para mantenerlos comprometidos? ¿Actividades? ¿Algo "divertido" sin parecer patético? ¿Es suficiente explicar a fondo en qué estoy trabajando?
Mis antecedentes: BS. en Ingeniería Informática. Un poco más de 4 años en el campo como ingeniero de software. Estoy en mi segunda empresa y recién comencé aquí hace un par de meses; tuve un par de correcciones de errores en nuestra base de código principal (que es bastante grande) y comencé y terminé un pequeño proyecto.
Acerca de mañana: Mi agenda está abierta (sin reuniones ni nada). Además, lo más probable es que no pueda involucrar a nadie más en el equipo. Nuestro próximo gran lanzamiento literalmente tendrá lugar hoy o mañana, así que prefiero no quitarle el tiempo a nadie.
Déles una breve explicación de la empresa, la industria, los productos y su rol.
Por supuesto, puede dejar que toquen el código, pero no algo en producción.
Guíelos, creando una rama de control de fuente para que no puedan dañar nada (suponiendo que no tenga intención de fusionar esto). Hábleles de los beneficios del control de código fuente.
Habla con ellos sobre el código. Un programador pasa mucho tiempo leyendo estas cosas. Vea lo que son capaces de descifrar. Elija algo simple y déjelos hacer un cambio. Compílelo (es posible que no funcionen con lenguajes compilados). Muéstreles algunas pruebas unitarias. Hagas lo que hagas
No olvide las comunicaciones, reuniones, documentos, seguimiento de errores, etc.
El nivel de habilidad podría estar en cualquier lugar. Expóngalos tanto como pueda. Recomendar recursos. Dígales que creen una cuenta de StackOverflow. Accede a GitHub. Creo que el objetivo no debe ser solo que esta persona tenga una comprensión perfecta de lo que hace un programador, sino que se vaya con alguna dirección y herramientas para seguir aprendiendo sobre programación. No depende de usted mostrarles lo difícil que es (es difícil, en este momento) o hacer todo lo posible para mostrarles el lado "divertido" del trabajo ni está allí para "eliminar" a los candidatos pobres.
Piense más en ser un facilitador.
matt krause