Leyendolo bien, no tiene mucha diferencia con ser docente, ¿no?
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.
