Nuevas tareas de desarrollador senior

21

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?

MrBliz
fuente
1
Realmente depende de cuán complicadas sean esas 11,000 líneas de código. Esperaría que alguien con 8 años (eso significa que comenzó a usarlo en 2003) pueda correr a toda velocidad dentro de una semana.
Ramhound
Como punto de datos, hace unas semanas, reasignamos un desarrollador a un proyecto con 13,700 líneas de código JavaScript y asumimos que sería productivo en un sprint (una semana) sin siquiera pensarlo realmente.
Gort the Robot
@StevenBurnap: Me gusta :) Encienda los pies y vea si quema la casa.
Joel Etherton
¿Soy realmente el único que piensa que 11k líneas no es mucho? Hubiera dado un día, por la bondad de mi corazón.
Louis Kottmann
Parte de su elección de tareas también puede depender de qué tan tarde va a ser su proyecto. Para obtener algunas ideas sobre cómo limitar el impacto del nuevo personal en el personal existente, consulte programmers.stackexchange.com/questions/164781/…
DeveloperDon

Respuestas:

38

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.

HLGEM
fuente
Esa es una gran respuesta, especialmente la parte sobre las revisiones de código y la opinión de los desarrolladores sobre el estado actual del proyecto. Afortunadamente no es un proyecto heredado, de hecho es muy nuevo y avanza a un ritmo muy rápido.
MrBliz
1
+1: muchos puntos buenos, pero me gustaría reiterar que es absolutamente esencial revisar todo su trabajo para que pueda evaluar su nivel de habilidad y asegurarse de que estén en la misma página que el equipo. Desafortunadamente, esto lleva mucho más tiempo que las primeras dos semanas. Otro +1 por no tan bueno como en la entrevista. Lo que le sucede a muchas personas entre la entrevista y el día en que aparecen es un misterio para mí. ¿Las lobotomías son realmente tan comunes como parecen? Esa es la única explicación que se me ocurre.
Dunk
Sí, revise su trabajo para asegurarse de que no se desvíen de los estándares establecidos. Pero si tienen ocho años de experiencia y usted tiene tres , probablemente sepan más que usted . Asegúrese de no obligarlos a hacer las cosas a su manera.
DJClayworth
2
@DJClayworth, si bien estoy de acuerdo en que es probable que la nueva persona tenga más conocimiento y que el OP debe prestar mucha atención a lo que quiere hacer de manera diferente, hay momentos en que su conocimiento del sistema y los requisitos pueden superar su mejor conocimiento general y Es posible que deba indicarle que tome un camino menos que óptimo por razones que se basan en la historia del sistema y los requisitos. A veces es necesario insistir en que hagan las cosas a su manera por razones que aún no conocen. Por supuesto, cuando lo haga, debe explicar por qué, no solo siempre lo hacemos así.
HLGEM
@Dunk: en mi experiencia, incluso las peores personas del mundo pueden comportarse durante unas horas durante una entrevista, cuando están desesperadas por un trabajo. Es por eso que el contrato de contratación, las pasantías y los ejemplos de código son tan importantes con los nuevos empleados.
Jordania
18

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.

Oded
fuente
Esto es más o menos lo que estoy pensando.
MrBliz
+1, esto es obvio, especialmente porque la base del código es pequeña.
Louis Kottmann
8

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.

aceinthehole
fuente
+1 Cuanto antes el nuevo empleado pueda comenzar a examinar el proyecto, antes se sentirá cómodo (dispuesto a asumir la responsabilidad / responsabilidad) de lo que está haciendo.
Chad Harrison
3

¿Cuánto tiempo?

¿Cuánto mide una cuerda?

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

Noche oscura
fuente
3

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!

Aprende todos los dias
fuente
2

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).

Bill Leeper
fuente
Interesante que todos asuman que es un chico ... :)
MrBliz
1. Yo diría en inglés que el pronombre predeterminado es masculino, escribir "él o ella" todo el tiempo sería apropiado, pero requiere más esfuerzo del que la mayoría de la gente quiere presentar. 2. ¿Qué porcentaje de programadores son mujeres? En este caso, el valor predeterminado de masculino tiene estadísticas de su lado ... Por lo tanto, me imagino que es más simple usar la forma simple predeterminada para referirse a un individuo aleatorio, sin suponer específicamente que son hombres o mujeres.
Thymine
Soy un chico y todos los demás también deben serlo :-). Solo por mi forma de escribir, no soy lo suficientemente disciplinado como para escribirlo todo el tiempo.
Bill Leeper
1

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).

Telastyn
fuente
2
Creo que mis estándares son probablemente demasiado altos, pero ¿los suyos ... 1 día ... y 1 semana para ser realmente productivo? IME, eso no es muy realista.
Dunk
@Dunk: ¿se le asignarán tareas y podrá abordarlas sin perderse por completo? No estoy diciendo que van a estar a toda velocidad, pero en ese momento que debería ser capaz de cazar a través de la base de código, saber a quién preguntar para aprender más, etc
Telastyn
Sí, en serio. 11k LoC no es muy grande. Prepárelo para que se desarrolle y se ejecute en el depurador y luego muéstrele cómo funciona. Eso debería bastar.
gbjbaanb
1

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.

jmoreno
fuente