Quand as-tu réalisé qu'il n'y a jamais de sortie dans le domaine technique ?

Cet article #BCGame @bcgame est sponsorisé en exclusivité

Beaucoup de jeunes qui viennent de commencer, y compris moi à l'époque, croyaient à une idée fixe : tant que mes compétences techniques sont assez impressionnantes, je suis irremplaçable.

Alors nous nous lançons dans une course effrénée. Apprendre Java, Go, Rust, lire du code source, déchiffrer des algorithmes, développer des microservices, adopter le cloud native. Aujourd'hui, on s'acharne encore sur Spring Cloud, demain il faut apprendre Service Mesh, après-demain, avec la montée en puissance des grands modèles d'IA, il faut vite apprendre Prompt Engineering.

Nous pensons que c'est de la progression, alors qu'en réalité, c'est une roue qui tourne sans fin.

Tu crois que tu construis une barrière technologique, alors qu'en fait, tu aides ton boss à tester la faisabilité de nouvelles technologies.

Dans l'industrie de l'internet, la dépréciation des compétences techniques est plus rapide que la chute d'un appartement en VEFA. Tu as passé trois ans à perfectionner un framework, mais Google ou Facebook sort une nouvelle version ou change de paradigme architectural, et ton art de la maîtrise technique, ta fameuse "technique du dragon", devient soudainement obsolète.

Mais cela ne veut pas dire que l'apprentissage est inutile, c'est que ta direction d'effort est peut-être erronée. Plutôt que de poursuivre des frameworks qui seront dépassés en trois ans, il vaut mieux se concentrer sur des logiques fondamentales qui ne changent pas en dix ans. Par exemple, pendant que tu te débats encore entre Spring Cloud et K8s, les grands maîtres réfléchissent à la cohérence des données dans les systèmes distribués. Si tu veux sortir du cycle des frameworks, je te recommande de dévorer ce livre considéré comme la Bible du backend : 《Conception de systèmes d'applications intensives en données》 (version lecture accélérée DDIA). Il explique l'essence de la distribution, des bases de données et de la conception système. En comprenant cela, peu importe le framework à la mode demain, tu pourras en voir la structure en un coup d'œil.

Tu te souviens de cette équipe de frères qui faisaient du Flash ? Ou de ces experts qui développaient pour Symbian ?

Est-ce qu'ils ne travaillaient pas dur ? Ne étaient-ils pas intelligents ?

Quand l'époque vous abandonne, elle ne vous dit même pas au revoir.

Ce qui est le plus effrayant, c'est que notre fierté, cette capacité d'apprentissage rapide, est en réalité la ressource la plus appréciée par le capital.

Parce que tu apprends vite, tu es considéré comme bon marché.

Autrefois, un vieux médecin chinois devenait de plus en plus précieux avec l'âge, car son expérience était irremplaçable. Et maintenant ? Un programmeur de 35 ans doit demander un salaire élevé, ce qui s'appelle un faible rapport qualité-prix. Un jeune diplômé de 23 ans, on lui donne deux manuels, il copie, modifie sur Github, et en un mois, il peut être opérationnel.

À ce moment-là, tu diras : "J'ai de l'expérience, je peux éviter les pièges."

Mais ne plaisante pas. Dans la majorité des scénarios CRUD, tu n'as pas besoin de compétences si avancées. Peu importe si ton code est un peu bâclé, il suffit d'ajouter deux serveurs. Peu importe si tu as une fuite de mémoire, un redémarrage à 4h du matin suffit.

Pour un boss, tant que ça tourne, c'est suffisant.

Ton code élégant, tes design patterns, ta pensée architecturale, tout cela, aux yeux du boss, est moins important que celui qui peut boire avec lui, lui faire rêver en lui promettant monts et merveilles, ou faire briller ses PPT.

C'est ça, la loi du marché : la monnaie mauvaise chasse la bonne.

Quand tu te rends compte que ton code source de fondation, que tu as étudié pendant deux semaines, est moins valorisé qu’un PPT de ton collègue qui crie "empowerment, grip, boucle fermée, granularité" tous les jours, il est temps de te réveiller.

Le plus grand malheur pour un technicien, c'est que nous sommes toujours trop éloignés de l'argent.

Nous sommes la productivité, mais pas les maîtres des relations de production.

Tu as écrit un algorithme de recommandation génial, qui augmente la rétention des utilisateurs. À qui revient le mérite ? À l'équipe marketing, au produit, voire au commercial qui a négocié le partenariat.

Pourquoi ?

Parce que dans la logique commerciale, la technologie n'est qu'un outil.

C'est comme construire une maison : tu es celui qui transporte les briques et monte les murs. Peu importe si le mur est droit ou si tu transportes les briques rapidement, c'est le promoteur immobilier, la vendeuse, voire la spéculation immobilière qui vendra la maison et en tirera profit, pas toi, le simple ouvrier.

De plus, la technologie est souvent celle qui doit assumer la responsabilité en cas de problème.

Le système plante ? C'est toi qui prends la responsabilité. La mise en ligne est retardée ? C'est toi. Il y a beaucoup de bugs ? C'est encore toi.

Mais si le business ne décolle pas ?

Le chef de produit dira : "Je veux que ça marche aussi, mais la technologie ne supporte pas, cette fonctionnalité ne peut pas être réalisée, le planning est trop long."

Regarde, tout est parfait dans cette boucle fermée.