Sobre los técnicos en programación de software y los pegadores de ladrillos

Con este son ya diez los años que llevo escribiendo código. Diez años no son nada. Los años los inventamos nosotros, pero ¿y el tiempo? ¿y la muerte?. 10 es un signo, pero ¿y el número? ¿y las matemáticas? Debido a ese extraño valor simbólico que damos al aniversario reflexioné sobre algunos momentos clave en este primer decenio. Empecé por el técnico laboral en programación de software y no tardé en fijar mi atención en lo malo que había sido, o al menos, en lo mal orientado que estuvo. Ahora dudo de la dificultad de comunicación entre industria y academia, ahora creo que en la instrucción de estos técnicos se refleja, no lo malo, si no lo poco que se entiende este oficio desde el mismo mercado laboral.

Una vez un amigo me contó, exaltado, que un dirigente de una organización se había referido a su equipo de desarrollo como pegadores de ladrillos -no recuerdo haciendo referencia a qué pero ahora no es importante- y cómo él había refutado esa posición y defendido al gremio de las punzantes opiniones de un insípido dirigente que levitaba con el poder de su cargo. Lo relevante de su relato no es la posible tensión ideológica en la comparación de los oficios pues el capitalismo no distingue eso, lo interesante es la analogía misma con el gremio de la construcción pero no al nivel de los respetados arquitectos y las complicadas arquitecturas, sino al nivel de los obreros, los maestros y sus ayudantes.

Muchos barrios de la ciudad han sido levantados por sus habitantes, levantando desde la maleza que cubría los terrenos. En la construcción de una vivienda participaba más de una familia donde algún familiar era o conocía a un maestro, también vecino de estos porque todos apenas llegaban. Entre muchos maestros dieron cara e identidad a barrios enteros con la práctica de su saber popular, ajustándolos a las necesidades reales de sus habitantes, es decir, ellos mismos, la comunidad. Para llegar a ser maestro de obra se empieza por ayudante, en ocasiones de algún familiar, ayudando, por ejemplo, a subir y bajar material y escombro; a mezclar; pegar ladrillos; etc. Saber cómo levantar una casa es algo que el ayudante aprenderá en un número indeterminado de construcciones y con un número indeterminado de maestros.

Related image

Viendo el pensum del técnico en programación de software en las páginas de varias instituciones se evidencia el mismo error: se espera que en dos años de instrucción el sujeto sepa lenguajes de programación, bases de datos, dispositivos móviles y hasta “Desarrollar aplicaciones complejas utilizando bases de datos”. Plantear un programa así es desconocer las necesidades de la industria, aún muy joven en el país. La orientación que se debe dar a un técnico en programación de software es similar a la de los ayudantes de construcción.

Los maestros de los que hablo aquí no recibieron una y otra vez, en distintos niveles académicos, la instrucción y la practica de cómo hacer una casa. Primero se aprende cuanto pesa un bulto de arena, cuanto esfuerzo cuesta moverlo. Se acude tanto a la ceremonia de la praxis que cuando el ayudante es ya un maestro sabrá, con un movimiento rápido del metro, cuantos viajes de arena necesita para iniciar una obra.

Es más útil para el equipo contar con alguien que sepa automatizar tareas con, por ejemplo, bash o que domine git a estos técnicos que saben hacer un crud. El perfil de nuestros técnicos, como el de un ayudante de construcción, debe ser el de un facilitador para el equipo, con dominio de varias herramientas. Alguien que tiene lista la mezcla de arena y cemento cuando empieza la construcción.

Introducir un perfil como este, un automatizador entrenado para que los programadores no se ocupen, por ejemplo, de un script de compilación y despliegue automático en la industria sacudiría a más de un equipo de programadores e ingenieros obsoletos que, por estar pensando si mejor en blanco o en negro, siguen compilando en la máquina del único cuyo usuario tiene acceso al servidor que también tiene instalado Visual Studio, por si es necesario… Ese es el estado de nuestros equipos de desarrollo. Por eso, no es de extrañar que demanden de la academia lo que no necesitan: más jóvenes que arrastren y suelten botones en una pantalla.

Es común que las discusiones sean del orden de si microservicios o monolítico, ¿y nosql? ¿si redis? ¿y el performance? pero nunca una sobre una estrategia de integración continua consensuada, y como se desconoce, obvio, nadie sabe implementarlo.

La instrucción de estos técnicos es mucho más sencilla, es realmente una instrucción de técnica, de repetición, como una kata, se usa una y otra vez la herramienta hasta que se domina. Conociendo, por ejemplo, un sistema de control de versiones, lo que es un compilador y sabiendo hacer un script de compilación, entonces si pensamos en escribir código, en aprender un estilo ya sea en la practica o en un siguiente nivel académico.

En el desarrollo de software le hemos puesto etiquetas a situaciones comunes con la construcción: el segundo piso de una casa lo nombraríamos feature y a un piso desnivelado le diríamos bug. Conocer e identificar estos artefactos, saber, por ejemplo, qué es y cómo se redacta una historia de usuario en determinadas herramientas facilitará la integración de los técnicos en el equipo, para esto no es necesario saber qué es el polimorfismo, solo distinguir una situación y usar una herramienta para documentarlo. Es necesaria la comunicación: son más los equipos que fallan por sus individuos e interacciones que por las herramientas y los procesos.

Ser productivo en un lenguaje de programación es fácil, pero solucionar problemas reales construyendo un producto de software no lo es tanto. Para esto es necesario participar en varios proyectos, en varios equipos, conocer e ir creando un estilo propio, un estilo definido por las necesidades y restricciones propias de las organizaciones y las verticales de negocio en las que hemos intervenido.

Nuestro oficio no es el de científicos de la computación, aunque obvio que hay ciencia en esto como en saber levantar las columnas de una vivienda. Hay que bajar la programación de software al servicio de la practica y elevar su enseñanza a ciencia, como la ciencia que existe en enseñar a alguien a construir una casa.

Debemos reconocer en los procesos de aprendizaje de oficios milenarios, como el de la construcción, aspectos y técnicas que nos pueden ser útiles. Este es un oficio joven aún y ya nos hablan de un deficit de programadores. Tal vez es el momento preciso para replantear entre academia e industria lo que significa para una sociedad como la nuestra los programadores de software.

Anuncios
Sobre los técnicos en programación de software y los pegadores de ladrillos

Un comentario en “Sobre los técnicos en programación de software y los pegadores de ladrillos

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s