El programador (una apología)

Me apetece hacer apología del puesto de programador, porque creo que es necesario por dos motivos fundamentales y relacionados: no se le considera un puesto apetecible por ser jerárquicamente bajo y no se tiene conciencia de que la experiencia en la programación sea útil. En resumen, que el puesto de programador no se considera de futuro[1]. Pero no es el futuro profesional del programador[2] de lo que quiero hacer apología, sino de la labor del programador en si: difícil pero necesaria y apasionante[3].

Los buenos programadores son imprescindibles para que este mundo funcione. En la eterna, manida y estéril discusión de las atribuciones profesionales se suele denostar la labor de programador en favor de la figura del arquitecto de software. No voy a entrar aquí en lo importante de una buena dirección y coordinación en un proyecto de desarrollo (que lo es), sino de lo importante que es el trabajo de base. Porque el de programador en un puesto intrínsecamente bajo desde el punto de vista jerárquico. ¿Significa eso que es un trabajo rutinario, sin retos ni creatividad? En absoluto. Es un trabajo muy decisivo, a veces creativo y de gran responsabilidad casi por definición.

Es difícil porque hacer software es intrínsecamente difícil[4][5] Y el creer que toda la dificultad se puede abstraer del programador hacia arriba en la jerarquía no deja de ser una especie de pensamiento mágico alejado de toda realidad. Es prácticamente imposible hacer un análisis y diseño completos sin resquicios y teniendo en cuenta todos los detalles del sistema final, tanto funcionales como de rendimiento y seguridad. Es muy frecuente que aparezcan aspectos dependientes de que la implementación sea óptima y adecuada al uso del sistema final.

Es de una gran responsabilidad porque, entre otras cosas, es muy fácil hacerlo mal y no es trivial descubrirlo[6]. El programador moldea con sus manos el sistema final que va estar funcionando, transforma en realidad, en funcional, un concepto ideal. Y es el que más directamente que se da de bruces con las limitaciones del mundo real, de las herramientas y los sistemas. Es el que, si es brillante, es capaz de dar soluciones a esas limitaciones o al menos no acrecentarlas. Pero un programador no muy hábil o simplemente poco disciplinado o descuidado puede provocar errores, tanto fáciles de detectar como demasiado sutiles para ser detectados cuando deben, en la fase más temprana posible del desarrollo.[7]

Tengo que decir que lo que yo entiendo por programador es lo que a veces se denomina "desarrollador", algo un poco más amplio que solo tirar líneas, pero me niego a renunciar a usar el término: me gusta decir programador, me gusta programar.

[1] Y es posible que no lo sea :( Me gustaría pensar que, por lo que cuento después, lo es.
[2] Bueno, hay muchos futuros dentro del desarrollo. Uno, ascender. Otro, especializarse. Pero bueno del futuro profesional prefiero que hablen los comentaristas...
[3] Obviamente hay mucho que comentar de los aspectos sociales del programador, que pueden condicionar, pero no hablaré de ellos. Para saber más pasa por aquí ( bueno, o por aquí)
[4] "The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence" No silver Bullet, Frederick P. Brooks
[5] Un poco más actual: Software Is Hard, Kyle Wilson
[6] Me gusta mucho la frase de Brian Kernighan: "Depurar es el doble de difícil que escribir el código por primera vez. Entonces, si escribes código tan inteligentemente como te sea posible, no vas a ser, por definición, suficientemente listo para depurarlo" Depurar es otra habilidad quizás no demasiado valorada del programador experto.
[7] Metodologías de desarrollo y/o testeo adecuadas y acordes con el proyecto aceleran la caza de errores, pero la disciplina y experiencia del programador son la base del desarrollo de calidad.

"El programador (una apología)" en barrapunto

¿Está acabando internet con el contenido extenso?

Se suele recordar mucho últimamente que el vídeo mató a la estrella de la radio por aquello del cambio de formato y de la (no) adaptación de la industria musical a esos nuevos formatos. Lo mismo seguramente se puede ampliar al resto de los contenidos culturales, en el amplio sentido de la palabra, y sobre todo al libro ¿Mató internet el contenido extenso? ¿Mató internet a los libros?

El caso es que últimamente he visto varios casos en los cuales el modo de publicación es controvertido porque se trata de contenidos de un volumen grande, más grande que un post de blog, para entendernos. Primero fue Ulrich Drepper que dudó que opción tomar y tomó la resolución de publicarlo por partes en LWN. Ian Lance Taylor ha publicado un número enorme de post, veinte, muy interesantes (para mi al menos ;) ) sobre enlazadores, pero demuestra claramente que el blog no sirve para crear contenidos amplios y legibles a la vez.

