Qué hacer con la estrella de los desarrolladores que no documentar su trabajo?[cerrado]

https://stackoverflow.com/questions/532338

collaboration

22-08-2019
|

Pregunta

Hay un colega que sabe en serio sus cosas, él es uno de los más brillantes que he trabajado nunca, pero:

trabaja en su propio área poco de su directorio de inicio en lugar de en el común CVS repositorio
no documento su código
no comentario su código, por ejemplo3,500 SLOC de C sin comentarios y sin líneas en blanco para romper las cosas
a menudo overcomplicates cosas, por ejemplo,utiliza tres secuencias de comandos de shell que llaman el uno al otro para hacer el trabajo que un simple script de shell podía hacer.

Tal vez esta es posiblemente una de esas personas que piensa que "si yo soy la única persona que sabe esto, que no puede deshacerse de mí"?

Alguna sugerencia sobre qué hacer?

Por CIERTO, la Gerencia sabe acerca de la situación y están tratando de cambiar las cosas.

Solución

En mi opinión alguien haciendo cosas tan estúpidas como usted ha descrito anteriormente, no puede ser un desarrollador estrella! A mí me parece como si intencionalmente hace las cosas más complicadas, ya que son, para que nadie más que él puede mantener el código. Esto se hace más importante de lo que realmente es! Hablale. Él tiene que cambiarlo! Si no lo hace, reemplazarlo con una verdadera estrella-desarrollador!

Te lo prometo, incluso en medio año que no sabrá cómo funciona su propio código! despedirlo y se puede ahorrar mucho tiempo y dinero.

Otros consejos

La parte CVS es fácil - un fallo de disco duro "accidental" le enseñará una lección para una vida (asegúrese de que tiene una copia de seguridad, así que en realidad no se pierda código)

Eso suena como una situación difícil.

En lo personal, me gustaría dejarlo ir. Él puede ser un desarrollador de estrellas, pero no es un jugador de equipo. Y es necesario tener un equipo cohesionado que pueden trabajar juntos si se quiere hacer un buen producto.

No documentar es una forma (muy malo) para garantizar la seguridad del empleo.

Puede hacer varias cosas para contrarrestar esto:

añadir documentación como requisito para las evaluaciones de desempeño personal.
no aceptan el software que no está documentado.
tener una palabra con el revelador y averiguar por qué no se explica.
Comprar un instrumento de documentación fresco.

Juega el poli malo / poli bueno boceto que has visto en las películas. Deje que la gestión sea el policía malo y que sea el poli bueno. Deje que el managament pedir documentación sobre-matar y por minuto copias de seguridad postal de su trabajo. Pero usted le ofrece la documentación moderada (por doxygen por ejemplo) y control de la fuente habitual de registros ...

Habla con él?

Si realmente es un "desarrollador estrella" que va a tomar nota de lo que dice.

No le puede cambiar durante la noche, pero podría ser que él es completamente inconsciente de que otras personas no lo consigue absolutamente como lo hace.

Editar:

Es probable que sea un poco tarde para cambiar ahora, pero se necesita más información en la elaboración de una solución. Es imposible que alguien aquí para sugerir realidad dejando que el chico vaya en base a estos puntos solamente. Si usted ha estado diciendo al chico todos los días durante el último año que tiene que cambiar o que está fuera de aquí, entonces se puede dejar que se vaya. Sin embargo, no veo ninguna evidencia de ello.

Un desarrollador brillante puede ser enseñado a utilizar control de código fuente, comentarios y documentos. Si pasas el esfuerzo aquí, entonces, que realmente tendrá un desarrollador estrella.

Es posible que se centrará en el área equivocada aquí, que está siendo dado la oportunidad de ver algunas debilidades en su proceso.

trabaja en su propia pequeña área de su directorio personal en lugar de en el repositorio CVS común

Una simple charla será probablemente suficiente aquí, los beneficios de control de versiones hablan por sí mismos y cualquier persona "brillante" es probable que ser entusiasta acerca de esos beneficios. Sin embargo, también puede ser una buena oportunidad de ver en los sistemas de control de versiones alternativas que permiten una mayor facilidad de uso y flexibilidad (echar un vistazo a bzr y GIT). Mejor aún, se involucrara en el proceso de selección, si realmente es una "estrella" que probablemente va a tener una buena entrada y ser más personal en su uso.

