Tous les quelques années, les outils changent complètement, et tous les quelques années, le même petit ensemble d'idées finit par expliquer ce qui a mal tourné.
Le problème de la demi-vie
La connaissance technique ne se périme pas à un rythme uniforme, et cette différence est la chose la plus utile qu'une organisation puisse comprendre pour former ses ingénieurs.
La connaissance des frameworks et des bibliothèques se périme vite. Une technique liée à une version, apprise aujourd'hui, est fréquemment obsolète en quelques années, parfois plus tôt. La connaissance des plateformes et des éditeurs se périme presque aussi vite, et les commandes et interfaces précises changent en permanence.
En dessous se trouve une couche qui a à peine bougé. Comment un ordinateur exécute des instructions. Ce que coûte une structure de données. Pourquoi certains algorithmes passent à l'échelle et d'autres non. Ce que fait un système d'exploitation avec la mémoire et avec l'attente. Comment les réseaux acheminent réellement un message.
Former les gens uniquement sur la couche qui se périme vite revient à les reformer tous les trois ans, indéfiniment.
Ce n'est pas un argument contre la formation pratique. C'est un argument de proportion. La plupart des budgets de développement technique en entreprise sont dépensés massivement sur la couche à la durée de vie la plus courte, et presque rien sur la couche qui rend le prochain outil apprenable en une semaine plutôt qu'en un trimestre.
Ce que couvre la direction
Le périmètre : algorithmes, structures de données, systèmes d'exploitation, réseaux et calculabilité.
Quatre domaines.
Algorithmes et structures de données. Ce que coûtent les opérations, quelle structure convient à quel schéma d'accès, et comment raisonner sur l'échelle.
Systèmes. Processus, mémoire, ordonnancement, fichiers, et les abstractions qui masquent le matériel.
Réseaux. Comment les données circulent, ce qui peut mal tourner, et pourquoi les systèmes distribués sont difficiles d'une façon bien précise.
Théorie de la calculabilité. Ce qui est calculable, ce qui est traitable, et où se trouvent les limites dures.
La complexité, l'idée unique qui se rentabilise d'elle-même
Si une organisation ne devait enseigner qu'un seul concept de cette direction, ce serait celui-ci.
La complexité algorithmique décrit comment le travail effectué par un algorithme croît avec la taille de l'entrée. La distinction n'est pas académique. C'est la différence entre un code qui fonctionne en test et un code qui échoue en production.
Trois conséquences pratiques.
Les données de test masquent le problème. Un algorithme dont le travail croît avec le carré de l'entrée paraît correct sur mille enregistrements et devient inutilisable sur un million. L'échec n'est pas un bug qui apparaît plus tard. Il était présent dès la première ligne et invisible à l'échelle du test.
La boucle imbriquée sur une base de données est l'erreur coûteuse la plus fréquente du logiciel commercial. Une requête à l'intérieur d'une boucle, où chaque itération fait son propre aller-retour, se comporte correctement avec quelques éléments et s'effondre sous un volume réel. Ce schéma revient sans cesse, dans tous les langages, écrit par des gens avec des années d'expérience, parce que personne ne leur a montré comment le repérer.
Choisir la bonne structure est généralement un gain plus important qu'optimiser le code. Chercher un élément dans une liste signifie examiner chaque élément. Le chercher dans une table de hachage est quasi immédiat, quelle que soit la taille. Changer une ligne l'emporte sur réécrire cent lignes.
Rien de tout cela n'exige de sophistication mathématique. Cela exige l'habitude de se demander ce qui se passe si cela devient dix fois plus gros, et cette habitude s'enseigne rapidement à des gens qui écrivent déjà du logiciel.
Ce que fait réellement le système d'exploitation
La couche que la plupart des développeurs en poste traitent comme invisible, et d'où provient une part étonnamment large des problèmes de production.
La mémoire. Comment fonctionne l'allocation, ce que coûte le garbage collection et quand il fait une pause, pourquoi la localité mémoire affecte la vitesse bien plus que le nombre d'instructions, et ce qui se passe réellement quand un processus épuise la mémoire disponible. Les problèmes mémoire comptent parmi les incidents de production les plus difficiles à diagnostiquer sans cette image mentale.
Processus et threads. Ce que signifie l'isolation, ce que coûte un changement de contexte, et pourquoi ajouter des threads au-delà d'un certain seuil ralentit un système au lieu de l'accélérer.
Entrées et sorties. La raison pour laquelle la plupart des applications attendent plutôt qu'elles ne calculent. Les opérations disque et réseau sont des ordres de grandeur plus lentes que l'accès mémoire, ce qui explique l'existence des approches asynchrones et non bloquantes. Les ingénieurs qui n'ont pas intégré cela optimisent le calcul dans des programmes qui passent leur vie à attendre.
Concurrence. Conditions de course, interblocages, et le fait que des opérations qui paraissent atomiques dans le code source ne le sont pas. C'est la catégorie de bug qui passe tous les tests et échoue en production sous charge, et qui ne peut se raisonner sans ce modèle.
Où cela se situe dans le domaine
L'informatique fondamentale est la première des huit directions du domaine IA, données et informatique d'Astra Trainer, et elle sous-tend toutes les autres. L'ingénierie logicielle, la science des données, le cloud et le DevOps, la cybersécurité et l'apprentissage automatique reposent tous sur les mêmes idées computationnelles, et les personnes qui les maîtrisent apprennent chaque nouvelle couche plus vite.
Elle se connecte le plus directement à l'ingénierie logicielle, qui applique cette matière sous contrainte commerciale, et aux systèmes informatiques et réseaux, où le système d'exploitation et la couche réseau constituent le travail quotidien. Vous pouvez découvrir les huit directions ici.
Pourquoi cela compte davantage aujourd'hui, pas moins
L'hypothèse courante veut que les outils de génération de code rendent les fondamentaux obsolètes. L'argument inverse est plus solide, et il repose sur ce que devient le métier.
Le travail passe de l'écriture au jugement. Relire un code que vous n'avez pas écrit, et décider s'il est correct, exige davantage de compréhension que de le produire, pas moins. Une fonction d'apparence plausible avec les mauvaises caractéristiques de complexité est exactement le genre de chose qui passe une relecture superficielle et échoue à l'échelle.
Le code généré est confiant sur la performance d'une façon qu'il ne peut justifier. Il ne connaît pas vos volumes de données, vos schémas d'accès ni votre budget de latence. Quelqu'un doit le faire.
Le débogage reste la partie difficile. Quand un système se comporte de façon inattendue en production, la question est de savoir ce qui se passe réellement, et cela se répond à partir d'un modèle de fonctionnement de la machine.
Les décisions d'architecture ne s'autocomplètent pas. Choisir entre cohérence et disponibilité, décider quoi mettre en cache, juger où placer une frontière : ce sont les décisions qui déterminent si un système survit, et ce sont toutes des questions de fondamentaux.
La formulation honnête est que ces outils relèvent le plancher de la production de code et élèvent la valeur de la capacité à l'évaluer. Les organisations qui ne retiennent que la première moitié découvriront laquelle des deux elles avaient.
Les postes, nommés
Ingénieurs logiciels, à tous les niveaux, puisque c'est le substrat.
Ingénieurs systèmes et programmeurs systèmes.
Ingénieurs performance, une spécialité distincte et durablement rare.
Ingénieurs en systèmes distribués.
Ingénieurs compilateurs et runtimes.
Ingénieurs bases de données, où structures de données et stockage se rencontrent.
Chercheurs en sécurité, dont le travail dépend de la compréhension de ce que fait réellement la machine plutôt que de ce que dit le code source.
Architectes techniques, qui prennent les décisions que cette matière éclaire.
Ingénieurs de recherche en systèmes d'apprentissage automatique, où l'efficacité à l'échelle est le problème dans son entier.
Qui peut être formé pour cela
Développeurs autodidactes et diplômés de bootcamp. Le groupe le plus large et le plus gratifiant. Ils ont fréquemment une solide compétence pratique, de bonnes habitudes d'outillage et une réelle expérience de livraison, avec une lacune précise ici. La combler est un travail bien défini plutôt qu'un programme de montée en compétences général, et l'effet sur leur plafond de progression est important.
Analystes et data scientists. Vers la performance et l'échelle, là où les requêtes et pipelines qui fonctionnent sur des échantillons échouent sur des données complètes, exactement pour ces raisons.
Administrateurs informatiques et systèmes. Détenant déjà la connaissance des systèmes d'exploitation et des réseaux côté opérationnel, avec besoin de la couche programmation.
Ingénieurs d'autres disciplines. Les diplômés en mathématiques, en physique et en ingénierie se convertissent bien, car le style de raisonnement se transfère.
Ingénieurs qualité et test. Vers des postes d'ingénierie, avec un fort sens de la façon dont les choses échouent.
Ingénieurs support. Vers le développement, avec une vraie connaissance de ce qui casse en production et pourquoi.
Sur les fondamentaux et le recrutement. Les entretiens algorithmiques sont largement utilisés et largement critiqués comme filtre de recrutement, et la performance à ces entretiens corrèle imparfaitement avec la performance au poste. Cette direction existe pour rendre les gens meilleurs à construire et diagnostiquer des systèmes, pas pour optimiser un format d'entretien. Les organisations qui utilisent cette matière devraient être claires sur celui des deux objectifs qu'elles poursuivent, car la formation qui sert l'un ne sert pas nécessairement l'autre.
Ce qu'il faut retenir
La connaissance technique se périme à des rythmes différents, et la plupart des budgets de formation sont dépensés sur la couche qui se périme le plus vite.
La complexité est le concept unique le plus précieux, car elle prédit l'échec à l'échelle avant même que le code ne soit écrit.
La plupart des problèmes de performance en production sont des problèmes de mémoire, d'attente ou de concurrence, et ces trois-là vivent dans la couche système d'exploitation que la plupart des développeurs traitent comme invisible.
La génération de code élève la valeur du jugement, et le jugement ici, ce sont les fondamentaux.
Et les personnes qui en profitent le plus écrivent déjà du logiciel pour vous, avec une lacune précise, visible et rapide à combler.
Pourquoi enseigner les fondamentaux plutôt que les frameworks actuels ?
Parce que la connaissance des frameworks se périme en quelques années alors que les idées computationnelles sous-jacentes tiennent depuis des décennies, et les personnes qui maîtrisent les fondamentaux apprennent chaque nouveau framework en une fraction du temps.
Quel est le concept unique le plus utile ?
La complexité algorithmique. Elle explique pourquoi un code qui passe les tests échoue en volume de production, pourquoi une requête dans une boucle s'effondre sous des données réelles, et pourquoi choisir la bonne structure de données l'emporte généralement sur l'optimisation du code.
Pourquoi les concepts de système d'exploitation comptent-ils pour un développeur applicatif ?
Parce que la plupart des problèmes de performance en production sont des problèmes de mémoire, d'entrées-sorties ou de concurrence. Les applications passent typiquement leur temps à attendre plutôt qu'à calculer, et optimiser le calcul dans un programme qui attend ne sert à rien.
Les outils de génération de code rendent-ils les fondamentaux moins importants ?
Ils les rendent plus importants. Le travail passe de l'écriture de code au jugement d'un code que l'on n'a pas écrit, et le code généré ne peut pas connaître vos volumes de données, vos schémas d'accès ni votre budget de latence.
Qui profite le plus de cette formation ?
Les développeurs autodidactes et les diplômés de bootcamp, qui ont souvent une solide compétence pratique et une lacune précise et enseignable ici, suivis des analystes de données confrontés à des problèmes d'échelle et des administrateurs systèmes évoluant vers le développement.