Je tente une modeste traduction en Français :
1 Tout bon travail de développement logiciel commence par gratter le petit truc qui démange personnellement le développeur
2 Les bons programmeurs savent quoi écrire, les excellents programmeur savent quoi réécrire (et réutiliser).
3 “Attends-toi à devoir tout jeter, tu le feras, de toute façon" (Fred Brooks, “The Mythical Man-Month”, Chapitre 11)
4 Avec la bonne attitude, des problèmes intéressants se révèleront à toi.
5 Quand tu perds ton intérêt dans un programme, ton dernier devoir est de le confier à un successeur compétent.
6 Considérer vos utilisateurs comme des co-développeurs est le chemin le moins tortueux vers de rapides améliorations du code et un débogage efficace.
7 Sortez vos évolutions de version rapidement et souvent. Et écoutez vos clients.
8 Avec une grande communauté de bêta-testeur et de co-développeurs, quasiment tous les problèmes seront rapidement identifiés, et le moyen de les corriger sera toujours évident pour l’un d’eux.
9 Une organisation de données bien pensée, avec un travail de programmation bourrin, ça fonctionne mieux que l’inverse.
10 Si vous considérez vos bêta-testeurs comme la plus précieuse de vos ressources, alors ils le deviendront effectivement.
11 La meilleure chose à faire, après avoi de bonnes idées, est de reconnaitre les bonnes idées de vos utilisateurs. Parfois, au plus tard, au mieux.
12 Il arrive parfois que les solutions les plus innovantes et disruptives viennent en réalisant que votre conception du problème était mauvaise.
13 “la perfection (en matière de conception) est atteinte, non pas quand il n’y a plus rien à rajouter, mais plutôt quand il n’y a plus rien à enlever.”
14 Chaque outil devrait être utile en fonction de ce qui est attendu de lui, mais un outil exceptionnel devrait de lui-même vous faire aller vers des utilisations que vous n’imaginiez pas.
15 Quand vous écrivez des programmes “passerelle” de tout type, prêtez une attention particulière à troubler le moins possible le flux de données, et ne jetez jamais d’information, à moins d’y être contraint par le receveur. !
16 Quand votre langage de programmation est bien loin d’être “Turing-complet”, le sucre syntaxique est votre ami.
17 Un système de protection n’est au mieux qu’au niveau de sureté du secret qu’il protège. Méfiez vous des pseudo-secrets.
18 Pour résoudre un problème intéressant, commencez par trouver un problème qui vous intéresse.
19 Compte tenu du fait que le coordinateur du développement a à minima un outil tel qu’Internet, et qu’il sait comment diriger sans contraindre, beaucoup de cerveaux valent nécessairement mieux qu’un.
