Lorsque vous collaborez avec moi et partagez du code source ou des extraits de terminal dans un logiciel compatible avec le format Markdown, tel que GitHub, GitLab, Mattermost, Zulip, etc., je vous encourage à entourer vos extraits avec des balises ```. Par exemple :

De même, pour les citations de texte en prose, utilisez les caractères > au début de chaque ligne, comme illustré ci-dessous :

> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse justo neque, facilisis ut commodo in, auctor at tellus. Morbi non mattis risus. In vehicula risus felis, ac ullamcorper magna consequat et.
> Sed finibus, lorem a rutrum pulvinar, magna urna rutrum tortor, eget faucibus dolor enim sit amet lacus. Nulla pulvinar ligula eu leo rhoncus faucibus.

Ce qui produira :

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse justo neque, facilisis ut commodo in, auctor at tellus. Morbi non mattis risus. In vehicula risus felis, ac ullamcorper magna consequat et. Sed finibus, lorem a rutrum pulvinar, magna urna rutrum tortor, eget faucibus dolor enim sit amet lacus. Nulla pulvinar ligula eu leo rhoncus faucibus.

Ces deux recommandations permettent d'améliorer le confort de lecture de vos messages.

Voir aussi je préfère recevoir les extraits de vos textes au format texte plutôt que sous forme de captures d'écran.

Lorsque vous collaborez avec moi, je préfère recevoir les extraits de vos textes Markdown, vos codes sources, et le contenu de votre terminal au format texte plutôt que sous forme de captures d'écran.

Voici ci-dessous six inconvénients liés à l'utilisation de captures d'écran.

1. Impossibilité de copier le contenu

Lorsque vous partagez des lignes de commande, des configurations ou des messages d'erreur en capture d'écran, je ne peux pas copier le contenu pour le tester ou effectuer des recherches. Cela m'oblige à ressaisir manuellement le texte, avec le risque d'introduire des erreurs.

De plus, il m'est impossible de citer précisément une partie de votre contenu lors de nos échanges.

2. Impossible de cliquer sur les liens

3. Recherche inefficace

Les outils comme GitHub, GitLab, Slack, Zulip, Mattermost, Signal, WhatsApp, ainsi que les moteurs de recherche dans les pages des navigateurs, ne permettent pas de rechercher du texte présent dans des images. Le format texte, en revanche, est entièrement indexable et facilitera la recherche d'informations.

4. Consommation de mémoire multipliée par 100

Les captures écrans consomment beaucoup plus d'espace disque que du texte.

Prenons l'exemple d'un extrait de terminal au format texte :

# docker info
Client: Docker Engine - Community
 Version:    27.1.2
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.16.2
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.29.1
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 194
  Running: 194
  Paused: 0
  Stopped: 0
 Images: 34
 Server Version: 27.1.2
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2

Cet extrait consomme 682 octets de mémoire.

Je viens de vérifier : une capture d'écran équivalente consomme 83 000 octets de mémoire, soit 121 fois plus d'espace disque qu'un simple extrait de texte. Pour ceux qui utilisent des écrans haute résolution, comme les écrans Retina, cette consommation peut même être multipliée par 4.

Il est regrettable de saturer 100 fois plus rapidement l'espace disque sur des services comme GitHub, GitLab, Slack, Zulip, Mattermost, etc., pour une expérience utilisateur finalement moins optimale.

5. Chargement moins rapide des pages

Ceci est surtout impactant pour les issues ou Merge Request avec beaucoup de commentaires.

6. Occupation excessive de l'espace écran

Les captures d'écran, en particulier celles prises sur des écrans Retina, occupent souvent un espace d'écran excessif dans la fenêtre du navigateur, rendant la lecture des commentaires plus difficile et nuisant à la fluidité de la navigation.

Je viens d'ajouter le contenu du Mail de Musk en 2010 « Les acronymes sont vraiment à éviter » dans la documentation guidelines du projet professionnel sur lequel je suis en train de travailler actuellement.

Pourquoi ?

Dans un souci d'efficacité, j'aime recevoir des informations le plus explicites possible, afin d'éviter des quiproquos, de minimiser mes risques d'erreurs, d'éviter de faire perdre du temps à mes collaborateurs en posant une multitude de questions.

Comme j'essaie de suivre la règle d'or, j'essaie moi-même de communiquer de la façon la plus explicite possible — je précise que ce n'est pas simple, même avec la meilleure volonté du monde !

C'est pour cela que j'évite au maximum de créer et d'utiliser des acronymes.

Voici quelques extraits du Mail de Musk 2010 « Acronyms Seriously Suck ».

L'utilisation excessive d'acronymes inventés est un obstacle important à la communication et il est extrêmement important de maintenir une bonne communication au fur et à mesure que nous nous développons.

👍️

Personne ne peut se souvenir de tous ces acronymes et les gens ne veulent pas avoir l'air stupides lors d'une réunion, alors ils restent assis dans l'ignorance. C'est particulièrement difficile pour les nouveaux employés.

Je suis tout à fait d'accord avec cette déclaration 👍️.
J'ai appris par expérience que la majorité des humains ne posent pas de question quand ils ne connaissent pas un mot ou un sujet.
J'essaie personnellement de mettre mon égo de coté et de poser la question, mais il m'arrive aussi de ne pas le faire.

D'autre part, ma mémoire est limitée, l'apprentissage des acronymes internes d'une organisation ou d'une équipe me demande trop de charge cognitive.

Un acronyme que la plupart des ingénieurs en dehors de SpaceX connaissent déjà, tel que GUI, peut être utilisé.

Je suis tout à fait aligné avec cette pratique👍️.

Personnellement, je suis la règle suivante : j'ai le droit d'utiliser un acronyme à condition qu'il soit référencé par une page Wikipedia et que la liste de ses homonymes sur sa page "disambiguation" soit très courte dans mon contexte d'utilisation (exemple pour FTP). Si ce n'est pas le cas, je n'utilise pas l'acronyme.