Programar es ...

Mito: Los programadores escriben código todo el día. 

Verdad: La mayoría de los programadores consumen un montón de tiempo (sin ningún orden en particular):

• Escribiendo con cuidado e-mails a otros programadores / listas de correo / personas no técnicas.
• Asistiendo a reuniones, trabajando en maquetas y esquemas de base de datos, preocupandose por las consecuencias en el rendimiento de las características propuestas.
• Redactando informes de errores y buscando errores en la DB.
• Luchando para averiguar por qué sistemas con numerosas capas ocultas están fallando, buceando en ficheros log de muchos GB’s con herramientas de línea de comandos. 
• Explicando el tiempo de caída del sistema a los usuarios o a altos directivos. 
• Aportando soluciones a extraños problemas.
• Leyendo documentación / libros / blogs de programación / notas de la versión/ anuncios de vulnerabilidad.
• Buscando código existente que hace lo que se quiere pero sin saber a qué llama.
• Evaluando si el código encontrado resuelve el problema /tiene un rendimiento aceptable/ se ajusta a la arquitectura / tiene una licencia aceptable / tiene una comunidad activa de soporte.
• Instalando, configurando y probando un código cuando se da cuenta que este no va a hacer lo que se pretende que haga.
• Googleando mensajes de error.
• Buceando en repositorios de código libre para ver "cómo [algunos proyecto de código abierto] lo hacen".
• Aprendiendo herramientas de control de código, utilidades bash, GNU, y los permisos de archivos de Linux (y / o los equivalentes de Windows).
• Configurando el IDE, las máquinas virtuales, los servidores web y las bases de datos.
• Encontrando la manera de meter con calzador un código que no fué diseñado para coexistir con otro.
• Determinando que tareas priorizar de una lista sin fin.

Versión traducida del blog www.mrclay.org - http://www.mrclay.org/2011/04/01/programming-is/

El último paga los platos rotos

Una verdad recurrente en el desarrollo de software es que los programadores pagan todos los errores, retrasos, carencias o ineficiencias en los pasos previos del proceso de desarrollo.  Muchas veces he pensado que este hecho era particular del proceso de desarrollo (ayudado por la incompetencia de muchos perfiles de consultoría). Esta mañana, esperando a que llegara mi compañera en su coche a recogerme he tenido tiempo de pensar en una metáfora que quisiera compartir.

Tengo la suerte de que me recogen enfrente de mi domicilio y me traen en coche hasta la oficina. Existen varios “acuerdos” más o menos formales: debo estar preparado entre las 8 y las 8 y cuarto de la mañana, pero se me avisa con una llamada perdida para que tenga tiempo de llegar al punto de recogida. Todo fácil.

Yo me planifico para estar listo para salir sobre las 8 de la mañana. Hay días que uno va sobrado de tiempo y me permite terminar tareas caseras pendientes; otros, por el contrario, voy mal de tiempo y, cuando suena el móvil con la llamada perdida, estoy terminando de arreglarme para salir. Es decir, el problema está en los límites inferior (las 8 de la mañana) y superior (las 8 y cuarto de la mañana).

Si mi compañera viene pronto (minutos antes de las 8) entonces hace la llamada de aviso en el último momento. Yo, que voy con mi planificación más o menos, me encuentro a medio arreglar y ya voy mal. Salgo con la lengua fuera. Malo para mí (y malo para ella que, normalmente le toca esperar).

Si, por el contrario, mi compañera viene tarde (minutos después de las 8 y cuarto) entonces hace la llamada de aviso pronto; supongo que tiene que ver con el agobio que lleva con la hora, intentando ganar tiempo al tiempo. Yo ya llevo un rato preparado y esperando la llamada y salgo rápido (o ya me han podido los nervios y he salido previamente al punto de encuentro). Resultado: me toca esperar más tiempo en la calle. Malo para mí.

 
En consecuencia, como soy el último de la cadena (como el desarrollador de software en el ciclo de vida de un sistema de información), soy el pagano de los platos rotos previos. Por defecto o por exceso.