¿Deberíamos persistir en que un empleado siga escribiendo código incorrecto después de muchos años? [cerrado]

13

Le hago esta pregunta a los programadores de C ++ porque: a) Sólo 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 escribe código como este.

HR y los directores saben que existe 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 se encuentran en un nivel muy básico: mi pregunta (a los programadores) es si a alguien que se declara desarrollador senior de C ++ se le debe dar un beneficio de duda basado en muestras de su código actual. Los no programadores, incluso las personas ajenas a la programación en C ++, no pueden emitir ningún juicio al respecto.

Para los antecedentes, se me asignó la tarea de administrar desarrolladores para una empresa bien establecida. Tienen un solo desarrollador que se especializa en toda su codificación C ++ (desde siempre), pero la calidad del trabajo es abismal. Las revisiones de código y las pruebas han revelado muchos problemas, uno de los peores 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. El usuario reportó una gran desaceleración, y su opinión fue: "no tiene nada que ver conmigo; si se dan por vencidos y se reinician, todo volverá a estar bien".

Le he dado 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 por el camino, y le asigné que escribiera un nuevo módulo. Lo revisé antes de que se integrara en nuestra base de código más grande, y me horroricé al descubrir la misma mala codificación que antes. La parte que me parece incomprensible es que parte de la codificación es peor que la de los aficionados. Por ejemplo, quería una clase (Foo) que pudiera poblar un objeto de otra clase (Bar). Decidió que Foo mantendrí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 joya:

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 ni un constructor de copias. Así que cada asignación de Foo en realidad filtra 3 objetos diferentes, y puedes 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 resbalón de una sola vez. Todo el concepto es incorrecto en muchos niveles.

Me sentiría más comprensivo si esto viniera de un principiante total. Pero este tipo ha estado haciendo esto durante muchos años y ha tenido una formación y un asesoramiento muy específicos durante los últimos meses. Me doy cuenta de que ha estado trabajando sin mentores o revisiones de pares la mayor parte del tiempo, pero estoy empezando a sentir que no puede cambiar. Así que mi pregunta es, ¿persistirías con alguien que está escribiendo un código tan obviamente malo?

    
pregunta user94986 26.06.2013 - 16:13

8 respuestas

22

Mi consejo sería confrontarlo sobre este ejemplo en particular y ver qué dice. Si él niega que haya algo malo con el código, entonces me temo que hay poco que puedas hacer. Si acepta que cometió un error (incluso si está a la defensiva), al menos hay espacio para mejorar. Si acepta el tiempo y el esfuerzo para mejorarlo, entonces usted o un programador senior deberán sentarse y codificar juntos hasta que todas estas tendencias se aplanen (prepárese para dedicar a esta persona durante al menos 1 mes).

Un mal programador con el que normalmente puedo trabajar, pero un programador que no puede mejorar, no puedo.

    
respondido por el Neil 26.06.2013 - 16:22
17
  

Así que mi pregunta es, ¿persistirías con alguien que está escribiendo un código tan obviamente malo?

No. Me gustaría despedir a cualquier desarrollador profesional de C ++ que careciera de la comprensión básica de la administración de memoria.

Si es alguien que viene de Java o C # o algo así, les daría un poco de latencia, pero esto es pura incompetencia.

    
respondido por el Telastyn 26.06.2013 - 16:24
13

No podemos responder a la parte más amplia de su pregunta. A saber, debe retener o despedir a ese empleado. Despedir a un empleado es difícil, pero esa es una decisión fuera del ámbito de una comunidad como esta.

Has actualizado tu pregunta para restringir las respuestas a los programadores de C ++. Para mis antecedentes / calificaciones: Me corté los 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 "pongo" un poco de twiddling.

Su respuesta y decisión se ajustan a esto: si alguien puede cambiar o no, depende de la persona y si quieren cambiar.

Pero empecemos con algunas preguntas tuyas:

  1. ¿Le has preguntado sobre el código y el ejemplo que mencionaste? ¿Cuál fue su impresión de la revisión?
  2. ¿Le brindó detalles específicos durante esos 6 meses sobre la comprensión de la manipulación de la memoria y asegurarse de que su código no tuviera pérdidas de memoria?
  3. ¿Estuvo proporcionando comentarios razonablemente frecuentes durante esos 6 meses para indicar si estaba progresando o no?
  4. ¿Dijiste explícitamente que su antigua forma de codificación ya no era aceptable en el nuevo código?

Debe asegurarse de poder decir 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 estado intentando y muestra algunos signos de progreso, tal vez necesite revisar su proceso de tutoría. En todo caso, tal vez deba considerar asociarlo con un programador más experimentado para que pueda obtener una respuesta inmediata mientras toma decisiones de diseño. No soy un fanático de la programación de pares, pero puede ser muy útil en un caso como este. Enviarlo continuamente para hacer más y más revisiones al código antiguo no siempre es una ruta práctica para aprender.

Si no lo ha intentado, entonces debes 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 encajen mejor y él esté más interesado en eso? Si no le importó intentarlo, entonces debes entender por qué.

