Ogeid

Ricardo Galli describe Diez señales de que no eres tan buen programador como piensas. Algunos de sus puntos son muy buenos, en especial el #2 y el #8 que marcan la diferencia entre un amateur y alguien que realmente entiende que hacer software profesionalmente es más que lograr que un programa funcione. No estoy muy de acuerdo con el primer punto, “estás convencido de que eres muy buen programador”. Sí creo que los mejores programadores suelen ser modestos y no van a gritar a los cuatro vientos que son unos genios, a pesar de saberse mejores que la media. Yo lo expresaría de la siguiente manera: de todos los programadores que están convencidos de que son muy buenos, esto sólo es cierto para una minoría.

A continuación van otros cinco signos que a mi entender delatan a un programador mediocre. Están en tercera persona, ya que imagino que ninguno de ellos lee este blog

1. Está convencido de que su herramienta o lenguaje preferido es mejor que otros.

He oído a muchos fanáticos de Python/Java/[insertar cualquier otro lenguaje popular] hablar en forma despectiva de otros lenguajes de uso masivo. Profundizando en la discusión, casi siempre ocurre que la persona se basa en supuestos sobre los otros lenguajes que o bien nunca fueron ciertos, o que han dejado de serlo hace mucho tiempo. Por ejemplo “Java es lento” o “Python no tiene buen soporte para aplicaciones web”. La realidad es que casi todos los lenguajes masivos son apropiados para una gran cantidad de desarrollos, y siempre existen algunos problemas para los cuales una plataforma puede ser más conveniente que otra. Eso no quiere decir que uno tenga que aprenderse todos los lenguajes, pero sí estar con los ojos abiertos a las alternativas posibles para solucionar un problema.

2. No dedica tiempo a continuar aprendiendo.

En esta profesión, nada se mantiene constante. Por ejemplo, una nueva versión de un lenguaje incorpora como nativas ciertas funcionalidades que antes uno debía desarrollar por su cuenta. Surgen herramientas nuevas que le ahorran mucho trabajo a quien las sabe usar. Y aunque todo fuera estático, uno siempre sabe menos de lo que cree y todos los días se puede aprender algo de otro. He conocido “programadores expertos” en lenguaje C que no conocen detalles relativamente básicos del lenguaje que están explicados con lujo de detalles en el libro de Kernighan y Ritchie.

3. Piensa en la implementación antes de analizar bien el problema.

El objetivo de un desarrollador de software es solucionar un problema. Un vicio de muchos programadores, que en realidad es parte de la naturaleza humana, es querer utilizar inmediatamente la experiencia adquirida y lanzarse a implementar una solución. En el terreno del software esto es peligroso. Antes de zambullirse a escribir código es necesario detenerse a pensar en las posibles evoluciones del sistema. Por ejemplo, qué funcionalidades nuevas querrá el usuario, qué requerimientos tienen más probabilidad de cambiar con el tiempo, qué ocurrirá si el número de usuarios crece muy rapidamente, etc. Por supuesto está el otro extremo (la famosa parálisis por análisis), pero por lo general eso se termina a la fuerza cuando el manager o el cliente exige algo para la semana que viene.

4. Le resulta difícil explicar sus ideas a otros.

Esto es una extensión del punto 4 de Ricardo, acerca del código ilegible. Un buen programador no sólo debe escribir código mantenible sino que además debe ser capaz de comunicar sus ideas en forma oral y escrita. El desarrollo de un sistema lo suficientemente complejo requiere la colaboración de gente con distintos niveles de conocimientos técnicos. Obviamente no es lo mismo explicar un bug de software a un colega que lograr que un cliente entienda que ese bug tiene repercusiones importantes y es necesario resolverlo antes que, por ejemplo, dedicarse a mejoras estéticas. Es cierto que la programación a veces atrae a personas con dificultades de comunicación que pueden llegar a hacer excelentes desarrollos de pequeña escala a nivel personal. A nivel profesional, el desarrollo de la capacidad de comunicación es tan importante como el aprendizaje continuo en lo técnico.

5. Le cuesta decir “no sé”.

Me ha tocado participar en proyectos en los que alguien llevó a cabo lo que llamamos “trabajo negativo”. Es decir, hubo que deshacer el desastre implementado por alguien y rehacerlo correctamente. Si el perpetrador original hubiera admitido que la tarea estaba por encima de sus capacidades, se habría ahorrado mucho tiempo. Esto en realidad vale para casi cualquier profesión (quizás no para un político), pero admitir la ignorancia propia es un signo de madurez y confianza en uno mismo. Un buen programador tiene presente que siempre es mucho mas lo que ignora que lo que sabe, y en particular no tiene deseos de reinventar la rueda. A veces se nos aparecen problemas que nunca hemos resuelto antes, y es probable que alguien dentro de la organización (o si no, en cualquier foro de discusión específico) lo haya enfrentado antes y pueda ayudarnos.

Para finalizar, estoy totalmente de acuerdo con lo que dice Ricardo respecto de lo que llama el movimiento “mileurista” (los programadores españoles que se quejan porque no les pagan más de mil euros). Las empresas serias pagan sueldos mucho mayores que eso, incluso un buen programador puede cobrar mil euros en lugares del mundo donde el costo de vida es una fracción del de España. Lo cierto es que el software es una actividad difícil y existe una enorme diferencia de habilidad entre la minoría más capaz y la media. Habiendo entrevistado a cientos de programadores a lo largo de la última década, en mi experiencia lo más común es que un candidato muestre una o más de las señales que describe Ricardo. Y eso sin contar los que son eliminados antes de llegar a la entrevista.