Aprender a programar no es lo mismo que aprender a desarrollar software.
Cuando uno empieza a programar, se enfoca en que el código funcione. Y está perfecto. Pero llega un punto donde el desafío pasa gradualmente a ser cómo estructurarlo para que escale, sea mantenible y no explote en producción.
Escribo esto no como crítica, sino más como una guía introductoria, o quizás un llamado de atención, para quienes estén avanzando en su carrera.
Es muy fácil caer en la trampa de pensar que porque tu app responde bien en local, ya está todo resuelto. Pero cuando entran más usuarios, más features, más personas al equipo, el código que parecía hermoso se vuelve un caos. Ahí es donde aparece la diferencia entre programar y desarrollar software profesionalmente: Hay que pensar en arquitectura, modularidad, control de versiones, testing, manejo de errores, documentación, y más.
Programar también es tomar decisiones
No se trata solo de “escribir código”, sino de tomar decisiones técnicas todo el tiempo:
- ¿Este dato lo guardo en una base de datos o en memoria?
- ¿Esta lógica va del lado del cliente o del servidor?
- ¿Conviene hacerlo con esta librería que conozco o aprender otra que lo resuelve mejor?
- ¿Conviene hacerlo con una librería?
- ¿Tiene sentido automatizar esto o lo hago manual por ahora?
Muchas veces, una mala decisión técnica puede llevar a una solución que funciona, sí, pero que no se puede mantener, que nadie entiende o que no escala. Por eso, pensar antes de(o, al menos, durante) codear es clave.
Cuidado también con los requerimientos del cliente. A muchos clientes aficionados de la tecnología, o que quizás han programado en el pasado, les gusta darnos diseños de infraestructura o lógica. Pero es necesario analizar con cuidado con estos requerimientos y repensarlos con el conocimiento que tenemos de nuestro código y estructura, para asegurarnos que tiene sentido y no estaremos causando un problema futuro. Debemos buscar la mejor forma de ejecutarlo, cumpliendo con sus expectativas, no con sus ideas de implementación (que posiblemente ni verán). En mi experiencia, es el 100% de las veces, pero puede variar.
Ejemplo práctico: ¿Harías una calculadora con IA?
Estás haciendo una app de facturación y tenés que calcular el total de una compra sumando los precios.
Hoy es común (o hasta demandado por nuestros pares) pensar: ¿Y si uso un modelo de IA para interpretar los precios, sumar y dar el resultado?
¿Funcionaría? Seguramente.
¿Tiene sentido? Ninguno. Lo que se necesita ahí es una suma, no inteligencia artificial. El problema no es técnico, es de criterio.
Este tipo de errores vienen de no parar a pensar cuál es la solución más simple, clara y apropiada para el problema real. Programar no es demostrar cuántas herramientas conocés, sino elegir bien cuál usar (y cuál no).
Otra trampa clásica: ¿Instalo una librería que sume por mi? ¡No! Es solo una suma. Sin embargo, is-odd tiene 365k descargas semanales…
Cabe mencionar que también hay casos opuestos: Parecen fáciles de hacer a mano, pero en realidad sí se recomienda usar una librería (estos son solo algunos que se me ocurren):
- Fechas (es más complejo que lo que parece)
- Internacionalización (traducciones), a menos que sean solo unas pocas palabras que puedas poner en un array.
- Expresiones matemáticas o lógicas (cuántas veces comencé a escribir mi propio compilador, o pensé en usar eval, ¡pero no!)
- Procesar o generar solicitudes HTTP (como subidas de archivos), FTP, SMTP, etc..
En una futura entrada hablaremos sobre opciones para estos casos.
Escribir menos también es escribir mejor
Una buena parte del crecimiento como desarrollador es entender que no todo se soluciona escribiendo más código. Soy un culpable de caer en esta trampa, escribiendo mi propio framework (y más de una vez) porque ninguno me gustaba. Hasta que otros lo hicieron por mi, y mejor de lo que podía hacerlo con mis recursos. A veces la solución más elegante es borrar, reutilizar, dividir en partes o usar una herramienta existente. No es falta de habilidad, es madurez técnica. No hace falta reinventar la rueda, sino saber cuándo vale la pena hacerlo.
A medida que creces, no solo se espera que sepas programar, sino que entiendas el sistema como un todo. Qué pasa cuando algo falla, cómo se integran los componentes, cómo trabajar en equipo y cómo tomar decisiones técnicas. No se trata de saber 10 lenguajes, sino de tener criterio para elegir bien y construir cosas sólidas.