J'ai parfois fait des choses un peu analogues, mais la systématisation du process (et l'inclusion des tickets de dette technique, dont je parle toujours mais que je ne fais pas assez) et vraiment bien pensée

Evidement que je suis d'accord avec Gregor Hohpe ! aider les développeurs à débugger est utile pour les développeurs (parce qu'on apporte de l'expérience et un regard différent) mais aussi pour les architectes (parce qu'on voit concrètement le système qu'on étudie habituellement de façon abstraite)

Peut-être la définition la plus poétique du borrow checker. Parce que peut-être qu'il vous surveille, mais c'est pour votre bien

Sapristi ! Il serait possible d'avoir un pattern proche des paramètres par défaut en Rust ? Ce serait cool !

Un très bon site de comics pour développeurs

Une liste de demi-fonctionnalités intéressantes dans certains langages peut-être un peu ésotériques

J'ai l'impression de lire un compte-rendu d'un jeu codingame (c'est normal), et ça me donne une idée sacrément curieuse (parce que, d'une façon très Durning-Krugerienne, j'ai l'impression qu'ils ont loupé quelques trucs)

Une stratégie de gestion des données supprimées de la base peut-être plus intéressante que la colonne "deleted_at", mais en tout cas un peu plus lourde

Traduction approximative "l'ajout abusif de fonctionnalités est la petite mort qui amène à la fin d'un logiciel. Je ferais face à mon désir de remplacer mon bloc if-else par un système d'événements. Je le laisserai me traverser sans rien ajouter"

Un moteur de recherche pour développeur appuyé par une de ces fameuses IA à base de grand modèles de langues

Un ensemble de ressources autour de l'éducation des développeurs.

Supposons que vous ayez besoin de textures, de blocs, d'éléments pour créer votre jeu ... Ce site vous les offre. Et c'est bien gentil.

Plus ça va, plus l'expérience me pousse à tenter d'expliquer simplement les choses. Et cet article est un parfait point d'entrée.

J'aime beaucoup ce sticker, il est assez drôle (même si il est assez faux)

Oh, j'aime vraiment beaucoup cette idée d'architecte qui partage le savoir, plutôt qu'un architecte qui code.

Une liste de conseils "de bon sens" (je me méfie beaucoup du bon sens, il fait brûler les sorcières). Les conseils qui sont donnés ici sont avant tout des conseils de pragmatisme : résolvez des problèmes clairs, et clairement exprimés, plutôt que de vous enfoncer dans des généralités insolubles.

Comme je dis toujours, pour réécrire un système, il faut pouvoir en reproduire les fonctionnalités ... et les bugs (et souvent, les bugs sont mal connus)

C'est une vision du rôle d'architecte que j'aime beaucoup.

Une surprise aussi intéressante que conceptuellement bonne : en PHP, les variables qui sont accessibles depuis une closure doivent être déclarées dans la signature de celle-ci. C'est un peu plus verbeux que dans d'autres langages, mais aussi plus lisible.

J'aime bien cette description de l'état d'esprit nécessaire à l'écriture de CSS. C'est bien autre chose que le code impératif.