Vous avez arrêté de lire la doc, maintenant vous ne comprenez plus les systèmes

Je n'ai pas étudié l'informatique à l'université. J'ai étudié la géophysique.

J'ai appris le logiciel en lisant. J'ai lu la documentation, le code source et les issues GitHub. J'ai lu de vieux articles de blog et des fils de discussion RFC. Je n'ai pas fait de bootcamp. J'ai utilisé un navigateur et de la matière brute.

Quand j'ai appris Cloudflare Workers, je n'avais pas de cours. J'avais la doc et le changelog. J'ai lu la configuration des bindings trois fois pour corriger un déploiement défectueux à 1h du matin. J'ai trouvé des réponses dans des fils GitHub datant d'il y a des années.

J'ai appris en m'immergeant dans la matière jusqu'à ce que le déclic se produise.

Maintenant, je vois un nouveau schéma. Les gens ne demandent pas pourquoi une section est déroutante. Ils demandent le code pour X. Ils ne suivent pas le code source pour comprendre le comportement. Ils demandent ce que fait une fonction.

L'objectif était autrefois la compréhension. Désormais, l'objectif est le résultat. Les gens appellent cela de l'efficacité. C'est en réalité de la dette.

Vous pouvez générer un circuit breaker sans savoir ce qu'est un état half-open. Cela fonctionne dans vos tests. Cela échoue en production six semaines plus tard sous une charge importante. Vous échouez parce que vous n'avez pas de modèle mental. Vous avez obtenu le « quoi » sans le « pourquoi ».

Le « pourquoi » est la seule chose qui importe.

Lire la documentation permet de construire un modèle mental. Vous voyez les compromis et les cas limites dans les notes de bas de page. La friction que vous ressentez en lisant est le moment où l'apprentissage se produit.

Quand j'ai construit Bookmark Brain, j'ai dû comprendre Cloudflare Vectorize. Je n'ai pas seulement utilisé l'API. J'ai étudié les dimensions d'embedding, le comportement des index et les métriques de distance de requête. J'ai lu l'article sur HNSW. Je me suis confronté à la confusion jusqu'à ce qu'elle se transforme en savoir.

Ce savoir permet à mes systèmes de fonctionner en production. Si quelque chose casse à 2h du matin, j'ai un modèle mental pour me guider. Si je n'utilisais que des prompts, j'aurais une démo, mais pas un système sur lequel je peux raisonner.

Cela crée une fracture dans l'ingénierie.

  • Dans les revues de code : Un développeur repère instantanément un problème N+1 parce qu'il a lu la doc de l'ORM. L'autre développeur passe à côté parce qu'il s'est contenté de générer le code.
  • En architecture : Un développeur comprend les partitions et les offsets de Kafka. L'autre connaît seulement le vocabulaire mais n'en maîtrise pas la structure.
  • En débogage : Le débogage est une fonction de votre modèle mental. Sans lui, vous ne faites que changer des choses en espérant que tout se passe bien.

L'IA ne peut pas appréhender une architecture entière. Elle ne voit pas la vue d'ensemble de votre base de code. J'ai vu des couches de mise en cache générées par l'IA passer tous les tests, puis faire planter la production parce qu'aucun humain n'avait compris les conditions de concurrence.

La fracture ne réside pas dans l'utilisation de l'IA. Elle réside dans la manière dont vous l'utilisez.

L'utilisez-vous pour comprendre les compromis ? Ou l'utilisez-vous pour éviter de comprendre ?

Les meilleurs développeurs ne se contentent pas d'aller vite. Ils continuent de lire les changelogs et le code source. Ils construisent un modèle mental que le prompting ne peut pas reproduire.

Lire la documentation est une pratique. Ce n'est pas une taxe sur votre productivité. C'est ce qui vous rend irremplaçable lorsque le système tombe en panne.

Si vous sautez la lecture, vous sautez la réflexion. Vous ne vous en rendrez compte que lorsque vous serez en production, sans aucun appui sur lequel vous reposer.

Source: https://dev.to/dannwaneri/you-stopped-reading-the-docs-now-you-dont-understand-the-systems-go1

Communauté d'apprentissage optionnelle: https://t.me/GyaanSetuAi