¿Cuándo te diste cuenta de que hacer tecnología no tiene futuro?

Este artículo #BCGame @bcgame patrocinador exclusivo

Muchos jóvenes que acaban de entrar en el sector, incluyendo a mí en su día, creen en una lógica fatal: mientras tenga habilidades técnicas lo suficientemente buenas, soy insustituible.

Así que nos esforzamos al máximo. Aprendemos Java, Go, Rust, leemos código fuente, estudiamos algoritmos, hacemos microservicios, trabajamos con tecnologías nativas en la nube. Hoy todavía estamos trasteando con Spring Cloud, mañana tendremos que aprender Service Mesh, pasado mañana, con el auge de los grandes modelos de IA, hay que aprender Prompt Engineering rápidamente.

Pensamos que esto es ser ambicioso, en realidad es una rueda de hamster cibernética.

Crees que estás construyendo barreras tecnológicas, en realidad estás ayudando a tu jefe a verificar la viabilidad de nuevas tecnologías.

En la industria de Internet, la depreciación de la tecnología es más rápida que la caída de una vivienda en preventa. Has dedicado tres años a perfeccionar un marco, y quizás Google o Facebook lancen una nueva versión o cambien su filosofía arquitectónica, y esa técnica que tanto enorgullecía tuya, tu “arte de matar dragones”, se vuelve papel mojado en un instante.

Pero esto no significa que aprender sea inútil, sino que quizás el rumbo de tu esfuerzo esté equivocado. En lugar de perseguir marcos que en tres años ya están obsoletos, sería mejor centrarse en las lógicas fundamentales que no cambian en una década. Por ejemplo, cuando todavía estás peleando por decidir si usar Spring Cloud o K8s, los verdaderos expertos piensan en la consistencia de datos en sistemas distribuidos. Si quieres salir del ciclo de los marcos, te recomiendo que leas esa biblia del backend, 《Diseño de sistemas de aplicaciones centradas en datos》 (versión con lectura guiada de DDIA). Trata sobre la esencia de los sistemas distribuidos, bases de datos y diseño de sistemas. Entender esto te permitirá, pase lo que pase con los marcos de moda, ver a través de ellos en un solo vistazo.

¿Recuerdas a los hermanos que hacían Flash en su día? ¿A los expertos que programaban en Symbian?

¿No se esforzaban? ¿No eran inteligentes?

Cuando la era te abandona, ni siquiera te dicen adiós.

Lo más aterrador es que nuestra orgullosa capacidad de aprender rápido, en realidad, es la propiedad que más le gusta a los capitales como recurso consumible.

Porque aprendes rápido, eres barato.

Antes, un viejo médico tradicional era cada vez más valioso, porque su experiencia no se podía copiar. ¿Y ahora? Un programador de 35 años, que pide un salario alto, eso se llama bajo costo-beneficio. Un recién graduado de 23 años, le das dos manuales, lo dejas copiar y modificar en Github, y en un mes ya está en marcha.

En ese momento dirás: tengo experiencia, puedo evitar errores.

No seas ridículo. En la mayoría de los escenarios de negocio CRUD, no necesitas tanta profundidad técnica. ¿Qué pasa si el código es un poco peor? ¿No basta con agregar dos servidores? ¿Y si hay fugas de memoria? ¿No basta con reiniciar a las 12 de la noche?

Para el jefe, lo importante es que funcione.

Tu código elegante, tus patrones de diseño, tu pensamiento arquitectónico, en los ojos del jefe, no valen tanto como ese adulador que puede beber con él, prometerle grandes planes, y hacer presentaciones que brillan.

Eso es la ley de la moneda falsa que expulsa a la buena.

Cuando descubres que el ingeniero de PPT que grita “empoderamiento”, “punto de apoyo”, “bucle cerrado”, “granularidad” todos los días, avanza más rápido en su carrera que tú, que has estado investigando el código fuente de bajo nivel durante medio mes, debes despertar.

El mayor sufrimiento de los técnicos es que siempre estamos demasiado lejos del dinero.

Somos la fuerza productiva, pero no los principales en las relaciones de producción.

Has creado un algoritmo de recomendación increíble, que aumenta la retención de usuarios. ¿De quién es el mérito? Es del equipo de operaciones, del producto, incluso del comercial que negoció la colaboración.

¿Y por qué?

Porque en la lógica comercial, la tecnología es solo una herramienta.

Como construir una casa, tú eres el que mueve los ladrillos y construye las paredes. Por muy rectas que sean, por mucho que muevas los ladrillos más rápido, al final, quien gana dinero vendiendo la casa es el promotor, la agente inmobiliaria, incluso los especuladores, pero tú, que solo mueves ladrillos, no.

Además, la tecnología suele ser la que carga con la culpa.

Si el sistema se cae, tú cargas con la culpa. Si lanzan algo tarde, tú cargas con la culpa. Si hay muchos bugs, tú cargas con la culpa.

Pero, ¿y si el negocio no funciona?

El gerente de producto dirá: “Yo también quiero que funcione, pero la tecnología no soporta esto, no podemos implementar esta función, el cronograma es muy largo”.

Mira, qué ciclo tan perfecto.