no documenta su código

No suena igual que la documentación es parte de su proceso. La gente va a resistirse a tener que hacer trabajo extra y si no hay un proceso definido, entonces estamos hablando de una gran cantidad de trabajo extra. Que realmente se necesita documentación? Si es así, ¿existe un proceso definido para crearlo? en caso de tener a alguien totalmente dedicado a ella? En caso de que por lo menos tener una herramienta para facilitar que (tal vez algo tan simple como mediawiki)?

no comenta su código, por ejemplo, 3500 SLOC de C sin comentarios y líneas en blanco a pico cosas

Tres palabras: Intercambio de revisión de código. Fuera de los beneficios de error atractivo obvias, esto también puede proporcionar una cierta presión de grupo, que es una fuerza fuerte y puede ser una buena cosa. Queriendo ser percibida así por sus pares auto-genera la propiedad y la calidad.

menudo overcomplicates cosas, por ejemplo, utiliza tres secuencias de comandos shell que llaman el uno al otro para hacer el trabajo que una simple script de shell podría hacer.

Una vez más, la revisión del código de pares. Usted menciona que la administración sabe acerca de las deficiencias de este programador. ¿El? Es bastante difícil para las personas cambian y mejoran si no se reconocen los problemas con la forma en que están haciendo las cosas.

Y, tal vez lo mejor de todo, mediante la presentación de los planes para mejorar el proceso de desarrollo (que probablemente mejorará no sólo su "estrella", pero todos los demás en el equipo) es probable que pueda ganar algo de estrellas de oro por sí mismo de la administración.

No suena como mucho de un programador estrella para mí. Todos los buenos programadores saben que el formateo de código y uso de materias de control de origen. Parece que a pesar de que hace buen avance por sí mismo, que está obstruyendo el progreso de los otros miembros del equipo, lo que podría tener un efecto negativo neto sobre el trabajo conseguir que se hagan. Hablar con él, y si se niega a cambiar sus prácticas, dejarlo ir.

Si realmente es tan brillante y no se puede cambiar su forma, ni tampoco quiere perderlo, pero aún quiere su código para ser documentado y comentado a continuación, mi sugerencia sería dejar que un desarrollador con menos experiencia hace la documentación y comentar para él. Personalmente si yo fuera un desarrollador estrellas Me siento prettiy tonto si se hizo algún otro para comentar mi código y me gustaría empezar a hacerlo yo mismo con el tiempo. Mientras tanto, mientras eso no ocurra el desarrollador con menos experiencia puede aprender una cosa o dos.

Hay más de ser un desarrollador estrella que acaba de ser un excelente programador. Si él no tiene habilidades de equipo y está ignorando deliberadamente las normas del equipo que necesita ser educado para él. Si se niega a adherirse a ellos después de hablar con la administración, tal vez no es el sistema más adecuado para su empresa.

Esta pregunta me pone nervioso, porque mientras que la persona que usted describe suena atroz, puedo ver un poco de mí mismo en él.

Creo que soy un buen jugador de equipo, y tengo la suerte de estar en un equipo muy bueno. Sin embargo, hago uso de métodos que mis colegas no entienden, aunque he intentado bastante difícil de explicar. No solo es un muy gran brecha experiencia, que no es una reflexión sobre cualquiera de nosotros.

Documentación es un tema amplio y complicado. Trato de seguir el seca (no repita usted mismo) Maxim. Documentación que está separado del código puede ser equivalente a repetir siempre lo mismo, por lo que es obligado a salir de la fecha, a menos que desacelerarse para mantenerla al día. Mi enfoque habitual es tocarla después.

A menudo el problema que estoy trabajando es tan complicado que pueda avanzar en el plan y documentar todo lo que quiero, pero cuando se trata de un código que a menudo descubre que estaba equivocado y tiene que volver a pensar en ella. Así que la idea de que se puede documentar las cosas de antemano, y que sólo tiene que seguir, sólo funciona para problemas bastante sencillo, me parece a mí.

De todos modos, creo que esta es una excelente pregunta, y la respuesta no es en absoluto sencilla.

