Después de muchos años dando clases y participando en proyectos reales, puedo afirmar que hay una confusión que aparece una y otra vez: pensar que programar y desarrollar software son lo mismo.
Es una confusión lógica. Cuando uno empieza, el foco está puesto en el código. Y, como es de esperar, al comenzar con un lenguaje lo primero que uno quiere es estar “codeando” y no “aburriéndose” documentando y haciendo gráficos. Y eso está bien, es parte del camino.
El problema aparece cuando ese enfoque no evoluciona.
Porque en la práctica profesional, escribir código es solo una parte de algo mucho más grande.
Desarrollar software implica entender un problema antes de pensar en una solución. Implica hacer preguntas, incluso de campos de acción o de negocios que desconocemos. Preguntas sobre objetivos, sobre personas, sobre contexto, sobre futuro. Muchas veces el error no está en cómo se programó algo o en la técnica utilizada, sino en que nunca se terminó de entender qué se necesitaba resolver.
En mis clases lo converso siempre: existen soluciones técnicamente correctas que no resuelven el problema planteado. En proyectos reales pasa lo mismo, solo que con consecuencias más caras. En definitiva, se puede realizar un programa perfecto desde la técnica, sin errores, pero que no es lo que el usuario necesita, por lo tanto … no sirve.
Cuando desarrollamos software, el código no vive solo. Vive en un sistema que va a cambiar y crecer. Y no siempre estos cambios están en nuestras manos, ni siquiera en las de quien usa el sistema. Vive en manos de otras personas que lo van a mantener, modificar o intentar entender dentro de seis meses o dos años. Vive en un contexto donde el tiempo, el presupuesto y las decisiones importan tanto como la tecnología elegida.
Es importante comprender que muchos de estos cambios pueden venir dados por legislaciones, contextos internacionales o decisiones tomadas por alguien que no está directamente relacionado con nuestro sistema, pero que igualmente nos impactan.
Por eso, desarrollar software también es tomar decisiones. Decidir qué hacer y qué no hacer. Decidir cuándo algo es suficientemente bueno. Decidir pensando en el largo plazo, aunque en el corto plazo nos apuren nuestro jefe o nuestro cliente.
Programar suele enfocarse en el “cómo”.
Desarrollar software obliga a hacerse cargo también del “para qué” y del “para quién”.
Y ahí aparece algo clave: muchas de las habilidades más importantes no se aprenden solo escribiendo código. Se aprenden analizando, discutiendo, equivocándose y revisando decisiones. Se aprenden con experiencia, pero también con método y estudios formales.
Este cambio de mirada suele marcar un antes y un después. Es el momento en el que el desarrollador deja de pensar solo en líneas de código y empieza a pensar en soluciones. En sistemas.
Y es, también, el punto en el que los proyectos y nosotros como profesionales, empezamos a mejorar de verdad.
