¿Qué es más importante para un ingeniero de software, programar bien en el lenguaje de programación o saber ortografía y redacción en su idioma? Piénsalo un momento antes de emitir una respuesta. Parece obvio responder “programar bien”, porque el contexto es desarrollo de software, y los que no saben hacerlo crean código muy problemático; te concedo eso, pues en mi experiencia he trabajado con personas que no sabían programar bien y nos entregaban archivos imposibles de usar y modificar, pero entonces estás olvidando que entre el 60% y el 65% del trabajo del software no se dedica a escribir el código.

La respuesta que doy a esta pregunta, y otras similares, es que ninguna es más importante que la otra. Ambas habilidades son fundamentales y descuidar alguna causa un desequilibrio en la fuerza (por citar Star Wars). Cuando conocí el marco de procesos “Personal Software Process (PSP)”, reparé en que uno de los criterios de entrada para aprenderlo es ser un programador competente; es decir, el proceso esperaba que ya supieras hacer software para usarlo; no te iba a enseñar a hacerlo o a resolver problemas técnicos.

La excelencia técnica debe ser una prioridad para los Ingenieros de Software, pero no la única. Es conveniente buscar un desarrollo balanceado, según el modelo de habilidades en T: conocimiento profundo de su disciplina y desarrollo en un conjunto amplio de habilidades fuera de su área principal.

Lograr esto requiere trabajo y disciplina. Aquí te comparto algunos de los aprendizajes que he obtenido al respecto a lo largo de mi carrera, que te ayudarán a conseguir equilibrio.

No aprendas a usar el framework haciendo el sistema

En muchas ocasiones, desarrollamos software usando herramientas nuevas. Al principio no las dominamos y tardamos un tiempo en sentirnos seguros con ellas. Una práctica frecuente es usar el proceso “code and fix”: escribimos un poquito de código para ver qué hace, repetimos y comenzamos a escribir y arreglar cosas con base en el comportamiento que vemos. Esto no sería un problema, de no ser porque lo hacemos en el código del sistema real y generamos una deuda técnica enorme.

¿Por qué es un problema hacerlo así? Porque eso entorpece una habilidad importante, la de aprender a aprender. Es verdad que aprendemos mucho cuando hay problemas, pero hay que procurar no ser la fuente de esos problemas.

Una recomendación que suelo hacer es esta: aprende a usar el framework haciendo el sistema, pero sin usar el sistema. En pocas palabras: haz una copia para ti o crea un sandbox separado, en el que puedas explorar sin riesgo.

No apliques religiosamente una metodología

En un equipo que lideré, un desarrollador me dijo: “sigo el proceso, primero hago el diseño, luego escribo todo el código, lo reviso, compilo, pero al ejecutarlo no sé lo que va a pasar”. Era una combinación de usar una herramienta de desarrollo nueva y un proceso diferente al acostumbrado, y yo estaba presionando por darle mucha importancia a seguir el proceso. De ahí aprendí que el proceso solo no resuelve los problemas, porque el resultado de ese proyecto fue malo.

Los métodos de trabajo, que contienen un proceso definido, fueron diseñados para funcionar en un contexto determinado. Cuando las circunstancias cambian, el método deja de funcionar. Si, a pesar de eso, insistes en seguirlo ciega y religiosamente como está, nunca te dará buenos resultados.

Mi recomendación es que conozcas y entiendas las circunstancias en las que funciona cada método; después, separarlo en prácticas y crear un toolkit con ellas, de donde puedes tomar elementos que te servirán para hacer un método adecuado al trabajo que haces en cada momento.

No elijas la tecnología antes de entender el problema a resolver

Un profesor solía decirnos: “cuando lo único que sabes usar es un martillo, a todo le ves cara de clavo”. Muchos ingenieros y organizaciones se especializan en uno o un par de lenguajes y herramientas de programación, y quieren hacer todos los sistemas en ellos. Toman una decisión importante sin haber comprendido el sistema que van a crear; es más, sin siquiera tener un proyecto.

Saber programar no significa solamente dominar lenguajes de programación. Saber programar significa entender cómo funcionan los sistemas en diferentes plataformas, arquitecturas y contextos, y cuál es la mejor manera de darle órdenes a una computadora para que resuelva problemas en ese contexto. 

Antes de llenar tu currículo con largas listas de herramientas (y por más que las vacantes insistan en que tengas 20 años de experiencia en lenguajes que existen hace apenas cinco), enfócate en los fundamentos de la programación, los paradigmas y las arquitecturas. Con eso en mente, es más fácil seleccionar las herramientas de desarrollo, antes que forzar a un sistema a encajar en algo que conocemos a priori.

Asume roles activamente dentro del equipo

El desarrollo de software abarca varias áreas: técnicas, como la implementación, el diseño y el testing, y las de gestión del trabajo, como planificar, tratar a los usuarios, asegurar la calidad, definir la forma de trabajo y liderar al equipo. Todas éstas deben ser ejecutadas y observadas para que obtengan buenos resultados. Son demasiadas para delegarlas a una sola persona, así que todo el equipo debe participar asumiendo estos roles. 

Mi recomendación es que te involucres voluntariamente en todos los roles, uno a la vez. Ningún responsable de rol debe ser experto en el área, pues su función principal es vigilar y observar que el trabajo se está haciendo; así que involucrarte como responsable de estas áreas te permitirá trabajar de cerca con los expertos y aprender de ellos.

¡Nos vemos en la siguiente entrega!