Estoy haciendo esta pregunta a los programadores de C ++ porque: a) Solo un programador de C ++ puede juzgar los méritos técnicos de los ejemplos; b) Solo un programador tendrá una idea del temperamento de otro programador que escriba código como este.
Recursos Humanos y los directores son conscientes de que hay un problema simplemente porque ven evidencia en el campo. Es mi decisión si le damos más tiempo al programador en cuestión. Muchos de los errores están en un nivel muy básico: mi pregunta (para los programadores) es si alguien que profesa ser un desarrollador senior de C ++ debería beneficiarse de una duda basada en muestras de su código actual. Los que no son programadores, incluso las personas que están fuera de la programación en C ++, no pueden juzgar esto.
Por antecedentes, me asignaron la tarea de administrar desarrolladores para una empresa bien establecida. Tienen un único desarrollador que se especializa en toda su codificación C ++ (desde siempre), pero la calidad del trabajo es abismal. Las revisiones y pruebas de código han revelado muchos problemas, uno de los cuales es la pérdida de memoria. El desarrollador nunca ha probado su código en busca de fugas, y descubrí que las aplicaciones podrían perder muchos MB con solo un minuto de uso. Los usuarios informaron grandes desaceleraciones, y su opinión fue: "no tiene nada que ver conmigo; si dejan de fumar y se reinician, todo vuelve a estar bien".
Le di herramientas para detectar y rastrear las fugas, y me senté con él durante muchas horas para demostrar cómo se usan las herramientas, dónde ocurren los problemas y qué hacer para solucionarlos. Estamos 6 meses en el camino y le asigné a escribir un nuevo módulo. Lo revisé antes de que se integrara en nuestra base de código más grande, y me consternó descubrir la misma codificación incorrecta que antes. La parte que encuentro incomprensible es que parte de la codificación es peor que la de un aficionado. Por ejemplo, quería una clase (Foo) que pudiera poblar un objeto de otra clase (Bar). Decidió que Foo haría una referencia a Bar, por ejemplo:
class Foo {
public:
Foo(Bar& bar) : m_bar(bar) {}
private:
Bar& m_bar;
};Pero (por otras razones) también necesitaba un constructor predeterminado para Foo y, en lugar de cuestionar su diseño inicial, escribió esta gema:
Foo::Foo() : m_bar(*(new Bar)) {}Entonces, cada vez que se llama al constructor predeterminado, se filtra una barra. Para empeorar las cosas, Foo asigna memoria del montón para otros 2 objetos, pero no escribió un destructor o un constructor de copias. Por lo tanto, cada asignación de Foo realmente filtra 3 objetos diferentes, y puede imaginar lo que sucedió cuando se copió un Foo. Y - solo mejora - repitió el mismo patrón en otras tres clases, por lo que no es un error único. Todo el concepto está mal en muchos niveles.
Me sentiría más comprensivo si viniera de un novato total. Pero este tipo ha estado haciendo esto durante muchos años y ha recibido capacitación y consejos muy centrados en los últimos meses. Me doy cuenta de que ha estado trabajando sin tutoría o revisiones por pares la mayor parte del tiempo, pero empiezo a sentir que no puede cambiar. Entonces mi pregunta es, ¿persistirías con alguien que está escribiendo un código tan obviamente malo?
fuente
Respuestas:
Mi consejo sería confrontarlo con este ejemplo en particular y ver qué dice. Si niega que haya algo malo con el código, me temo que hay poco que pueda hacer. Si acepta que cometió un error (incluso si está a la defensiva al respecto), entonces al menos hay margen de mejora. Si acepta el tiempo y el esfuerzo para mejorarlo, entonces usted o un programador sénior deberá sentarse y codificar hasta que todas estas tendencias se aplanen (prepárese para dedicar a esta persona durante al menos 1 mes).
Un mal programador, por lo general puedo trabajar, pero un programador que no puede mejorar, no puedo.
fuente
No. Yo despediría a cualquier desarrollador profesional de C ++ que careciera de la comprensión básica de la administración de memoria.
Si se trata de alguien que viene de Java o C # o algo así, les daría algo de libertad, pero esto es pura incompetencia.
fuente
No podemos responder la parte más amplia de su pregunta. A saber, si retiene o despide a ese empleado. Despedir a un empleado es difícil, pero esa es una decisión fuera del alcance de una comunidad como esta.
Actualizó su pregunta para restringir las respuestas a los programadores de C ++. Para mis antecedentes / calificaciones: corté mis dientes en C, y puedo codificar en C ++, C # y Java. Y me gusta perseguir las condiciones de carrera entre hilos porque creo que es divertido. Sí, me "vuelvo" un poco tonto.
Su respuesta y decisión se ajustan a esto: si alguien puede cambiar o no depende de la persona y si quiere cambiar.
Pero comencemos con algunas preguntas tuyas:
Debe asegurarse de poder decir que sí a todas esas preguntas. Si no, todavía hay una carga de prueba de su parte para comunicarse con él.
Su respuesta a su reciente revisión será la parte más reveladora.
Si lo ha intentado y muestra algunos signos de progreso, tal vez necesite revisar su proceso de tutoría. En todo caso, tal vez deba considerar emparejarlo con un programador más experimentado para que pueda obtener comentarios inmediatos mientras toma decisiones de diseño. No soy fanático de la programación de pares, pero puede ser muy útil en un caso como este. Enviarlo continuamente para que haga más y más revisiones al código antiguo no siempre es una ruta práctica para el aprendizaje.
Si no lo ha intentado, entonces necesita comprender mejor su motivación. ¿No entendió que necesita esforzarse más? ¿Simplemente no le importa? ¿Hay otras áreas en el equipo donde sus habilidades encajarían mejor y está más interesado en eso? Si no le importaba intentarlo, entonces debes entender por qué.
A partir de ahí, sabrás si quiere cambiar y si puede cambiar. Ningún deseo de cambiar es equivalente a no poder cambiar. Si hay deseo y un grado de progreso, considere cambiar la forma en que está tratando de rehabilitarlo.
fuente
Me temo que su código incorrecto no es el único problema en su equipo.
Dices que ha estado en la empresa durante un período prolongado de tiempo. Despedir a esa persona rara vez es una buena idea (a menos que sea un empleado tipo Wally). Su conocimiento de las necesidades del cliente, los productos que posee, etc. a menudo es mucho más valioso que el código que escriben.
Soluciones:
fuente
Tomar la decisión de despedir a alguien es una decisión difícil para cualquiera. Sin embargo, su situación se ve agravada por varios factores:
Dicho esto, ha pasado los últimos 6 meses mostrando al desarrollador el error de sus costumbres y su nuevo código aún no ha mejorado.
En esta etapa, realmente necesita comenzar una gestión proactiva para que dentro de 3 meses tenga
o
Para hacer esto, aunque necesita sentarse con el desarrollador, explicar lo que está mal por escrito / correo electrónico, explicar cómo puede mejorar el desarrollador y decir muy claramente que si no se materializa la mejora esperada, se terminará en 3 meses.
¡También debe tener muy claro que se espera la mejora a partir de este momento para el resto de su empleo en la empresa y no solo para el período de 3 meses!
También debe informar a su propio gerente y al Departamento de Recursos Humanos (si corresponde).
Durante este proceso, tendrá que administrar activamente al desarrollador y revisar las tareas / código cada 1-2 días y asegurarse de que estén a la altura, detallar los que no lo están y explicar qué se puede hacer para mejorarlos.
fuente
O no ha sido claro acerca de cuán en serio se toma su mala mano de obra (es decir, es posible que vea el tiempo que ha pasado con él como una opción si quiere mejorar en lugar de una necesidad absoluta), o tiene una increíblemente mala actitud que es insostenible. Si aún no está claro para este desarrollador que está considerando su posición sobre este tema, entonces debe explicarse (suponiendo que su liderazgo esté bien con su autoridad para finalizar). El choque con suerte traerá cambios.
Sin embargo, la decisión de empleo tiene implicaciones mucho más amplias que solo este tipo, debe considerar el impacto en el equipo. Si se permite que su actitud prospere, puede proporcionar resentimiento hacia los demás o hacer que otros sientan que este tipo de cosas también está bien. Sin embargo, desde el punto de vista del equipo, debe quedar absolutamente claro que si fue, fue por las razones correctas y tuvo una amplia oportunidad de mejorar.
Una joya que compré en un curso hace años es el hecho de que las personas con conocimientos técnicos que otros no tienen pueden liderar la administración para darles holgura. Es malo para el equipo. Puede tener miedo de perder el único desarrollador de c ++, pero pueden ser reemplazados. Obviamente, existen riesgos inherentes si conoce bien los productos lanzados, pero a menudo he visto a personas con conocimientos técnicos / de productos aparentemente irremplazables reemplazados más fácilmente de lo previsto. Los equipos y las organizaciones a menudo pueden llenar los vacíos que inicialmente parecen difíciles de llenar. Por supuesto, si él no tiene habilidades de C ++ o conocimiento específico de la organización que cree que será difícil de reemplazar, ¡hay mucho menos problema!
fuente
Por supuesto que no deberías. Recuerde, esto no es una organización benéfica, está intercambiando dinero por trabajo. Si no está retrasando su parte del trato, entonces, como cualquier transacción, dejaría de pagar.
fuente
Si desea darle una oportunidad, desarrolle una prueba estandarizada que reúna métricas sobre pérdida de memoria. Monitoree su progreso semanalmente, insistiendo en ver el código que ha cambiado, y busque mejoras. Si no puede arreglárselas en ese punto, despide a la inútil invectiva.
fuente