A partir de ahí, sabrá 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, entonces considera seriamente cambiar la forma en que intentas rehabilitarlo.

    
respondido por el GlenH7 26.06.2013 - 16:26
10

Me temo que su código incorrecto no es el único problema en su equipo.

  1. ¿Quién revisa su código? ¿Por qué se escapó sin una advertencia para aceptar código con vulnerabilidad de pérdida de memoria?
  2. ¿Por qué las pruebas de estrés no encontraron este problema? ¿Los usas? Si es así, ¿por qué no están trabajando?
  3. Fue dejado desatendido durante un largo período de tiempo. ¿Por qué?
  4. No está usando las herramientas que le diste. ¿Cómo lo motivaste a comenzar a usar las herramientas adecuadas?

Usted dice que ha estado en la empresa durante un período prolongado de tiempo. Despedir a una persona así rara vez es una buena idea (a menos que sea un empleado de tipo Wally). Su conocimiento de las necesidades del cliente, los productos que posee, etc. suele ser mucho más valioso que el código que escriben.

Soluciones:

  • muévalo a Control de calidad para que aprenda qué debe evitar
  • programación en pareja con alguien que puede señalar sus errores
  • esfuerzo de control de calidad extendido en su código
  • haz que escriba pruebas de estrés, si ve que su máquina de desarrollo se bloquea después de crear y destruir 10k de objetos, tal vez aprenda
  • algunos / todos ellos arriba :)
respondido por el Andrzej Bobak 26.06.2013 - 16:44
3

Tomar la decisión de despedir a alguien es una decisión difícil para cualquiera. Sin embargo, su situación está compuesta por varios factores:

  1. Parece que este desarrollador ha estado en la compañía por varios años
  2. El desarrollador escribe todos los códigos C ++ de las compañías
  3. aparece         que antes de ti nadie discutió el nivel de código pobre con         el desarrollador
  4. Como nuevo gerente, no tiene idea de quién / qué     desarrollador sabe en / acerca de la empresa y lo que la política     Las ramificaciones de despedir al desarrollador son

Dicho esto, has pasado los últimos 6 meses mostrando al desarrollador el error de sus formas y su nuevo código aún no ha mejorado.

En esta etapa, realmente necesita comenzar una administración proactiva para que dentro de 3 meses tenga

  • Un programador decente de C ++ que sabe lo que está haciendo

o

  • Ha finalizado el desarrollador.

Para hacer esto, debe sentarse con el desarrollador, explicar qué es lo que está mal en la escritura / correo electrónico, explicar cómo puede mejorar el desarrollador y afirmar muy claramente que si no se materializa la mejora esperada, será capaz de hacerlo. Terminado en 3 meses.

¡También debe tener muy claro que la mejora se espera 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 el desarrollador y revisar las tareas / el código cada 1-2 días y asegurarse de que estén al día, detallando las que no lo son y explique qué se puede hacer para mejorarlas.

    
respondido por el armitage 26.06.2013 - 17:49
1

O bien, no ha sido claro qué tan seriamente 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 si tiene Una actitud increíblemente mala que es insostenible. Si no está claro para este desarrollador que está considerando su posición sobre este tema, entonces debe ser explicado (asumiendo que su liderazgo está de acuerdo con su autoridad para terminar). Esperemos que el choque provoque un cambio.

La decisión de empleo tiene implicaciones mucho más amplias que solo este tipo, sin embargo, debe considerar el impacto en el equipo. Si se permite que su actitud prospere, puede proporcionar resentimiento de 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 lo hizo, fue por las razones correctas y tuvo muchas oportunidades de mejorar.

Una de las gemas que aprendí en un curso hace años es el hecho de que las personas con conocimientos técnicos que otros no tienen pueden hacer que la gerencia les dé un descanso. Es malo para el equipo. Puede tener miedo de perder al único desarrollador de c ++, pero pueden ser reemplazados. Obviamente, hay riesgos inherentes si él conoce bien los productos lanzados, pero a menudo he visto a personas con conocimientos técnicos / productos aparentemente insustituibles 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 conocimientos de c ++ o conocimientos específicos de la organización que crees que serán difíciles de reemplazar, ¡hay mucho menos problema!

    
respondido por el Wayne M 26.06.2013 - 18:46
0

Por supuesto que no deberías. Recuerda, esto no es una organización benéfica, estás intercambiando dinero por trabajo. Si no está demostrando su parte del trato, entonces, como cualquier transacción, dejaría de pagar.

    
respondido por el BigOmega 26.06.2013 - 16:26
-1

Si desea darle una oportunidad, desarrolle una prueba estandarizada que reúna las métricas de la pérdida de memoria. Supervise su progreso semanalmente, insistiendo en ver el código de que él cambió y busque mejoras. Si no puede arreglárselas en ese momento, saque la invectiva inútil.

    
respondido por el Jack Aidley 26.06.2013 - 18:27

Lea otras preguntas en las etiquetas