es el tipo realmente una estrella de rock? ¿Seriamente? Piensa en ello un segundo. ¿Es inteligente, pero no hacer las cosas, o es inteligente y capaz de hacer las cosas?

Piense que sea muy difícil.

Si realmente es una estrella de rock, entonces tal vez usted no debe meterse con él. Se está produciendo cosas muy impresionantes utilizando su propio proceso. El hecho de que hay una manera diferente de hacer las cosas que funcionan mejor para usted, no significa que le va a permitir producir su mejor trabajo. En lugar de tratar de conseguir que doblar a su proceso, que muy bien podría matar a toda su genialidad, usted debe tratar de encontrar una manera de adaptarse a la forma en que funciona.

Si realmente es tan bueno como usted dice, no debe importa hacer eso. Si no vale la pena el esfuerzo para hacer eso, entonces él realmente no es tan buena. En ese caso, usted no tiene una estrella de rock, que acaba de tener un programador mediocre que no le gusta jugar sea las reglas. Esos tipos, sólo debe deshacerse de él. Una estrella de rock temperamental es por lo general vale la pena el dolor, sin embargo, debido a la calidad de lo que él o ella puede producir. Esas personas, que deben hacer un gran esfuerzo para mantener.

Suena como un programador estrella que está aburrido de su trabajo y es más de lo que complica las cosas para que sea más que un reto. Que va a encontrar algo mejor muy pronto.

Tratar de cambiar las cosas? ¿Qué prefieres, una pieza poco documentada de trabajo de software o un junco bien documentado? Algunas personas son capaces de software de escritura que requiere poco o nada de comentarios, que no es un indicador fiable de la calidad.

Me temo que va a perder un buen desarrollador.

"Hola Estrella desarrollador,

sólo un poco informal mano a mano que le diga que a partir de la próxima semana, vamos a ser requieren documentación de código y útil comentar en el código - que va a ser la política de la empresa, y no habrá excepciones "

A partir de entonces, sólo se ocupa de que el fracaso de la misma como lo haría frente a un fracaso para subir a tiempo, un fracaso para detener perdiendo el tiempo durante el trabajo, etc. El fondo es si el jefe dice el documento, se documentan o usted no está haciendo su trabajo correctamente.

Si está trabajando de esta manera, no es un desarrollador estrellas - grandes desarrolladores de software de mantenimiento comprenden que es extremadamente importante. Probablemente tendrá que pagar un alto precio por esto en el largo plazo, estaría muy directo con él acerca de lo serio que es y le dejó ir si no puede comenzar a ajustar. He visto esto muchas veces antes y es una bomba de tiempo.

Para ser honesto, he visto un montón de desarrolladores como éste y, a menos que estén fuera de su escuela, no van a cambiar. Yo digo sin pérdidas corto el momento, su único va a poner más duro para que le despidan mientras sigue echando código más imposible de mantener:)

Es muy poco probable que la administración va a deshacerse de él si es realmente brillante.

Todo el proyecto se puede cerrar, por supuesto, pero no habrá ningún uso en el CVS y documentación a continuación, de todos modos.

No hay gestión se disparará un buen programador sólo para contratar a una mala.

Dile que ayudará lo para deshacerse de gestión cada vez que quiere.

¿Qué es la que quiere cambiar de trabajo? Él puede decirle a la gerencia: "OK, la gente, todo es igual que usted me preguntó:. Registré, documentado y bajo a controlar he terminado con mi parte, debo empacar y dejar".

¿Puede el equipo tenga éxito con fuera de él? Si es así impulsar el tema y se niegan a aceptar cualquier código que no está debidamente documentado o no cumpla con otras normas. Esperamos que esto mi punto de vista, sino que sólo podría hacerlo enojar y hacer que renuncie. Si el equipo no puede tener éxito con él fuera, entonces estás de suerte hasta que pueda capacitar a un reemplazo hasta su nivel de habilidad que no puede ser vale la pena el tiempo y esfuerzo.

1 a ocdecio - si es un desarrollador estrella, entonces su código debe estar basado en un diseño tan alta calidad que se documenta en sí

