.webp)
¡Devolvamos el pensamiento crítico a la programación!
Ahora hay desarrolladores frontend, backend y fullstack, automatizadores de pruebas, desarrolladores de infraestructuras, ingenieros de datos, integradores y cientos de roles más
Esto no es malo; al contrario, tiene enormes beneficios desde la perspectiva de la resolución de problemas, las necesidades del mercado, la productividad, la gestión de proyectos y los recursos necesarios. Sin embargo, entre tantos roles, metodologías, frameworks y lenguajes de programación, nos estamos ahogando en un mundo lleno de prácticas que, aunque bonitas y prometedoras en teoría, están sacando de la ecuación nuestro pensamiento crítico, creatividad y capacidad de contribuir a las soluciones. Cada vez estamos más limitados a simplemente programar lo que las empresas quieren, como sea que se pueda hacer, siempre y cuando funcione, y además debe ser seguro, rentable, rápido y entregado a tiempo.
Probablemente esta idea de como sea que puedas hacerlo, siempre y cuando funcione, suene familiar para muchos, y tal vez suene muy parecido a tu día de trabajo promedio. Para muchos de nosotros, esto representa un conflicto constante, en el que las expectativas de los usuarios no siempre son compatibles con la realidad de lo que se puede completar en el tiempo asignado por los jefes de proyecto, convirtiendo todo en una batalla contra el tiempo. Además de ser poco agradable, esto deja poco (o ningún) tiempo para dedicar a otros aspectos clave del proceso de construcción de software, como la estabilidad, la alineación con los procesos funcionales, las estrategias de la empresa, el apoyo durante la operación diaria y el usuario final.
Recientemente, la falta de énfasis en estos aspectos ha traído consecuencias que muchos conocemos y hemos visto en nuestro propio trabajo, desde aplicaciones inestables o fallos recurrentes hasta errores graves por imprevistos que pueden llevarnos a soluciones improvisadas que ponen en riesgo mucho más que métricas o características del software.
Cuando consideramos los errores de software, vemos que hoy en día no muchos profesionales son conscientes de lo que puede pasar si algo falla, porque el foco está en codificar y completar, y a menudo no miramos más allá de esas métricas de finalización y calidad, más allá del código, más allá de los servicios, o incluso más allá, a las personas que usan el software, los usuarios finales. Debemos ser conscientes de que si algo falla en el software que construimos, alguien se verá afectado.
Esto puede adoptar la forma de situaciones que van desde no poder completar una tarea en el trabajo, no poder realizar un pago en línea o con tarjeta en un restaurante u hospital, hasta generar errores de cálculo para un débito, dejando sin dinero a alguien que luego lo necesita en caso de emergencia. Puede sonar dramático, pero esa es la realidad. Y no siempre somos conscientes del impacto que esto puede tener, ya sea porque no nos damos cuenta, porque nuestros usuarios no nos informan sobre los proyectos o porque ni siquiera pensamos en ello porque creemos que lo más importante es entregar a tiempo o que el código funcione y ya está.
El objetivo de plantear estas ideas es invitarnos a ser más sensibles como profesionales, a usar nuestras facultades críticas sin miedo ni pudor, a hacernos preguntas que vayan más allá de lo que nos piden que codifiquemos, a ver el impacto de lo que hacemos, a pensar que, para desarrollar un buen software, no basta con programar y cumplir los plazos del proyecto. Creo que también deberíamos pensar como posibles usuarios o clientes de lo que estamos construyendo, considerar siempre que algo puede salir mal y prepararnos para ello, pensando en el futuro para solucionarlo.
Debemos implicarnos plenamente en lo que estamos construyendo para entender el porqué y para quién lo hacemos. Entonces, al final, nuestro trabajo no consiste simplemente en escribir código que funcione bien según los requisitos (porque el usuario no siempre tiene razón) y crear documentación que lo respalde, no se trata de los cientos de métricas y pruebas de laboratorio que no reflejan la realidad, no se trata de saber mucho sobre tecnología, frameworks o lenguajes de programación. Se trata de ser sensible, de entender el contexto y las necesidades que vamos a satisfacer con nuestra tecnología, de abarcar el desarrollo de software en todas sus dimensiones, desde la teórica, la corporativa y la comercial, hasta la que puede ocurrirle a la gente corriente que utiliza esta tecnología o se ve beneficiada o afectada por ella.
Por eso creo que el desarrollo de software no debe limitarse a la tecnología y a escribir bien el código. ¿Qué opina usted?
Debemos implicarnos plenamente en lo que estamos construyendo para entender el porqué y para quién lo hacemos.
Entonces, al final, nuestro trabajo no consiste simplemente en escribir código que funcione bien según los requisitos (porque el usuario no siempre tiene razón) y crear documentación que lo respalde, no se trata de los cientos de métricas y pruebas de laboratorio que no reflejan la realidad, no se trata de saber mucho sobre tecnología, frameworks o lenguajes de programación. Se trata de ser sensible, de entender el contexto y las necesidades que vamos a satisfacer con nuestra tecnología, de abarcar el desarrollo de software en todas sus dimensiones, desde la teórica, la corporativa y la comercial, hasta la que puede ocurrirle a la gente corriente que utiliza esta tecnología o se ve beneficiada o afectada por ella.
Por eso creo que el desarrollo de software no debería limitarse a la tecnología y a escribir bien el código. ¿Qué opina usted?
