Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
1IV20.
EL BUEN PROGRAMADOR.
Tiene algo de ciencia y tiene algo de arte. El arte se manifiesta en esos momentos en que hay que hacer
algo y uno no sabe por dónde arrancar. Se nos ocurren mil formas distintas de encararlo, pero todo es
una experimentación. Sumado a eso, puede ser que esa particular tarea no nos agrade mucho. Y por si
fuera poco, la mayoría de los programadores tenemos "horarios flexibles". No tenemos un jefe que nos
diga "¿presentaste el formulario en tribunales?", "¿cuántos clientes visitaste?". En esos momentos es
donde hay que hacerse fuerte y ponerse metas y objetivos, y terminar de alguna manera nuestro trabajo.
Mucho se ha escrito acerca de esto. Incluso se han creado "técnicas" para optimizar el tiempo. Pero
sigue siendo un problema recurrente. El buen programador conoce estas dificultades, conoce sus
propias limitaciones y sabe cómo atacarlo.
Esto también tiene que ver con el "ser" de cada persona, por eso no voy a extenderme en mi análisis. A
mi juicio, lo importante para una persona es sentarse de vez en cuando a solas, en silencio y hacerse las
preguntas básicas:
¿Qué estoy haciendo bien?, ¿Qué estoy haciendo mal?, ¿Me gusta lo que hago?, ¿Cómo puedo mejorar? Y
¿Qué necesito cambiar?
Tener la capacidad de comunicarse con otros es fundamental. Y por comunicarse no digo: "convencer al
otro programador que mi lenguaje es mejor o que mi editor es mejor" o "convencer al PM que tal o cuál
feature quede afuera del release". Me refiero a lograr una profunda comunicación con el otro. Entender
a las personas que nos rodean, conectar, lograr empatía.
La interacción social es la base del crecimiento de nuestra raza. No hay nadie que se haya desarrollado
individualmente. Los programadores podemos tomar mucho de las otras personas. Afortunadamente
hay muchos programadores que fomentan la comunicación. Un ejemplo es la comunidad de PyAr: Si bien
no soy un asiduo participante se ve que las personas interactuan activamente. De ahí salen cosas muy
buenas, los programadores se ayudan a sí mismos y comparten cosas.
Es clave para un programador ir hacia el centro, hacia las bases de lo que hace. Uno no debe "aprender
python". Debe aprender el concepto de objetos, de programación funcional, de concurrencia, etc. Eso es
lo que diferencia a los buenos programadores. Los lenguajes pasan, las tecnologías pasan, las técnicas
pasan. Las bases quedan. Es por eso que quienes aprenden las bases pueden transformarse a sí mismos
hacia lo nuevo, evolucionar.
Con "Conceptos Generales" me refiero a cosas que uno hace a la hora de programar que son básicas y
están más allá del lenguaje de programación o la plataforma usados. Tal vez la mejor manera de
explicarlo es mediante ejemplos:
Manejo de colecciones: Cuál es la mejor forma de iterarlas, de modificarlas. Qué complejidad tiene cada
tipo. Cuándo usar un tipo u otro, etc.
Algorítmica en general:
Curiosidad; Un buen programador siempre está ávido de conocimientos. Hasta que no conoce el
problema en profundidad no se detiene de trabajar. Es esta característica la que permite que un
programador pueda adquirir el conocimiento y habilidades para entender cualquier tecnología
subyacente en la que necesite escribir código.
Pensamiento claro; Un pensamiento claro es un ejercicio de lógica. Por esta razón es que los
programadores con excelentes bases matemáticas superan en rendimiento en la mayoría de las veces a
sus pares que carecen de estos conocimientos.
Atención a los detalles; He notado que la característica de atención a los detalles está estrechamente
relacionada con la curiosidad. Un programador que no presta atención a los detalles principalmente en el
proceso de escritura de código es altamente improductivo. La falta de esta habilidad se refleja en
aquellos que escriben código desordenado, sin comentarios y no implementan las medidas de seguridad
adecuadas para garantizar la integridad del software.
Pasión; Los mejores programadores respiran código las 24 horas. Esta “pasión” es la que permite aplicar
trucos y buscar soluciones creativas al momento de enfrentar problemas complejos.
Adaptabilidad; Es muy difícil que un proyecto de software termine con las mismas especificaciones que
se delinearon al comienzo del proyecto. Las cosas cambian y los grandes proyectos también. Un
programador debe saber cómo adaptarse a los cambios. Los programadores que no se adaptan fracasan.
Explora código; Un forma rápida y eficiente de incrementar tus habilidades en programación es a través
de la exploración de código escrito por otros. Algunos de los mejores programadores del mundo
colaboran en proyectos Open Source. Involúcrate y aprender de los gurúes.
Filosofía…
Bello es mejor que feo, si se ve bien por dentro es probable que lo sea también por
fuera y funcione muy bien.
Explícito es mejor que implícito, no espere que quien lea su código sea un guru, es
probable que más tarde ni usted mismo se entienda, su propia genialidad.
Simple es mejor que complejo.
Complejo es mejor que complicado.
Plano es mejor que anidado.
Disperso es mejor que denso., pequeños trozos de código son mas legibles
que extensos galimatías de código críptico.
La legibilidad cuenta., si al leerlo choca es probable que sea difícil de mantener,
alinear, tabular, separar, emparejar y nunca descansar.
Los casos especiales no son tan especiales como para quebrantar las reglas no olvide
que las excepciones son eso, casos excepcionales no trate de pasarse de listo con
esto.
Aunque lo práctico gana a la pureza., tres lineas de código prosaico son a menudo
mas mas fáciles de darles soporte que una sola linea genial.
Los errores nunca deberían dejarse pasar silenciosamente, cuando menos los
pienses si pueden fallar , fallarán
A menos que hayan sido silenciados explícitamente.
Frente a la ambigüedad, rechaza la tentación de adivinar, si no sabes pregunta.
Debería haber una -y preferiblemente sólo una- manera obvia de hacerlo, código
rebuscado lo único que ayudan es engrandecen el ego de quien lo hizo, y a madriar a
quien le toca darle soporte.
Aunque esa manera puede no ser obvia al principio.
Ahora es mejor que nunca.
Aunque nunca es a menudo mejor que ya mismo.
Si la implementación es difícil de explicar, es una mala idea, lo más seguro que el
menos la entiende, es usted mismo.
Si la implementación es fácil de explicar, puede que sea una buena idea.
Los espacios de nombres (namespaces) son una gran idea, no invente nombre que
luego no recuerde que son., se supone que deben ser una ayuda, no un mensaje
de espías.