Nuevas tareas de desarrollador senior

Tengo un desarrollador senior con ocho años de experiencia .NET a partir de mañana para trabajar en una aplicación de 11,000 líneas de código. En el equipo estoy yo y otro programador. Ambos tenemos unos tres años de experiencia cada uno.

Es mi primer proyecto como gerente (también soy desarrollador del proyecto) y esta es la primera vez que tengo que presentarle a alguien una base de código ya establecida. Obviamente, revisaré cada módulo, el proceso de implementación, etc., y les daré la ubicación del repositorio de control de origen, la documentación (que no es la mejor), etc.

¿Cuánto tiempo debo darles antes de que estén listos para comenzar a escribir nuevas funciones y corregir errores?

Asignaría un par de errores de baja prioridad el primer día, de esa manera nadie gritaría si no se hacen de inmediato, dando al nuevo desarrollador algo de tiempo para familiarizarse con la base del código.

Lo más importante es tener una revisión del código de todo su trabajo las primeras dos semanas. No querrás descubrir que el tipo va en la dirección equivocada o no sigue los estándares de codificación de la compañía durante meses. Es mejor asegurarse de que sepa lo que se espera desde el principio, y las revisiones de código lo aseguran. Por supuesto, creo que las revisiones de código son buenas para todos los empleados (revisamos el 100% de nuestro código antes de la implementación), pero son fundamentales para los nuevos empleados y deben hacerse en persona, donde puede responder preguntas y remitirlas a la documentación que tal vez no tengan. visto aún si es necesario.

Lo que no quieres es que venga un chico nuevo y use un estilo diferente al resto de ustedes. Las personas a menudo intentan seguir usando el estilo de código de su trabajo anterior, incluso cuando entra en conflicto con el estilo de código utilizado en el nuevo lugar, lo que puede crear confusión y molestia por parte de los otros desarrolladores.

Una cosa que he notado incluso con desarrolladores experimentados es que algunos de ellos no son tan buenos como parecían en la entrevista, la revisión del código lo ayudará a descubrir esto rápidamente, para que pueda solucionarlo. También los alentará a hacer algo realmente, he visto a nuevos empleados que no están revisados ​​por código arrastrar un proyecto sin mostrar lo que le estaban haciendo a nadie y luego irse una semana antes de la fecha límite que sabían que no iban a cumplir porque estaban en la cabeza y en realidad no habían completado ninguna parte del proyecto. Es mejor consultar temprano y con frecuencia con nuevas personas hasta que esté realmente seguro de que están funcionando.

Además, es normal que el nuevo individuo se horrorice por el estado de su proyecto heredado. No está diseñado como él cree que debería haber sido. Espera esto, escúchalo y no descartes automáticamente todo lo que dice. En particular, esta persona parece tener más experiencia que usted o los otros desarrolladores, puede ver cosas que no había considerado. Sin embargo, como gerente, debe equilibrar los cambios propuestos con la carga de trabajo y los plazos actuales. Es posible que todos quieran invertir algo de tiempo en aprender a refactorizar el código existente e invertir algunas horas en sus estimaciones de tiempo para hacerlo, especialmente si el nuevo individuo tiene algunas preocupaciones válidas. Probablemente no puedas soportar una reescritura total (muchas personas que vienen nuevas piensan que deberíamos comenzar de nuevo y hacerlo mejor),

Si tiene algún tiempo en el que no se espera que él esté contribuyendo completamente (y contabilizando completamente su tiempo por el cliente), también podría ser un momento en el que pueda comenzar con algunas de esas refactorizaciones que ha querido hacer pero que no tiene No tuve tiempo de hacer. A veces, es bueno usar el nuevo período de capacitación de personas para abordar algunas cosas que no están en el plan del proyecto. Pueden aprender la base del código y si lo que quieren hacer no funciona, no ha afectado los cronogramas existentes porque aún no los ha incluido en el cronograma existente. Y si funciona, es posible que tenga una gran victoria para facilitar el mantenimiento futuro o mejorar la seguridad o el problema.

Comience de inmediato en tareas pequeñas, cosas que no requieren una imagen más amplia.

A medida que estén más seguros y familiarizados con la base de código, graduarlos para tareas cada vez más grandes. La rapidez con que eso suceda depende principalmente de ellos.

Siempre me gusta que me asignen tareas desde el principio, entendiendo que tomará mucho más tiempo profundizar en el código, y se harán muchas preguntas durante los primeros días / semanas.

Me parece que no soy capaz de comprender completamente un proyecto hasta que tengo que entrar y arreglar o cambiar algo.

Además ... No importa qué tan bien creas que has explicado cómo funciona un proyecto, siempre existe el 'oh sí, olvidé decirte', 'nos encontramos con este problema, así que hicimos esto' momentos que no se descifraron hasta en realidad comienzas a trabajar.

¿Cuánto tiempo?

¿Cuánto mide una cuerda?

Cuando se siente cómodo: cuando arregla su primer error -> está listo .

En la comunidad de código abierto, todos los que querían unirse al proyecto primero lidian con algunos pequeños problemas. Si él o ella puede manejar el problema muy bien, se le asignará la tarea más importante. De esta manera, se convertirían en un desarrollador principal del proyecto.

Este desarrollador senior tiene ocho años de experiencia en .NET, por lo que puede asignarle algunos errores simples para que los arregle. Si le resulta fácil tratar con ellos, puede asignarle problemas complejos para ayudarlo a familiarizarse con toda la aplicación. Después de eso, podría comenzar a escribir nuevas características y analizar problemas extraños. ¡Solo hazlo, no tiene tiempo de configuración!

8 años de experiencia Simplemente lo arrojaría. Debería poder nadar. Como otros han señalado, comience con pequeñas tareas fáciles. Le permitirá pasar por el proceso de entrada / salida de código y cualquier otro proceso de desarrollo que tenga.

He cambiado de trabajo muchas veces y he contribuido en todas ellas durante la primera semana. Lo más difícil me llevó una semana obtener el código para compilar (100k + líneas de código al menos). Una construcción completa tomó 8 horas para ese proyecto.

Trabajé unas 80 horas la primera semana (el proyecto estaba muy retrasado).

Para una aplicación tan pequeña y un desarrollador experimentado, creo que un día es suficiente para errores básicos. Errores involucrados o pequeñas características más cerca de una semana (una vez que son más claros en el dominio del problema y la arquitectura).

La respuesta es, depende. Si desea que solucione un error por un error en algo o cambie el color de un elemento GUI, entonces aproximadamente 5 minutos (aquí es donde guardamos nuestro código), si desea un rediseño total de toda la arquitectura de la aplicación que Requiere un poco más de tiempo.

Realmente depende de la tarea que esperas que realice.