No suelo hablar de estos temas, hay lugares más especializados en esta temática y que seguramente lo comenten mucho mejor que yo. Quizás la experiencia propia me haga estar totalmente de acuerdo con el artÃculo que referencio.
Normalmente en las empresas de consultorÃa informática en la que los trabajadores son recursos, se suele dar la circustancia de que un buen programador sale caro para el proyecto, por lo que debe ascender, pasar a ser analista (o documentalista, según se vea) y asà ser productivo para el cliente.
El artÃculo comenta ciertas cosas que muchos gestores de proyecto deberÃan tener en cuenta, como por ejemplo que un buen programador es más productivo que uno medio. Un buen programador suele hacerse cargo del proyecto y no suele ser necesario que estén detrás de él, que le expliquen las especificaciones o los requerimientos. Tampoco hay que estar detrás de él para saber el estado de su trabajo.
Cuánto mayor es tu experiencia desarrollando, más conocimientos tienes y menos fallos cometes, aunque sea por haberte peleado con ellos. Incluso encuentra los fallos con mayor rapidez y le da una solución en menos tiempo, ya que en muchas ocasiones los fallos suelen ser bastante parecidos y se repiten.
Supongo que por la experiencia de que el código nunca acaba de estar completo, asà como las funcionalidades, un buen programador suele escribir código más fácil de mantener. Lo cual reduce tiempos de desarrollo en funcionalidades posteriores, y no hacerlo aumenta los tiempos estimados de desarrollo. Pensar en el futuro te evita reescribir lo ya desarrollado y añadir cosas nuevas con más facilidad.
El código limpio y eficiente se consigue con los años de trabajo. Es lógico pensar que un buen desarrollador hace más cosas en menos código, lo cual en caso de errores detectados, localizar el punto donde falla será más fácil porque hay menos código que seguir.
También me gustarÃa añadir que un buen desarrollador suele encontrar los fallos que cometen los analistas, sin necesidad de preguntar a éste cómo hacerlo. Y por último, darle un consejo a los jefes de proyecto, dos juniors no salen más baratos que uno o dos seniors, la experiencia lo demuestra (al menos desde el punto de vista del desarrollador).
Gracias Millán por el enlace.
10 Developers For The Price Of One