¿Cual es la tendencia? Hemos visto decaer sitios de generación y promoción de contenidos que premiaban calidad y extensión, como k5 o libertonia. Triunfan sitios del tipo digg, reddit o meneame en los que sólo se hace referencia y se extracta brevemente. No se me entienda mal, los sitios me parecen útiles, programming.reddit y tecnologia.meneame los visito y uso. Pero creo que tienden a ser autocontenidos, a quedarse más en si mismos que a servir para lo que probablemente deberían servir: promocionar contenido de calidad. Es la tendencia al minimalismo, tanto en la referencia como en el comentario: estos sistemas premian la brevedad y la concisión, con buenas razones, pero en perjuicio de contenido espeso y en favor del impactante. /. en las dos versiones que uso estaría a medio camino, pero no se acaba de librar de este mal... Es el signo de los tiempos, en los que la sobrecarga informativa va acompañada de atención parcial continuada...

Pues bueno, Charles Petzold, que escribe mucho mejor que yo y que además tiene un buen curriculum de libros espesos publicados reflexiona sobre ello en Hard Work, No Pay: What's the Point?, teniendo en cuenta que lo hace, al menos en parte, desde el punto de vista de un autor. Se pregunta ¿por qué libros y no entradas en blogs? Y responde (citraduzco un poco al vuelo)

Es fácil convencerse de que los pedacitos de prosa representan el nivel óptimo de granularidad de información. Es parte de la visión utópica de la web como una plétora de páginas débilmente enlazadas cuya sinergia genera toda la información que necesitamos. Esta ilusión está afectando a la manera en la que aprendemos y tengo miedo de que no tengamos una visión más amplia y completa que solo un libro puede proporcionar. Un buen autor encontrará una selva poco manejable de información y cortará una senda coherente para pasar a través de ella, a través de una narrativa que enlaza el material.

Respuesta que me ha gustado mucho porque ilustra muy bien el tipo de libros que deberían sobrevivir a la mencionada sobrecarga informativa: aquellos que son capaces de establecer un poco de orden y hacer un poco más comprensible la realidad fragmentada.

¿Está acabando internet con el contenido extenso? en barrapunto

Lo que todo programador debería saber sobre la memoria

Así titula Ulrich Drepper un artículo sobre los posibles cuellos de botella que se generan en las arquitecturas modernas de uso común, explicando el comportamiento de las caches de CPU, el diseño de los controladores de memoria, el DMA... Debería ser útil para esos momentos en los que las abstracciones que usamos empiezan a fallar y debemos conocer lo que hay debajo.

El modo de publicarlo es un poco, bueno, llamémosle arcaico, pero nos conformaremos porque el contenido lo merece, y porque es el deseo del autor, claro... El caso es que se va a publicar por partes en LWN.net y al comienzo serán accesibles solo para suscriptores y posteriormente para el resto. Al final publicarán la versión pdf que probablemente será muy interesante para imprimir. Actualización (22/11/07): Ya está disponible la versión en pdf: "What Every Programmer Should Know About Memory" por Ulrich Drepper

He ido actualizando esta entrada conforme se han liberado las todas las partes del documento, muy interesantes:

• What every programmer should know about memory, Part 1
• Memory part 2: CPU caches
• Memory part 3: Virtual Memory
• Memory part 4: NUMA support
• Memory part 5: What programmers can do
• Memory part 6: More things programmers can do
• Memory part 7: Memory performance tools
• Memory part 8: Future technologies
• Memory part 9: Appendices and bibliographys

Bonus Track: Como creo que pega en esta entrada, pongo el link a unas charlas con diapositivas de Herb Sutter sobre temas similares: Machine Architecture: Things Your Programming Language Never Told You (jejeje, Sutter y Drepper ¿lo mejor de los los dos mundos?)

Lo que todo programador debería saber sobre la memoria en barrapunto

Paul Graham Facts

Paul Graham Facts. Sólo apto para quien sepa quien es Paul Graham (bueno, y aún así...) Ejemplo: Paul Graham is so good, he always tips using $2.56 cheques made out by Donald Knuth

Actualización: por si alguien es tan masoquista de quedarse con ganas de más: Bruce Schneier Facts. Espero que me sepan perdonar :)

Paul Graham Facts en barrapunto