Arrêtez de lire pour constituer une bibliothèque. Commencez à lire pour résoudre un problème.
La plupart des listes de lecture en ingénierie se concentrent sur l'accumulation de connaissances. L'ingénierie moderne récompense la résolution de goulots d'étranglement.
Un ingénieur junior m'a récemment montré une liste des « 10 meilleurs livres pour les ingénieurs ». Elle ressemblait aux listes d'il y a dix ans. Elle reposait sur la même vieille hypothèse.
L'hypothèse est que lire suffisamment de livres fait de vous un meilleur ingénieur. Les équipes performantes n'apprennent pas de cette manière.
Les meilleurs ingénieurs construisent des plans d'apprentissage autour des contraintes.
Les listes de lecture classiques partent du principe que toute connaissance a de la valeur. En réalité, la valeur en ingénierie dépend du contexte.
• Un ingénieur backend confronté à des problèmes de base de données n'a pas besoin d'un livre sur l'Agile. • Une équipe qui dépense trop en inférence d'IA n'a pas besoin d'un livre générique sur l'artisanat logiciel. • Une startup confrontée à des problèmes de latence n'a pas besoin d'un cadre de leadership.
Ces personnes ont besoin de solutions au goulot d'étranglement spécifique auquel elles sont confrontées. Les listes de lecture optimisent l'exhaustivité. L'ingénierie récompense la pertinence.
Les fondamentaux comme les bases de données et les réseaux comptent toujours. Mais ils ne suffisent plus.
Les systèmes modernes apportent de nouvelles contraintes. Les coûts d'inférence de l'IA en sont un exemple majeur. Les listes traditionnelles couvrent rarement ces problèmes.
Le défi n'est plus seulement d'écrire un logiciel correct. Le défi est de construire des systèmes fiables sur des composants probabilistes.
Par le passé, les ingénieurs travaillaient avec des systèmes déterministes. La même entrée produisait la même sortie.
Aujourd'hui, les systèmes se comportent différemment. Un prompt donne des réponses différentes. Un agent emprunte des chemins différents. Une mise à jour de modèle modifie le comportement sans que vous n'ayez à changer votre code.
Les nouvelles questions sont : • Comment évaluez-vous la qualité ? • Comment gérez-vous ces changements ?
Ce ne sont pas des cas particuliers. Ce sont des tâches d'ingénierie quotidiennes.
Les ingénieurs chevronnés ne lisent pas de la première à la dernière page. Ils lisent pour comprendre les mécanismes. Ils trouvent un goulot d'étranglement, identifient le mécanisme et n'apprennent que ce dont ils ont besoin.
• Si la latence est élevée, étudiez le batching. • Si le contexte est un problème, étudiez la récupération (retrieval). • Si les agents échouent, étudiez l'évaluation.
Cela relie l'apprentissage directement à la production. La connaissance devient un levier.
Utilisez cette boucle d'apprentissage :
- Identifiez le goulot d'étranglement.
- Trouvez la ressource spécifique pour ce problème.
- Appliquez la solution.
Arrêtez d'essayer de terminer une liste de lecture. Commencez à essayer d'améliorer le système.
Avant votre prochain livre, demandez-vous : quelle est la plus grande contrainte de mon système ?
S'agit-il de la latence, du coût, de la fiabilité ou de l'observabilité ?
Trouvez la ressource qui s'attaque à ce goulot d'étranglement. L'ingénierie n'est pas un concours de lecture. C'est un métier de résolution de contraintes.
Le système dicte ce que vous apprendrez ensuite.