¿Cómo saber quien es un buen desarrollador?

Planteaba José M. Aguilar la interesante cuestión que da título a este post. Es también una pregunta que recibo a menudo en los cursos de Gestión de Proyecto que imparto. Asi que voy a dar mi opinión. Opinión que esta basada simple y llanamente en lo que yo valoro cuando trabajo con un desarrollador codo con codo.


Todas las cuestiones que se han planteado en los comentarios al post de José son relevantes, desde luego, pero en mi opinión hay tres factores claves a la hora de distinguir a un buen desarrollador:


La calidad de los artefactos que generan (código, diagramas, diseños, planes de proyecto, burndown charts, etc… según el perfil), algo facil de comprobar simplemente viendolos. Ver el código de un desarrollador, pantallazos del trabajo de un diseñador, o pedirle a un arquitecto que te explique algunos diagrámas de sus arquitectura es algo que sin duda nos va a dar idea de la calidad de su trabajo. En el desarrollo de software la calidad no es opcional. Esto nos da un vistazo ràpido de las capacidades técnicas con cierta independencia de la tecnología que emplee. Si un desarrallador no nos puede enseñar nada del producto de su trabajo es seguro una mala señal y esto ocurre a menudo. Por otro lado, aquel que nos enseñe su trabajo y hable de él con pasión tiene bastantes números, en mi opinión, para ser un buen desarrollador.


La cantidad de proyectos completados, puestos en producción y con usuarios usándolos en los que han participado. Esto nos da una idea rápida de la experiencia real y de las capacidades no técnicas. Es fácil preguntar por este punto en una entrevista, además da oportunidad al desarrollador de explayarse sobre lo que aporto en esos proyectos, las dificultades que encontro etc… Pero sobre todo esto nos da una idea de si es alguien que termina lo que empieza. Conozco algunos desarrolladores técnicamente excelentes incapaces de completar nigún proyecto. Un proyecto es un camino duro, lleno de momento mejores y peores, de cosas divertidas y cosas menos divertidas. Muchos desarrolladores pierden la ilusión por el proyecto una vez esta hecho lo que ellos consideran el ‘trabajo bonito’. Otros muchos carecen del pragmatismo necesario para completar los proyectos, y convierten los proyectos en los que participan en un continuo ejercicio de investigación. Hay que distinguir desarrollo de investigación. La cantidad de proyectos completados también es indicador de la capacidad para dominar tecnologías, en lugar de dejar que estas dominen el discurrir del proyecto. No quiero decir que las cuestiones técnicas no sean relevantes, pero si quiero decir que no son las más relevantes.


Las capacidades de comunicación tanto oral como escrita. Esto nos da idea de si podrá comunicarse con otros miembros del equipo. Las dificultades de comunicación es uno de los principales problemas que se encuntran los proyectos de software. Si los miembros del equipo no son capaces de transmitir información de manera fluida tendremos serios problema a la hora de conseguir que el equipo de desarrollo funcione como un autentico equipo. Además esta no es una cuestión relevante solo de puertas adentro del equipo. Los proyectos son un exito o un fracaso en función de lo que el cliente percibe. Un grupo de desarrolladores capaz de comunicarse con soltura con el cliente con seguridad va a obtener mejores resultados, resultados más alineados con las necesidades del cliente. Pero si este no fuese el caso y los resultados solo fuesen ‘normalitos’, las capacidades comunicativas siempre juegan a favor de que los resultados obtenidos, sean cuales sean, se ‘vendan’ mejor. Otro factor importante es que quien es un buen comunicador suele ser un gran lector, y para estar al día en esta industria hay que leer mucho… por mucho que a algunos no les gusten los libros. Y para terminar todo proyecto de software necesita generar algo de documentación por mucho que yo no sea muy amigo de la documentación por la documentación (1, 2 y 3), y es una tarea que los desarrolladores no disfrutamos por lo tanto cuanto mejores seamos escribiendo menos nos costará realizar la ardua labor. 