Una vez dicho esto, la frustración podría ser que a pesar de que es excelente en las áreas que son interesantes para él técnicamente exigente, que no Muck-en con la entrega de características - sólo tú sabe si esto es un problema para su organización.

Tener un "gurú" disponible puede ser un salvavidas absoluta - o al menos lo que solía ser, o tiene Stackoverflow hizo ese papel redundante

No deje que el código será liberado hasta que haya pasado la revisión de código y sólo permitir que pase si hay suficientes comentarios y / o documentación para el código que ha escrito para la característica de corriente / proyecto.

Editar Llevarlo hasta en su valoración. Documentación / código comentando puede ser dada a él por sus "áreas de mejora".

: -)

También puede añadir controles automáticos de calidad que puedan impedirle el check-in a su código hasta que fue suficientemente documentado.

Esto es, si se le puede convencer de hacer el ingreso en el primer lugar! (Lo cual es esencial, OMI)

Hay un montón de gente aquí en los "sin comentarios, ¿y qué?" carro de aquí. leer y escribir código sin comentarios es perfectamente posible, pero sólo porque alguien es inteligente y no hace comentarios no significa necesariamente que están escribiendo código de leer y escribir.

Así que vamos a aclarar. Ya dijiste que no documenta su código en absoluto, ya sea en los comentarios o documentos separados, y que no utiliza ningún tipo de control de origen. ¿Qué hay de:

¿Es su código comprensible a pesar de la falta de comentarios?
¿Su equipo utiliza ningún tipo de seguimiento de problemas (por ejemplo FogBugz, Bugzilla, etc), que participa en?
¿Es su código bajo prueba?
¿Hay alguien más en el equipo que en realidad es al menos un poco familiarizado con cómo su código funciona?
¿Está dispuesto a reconocer por lo menos que podía soportar que hacer algunos cambios en la forma en que trabaja con el resto del equipo?

Si la respuesta a todas estas preguntas es "no", que tiene un gran problema. Sólo ser inteligente no significa necesariamente que alguien un activo. ¿Tiene alguna garantía de que no va a salir de su mañana de la empresa, o ser golpeado por un autobús? Cómo atornillado estaría usted si eso ocurriera? ¿Vale la pena el riesgo?

Creo que esto es bastante típico en cualquier entorno. ¿Cómo se llega a alguien para hacer lo que quiere? Esto es exactamente lo que "Cómo ganar amigos e influir sobre las personas" se trata. Dale Carnegie no era sobre la manipulación, pero la gestión de personas.

Me suena como si estuviera simplemente inexperto y necesita un poco de experiencia y orientación.

¿Usted cree que puede sentarse y hablar con él sobre estos temas? Decirle a alguien que está haciendo algo mal a menudo parece que el mal que hay que hacer (sobre todo en la sociedad occidental de hoy en el que no quería herir los sentimientos de otras personas), pero creo que se puede llegar muy lejos explicando con calma y honestidad los problemas y hablando a través. Sirve de ayuda si la persona que usted y su opinión, que es un asunto completamente diferente y se habla en el libro mencionado anteriormente respeta. Asegúrese de que entiende que estos son problemas graves. También, que en cualquier trabajo de desarrollo futuro que le espera para hacer estas cosas también, así que es una buena idea a la práctica ahora.

No creo que esperar hasta la próxima revisión del desempeño es una buena idea. Acumulando un montón de comentarios negativos y entregar todo a la vez es una mala idea y realmente no le gustó una vez hecho esto a mí.

Código documentación está sobrevalorado. formación CVS es fácil.

Una buena clase debe revelar su propósito a través de sus métodos y propiedades.

Documentar el modelo fuera de la aplicación también es más fácil de fluir y comprender.

Me volvería a llevar a su atención, si no puede que lo resuelva Parece que van a perder un desarrollador estrella.

Editar: Vaya - CSV utilizado en lugar de CVS, para muchas de las importaciones y yo uso SVN je

Haz que utilizar herramientas automatizadas ejecución-verificación. (Véase mi respuesta a " Cómo hacer preguntas a un obsructionist? ")
Si overcomplicates y no utiliza SCC, que es no un excelente desarrollador -. Estas cosas son parte importante de la ingeniería de software
En el caso muy improbable de que tiene algo de brillantez insustituible en áreas como algoritmos, le asigne a trabajar en esa área, por ejemplo, los algoritmos que definen, y obtener un programador real para hacer la codificación.
Utilice el código de análisis estático de entender y limpiar su código.

