Para fines prácticos soy autodidacta en sistemas. Empecé a programar hace 34 años, en 1991, a los 19 años, leyendo manuales y especificaciones de lenguaje. Sí he tomado algunos cursos: Visual Basic Fundamentals y Visual Basic en New Horizons, allá por 1997. Estudié LSCA en 1995 en una universidad ya desaparecida; no vimos mucho de programación, salvo algo de lenguaje C.
He tomado cursos de bases de datos y he leído y programado mucho. Se dice que dominas un tema a las 10,000 horas. Eso equivale a unos cinco años de semanas de 8 horas diarias. Yo calculo que en mis primeros años trabajé, en promedio, de 80 a 90 horas semanales, llevando el manejo de personal al mismo tiempo y programando en mi casa los fines de semana. Así que puedo decir que en 1993, a los 21 años, probablemente ya tenía las 10,000 horas.
Mientras yo acumulaba horas reales de programación, las universidades seguían atrapadas en ejercicios desconectados de la práctica. Los planes de estudio suelen ser enseñados por personas que jamás pudieron ejercer. Por ejemplo, mi hijo estaba pensando en estudiar sistemas; el plan de UNITEC tenía solo TRES materias de programación: una era Base de Datos y la otra Programación Orientada a Objetos. Además de ser caro e inútil, le recomendé irse por la escuela pública a una Licenciatura (no Ingeniería, porque está negado para las matemáticas) y estudiar por fuera los temas importantes.
Mi trabajo me ha hecho interactuar con dos de las tres universidades públicas más grandes de México. He manejado servidores en la nube para dos de ellas; no creando para terceros, sino siendo el administrador de mis propios servidores y atendiendo a los usuarios. Esa experiencia me confirma que la brecha entre la práctica real y la enseñanza académica sigue siendo enorme. De plano, a veces no tengo idea de por qué los clientes con problemas usan lo que usan. Los programadores se van delos trabajos por lo no manejable, sea tecnología o factor humano. Muchas veces es el stack de tecnologías, y ahí es donde suena el teléfono y me llaman, o recibo un correo electrónico.
Tengo mi propia empresa (medida que tomé por ataques de una secta destructiva para proteger mi patrimonio), pero he pasado por unos quince trabajos de desarrollo. Los últimos quince años han sido con unos tres clientes fijos (incluyendo una de las universidades) y otro que recibía gente de servicio social para tratar de sustentar con «becarios» el costo de no contratar personal. Yo, sinceramente, los usaba para que hicieran videos y cosas así, lo mismo que con sus prácticas profesionales. Les enseñaba a levantar servidores y cómo manejar ciertos problemas con el recurso humano.
La Informática es el manejo de información; la Ingeniería está más enfocada en hardware; y la Licenciatura, en los procesos de negocios. Pero eso sí: casi todos los planes de estudio, a pesar de las calificaciones de 9.x, les dan la teoría pero no la práctica. También les enseñaba a los que querían cómo pasar exámenes en entrevistas de trabajo, así como los exámenes psicológicos. El mejor programador que vi de esos treinta muchachos tronó el psicológico inicial que le apliqué. Ni siquiera lo hubiera pasado a entrevista en el mundo real. Su trabajo fue regular: no entregó el esquema de base de datos, fue grosero con su compañera de clases y no supo decirme qué servicio de Java usaba, pero eso sí, estaba en Azure. ¿Autodidacta? Probablemente.
En mi experiencia, la universidad no prepara ni en lo técnico ni en lo humano. Me encuentro entonces con dos problemas principales:
-
Desarrolladores que aprenden algo impulsado por la moda y no saben que hay versiones o que el software cambia.
-
Personas que usan lo que usan solo porque es lo que hay donde están.
La universidad no enseña a evaluar el costo de mantenimiento. Los desarrolladores jóvenes eligen React porque es tendencia, pero si el core de la aplicación maneja datos complejos, muchas veces el costo de Azure o la memoria requerida salen más allá de los límites de estabilidad de una empresa mediana. Ahí entran desde aseguradoras con su propia empresa de software (el lugar más infame en ambiente y contradicciones que me tocó ver en 33 años de trabajo). También he visto casos donde prefieren pagar horas extra a alguien de planta que se la pasa usando Duolingo en yidish, esperanto y alemán en horas de trabajo, que pagar en tiempo y forma a la persona que saca el trabajo (que en este caso era yo, por honorarios).
Pero el costo de mantenimiento es también el costo de la continuidad de negocio. La deuda técnica. Si $2+2=4$ y $1+1+1+1=4$, pero el segundo método es más lento y propenso a errores, eso es lo que hace la mayor parte de las empresas. El enfoque universitario te impone ese $1+1+1+1$, pero el sentido común te dice otra cosa. No es normal que una cajera que gana casi el salario mínimo gaste el 20% de su sueldo en Uber por los días que estuvo a punto de llegar tarde. El tema es la relación con la continuidad de negocio, el «negocio en marcha» como decimos en contabilidad, y ese costo de mantenimiento.
En los últimos tres años nos hemos metido en una situación inmanejable. Ahora vamos por un $((1+1)+2)/2 \times 2$ para programar. Nuestras opciones de ecosistema de stack están mal. No solo por lo que enseñan. Así como las licencias de SQL Server son carísimas (sobre todo para México), tenemos capas en React y Java Spring Hibernate que son inmanejables y consumen mucha memoria costosa. El equivalente a los costos de SQL es querer Azure y AWS cuando tu lista de clientes no llega a 50 grandes y menos de 200 chicos.
Uno de los problemas que encontré entre 2014 y 2015 fue mi primer desastre ajeno a resolver de React. El cliente tenía una corrupción de Maven (el gestor de dependencias de Java, equivalente al Composer de PHP). Tenía un caché corrupto en la PC de alguien despedido. Normalmente habría descargado de nuevo Maven y santo remedio, pero no podía hacerlo por restricciones de permisos. En ese entonces React tendría unos tres o cuatro años y ya presentaba casi todos los problemas actuales. Mis opciones eran: a) llorar, b) formatear o c) hacer otra cosa.
Hice otra cosa. Aunque las incompatibilidades de Java son una razón para no usarlo en mis proyectos propios, eso no significa que no lo sepa. Terminé usando Gradle (que en 2025 sigue vigente) para limpiar el desastre. Explico, de años antrás en Java yo conocía Gradle y sabía que era similar a Maven. En lenguaje simple, el problema parecía ser Maven, y lo que acabé haciendo fue usar otro ‘configurador’ llamado Gradle (para simplificar, diré que es una alternativa a Maven pero más robusta).
¿Cómo identificas qué usa el usuario? Yo uso una bitácora MySQL que, con dos líneas de código en PHP o unas siete en Java, guarda en la base de datos si entraron a /app, /users, /ventas, etc. Tras cuatro días analizando el código infumable de React, mi base de datos me mostró 40 «puntos de entrada». Eso me dio una idea del problema.
Puse Gradle y empecé a migrar. Estaban implementando Spring Boot. Al universitario de hoy, doce años después, le enseñan Maven si bien le va; o si es autodidacta, aprende a buscar librerías (que pueden causar problemas de compliance). La mayoría no busca alternativas. Yo conozco varios modos de hacer las cosas. En un cliente de gobierno tuve que probar siete métodos antes de que uno funcionara por los puertos cerrados y la red inestable. Considerar alternativas no te lo dan en la universidad.
El problema en aquel proyecto era que la dependencia A llamaba a la librería XYZ v1.3 y la dependencia B usaba la v2.0. No podían coexistir. Usé un proceso llamado shadow para decidir qué dependencia usar. Pero el proceso que tampoco te enseñan en la escuela es SIMPLIFICAR, como diría Thoreau en Walden.
Simplificar es lo que salva los proyectos. Meter una dependencia innecesaria es, como diría Bulwer-Lytton en Zanoni: «El que echa agua en un lodazal no hace más que ensuciar el agua». Si tienes un buen elemento, págale. Si necesitas un proveedor, págale. Si quieres seguridad, saca tres respaldos diarios. Es simple.
Finalmente, en aquella ocasión, convertí el proyecto a Gradle en semana y media, quité React y usé Bootstrap con Thymeleaf (que venía por defecto en Spring Boot). Fue hace diez años y ya era un problema. React mete complejidad innecesaria con sus useEffects y la dependencia de componentes de terceros. Si eres responsable, no puedes hacer eso; por compliance, la responsabilidad es tuya si algo falla, especialmente en sectores de salud o financiero.
Un programador arriba del promedio sabe qué es Thymeleaf, aunque sea tecnología de hace diez años. ¿Por qué el 90% de las ofertas de empleo son sobre React y Spring Boot? El problema es que para muchos la curva de aprendizaje se quedó en lo primero que aprendieron. Si quiero un proyecto propio en Java, uso Quarkus. Si quiero que sea mantenible para otros, uso JDBC o Hibernate con Thymeleaf. Y les digo: NO usen Express del stack MEAN como si fuera la espada láser de los Jedi.
Desde 2014 enfrento servidores sobredimensionados en REACT y personas que no saben hacer un «Hola Mundo» sin llamar a quince dependencias. Se trata de buscar alternativas y simplificar. Como parte de lo que haré para mi cliente, levantaré desde cero un servidor Debian 13 con Spring Boot, Gitea y Thymeleaf (además de React para su migración). Su costo anual entre empleados y AWS es de 90,000 USD; ya no pueden pagarlo. Esta solución simplificada cuesta 35,000 USD anuales, solo por salirse de AWS y dejar React a mediano plazo.
Todo porque no buscan alternativas. Como ejemplo, dejaré una adaptación de un programa de terceros de un «carrito de ventas» en Spring Boot / Thymeleaf. El siguiente tutorial tratará sobre Debian y cómo:
-
Instalar LAMP con PHP 8.4.
-
Instalar MariaDB.
-
Instalar Node.js y React.
-
Instalar Gitea y cerrar puertos.
-
Dejar andando Spring Boot bajo Thymeleaf y modo React.
La universidad y autdidactas estándard enseñan a acumular dependencias, pero la práctica exige simplificar para sobrevivir.
Lo más raro es que no solo cobraré por ello, sino que un programa que haga de cero lo que ellos hacen, lo terminaría yo en menos de un mes con Thymeleaf, o en 15 días con PHP puro.