Salario de un buen programador

Como gerente de proyectos, ¿que considerarías una buena contratación?.

1. Un programador cuyo salario ronda la media y produce lo que la media
2. o uno cuyas aspiraciones salariales sobrepasan a las del resto de tu equipo pero produce 5 o hasta 10 veces más? 

¿¿10 veces más??? - no puede ser!

Puede sonar exagerado pero el desarrollo de software es una de las disciplinas en donde podemos encontrar una disparidad similar de rendimiento productivo. 

Una contratación no adecuada puede aportar a tu equipo no solamente un rendimiento negativo (no solamente gastas dinero en un recurso que no aporta valor sino que su inclusión merma el rendimiento global, en lugar de incrementarlo), sino que puede afectar al ambiente de trabajo, creando insatisfacción, baja moral, sensación de poca realización profesional y/o estancamiento.

Sin embargo, una buena contratación, además de las aportaciones personales del individuo, puede atraer un ambiente creativo, nuevas ideas y estimular la productividad general y satisfacción del equipo de desarrollo.

Como dice Joel, es mejor no contratar un programador bueno que contratar uno malo (inglés)

¿Y como diferencio a un buen programador?

Cuidado, a veces las apariencias engañan:

Un programador no es productivo:

• Si produciendo muchas líneas de código en poco tiempo o "acabando" sus tareas rápidamente:
  1. Se tarda muchas veces más lo que costó la tarea en sí en encontrar y solucionar los bugs asociados al el código creado (hacerlo deprisa y mal, vamos)
  2. Se crea código repetido, mal diseñado, o inmantenible que hace dificultosas futuras modificaciones (pan para hoy, hambre para mañana)
  3. Crea interfaces poco usables, que el usuario no entiende, generando muchas horas de soporte y modificaciones, y lo peor, insatisfacción en el cliente.
• Un programador es productivo, si produciendo muchas menos líneas de código:
  1. Anticipa requisitos futuros, evitando altos costes de reprogramación
  2. Crea código de calidad, que necesita poca o ninguna revisión posterior en QA
  3. Crea código mantenible y fácilmente entendible por otro programador.
  4. Piensa en como el usuario va a utilizar la aplicación y crea interfaces usables,  evitando tener que contratar un especialista en experiencia de usuario y aumentando la satisfacción del cliente.

Este artículo (inglés) introduce un concepto interesante: "total cost of ownership" o "el coste de tener un desarrollador en la empresa." 

El hecho de que un programador pueda escribir código eficiente, mantenible, usable y con menos fallos, hace que aumente la  productividad de conjunto del equipo de desarrollo, que el equipo de QA trabaje más tranquilo (y dedique menos recursos a revisar su código) y que al final el cliente esté más feliz con la aplicación, aumentando la satisfacción y productividad de todo el mundo. ¿Que precio tiene eso?

Moraleja: si estudiamos su productividad, los mejores desarrolladores están infra-remunerados, y los peores, sobre-remunerados.

Actualización (19Feb09): Concepto interesante: Programadores con producción neta negativa.

2 comentarios

[ivan - 19 de febrero de 2009 - 16:51]

La suerte y desgracia de Joel es que recibirá cientos de CV de candidatos de todas partes del mundo (de candidatos con opción a VISA estadounidense, claro) y tendría un "cuello de botella" en los períodos de prueba de los candidatos, teniendo que rechazar a muchos realmente buenos por falta de vacantes o espacio.

Estoy de acuerdo contigo Alfredo en que cuando recibes unos pocos CV al mes y no tan brillantes tienes más obligación de utilizar el método de prueba/error.

[Alfredo - 19 de febrero de 2009 - 16:43]

No estoy muy de acuerdo con Joel. A un mal programador lo despides en el periodo de prueba. Y si dejas pasar a un buen programador ya no lo recuperas.