La programación en parejas. Encuentra pares hima que "completar" él para conocer los requisitos que acabamos de enumerar. Va a resolver un problema control de código fuente, documentación, cuestionar todas sus acciones, etc También se entrena a otro individuo mediante el uso de la fuerza primero chico

A partir de lo que usted describe, este individuo es claramente no un desarrollador estrella. La programación es un deporte de equipo, y los que no juega bien con otros no agrega mucho valor a un proyecto.

En lo personal, yo no podría recordar código que he escrito 6 meses o más atrás, y mucho valor un historial de los cambios en algún tipo de control de código fuente.

Si tuviera revisiones de código regulares con este chico creo que se vería que no es tan estelar de un desarrollador como usted piensa que es.

Estoy de acuerdo con la mayoría de la gente en este hilo.Una forma para ponerlo en el punto caliente es un Equipo de Revisiones de Código.

Para la primera revisión del código de la reunión de elegir el código de un miembro del equipo que está abierto y aceptar las recomendaciones.La "estrella" de los desarrolladores tendrán la oportunidad de ver cómo el código de revisión de las obras y, a continuación, usted puede programar su código para ser revisados siguiente.Darle un poco de tiempo para prepararse para la próxima reunión y, a continuación, él debe ser de al menos comentar su código.

La intención de las revisiones de código no es de poner en vergüenza a la gente, pero en lugar de colaborar y de identificar los temas y lugares para la mejora, pero será una buena manera de poner la estrella del desarrollador en el asiento caliente.

En mi opinión, es necesario colocar este tipo. Suena como su código es ilegible y que definitivamente no es un equipo, ni una caja fuerte, reproductor.

También es una muy mala práctica para permitir que alguien se ven como indispensable. Si se le deja seguir con esto, sus prácticas se pondrán peor, no mejor. Cuando sale, por todo el mundo hace, se le dejó con un dolor de cabeza enorme de código enredado. Es necesario cortar sus pérdidas ahora si no quiere ponerse en forma.

Finalmente, manteniendo este desarrollador sin él reinante en sets un mal ejemplo de los desarrolladores jóvenes. Si se les obliga a trabajar correctamente, corre el riesgo de resentimiento por parte de los "por qué él y no yo" multitud. Si no lo hace, se obtiene un montón de trucos que funcionan como su "estrella".

En resumen, a menos que se perfila muy, muy rápidamente, es el momento de dejarlo caer, por la salud y la cordura de todo su personal de desarrollo.

Hemos tenido un problema similar cuando empecé mi trabajo actual hace un poco más de 3 años, nuestro desarrollador principal era un vaquero. Era muy inteligente, pero muy irregular, algunas de sus cosas fue muy bien documentados, pero tan excesivamente complicado era que podrá imponerse a mantener, o código primero y averiguar lo que estaba construyendo más tarde, se tiraría código para ver qué atenerse.

Se fue hace aproximadamente 2 1/2 años, y todavía nos está rondando cuando encontramos algo de su antiguo código, y en su defensa que es como la tienda de desarrollo que aquí se llevó a cabo en ese entonces, en los últimos 3 años he estado en una cruzada para cambiar esa mentalidad.

Cuando usted se convierte en un desarrollador estrella deja de ser mucho acerca de qué tan bien conoce el sistema, código, marco, la arquitectura, etc., y más sobre

La escritura elegante mantenible código, flexible y fácil de leer
El trabajo con el resto del equipo:. El uso de control de código fuente, lo que lleva por ejemplo, etc
La documentación de lo que cada método, clase, objeto, etc está haciendo
la investigación de nuevas y mejores formas de hacer las cosas por sí mismo, y su equipo

si no está siguiendo los cuatro de éstos en algún nivel no eres un desarrollador estrella, más aún si se niega a tratar / aprender a usarlos, entonces es hora de que eso debería encontrar otras oportunidades de empleo de una manera u otra, escucho de hambre artista es popular entre este tiempo de persona (todo el asunto entienden mal genio)

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow