Había leído una entrevista con un gran programador (no está en inglés) y en él dijo que "un gran programador puede ser 10 veces más bueno que uno mediocre", explicando por qué los buenos programadores están muy bien pagados y por qué Las compañías de programación ofrecen muchas facilidades para sus empleados. La idea era que existe una gran demanda de buenos programadores, debido a la razón anterior y es por eso que las compañías pagan mucho para traerlos.
¿Estás de acuerdo con esta afirmación? ¿Conoces algún hecho objetivo que pueda respaldarlo?
Editar: la pregunta no tiene nada que ver con la experiencia; Si habla de un gran programador con 1 año de experiencia, entonces debe ser 10 veces más productivo que un programador mediocre con 1 año de experiencia. Estoy de acuerdo en que desde cierta experiencia años en adelante, las cosas comienzan a disiparse, pero ese no es el propósito de la pregunta.
fuente
Respuestas:
En dos artículos escritos por Steve McConnell se proporciona una descripción general y un análisis bastante exhaustivos de la investigación sobre las diferencias de productividad :
Variaciones de productividad entre desarrolladores de software y equipos: el origen de "10x"
Orígenes de 10X: ¿cuán válida es la investigación subyacente?
El primer artículo ( Variaciones de productividad ... ) establece:
Este artículo también tiene una nota al margen interesante:
El segundo artículo ( ... ¿Qué tan válida es la investigación subyacente? ) Se ha escrito principalmente para abordar la revisión crítica del primero por Laurent Bossavit :
En el segundo artículo, en la sección Una inmersión más profunda en la investigación que respalda "10x" McConnell vuelve a verificar con más detalles las referencias utilizadas en el primer artículo y concluye:
En aras de la exhaustividad, la lista de referencias utilizadas en las variaciones de productividad ... también se cita a continuación:
fuente
Un programador realmente terrible puede tener una productividad bajo cero (los errores que introducen tardan más en solucionarse de lo que se necesitaría para hacer todo su trabajo por ellos).
Y un programador genuinamente excelente puede hacer cosas que los programadores pobres y promedio simplemente nunca lograrían, sin importar cuánto tiempo les dedique.
Por estas razones, es difícil hablar de "10 veces más productivo" o "100 veces más productivo".
Sin embargo, lo que hay que recordar es que la mayoría de los empleadores de programadores no tienen ninguna necesidad de que realicen las tareas difíciles que los programadores promedio no podían manejar. La mayoría del código que se está escribiendo son sitios web, aplicaciones de línea de negocios, aplicaciones de intranet, etc., gran parte de lo cual no es tan difícil. El programador productivo en ese entorno es el que mejor comprende e implementa las necesidades de los usuarios, no el que puede escribir el código más inteligente.
De hecho, la mayoría de los empleadores de programadores estarían mejor con un buen programador que con uno excelente, porque el excelente simplemente se aburrirá y se irá. Tengo que encontrar una buena combinación entre programadores y trabajos.
fuente
Hechos y Falacias de los estados de Ingeniería de Software (Hecho 2, disponible en la vista previa de Amazon):
(mira la lista de fuentes allí para la investigación)
Por supuesto, si compara la productividad de un no programador (o un programador muy malo) con el bueno (en términos de experiencia y conocimiento), la diferencia puede ser infinitamente grande (
n/0 == infinity
para cualquier positivon
), pero tampoco es justo ni una comparación sensata.Su salario puede depender de múltiples factores (en orden aleatorio):
junto con tu personal ...
fuente
Mi respuesta es "sí, pero tenga cuidado de cómo usa esa métrica".
Un programador que, digamos, funciona de manera óptima, es aquel que crea para la funcionalidad y causa menos errores que necesitan reparación que sus hermanos de bajo rendimiento. No me resultaría difícil creer que estas personas puedan rendir a 10 veces la productividad de los demás, particularmente cuando consideras que una sola elección buena o mala hecha en una hora puede tener fácilmente 10 horas de impacto, y los programadores hacen muchas de esas elecciones la mayoría de los días.
Pero...
Debes tener cuidado al medir esto. Realmente no confío en la mayoría de las mediciones de productividad, ya que he visto un sinfín de casos en los que casi todas las métricas conocidas no consideran algo que considero vital para la productividad del equipo. Por lo tanto, generalmente odio los números tan difíciles de "productividad". Aquí hay algunos ejemplos:
Muchos sistemas de medición han tratado de tener en cuenta estos factores, pero aún no he visto que haya uno que tenga en cuenta todos estos problemas, por lo que nunca estoy demasiado impresionado con factores como "un buen desarrollador es 10 veces más productivo que un mediocre "porque tengo que preguntarme si la métrica realmente representa todo el trabajo que se necesita para un producto continuo exitoso o un equipo exitoso y próspero.
Entonces mi gran advertencia es: ¿qué vas a hacer con esta métrica? Usaré algo como esto para tener en cuenta que las herramientas y el talento correctos pueden causar una gran diferencia en la forma en que se realiza el trabajo, pero si intenta optimizar a un equipo donde cada individuo produce 10 veces la producción "típica", está obligado a Un caso de frustración. Lo mejor es encontrar una manera de hacer que su equipo haga 2-3 veces lo que estaban haciendo antes trabajando juntos mejor.
fuente
En su libro The Leprechauns of Software Engineering , Laurent Bossavit describe la investigación del reclamo de productividad 10x. Descubrió que no hay números sólidos detrás de esto: la afirmación ha pasado de la especulación al "hecho establecido" por un juego telefónico de afirmaciones sucesivamente más concretas en citas. La publicación de blog que comprende el capítulo sobre el reclamo 10x, e incluye las citas y citas erróneas relevantes, es un hecho y un folklore en la ingeniería de software .
Lo que encontró es algo como esto: alguien en 1968 hizo un estudio comparando a las personas que resolvieron un problema de depuración en particular, y descubrió que algunos de ellos lo hicieron 10 veces más rápido que otros. De esto podríamos concluir que algunas personas son 10 veces mejores para resolver ese problema , o podríamos concluir que algunas personas tuvieron suerte o una gran variedad de cosas diferentes. Algunas personas optaron por citar esto como (todas estas son paráfrasis) "un estudio (Sackman et al, 1968) encontró que algunos programadores trabajan 10 veces más rápido que otros". Luego se convirtió en "los estudios han demostrado que los buenos programadores son 10 veces mejores que el promedio" y finalmente "es de conocimiento común que la productividad del programador varía en 10 veces entre los individuos". Luego, alguien recopila todas estas citas, citando erróneamente una fuente original decir "muchos investigadores creen ...".
Por supuesto, no sería un juego telefónico si solo cambiara la veracidad de la afirmación: el multiplicador también va a 11 y más .
fuente
" El programador productivo en ese entorno es el que mejor comprende e implementa las necesidades de los usuarios, no el que puede escribir el código más inteligente " . ( Respuesta de Carson63000 )
Ese punto clave junto con bethlakshmiLos puntos hacen un gran punto. Un gran desarrollador puede ser excelente en su única parte de la realidad, pero se separará pronto a medida que el mundo cambie. Ser capaz de mantenerse al día con las necesidades del negocio es mucho más importante que cualquier otra cosa. Al final del día, a menos que su negocio sea tecnología, al negocio no le importa la tecnología; Necesitan soluciones. Por lo tanto, ser excelente con los patrones de diseño no significa ponerse en cuclillas para los usuarios finales que solo necesitan un volcado de datos para mostrar en una página web. He visto a desarrolladores mediocres asegurarse un trabajo atendiendo a la empresa que los apoya, mientras que los grandes desarrolladores se aburren y se van en busca de un desafío interminable. Dependiendo de su organización y proyecto (s), es posible alimentar a estos desarrolladores hambrientos de desafíos, pero es probable que haya un momento en el que simplemente no ' No necesita esa cantidad de potencia de procesamiento. A estos desarrolladores no les gusta quedarse inactivos como un procesador. Se apagarán y se reiniciarán en otro lugar.
Por último, diré que está bien saber quiénes son sus artistas "clave", pero un "equipo" de desarrollo sigue siendo un equipo. Para reiterar bethlakshmi, " ¿qué vas a hacer con esta métrica?"Si necesita un equipo que se comporte como un equipo, no me enfocaría en las métricas como estas. Me daría cuenta de que incluso el jugador más pequeño sigue siendo una parte importante del equipo. Incluso con un 60% menos de la productividad de su clave jugador, ese jugador puede estar dando a su equipo algo que necesita. Descubra qué es e intente multiplicarlo. No queme a su jugador clave asumiendo que debe liderar el equipo, encuentre formas de multiplicar su producción también, contaminando a los otros jugadores con esa grandeza. Esto requiere un poco de creatividad, no solo números. Al final, puedes aprender que lo que hace que un buen programador no sea ese programador, podrían ser sus compañeros, sus oportunidades en el lugar de trabajo o incluso podrías ser tú.
fuente