¿Cómo incluir desarrolladores novatos en tu proyecto?

Estamos considerando enseñarles a algunos empleados que tienen experiencia en programación de nivel cero o general para aficionados a quitarme la carga de trabajo.

Utilizamos Python / Django, que tiene la documentación más amigable y muy fácil de aprender.

Actualmente soy un departamento de TI de un solo hombre para mi empresa y no tengo suficientes horas para desarrollar todo lo que la empresa necesita. No somos una empresa de software, pero ayuda tener TI interna para automatizar tareas, desarrollar funciones de servicio al cliente, analizar datos, etc.

¿Cómo integras lentamente a los novatos que trabajan en tu base de código? Digamos que tienes un interno, ¿qué hacen? Soy completamente reacio a permitirles diseñar o desarrollar código central, ya que nos ocuparemos de sus errores / patrones de diseño extraños durante años. Como desarrollador principal, seré yo quien tenga que solucionar su código.

Mi idea era que los novatos solo modificaran el código existente, nunca construyeran funciones centrales. Puedo descargarles el trabajo con tareas simples después de construir la función en sí.

Queremos que nuestros empleados aprendan / encuentren valor en la empresa, y generalmente tenemos personas que "suben de rango".

¿Es una práctica estándar enseñar a personas con programación de nivel general / aficionado? ¿Cómo funciona el "subir de rango" en una empresa de software para programadores de nivel junior? ¿Cuándo comienzan a trabajar en el código central?

Estoy tratando de decidir si va a causar más daño que la ayuda, y si hay una manera de que podamos usar su ayuda sin potencialmente arriesgar el código del sitio central (¿entornos aislados?).

Si delega al novato a un papel ineficaz, él / ella nunca aprenderá nada sustancial, y ciertamente no serán demasiado terriblemente útiles para usted.

Permíteme darte un consejo, mi primer trabajo de TI fuera de la escuela fue en una empresa de fabricación relativamente pequeña donde iba a trabajar en software para ayudar a los ingenieros de ventas a escribir presupuestos para varios proyectos. También se suponía que debía ayudar al tipo de TI que manejaba la TI por sí solo para toda la empresa.

El tipo era un desastre estresado con exceso de trabajo, y el peor perfeccionista de microgestión en el que he trabajado. Se suponía que debía aligerar su carga de trabajo, pero él pasó casi tanto tiempo preocupándome por mí y mi trabajo de manera preocupante como yo pasaba trabajando (casi nunca salía de la oficina, creo que despreciaba a su familia). Si cometiera un solo error, él perdería la cabeza por completo y comenzaría a hacer un berrinche, "¡Sabía que no debería haber confiado en ti con esto, era demasiado importante!" y otras diatribas.

El punto que estoy tratando de hacer es NO ser así. No solo hará que los novatos se sientan miserables y destruyan su moral, sino que también encenderán la vela en ambos extremos preocupándose por su trabajo.

Bríndeles la oportunidad de demostrar su valía pero que tengan especificaciones técnicas formales, revisiones de diseño y revisiones de código. También puede probar lo que producen para asegurarse de que cumpla con los requisitos.

Creo que te sorprenderá lo capaces que pueden ser algunos de ellos.

Solía ​​trabajar en una tienda de software, donde estábamos codificando un proyecto grande (tiempo de aceleración significativo).

Los novatos fueron tratados como veterinarios. Se les asignó un líder técnico y comenzaron las funciones "por su cuenta". El estilo de la arquitectura fue dictado, pero fueron libres de crear su propio diseño limpio. Los "patrones de diseño extraños" fueron eliminados durante las revisiones (diarias) del código de pares.

Un error que he visto en otra tienda: suponga que "core" es difícil y que "ui" es fácil. A los novatos les fue más fácil en el núcleo y desordenaron el código de interfaz de usuario de la interfaz de usuario.

¡Buena suerte!

Desea comenzar dándoles funcionalidades de piezas pequeñas y discretas para implementar. Defina la entrada que promete y la salida que espera, y permita que conecten los puntos. Y luego use la revisión del código líder del equipo para garantizar la calidad, y la revisión por pares para capacitarlos a aprender unos de otros y a aprender ellos mismos.

Esto supone que tiene una arquitectura de aplicación general que permite construir unidades atómicas de lógica de manera desacoplada. Si no, te diriges a un mundo de dolor cuando varios desarrolladores trabajan en él, ese sería el caso incluso con viejos profesionales.

Inevitablemente, tendrás ciertas personas que lo aprenderán, aprenderán rápido y se levantarán. Asegúrese de seguir alimentándoles tareas que son solo un pequeño paso más allá de su capacidad actual. Nada educa a alguien como una tarea que comienza imposible. Inevitablemente, tendrás algunas personas que lo intentan y nunca lo agarran realmente. Se debe agradecer a esas personas por sus esfuerzos y hacer una transición con gracia a otra cosa.

¿Cómo puede su empresa darse el lujo de alejarse de otros empleados, pero no contratar a alguien con experiencia en programación? La cantidad de su tiempo de entrenamiento, resolución de problemas y mantenimiento de la mano es costosa.

Lo único que he hecho en esta área es enseñar a las personas cómo usar un redactor de informes o tal vez algún código VBA / Macro para Excel. Normalmente doy los conjuntos de datos para reutilizar. Hacer que aprendan SQL es difícil, pero lo he visto hecho (les pagué para que recibieran capacitación externa). La mayoría de estas personas eran analistas financieros que tienen la capacidad de aprender a codificar, pero puede que no se hayan tomado el tiempo. Intentar esto con algunas personas en operaciones es una posibilidad remota.

Asegúrate de encontrar a la persona adecuada y realmente quieren aprender a codificar. No tendrás tiempo para enseñarles todo. Tendrán que hacer mucho por su cuenta.

@louisgab tenía razón sobre la revisión del código. Ese sería mi primer paso también. Una cosa crítica que lo ayudará es asegurarse de que tengan que corregir sus propios errores, ya sea que los encuentre en la revisión de código o más adelante. Ganaron; ni siquiera se dan cuenta de que están cometiendo errores a menos que tengan que corregirlos. Asegúrese también de explicar por qué la solución que usaron es un error y por qué lo que propone es mejor. Las primeras semanas se sentirá como si tuviera más trabajo por tener a estas otras personas, pero si hace sus revisiones de código y explica las cosas y espera que aprendan, en unas pocas semanas serán de mucha más ayuda que si solo hazlo todo tú mismo. Pero hay un compromiso inicial de su tiempo para ponerlos al día de lo que su gerencia necesita estar al tanto.