9 comentarios sobre “¿Cómo saber quien es un buen desarrollador?”

  1. Yo opino que la clave está en el mismo aspecto que en cualquier otro trabajo de este mundo, el trabajo te tiene que apasionar y que gustar, el resto es echarle horas.

    Pero esos tres puntos que has nombrado, para el mundo de desarrollo de software son básicos e indiscutibles.

    Un saludo 🙂

  2. Muy interesante… Agregaría la capacidad de encontrar soluciones, muchas veces me he encontrado con desarrolladores que simplemente esperan que les digan lo que hay que hacer y que frente a la barrera de un problema se cruzan de brazos… La capacidad de resolver problema con sentido común (creatividad) para mí es valiosa.

  3. Yo cambiaria en el título «buen desarrollador» por «excelente desarrollador», ya que considero que tanto este articulo como el que lo ha provocado describen a «excelentes desarrolladores» y creo que no es posile juntar tanta «calidad» profesional en un mismo grupo de trabajo, por salud. Considero necesario tener un grupo de «buenos programadores» capaces de aplicar la tecnologia seleccionada por el equipo para resolver el problema planteado, incluso sin formular demasiadas «pegas» a su diseño, pero si con un profundo conocimiento de la herramienta. Tener un equipo lleno de «excelentes programadores» lo compararia con una obra llena de arquitectos e ingenieros haciendo albañilería, fontanería, etc.
    El «excelente programdor» debería cumplir las características que habeis descrito, además de ser creativo, es decir, imaginar y pensar nuevas formas y cosas a aplicar a la solución e innovador, es decir, una persona perseverante que haga y aplique de forma pragmática las ideas surgidas de la creatividad, aunque sea copiando, hasta finalizarla. Estas dos características, si están en la misma persona, deberián representar un 50% cada una, ya que considero que la persona creativa, una vez aportada la idea, tiende a pasar su aplicación a otro para que la desarrolle y así poder implicarse con nuevos «retos».
    Y lo más importante, sin lo cual, no valen ni buenos ni excelentes ni na de na, si no tienes unos responsables que te dejen ser creativo e innovador, que por desgracia suele ser lo típico, de poco valen todas estas características.
    Un saludo, VAS.

  4. Yo creo que generalizar nunca es buena idea y el título habla sobre un perfil bastante concreto.

    En un proyecto entran en juego diferentes roles y no todos requieren las mismas aptitudes y precisamente esa es la gracia de los Roles.

    Cuando buscas un jefe de proyecto no buscas lo mismo que un analista o si simplemente necesita un desarrollador.

    Hay que diferenciar muy bien los perfiles o se busca un chico para todo con ganas de trabajar?

    Saludos.

  5. Vas, estoy de acuerdo en la mayor parte de lo que comentas, pero no comparto tu opinión en lo relativo a que no es sano juntar muchos buenos desarrolladores. Cuantod mejores buenos desarrolladores puedas poner en tu equipo mejor.

    No me vale el símil de «Tener un equipo lleno de «excelentes programadores» lo compararia con una obra llena de arquitectos e ingenieros haciendo albañilería, fontanería, etc.»

    Evidentemente en un equipo de desarollo tiene que haber diferentes perfiles, pero al contrario que en una obra, en un proyecto todos los perfiles tienen un valor muy similar. Todos los roles de un proyecto son igualmente valiosos. No creo en tener ‘picacódigos baratítos’. En una obra tu puedes tener a un peon moviendo tablones, y si no es muy listo, lo más que puede hacer es atramparse un dedo. Un desarrollador malo puede afectar a un proyecto de miles de formas. Para empezar, cada línea de código supone una decena de decisiones de diseño. Esto es lo que hace que desarrollar software sea diferente de el resto de actividades productivas.

    Un saludo titán!!!

  6. Aupa Rodrigo!

    Yo bajando al crudo mundo de la realidad… Realmente es muy difícil encontrar gente con todas y cada una de esas características, y más difícil aún contar con varios de esos en una empresa (salvo en ciertas excepciones, claro ;)). De ahí que tengamos que evaluar puntos fuertes y débiles de cada persona, y combinarlos para que se compensen entre sí. No será el equipo ideal, pero será válido.

    Por ejemplo, creo que el papel del megafriki también puede tener su sitio, y ese sitio es el del «Catalizador». Este Catalizador, campeón de lo técnico al cual le aburren sobremanera los «sota-caballo-y-rey», te puede servir de soporte para varios equipos, cada uno en su proyecto, para quitarle las piedras del camino a los proyectos. Así puedes tener a una (o más) personas que te ahorran muchas, muchas horas en diversos proyectos, y que hacen fácil lo que a otras personas les resultaría complicado.

    Es decir, tienes gente centrada en darle al cliente lo que necesita (es decir, proporcionarles la funcionalidad que necesitan), y unos poquitos (los fontaneros, que ponen tuberías y les encanta) ayudando a esta gente con los obstáculos técnicos que puedan aparecer.

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *