Reflexiones sobre la vocación de los desarrolladores, y sobre la importancia de mantener la pasión por crear software a lo largo de nuestra carrera.
Empecé a programar a los 13 años. Empezó siendo un juego, y lo fue por mucho tiempo, hasta que empezaron a pagarme por hacerlo.
Entonces tuve que empezar a programar lo que me pedían, en lugar de programar lo que yo quería. Así y todo, seguía disfrutando de la tarea de programar; era algo que hacía con naturalidad y que me “salía solo”, como quien tiene algo de habilidad para tocar un instrumento musical. De todos modos tuve que estudiar para perfeccionarme y justificar lo que me pagaban por programar.
Con el tiempo y la experiencia, me volví “senior”. Eso significaba que recibía encargos más difíciles de hacer, y que podía resolverlos. Después comencé a repartir mi tiempo entre programar y especificar tareas para otros programadores.
Hasta que un día dejé de programar. Y me volví analista.
Hoy digo (mitad en broma mitad en serio) que “me jubilé como programador”.
¿Por qué? Dos motivos:
1. El conocimiento funcional que adquirí sobre determinados dominios hizo que mi tiempo fuera más valioso haciendo análisis que programando.
2. La actualización tecnológica me pasó de largo. Lo digo dejando caer una lágrima, pero hoy el esfuerzo que me demandaría ponerme al día con todas las herramientas y tecnologías de programación sería excesivo, y me distraería de las actividades de análisis que (por lo dicho en el punto anterior) me veo obligado a hacer. Sí debo mantenerme al día en el conocimiento de las nuevas herramientas y tecnologías, para saber qué potencial tienen; esa es una obligación ineludible de todo analista.
Nostalgias informáticas
A veces, las circunstancias me obligan a programar un poco. Y es entonces cuando me agarra un poco de nostalgia, que debe ser semejante a la que les da a los directores técnicos/ex futbolistas a quienes les cae una pelota a los pies y se ponen a hacer jueguitos.
Entonces me pregunto qué fue lo que me atrajo de la programación desde un principio. Y pienso que debe ser la posibilidad de construir cosas que funcionan (maquinarias, podría decirse) y hacerlo de una manera virtual, sin necesidad de ensuciarse las manos ni dominar herramientas y aparatos “físicos” que siempre me parecieron ruidosos, inmanejables y hasta peligrosos. Hay un placer innegable en escribir un programa y verlo funcionar en forma efectiva, sin errores. No importa que sea un juego o un sistema de facturación; es lindo ver una creación propia que funciona, y bien.
Pero uno se vuelve grande, y pierde la habilidad para salir a la cancha y correr atrás de la pelota. Hay que quedarse junto al banco y dar instrucciones. Entonces, la satisfacción no viene de construir algo y verlo funcionar, sino de dar instrucciones para que otros lo construyan, y ver que lo construyen bien, y que funciona, y darle una palmada en el hombro al que lo hace, y decirle: “lo estás haciendo bien siguiendo mis instrucciones”.
Convengamos que no todo analista es un programador jubilado (así como no todo DT es un ex jugador). Hay quienes salen de la facultad y comienzan a trabajar de analistas, sin haber estado dentro de la cancha corriendo atrás de la pelota. ¿Son mejores o peores analistas que los ex programadores?
Quién sabe. Quizás no tienen vicios de programador, entonces no tratan de que el programador haga las cosas como ellos lo harían, sino que le dejan libertad para que lo haga de la forma que le parezca mejor. Pero también puede ser que les cueste más trabajo encontrar un idioma común para transmitirle fielmente sus ideas al programador.
Todos somos traductores. El analista traduce lo que pide el cliente en modelos conceptuales; el diseñador y el programador traducen los modelos conceptuales en modelos de clases y finalmente en código de programación. A veces esas tres personas son en realidad una, a veces son dos, o tres.
Sería bueno saber en qué condiciones se obtienen las traducciones más fieles, si cuando los roles están en personas separadas, si cuando están en una o en dos, si cuando el analista es ex programador, o cuando el analista es sólo eso: analista y punto.
En cualquier caso, creo que lo importante es rescatar eso que nos atrajo a la actividad del desarrollo de software desde un principio, independientemente de que estemos en el sillón del analista, dibujando diagramas y narrando casos de uso, o en el del programador, tirando líneas de código: disfrutar de la satisfacción de ver funcionando a nuestras creaciones de software.
