Scott H. Young explique pourquoi étudier des solutions détaillées peut être plus efficace que résoudre seul des problèmes lorsqu’on débute. Les recherches de John Sweller montrent que la recherche laborieuse d’une solution surcharge la mémoire de travail et limite la compréhension des principes. Avec l’expertise, cet avantage s’inverse : la résolution autonome et le rappel des connaissances deviennent plus bénéfiques. L’auteur recommande une progression combinant exemples corrigés, explication personnelle des étapes, suppression graduelle des aides et exercices indépendants.

Matklad recommande d’éviter qu’une fonction publique d’un module en appelle une autre pour réutiliser son implémentation. Mieux vaut extraire la logique commune dans une fonction privée appelée par les deux : l’API publique reste ainsi adaptée à ses utilisateurs, sans accumuler des paramètres optionnels destinés uniquement aux besoins internes. Il distingue toutefois les fonctions publiques servant de raccourcis, qui peuvent légitimement composer d’autres appels publics. Il rappelle enfin qu’une règle de conception doit être jugée sur ses motivations plutôt qu’appliquée aveuglément.

Un « DNS menteur » est un résolveur qui modifie ou invente les réponses des serveurs faisant autorité, souvent pour empêcher l'accès à certains domaines. Stéphane Bortzmeyer distingue plusieurs usages : censure, blocage publicitaire ou protection contre des sites malveillants. Il illustre le mécanisme avec une réponse de Free renvoyant l'adresse locale 127.0.0.1, puis avec Google Public DNS, qui signale explicitement un blocage via le code EDE 16. Changer de résolveur peut contourner certains blocages, mais cette solution n'est pas accessible à tout le monde.

La méthode ZOMBIES est une heuristique pour choisir progressivement les prochains tests en TDD : Zero, One, Many, Boundary, Interface, Exceptions et Simple Scenarios. À travers un kata de calcul de score au bowling en Rust, l’auteur montre comment démarrer par les cas élémentaires, généraliser le comportement, puis traiter les spares, les strikes et les cas limites. L’approche complète le cycle Red–Green–Refactor sans le remplacer, en encourageant de petites étapes et un refactoring guidé par les tests.

Nicolas Simond partage son usage quotidien de Claude Code pour l’administration systèmes : génération de documentation d’infrastructure, analyse d’incidents, durcissement de serveurs et création de petits outils. Il délègue le code à des modèles Ollama via Aider, puis fait relire les modifications par Claude dans des branches Git isolées. Les données clients restent locales : seuls des exemples anonymisés servent à concevoir les scripts. L’auteur insiste sur les règles de projet, les contrôles humains et les tests, tout en soulignant les gains de temps obtenus sur les tâches répétitives.