Perspectives

Commandes unix pour la manipulation de lignes de texte

Wed, 01 May 2019 00:00:00 GMT

Parfois, vous n'avez pas d'outil pour consulter les événements applicatifs. D'autre fois, on ne veut même pas vous y donner accès. Par contre, on aura bien voulu vous donner une archive bourrée de fichiers de logs sur un poste dédié. Mais que faire avec cet amas d'octets quand on a qu'un système unix entre les mains ? Regardons ensemble.

Comme sujet de pratique, nous allons explorer les logs d'un honeypot pour trouver des traces d'attaques et voir d'où elles peuvent venir (géographiquement). Un honeypot dans le domaine de la sécurité est une machine destinée à être attaquée pour observer des comportements malveillants. Nous nous baserons sur les logs disponibles sur ce site : http://old.honeynet.org/scans/scan34/. Le plus souvent, dans un environnement où ce type de besoin est fréquent, vous serez équipés d'outils qui feront toutes ces étapes pour vous et agiront même selon les événements de sécurité. Mais il arrive que ces outils ne soient pas présents, ou que vous ayez besoin de sortir des sentier battus proposés par les-dits outils.
Plus généralement ces commandes sont des connaissances de base en système unix. Elles vous serviront autant pour de l’administration du système que pour des tâches spécialisées comme l’audit d’une base de code par exemple.

Ce que vous pourrez faire à l'issue de cet article :

ouvrir une archive tar
lister des lignes
filtrer les lignes qui matchent ou non avec des regex
chaîner des commandes
compter le nombre de lignes
retirer les lignes en doublon
stocker un résultat intermédiaire
sélectionner du texte dans chaque ligne
formater les lignes
exécuter des commandes sur les lignes

Avant propos

Dans cet article certaines commandes nécessitent l'utilisation d'expressions régulières (aussi appelées regex). Je ne décrirai pas la façon de les utiliser. Mais sachez, si vous vous documentez sur le sujet, que les différents langages n'ont pas exactement les mêmes notations.

À la fin de cet article vous trouverez une fiche rapide de référence sur toutes les commandes que nous aurons vues.

Pour toutes les commandes que nous allons voir, je vous encourage à lancer un man (pour manuel) pour voir à quoi ressemble la doc de la commande en question. Chercher dans cette doc les éléments que je vais vous présenter vous donnera un réflexe qui vous servira pour toujours ! Enfin tant que vous serez dans un shell unix.

Exemple pour consulter la doc de la commande echo :

$ man echo

NAME
    echo -- write arguments to the standard output

SYNOPSIS
    echo [-n] [string ...]

DESCRIPTION
[...]

Une fois dans la doc vous pouvez également faire des recherches avec la commande /. Par exemple si je cherche des informations sur les retours à la ligne, une fois dans la page de manuel de echo je tape la touche / suivi du mot clé que je cherche :

/newline

Commençons par ouvrir l'archive

Après avoir téléchargé le fichier SotM34-anton.tar.gz, nous allons l'ouvrir. Selon l'extension, tar signifie que c'est une archive de type tar qui peut être extraite avec le programme du même nom, et gz signifie que l'archive est compressée (l'extension tgz est une contraction avec les mêmes significations). Nous l'ouvrons alors avec cette commande :

$ tar xzf SotM34-anton.tar.gz

Dans le détail cette commande est composée de :

tar: le programme qui permet de créer, et ouvrir des archives
x: pour extract, dit à tar d'extraire le contenu (l'option c, pour compress, permet au contraire de compresser des fichiers)
z: indique que l'archive doit être décompressée
f: permet de spécifier l'archive à ouvrir
SotM34-anton.tar.gz: le nom de l'archive sur laquelle nous travaillons

Après avoir exécuté cette commande, vous devriez voir apparaitre le dossier SotM34 à côté de l'archive. Celui-ci contient les logs qui nous intéressent.

N'oubliez pas de faire un man tar pour retrouver les options présentées ici !

Localiser des traces d'attaques

Maintenant que nous avons nos logs, commençons par les traces les plus simples et évidentes à trouver : une attaque brute-force sur le login de la machine. Cherchons alors des événements répétés dans les logs secure de syslog qui contiennent les événements de login.

Après un cd syslog, affichons chaque ligne des fichiers secure :

$ cat secure*

cat est le programme d'affichage
secure* signifie que nous allons lister tous les fichiers commençant par secure suivi de n'importe quel texte. Dans notre cas, c'est comme si nous avions lancé cette commande : cat secure secure.1 secure.2 secure.3 secure.4 secure.5 secure.6

Un extrait du résultat:

Mar 13 16:26:09 combo sshd[8714]: Accepted password for test from 59.120.2.133 port 57019 ssh2
Mar 13 16:26:09 combo sshd[8716]: Accepted password for test from 59.120.2.133 port 57023 ssh2
Mar 13 16:26:09 combo sshd[8721]: Accepted password for test from 59.120.2.133 port 57051 ssh2
Mar 13 16:26:09 combo sshd[8720]: Accepted password for test from 59.120.2.133 port 57049 ssh2
[...]

Ce qui s'affiche est tout le contenu des fichiers. On peut voir plusieurs lignes différentes, mais chercher les traces d'attaque dans ce résultat est fastidieux. Voyons comment extraire cette information de ces lignes de texte.

Filtrer les lignes qui indiquent l'utilisation d'un mauvais mot de passe

Nous allons faire en sorte que seules les lignes avec des tentatives échouées de login pour mauvais mot de passe s'affichent. On voit dans les lignes affichées avec la commande précédente que certaines lignes ressemblent à ça :

Feb  5 04:32:25 combo sshd[9703]: Failed password for nobody from 210.3.2.8 port 53044 ssh2

La partie commune à toutes les tentatives échouées est donc : Failed password. Nous allons alors filtrer les lignes pour n'avoir que celles qui contiennent ces deux mots.

$ grep 'Failed password' secure*

grep est la commande qui permet de filtrer des lignes de texte
'Failed password' est la chaîne que nous voulons sélectionner
secure* est comme pour cat la liste des fichiers commençant par secure

Un extrait du résultat:

secure:Mar 13 22:50:55 combo sshd[9356]: Failed password for root from 67.103.15.70 port 55639 ssh2
secure:Mar 13 22:51:07 combo sshd[9358]: Failed password for root from 67.103.15.70 port 55895 ssh2
secure:Mar 13 22:51:18 combo sshd[9360]: Failed password for root from 67.103.15.70 port 56110 ssh2
[...]

Mais comment savoir combien de tentatives échouées le serveur à subit ?

Obtenir le nombre de lignes affichées

Pour connaître le nombre de lignes, j'ai utilisé une autre commande : wc (word count). Cet utilitaire permet de compter les mots, lignes, nombre de caractères et bytes.
Pour connaître le nombre de lignes dans le fichier secure.1 :

$ wc -l secure.1

wc : l'utilitaire qui permet de compter
-l : l'option qui permet de ne compter que le nombre de lignes
secure.1 : le fichier dont on veut compter le nombre de lignes

Le résultat:

234 secure.1

Sauf que le résultat de grep n'est pas un fichier. Pour la plupart des commandes que je vous présente dans l'article, celles-ci peuvent être exécutées sur des fichiers, mais également sur l'entrée standard. L'entrée standard c'est le nom que l'on donne aux "champs" qui nous permettent de donner des informations à des programmes. Par exemple quand vous tapez une commande, vous la donnez à l'entrée standard.
Essayons en tapant wc -l seul : le programme sera en attente d'informations. Vous pouvez alors taper tout ce que vous voulez et même revenir à la ligne. Pour sortir de l'entrée standard il faut notifier wc que nous avons terminé avec la combinaison de touches ctrl-D qui, sous un système unix, envoie le signal EOF pour End Of File. Vous verrez alors un résultat qui ressemble à celui que vous avez obtenu en donnant un fichier à wc

$ wc -l
Un exemple
Avec
Des lignes
        3

Cependant, ce que donne grep en résultat vient sur la sortie standard (et non l'entrée). Pour envoyer la sortie standard d'un programme sur l'entrée standard d'un autre, Unix propose le pipe noté |.
Si on chaîne les commandes grep et wc nous avons alors :

$ grep 'Failed password' secure* | wc -l
    702

Le caractère | sera très souvent utilisé tout le long de cet article car il permet de combiner autant de commandes que l'on veut. Et si vous tentiez d'utiliser la commande grep à nouveau retrouver les tentatives échouées ? Et cette fois-ci, tentez d'utiliser pipe, sans donner directement des fichiers à grep.

Trouver les IP des attaquants

Dans le résultat de la commande grep, nous pouvons voir plusieurs IP différentes. Certaines tentatives échouées pourraient être anecdotiques, mais d'autres bien plus nombreuses ressemblent plutôt à un comportement malveillant.

Nous allons alors extraire les IPs de nos attaquants avec la commande grep à nouveau, mais cette fois-ci avec une option permettant de ne garder en sortie standard que la condition qu'on lui spécifie :

$ grep 'Failed password' secure* | grep -Eo '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}'

-E: signifie que nous utilisons une expression régulière et non une chaîne de caractère simple
-o: signifie que seul ce qui correspondra à la regex sera affiché en sortie standard (au lieu de toute la ligne)
[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3} correspond à une regex pour filtrer des IP très grossièrement, chaque partie porte ce sens :
- [0-9]: n'importe quel caractère allant de 0 à 9
- {1,3}: entre 1 et 3 caractères
- \.: le caractère .

Un extrait du résultat:

67.103.15.70
67.103.15.70
67.103.15.70
67.103.15.70
67.103.15.70
67.103.15.70
67.103.15.70
67.103.15.70
128.59.112.2
[...]

Nous avons alors réussi à extraire les IPs !

Compter les apparitions de chaque IP

Toutes ces IPs c'est bien mais wc ne permet de compter qu'un nombre total de lignes. Il faut alors compter en distinguant les lignes qui se ressemblent ! On va alors utiliser la commande uniq qui permet de distinguer les lignes similaires :

$ grep 'Failed password' secure* | grep -Eo '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | uniq -c

uniq: la commande qui permet de distinguer les lignes identiques
-c: qui permet de compter le nombre de lignes identiques

Un extrait du résultat:

[...]
 9 202.110.184.100
 2 67.103.15.70
17 210.125.27.175
14 202.110.184.100

Le résultat est déjà plus intéressant, mais on remarque que les mêmes IPs apparaissent plusieurs fois. uniq -c ne distingue que les lignes identiques consécutives, il faudrait trouver un moyen de regrouper toutes les lignes identiques. On va pour cela utiliser la commande sort juste avant que uniq prenne la main :

$ grep 'Failed password' secure* | grep -Eo '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | sort | uniq -c

sort: trie les lignes dans l'ordre croissant
uniq -c: commande exécutée précédemment qui permet de regrouper et de compter les lignes identiques consécutives

Un extrait du résultat:

23 128.59.112.2
 1 148.228.20.76
 8 198.107.38.61
[...]

Et pour aller plus loin nous allons même retrier les lignes pour avoir les IPs les plus présentes vers la fin de la liste :

$ grep 'Failed password' secure* | grep -Eo '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | sort | uniq -c | sort

Un extrait du résultat:

1 148.228.20.76
1 82.76.137.124
2 202.69.66.162
2 211.141.89.73
[...]

Une pause

Notre ligne de commande commence à être assez longue. Nous allons donc stocker nos résultats.

On pourrait stocker le résultat dans un fichier si on voulait s'en resservir plus tard :

$ grep 'Failed password' secure* | grep -Eo '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | sort | uniq -c | sort > bad_ips

>: redirige la sortie standard vers un fichier
bad_ips: le nom du fichier dans lequel nous stockerons les lignes

Pour se resservir du fichier, il suffit de se resservir de cat sur le fichier pour reprendre là où on en était.

On pourrait également stocker le résultat dans une variable qui ne durera que le temps que notre terminal sera ouvert :

$ bad_ips=$(grep 'Failed password' secure* | grep -Eo '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | sort | uniq -c | sort)

bad_ips=$( ... ): stocke dans la variable bad_ips le résultat de la commande qui se trouve entre les parenthèses

Pour se resservir de la variable nous pouvons utiliser

$ echo "${bad_ips}"

${...}: permet de demander une variable préalablement remplie
Les guillemets sont nécessaires, autrement la variable sera déroulée comme une liste de paramètres pour echo, hors nous voulons garder la suite de ligne. Si vous tentez un echo sans les guillemets, vous verrez que tous les paramètres auront été affichés côte à côte.

Pour la suite, j'utiliserai la variable, mais n'hésitez pas à utiliser la version fichier, le résultat sera le même !

Sélectionner les 5 IPs les plus "agressives"

Dans cette liste d'IPs, toutes ne sont pas nécessairement intéressantes. Ici on va se concentrer sur l'extraction des 5 IPs les plus représentées dans les tentatives échouées. Notre liste étant déjà triée par ordre croissant, il faudrait que nous ne puissions afficher que les 5 dernières lignes. Pour cela, nous allons utiliser la commande tail :

$ echo "${bad_ips}" | tail -n 5

tail: la commande qui permet d'afficher les dernières lignes fournies en entrée standard ou par fichier
-n 5: l'option n permet de spécifier le nombre de lignes que l'on veut afficher

Le résultat:

32 81.56.82.49
80 222.237.79.237
80 62.193.229.186
80 66.79.166.130
93 202.110.184.100

Nous avons donc les lignes, mais il nous faudrait uniquement les IPs, pas le nombre. Nous allons donc réécrire les lignes pour n'avoir plus que les IPs. awk est un programme qui permet d'effectuer des actions sur les lignes, un peu comme une fonction map. Lorsqu'il est exécuté :

$ echo "${bad_ips}" | tail -n 5 | awk -F ' ' '{print $2}'

awk: le programme qui va transformer les lignes
-F ' ': cette option permet de définir un séparateur, et comme sur nos lignes il y a un espace entre le nombre et l'IP, nous spécifions un espace (par défaut awk gère déjà l'espace, je l'ai placé ici pour l'exemple)
{print $2}: l'action à réaliser, ici on demande à afficher la deuxième colonne (de part et d'autre du séparateur), $0permet d'afficher toute la ligne

Le résultat:

81.56.82.49
222.237.79.237
62.193.229.186
66.79.166.130
202.110.184.100

Voilà nos 5 IPs !

Localiser les IPs

Et si nous tentions d'obtenir la localisation de ces 5 IPs ? Un service gratuit https://hackertarget.com/geoip-ip-location-lookup/ permet d'appeler une API (max 100 appels par jour) pour obtenir la localisation d'une IP. Ce type de service est notamment utilisé en détection de fraude, par exemple par des partenaires de paiement pour des sites de billetterie, afin de désactiver l'accès d'une région à un service si le taux de fraude de cette provenance est trop important. L'url proposée s'utilise en ajoutant l'IP à la fin de l'URL, dans les query parameters : https://api.hackertarget.com/geoip/?q=1.1.1.1 . Nous utiliserons donc la commande curl qui permet de faire des appels http de cette façon : curl https://api.hackertarget.com/geoip/?q=1.1.1.1

Jusque là nous ne faisions que transmettre la sortie standard vers l'entrée standard, mais dans ce cas nous ne pourrons pas simplement laisser la commande se débrouiller avec cette entrée car elle doit faire quelque chose de spécifique : ajouter le paramètre à la fin de l'URL.
Deux méthodes sont dans ce cas possible. La première méthode implique de reformarter les lignes avec awk, qui est un outil que nous avons déjà vu. Nous allons donc en utiliser une seconde qui consiste à utiliser xargs pour arranger des paramètres pour une autre commande. Le nombre d'appels au service étant limité, je vous propose de stocker le résultat dans un fichier ou une variable au choix pour s'en resservir sans refaire les appels http.

$ echo "${bad_ips}" | tail -n 5 | awk '{print $2}' | xargs -I{} curl -w "\n" https://api.hackertarget.com/geoip/?q={} > bad_ips_location

xargs: la commande qui permet d'arranger les paramètres pour une autre commande, ici curl
-I {}: cette option décrit quel symbole utiliser, ici {}, pour représenter la ligne en entrée (la notation {} est semble-t-il standard, parce que ce serait celle de find, je vous laisse vérifier par vous-même !)
curl: la commande qui fera l'appel http (celle-ci me sert très souvent)
-w "\n": l'option de curl qui permet d'ajouter du texte à la fin de la réponse, ici on veut un retour à la ligne après chaque réponse
https://api.hackertarget.com/geoip/?q={}: l'URL que nous voulons appeler dans laquelle nous avons placé notre symbole décrit avec -I
> bad_ips_location: comme vu plus haut, on redirige la sortie standard de curl vers un fichier pour stocker le résultat

Un extrait du résultat après un cat bad_ips_location:

[...]
IP Address: 62.193.229.186
Country: France
State: Provence-Alpes-Cote d'Azur
City:
Latitude: 43.2854
Longitude: 5.3761
[...]

Et nous avons différentes informations comme le pays et la région d'où proviennent les IPs. Et voilà !

Il faut cependant noter qu’une IP ne donne pas nécessairement la véritable adresse de l’attaquant. D’un part elle pourrait être celle d’un VPN utilisé pour cacher l’origine réelle. D’autre part cette IP pourrait être celle d’un zombie, c’est à dire un appareil piraté dans le but d’émettre des attaques (comme une webcam dont on aurait pas changé le mot de passe par défaut). Dans le cas d’un déni de service, ces appareils zombies peuvent attaquer par milliers pour rendre le ban d’IP inutile.

Bonus track : voir les IPs sur une carte

Et si on visualisait la localisation des IPs sur une carte ? Il faudrait pouvoir appeler une url vers une carte avec la latitude et la longitude en paramètre, sauf que dans notre cas, ces valeurs ne sont pas sur les mêmes lignes. Alors comment les capturer ? Plusieurs méthodes permettent d'y parvenir, mais nous allons principalement réutiliser les mêmes commandes pour explorer d'autres de leurs options.

On va commencer par ne filtrer que les lignes indiquant la Latitude et la Longitude. Ces lignes étant consécutives, on va se servir de l'option de contexte -A de grep

$ cat bad_ips_location | grep --no-group-separator -A1 Latitude

grep: la commande qui nous permet de sélectionner les lignes
--no-group-separator: empêche grep d'afficher un séparateur entre les lignes de contexte (Attention, sous osx ce paramètre n'existe pas et n'est pas nécessaire)
-A1: demande à afficher 1 ligne après la ligne sélectionnée (-B permet d'afficher les lignes d'avant)
Latitude: le texte à sélectionner

Un extrait du résultat:

[...]
Latitude: 43.2854
Longitude: 5.3761
[...]

Une fois ces lignes affichées, nous allons afficher sur la même ligne la latitude et la longitude. awk permet d'exécuter des commandes complexes sous forme de script shell. Nous allons stocker la latitude dans une variable quand on tombera sur cette ligne, et afficher le contenu de la variable et la ligne courante quand la ligne courante est la longitude.

$ cat bad_ips_location | grep --no-group-separator -A1 Latitude | awk '{if (/Longitude/) print lat " " $0; lat=$0}'

awk: notre commande de transformation de ligne

Le script donné à awk peut être vu de cette façon :

{ # début du script
    if (/Longitude/) # si la ligne courante contient 'Longitude'
        print lat " " $0 # alors on affiche la variable latitude puis un espace et la ligne courante (donc la longitude)
    ; # fin du alors, début du sinon
        lat=$0 # sinon on stocke le contenu de la ligne courante (qui devrait être la latitude)
} # fin du script

Les parties alors et sinon peuvent contenir plusieurs commandes, mais dans ce cas chaque partie doit être encadrée d'accolades, et les instructions à l'intérieur doivent être séparées par des ;.

Le résultat:

Latitude: 43.5995 Longitude: 1.4332
Latitude: 37.5112 Longitude: 126.9741
Latitude: 43.2854 Longitude: 5.3761
Latitude: 37.3249 Longitude: -121.9153
Latitude: 30.5801 Longitude: 114.2734

On a donc désormais la latitude et la longitude sur une même ligne.
Nous allons finir en utilisant une commande que nous avons déjà vu pour transformer les lignes et extraire les colonnes qui nous intéressent. Vous remarquerez que nous aurions pu utiliser presque exactement cette commande à la place de xargs pour faire notre première requête qui nous a donné les lieux.

$ cat bad_ips_location | grep --no-group-separator -A1 Latitude | awk '{if (/Longitude/) print lat " " $0; lat=$0}' | awk '{print "https://www.openstreetmap.org/#map=14/" $2 "/" $4}'

awk: notre commande de transformation de ligne
{print "https://www.openstreetmap.org/#map=14/" $2 "/" $4}: on affiche l'URL openstreetmap, suivie de la deuxième colonne (valeur de la latitude), suivie d'un slash pour respecter le format des paramètre de l'URL, suivi de la quatrième colonne (valeur de la longitude)

Un extrait du résultat:

[...]
https://www.openstreetmap.org/#map=14/37.5112/126.9741
[...]

Et voilà des liens qui nous afficherons l'emplacement des IPs sur une carte !

Quickref

Vous pouvez retrouver l'ensemble des commandes de ce tuto ici :

La plupart des exemples suivants consomment un fichier. Mais n'oubliez pas qu'il peut consommer la sortie standard d'une autre commande à travers |.

Page de manuel des commandes: man some_command
- /: une fois dans man, cette touche permet de rechercher du texte (e.g.: /ma recherche)
Décompresser et ouvrir une archive: tar xzf file.tar.gz
- tar: le programme qui permet de créer, et ouvrir des archives
- x: dit à tar d'extraire le contenu (l'option c permet au contraire de créer une archive, cf man tar)
- z: indique que l'archive doit être décompressée (inutile si l'archive n'est qu'un file.tar)
- f: permet de spécifier l'archive à ouvrir
- file.tar.gz: le nom de l'archive sur laquelle nous travaillons
Afficher le contenu de fichiers: cat secure*
- cat est le programme d'affichage
- nom* signifie que nous allons lister tous les fichiers commençant par nom suivi de n'importe quel texte. Dans le cas de cet article, cat secure* revient à faire : cat secure secure.1 secure.2 secure.3 secure.4 secure.5 secure.6
Filtrer les lignes en fonction d'une chaîne de caractère: grep 'chaîne à rechercher' nom*
- grep est la commande qui permet de filtrer des lignes de texte
- 'chaîne à rechercher' est la chaîne que nous voulons sélectionner
- nom* est comme pour cat la liste des fichiers commençant par nom
Filtrer les lignes en fonction d'une expression régulière: grep -Eo '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' filename
- grep est la commande qui permet de filtrer des lignes de texte
- -E: signifie que nous utilisons une expression régulière et non une chaîne de caractère simple
- -o: signifie que seul ce qui correspondra à la regex sera affiché en sortie standard (au lieu de toute la ligne)
- [0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3} correspond à une regex pour filtrer des IP très grossièrement, chaque partie porte ce sens :
  - [0-9]: n'importe quel caractère allant de 0 à 9
  - {1,3}: entre 1 et 3 caractères
  - \.: le caractère .
Filtrer les lignes en affichant également les lignes suivantes: grep --no-group-separator -A1 Latitude filename
- grep: la commande qui nous permet de sélectionner les lignes
- --no-group-separator: empêche grep d'afficher un séparateur entre les lignes de contexte (Attention, sous osx ce paramètre n'existe pas et n'est pas nécessaire)
- -A1: demande à afficher 1 ligne après la ligne sélectionnée (-B permet d'afficher les lignes d'avant)
- Latitude: le texte à sélectionner
Compter un nombre de lignes: wc -l filename
- wc : l'utilitaire qui permet de compter
- -l : l'option qui permet de ne compter que le nombre de lignes
- filename : le fichier dont on veut compter le nombre de lignes
Trier des lignes dans l'ordre croissant: sort filename
- sort: trie les lignes dans l'ordre croissant
Dédoubler des lignes identiques consécutives: uniq -c filename
- uniq: la commande qui permet de distinguer les lignes identiques consécutives, faire un sort au préalable si on veut éliminer les doublons non consécutifs mais attention vous perdrez l'ordre d'apparition des lignes à l'origine
- -c: qui permet de compter le nombre de lignes identiques
Capturer la sortie standard d'une commande dans un fichier: some_command > filename
- >: redirige la sortie standard vers un fichier
- filename: le nom du fichier dans lequel nous stockerons les lignes
- peut être affiché avec un cat filename
Stocker la sortie standard d'une commande dans un ficher: bad_ips=$(some_command)
- filename=$( ... ): stocke dans la variable filename le résultat de la commande qui se trouve entre les parenthèses
- peut être récupéré avec echo "${filename}"
Afficher uniquement les 5 dernières lignes d'un fichier: tail -n 5 filename
- tail: la commande qui permet d'afficher les dernières lignes fournies en entrée standard ou par fichier
- -n 5: l'option n permet de spécifier le nombre de lignes que l'on veut afficher
- l'option -f permet d'afficher les dernières lignes d'un fichier pendant qu'il est en cours d'écriture (utile par exemple quand ils s'agit de logs)
- son pendant pour le début de fichier est head
Positionner des paramètres pour d'autres fonctions: some_command | xargs -I{} somecommand {}
- xargs: la commande qui permet d'arranger les paramètres pour une autre commande, ici curl
- -I {}: cette option décrit quel symbole utiliser, ici {}, pour représenter la ligne en entrée
- curl: la commande qui fera l'appel http
- -w "\n": l'option de curl qui permet d'ajouter du texte à la fin de la réponse
- https://api.hackertarget.com/geoip/?q={}: l'URL que nous voulons appeler dans laquelle nous avons placé notre symbole décrit avec -I
Transformer les lignes: awk -F ' ' '{print $2}'
- awk: le programme qui va transformer les lignes, un peu comme une fonction map
- -F ' ': cette option permet de définir un séparateur, et comme sur nos lignes il y a un espace entre le nombre et l'IP, nous spécifions un espace (par défaut awk gère déjà l'espace, je l'ai placé ici pour l'exemple)
- {print $2}: l'action à réaliser, ici on demande à afficher la deuxième colonne (de part et d'autre du séparateur), $0permet d'afficher toute la ligne

Grouper des paires de lignes avec un script shell: awk '{if (/Longitude/) print lat " " $0; lat=$0}' filename

awk: notre commande de transformation de ligne

La script donné à awk peut être vu de cette façon :

{ # début du script
    if (/Longitude/) # si la ligne courante contient 'Longitude'
        print lat " " $0 # alors on affiche la variable latitude puis un espace et la ligne courante (donc la longitude)
    ; # fin du alors, début du sinon
        lat=$0 # sinon on stocke le contenu de la ligne courante (qui devrait être la latitude)
} # fin du script

Effets de pratique distribuées sur la mémorisation

Fri, 26 Jul 2019 00:00:00 GMT

Introduction

L'étude des effets des pratiques distribuées a débuté avec les travaux d’Hermann Ebbinghaus à la fin du XIXe siècle. La dernière revue sur le sujet date de 1987. Ceci est la synthèse d'une revue de Émilie Gerbier et d'Olivier Koenig publiée en 2015 dans L'Année Psychologique 2015/3 (Vol. 115).

Dans cette revue, il est question de deux sous-effets de la pratique distribuée :

l'effet d'espacement : les répétitions espacées sont-elles plus efficaces que des répétitions enchainées immédiatement
l'effet d'intervalle : les répétitions effectuées dans des conditions différentes ont-elles des effets sur la mémorisation

Effet d'Espacement

Paradygme expérimental

Pour mesurer cet effet, l'expérience s'est déroulée en 3 étapes :

La phase d'apprentissage
Le délai de rétention
La phase de rappel

En phase d'apprentissage, on présente deux fois les items à apprendre. Pour chaque présentation, le participant a pour objectif de mémoriser ces items. Deux types de phase d'apprentissage seront évaluées, en faisant varier l'intervalle inter-répétition (IIR), c'est à dire l'intervalle entre la première présentation d'un item, et sa deuxième présentation. Dans le cas d'une IIR nul, l'item est alors présenté deux fois d'affilée (e.g. IRR de 0 = dog-chien, dog-chien). On parle alors de condition massée. Dans le cas d'un IRR positif, les deux présentations d'un item sont intercalées avec la présentation d'autres items (e.g. IIR de 2 = dog-chien, house-maison, car-voiture, dog-chien). On parle alors de condition distribuée.

Après la phase d'apprentissage, un délai de rétention (DR) variable s'écoule avant la phase de rappel.

En phase de rappel le paticipant doit restituter un maximum de bonnes réponses. Les méthodes de rappel peuvent varier : rappel libre (dog-chien), rappel indicé (dog-?), reconnaissance, jugement de fréquence ...

L’Année psychologique, 2015/3 (Vol. 115), p. 435-462. Schéma du paradigme classiquement mis en œuvre pour étudier les effets de pratique distribuée. Cas A étude de l'effet d'espacement. Cas B étude de l'effet d'intervalle.

Résultats

Les performances de la condition distribuée sont deux à trois fois supérieures à la condition massée. Ces performances sont indépendantes de la méthode de rappel utilisée. La condition distribuée mettrait en jeu la mémoire procédurale, ce que ne mobiliserait pas la condition massée. Trois hypothèses ont pu être testées dans ces conditions.

Mécanismes en jeu

Variabilité d'encodage

L'hypothèse de variabilité d'encodage, selon laquelle une information serait mieux mémorisée en la répétant dans des conditions différentes, n'a pas été retenue. Ces conditions peuvent être la couleur, le son, l'état émotionel, les items vus précédement, et cetera.
Là où la variabilité d'encodage semble augmenter sensiblement les performances en condition massée, elle est contre productive en condition distribuée.

Au contraire, la mémorisation en condition distribuée est plus efficace quand un item est répété dans des conditions similaires.

Traitement déficitaire

L'hypothèse du traitement déficitaire, selon laquelle l'attention à la mémorisation décroit lors de la seconde présentation d'un item, a pu être prouvée dans les deux conditions. Cependant la décroissance d'attention est plus importante en condition massée que distribuée.

Cette décroissance serait à la fois physiologique et consciente. Consciement, on suppose que le participant pourrait plus facilement avoir l'illusion de savoir en condition massée car il vient à peine de voir la première présentation lorsqu'on lui présente la seconde. Physiologiquement, en condition massée l'item est encore en mémoire de travail (très court terme). L'activation, et donc le traitement sémantique (l'appropriation du sens), serait alors moins importante.

On remarque aussi que plus l'IIR est important, moins le traitement déficitaire est important. L'attention à la mémorisation est d'autant plus importante que la deuxième présentation est espacée de la première. Cela serait dû à l'absence de suppression de répétition, c'est à dire que lorsque l'information est répétée à très court intervalle, le cerveau réduit l'importance de l'information.

L'amplitude de cet effet d'espacement ne varie pas avec l’âge.

Des mécanismes neurophysiologiques à l’œuvre au niveau synaptique dans l’effet d’espacement ?

En stimulant des neurones de façon espacée, le neurone pré-synaptique (celui qui emet) renforce la synapse du neurone post-synaptique (celui qui reçoit) au contraire de stimulations en condition massées. On observe que les changements biochimiques en sein des neurones sont plus importants lors d’une stimulation espacée, c'est à dire qu'ils sont plus impactés par la stimulation.

Effet d’intervalle sur une longue échelle de temps

Paradigme expérimental

Dans les conditions citées précédement, la variation a portée à la fois sur les intervalles inter-répétition (IIR) et sur les délais avant le rappel (DR).

L’Année psychologique, 2015/3 (Vol. 115), p. 435-462. Reproduction d’une partie des résultats de l’étude de Cepeda et al. (2008).

Résultats

On observe d'abord que la performance est plus durable après une répétition que avant.
On constate que la durée d'IIR optimale a une durée plus courte que le DR. Cet effet est observable quel que soit l'âge et l'espèce. Par exemple, on a pu observer une IIR optimale de 1 jour pour un DR de 7 jours, ou bien une IIR de 21 jours pour un DR de 350 jours. L'IIR optimal doit donc être calculé pour un DR donné.

Mécanismes en jeu

Hypothèse de la récupération en phase d’apprentissage

L'hypothèse de la récupération en phase d'apprentissage, selon laquelle la reconnaissance d'un item lors de la phase d'apprentissage favorise sa mémorisation, est validée. Cette validation appuie la réfutation de l'hypothèse de variabilité d´encodage, un item doit donc être présenté de façon similaire pour faciliter sa mémorisation.

La répétition est plus efficace lorsque la reconnaissance d'un item mobilise la mémoire à long terme, ce qui appuie les résultats de l'hypothèse du traitement déficitaire. La condition massée ou une IIR court mobilisent la mémoire de travail ce qui n’apporte aucun bénéfice. En revanche si l’IIR est trop long, la récupération est très difficile voire impossible, et la répétition n’est pas reconnue.

Il existe donc une IIR optimale favorisant la mémorisation.

La non-indépendance des traces en mémoire et la suradditivité

La mémorisation est plus efficace lorsque que les traces mnésiques ne sont pas indépendantes. C'est à dire que la mémorisation de la seconde présentation dépend du lien qui peut être créé avec la première. Lorsque la seconde présentation d’un item semble différente de la première, les traces mnésiques on plus de chances d’être indépendantes.

L’espacement de la répétition d’un item perçu comme identique ajoute un statut particulier à l’item qui le rend plus simple à récupérer, et donc, selon la précédente hypothèse, facilite la mémorisation.

Mécanismes cognitifs en jeu dans la récupération en phase d’études

Lors de l'effort de mémorisation d'un item à la seconde présentation, ce n’est pas la première mémorisation qui est renforcée, mais la nouvelle mémorisation qui bénéficie de la première. On parle de mémorisation récursive. Une nouvelle mémorisation repose alors sur :

l'item présenté
le traitement de la mémorisation précédente
les éléments contextuels de la mémorisation précédente
le traitement actuel de l'item

La mémorisation récursive est une composition des mémorisations plutôt qu'une mémorisation indépendante des différentes occurences.

On observe aussi que l’expérience subjective consciente du contexte passé favorise la remémoration (dans d'autres expériences, il a été observé que la force d'un souvenir était dépendante du contexte émotionel et de la force de ce dernier). Pour autant, la remémoration serait plus forte avec des délais importants parce que les éléments instables (contexte, émotions) disparaîtraient plus facilement avec le temps que les éléments stables (sémantique). Un délai important permettrait alors de ne renforcer que l’essentiel.

Consolidation et sommeil

La consolidation peut avoir lieu dans la minute et plusieurs jours après, et semble se produire en rattachant des zones au sein de l'hypocampe.

Le sommeil participe aussi à cette consolidation. Un sommeil normal entre les IIR renforce les performances de rétention. (Sur les épaules de Darwin: La stimulation biochimique de la journée est comme purgée des signaux les moins forts : chaque signal perd en intensité et ne persistent que les plus forts).

Dans les expériences, une IIR de 7 jours semble optimale pour 2 mois, et une IIR de 21 jours au delà.

Conclusion

Durant ces expériences, il a aussi été observé que le test de rappel d'un item permet une mémorisation plus efficace que si l'item est simplement présenté à nouveau. On observe aussi qu'induire le rappel des présentations précédentes améliore la récupération.

Finalement, les répétitions massées d’une même leçon ne sont pas favorables à l'exercice de mémoire des enfants. Il n'y a pas de durée optimale précises dans l’éducation, mais une distribution des répétitions sur plusieurs jours suffit quand les tests sont suivis d’une séance de réapprentissage (présentation des questions et solutions).

Une piste pour la mémorisation à plus long terme serait plus de répétitions avec une augmentation progressive des IIR.

L’Année psychologique, 2015/3 (Vol. 115), p. 435-462. Reproduction d’une partie des résultats de l’étude de Cepeda et al. (2008) avec inversion des axes.

Récap/Idées

Il faut estimer le délai de rétention voulu avant de décider d'une fréquence de répétition. Lors de ces répétitions, il faut être attentif à ce que l'item soit reconnaissable pour provoquer la récupération des présentations précédentes.

Une répétition dans la même journée n'a presqu'aucun bénéfice si l'objectif est de mémoriser pour plusieurs jours. Dans le cas d'un apprentissage à très long terme, la fréquence de répétition doit s'espacer progressivement en suivant une fonction puissance. On peut étudier l'efficacité d'une suite de Fibonacci : 1, 2, 3, 5, 8, 13, 21, 34. La répétition à très long terme nécessiterait d'atteindre des espacements de plus de 21 jours. D'un élève à l'autre cette séquence sera plus ou moins efficace. Par la mesure des résultats de rappel, on pourrait augmenter la difficulté de rappel quand l'élève a de très bons résultats en augmentant l'espacement entre les répétitions, et la réduire dans le cas inverse.

Si toutes ces conditions sont respectées, il faudra également que le sommeil des élèves soit suffisamment bon pour que la consolidation mette en évidence les éléments les plus importants à mémoriser.

L'effet du contexte émotionel est aussi à surveiller. Pour aller plus loin sur l'effet des émotions, voilà un article de l'unité Inserm V1077-EPHE-UNICAEN\ Neuropsychologie et imagerie de la mémoire humaine de Caen.

On voit alors que le bachotage repond très bien au problème qu’il tente de résoudre : Pour un délai de rétention à très court terme, des répétitions faiblement espacées sont efficaces. Aujourd’hui cette méthode donne des résultats suffisants dans une logique de rentabilité scolaire pour passer des contrôles relativement simples. L'illusion de réussite répétée de cette méthode pendant toute la scolarité pourrait-elle être responsable d’une accoutumance à la procrastination ?
En tout cas, il n’encourage certainement à planifier ses révisions.

Les élèves questionnent également l’intérêt de la mémorisation à long terme : à quoi servent les cours plus tard ? Je me rappelle m’être souvent fait expliqué (et c’est encore le cas des générations actuelles) que ça me servirait plus tard. En tant qu’adulte, la projection à long terme est chose aisée, bien que les espèces de notre planètes puissent certainement contester ce postulat. Mais qu’en est-il des élèves à qui l’on demande se préparer à des évènements encore loin de leur réalité (pour dans le même temps leur dire qu’il faut profiter de leur présent).

Une solution serait de relier les cours a l’actualité. Chaque évènement plus ou moins proche de leur réalité pourrait être expliqué dans les cours de différentes matières. Le bénéfice serait théoriquement double.

Le premier serait de les aider à donner du sens au monde qui les entoure. Comprendre notre environnement et notre place en son sein est le premier pas vers des choix informés et alors une éthique politique.

Le second serait que pour chaque nouvelle ressemblant à une actualité expliquée et comprise, un rappel serait provoqué sur le cours et l’explication. L’actualité elle-même renforcerait alors la mémorisation des éléments du cours qui font sens dans leur réalité. Ces connaissances perdureraient alors à plus long terme, et plutôt que sous une forme standardisée et sémantiquement légère, une forme subjective et assimilée.

Source

Gerbier Émilie, Koenig Olivier, « Comment les intervalles temporels entre les répétitions d’une information en influencent-ils la mémorisation ? Revue théorique des effets de pratique distribuée », L’Année psychologique, 2015/3 (Vol. 115), p. 435-462. DOI : 10.4074/S0003503315000159. URL : https://www.cairn.info/revue-l-annee-psychologique1-2015-3-page-435.htm

Le phare d'eau de nos règles, ou comment trouver son chemin dans notre fatigue sociale

Fri, 21 Feb 2020 00:00:00 GMT

Pourquoi cet article

Récemment, un ami m'expliquait que ses interactions sociales devenaient de plus en plus difficiles. C'est quelque chose que j'ai également vécu, et que j'ai tenté de comprendre. Différentes lectures m'ont permis de voir plus clair sur la perte d'énergie que ces interactions engendraient, et après avoir été accompagné par un thérapeute pour déloger de vieux mécanismes, j'arrive même à récupérer en marchant. La solitude est toujours un moment précieux pour me ressourcer, mais je ne suis plus autant drainé par une conversation, ni réfractaire à sortir en groupe. J'ai aussi à nouveau appris à exprimer mes sentiments.

Cet article est une retranscription d'une suite de messages que je lui ai envoyé très tôt un matin, d'où l'absence de dialogue. Et je les publie sur sa proposition. Certaines parties sont accompagnées de commentaires en dessous en plus foncé et italique pour apporter du contexte ou des explications. N'hésitez pas à les passer si le paragraphe commenté vous parle. Un bouton a été ajouté spécialement sur cet article à cet effet. J'espère que certaines parties vous éclaireront comme elles m'ont éclairé. Bonne lecture.

Début de la conversation

C’est très clair parce que je suis passé par là. Ça peut encore m’arriver de temps en temps mais clairement pas aux intensités que j’ai connu ces dernières années. Et il y a des choses pour lesquelles je ne m’embête plus et d’autres pour lesquelles je continue de faire des efforts. Mais dans l’ensemble, je me fatigue moins, je récupère même.

Pareil j’avais beaucoup de mal à sortir mes derniers points d’énergie pour parler avec ma femme le soir.

Mon ami me disait que la majorité de ses points (d’énergie) étaient consommés lors de son travail. Il lui restait alors très peu d'énergie, même pour les interactions les plus faciles. À la longue, la fatigue qui s'accumule fait que le moindre effort semble titanesque, et nous donne envie d'abandonner toute interaction. On n'arrive plus à s'investir émotionnellement et pour autant on subit la détresse de nos proches. Il est clair que cette solution court-termiste isole et peut endommager profondément vos relations.

Je trouve que certaines interactions demandent plus d’énergie parce qu’il y a plus à porter, autant pendant qu’en dehors de la conversation. Pendant parce qu’il faut parfois dépenser plus d’énergie pour transmettre un message sous une forme qui ne nous convient pas, et en dehors parce que nous repensons à une interaction qu’on aurait voulu voir se dérouler autrement, ou bien dont on anticipe l’effort et les conséquences.

Là où je continue d’investir souvent, c’est sur le pendant l’interaction. Mais j’ai clarifié avec moi-même ce que j’étais prêt à taire, et ce que je devais exprimer (avec des formes, mais de façon claire et directe). En revanche je fais tout pour qu’en dehors ça ne traine pas dans ma tête, que ce soit l’anticipation ou les souvenirs.

Pour le en dehors des interactions, faut enquêter avec la thérapeute pour « debugger » cet algo qui te pèse. Et pour les interactions avec les autres, faut comprendre quel overhead tu ajoutes pour transmettre tes messages ou les recevoir.

Nous sommes tous les deux dans l'informatique et certaines analogies nous facilitent la transmission d'une idée. Par "débugger cet algo" j'entends analyser notre logique personnelle pour y trouver des incohérences. Et par overhead j'entend une charge supplémentaire à la charge utile, par exemple pour dire "j'ai faim" on pourrait prendre des pincettes avec quelqu'un en reniant notre propre besoin et lui dire "est-ce que tu aurais faim ?". Je reviens plus loin sur la nature de cette charge.

Quant à la thérapeute, mon ami a récemment pris rendez-vous avec elle, ce que j'ai également fait à ce moment là. J'avais choisi un practicien en fonction de mes lectures, et à ce moment là, c'était The Satir Model. C'est un livre sur les méthodes de Virginia Satir, une psychothérapeute familiale qui a développé des méthodes humanistes et systémiques. C'est à dire que le thérapeute entre dans la relation avec l'accord des parties pour apporter un oeil extérieur sur leur système d'interaction. En somme, en interrogeant, écoutant et en observant, elle met en évidence les rapports de force et les cercles vicieux. Elle ne va pas vous dire ce qu'il est normal de faire ou penser dans une relation ou à titre personnel, car on considère que chacun est complet, unique, et fait de son mieux, mais elle travaillera le rapport entre une personne et son environnement. Le thérapeute que j'avais trouvé suivait la Gestalt-thérapie, dans la mouvance de ce que je viens de décrire et prenant ses sources dans les théories de Kurt Lewin, Carl Rogers ou encore Abraham Maslow (surtout connu pour la pyramide éponyme que le monde de l'entreprise interprète sans comprendre la profondeur et les nuances de sa théorie).

Tu remarqueras que dans les deux cas les solutions sont de ton côté :) du moins au début, ça ne veut pas dire qu’il n’y aura rien à clarifier avec d’autres.

C’est normal ce qui arrive, et ça peut arriver à tout le monde, d’autres n’iront pas jusque là mais traîneront des fardeaux qui ne les ont pas encore vidés, mais les entament progressivement.

Ces fardeaux ce sont des règles que tu as apprises.

« Quand je suis en groupe je dois me comporter de telle façon »
« Quand je suis fatigué, je dois faire ceci »
« Quand on me dit ça, je dois me protéger de telle façon »
« Si tel événement se produit, ça veut dire que j’agis mal »

Je parle beaucoup de règles où la personne subit parce que c'étais mon cas. D'autres peuvent avoir des règles différentes comme : "Quand je me sens vulnérable je dois faire des blagues à propos de tout", ou encore "Quand on expose une de mes failles, je dois blâmer quelqu'un d'autre". Une de mes craintes était d'ailleurs de trop m'exprimer, de me mettre en colère, par peur d'être violent avec d'autres, aussi violents soient-ils, parce que j'étais (et je suis toujours) convaincu qu'ils souffraient et que ma colère ne résolverait rien (ça par contre je suis désormais convaincu du contraire depuis que j'ai compris ce que me permet ma colère).

Ces règles apparaissent naturellement. C’est normal qu’elles existent, car elle nous permettent de nous adapter à notre environnement, et elles se forment très très tôt dans notre vie pour équilibrer les besoins bruts avec la réalité :
« Quand j’ai envie d’uriner, je dois attendre d’être aux toilettes »
Chez Freud et Jung la partie besoin brut est dans l’inconscient, c’est elle qui crie à travers des signes physiques quand elle ne peut plus s’exprimer à travers certaines règles qui laissent le besoin inassouvi. L’ego (oublions la teinte négative qui lui est associée pour l’instant, c’est le moi) lui est à cheval entre conscient et inconscient. C'est ici que tu as les règles qui tentent de réconcilier tes besoins avec les limites de la réalité. Et dans le conscient tu as tes pensées, ce que tu dis et parfois ce que tu fais. Mais tu as une troisième partie, le surmoi, l’idéal qu’on voudrait atteindre ou encore notre juge intérieur, le « je devrais être comme ça » ou encore "ne fait pas ca".

Heureusement que des règles s’installent, ça évite les « j’ai sommeil je vais m’endormir au milieu de la route », et heureusement qu’on a une cible à atteindre pour devenir meilleur. Tout ça nous aide à survivre et à vivre en société. Mais on comprend assez vite que l’esprit coincé entre trois parties avec leurs exigences (réalité, idéal, besoin) galère à jongler sur des règles pour tout satisfaire. T’as déjà codé un système avec autant de règles de gestion ? C’est sûr, ce sera buggé x)

Pour faire une autre analogie sur les systèmes avec plein de règles de gestion, imaginez un jeu de plateau avec un gros livre de règles. Plus vous aurez de règles dans ce livre, plus il sera difficile de prédire les impacts qu'une règle aura sur une autre. On finit facilement avec un jeu déséquilibré.

Tout n’est pas réconciliable, c’est pour ça qu’on vit mieux avec des paradoxes qu’avec des absolus. Et ces paradoxes ne sont pas nécessairement déraisonnables. Ils sont une façon que ton esprit a trouvé de réconcilier les choses.

Seulement voilà, réconcilier les choses (réalité, idéal, besoin), l’esprit le fait au cas par cas. Heureusement, c’est bien pour cette raison qu’on peut si facilement s’adapter. Et c’est grâce à ces règles qu’on s’en sort. Mais parfois, certaines règles vont persister, même quand on en a plus besoin. On continue alors à appliquer les :
« Quand je prend la parole en public, on se moque de moi, donc je dois être discret pour me protéger »
Grâce à cette règle, au collège, on ne venait plus m’embêter vu que j’étais moins visible. C’est génial, cette règle a bien fait son job. Mais quand il s’agit de défendre ses droits dans une autre situation, ou de démontrer notre légitimité sur un sujet, elle nous encombre.

Cet encombrement pèse pendant nos interactions, parce qu’on tente d’appliquer quantités de règles juste pour faire passer un message.

Mais ça pèse aussi en dehors.

Quand on ressasse, c’est parce que des règles bien cachées nous font rejouer un événement qu’on arrive pas à réconcilier.
Par exemple face à quelqu’un qui nous exprime sa douleur vis à vis de ce qu’on lui aurait fait ou dit :
« Je devrais toujours être bien vu par les autres »,
« Je devrais exprimer ma crainte »
Et on arrive pas à décider ce qu’on doit faire de l’évènement.

L’anticipation fonctionne à peu près pareil, on arrive pas à décider de ce qu’on devra faire, donc on boucle entre des règles irréconciliables, et pire, vu qu’il nous manque la réalité (vu qu’on ne peut pas prédire ce qu’il se passera) on invente. Sauf que les événements inventés déclenchent d’autres règles, et tu peux tomber dans des boucles complètement artificielles.

Pour s’en sortir, faut pouvoir éditer ces règles.

Y’a plusieurs étapes (que Weinberg décrit très bien, je pense me rappeler qu’il en parle dans Becoming a change artist, ou Becoming a technical leader)
La première c’est de conscientiser ces règles. C’est là que le thérapeute est le plus efficace. Tandis que tu seras perdu dans une boucle sans la reconnaître, elle, en oeil extérieur, pourra mettre en avant des contradictions. Une fois évidentes, faut comprendre pourquoi elles sont là. Quelle est la situation dans laquelle nous avons eu besoin d’établir cette règle ?

Gerald Weinberg est auteur de livres des domaines du conseil, de la résolution de problèmes, de la gestion d'équipe technique, de la transformation de groupes, ... Il a notamment été influencé par Virginia Satir, et c'est l'un de ses livres qui m'a poussé à creuser les pratiques de cette psychothérapeute.

Une fois au grand jour, il faut commencer par reconnaître son utilité. Y’a pas de « nan mais quel idiot, qu’est-ce que je fais avec ça »
Heureusement que cette règle était là, bravo pour avoir remédié à cette situation à l’époque

Mais maintenant voilà, qu’est-ce qui dans cette règle aujourd’hui fait que ça ne fonctionne pas ? Faut-il tout jeter ? Ou bien seulement l’améliorer ? Ou encore ajouter une règle supplémentaire ?
« je devrais exprimer ma crainte, en étant le plus clair possible sur mes intentions et sans accuser pour que la personne ne se sente pas attaquée »
« Je ne suis pas responsable des émotions des autres, quand j’ai fait de mon mieux pour ne pas les offenser ».
La meilleure et unique solution n'existe pas, on tente de réconcilier trois parties (peut-être plus ?)

Ici, "peut-être plus" inclut les personnes avec qui nous interagissons. Souvent nous aurons des règles spécifiques dans nos interactions avec chaque personne.

Puis on tente ces nouvelles règles, on analyse, on ajuste. Finalement faut peut-être dépenser un peu plus ou moins lors de la conversation pour éviter de boucler.

En plus d’avoir vécu tout ça, y’a trois bouquins qui m’ont permis de comprendre tout ça :

Becoming a change artist (ou technical leader ?) de Gerald Weinberg
Your many faces de Virginia Satir (the Satir model aussi est bon, mais je ne l’ai pas encore fini)
Maps of the mind de Charles Hampden-Turner (très bon résumé interprété de l’histoire de la psychologie, et de la sociologie, ... et autres domaines affiliés)

Ce qui est génial, c’est qu’une fois que tu comprends ça, ça ne peut que prendre la bonne direction pour toi et ton entourage :D

À la fois on devient plus tolérant avec soi-même, on est plus attentionné à nos propres besoin, et on est aussi plus tolérants envers les autres

En somme, tu te feras du bien, et ça diffusera dans ton entourage :)

Fin du monologue et un peu de rab sur la colère

Si je reviens sur la colère dont je parlais en commentaire, je disais qu'elle m'effrayait parce que j'avais peur de blesser, même ceux qui seraient violents avec moi parce que j'étais persuadé qu'ils étaient eux-même blessés. Je suis toujours convaincu de leurs douleurs et difficultés. Par exemple le blâme est un mécanisme de compensation externe à une situation difficile à réconcilier en interne.

En revanche j'ai complètement changé de posture vis à vis de ma colère. Avant je pensais m'être mis en colère 2 fois en 3 ans. Deux explosions violentes et blessantes pour mes interlocuteurs parce qu'ils avaient dépassés des limites et que j'avais l'énergie de les défendre. Mais en discutant avec mon thérapeute, j'ai réalisé que ma colère se faisait sentir bien plus souvent que ca, parfois plusieurs fois par semaines, mais à plus faible intensité. Si faible que j'interprétais cela que comme une gêne répétitive à laquelle je m'étais habitué dans mes interactions. Je ne l'exprimais donc presque pas. Sauf que lorsqu'on ne l'écoute pas un besoin aussi récurent de respect, soit on implose, soit on explose. Deux fois en trois ans c'est peu, donc la plupart du temps j'implosais. Ca se manifeste par des burn-outs, des dépressions, des choses qui ne touchent que nous donc, et n'agissent pas sur ce cri interne qui demande à être respecté par notre interlocuteur. Je pouvais ressentir cette gêne par exemple lorsqu'on me demandait (sans vraiment me demander) si je pouvais prendre en charge un énième chose et que je n'osais pas refuser. Ou bien encore lorsqu'on me disait que mon boulot n'était pas suffisamment bon (sans forcément d'arguments, mais j'étais une éponge vis à vis de ces commentaires, et mon surmoi s'en alimentait à coeur joie).

Alors quoi, ai-je explosé pour réclamer mon dû ? Non. Ai-je fais sentir à la personne qu'elle était responsable de ma colère ? Je n'espère pas. Mais je ne me suis pas tû pour autant. La méthode est "simplement" d'expliquer pourquoi nous n'accepterons pas une situation, en disant très clairement "je ne veux pas" ou "non". Si on expose clairement notre limite, et qu'on n'accuse pas la personne en face de la franchir, le plus souvent les gens entendront simplement qu'ils devront trouver une autre solution, ou bien ils ne se sentiront simplement pas visé. Dans les cas où la personne le prendrait mal, vous aurez fait au mieux pour ne pas blâmer. Peut être vous exprimera-t-elle une limite que vous pourrez alors respecter. Mais vous n'êtes pas responsables de ses conflits internes.

Cacher les commentaires

Remplacer SCSS par PostCSS, sus à l'usine à gaz

Sat, 18 Apr 2020 00:00:00 GMT

Pourquoi cet article

J'utilise peu de fonctionnalités de scss, même pour des projets de grande taille. Je trouve que le css scopé ou a minima les imports suffisent à organiser les feuilles de style. Parmis les fonctionnalités non disponibles dans le CSS natif et qui me servent souvent, il y a les variables (e.g. $button-color=#eeeeee) et les styles imbriqués. C'est vraiment sous exploiter scss.

En fouillant sur la façon de porter mon css sur des navigateurs qui datent, je suis tombé sur PostCSS. PostCSS transforme le code CSS incompatible avec du Javascript. C'est tout. Et si on en veut plus, on ajoute des plugins. Très léger, extensible, et déjà bien fourni par sa communauté, c'était l'outil idéal pour moi. Et si comme moi vous utilisez peu de fonctionnalités SCSS, porter le code ne demandera que d'ajouter une poignée de plugins qui resteront plus légers que d'utiliser node-sass. Pour comparaison, mes fichiers sont près de deux fois moins lourds avec PostCSS qu'avec node-sass, et je gagne une poignée de secondes au temps de build.

Au passage, pour ceux qui utilisent Vue, sachez que PostCSS est déjà embarqué notamment pour permettre d'utiliser le mot clé scoped qui isole les feuilles de style entre composant. Vous pouvez donc déjà tirer parti de sa puissance en lui ajoutant des plugins.

Au revoir npm rebuild node-sass.

Webpack et PostCSS

J'utilise Webpack sur mes projets, je ne fournirai donc pas d'exemple avec yarn ou autre, mais utiliser PostCSS devrait être très simple quel que soit l'outil.

Voilà ce dont vous avez besoin

Installer les paquets de PostCSS et des plugins qui vous intéressent

La base, les deux premiers paquets sont certainement déjà présents si vous utilisiez scss :

npm install --save style-loader css-loader postcss-loader

Pour ne plus s'embêter avec les préfixes spécifiques à chaque navigateur :

npm install --save autoprefixer

Pour pouvoir importer des fichiers css dans d'autres fichiers css :

npm install --save postcss-easy-import

Pour permettre l'imbrication de classes :

npm install --save postcss-nested

Pour pouvoir utiliser les dernières fonctionnalités CSS mais les rendre compatibles avec les anciens navigateurs :

npm install --save postcss-preset-env

Pour pouvoir utiliser des variables :

npm install --save postcss-simple-vars

Configuration de PostCSS

Vous aurez besoin de renseigner les plugins que vous voulez appliquer ainsi que leur configuration. Pour cela j'utilise un fichier postcss.config.js. Notez que les plugins seront appliqués dans l'ordre dans lequel ils seront renseignés ici.

module.exports = {
    plugins: {
        'postcss-easy-import': {},
        'postcss-nested': {},
        'postcss-simple-vars': {},
        'autoprefixer': {},
        'postcss-preset-env': {},
    },
};

J'utilise la configuration par défaut pour chacun. Mais vous pourriez par exemple changer les versions de navigateur supportées par votre site :

...
'postcss-preset-env': { browsers: 'last 2 versions' },
...

Règles Webpack

Pour que PostCSS traite vos fichiers, il faut qu'il sélectionne les fichiers avec l'extension que vous utilisez (e.g. .css), et qu'il applique un ensemble de loaders.

module: {
    rules: [
        ... d'autres règles ...
        {
            test: /\.css$/,
            use: [{
                loader: 'style-loader',
            }, {
                loader: 'css-loader',
                options: {
                    importLoaders: 1,
                }
            }, {
                loader: 'postcss-loader',
            }],
        },
    ]
}

C'est tout.

D'autres idées de plugin

CSS Modules, La fin du style global, particulièrement utile quand un plugin d’import de fichiers css
postcss-easy-import pour pouvoir importer des fichiers css dans d'autres fichiers css
postcss-increase-text-sizes, pour implémenter une fonctionnalité qui change la taille de texte de l'écran (i.e. rendre un site plus accessible)
CSSNano pour minifier votre css et soulager la planète
Et bien plus

Et rien à voir ou presque :

Stylelint, pour que toutes vos définitions de style se ressemblent, fourni avec --fix (dans IntelliJ il vous souligne le non respect des règles)
normalize.css, pour alléger l'essentiel des styles par défaut et pouvoir styliser ses éléments sans se battre avec les styles de chaque navigateur

Atteindre l'écoute active en groupe

Sat, 21 May 2022 00:00:00 GMT

Pourquoi cet article

En ce moment, j'anime des ateliers d'EventStorming pour l'équipe d'un client. J'ai été frappé par le manque d'écoute, et frustré par les conséquences : confusion dans le vocabulaire, trous dans le process, déformation du métier au service de la tech, ... Tout ce que l'EventStorming devrait, si ce n'est éviter, minimiser.

Ce n'est pas l'unique type d'atelier qui requiert de l'écoute. Et lorsqu'on parle d'échange, voire plus généralement de travail collectif, l'écoute devrait aller de soi : on échange rien si on ne peut pas recevoir.

Je voudrais alors lister les signaux qui peuvent indiquer que les membres d'une équipe ne s'écoutent pas, et proposer quelques aides pour les surmonter.

De quoi on parle, et que faire

Certains de ces signaux peuvent être visibles chez les autres. D'autres seront plutôt internes à chacun. Et parfois, même pour soi, il sera difficile de les détecter.

Parler en même temps, et discussions en parallèle

Il est possible que dans certains groupes, entre personalités fortes, on ai besoin d'interrompre les gens. Il y aura alors un recouvrement de quelques brèves secondes, mais ça peut faire partie d'un protocole implicite, et qui ne frustre pas les gens. Il arrive en revanche que ce recouvrement soit plus long, voire même que la personne qui s'exprimait ignore une autre qui a voulu prendre la parole, et l'ignore au point de ne pas revenir vers elle. Dans ce cas, l'idée est imposée au groupe. Cela ne signifie pas nécessairement qu'il n'y a que la personne qui s'impose qui n'écoute pas, c'est peut être une conséquence du fait qu'elle n'est pas écoutée. La personne va alors jouer le jeu du groupe, car l'écoute n'est pas dans cette culture.

Pas aussi violent que le signal précédent, les discussions simultanées impliquent que, dans un groupe, plusieurs informations peuvent circuler sans que tout le monde soit au courant. Cela m'évoque un phénomène pouvant se produire dans un système distribué que l'on appelle un split-brain. Quand un split-brain se produit, des échanges à propos d'un même sujet vont avoir lieu avec des parties qui ne communiquent pas entre elles. Il en résulte que plusieurs "vérités" à propos d'un même sujet vont circuler dans ce système, à l'image de ce qu'évoque le split-brain : comme si deux parties d'un même cerveau ne communiquaient plus.
Dans le cas d'un groupe, c'est comme si, entre elles, des personnes décidaient de la définition d'un terme tandis que d'autres personnes du même groupe décident d'une autre définition pour ce terme. Dans certains ateliers, ce phénomène est provoqué, et par la suite la structure de l'atelier mène à une "réconciliation" à propos de cette vérité.
Justement dans le cas de l'EventStorming, les premiers instants durant lesquels les participants posent les premiers évènements vont se dérouler les uns plus ou moins indépendamment des autres. On profite volontairement de cette dispersion pour couvrir un maximum de cas. En revanche par la suite, on provoque une convergence et il faut alors que chacun partage les informations.
Mais quand cela se produit sans ce protocole de réconciliation, comme plus tard dans les ateliers d'EventStorming, les gens continueront leurs discussions en pensant parler de la même chose, alors qu'en réalité ce n'est pas le cas, quand un terme est évoqué chacun pense à une chose différente. Cela implique également une perte de temps pour rattraper le contexte qui n'a pas été partagé lorsqu'on se rend finalement compte du quiproquo.

Dans le cas des discussions parallèles, si les gens sont conscients du problème, le "remède" peut être simple. Une façon amusante peut être de proposer un moyen d'interruption qui attire l'attention comme une "boite à meuh". Une autre technique moins bruyante est d'instaurer un protocole où lorsque quelqu'un lève la main et se tait, les autres doivent aussi la lever et se taire.

Dans le cas où la dynamique d'équipe ne le permet pas, et également pour s'occuper des prises de paroles imposées, quelqu'un peut être désigné, à tour de rôle, pour attribuer la parole lorsque cela devient chaotique. Cette personne devra alors faciliter les échanges, créer l'espace pour que chacun puisse s'exprimer tour à tour, et être attentive à ne pas en profiter pour pousser ses propres idées. Elle sera en revanche autorisée à interrompre les autres pour redistribuer la parole équitablement.

Et si la facilitation par un membre de l'équipe est trop complexe à gérer, il faut probablement mobiliser une personne dont c'est le métier pour faciliter le travail de groupe, et autonomiser l'équipe sur ses protocoles d'échange.

Penser à ce qu'on dira ensuite au lieu d'écouter la personne

Ce signal est plus difficile à observer chez les autres, mais on peut parfois deviner qu'il se produit. Quand quelqu'un qui n'écoute pas reprend la parole, la suite peut ressembler à "J'entends mais ...", ou bien elle peut commenter, avec une phrase superficielle, ce qui a été dit pour basculer sans transition à un sujet très différent. Parfois on verra même l'impatience de la personne se manifester dans ses gestes car elle est déjà dans la réplique d'après. Cela ressemble plus à du silence par politesse, mais pas de l'écoute. Et il y a fort à parier que si cette personne n'écoute pas, ses interlocuteurs finiront par ne plus écouter eux non plus.

La meilleure chose à faire dans ces cas là, c'est de créer les conditions pour l'écoute. Si on suit la logique que l'écoute des autres vient en écoutant l'autre, il faut alors écouter activement la personne qui tente d'imposer son idée. C'est à dire de poser un maximum de questions pour bien saisir toute la portée de ce qui est dit, et prouver, notamment par la reformulation, que l'on a bien entendu ce qui a été dit. Ensuite, avant de proposer son idée, il faut basculer vers les idées des autres en suivant le même procédé, et démontrer par l'exemple le protocole à suivre pour échanger. Les gens qui n'écoutaient pas finissent alors par reproduire le comportement, par mimétisme, et persistent en réalisant qu'il n'est pas à leur désavantage, et en sentant qu'elle sont écoutées. La dynamique du groupe peut alors progressivement changer, et après des rappels par l'exemple lors des sessions suivantes, le protocole finit par entrer dans la culture du groupe. Il y aura très probablement récidive car ces personnes sont certainement dans d'autres groupes sociaux où les idées sont imposées, et dans ce cas il faudra persister jusqu'à ce que chacun intègre que ce protocole est propre à ce groupe.

Quand il s'agit de soi-même ce n'est pas plus simple, surtout quand on n'a jamais fait attention à ce phénomène auparavant. On est convaincu que notre méthode/idée est la meilleure, et peut-être à raison, on veut alors absolument que l'équipe suive cette direction. Cependant, sans écoute, on se prive progressivement l'écoute des autres, et les prochains sujets ne seront pas plus simples à traiter car d'une part on ne bénéficiera pas des idées intéressantes des autres, mais ils ne bénéficieront pas non plus des nôtres vu qu'ils n'écouteront plus. En somme, on accumule une dette de fermeture d'esprit du groupe en forçant les choses sans considérer son interlocuteur.

Se dire qu'on doit absolument écouter alors qu'on est la personne qui impose revient à une injection assez violente envers soi : au final, aussi paradoxal que cela puisse paraitre, on écoute pas les autres car on ne s'écoute pas soi-même. Au contraire donc il faut chercher à comprendre ce qui nous met dans cette position : est-ce une peur ? une volonté de bien faire ? voit-on quelque chose venir que les autres ne verraient pas ? a-t-on très envie de vivre la mise en place d'une idée ? Une fois que l'on a identifié ce qui nous motive à pousser une solution, on peut se tourner vers les autres en soumettant notre problème. On leur demande alors de nous rassurer sur ces points si l'équipe venait à prendre une direction différente de celle que nous imaginions. Si ces inquiétudes étaient résolues avec leur solution, quelle justification resterait-il pour la nôtre ? De la même façon, par l'exemple vous montrerez que c'est acceptable d'abandonner ses idées, et que ça n'implique pas pour autant de taire les problèmes que l'on a identifié.

Conclusion

Lorsque chaque personne est consciente des problèmes d'échange, mettre en place un protocole reste la solution la plus simple.
Mais lorsque ce n'est pas le cas, il faut se rappeler que l'écoute vient avec l'écoute, c'est un effort constant, mais sur le long terme il reste moins couteux et plus riche que de devoir imposer ses idées constamment. De fait, plutôt que de faire l'injonction à plus d'écoute, il est nécessaire de commencer par s'écouter soi-même, puis de donner l'exemple sur ce qui nous permet d'être entendu : partager les problèmes qui nous préoccupent, les questions, plutôt que les solutions.

J'éditerai peut être à nouveau ce post si je détecte de nouveaux types de signaux, ou si je découvre des méthodes plus efficace pour rétablir l'écoute.

Engagement de sprint et écarts de performance

Sat, 18 Feb 2023 00:00:00 GMT

Pourquoi cet article

Récemment un ami m'expliquait qu'il avait été surpris d'une remarque d'un PO. Ce dernier était fier que l’équipe ai sorti 82% des points engagés car ça n'était encore jamais arrivé (d'ordinaire ça moyenne à 55% de l'engagement). Sa première remarque a été que l'équipe technique ne sait probablement pas faire d'estimations. Rien ne l'exclu pour le moment, mais c'est un réflexe que j'ai déjà vu/entendu, et qui, je trouve, nous empêche de voir plus loin que la responsabilité des devs. Sans pouvoir rencontrer le PO de suite, on s'est donc pris au jeu des hypothèses et des zones à explorer, et plutôt que de mettre un wall of text, j'ai pondu mes idées dans un doc que je restitue quasi tel quel ici, modulo des détails qui complexifieraient la compréhension. La forme sera donc celle que j'emploie par chat d'ordinaire.

Le contenu

Au sujet des mauvaises estimations je pense que c’est questionnable : si la moyenne de 55% n’a pas un écart-type de malade (genre 20 points?) alors le réalisé est plutôt stable, ce qui signifie nécessairement que l’estimation de l’équipe rend le périmètre réalisé en fin d’itération prédictible : 55% de l’engagement. Et je pense qu’on en demande pas plus que d’être prédictible à des estimations. Si les estimations sont mauvaises, donc avec un écart-type de ouf, ça veut certes dire qu’il y a quelque chose à faire côté dev, mais ce serait surprenant de la part d’une équipe qui existe depuis un moment, et probablement aussi que le PO a un problème de découpe de ses tickets (plus c’est fin, plus c’est simple à estimer, plus c’est gros, plus c’est faux, il saboterait donc sa capacité à prédire)

En supposant des estimation "justes", pour moi la toute première question serait : si cela fait un moment qu’ils font en moyenne 55% de ce qu’ils estiment, est-ce parce qu’à chaque sprint après avoir révisé la capacité de l’équipe ils font 55% de moins que la nouvelle estimation (donc en gros c’est méchamment dégressif et donc grave), ou est-ce parce qu’ils ne prennent pas en compte la capacité de l’équipe mais l’estimation d’un backlog qui ne bouge pas par rapport à une cible qui ne bouge probablement pas (auquel cas faire des prédictions sur ce qu’ils auront est plutôt compliqué d’une part, mais d’autres part ça veut dire qu’il n’y a pas révision des solutions (peut-être même pas de brainstorming avec les métiers pour savoir comment atteindre une date avec un périmètre fonctionnel soutenable et acceptable ?))

Pourquoi c’est intéressant : si le PO est fier que l’équipe ai pu faire 82% je prend l’hypothèse que c’est parce que la capacité de l’équipe était de 55% de ce qui est habituellement estimé, et donc que la capacité de l’équipe n’est pas révisée. Hypothèse corollaire : le PO compte plus sur un effort redoublé de l’équipe de dev pour sortir des tickets à la date malgré son retard, plutôt que sur un dialogue avec les devs et le métier pour atteindre la date avec des fonctionnalités acceptables pour le client et soutenable pour l’équipe.

En se projetant sur les différents cas : Si la capacité d’équipe n’est pas révisée, peut être que le périmètre ne l’est pas.

S’il ne l’est pas, et qu’on n'atteint pas les engagements, comment expliquera-t-on au client qu’il n’a pas tout ce qui était promis ? Potentiellement culture du blame en cours ou à venir car la pression et les responsabilités sont portées uniquement par les devs, pas de remise en cause du process du reste de la boite (qui participe aussi au delivery de plus ou moins loin, que ce soit le PO, les commerciaux, d’autres experts, designers, …)
S’il ne l’est pas, et qu’on atteint les engagements, après avoir fait 55% de l’estimation pendant un moment, comment l’équipe a pu réaliser cet exploit ? Quels sacrifices ont eu lieu, et quand faudra-t-il les payer ? Est-ce pris en compte dans les itérations suivantes ? Le métier est-il au courant du prix payé pour atteindre cette cible ? (j’espère que le devs partagent ce genre d’infos, autrement ça veut dire qu’ils y a des mines dans la roadmap, que des infos stratégiques cruciales ne sont pas partagées)
Si la capacité de l’équipe est constamment révisée
Si on atteint les engagements, alors ça veut dire que l’équipe fait de moins en moins à chaque sprint, et qu’il y a un très bon dialogue avec les clients pour réviser les attentes ; ou bien que la roadmap est remplie de trucs inutiles pour le jalon, et que l’équipe a fini par se focus uniquement là dessus
Si on ne les atteint pas, alors quelque chose dégrade progressivement l’écosystème technique, l’équipe est en train de s’enliser

Si l’écart de 82% est aussi notable, c’est une exception, et pour moi ça devrait être autant scruté/investigué qu’un incident car hors norme. Quels changements dans les pratiques ? La nature des tickets ? Il y a peut être des choses à en tirer pour reproduire le résultat, ou peut être que c’est impossible, mais la question c’est qu’est-ce qui a changé dans le processus, est-ce un trou ? (quelque chose de pas fait / ignoré) une amélioration ? Autre chose ? Exemple qui parait débile mais c’est du déjà vu, on se met à compter les bugs, ou tout autre type de ticket qui n’a rien à voir avec nos engagements avec le client et qu’on ne comptait pas jusque là

Avec les 55% t’as aussi évoqué gestion du temps. Ça peut vouloir dire comme tu le soulignais qu’ils le gèrent mal, donc par exemple qu’ils ne timeboxent pas ou mal leurs expérimentations (test d’implem d’une story sur laquelle ils se sont engagés) et c’est curieux dans ce cas s’ils arrivent à reproduire régulièrement 55% avec un problème aussi variable, mais là va falloir leur parler pour savoir. C’est aussi possible qu’ils passent effectivement le temps estimé sur leurs tickets, mais qu’ils ne font pas tous leurs tickets car d’autres tâches que celles planifiées leur mange leur capacité. En gros faut partir à la chasse du travail non planifié, et la première que je regarderai dans ce cas ce sont les bugs, les incidents, le support (en ont-ils ?), et de voir les métriques qui correspondent (quel Mean Time to Restore, quel Change Failure Rate, voire quel Lead Time aussi, quelle tendance de nombre de tickets de bug, nombre d’occurence d’incident (et faux positifs)). Et selon ce qui est observé là y’a tellement de possibilités que je ne vais pas tenter différentes hypothèses, faudra qu’on reparle.

La chute

Plusieurs hypothèses qui ne concernaient pas les devs étaient pas loin d'être vraies, et posent pas mal de questions sur la maintenabilité de ce projet et la soutenabilité des efforts sur le long terme. Mais la dure vérité sur cette performance exceptionnelle, est que l'équipe a changé la durée de son sprint. Donc pour le même "volume" de tâches que d'ordinaire et en plus de temps, l'équipe a atteint 82% de son engagement. Elle n'a simplement pas pris en compte le changement de référentiel.

Liens du 24 février 2023

Fri, 24 Feb 2023 00:00:00 GMT

Pourquoi cet article

Depuis un bon moment maintenant je suis le partage de lien et le blog d'un ancien collègue, et j'y trouve beaucoup de choses qui me font bouillonner le cerveau.
Récemment un autre collègue redécouvrait son blog, et me montrait la quantité de lien qui lui-même partageait.
Je me suis dis que j'allais tenter d'en faire de même.

Les liens

"Conway’s Law Doesn’t Apply to Rigid Designs"

While systems do mimic their organisations’ structure, changing the organisation doesn’t seem to have the same effect. That’s because we’re not accounting for the properties of the system under design itself.

"The Viable System Model" - Stafford Beer

Anthony Stafford Beer, better known as Stafford Beer, was a pioneering British consultant and leadership theorist who is best known for his theories regarding management cybernetics, and how to apply them to human organisations. […] The effect principle was that organisations should maximise the freedom of their participants, within all practical constraints of the requirement of them to fulfil their purpose. He blended the field of cybernetics with that of management in order to try and formulate organisational systems which ticked these criteria.

"Déclin des insectes : battons-nous pour que les générations futures ne trouvent pas ça « normal » "

Dans le milieu scientifique, on admet désormais que nous souffrons tous du « syndrome de la référence changeante », phénomène qui nous fait accepter comme normal le monde dans lequel nous grandissons, même s’il est très différent de celui dans lequel nos parents ont grandi. Tout tend à prouver que nous, humains, sommes également assez nuls pour détecter un changement graduel qui s’effectue au cours de notre vie.

"Real-world Engineering Challenges #8: Breaking up a Monolith"

Specifically, we’re diving into a massive migration project by Khan Academy, involving moving one million lines of Python code and splitting them across more than 40 services, mostly in Go, as part of a migration that took 3.5 years and involved around 100 software engineers.

Liens du 3 mars 2023

Fri, 03 Mar 2023 00:00:00 GMT

"Meaningful Metrics"

Over the years, I can remember working with exactly one organization that used my idea of an excellent approach to software engineering metrics. Their approach was based on several points.

"Modularizing React Applications with Established UI Patterns"

The benefits of the new structure

Having a class encapsulates all the logic around a payment method. It’s a domain object and doesn’t have any UI-related information. So testing and potentially modifying logic here is much easier than when embedded in a view.
The new extracted component PaymentMethods is a pure function and only depends on a domain object array, which makes it super easy to test and reuse elsewhere. We might need to pass in a onSelect callback to it, but even in that case, it’s a pure function and doesn’t have to touch any external states.
Each part of the feature is clear. If a new requirement comes, we can navigate to the right place without reading all the code.
I have to make the example in this article sufficiently complex so that many patterns can be extracted. All these patterns and principles are there to help simplify our code's modifications.

"Exploitation des données : un changement de contrat social à bas bruit"

La logique du contrat social (notamment depuis la révolution industrielle puis le développement de l’État providence au XXe siècle) était une logique assurantielle. Ignorant le futur, les individus avaient intérêt à s’assurer collectivement contre le risque. Désormais, le développement de l’analyse prédictive rend caduque cette version du contrat. Les offres d’assurances peuvent être adaptées aux risques précis que chacun encourt.
Les géants du numérique connaissent nos préférences, nos opinions, nos envies et nous enferment dans ce que l’essayiste Eli Pariser nomme une « bulle de filtre ». Le contenu en accord avec nos idées y est surreprésenté et les avis contradictoires y font défaut, augmentant alors la diffusion des fake news – à plus fort potentiel de réactions et donc de diffusion. Nous partageons dès lors de moins en moins de vérités et d’expériences communes, pourtant nécessaires au fonctionnement de la démocratie.

En analysant nos données pour prédire notre comportement, le capitalisme devient un « capitalisme de surveillance » pour reprendre les mots de l’universitaire Shoshana Zuboff. Pour ces entreprises, les individus ne sont plus des clients mais des produits pour les annonceurs. Le philosophe Bernard Stiegler explique ainsi que les individus se sont transformés en « fournisseurs de data ». Déjà individualisés, ils sont en outre désindividués : leurs données permettent de les déposséder de leur volonté.

"Startup Decoupling & Reckoning"

During the last few years low interest rates and money printing led to a funding bubble in private technology. Many startups received pre-emptive extra “free rounds” and hired teams much larger then their stage or progress merited. In parallel, abundant money and secondaries meant companies that should have shut down or sold kept going (indeed - this was a pre-COVID phenomenon from ~2017 or 2018 on). There was always another round or extension to keep companies without real product-market fit going. Or founders sold secondary stock in multiple rounds instead of selling a company that wasn’t really working.
These trends have resulted in an overhang of companies that either (1) lived without product market fit and survived well past their natural expiration point, or (2) hired way ahead of progress and burned large sums with high valuations and now are stuck with little progress per dollar and a large preference stack.

Liens du 10 mars 2023

Fri, 10 Mar 2023 00:00:00 GMT

"Whether architects must code or not has been much debated. Why not try debugging?"

Why is it so important for architects to be connected to the engine room? In short, to validate (or invalidate) their assumptions. Architects make decision based on mental models and heuristics. However, the systems we deal with evolve and change rapidly, forcing us to revisit our past assumptions. For example, many architects still aim to eliminate any duplication in their systems. However, modern development, testing, and automation approaches have made it much easier for us to handle duplication while Economies of Speed highlight the cost of de-duplication. That’s why many organizations now tolerate duplication and some even favor it (consider the famous Amazon “2 > 0” mantra).

Visiting the engine room keeps architects from the proverbial ivory tower: making decisions and passing them down via a one-way command-and-control setup, ignoring downstream costs and challenges. In the past, assumptions and heuristics held longer thanks to slower evolution of the underlying technologies, allowing architects to get away with some amount of ivory tower-ness. At the current pace of technical evolution and the rate at which disruptive technologies arrive, not visiting the engine room regularly would be considered gross negligence for architects.

"OpenAI Is Now Everything It Promised Not to Be: Corporate, Closed-Source, and For-Profit"

“Y'all keep telling us AGI is around the corner but can't even have a single consistent definition of it on your own damn website,” tweeted Timnit Gebru, a computer scientist who was fired from Google for publishing a groundbreaking paper about the risks of large language models, which includes its dangerous biases and the potential to deceive people with them.

Emily M. Bender, a professor of linguistics at the University of Washington and the co-author of that paper, tweeted: “They don't want to address actual problems in the actual world (which would require ceding power). They want to believe themselves gods who can not only create a ‘superintelligence’ but have the beneficence to do so in a way that is ‘aligned’ with humanity.”

"Beyond Blaming"

To make matters worse, unless we manage well, tougher projects tend to dimish congruence–because stress tends to rise when the expectation of quality rises. We are not always utterly logical creatures, but have feelings as well as thoughts in response to tougher assignments. When these inner feelings are strong enough, they translate into characteristic styles of coping with the stress. If our characteristic style is incongruent, communications become less effective and the job becomes even more difficult, creating a viscious cycle.

Congruence, of course, is but one of the factors in effective communication–other factors include such things as timeliness, memory, proper audience, and accuracy of data. But without congruence, your efforts to improve these more “logical” factors will always be seriously undermined, along with your ability to build bigger, more complex, or more reliable systems.

"SaaS startups will have to care about productivity again"

When the money flows freely, and there's a strong cachet to having tons of open positions, you can be forgiven to think that the individual productivity on a product team just doesn't matter. So much time is spent coordinating the work anyway. Who cares if the stack you're using takes twice the number of people to ship meaningful updates? You can just hire four times as many heads!

Those days seem to be over, at least for most SaaS startups. Entrepreneurs everywhere are suddenly having to count each hire as a cost rather than a trophy. Getting to profitability is no longer a distant, post-IPO nice-to-have, but a short-term necessity for survival. But how to do that without cutting off the legs of the product team? By using better tools and techniques, that's how.

I've been talking to a lot of SaaS entrepreneurs lately. Here are the three pieces of advice that I've given them all

Liens du 17 mars 2023

Fri, 17 Mar 2023 00:00:00 GMT

Quantifying Technical Debt

That’s called churn—losing developers who know your product and replacing them with developers who don’t know your product. This is a massive source of maintenance load, because it causes context loss: when all the knowledge that the leaving developer had, but didn’t document, effectively evaporates. This is where abandoned houses come from, and this is one of the reasons that losing a dev can realistically cost the organization, all told, several times the outgoing dev’s annual salary. There’s a way to regenerate lost context, but it’s expensive. We’ll get there later.

Dans cet article d'une série de trois, Chelsea Troy renome la "technical debt" en "maintenance load" et montre en quoi cette perspective permet de mieux qualifier ce qui gêne les développements. Sans même lire les deux suivants, rien qu'à travers cette nouvelle notion, on a déjà une bonne idée de la façon on pourrait prioriser et traiter ces freins.

I resigned from my position as an executive consultant for VR with Meta - John Carmack

We have a ridiculous amount of people and resources, but we constantly self-sabotage and squander effort. There is no way to sugar coat this; I think our organization is operating at half the effectiveness that would make me happy. Some may scoff and contend we are doing just fine, but others will laugh and say “Half? Ha! I’m at quarter efficiency!” It has been a struggle for me. I have a voice at the highest levels here, so it feels like I should be able to move things, but I’m evidently not persuasive enough. A good fraction of the things I complain about eventually turn my way after a year or two passes and evidence piles up, but I have never been able to kill stupid things before they cause damage, or set a direction and have a team actually stick to it. I think my influence at the margins has been positive, but it has never been a prime mover.

Dans cette courte annonce, John Carmack (Wolfenstein 3D, Quake, Rage, ...) explique les raisons qui l'ont poussé à quitter Meta.

Tool: Try Google’s Manager Feedback Survey

Google gathers feedback from employees on their managers through a semi-annual Manager Feedback Survey. Googlers answer confidentially and managers receive a report of anonymized, aggregated feedback if they get at least three survey responses, to preserve anonymity. Reports used to require more responses to ensure anonymity and avoid manager retaliation but the People Operations team didn't see much of this behavior. By reducing the threshold for reporting to three, far more managers of smaller teams could benefit from the feedback.

Une courte page sur le formulaire qu'utilise Google pour que les employés évaluent les compétences de leur manager. J'ai tenté d'utiliser ce formulaire avec mes managés, mais dans une boite de conseil, où les managers de carrière ne sont pas les managers opérationnels, de nombreuses questions doivent être ignorées ou détournées pour en retirer des infos. Je pense toutefois que c'est une bonne inspiration.

Why Tech Companies Are Bad

This is not an accident. It’s an inevitability. Not all Bad tech companies are successful, but almost all successful tech companies are Bad.
[...]
What you can know in advance, is that any startup that survives the maze found the Fastest Survivable Path.
[...]
Winning startups operate in grey areas until they’re white, with a culture just bad enough not to kill them, and figure out the business model later. They take the fastest, riskiest path that actually works. They are the survivors of the Fastest Survivable Path.

Dans ce court article, Alex Crompton explique pourquoi, selon lui, les boites tech doivent prendre des risques en termes culturels, légaux, techniques, ... pour atteindre leur marché cible. Sur l'aspect technique, ça m'a rappelé ce court article "You can always go faster" qui parle de quand utiliser la stratégie "move fast and break things" de Facebook.

Liens du 24 mars 2023

Fri, 24 Mar 2023 00:00:00 GMT

Repeat yourself, do more than one thing, and rewrite everything

Almost every web application leans heavily on an operating system, a database, and a variety of other lumps of code to get the job done. A modern website reuses millions of lines of code without even trying. Unfortunately, programmers love to avoid repetition, and “Don’t Repeat Yourself” turns into “Always Use an Abstraction”.

By an abstraction, I mean two interlinked things: a idea we can think and reason about, and the way in which we model it inside our programming languages. Abstractions are way of repeating yourself, so that you can change multiple parts of your program in one place. Abstractions allow you to manage cross-cutting changes across your system, or sharing behaviors within it.
The problem with always using an abstraction is that you’re preemptively guessing which parts of the codebase need to change together. “Don’t Repeat Yourself” will lead to a rigid, tightly coupled mess of code. Repeating yourself is the best way to discover which abstractions, if any, you actually need.
As Sandi Metz put it, “duplication is far cheaper than the wrong abstraction”.

Pragmatisme dans l’usage d’adages de développement. Must read. Ça m’a permis de trouver des mots pour des mauvais usages courants de principes comme DRY.

Cloudflare considered harmful

You would think that this last point might make Cloudflare realise that trying to stop comment spam at the CDN level is a futile idea and can only result in breaking HTTP, but no. What Cloudflare is trying to do here is a fundamentally broken practice (in fact, the whole premise of “web application firewalls” is fundamentally broken, see below) because Cloudflare is not in a position to understand the semantic meaning of HTTP traffic and is definitely not in a position to rearchitect a site operator's web application so that it understands why its own AJAX requests are randomly being denied.

In other words, since CAPTCHAs are discriminatory to robots as discussed above, Cloudflare's service is unwittingly discriminatory to the JavaScript of the very websites it serves, breaking them. Cloudflare's response to this appears to be to CAPTCHA the entire website up-front on the off chance someone might want to post a comment, though even this doesn't always work; I have definitely encountered websites which didn't do so and which had broken AJAX functionality due to the subsequent AJAX-triggered requests being denied by Cloudflare, a condition the JS code was not designed to handle (nor would there be any sane way for it to handle it anyway).

L’extrait en dit déjà pas mal. Le design de Cloudflare est contre-intuitif, et potentiellement nuisible pour les sites qu’il sert.

Managing Nerds

The bitter nerd. Another default opening position for the nerd is bitterness — the curmudgeon. Your triage: Why can’t he be a team player? There are chronically negative nerds out there, but in my experience with nerd management, it’s more often the case the nerd is bitter because they’ve seen this situation before four times and it’s played out exactly the same way. Each time:

Whenever management feels they’re out of touch, we all get shuttled off to an offsite where we spend two days talking too much and not acting enough.

Nerds aren’t typically bitter; they’re just well informed. Snark from nerds is a leading indicator that I’m wasting their time and when I find it, I ask questions until I understand the inefficiency so I can change it or explain it.

Un article plein d’humour, qui modélise des types de comportements de techos et donne quelques tips de management. Je m’y suis parfois reconnu …

The Cost of Cloud, a Trillion Dollar Paradox

Now, there is a growing awareness of the long-term cost implications of cloud. As the cost of cloud starts to contribute significantly to the total cost of revenue (COR) or cost of goods sold (COGS), some companies have taken the dramatic step of “repatriating” the majority of workloads (as in the example of Dropbox) or in other cases adopting a hybrid approach (as with CrowdStrike and Zscaler). Those who have done this have reported significant cost savings: In 2017, Dropbox detailed in its S-1 a whopping $75M in cumulative savings over the two years prior to IPO due to their infrastructure optimization overhaul, the majority of which entailed repatriating workloads from public cloud.

Yet most companies find it hard to justify moving workloads off the cloud given the sheer magnitude of such efforts, and quite frankly the dominant, somewhat singular, industry narrative that “cloud is great”. (It is, but we need to consider the broader impact, too.) Because when evaluated relative to the scale of potentially lost market capitalization — which we present in this post — the calculus changes. As growth (often) slows with scale, near term efficiency becomes an increasingly key determinant of value in public markets. The excess cost of cloud weighs heavily on market cap by driving lower profit margins.

The point of this post isn’t to argue for repatriation, though; that’s an incredibly complex decision with broad implications that vary company by company. Rather, we take an initial step in understanding just how much market cap is being suppressed by the cloud, so we can help inform the decision-making framework on managing infrastructure as companies scale.

Un article « contre-courant » sur le cloud vs OnPremise. Les chiffres sont assez dingues, mais j’imagine qu’après avoir suffisamment grossi, une entreprise a les moyens pour un shift d’une partie de ses assets OnPremise. Aussi dans l’article, une raison de continuer Kube dans le cloud, mais la raison me parait trop faible face à l’avantage des services managés. Pourquoi s’embêter à maintenir un Kube dans la phase de scaling dans le cloud quand de toute façon la culture d’infra devra basculer au moment de switcher OnPrem ? D’autant qu’au moment du scaling biz ça me parait plus important de focus sur la prise de masse que l’économie d’infra. La préparation la plus évidente reste d’avoir containerisé, et je pense qu’elle suffit jusqu’au besoin de bascule. Qu’en pensez-vous ?

Liens du 31 mars 2023

Fri, 31 Mar 2023 00:00:00 GMT

Society's Technical Debt and Software's Gutenberg Moment

Every wave of technological innovation has been unleashed by something costly becoming cheap enough to waste. Software production has been too complex and expensive for too long, resulting in immense, society-wide technical debt. This technical debt is about to contract in a dramatic, economy-wide fashion as the cost and complexity of software production collapses, releasing a wave of innovation.

Une perspective que je n’avais pas sur l’impact économique et social des différentes avancées tech, et qui donne un angle différent sur l’IA. Finalement, serait-il possible que les ingénieurs en informatique mettent la clé sous la porte plus vite que toutes ces professions dont on disait qu’elles seraient remplacées par des IA ?

Enquête : derrière l’IA, les travailleurs précaires des pays du Sud

Nos recherches appuient l’hypothèse que le développement de l’intelligence artificielle ne signifie pas la fin de travail due à l’automation, comme certains auteurs l’avancent, mais plutôt son déplacement dans les pays en voie de développement.

Notre étude montre aussi la réalité de « l’IA à la française » : d’un côté, les entreprises technologiques françaises s’appuient sur les services des GAFAM pour accéder à des services d’hébergement de données et de puissance de calcul ; d’un autre côté les activités liées aux données sont réalisées par des travailleurs situés dans les ex-colonies françaises, notamment Madagascar, confirmant alors des logiques déjà anciennes en matière de chaînes d’externalisation. La littérature compare d’ailleurs ce type d’industrie avec le secteur textile et minier.

[…]

Les données du questionnaire révèlent que ce secteur emploie majoritairement des hommes (68 %), jeunes (87 % ont moins de 34 ans), urbains et éduqués (75 % ont effectué un passage dans l’enseignement supérieur).

Quand ils évoluent au sein de l’économie formelle, ils occupent généralement un poste en CDI. La moindre protection offerte par le droit du travail malgache comparée au droit du travail français, la méconnaissance des textes par les travailleurs, et la faiblesse des corps intermédiaires (syndicats, collectifs) et de la représentation en entreprise accentuent néanmoins la précarité de leur position. Ils gagnent en majorité entre 96 et 126 euros par mois, avec des écarts de salaires significatifs, jusqu’à 8 à 10 fois plus élevés pour les postes de supervision d’équipe, également occupés par des travailleurs malgaches situés sur place.

[…]

Ce schéma rappelle ce que le chercheur Jan Padios désigne comme le « colonial recall ». Les anciens pays colonisés disposent de compétences linguistiques et d’une proximité culturelle avec les pays donneurs d’ordres dont bénéficient les entreprises de services.

[…]

Derrière l’explosion récente des projets d’IA commercialisés dans les pays du nord, on retrouve un nombre croissant de travailleurs de la donnée. Alors que la récente controverse autour des « caméras intelligentes », prévues par le projet de loi relatif aux Jeux olympiques de Paris, s’est principalement focalisée sur les risques matière de surveillance généralisée, il nous semble nécessaire de mieux prendre en compte le travail humain indispensable à l’entraînement des modèles, tant il soulève de nouvelles questions relatives aux conditions de travail et au respect de la vie privée.

Rendre visible l’implication de ces travailleurs c’est questionner des chaînes de production mondialisées, bien connues dans l’industrie manufacturière, mais qui existent aussi dans le secteur du numérique. Ces travailleurs étant nécessaires au fonctionnement de nos infrastructures numériques, ils sont les rouages invisibles de nos vies numériques.

C’est aussi rendre visible les conséquences de leur travail sur les modèles. Une partie des biais algorithmiques résident en effet dans le travail des données, pourtant encore largement invisibilisé par les entreprises. Une IA réellement éthique doit donc passer par une éthique du travail de l’IA.

Une enquête qui met en évidence l’entretien de l’inertie du système colonial dans l’entretien du système numérique. Je pense que cet article est à mettre en perspective avec le suivant sur la transformation du secteur du développement informatique par l’IA. Il n’y a jamais de magie, et toujours plus d’inégalités.

One Way Smart Developers Make Bad Strategic Decisions

Sometimes smart people working hard make things worse. The following story is based my recollection of some real events.

Dans cet article, Adam Gordon Bell parle de biais que donne la posture d’un concepteur ou décideur, et ce que l’abstraction d’un vision globale a pour conséquences locales.

Why Your Efforts to Make Your Company Inclusive Aren’t Working

Diversity is not chiefly a pipeline problem. At the industry level, it is chiefly an inclusion problem tied to very specific monetary outcomes for your company. And you want to build an inclusive company. But at this company that you’ve built/joined, you’re struggling to make progress. You’ve done hours and hours of implicit bias training, but somehow every time you dare to do an anonymous survey, you get additional tips from employees about exclusion-related bullshit that happened to them.

L’inclusivité au delà de l’injonction à la diversité. Dans cet article, Chelsea Troy décrit des pratiques et compétences que j’ai pu voir et vivre dans des équipes efficaces et résilientes aux aléas d’un projet. Elle explique aussi pourquoi vos tentatives pour arriver à ce type de culture pourraient échouer.

Liens du 7 avril 2023

Fri, 07 Apr 2023 00:00:00 GMT

Disasters I've seen in a microservices world

When Martin Fowler's post about microservices came out in 2014, the teams where I worked were already building service-oriented architectures. That post and the subsequent hype made their way into almost every software team in the world. The "Netflix OSS stack" was the coolest thing back then, allowing engineers worldwide to leverage Netflix's lessons in distributed systems. More than six years later, if we look into software engineering jobs right now, most of them talk about a microservices' architecture.

In the earliest part of the 2010s, many organizations were suffering challenges regarding their software development cycle. Folks working with other 50, 100 or 200 engineers struggled with development environments, heavy QA processes and programmed deployments. While Martin Fowler's "Continuous Delivery" book shed light on many of those teams, they started to realize their majestic monoliths were creating organizational problems for them. Hence, microservices were appealing for software engineers. It's more challenging to introduce continuous delivery or deployment in a big project rather than start with it.

La huitième plaie. Un article qui se lit bien, une chambre d’écho qui fait du bien (surtout en ce moment). J’aime bien les articles un peu « histoire » sur de la hype en informatique, je trouve qu’on en trouve encore trop peu pour comprendre le chemin que fait notre domaine.

Enterprise architecture: Forget systems thinking, improve communication

The analysis provided above demonstrates that systems thinking, as a personal mental disposition, besides being a trivial idea, is essentially orthogonal to the social problem of alignment. Aligning business and IT elements of organisations requires improving interpersonal information exchange between various stakeholders and establishing collaborative decision-making procedures, rather than merely thinking differently. For this reason, systems thinking on its own, no matter how well-developed, is unable to deliver any significant organisational enhancements (besides that, it is also debatable whether, or to what extent systems thinking can be developed in an individual). In other words, systems thinking as a paradigm for EA practitioners is mostly futile, it cannot really benefit EA practices and drive the EA discipline forward.

Selon l’article, soit on utilise du system thinking tout seul pour élaborer l’archi parfaite qui ne verra jamais le jour, soit on communique avec les gens pour trouver une solution imparfaite mais qu’on pourra appliquer. Bien que je comprenne sa stratégie de dégrader le premier pour élever le second pour éveiller l’intérêt des archi qui se seraient perdus dans leurs outils, je pense que les approches ne sont ni exclusives ni orthogonales. Mais plutôt que sans la communication on ne peut pas avoir la matière pour penser le système, et qu’aussi abstrait que puisse être le system thinking ce dernier permet à l’architecte d’apporter une perspective au groupe durant la communication lorsqu’il s’agit de mettre les gens d’accord, un peu à la façon décrite par Gregor Hohpe dans son article Architects See More Dimensions. J’ai tout de même bien aimé cet article, facile à lire, et le message est bien évident !

Habits of High-Functioning Teams

I often struggle to explain what it means to be part of a high-functioning software team. Sure, there are mountains of literature, and an entire genre of LinkedIn thought leadership that professes all kinds of guidelines and heuristics about what makes teams work, but in my experience, it’s hard to internalize these ideas and follow someone else’s model if you’ve never seen what good looks like.
I’ve been very lucky to have worked directly with dozens, if not hundreds, of developers by this point in my career. I’ve been on some unhealthy teams: teams where people were fearful, and held their cards very close to their chest out of a perceived or real worry around their job security. I’ve also been on dysfunctional teams, where many days or weeks of development time was wasted while the team whiplashed between unclear priorities, or where the cost of coordination had grown so high that no one simply wanted to do it, leaving team as a collective of individuals rather than a unit. But I’ve luckily spent time on some very high-performing teams. When I’ve been on those teams, I was excited to come to work everyday, I wasn’t afraid of disagreeing publicly with those more senior than me, and I felt like my voice and my work had impact.
In this post, I’ll try to document the characteristics and habits of the highest-performing teams I’ve been on.

"This." comme ils disent. J’ai vécu ce type de contexte à haute sécurité psychologique (cc DAB 👋). Et même quand on en fait partie, l’efficacité du groupe arrive encore à impressionner. Je rêve de retrouver un tel contexte, mais de façon plus permanente. C’est ce qui me fera quitter le conseil, même si c’est pour le construire.

Why Write?

Writing about something teaches you about what you know, what you don’t know, and how to think. Writing about something is one of the best ways to learn about it. Great writing requires you to position your idea in a way that will resonate with the reader.

Découvrez pourquoi l'écriture est importante, même dans un monde où l'IA peut écrire pour vous. L'écriture vous apprend à penser et à comprendre les problèmes en profondeur, ce qui est essentiel pour résoudre les problèmes difficiles. De plus, une bonne écriture nécessite de positionner votre idée de manière à ce qu'elle résonne avec le lecteur.
Merci l’IA d’avoir rédigé ce résumé pour moi. Plus sérieusement: oui, ça aide à produire le discours, mais lorsqu’on écrit pour d’autres il ne faut pas oublier que notre discours interne (l’enchaînement d’idées visant à formuler notre connaissance) n’est pas nécessairement adapté à la transmission à un tiers. Autrement dit, la chaine d’idées doit partir de ce qu’on sait que nos interlocuteurs savent (parait que ça va sans dire, mais ça va mieux en le disant), et c’est notamment par ce biais là qu’on apprend en transmettant.

Liens du 14 avril 2023

Fri, 14 Apr 2023 00:00:00 GMT

Pour changer, une suite pas très tech d'articles (bon ok, sauf le dernier).

Et comme ça fait un peu plus d'un mois et demi que je publie des liens, je vous pose la question très ouverte : Comment ça se passe jusqu'ici ?

Vous pouvez répondre par le canal que vous préférez, mais sachez qu'à travers la newsletter il est aussi possible de répondre directement au mail. Je serai le seul à recevoir la réponse.

Idle Threat: What Incremental Games Say about Our Relationship to Work

I have a new job, though I’d be the first to admit it doesn’t look like one. Nevertheless, it’s important to me: I click and click at little squares until coins come out, and spend the coins until I get more squares. The job is a game called Garden Galaxy, and I’m its newest employee.

[…]

I know that games aren’t work, at least if you’re not explicitly playing them for money. And I know about the intricacies of simulating work. I’ve written about it.

But you don’t understand: I need to finish making my garden.

[…]

In all these games I’m anything but idle, which makes a game like Garden Galaxy stop me in its tracks. The sounds, the aesthetic, even the gameplay tells me that by playing, I should be relaxing—so why does it feel like I’m doing something else?

L’entrée. Court, facile à lire, et qui me fait réfléchir sur les jeux et autres apps "que je consomme"

The Art of Lying Fallow: Psychoanalyst Masud Khan on the Existential Salve for the Age of Cultish Productivity and Compulsive Distraction

“a generation that cannot endure boredom will be a generation… in whom every vital impulse slowly withers, as though they were cut flowers in a vase,”

[…]

It is a strange and uncanny result of urban civilization and the impact of technology on human experience that leisure has become a pursuit and an end in itself. It has gradually become an industry, a profession and an imperative social need of the individuals in modern societies. Everyone strives for more and more leisure and knows less and less what to do with it. Hence the emergence of a colossal trade in organizing people’s leisure. This need is perhaps one of the real absurdities of our existence today, and it reflects the decay of some crucial value-systems… in all types and kinds of human beings. The pursuit of frantic leisure… is perhaps one of the most dissipating qualities of the technical cultures. The individual on whom leisure has been imposed in massive doses, and who has little capacity to deal with it, then searches for distractions that will fill this vacuum… A great deal of the distress and psychic conflict that we see clinically… is the result of a warped and erroneous expectancy of human nature and existence. It is the omnipresent fallacy of our age that all life should be fun and that all time should be made available to enjoy this fun. The result is apathy, discontent and pseudo-neurosis.

[…]

A craving for leisure, and the concomitant yearning for distractions to fill the void of given-leisure, is the result of our failure to understand the role and function of the need to lie fallow in the human psyche and personality… We have industriously misinformed ourselves about the essentials of human nature. We have confused the necessity to relieve human poverty and misery with the demand that all life should be fun and kicks. The entertainment media of modern cultures have further exploited this leisure void for commercial gain and flooded citizens with ready-made switchable distractions, so that no awareness of the need to develop personal resources to cope with fallow states can actualize as private experience.

Le plat principal. Plus long, et probablement celui qui bouscule le plus, essentiellement sur le rapport à l'ennui et l'activité. Je l’ai pourtant trouvé reposant à lire.

Against Innovation

What had happened earlier that spring was a routine software update to a piece of my digital studio. But the update rendered a different, crucial piece incompatible. So I updated that. Which made another piece incompatible – an expensive piece. And I couldn’t update that. (This was at the height of the pandemic. Who could afford to update anything?)

Moreover, I was in the middle of a project – mixing our album A Sky Record – and I very much wanted to continue along the lines I had started. In the digital era, we are all accustomed to fast moving technology – but could I really no longer make it through even one album from start to finish on the same equipment? And if not, how do we ever come to any kind of mastery of our tools?

Le fromage. Court, pas spécialement tech, mais qui rappelle que derrière chaque update la rupture de contrat d’interface est le sommet de l’iceberg.
Qu’en est-il des apprentissages ?

Generative Agents: Interactive Simulacra of Human Behavior

This paper introduces generative agents, interactive computational agents that simulate human behavior. We describe an architec- ture for generative agents that provides a mechanism for storing a comprehensive record of an agent’s experiences, deepening its understanding of itself and the environment through reflection, and retrieving a compact subset of that information to inform the agent’s actions. We then demonstrate the potential of generative agents by manifesting them as non-player characters in a Sims-style game world and simulating their lives in it. Evaluations suggest that our architecture creates believable behavior. Going forward, we suggest that generative agents can play roles in many interactive applications ranging from design tools to social computing systems to immersive environments.

En gros : Westworld en virtuel c’est pour aujourd’hui. Et si vous avez eu l’occasion de tester les technos OpenAI vous comprendrez vite que, sans aller dans un design aussi poussé que proposé ici, ces simulations sont très accessibles.
Merci gauthe_t pour ce dessert à ganache au chocolat bien solide.

Liens du 21 avril 2023

Fri, 21 Apr 2023 00:00:00 GMT

Myth of the Lone Genius, Où je me suis trompé sur l’agilité, How Complex Systems Fail, No Ghosts!

Myth of the Lone Genius

While we frame early pioneers in our field as lone geniuses who applied their technical prowess to invent new technologies and ways of solving challenging problems, the reality is that these people never really worked alone. The notion of the lone genius arguably has its origins in the 18th century, during the period that historians have dubbed The Enlightenment.

Comment la notion du génie solitaire est née et pourquoi elle est un mythe dans l'industrie technologique. L'auteure relate des relations de collaboration et de partenariat au sujet d'inventions bien connues pour expliquer en quoi elles sont en réalité le moteur de la créativité, et remet en question l'importance des compétences techniques par rapport aux compétences interpersonnelles.

Où je me suis trompé sur l’agilité : l’état d’esprit

Ces réflexions trouvent leur apothéose en 2015 avec le livre The Agile Mind-Set de Gil Broza qui affirme que la pièce manquante des processus Agiles, c’est l’état d’esprit Agile. Le chapitre 1 comporte une description des éléments constitutifs d’un état d’esprit.

J’ai trouvé utile de considérer qu’un état d’esprit comporte trois éléments :
Valeurs : ce que vous considérez comme étant le plus important dans la situation actuelle.
Croyances : ce que vous considérez comme vrai dans ce genre de situation.
Principes : les normes qui guident vos choix, vos décisions et vos actions.

Plus loin, Broza précise ce qu’il entend par croyances.

Les croyances évoquent le fait religieux, mais dans le contexte de l’état d’esprit Agile, elles ont un sens tout autre.
Une croyance est une conviction. C’est quelque chose que vous considérez comme vrai mais que vous n’avez pas prouvé et peut-être que vous ne pouvez pas prouver de manière rigoureuse.

Aujourd’hui cette affirmation que l’agilité est un état d’esprit est tellement courante qu’elle a été reprise par d’autres mouvements comme le Produit.

[…]

Il n’y a pas si longtemps, je me serais senti bien seul en disant que l’agilité ne doit pas être définie comme un état d’esprit. Aujourd’hui, grâce à une insatisfaction grandissante envers l’agilité, j’ai de plus en plus d’interlocuteurs, comme Denis Migot ou Allen Holub, qui seraient d’accord ou du moins intrigués.

C’est en particulier grâce à l’écoute de diverses présentations données par Dave Snowden que j’ai commencé à revoir ma position sur le sujet. Il avance plusieurs arguments qui m’ont paru suffisants. Mais je sais qu’ils ne sont pas convaincants pour tout le monde alors je me permets d’en ajouter d’autres à la liste.

Une chambre d’écho pour moi, plus ça va moins je suis à l’aise avec les discours d’anciennes et nouvelles méthodes répandues ou comme on dit "évangélisées". Je pense même que dans mon contexte pro actuel on pourra bien plus trouver notre bonheur dans un bon vieux cycle V à notre sauce qu’en cherchant même juste à tendre vers l’agilité.

How Complex Systems Fail

Post-accident attribution to a ‘root cause’ is fundamentally wrong.

Because overt failure requires multiple faults, there is no isolated ‘cause’ of an accident. There are multiple contributors to accidents. Each of these is necessarily insufficient in itself to create an accident. Only jointly are these causes sufficient to create an accident. Indeed, it is the linking of these causes together that creates the circumstances required for the accident. Thus, no isolation of the ‘root cause’ of an accident is possible. The evaluations based on such reasoning as ‘root cause’ do not reflect a technical understanding of the nature of failure but rather the social, cultural need to blame specific, localized forces or events for outcomes.

[…]

Hindsight biases post-accident assessments of human performance.

Knowledge of the outcome makes it seem that events leading to the outcome should have appeared more salient to practitioners at the time than was actually the case. This means that ex post facto accident analysis of human performance is inaccurate. The outcome knowledge poisons the ability of after-accident observers to recreate the view of practitioners before the accident of those same factors. It seems that practitioners “should have known” that the factors would “inevitably” lead to an accident. 2 Hindsight bias remains the primary obstacle to accident investigation, especially when expert human performance is involved.

De bonnes piqures de rappel sur la nature des systèmes complexes, de la présence constante des erreurs, et de la rareté des véritables incidents.

No Ghosts!

By “ghost” here, I mean any situation where resources are referenced by plain data.

And by “plain data” here, I mean strings, integers, or any other data where independently produced copies of the data are interchangeable. For example, two completely independent parts of a system may create a string with the value "Purple", and the two strings will be interchangeable.

Plain data can contain filenames, network addresses, usernames, or other forms of data which effectively reference resources.

For example, when we say that a particular string contains a filesystem path, we mean that it refers to an entity in a filesystem namespace. Filesystem namespaces are not explicitly passed as arguments in the APIs of many popular systems, so from the perspective of an API, while paths are explicit string parameters, the additional information referenced by those paths is not. In this post, we'll say this additional information is being carried by a “ghost”.

Un article de sécu sur les communications inter-systèmes. Non seulement j’en ai appris sur la sécu, mais je repars aussi avec le concept de Ghost et tout ce que ça implique en archi logicielle et SI ! Ça se lit tout seul

Liens du 28 avril 2023

Fri, 28 Apr 2023 00:00:00 GMT

Fire and Motion, Evaluating Team Members’ Contributions to a Maintainable Code Base, Reasons to avoid Javascript CDNs, Scale is poison

Fire and Motion

When I was an Israeli paratrooper a general stopped by to give us a little speech about strategy. In infantry battles, he told us, there is only one strategy: Fire and Motion. You move towards the enemy while firing your weapon. The firing forces him to keep his head down so he can’t fire at you. [...] The motion allows you to conquer territory and get closer to your enemy, where your shots are much more likely to hit their target. If you’re not moving, the enemy gets to decide what happens, which is not a good thing. If you’re not firing, the enemy will fire at you, pinning you down.

L'auteur raconte comment la stratégie militaire de "Fire and Motion" (tir de couverture) peut être appliquée dans le monde du développement de logiciels pour progresser chaque jour dans ses tâches. Le même parallèle est utilisé pour expliquer ce qui fait courir un bon nombre d’entreprises. Une idée à bien garder en tête lorsqu'on se lance dans les fonctionnalités d'un produit sur lequel il y a concurrence, j’ai encore entendu aujourd’hui : « il y a de la concurrence sur ce domaine, on a intérêt à développer les mêmes fonctionnalités que les autres ».

A Rubric for Evaluating Team Members’ Contributions to a Maintainable Code Base

How much of your engineering team’s effort gets spent on keeping the existing system running, rather than changing the feature set? One of the most important concepts for addressing a code base’s maintenance load is code stewardship—the trick (or really, the entire skill set) of keeping a code base maintainable. Engineers receive more mentions, accolades, raises, and promotions from cranking out features than from investing time in code stewardship, so the former represents a massive opportunity cost of doing the latter.

Un bon combo avec le « toil » SRE, le maintenance load est un concept bien plus évident à manipuler que la dette. Récemment j’ai organisé des ateliers de rétrospective technique et me suis servi du concept pour prioriser les tâches du backlog tech selon deux axes : qu’est-ce qui demande le moins d’effort et fait gagner le maximum de temps lors du développement des features, en quelque sorte le négatif du « maintenance load »

Reasons to avoid Javascript CDNs

Many javascript projects have install instructions recommending that people use a CDN like jsdelivr or unpkg to include the code on their website. This has the advantage that it's quicker to get started with, and it's often claimed to load faster. However, it also has downsides when it comes to privacy, security, and systemic risk, and it may actually be slower in some common cases. Here are some reasons not to use a javascript CDN, and some alternatives to consider instead.

Je pense que j’ai plus souvent eu à intégrer du code js tiers par un gestionnaire de dépendances que par CDN. Cela dit pour les rares cas où je l’ai fait je ne savais pas qu’il existait des contre-mesures comme le SRI sur le tag script !

Scale is poison

I've worked for a wide range of companies throughout my career. From a big US tech giant to a small Norwegian SaaS platform, with some bits in between. To me the problem is clear: big companies can't afford to give a fuck.

Why is it that companies paying Google $100,000 a month for GCP get ghosted by support staff, yet Jason Fried regularly answers questions about his company directly on Twitter?

The answer is scale.

L'extrait en dit peut être déjà assez long ^^'

Liens du 5 mai 2023

Fri, 05 May 2023 00:00:00 GMT

150 African Workers for ChatGPT, TikTok and Facebook Vote to Unionize, Gradle still sucks, The Complete Guide to the Kano Model, Thinking about our passive exposure to IPv6 issues

150 African Workers for ChatGPT, TikTok and Facebook Vote to Unionize at Landmark Nairobi Meeting

More than 150 workers whose labor underpins the AI systems of Facebook, TikTok and ChatGPT gathered in Nairobi on Monday and pledged to establish the first African Content Moderators Union, in a move that could have significant consequences for the businesses of some of the world’s biggest tech companies.

[…]

Those two judgments against Meta include one from April in which a Kenyan judge ruled Meta could be sued in a Kenyan court—following an argument from the company that, since it did not formally trade in Kenya, it should not be subject to claims under the country’s legal system. Meta is also being sued, separately, in a $2 billion case alleging it has failed to act swiftly enough to remove posts that, the case says, incited deadly violence in Ethiopia.

[…]

Workers who helped OpenAI detoxify the breakout AI chatbot ChatGPT were present at the event in Nairobi, and said they would also join the union. TIME was the first to reveal the conditions faced by these workers, many of whom were paid less than $2 per hour to view traumatizing content including descriptions and depictions of child sexual abuse. “For too long we, the workers powering the AI revolution, were treated as different and less than moderators,” said Richard Mathenge, a former ChatGPT content moderator who worked on the outsourcing company Sama’s contract with OpenAI, which ended in 2022. “Our work is just as important and it is also dangerous. We took an historic step today. The way is long but we are determined to fight on so that people are not abused the way we were.”

En lien direct avec un article précédemment partagé sur l’exploitation de travailleurs pour la modération de contenus générés sur les réseaux ou par les IAs. J’espère que l’impact sera à la hauteur des ambitions, et curieux de voir comment les GAFAM & co trouveront de nouveaux moyens d’exploiter les inégalités pour leur marge.

Gradle still sucks

What sucks about the above process is not that it’s long. It’s the sheer number of concepts that must be learned and interacted with: subbuilds, subprojects, plugins, tasks, providers, extensions, source sets, configurations, artifacts, dependencies, and all of the quirks and workarounds involved with each of those things.

All of this complexity makes working with Gradle a slog. You can fully, deeply understand every single aspect of your build until you want to do one thing slightly differently and suddenly it doesn’t work because you were supposed to be using some totally different part of Gradle you never heard about before.

The whole idea of using community-developed plugins becomes a minefield because the chance of them applying all of the concepts completely correctly is essentially 0%, meaning you might be okay as long as you’re only doing basic stuff, but as soon as you stray off the beaten path stuff starts breaking and you have almost no chance to fix it properly yourself.

La liste des étapes est longue, mais si vous en avez le courage, et lisez entre les lignes, vous reconnaîtrez sûrement d’autres outils que vous utilisez sur vos projets.

Je vois déjà dans l’audience un sourire de maniaque grandir sur le visage d’un utilisateur pragmatique de Gradle, prêt à jeter son casque Bluetooth à travers la pièce. Oui l’auteur s’est acharné à suivre le chemin de la « best practice », et bien sûr plus quelque chose est adaptable, moins il est adapté. Et si l’outil permet de sortir de ces best practices, c’est probablement justement parce qu’il serait idiot de les appliquer en tout contexte.
Cela dit, l’article fait mouche volontairement et involontairement sur plusieurs points :

le « golden path » de ces best practices est anormalement complexe
ce « golden path » étant ingérable, les outils communautaires préfèrent la configuration plutôt que la convention ce qui rend leur intégration terrible
avez-vous bien lu le vocabulaire gradle ? Ce système semble-t-il avoir des « propriétés affordantes » ? Encore une fois : adaptable vs adapté

Et ce n’est pas propre à Gradle. Vous avez tenté d’introduire des étapes custom de génération à partir de source avec webpack sans bidouiller ? (Btw ce site est généré grâce à de telles étapes)
Au fond, le seul outil qui m’a donné le moins de fil à retordre pour organiser des étapes de build est aussi le plus vieux : Makefile.

The Complete Guide to the Kano Model

The features you choose to study should be those where the user will get any sort of meaningful benefit out of them. Your backlog may contain a number of different kinds of items you may need to include such as technical debt payment, something for the sales or marketing teams, a reporting system, or a design refresh. All of these are out of scope of the Kano analysis.

We’re measuring customer satisfaction among externally tangible features, but products are way more than that. If you need data to support not doing something an internal stakeholder is asking of you, you’ll be doing a disservice to your team, your customers and yourself if you use a Kano study for that.

[…]

If you’re seeing multiple results without a clear category, there may hidden customer profiles that you’re not considering. In this case you should probably go back to the customer responses to look for patterns; try checking which customers’ answers are usually the same as other customers’, to find “demographic clusters” you may be missing.

From the results table, you can rank features according to their importance. After that, the general rule of thumb to use when prioritizing is to go after all Must-be features, then add as much Performance ones as you can and finally include a few Attractive ones.

This type of analysis is great to give you a first level of understanding and it’s useful in many contexts where you don’t need a more rigorous approach (e.g., testing design ideas or making a rough draft of your roadmap.)

Une fois priorisés dans un backlog la valeur de chaque story semble facilement comparable, leur ordre apparaît évident, mais ce n’est que le résultat d’un processus absolument pas linéaire. Confondre ce résultat et les moyens pour y parvenir nous empêche d’ajuster rapidement notre trajectoire, et donne très souvent pour résultat un bête alignement d’epics dont on se demande parfois pourquoi on les découpe en tickets si fins. Cet article présente un modèle qui permet de classer des fonctionnalités en prenant compte l’aspect dynamique de la « valeur » de chacune. C’est à dire que même si l’on montre très souvent le graphe du modèle de Kano, il s’agit d’un outil qui est loin de ne considérer que 2 dimensions.

Thinking about our passive exposure to IPv6 issues

If I were an evil threat actor, I'd be learning as much about #ipv6 as possible right now. I'm convinced that many companies that say they "aren't using" IPv6 are in reality just ignoring IPv6, and it would be easy to set up a "shadow network" consisting of IPv6 traffic where you could get away with murder. Nobody at the company is logging IPv6 traffic and events, none of the tools are configured to monitor it, and a large majority of the staff knows nothing about it.

"But we disable IPv6!"

Really? On your users mobile devices? On printers? On random IoT devices? And most of all, on your remote user's networks? Good luck, my guy.

Liens du 12 mai 2023

Fri, 12 May 2023 00:00:00 GMT

Programs, life cycles, and laws of software evolution, Modulith First! The appropriate path to microservices, The Microservices Fallacy - Part 9 Moduliths, An Update on the Lock Icon

Programs, life cycles, and laws of software evolution

Top-level managerial pressure to apply life-cycle evaluation is therefore essential if a development and maintenance process is to be attained that continuously achieves, say, desired overall balance between the short- and long-term objectives of the organization. Neglect will inevitably result in a lifetime expenditure on the system that exceeds many times the assessed development cost on the basis of which the system or project was initially authorized.

[…]

The final section of the paper (V. Applied Dynamics) is a case study in how knowledge of these laws can be used to guide longer-term planning processes. Lehman analyses the releases of System X (a general purpose batch operating system) through one by looking at the number of modules added and changed during each release, as a proxy for complexity. By looking at the average number of modules changed per day during a release, it can be seen that releases that push the rate higher tended to be ‘extremely’ troublesome and followed by considerable clean-up. Likewise releases that exceeded the normal incremental baseline of module growth (number of new modules) also tended to leave a poor quality base and need to be followed by a clean-up release. Thus it becomes possible to look at the current rates of change and addition, and make an assessment of the likely underlying quality trends and what what can be accomplished in the near future.

Résumé d’un papier datant de 1980, très agréable à lire, et qui montre bien qu’on a pas fini de lutter à gérer la complexité du développement logiciel. Sur mon projet actuel encore je me bat pour qu’on gère l’obsolescence et qu’on arrête de considérer le développement comme un empilement de code.

Modulith First! The appropriate path to microservices

Microservices are a great mechanism to ensure modular delimitation in a system over the long term. As an architectural style, however, they do not answer the question of where exactly the demarcation between the individual services works best. Technical, vertical structures and domain-driven design are on everyone's lips, but they also do not represent an easy-to-use panacea for an efficient separation of modules and services. In this article we take a look at approaches that are comparatively objective because they are supported by metrics. At least at the beginning, we rely on a so-called "modulith" because it is easier to measure than distributed systems such as microservices.

Un article qui donne de la matière quel que soit le découpage et découplage de code qu’on vit ! Je pense me servir des métriques pour mesurer le chaos de microservices que je vois en ce moment. Je pense que ça peut servir de bons proxies pour évaluer la qualité du mode d’organisation et d’implémentation de la solution.

The Microservices Fallacy - Part 9 Moduliths

If you do not need to go fast and/or do not have multiple teams and do not have very disparate NFRs for different parts of your application, a modulith can be a sensible alternative to microservices. It offers most advantages of microservices like better maintainability and evolvability, team independence and more while not exhibiting the intricacies of microservices at runtime. A modulith is still a deployment monolith, i.e., one of the simplest runtimes architectures available.

A modulith requires advanced functional design skills and strict implementation rigor – two properties that unfortunately are not seen very often in most companies. If you do not have the two skills in your company, most likely you will up with the dreaded big-ball-of-mud-type monolith.

Yet, this is still better than a distributed big ball of mud that you would end up with if you were going for microservices while lacking the two aforementioned skills.

Pas nécessairement l’article le plus auto-portant, mais il donne déjà de quoi penser sur la stratégie modulith (qui en soit ne surprendra pas, mais qui pourrait bien être la mode qui nous sauvera de la précédente). L’article suivant est intéressant également, et donne une autre stratégie d’isolation. Reste tout de même et toujours la façon formaliser le modèle mental pour que le découpage et découplages deviennent évidents, et ça, ça ne viendra pas d’un style d’architecture qui n’a pour but que d’organiser la solution.

An Update on the Lock Icon

For example: we know that the lock icon does not indicate website trustworthiness. We redesigned the lock icon in 2016 after our research showed that many users misunderstood what the icon conveyed. Despite our best efforts, our research in 2021 showed that only 11% of study participants correctly understood the precise meaning of the lock icon. This misunderstanding is not harmless — nearly all phishing sites use HTTPS, and therefore also display the lock icon. Misunderstandings are so pervasive that many organizations, including the FBI, publish explicit guidance that the lock icon is not an indicator of website safety.

Énième exemple que l’UX est cruciale dans le domaine de la sécurité. Chrome dévoile sa prochaine évolution de l’icône verrou de la barre d’adresse.

Liens du 19 mai 2023

Fri, 19 May 2023 00:00:00 GMT

Estimating Software Projects: The art of the SWAG, It’s a Modulith, The Worry Police, (missed) Shift Left

Estimating Software Projects: The art of the SWAG

For example, I can make a SWAG about upgrading a codebase from Python 2 to Python 3: I’ve done this work myself a bunch, and observed many more porting projects, and so my intuitive guesses about a new codebase tend to be reasonably accurate. I can’t make a good SWAG in the seemingly similar situation of upgrading a Perl 5 codebase to Perl 6: I simply don’t have enough priors to build on.

So what’s happening isn’t a guess: no, you’re using a highly sophisticated neural network that’s been trained on substantial prior experience. When someone asks, “how long with that take?” and an immediate answer springs to mind, that’s the result of some very quick, often unconscious pattern-matching against your prior experience. This is what Daniel Kahneman calls “System 1 thinking”: fast, instinctive, intuitive. (For more, see Thinking Fast And Slow). System 1 can be accurate in some circumstances – including, in my experience, these quick estimates. But only some of them.

Une bonne description du processus mental d’estimation à la volée, et surtout de bons tips quand ne pas en faire !

It’s a Modulith

With this as a background, one can now read “Scaling up the Prime Video audio/video monitoring service and reducing costs by 90% ”, a writeup published by the Amazon Prime Video Streaming Team. They have implemented a functionality which probes frames from the video stream sent to customers, applies tests and recognizes certain artefacts that impair quality, so that they can be corrected.

Amazon being Amazon, they have implemented that as a pile of microservices that interact in an event-driven architecture with lambdas and step functions, in order to shovel data from one S3 bucket into another, running the required analytics on the way. Notification about things found are being put on SNS.

[…]

Unfortunately, the subtitle of the article is “The move from a distributed microservices architecture to a monolith application helped achieve higher scale, resilience, and reduce costs”. This sets wrong expectations and makes it harder to pick up the actual learning.

What the AWS Prime Video team arrived at is most closely described as a Modulith , only that they arrived at it the other way around. Fowler suggests you start Monolith first and then chisel off the components you identify as standalone subservices. They instead used pre-made AWS infrastructure components to build a highly modular prototype, and then identified tightly coupled components and merged their deployment without giving up the modular structure. Fowler himself points to an article by Sam Newman and the book that came from it as a way of doing this.

The result is not really a single-instance monolith, anyway. Components are merged into a single ECS container, but of course ECS will deploy it with the required degree of parallelism, and it is still part of a larger system that communicates in an event-driven architecture using lambdas and messages.

So if this article is anything, it is an example of the benefits good observability has, and how a good architecture allows you to rearrange the layout of well-isolated and structured components with clean interfaces at will. The application can be made to run on different substrates, in order to react to different demands of scale or changing business requirements.

Une autre perspective intéressante sur cet article d’amazon Prime Video, un focus bien plus archi que technologique !

The Worry Police

The Worry Police might sound engaged with their questions, but they aren’t. They’re worried. They believe this continued incessant worry will somehow miraculously guide this project in the correct direction, and sometimes they’ll get lucky. The Worry Police don’t have hope because they haven’t been rewarded for hope, for optimism.

[…]

The Worry Police exist for a reason you need to understand. They were granted power because the perception was they added value. There is a cultural reason they exist at your company.

The Worry Police, you might infer, aptly describes a specific job, but the Worry Police is neither a job nor a role, but a learned attitude. The Worry Police might read like a gross exaggeration, but they’re not. They’re in the room right now with you. Worrying.

Un article plutôt descriptif sur un modèle mental qu’on retrouve facilement dans nos boulots, et un modèle cible qui permet d’avancer (mais rien sur le chemin à parcourir entre deux !)

(missed) Shift Left

Shift left! Shift left! They say. This is a common refrain when people are talking about DevOps. Deming taught that we have to build quality in, we cannot inspect quality in at the end, so we need to shift left.

So teams set off to shift left, not sure exactly what this means, but often it’s approached as though it will mean more of their work will be given to the developers. They will finally understand what we go through! They will finally learn about our jobs!

Un article court qui pose des mots sur la stratégie Shift Left, et des préconditions pour y parvenir.

Un cadran pour les prioriser tous

Wed, 24 May 2023 00:00:00 GMT

Quand on se dit qu'il faut s'attaquer à la dette c'est qu'il est souvent déjà trop tard. Voici une stratégie qui m'a aidé, et qui servira que votre projet soit sous l'eau ou en bonne santé.

Pourquoi cet article ?

J'ai commencé à parler d'un modèle que j'utilise sur ma mission actuelle, et qui est grosso modo une forme plus explicite de la façon dont je pratique la priorisation des "sujets techniques", notamment l'infâme "dette technique".

TL;DR: passez à la partie suivante.

Rétrospectivement, le concept de dette ne m'a réellement servi que lors de discussions vis à vis de projets inventés de toutes pièces pour se convaincre les uns les autres de la façon dont gérer ce qu'il se cachait sous le concept. Autant dire, on avait besoin d'un concept pour résoudre un problème inventé, et pouvoir se féliciter quand l'univers factice tenait debout tout seul dans la logique qu'on avait pu se partager.
En revanche, quand il s'agissait de parler de ce qui se cache réellement derrière ce concept de dette, la métaphore m'a finalement le plus souvent desservie. Combien de projets en bonne santé avez-vous rencontrés qui ont dû investir dans une étude, une réflexion profonde, et des indicateurs pour gérer leur dette ? Et combien de fois avez-vous vu ces mêmes choses pour des projets dont on se disait que la dette était le problème qui faisait que le système était en mauvaise santé ? D'expérience, et des discussions que j'ai eu avec d'autres du domaine, proportionnellement bien plus dans le second cas que dans le premier. La question de la dette ne se pose pas dans un projet qu'on sait maintenir, en revanche elle se pose dans un projet qu'on ne sait pas maintenir. Et c'est là que la métaphore de la dette est contre productive, car elle nous fait croire qu'il suffit de "régler la dette", alors qu'en réalité on devrait apprendre à maintenir le projet.

La métaphore la plus proche que j'ai pu trouver pour mieux illustrer cette activité à gérer est celle de "maintenance load", ou charge de maintenance, que j'ai pu lire dans l'article "Quantifying Technical Debt" de Chelsea Troy. En gros, avec mes propres mots, la charge de maintenance c'est l'effort investi à faire autre chose que faire évoluer le système pour le bénéfice direct des utilisateurs. Quelques exemples : corriger un bug, investiguer un incident, faire des rollbacks, mettre à jour des dépendances, intégrer du code entre branches, etc. Plus on passe de temps sur la charge de maintenance, moins on a de temps pour fournir de nouvelles fonctionnalités. Hors, comme l'indique très bien l'article cité plus haut, plus on ajoute de fonctionnalités, plus on dégrade le système. Et forcément, plus il est dégradé, plus il est difficile de le faire évoluer, que ce soit pour des fonctionnalités ou de l'amélioration technique. On voit alors que la dette n'est pas un problème en soi, mais un symptôme d'un problème plus profond : on ne sait pas maintenir le système. Régler la dette revient donc à régler les symptômes, et non la cause. Et comme tout symptôme, il peut revenir, et il reviendra tant qu'on ne s'attaquera pas à la cause : savoir maintenir le système.
L'avantage de cette métaphore c'est que lorsqu'il s'agit de savoir par quoi commencer, il devient facile de comprendre que le but sera de réduire le maximum de charge de maintenance avec le moins d'effort possible. Et non de refactorer du code parce qu'on ne le trouve "pas beau", ou parce qu'il ne correspond pas aux "bonnes pratiques" du marché.

Récemment, un ami me parlait de la volonté de sa hiérarchie de s'attaquer à la dette, et comme j'avais un outil sous la main qui m'aidait à traiter ces sujets en continu et avoir une stratégie pour les prioriser, je lui ai proposé de lui partager. La suite est peu ou prou ce que j'ai pu lui dire.

Processus

Les gens qui entretiennent le code (appli, d'infra, peu importe) savent souvent là où ça va mal, donc le principe c'est de leur faire dumper tout ce qu'ils verraient à améliorer dans leur quotidien. Le mieux c'est de faire ça sur un board / tableau blanc pour qu'ils dumpent leurs tickets / post-it chacun dans leur coin. Tant pis pour les répétitions, ce sera même un indicateur de ce qui motive / intéresse / touche le plus l'équipe.

Une fois les tickets dumpés, il risque d'y avoir de tout. On cherche à faire ressortir les axes d'amélioration tech, mais sans nier le reste qui a été pondu car ça a aussi de la valeur. Donc pour commencer chaque personne va présenter ses tickets. Les gens discutent pour bien comprendre de quoi il s'agit, et on regroupe les tickets au fur et à mesure pour les catégoriser.

Ce qui n'est pas de l'amélio technique est à mettre dans des catégories qui serviront en dehors du cadran. Deux exemples :

perf : ça touche directement les utilisateurs, si y'a besoin de perf, le métier saura le prioriser, mais ça peut être bon de le faire remonter
amélio UX / idée de feature : pareil, ça peut être bon de le faire remonter notamment pour montrer qu'on est investi sur le produit et avoir le plaisir de dire "ça c'était mon idée", mais c'est pas à l'équipe de décider si ce sera dans le prochain sprint

Le reste, c'est sûrement de l'amélio tech, et c'est à l'équipe de décider ce qui est prioritaire. Et voilà comment :

Une fois tout présenté, pour aider l'équipe à prioriser, on va utiliser un cadran avec deux axes

gain de temps pour les prochains développements: genre moins de bug à traiter, temps de build plus court, moins de temps à debugger, moins de temps investi à déployer, moins de temps à tester, moins de temps à faire des rollback, etc.
effort: le temps nécessaire pour réaliser le ticket

Si on a peu de tickets / participants, le mieux est encore de discuter de chaque ticket et de le placer sur le cadran. Si on a beaucoup de tickets / participants, on peut utiliser le même principe que l'extreme quotation : en gros chacun prend des tickets au hasard, et sans discuter avec les autres les posent sur le cadran. Quand on a plus de tickets, on regarde ce qui a été posé, et si on est pas d'accord avec le positionnement d'un ticket on le dit pour en parler avec l'équipe. C'est très rapide car on ne parle que de ce qui n'est pas évident.

Un exemple de cadran avec des tickets

Une fois ces tickets placés, on trace les impitoyables lignes de séparation du cadran.

Dans les équipes les plus avancées (et je parle bien en tant qu'équipe et non de personnes), la taille est quelque chose de plus facilement appréhendable et estimable, et on peut donc définir des tailles de tâches en heures / jours / points / whatever, et placer les lignes en fonction de ça. Si vous prenez habituellement 20% à 30% d'un temps de sprint pour de l'amélioration technique, avoir une estimation plus évidente permet de rendre la capacité de production de fonctionnalités de l'équipe plus prédictible.

Dans le cas où l'équipe n'en est pas à ce niveau et qu'elle court après les problèmes l'enjeu est d'abord de stabiliser les choses et de se donner les capacités de pouvoir découper les tâches tech (des prérequis de la prédictibilité). Par exemple en découplant certains morceaux pour limiter les effets tunnel en cas de modification. Et moins d'effet tunnel signifie plus d'espace durant les sprints pour de la fonctionnalité et un espace plus prédictible pour améliorer la technique (un début de cercle vertueux donc).
Dans ces cas là donc je place les lignes arbitrairement, ici je les aligne pile sur les milieux des axes, car le placement des tickets est fait relativement les uns aux autres. Ce qui permet donc à l'équipe de prendre de définir des tâches comme "petites" relativement à ce qu'elle est capable de faire de plus petit à ce jour.

Le cadran avec les lignes pour classer les tickets, et des hints sur quoi faire de chaque zone

En somme :

Tous les tickets qui tombent dans la partie peu d'effort / beaucoup de gains peuvent être embarqués dans les prochains sprint (bien sûr on en discute entre nous avant pour être sûr de ce qu'on fait)
Si ça tombe de la partie beaucoup d'effort / beaucoup de gain, il faut trouver une stratégie pour que ça tombe dans la partie précédente (découpe, autre méthode, ...).
Quand ça tombe dans la partie beaucoup d'effort et peu de gain, c'est que c'est surement à jeter, ou sinon à rediscuter.
Si c'est dans peu d'effort, peu de gain, faut discuter aussi pour comprendre si c'est pertinent, pourquoi ça a été proposé, etc.

Dans la durée

Le contenu du cadran va vieillir, mais contrairement à un backlog de dette, ce n'est pas grave, on peut même jeter ce qui ne bouge jamais des cadrans pas immédiatement activables. Tout ce qui compte c'est de trouver des tickets qui tombent dans le cadran en bas à droite, et de les traiter.

Le mieux est de réévaluer ce qu'il y a dans le cadran durant les rétrospectives techniques (1 à 2 fois par sprint le plus souvent suffisent).

Si par le plus grand des hasards vous vous retrouvez avec trop de tickets dans cette zone (déjà se demander si on a bien évalué leur position), une solution est de se demander ce qui va arriver fonctionnellement dans les prochains sprints et de prendre les tickets qui aideront à développer ces fonctionnalités plus efficacement ou simplement.

L'avantage, c'est que c'est transparent pour tout le monde, et facile à communiquer aux stakeholders, et donc facile de justifier pourquoi cette tâche est faite, et montrer qu'on se soucie de notre capacité à pouvoir continuer à "livrer de la valeur".

Liens du 26 mai 2023, CommonCog

Fri, 26 May 2023 00:00:00 GMT

Pour cette semaine, j'ai voulu tenter un autre format. La réflexion que je me suis faite c'est qu'à force de parcourir des liens, je commençais à voir quelques sites qui me paraissaient pertinent au delà de l'article qui m'y avait attiré. Et que lorsque je tombe sur un tel site, en donnant plus de détails et publications je pourrais, peut-être, vous donner envie de vous y abonner par flux rss / mail ou tout autre moyen de publication qu'il rendrait disponible.

Le site de cette semaine est CommonCog. Il se décrit comme tel :

Commoncog is a blog about better business and career decision making.

That's a snappy way to say that the blog is about anything that might help you make better decisions in business (from the perspective of an operator, natch), or in your career.

En parcourant plusieurs de ses articles, j'ai découvert bien plus que ça comme la performance opérationnelle, l'appropriation de modèles mentaux, des postures, ... L'auteur a aussi une formation de développeur ce qui l'amène parfois à illustrer ses sujets avec des exemples qui parlent à un public sensible au domaine. Je trouve que ses articles sont bien rédigés et accessibles, mais peuvent parfois être longs.

Si les articles ci-dessous vous inspirent, vous pouvez le suivre par flux RSS, twitter, newsletter, et il existe même un podcast !

Are You Playing to Play, or Playing to Win?

I played Judo very competitively when I was younger. For about two years when I was 18, my entire life was school, training and sleep. The only problem was that I wasn’t very good at it. I had it in my head that the only Judo worth playing was a ‘Japanese’ style of Judo — an upright, dynamic, beautiful style. No other style, I thought, was worth looking at — not Georgian, not Mongolian, not even French.

[…]

I wished I’d learnt this alternative view of competition earlier in my life. As a competitor, I didn’t think very deeply about the constraints that I was facing, and I didn’t have a coherent strategy to win. I simply thought to myself: “Ahh, the Japanese play beautiful Judo. That’s the best form of Judo, and the only form of Judo worth playing. I want to be like that.” And then I refused to look at other styles.

I was, in other words, a scrub.

J’ai appris des trucs : La notion de scrub, le concept de Shepardizing qui est totalement la bonne description de ma méthode pour vous alimenter en liens (cela il y a une première étape quasi instinctive pour sélectionner le premier article source, et je tenterai de l’expliciter par la suite), et j’ai remis en perspective mon approche dans les jeux, en mission, et dans la vie en général (ce n’est que le début de la réflexion).

You Can't Teach What They Aren't Ready to Know

There’s an old English proverb about leading a horse to water — a proverb that has been in continuous use since the 12th century. Given what we know of how humans learn, we could presumably adapt this saying to more modern concerns: something like “you can lead a student to a mental model, but you can’t get it to take”.

[...]

In the past, when I trained my teammates in Vietnam to understand decorators in Python, or blocks in Ruby, I often came up across the same, uncrossable conceptual chasm. I used to say things like “give it some time”, or “wrestle with it for a little longer”, in the hopes that continuously bashing one’s head against the conceptual wall would lead to an eventual leap in understanding.

Papert suggests something better. From his point of view, because all knowledge is constructed, the best way to teach would be to give a student a series of progressive exercises designed to correct their existing mental models.

C'est une question constante que je me pose quand j'écris un article : comment amener le lecteur des modèles mentaux qu'il possèdent vers celui que je suggère. Et ça implique tellement de choses :

comment expliciter ce que j'ai pu apprendre, c'est-à-dire former un discours
d'où partent les lecteurs, c'est-à-dire se projeter sur les personnes à qui on s'addresse et tenter de s'imaginer leurs modèles mentaux
comment construire l'article pour les emmener du point A au point B

Quand je me relis aujourd'hui je me dis que la route est encore longue.
De façon assez frustrante, je trouve que lorsque j'accompagne quelqu'un, ces étapes peuvent être à la fois faciles à évaluer au cours d'une discussion avec la personne (un public précis qui partage son modèle de façon plus ou moins explicite et un discours qu'on peut adapter à la volée), et facile à oublier en cours de route (pression du contexte, changements d'humeur, ...).

The Mental Model FAQ

At the beginning of 2019, I wrote a series on Putting Mental Models to Practice. That series was an actionable summary of the judgment and decision making literature, and existed as a constructive alternative to my criticism of mental model writing in The Mental Model Fallacy.

This post is a shortened version of the conclusions in my mental models series

[…]

I am a programmer by training. When I read a codebase, I build a mental model of the program in my mind. My brain’s chosen representation is a set of blocks that ‘interface’ with each other. A close friend tells me that his representation is a set of pipes that carry data throughout the program. Our brains may choose different analogues, but the point here is that they are physical in nature, and individually constructed.

[…]

To state this another way, you cannot learn the mental models of experts by studying the frameworks they teach. You must construct it for yourself through practice — perhaps by using their utterances as a guide — but ultimately your own competence has to be built on what you already know.

So, yes, mental models are incredibly useful. If nothing else, they tell you that the valuable bits of expertise is not what is communicable, but what is tacit and stuck inside the practitioner’s head.

[…]

In academia, the cognitive biases and heuristics tradition that was pioneered by Kahneman and Tversky seem particularly well-suited to probabilistic domains (book recommendation: Thinking: Fast and Slow). The naturalistic decision making field is better adapted to regular domains (book recommendation: The Power of Intuition). I sample both in my series, and continue to believe that both domains contain techniques that are useful to the career-minded individual.

Je suis initialement tombé sur ce blog par un article beaucoup acide / coup de gueule, qui m'a parlé et à la fin m’a emmené sur une série plus constructive qui m’ouvre encore un peu plus les yeux sur la façon de transmettre et d’apprendre. Cet article est un aperçu déjà bien pertinent de cette série qui vous dira assez vite s’il y a matière à lire des parts de cette série.

Ça touche complètement cet espace souvent indisponible que l’on rencontre en mission de conseil, le temps de répéter des gestes pour transmettre au lieu de larguer des livrables et grands discours.
Et j’ai la satisfaction supplémentaire à travers cet énième témoignage de me dire que j’avais eu raison de suivre mon intuition en n’écoutant pas ce que mes profs avaient pu me répéter (et qui je le reconnais n’était pas adapté au milieu scolaire), et qui avait été bien synthétisé sur un bulletin par : « Julien se repose trop sur son intuition ».

The Deming Paradox: Operationally Rigorous Companies Aren't Very Nice Places to Work

I’m writing about Deming’s overall philosophy here because of a fundamental tension I’ve noticed the more I’ve dug into his work: the data tools and statistical methods he popularised can and have been used to produce amazing business outcomes with horrible human costs. But the man himself espouses a philosophy that is deeply humanistic in nature. You could argue that his methods are used to produce the former outcomes mostly by ignoring his latter ideas. But I’m not sure how true this is, and I’ll get to that in a bit

[…]

I have a couple of big, unanswered questions at this point. The biggest is whether any company has successfully implemented the entirety of Deming’s business philosophy — both the data driven, operationally rigorous parts, as well as the humanistic, “treat all workers with joy and respect” part, and gotten it all to work. Since Deming’s ideas have found the most acceptance and implementation in Japan, I figure I’ll have to dig into the histories of various Japanese auto companies, which I don’t know a great deal about.

[…]

But it so happens that there is a famous Western company that has adopted Deming’s business philosophy wholesale. That company is Koch Industries, and reading about Deming in Christopher Leonard’s Kochland was perhaps the first indication to me that this entire Deming thing wasn’t some odd management cult from an obscure business guru.

Le début d'un article à suivre, comme l'auteur je n'avais pas cette dimension humaine en tête, et les impacts de la "rigueur opérationnelle" me font également réfléchir à d'autres méthodes/théories/frameworks poussés pour la performance. Dernière en date à laquelle j'ai souscri : Accelerate. L'étude précise qu'elle se préoccupe du bien-être des opérationnels, et explique que le suivi des indicateurs en suivant certains des outils prescrits réduirait les chances de burn-out. Cela dit, Accelerate clame aussi un lien avec PDCA, la roue de Deming. Je me demande à quelle point les objectifs de ce framework sont en opposition, à quel point la réduction du burn-out est seulement possible en suivant le même fondement. L'étude possède-t-elle des blindspots sur le sujet ?

Je n'ai pas creusé plus loin les différents papiers que Nicole Forsgren et ses collègues ont sorti jusque là, mais dans les dernières annonces est apparu :

d'abord le framework SPACE (2021) au sujet de la productivité des devs et qui inclu parmi ses 5 axes : satisfaction et bien être des développeurs, et efficacité et flow
puis le papier DevEx (2023) resserant la mesure sur trois axes : Feedback loops, flow state, cognitive load

Ces deux pages sont plutôt courtes. Ce que je vois cependant c'est que le focus a dévié sur la qualité de travail des développeurs, un aspect moins élaboré dans Accelerate ou les State Of DevOps qui ont suivi, avec d'abord un axe propre au bien-être, puis un focus sur les effets de l'environnement de travail. Ces papiers ne résolvent pas la contradiction potentielle entre le bien être et la roue de Deming, et je ne retrouve pas un aspect qui couplait les métriques Accelerate et devaient garantir la "solidité" du modèle, c'est à dire que ces axes/métriques ne sont pas "en tension", c'est à dire couplé. En somme on pourrait suivre une partie en ignorant le bien-être. Mais de toute façon, quel modèle ne peut être détourné. Le problème est ailleurs.

Feedbacks

Alors au final, est-ce un format intéressant ? Si oui est-ce qu'il donne envie de suivre le site proposé, et sinon est-ce réellement un problème ?

J'ai également pris pour habitude de proposer 4 liens, mais est-ce trop ? Ou cela convient-il ?

N'hésitez pas à me partager quoique ce soit, en réponse à ce mail, par messagerie instantanée, carte postale, ... (oubliez le fax).

Liens du 2 juin 2023

Fri, 02 Jun 2023 00:00:00 GMT

deploy-your-own-saas, How do you cut a monolith in half, #define CTO, Everything’s Broken Everything’s Too Complicated

deploy-your-own-saas

The scryer looks at you with sympathetic
eyes.

"If "the cloud" is just someone else's
computer so let's go with mine then."

Une liste de tout un tas d'alternatives en self-hosting à des solutions SaaS telles que Netflix, Evernote, Dashlane, Google Analytics, Mailchimp, ... C'est intéressant rien que pour constater la diversité des solutions !

How do you cut a monolith in half?

Performance isn’t easy either. You don’t want queues, or persistence in the central or underlying layers of your system. You want them at the edges.

It’s slow is the hardest problem to debug, and often the reason is that something is stuck in a queue. For long and short-lived tasks, we used back-pressure to keep the queue empty, to reduce latency.

When you have several queues between you and the worker, it becomes even more important to keep the queue out of the centre of the network. We’ve spent decades on tcp congestion control to avoid it.

If you’re curious, the history of tcp congestion makes for interesting reading. Although the ends of a tcp connection were responsible for failure and retries, the routers were responsible for congestion: drop things when there is too much.

The problem is that it worked until the network was saturated, and similar to backlog in queues, when it broke, errors cascaded. The solution was similar: back-pressure. Similar to sleeping twice as long on errors, tcp sends half as many packets, before gradually increasing the amount as things improve.

[...]

Pushing work to the edges is how your system scales. We have spent a lot of time and a considerable amount of money on IP-Multicast, but nothing has been as effective as BitTorrent. Instead of relying on smart routers to work out how to broadcast, we rely on smart clients to talk to each other.

Pushing recovery to the outer layers is how your system handles failure. In the earlier examples, we needed to get the client, or the scheduler to handle the lifecycle of a task, as it outlived the time on the queue.

[...]

Be warned: A distributed system is something you can draw on a whiteboard pretty quickly, but it’ll take hours to explain how all the pieces interact.

Un article sur la communication entre les services d'un même système. L'auteur étale d'abord les mauvais usages, puis rappelle comment de vieux problèmes ont pu être résolus au sein de systèmes distribués. C'est truffé de bonnes guidelines.

#define CTO

I joined Stripe as an engineer in 2010. I began by working on the backend infrastructure: designing the server architecture, creating our credit card vault, and producing internal abstractions to make people’s jobs easier. I loved writing code, but I also spent a bunch of time on other things: figuring out our recruiting program, shaping the culture, or making our first T-shirts (which have been banned since we hired our first designer). I wasn’t doing these things particularly because I preferred them to coding: instead, I had a very strong vision of the environment I wanted to be a part of, and I was willing to go out of my way to make it exist.

As time went on, I accumulated more and more responsibilities which were not strictly writing code. As Nelson Elhage liked to put it, my job became full-time “early employee”. My days were filled with writing cultural guides, acclimatizing new people, running our recruiting program, and the like. I’d often think it was time to give up on coding altogether, but I somehow always found a way back to it.

About a year and half ago, we officially declared me CTO. It was really just putting a word to what I was already doing — the most common reaction was “wait, I assumed Greg was CTO already”. This post is the story of what happened next: finding a partner to build our engineering team with, and figuring out my role as the organization changed.

L’histoire d’un CTO qui cherche sa place. Mais au fond je pense que l’histoire, les questionnements, peuvent correspondre à n’importe quel poste de management technique.

Everything’s Broken, Everything’s Too Complicated

It’s not hard to understand either why the hacker-types who spend their days and nights in front of a computer and who make all the decisions about what tools will run your thermostat and phone love it, or why everyone else thinks it’s not for them.

Si vous avez la flemme de tout lire, vous pouvez sauter la première partie en lisant depuis « Not an exception ». Pour résumer la première partie, l’auteur parle de ses difficultés à passer un examen en remote pour sa certification Azure, et de toute la complexité et incidents techniques pour y parvenir. La deuxième partie fait un résumé des déboires, qu'on reconnaitra même en dehors des systèmes d'examen, et c'est tout le sujet. Les systèmes et applications se complexifient, mais malheureusement pas parce que les services à rendre deviendriaent complexes. Je pense que cette tendance est d'autant plus dramatique dans les systèmes publiques comme pour la déclaration des impôts.

Liens du 9 juin 2023

Fri, 09 Jun 2023 00:00:00 GMT

Type-Safe Error Handling In TypeScript, Writing Python like it's Rust, Modern work requires attention. Constant alerts steal it, What are Casual Creators?

Type-Safe Error Handling In TypeScript

Now imagine a month later, you are working on your project when you or a colleague forget to wrap makeHttpRequest inside of a try / catch block.

Two things happen here:

The compiler is no longer able to tell you whether your code is safe from runtime errors. In other words, using throw is not typesafe. And is just as dangerous as any. They both dilute the benefits of using TypeScript in the first place.
Because neither the compiler nor the types tell you that makeHttpRequest can fail (read: throw), you will eventually get a runtime error. This is a waste of time, money and happiness for everyone. People begin to ask why they're using TypeScript if the compiler isn't helping them with something so basic as adding a try / catch block.
So the question is:

How do we encode failability into the typesystem?

First, let's begin by acknowledging that throw is not typesafe. We must use a different approach in order to get the TypeScript compiler on our side.

Un article intéressant sur la gestion des erreurs. Je n’avais jamais vu throw comme n’étant pas "typesafe". Et je réalise que d’autres langages sont dans la même situation et bénéficieraient de l’approche présentée ici, comme python. Même avec des type hints / mypy et tout ce que l’on peu utiliser pour rendre ce langage plus maintenable pour des projets complexe. Et je réalise aussi qu’implicitement j’étais en partie protégé de ce genre de choses en Java, car l’application ne sera pas "compilée" si une méthode contient un appel à une exception qui n’est pas gérée.

La proposition de l’article est intéressante, surtout pour gérer des cas d’erreurs avec le même flow d’exécution qu’un succès, et encore mieux si on a du pattern marching, comme souligné dans les commentaires. Mais comme le disent ces mêmes commentaires, la stratégie "never throw" n’est pas possible lorsqu’on interagit avec des dépendances qu’on ne maîtrise pas. Récemment j’ai fini par abonner une méthode de gestion générale d’erreur à l’événement unhandledException pour attraper et gérer d’une façon ou d’une autre tout ce qui n’est pas connu / géré (le but étant de les mettre en évidence à travers ce « catch all », d’avoir une façon générale et imparfaite de gérer le comportement des ces cas là et de réintégrer progressivement leur gestion au sein de l’application).

Writing Python like it's Rust

To be clear, by “guarantees” I don’t mean memory safety here (Python is reasonably memory safe as-is), but rather “soundness” – the concept of designing APIs that are very hard or outright impossible to misuse and thus prevent undefined behaviour and various bugs. In Rust, an incorrectly used interface will usually cause a compilation error. In Python, you can still execute such incorrect program, but if you use a type checker (like pyright) or an IDE with a type analyzer (like PyCharm), you can still get a similar level of quick feedback about a possible problem.

[…]

One of the sources of this mess is code that tries to track the object’s invariants at runtime. It has to consider many situations that can happen in theory, because they were not made impossible by the type system (“what if the client has been asked to disconnect, and now someone tries to send a message to it, but the socket is still connected” etc.).

[…]

The core of the problem is that the client can exist in various (mutually exclusive) states, but instead of modelling these states separately, they are all merged in a single type.

[…]

Object detection is a computer vision task that I sometimes work on, where a program has to detect a set of bounding boxes in an image. Bounding boxes are basically glorified rectangles with some attached data, and when you implement object detection, they are all over the place. One annoying thing about them is that sometimes they are normalized (the coordinates and sizes of the rectangle are in the interval [0.0, 1.0]), but sometimes they are denormalized (the coordinates and sizes are bounded by the dimensions of the image they are attached to). When you send a bounding box through many functions that handle e.g. data preprocessing or postprocessing, it is easy to mess this up, and e.g. normalize a bounding box twice, which leads to errors that are quite annoying to debug.

Des pratiques top pour du python un peu plus sûr ! Quelques exemples d’application viennent de l’expérience de l’auteur en machine learning, mais ceux-ci peuvent très bien s’utiliser dans les cas plus courants de réalisation de service classique ou BFF.

Modern work requires attention. Constant alerts steal it

On top of that, we regularly juggle multiple tasks simultaneously. Our attention is pulled in multiple directions, regardless of whether you live an inbox zero life or not. Flow states require sustained attention over time, and our days get chopped into pieces by interruptions and meetings. Researchers at UC Irvine found that on average, office workers switched tasks or were interrupted about every three minutes. Recovering from those interruptions could take workers up to 20 minutes to get back to where they were. In fact, these interruptions could cost individuals up to six hours every day.

When we have multiple demands on our attention, we try multitasking—splitting our spotlight or shifting it rapidly to focus on the many tasks that come our way. The truth is, we’re bad at multitasking. There’s a mental cost to switching tasks, and that cost translates to up to 40% more time to complete the tasks. Small errors of inattention slip in—typos, missed cues, and quickly forgotten details. Even trying to do only two things at once can mean you do both badly.

J’ai placé celui-ci, assez court, ici rien que pour avoir les chiffres sous la main. Je compte les dégainer sous peu dans ma mission : le backlog n’est pas respecté par qui que ce soit, quand un sujet est considéré important il est traité comme urgent, et plusieurs contacts par messagerie asynchrone attendent une réponse synchrone. Adieu la concentration.

What are Casual Creators?

Why hasn’t anyone identified this field yet?

Partly, audience. Though there are exceptions, this field has traditionally been sold as a young, or female, which is a recipe for not being taken seriously by either academics or software engineers. It’s easy to spot a parallel with the field of casual games: both get derided as the amusements of “housewives” and “children”, as though these humans are less worthy of entertaining than…say, 26 year old male games engineers (or that engineers don't want to be playfully creative). Like casual games, they are often simple, and designed for short periods of engagement, rather than long term mastery, so those who have spent years mastering an extensive and arcane interface, whether Maya or Final Fantasy, are not often enthusiastic about something that attempts greater simplicity at the cost of reduced control.

But it’s also an economic problem.

Remember that part of the definition of a casual creator is “privileges enjoyment of the creative process above productivity”. Most of the creativity tools, like Maya, GarageBand, Photoshop, and Final Cut Pro, were designed for professional people who were trying to get work done. They are priced astronomically because they are sold, not to people, but to corporations who want their employees to do more work. Even a self-employed designer will not turn to a client and say “You know, I couldn’t really make the exact website you asked for, but I’ve made something surprising and I feel great about myself” and expect payment. It’s also telling that a lot of the creativity research is sponsored by the military, with the goal of enhancing workflow and generating better ideas.

This economic view creeps into our definitions of creativity.

Creativity is any act, idea, or product that changes an existing domain, or that transforms an existing domain into a new one.

Well, that takes care of all our world-changing creatives, those producers of creative acts of great cultural, social, and usually economic, significance. But we colloquially use “creativity” for many more situations than a universally novel, globally significant act of creation. We speak of children being creative, of moments of creative problem-solving in our daily lives, of creativity in art therapy or as a hobby.

[…]

To cite wallpaper designer, socialist and futurist, William Morris, we are creative so that “our days will be happy and eventful.” We can scientifically demonstrate that people who do art therapy are happier, healthier, more at ease, less in pain, and more social after having a creative experience. The existence of pottery-painting and paint-by-numbers kits shows proof that people enjoy being creative, even if the world won’t be noticeably changed by their output. It also turns out that restrictions, constraints, and support structures and guided assistance don’t fundamentally undermine the creative process, but often enhance it.

So if this type of human activity already exists, why make software for it? And why write about that software? As happens when any activity it translated into software, a potentially huge new world of possibilities arise that would not have been possible while then activity remained non-digital, but in many ways, it continues to fill the same niche. Chess became computer chess, but then also became Call of Duty and League of Legends, products that would not have been possible without the exploration of possibilities that were exposed when the desire for tactical competition made the jump to the digital space.
And why write about it? Because this period of translation and exploration has just begun for Casual Creative software. It remains uncategorized, falling into a half-dozen different categories on the app store. The focus of thinkers and researchers, both in academia and in industry, remains focussed on “creativity support tools” and the broad, professional productivity tools, like Maya and Photoshop, while this area remains unexamined. And, for a field of such seemingly simple pieces of software, there’s a lot to examine.

Un article à part sur les outils et la créativité, ou plus spécifiquement sur les outils qui n’ont pas vocation à servir une quelconque productivité

Liens du 16 juin 2023

Fri, 16 Jun 2023 00:00:00 GMT

Productivity is unproductive, Monoliths are not dinosaurs, Ctrl-Zine Issue 3, The Coaching Habit – Say Less, Ask More & Change the Way You Lead Forever

Productivity is unproductive

I went on a solid system clean-out over the holiday, but I noticed something interesting - as I got to inbox zero across all my various buckets, instead of feeling like I had made space for real creative projects (like writing this blog), I found myself missing that mini dopamine hit of clearing items off my lists, and kept revisiting inboxes instead of actually doing real sh**. This is especially pathological given that we now live in a world of limitless input, with literally thousands of hours of new content, writing, videos, podcasts being created every minute.

[…]

If you could just get organized, you'd put all the little tasks in the container and then you'd have plenty of time left to tackle all the big important things. It always feels like with just a bit more effort you'd finally get to the end of your to-do list once and for all. But that's not how to do lists work, and that's not how time works. The list is infinite, and time isn't a container, it's just one present moment after another.

[…]

It can in fact be a relief to realize this, to see that the goal is structurally impossible, and therefore that it's reasonable to disconnect your self worth from checking off all the things. There's this idea that if you finally get through doing this or that, your real life will finally begin, that there will be this moment where the dress rehearsal will end. But this isn't a rehearsal. This is it. This is your life. So paying attention to it right now is sort of all we've got.

Et bim. Un article bien court qui met des claques. J’en ai encore supprimé quelques trucs de mon téléphone et abonnements.
L’auteur pose également des questions et suggère des méthodes pour s’aider à se libérer.

Monoliths are not dinosaurs

However, I want to reiterate, that there is not one architectural pattern to rule them all. How you choose to develop, deploy, and manage services will always be driven by the product you’re designing, the skillset of the team building it, and the experience you want to deliver to customers (and of course things like cost, speed, and resiliency). For example, a startup with five engineers may choose a monolithic architecture because it is easier to deploy and doesn’t require their small team to learn multiple programming languages. Their needs are fundamentally different than an enterprise with dozens of engineering teams, each managing an individual subservice. And that’s okay. It’s about choosing the right tools for the job.

There are few one-way doors. Evaluating your systems regularly is as important, if not more so, than building them in the first place. Because your systems will run much longer than the time it takes to design them. So, monoliths aren’t dead (quite the contrary), but evolvable architectures are playing an increasingly important role in a changing technology landscape, and it’s possible because of cloud technologies.

Un court article du CTO d’Amazon, en réaction aux réactions suite à l’annonce du passage d’une archi distribué à une unité de déploiement pour une équipe d’Amazon. J’espère qu’on s’en rappellera la prochaine fois qu’ils feront les éloges d’un nouveau style architectural ! (bien sûr ça s’achève par une promotion des vertus du cloud)

Ctrl-Zine Issue 3

The tools of the original internet are still here for us, carefully preserved and maintained by those who never stopped finding them useful, and anyone can pick them up and start learning. Find an old computer you no longer use, or buy one locally or from the internet. Install a lightweight version of Linux on it- the process is easy, and the right one will run just fine. Write a website using simple HTML, or one of the many alternative protocols, and host it from your home. Domain name optional. Join a tilde and learn how to navigate around a commandline. Most of all, relax and have fun.

The pioneers of our field kept this software free for a reason.

Pour changer de format: un zine pas bien long et pas prise de tête.

The Coaching Habit – Say Less, Ask More & Change the Way You Lead Forever

In trying to be helpful, high performers become unhelpful and would be better served by focusing on developing their coaching habit instead. Though often they tend to rather create a dependency on themselves, becoming a bottleneck and unintentionally they fail to unlock the potential in others.

This is particularly detrimental when high performers (as they tend to) become managers, they end up doing too much of the deliverable or task themselves. Similarly, a manager becomes overly reliant on one or two high performers. They default to asking the high performers, instead of extending the development opportunities more widely. This is what I have heard termed as performance punishment, being punished with an excessive workload as a reward for performing well. Additionally, the reality is that high performers tend to have more options to leave, so it’s a risky strategy.

Un modèle descriptif d'expert qui s'isole, suivi d'un modèle prescriptif pour sortir de cette isolation et connecter avec le reste de l'équipe pour tendre vers son autonomie.

Liens du 23 juin 2023

Fri, 23 Jun 2023 00:00:00 GMT

Full Time, On discovery and consumption, When We Lose Autonomy—Whose Life Are You Living?, Modern software quality, or why I think using language models for programming is a bad idea.

Full Time

I started this work just to see how far I could take it. Building an Internet search engine was such a ridiculous thing to attempt, it was such an obvious truth that it couldn’t be done…

Plus belle découverte de la semaine.

Je n'arrive plus à trouver ce que je veux par Google. C'est bêtement devenu une méta-marketplace. Depuis le début de cette Newsletter et avant ça pour ma veille personnelle, je passe par d'autres moyens pour explorer des sujets activement, sans attendre que ça tombe dans ma boite (même si je n'exclue pas ce que je peux y trouver d'intéressant), en sautant de sites en sites. Mais lorsqu'il s'agit d'explorer un sujet précis, je me retrouve vite contraint par mes sources. J'en suis venu a monter un moteur de recherche maison qui fonctionne à peu près, mais qui m'a tout de même permis de découvrir par hasard plus de contenus intéressants qu'à travers les moteurs classiques.

Et voici que je tombe sur Marginalia search. Le mode recherche ressemble beaucoup à la façon dont j'utilisais Google vers 2007 : une suite de mots clés que je voudrais voir ressortir dans une page (et il donne même la position dans la page !). Et ça fonctionne au top ! Une autre fonction que je trouve géniale, c'est que le moteur permet de ne filtrer que les résultats provenant de blogs et sites personnels, ce qui permet de trouver largement moins de contenus commerciaux, beaucoup plus de retours d'expérience et de points de vue d'experts.

Dans cet article, l'auteur explique qu'il passe à plein temps sur le développement de ce moteur.

On discovery and consumption

I was reading this article earlier today and it got me thinking about something that I have never considered before. One major change the web has experienced was the consolidation of discovery and consumption. Digg was—and still is—a place to discover new content but the consumption of that content takes place away outside of Digg.

And the same was true for discussions around the content. Those used to happen in comment sections spread across the internet. But now, places like Twitter or Instagram are acting as places for both the discovery and the consumption of new content.

Un article très court, vous venez d'en lire la première moitié, et qui donne une perspective sur l'évolution des plateformes de contenu. Reddit est cité en exemple de ce qui ressortirait du lot, mais comme on le verra dans la newsletter de la semaine prochaine, les choses ont changé.

When We Lose Autonomy—Whose Life Are You Living?

"Your heart sees the important things in life, but your eyes don't see them."

The message is a fantastic reminder of how adults tend to bind themselves with a narrow view of the world.

Optimizing a function against an observable objective is easy. Just take a global average, and follow what the greatest majority agrees. On the other hand, no one, except yourself, can define a metric that measures your happiness. In fact, it is easier to make ourselves "busy," avoid a conversation with oneself, and list many reasons not to act, because everyone does so. This is when humans lost their autonomy. But busy for what? We already have (and can do) more than we think, and the key may have been right in front of us since a long time ago.

Speaking of adult life, understanding the nature of aging might help us to be autonomous agents. In From Strength to Strength, social scientist Arthur C. Brooks highlighted that our intellectual performance peaks out much earlier than we think, and life transitions to its second phase as early as in our 30s. In the later phase, people need to cultivate spiritual life and deep relationship with surrounding people, and the effectiveness is proven by social scientific studies7. Otherwise, we end up with workaholics and success addicts as many "successful" but unsatisfied people are. Be careful: our eyes don't see the most important things in life regardless of how hard we work.

Sur la boulimie de l'information normée et son influence sur nos vies.

Modern software quality, or why I think using language models for programming is a bad idea

We are a mismanaged industry that habitually fails to deliver usable software that actually solves the problems it’s supposed to.
Thus, Weinberg’s Law:

If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.

It’s into this environment that “AI” software development tools appear.

The punditry presented it as a revolutionary improvement in how we make software. It’s supposed to fix everything.
—This time the silver bullet will work!

[…]

If you were ever wondering if we, as an industry, were capable of coming up with a systemic issue to rival the Y2K bug in scale and stupidity? Well, here you go.

You can start using a language model, get the stock market bump, present the short term increase in volume as productivity, and be long gone before anybody connects the dots between language model use and the jump in defects.

Even if you purposefully tried to come up with a technology that played directly into and magnified the software industry’s dysfunctions you wouldn’t be able to come up with anything as perfectly imperfect as these language models.

It’s nonsense without consequence.

Sur l'utilisation de l'IA pour l'assistance au développement. Même si cet aspect de vous intéresse pas, je vous conseille vivement de lire le premier cinquième de l’article (jusqu’à la section sur le management donc).

Liens du 30 juin 2023

Fri, 30 Jun 2023 00:00:00 GMT

A manager should multiply, not add, On the Normalization of Deviance, Answering machines, Tech's Reckoning

A manager should multiply, not add

If you are managing a team of people that are transporting rocks from A to B and you spend one hour picking ups rock from A and dropping them on B, you added one hour of work. If you spend that one hour procuring wheeled carts so that people don’t have to carry rocks on their backs, you increased their performance by 25% (and happiness). One task makes you an adder, one makes you a multiplier.

Très court article. Y reconnaissez vous des managers ?

On the Normalization of Deviance

As testers, we must remain alert to any symptom, anything that seems out of place, a hissing sound, a grinding sound, an inconsistency, missing text, or a starter that sometimes doesn’t work.

[…]

This — missing user data from a different day — seems to be evidence of a more systemic problem. To a tester, the fact that some message notifications seem to be displayed properly is unremarkable. The important thing is that some don’t.

[…]

The Challenger flight is an excellent example. There are several references to flights that had gone before. The acceptance and success of these flights is taken as evidence of safety. But erosion and blow-by are not what the design expected. They are warnings that something is wrong. The equipment is not operating as expected, and therefore there is a danger that it can operate with even wider deviations in this unexpected and not thoroughly understood way. The fact that this danger did not lead to a catastrophe before is no guarantee that it will not the next time, unless it is completely understood.

[…]

Dear testers, and dear developers: can work does not mean does work, and seems to work now does not mean will work later. A problem that appears briefly and seems to go away is evidence that we have an inconsistent system. That’s not an invitation to shrug; it’s a motivation to investigate.

Un article du fameux testeur Michael Bolton. Je crois que j’ai vu ce qu’il décrit dans chacune de mes missions. Sur la dernière, chacun des 30 composants du SI montre ce genre de signaux.

Answering machines

Google has been around for almost 25 years. That is an eternity when it comes to the digital world. And Google was not the first engine to go online: from AltaVista to Yahoo! to Lycos we had our fair share of search engines available to search the web. Right now, the search engine world is going through a weird phase. And that's because AI has descended upon us. Bing with GPT, Google with Bart, it seems like the AI revolution of search engines is inevitable.

But I'm wondering, at what point a search engine stops being that and becomes something else?

Un article ultra-court (vous venez d'en lire la première moitié).

Tech's Reckoning

Venture capital is the one that set these valuations, venture capital is the one that incentivized and propped up bad companies while letting others languish, and venture capital is the one that is refusing to invest as a result.

This is also being framed as a new problem, versus the natural result of over a decade of bad companies receiving ungodly amounts of money. Color raised $41 million for a niche social app in 2011 before shutting down a year later. Clinkle raised $25 million for their sound-based payments app in 2013, shutting down three years later because it never really had any kind of product to speak of, but not before creating the best/worst tech advert of all time. Theranos raised over $700 million for a non-existent product and its founder went to jail. WeWork raised over $20 billion, never turned a profit, and now has a market cap of less than $500 million — and yet its founder Adam Neumann was able to raise hundreds of millions of dollars for another company.

Blue Apron, a meal kit company) that never turned a profit (outside of the pandemic), raised $193 million of venture capital, went public at a $1.89 billion valuation in 2017, has had to raise over $200 million of post-IPO funds, and as of writing has a market cap of $41.5 million. Its CEO said last year that profit is “only a goal over the long term.” The Honest Company, an unprofitable home goods store with little or no differentiation other than being founded by Jessica Alba, raised over $500 million of venture capital and was able to IPO for $1.4 billion in 2021. Its current market cap is under $160 million.

Venture has been incentivized for years to create shambling “growth” companies that can be acquired by big firms that don’t think too much about what they’re buying, or dumped onto the public markets. The problem is that the markets themselves — as rotten as their incentives may be — have shown an intolerance for the lack of basic business acumen that most startups seem to have. An alarming amount of venture capital isn’t being invested to create good or sustainable or reliable or even public-ready companies, but obtuse stores of value that burn cash and lock up talented tech workers looking to vest their stocks.

Tiens ça me rapelle un intervenant dans l'école dans laquelle j'étudiais. Il m'avait choqué quand il nous a dit en 2011 : "Devenez des serials entrepreneurs ! Créez des boites et revendez-les !"

L'article mentionné au début est pas mal aussi !

Liens du 8 juillet 2023

Sat, 08 Jul 2023 00:00:00 GMT

Hier j'ai eu un petit souci technique de publication, et je n'ai pas eu l'énergie de le creuser après une journée bien blindée. Ainsi commencent les premiers liens du samedi!

Au menu : Mockingjay process injection technique allows EDR bypass, The Small Stuff, Blog with Markdown + Git and degrade gracefully through time

Mockingjay process injection technique allows EDR bypass

For our proof of concept, we specifically chose the ssh.exe process located in the Visual Studio directory to inject our payload. It is important to note that in this injection method, there is no need to explicitly create a thread within the target process, as the process automatically executes the injected code. This inherent behavior makes it challenging for Endpoint Detection and Response (EDR) systems to detect this method.

C’est si « bête », et du coup si génial.

The Small Stuff

For three days and nights the Java master did not emerge from his cubicle. On the fourth day the monks of the temple sent a novice to inquire after him.

The novice found the master at his whiteboard, contemplating a single dataflow diagram. The novice recognized it as a minor component of the vast system that the monks were contracted to maintain. Politely, the novice asked what the master was working on.

De la fiction à propos de concepts sur le développement de logiciels écrite sous forme de koans. Assez reposant et drôle. Chaque koan est bien court. À lire à votre rythme.

De-Googling

Punishment for cancelled subscriptions

[…]

Since I deactivated my Workspace account, I’ve noticed that Google regularly tries to push me to reactivate the account.

[…]

There are a few things that make this a particularly dark pattern:

This happens even when I’m trying to access services that are openly available to users without a Google account, like Google Translate.

I’m simultaneously signed into several Google accounts, but Google always defaults to the ex-Workspace account.

When I try to switch account from this page, I’m redirected to the admin.google.com interface, which is only available to Google Workspace accounts. This makes it difficult to switch to a non-Workspace account.

[…]

This anecdote serves as a frequent reminder not to use Google at all.

Quelle bande de pourris.

Blog with Markdown + Git, and degrade gracefully through time

A simple proposal I’d like to make to current and future blog authors: run your blog in whatever technology you want […] But, remember at the end of the day that a blog is text and multimedia. Store your content in the simplest formats in which it can possibly be stored – I’d suggest Markdown and Git – and use the great frontend to read from that and render it however you want.

Exactement ce sur quoi ce blog repose. Ce qui construit le blog est custom, et plutôt light.
En revanche mon plus grand problème c’est la technologie sur laquelle repose la Newsletter. J’utilise majoritairement mon mobile pour toutes les étapes, de l’écriture à la publication. Cependant il arrive (trop) fréquemment que le service de mailing échoue, et l’interface responsive est absolument horrible en version mobile. Quand j’aurai regagné un peu d’énergie, je vais chercher à m’en débarrasser.

Liens du 14 juillet 2023

Fri, 14 Jul 2023 00:00:00 GMT

.io domains considered harmful, A Quick Primer on Robert "Uncle Bob" Martin, Good Practices For Supply Chain Cybersecurity, Stop Ignorance in Testing

.io domains considered harmful

             recap.
ethos capital was formed
    to raise money
       to buy and profit from the .org domain
which has historically been not-for-profit
    and had a price ceiling
       but they were stopped 🥳
but they got pissed and bought some other domains 😠
    and now, ethos capital owns .io

[...]

1967: the USA asks the UK to expel the native Chagossians from the chagos
archipelago

* the chagos archipelago is - you guessed it - within
  the british indian ocean territory

* the UK obeys and expels the native Chagossians

1971: the USA builds a military base on the chagos archipelago

* since 1971, the chagos archipelago has _only_ been inhabited by
  employees of the US military - everyone else is forbidden.

[...]

2021: the Chagossian Refugees Group submits complaint against paul kane and
ethos capital, seeking repatriation of $7m/year for the .io domain

Ah ... du coup j'ai fait un quick check sur Wikipedia :

Paul Kane is chief executive of the British technology firm CommunityDNS and from 2010 to 2017 was one of seven people entrusted with a credit card-like key to restart portions of the World Wide Web or internet which are secured with DNSSEC, after a catastrophic event such as a major security breach or terrorist attack. If such a situation arises, five keyholders will travel to the United States to meet up and restart the DNSSEC system. Kane runs ICB, registrars for the controversial .io ccTLD.

Wikipedia

Le gouvernement américain ayant exigé au cours des négociations un « contrôle exclusif », le gouvernement britannique entreprend d'expulser peu à peu les Chagossiens, habitants autochtones de l'archipel : interdiction de retour après un voyage, restriction de l'approvisionnement en nourriture et en médicaments, empoisonnement et gazage de tous les chiens, etc. En 1973, les derniers habitants sont déportés par cargo vers les Seychelles et l'île Maurice [...] Au début du mois de janvier 2023, le Royaume-Uni accepte de participer aux négociations avec Maurice28.

Wikipedia

A Quick Primer on Robert "Uncle Bob" Martin

If you respect and follow Martin's work, I think it's worth evaluating why that is, and I hope that this post will help you in doing so.

Je ne vais pas divulgâcher les incohérences techniques, c'est la partie qui m'a le plus intéressé dans cet article. J’ai lu son livre Clean Code il y a longtemps, et je n'avais pas l’esprit critique et ni le personnage en tête. J’ai cependant fini par ne plus le considérer à cause de ses opinions et son mode d’expression culpabilisant. En revanche je ne savais pas à quel point il pouvait être techniquement à côté de la plaque …

Good Practices For Supply Chain Cybersecurity

Among the findings the following points are observed.

86 % of the surveyed organisations implement information and communication technology / operational technology (ICT/OT) supply chain cybersecurity policies.

47 % allocate budget for ICT/OT supply chain cybersecurity.

76 % do not have dedicated roles and responsibilities for ICT/OT supply chain cybersecurity.

61 % require security certification from suppliers, 43% use security rating services and 37% demonstrate due diligence or risk assessments. Only 9 % of the surveyed organisations indicate that they do not evaluate their supply chain security risks in any way.

52 % have a rigid patching policy, in which only 0 to 20 % of their assets are not covered. On the other hand, 13.5 % have no visibility over the patching of 50 % or more of their information assets.

46 % patch critical vulnerabilities within less than 1 month, while another 46 % patch critical vulnerabilities within 6 months or less.

The report also gathers good practices on supply chain cybersecurity derived from European and international standards. It focuses primarily on the supply chains of ICT or OT. Good practices are provided and can be implemented by customers (such as organisations identified as essential and important entities under the NIS2 directive) or their respective suppliers and providers. The good practices cover five areas, namely:

strategic corporate approach;

supply chain risk management;

supplier relationship management;

vulnerability handling;

quality of products and practices for suppliers and service providers.

Finally, the report concludes the following.

There is confusion with respect to terminology around the ICT/OT supply chain.

Organisations should establish a corporate-wide supply chain management system based on third party risk management (TRM) and covering risk assessment, supplier relationship management, vulnerability management and quality of products.

Good practices should cover all various entities which play a role in the supply chain of ICT/OT products and services, from production to consumption.

Not all sectors demonstrate the same capabilities concerning ICT/OT supply chain management.

The interplay between the NIS2 directive and the proposal for a cyber resilience act or other legislation, sectorial or not, which provides cybersecurity requirements for products and services, should be further examined.

ICT : Information and Communication Technology
OT : Operational Technology

Un rapport (plutôt long si on lit la partie good practices) sur la sécurité des supply chain d'entreprises/services critiques en europe. Rien que le résumé est intéressant. Les graphes qui suivent ne sont pas tous très lisibles.

Stop Ignorance in Testing

Scripted testing… There are so many things wrong with it, its hard to know where to begin. Many test experts and prolific bloggers have written about this theme, therefore there is an abundance of literature about topics such as scripted testing vs. exploratory testing out there.

The highest form of ignorance is when you reject something you don’t know anything about. Wayne Dyer
ST is like an old wives’ tale, an urban legend, something that gets passed down from generation of testers to generation, and gets propagated and perpetuated due to the ignorance of testers everywhere. I was once an ignorant tester myself, who like many others learned from another unenlightened tester that the way to test is to write countless numbers of test scripts, with detailed steps, which will be diligently reported upon daily and you will get a gold star if you execute the pre-set quota of test cases for the day.

In this day and age however, there is no excuse to be uninformed about anything,

Un article court qui finit par des (bonnes) références sur le test exploratoire.

Liens du 21 juillet 2023

Fri, 21 Jul 2023 00:00:00 GMT

How to feel more productive after moving from coder to manager, Yes, You Should Estimate Software Projects, Is CSS Turing Complete, More, Not Less, Regeneration and Reframing

How to feel more productive after moving from coder to manager

at the end of a day coding, I could look back at my code and feel productive, whereas at the end of a day managing, mostly meetings, I felt exhausted and with nothing to show for.

I’ve been managing for 10 years, taking over and building teams from scratch, being hands on and hands off and that feeling of not being productive is rarely there and I think there’s one habit that I have that helps a lot and I highly recommend it to all managers: write down notes.

Sur ma dernière mission c'est probablement ce que je pouvais faire de mieux, et effectivement c'est l'une des rares activités qui me donnaient l'impression d'être utile (d'autant plus que peu s'y collaient et nombreux oubliaient les contenus des nombreuses réunions).

Yes, You Should Estimate Software Projects

Giving estimates, than missing them forces deeper reflection and faster learning about the types of unknowns in the software world. When it comes to why estimates are difficult, most engineers and engineering leads throw their hands up in the air and say, "Software has too many unknowns! We can't tell what unknowns we'll find, even with the simplest task!" This is how I thought, when I started out. But when you end up giving estimates, then miss them by a large margin, you cannot avoid having an honest conversation with yourself and your team. What did we miss? Why did we miss it? How can we try to account for it, the next time?

Vécu et vérifié. En 2018, l'un des clients pour lequel je (et l'un d'entre vous aussi ^^) bossais avait besoin de reprendre son site avant un évènement critique. Critique dans le sens : ce seul évènement remplissait l'essentiel des caisses sur l'année. Chaque année ce même évènement avait lieu, et les besoins d'aménagement d'infrastructure physique pour cet évènement rendait impossible tout décalage de date.

Nous avons travaillé avec des estimations, une roadmap sur 8 mois a été établie, et ce faisant nous avions toutes les informations pour comprendre que nous devions traiter nos risques dès le premier sprint. Tous les mois, nous recommencions l'exercice de réestimation de tous le backlog, au regard des évolutions du système actuel, des tâches à venir qui avaient plus ou moins changé en fonction des apprentissages métier et techniques. Dit comme ça, ça peut paraitre long et complexe, mais l'exercice ne durait pas plus de 2h pour les devs, un peu plus pour les PO qui devaient préparer le terrain et le synthétiser.

Les plus gros risques ayant été traités au plus tôt, la tension n'a eu lieue qu'au début lorsqu'il s'agissait de s'ajuster sur le plus structurant, mais très vite, notre client et nous-mêmes étions de plus en plus à l'aise, sereins, que nous atteindrions la cible avec le bon produit, fini pour l'évènement, et prêt à accueillir les évolutions des années à venir : oui sans la charge mentale d'une dette à rattraper après l'évènement.

Je vais partager le point de vue d'un collègue sur le sujet "no estimates" : c'est possible et souhaitable d'utiliser cette méthode lorsque vous vous êtes rendus capable de découper suffisamment finement toute tâche jusqu'à ce qu'elles soient toutes petites et de la même taille. L'avantage de ce petit découpage c'est que l'on évite les effets tunnel, réorienter le travail devient beaucoup plus simple. Et ce qui est amusant de fait, c'est que cela permet, malgré ce qu'indique le nom, de faire des roadmaps pour réajuster la trajectoire. Car oui, le travail d'estimation doit tout de même avoir lieu, autrement comment saurait-on qu'une tâche est petite et de la même taille que les autres ?

Is CSS Turing Complete?

Okay, now we are going to make a big jump, and I haven’t quite connected the dots enough to explain it in my own words, so here is a blanket statement and some sources:

Rule 110 is a cellular automaton (we’ll get to that in a moment) that is capable of universal computation and is therefore Turing complete.

I don’t entirely understand how cellular automata are capable of computation, but apparently there are systems modeled after certain automata and those systems are Turing complete. At least, according to this Stack Overflow thread that references this research paper that I did not read.

So, from what I can gather, Rule 110, is a kind of litmus test for Turing completeness: if the language can encode Rule 110, then it is Turing complete.

Parce qu'elle le pouvait ? C'est amusant et en même temps intéressant. Ses autres articles sur le CSS comme langage de programmation sont pas mal aussi !

More, Not Less: Regeneration and Reframing

As I’ve mentioned a few times, the Montreal Protocol to reduce CFCs and repair the ozone layer likely succeeded not because corporations suddenly became altruistic, but because ready—and profitable—substitutes existed.

[...]

After many years of losing ground on the climate-change front, the approach that will (finally!) work is to replace things people don’t like with things they do like, and to replace carbon-heavy things people do like with things they like even more. That’s a trade-off people will make. It works with human nature, not against it.

De toute évidence, la stratégie actuelle ne paie pas. Alors pourquoi pas ?

Liens du 28 juillet 2023

Fri, 28 Jul 2023 00:00:00 GMT

GPT-4 and professional benchmarks, the wrong answer to the wrong question, How V8 JavaScript engine works step by step [with diagram], Unclogging the Bug Pipeline, CSS property order

GPT-4 and professional benchmarks: the wrong answer to the wrong question

As further evidence for this hypothesis, we tested it on Codeforces problems from different times in 2021. We found that it could regularly solve problems in the easy category before September 5, but none of the problems after September 12.

In fact, we can definitively show that it has memorized problems in its training set: when prompted with the title of a Codeforces problem, GPT-4 includes a link to the exact contest where the problem appears (and the round number is almost correct: it is off by one). Note that GPT-4 cannot access the Internet, so memorization is the only explanation.

[…]

Because of OpenAI’s lack of transparency, we can’t answer the contamination question with certainty. But what’s certain is that OpenAI’s method to detect contamination is superficial and sloppy

[…]

On top of this, professional exams, especially the bar exam, notoriously overemphasize subject-matter knowledge and underemphasize real-world skills, which are far harder to measure in a standardized, computer-administered way. In other words, not only do these exams emphasize the wrong thing, they overemphasize precisely the thing that language models are good at.

Un regard critique sur les études de performance des versions de GPT et autres modèles.

How V8 JavaScript engine works step by step [with diagram]

From a high-level view, the V8 JavaScript engine execution consists of 5 steps.

Initialize environment in the host

Compile JavaScript codes

Generate bytecodes

Interpret and execute bytecodes

Optimize some bytecodes for better performance

V8, moteur d'exécution de Javascript au sein de Chromium mais aussi de NodeJS, under the hood comme on dit. Notez les deux pointeurs eux aussi intéressants "how the call stack works" et "the event loop"

Unclogging the Bug Pipeline

Let’s call that the “kinetic” model of the test process. There is truth to that model, because we can ask “why don’t the bugs just fall right out when we want them?” The answers to that are interesting and deep. The product, the tester, and the test process itself— all these things together— can be thought of as a sieve with different filters that can block the good bugs from being reported. Part of testing well is to keep those filters unclogged. But they are not just filters, they are also steps in a chain of evidence. When you report a bug you are reporting an unbroken chain of reasoning that spans “this is a problem that matters” back to “this exists.”

[...]

Since it is both a sieve and a chain, let’s call it something that evokes both ideas: a bug reporting pipeline. Let’s look closely at it and how it can go wrong.

Un article top d'un acolyte de Michael Bolton par lequel j'ai beaucoup appris sur la complexité humaine, technique et organisationnelle que rencontrent les testeurs. Je pense que c’est autant utile de comprendre ce qu’il se passe durant cette phase pour mieux préparer les choses en dev et design.

CSS property order

CSS property order matters, especially on larger teams with several engineers and designers all contributing code. I know it’s been discussed, but frankly there’s always room for improvement and alternate approaches.

Testé et approuvé. On a utilisé cette approche sur quelques missions où nous n'avions pas de framework qui change fondamentalement la façon d'écrire du CSS (spécifiquement PostCSS, permettant d'écrire du CSS3 avec quelques améliorations qui transpile pour rendre compatible avec tout type de navigateur). C'est d'autant plus jouable en utilisant un linter de css qui permet de faire du fix à notre place comme stylelint.

C'est d'ailleurs ce qu'utilise ce blog : PostCSS avec une poignée de plugins(la conf a légèrement évolué depuis), et le linter stylelint avec le plugin stylelint-config-recess-order. J'utilise notamment la configuration avancée dans cette page pour avoir un retour à la ligne entre les sections.

L'avantage c'est que lorsqu'on tombe sur CSS qu'on a pas écrit, la structure et l'ordre des propriétés étant strictement les mêmes sur toute la base de code, on s'y retrouve très facilement. Au point où, même sur des projets au style très sur mesure, le style est absolument maitrisable sans framework.

Liens du 4 août 2023

Fri, 04 Aug 2023 00:00:00 GMT

How to Kill a Decentralised Network (such as the Fediverse), I'm betting on HTML, Retrieving your browsing history through a CAPTCHA, Tout savoir sur les Design Systems

How to Kill a Decentralised Network (such as the Fediverse)

What Google did to XMPP was not new. In fact, in 1998, Microsoft engineer Vinod Vallopllil explicitly wrote a text titled "Blunting OSS attacks" where he suggested to "de-commoditize protocols & applications […]. By extending these protocols and developing new protocols, we can deny OSS project’s entry into the market."

[...]

This anecdote was told Glyn Moody in his book "Rebel Code" and demonstrates that killing open source and decentralised projects are really conscious objectives. It never happens randomly and is never caused by bad luck.

[...]

Those bugs, together with political lobbying, were one of the reasons that pushed the city of Munich to revert its Linux migration. So yes, the strategy works well. Today, docx, xlsx and pptx are still the norms because of that. Source: I was there, indirectly paid by the city of Munich to make LibreOffice OOXML’s rendering closer to Microsoft’s instead of following the specifications.

[...]

People who don’t know history are doomed to repeat it. Which is exactly what is happening with Meta and the Fediverse.

Un article sur la stratégie employée par Google, Microsoft et probablement bientôt Meta pour éliminer des initiatives qui leurs feraient de l'ombre. La suggestion de fin ne me satisfait pas plus, elle continue d'aller dans la direction d'un même article que l'auteur a écrit "Splitting the web" où il explique que c'est pas grave si la scission continue, et qui pour moi va dans le sens d'un creusement d'inégalité d'une part (ceux qui restent du côté non tech savvy deviennent victimes d'un écosystème qu'elle ne comprennent pas et ne peuvent s'en extraire), et d'autre part je pense que la tendance peut saboter les moyens et fondations des logiciels libres. Pour donner une image plus dramatique, ça me fait craindre un scénario du type décrit dans "Les Furtifs" de Alain Damasio où au final les corporations detiennent jusqu'aux infrastructures de communications, un espace où la non confirmité à des règles commerciales équivaut à de l'illégalité, punie par une déchéance d'accès à des services (non sans rappeler aussi l'épisode "Nosedive" de Black Miror).

I'm betting on HTML

At its core, the internet is used to transmit data that helps humans interact with the world as they perceive it. The freedom that HTML/CSS/JS provide is a double-edged sword because access to data has become limited. Instead of open and accessible data formats and APIs, we’re kept within the walled gardens of major technology companies that operate mass social media sites. Because of this, interoperability between these platforms is effectively impossible, further complicated by these companies’ hesitance to allow easy data porting. After all, that’s their entire product, and without it, they can’t make money. The recent instability of our social media sites has renewed interest in decentralized platforms like the “fediverse”. Both Meta’s Threads and Jack Dorsey’s (Twitter founder) Bluesky claim interoperability with the larger fediverse. This is great!

But guess what? The general population doesn’t care!

Court article qui repasse sur de "nouveaux" éléments HTML. Ce que j'aime avec ce type d'article c'est qu'on a encore la démonstration qu'on peut avoir des pages esthétiquement suffisantes, avec des composants riches, sans besoin d'une usine à gaz en Javascript. Juste avec du HTML. Je pense sincèrement que l'on devrait repenser notre approche lors du développement de sites/applications web. Quelque chose du type vanilla-first. Et comme j'imagine que l'idée n'est pas neuve, en fouillant juste un peu : Vanilla first

Retrieving your browsing history through a CAPTCHA

Proof of concept history sniffing, where visitors do the hard work.

[...]

You might already be thinking of various ways to exploit this, perhaps using background-images to send GET requests to a server, or maybe by using window.getComputedStyle to get the colour of a link.

Unfortunately (well, actually fortunately), browser vendors have thought of that (or more likely: those methods have already been exploited), and most limit the CSS you can apply to visited links, alongside making window.getComputedStyle lie sometimes.

[...]

So, rather than using a computer to find out if a link is visited, why don't we trick our visitors into doing it for us instead! 😀

Court article. Comme d'hab, fallait y penser, et ça dit bien qu'on a certainement encore beaucoup à découvrir ... à garder en tête la prochaine fois qu'on vous suggère un CAPTCHA chelou !

Tout savoir sur les Design Systems

Contrairement à ce que j’entends régulièrement, un Système de Design n’est pas une librairie de composants sur Sketch, pas plus qu’une Style Guide ou une Pattern Librairie. En fait, il englobe tout cela dans un ensemble beaucoup plus large.

[...]

Le Design System n’est donc pas un livrable mais une suite de livrables. Il évoluera constamment avec les produits et les technologies émergentes.

Comme Jina Anne l’explique très bien lors de cette conférence (avril 2018), un Système de Design se compose d’éléments tangibles et intangibles :

Des outils pour les designers et pour les développeurs, des patterns, des composants, des guidelines…

Mais également (et c’est souvent le plus difficile à mettre en place) des éléments beaucoup plus abstraits comme des valeurs de marque, des façons communes de travailler, un état d’esprit, des croyances partagées…

Un article plutôt long, mais simple pour aborder le sujet, et avec pas mal de pointeurs vers des design systems ou de quoi creuser.

Liens du 11 août 2023

Fri, 11 Aug 2023 00:00:00 GMT

JavaScript, V8 Engine, Self-hosting a mail server in 2019, trpc / trpc 🧙‍♀️ Move Fast and Break Nothing. End-to-end typesafe APIs made easy., We can save what matters about writing—at a price

JavaScript: V8 Engine

When a fetch request is made, instead of waiting for it to complete, its callback gets added to the Web API. The browser then sets up to listen for the response from the network.

The fetch frame then gets popped off the stack & the engine continues execution.

When the network request is received, the callback is passed to the Callback Queue.

Un tutoriel animé, très court, qui montre quelques fonctionnements essentiels de V8. Hyper simple à saisir.

Self-hosting a mail server in 2019

After a short research I started a Postfix instance in a docker container. A few hours later I successfully configured my domain to work with the SMTP server and sent a test email. It arrived in the SPAM folder of my Gmail account.

Oui, parce que je cherche à héberger mon serveur SMTP ... C'est tout de même assez dingue de voir que quelque chose qui devrait être accessible à tout le monde (non sans certaines compétences certes) est en réalité très difficile à mettre en place, et que cela est essentiellement dû aux différentes règles imposées par chacun des hébergeurs mails.

trpc / trpc 🧙‍♀️ Move Fast and Break Nothing. End-to-end typesafe APIs made easy.

tRPC allows you to easily build & consume fully typesafe APIs without schemas or code generation.

Un repo github d’une lib qui permet d’assister les développements en signalant des erreurs de type lorsque la consommation d’API côté client ne correspond plus à la signature côté serveur. Du type checking cross appli donc, malgré la rupture d’intégration de code !

We can save what matters about writing—at a price

Making it harder to cheat is not a bad idea. But the MLA-CCCC task force doesn’t dwell on this cynical angle. Instead they suggest that we should foreground “process knowledge” and “metacognition” because those things were always the point of writing instruction. This is much the same thesis Corey Robin explores at the end of his post when he compares writing to psychotherapy: “Only on the couch have I been led to externalize myself, to throw my thoughts and feelings onto a screen and to look at them, to see them as something other, coldly and from a distance, the way I do when I write.”

[...]

Yes, that could happen. So this is where we reach the slightly edgier spin I feel we need to put on “teach the process” — which is that, over the long run, we can only save what matters about writing if we’re willing to learn something ourselves. It isn’t a good long-term strategy for us to approach these questions with the attitude that we (professors) have a fixed repository of wisdom — and the only thing AI should ever force us to discuss is, how to convey that wisdom effectively to students. If we take that approach, then yes, the game is over as soon as a model learns what we know. It will become possible to “cheat” by simulating learning.

Un avis sur une approche possible des enseignants vis à vis de l'utilisation des IA génératives sur les travaux écrits. Un des articles liés m'a également tapé dans l'oeil "Will 2024 Look Like 1984?".

Liens du 18 août 2023

Fri, 18 Aug 2023 00:00:00 GMT

HATEOAS and JSON, Is slowness the essence of knowledge?, Modern EU policies need the voices of the fourth sector, Splitting the Web

HATEOAS and JSON

This page is a reworking on the Wikipedia Entry on HATEOAS, which uses JSON. Here we use HTML to explain the concept, and contrast it with JSON APIs. It is a more opinionated explanation of the concept than would be appropriate for Wikipedia, but it is more correct in our opinion.

[…]

The web browser does not know about the concept of an overdrawn account or, indeed, even what an account is. It simply knows how to present hypermedia representations to a user.

Hence we have the notion of the Hypermedia being the Engine of Application State. What actions are possible varies as the state of the resource varies and this information is encoded in the hypermedia.

[…]

Note that this HTML response encodes all the information necessary to update the account balance, providing a form with a method and action attribute, as well as the inputs necessary for updating the resource correctly.

The JSON representation does not have the same self-contained “uniform interface” as the HTML representation does.

Je pense que l’article est intéressant sur l’axe « affordance » du système à exploiter. C’est à dire : en quoi une interface (programmatique ou non !) suffit à décrire son propre usage. Ça me rappelle une suite de vidéos d’un théoricien des langages de programmation, Robert Harper, dont le propos était, si je résume très grossièrement avec mes mots, de dire qu’un logiciel maintenable était d'abord un logiciel affordant pour ceux qui le maintiennent, avec une forte emphase sur les interfaces tels que les types. Sur un billet de blog, un autre, parlant du même théoricien et vulgarisant ses propos, démontrait en quoi des langages comme java, typescript ou autre ne permettait pas de construire des modules affordant avec autant facilité :

Understanding real modules is worthwhile even if you never intend to work in a language that has them. Modules are fundamental, and so much of what is done in other languages, from build configurations to dependency injection to the Adapter pattern, are in large part an attempted encoding of things easily expressed with modules. To write namespaces in other languages worthy of being called “modules,” you need to understand what representational secrets are shared internally and hidden externally. To properly parameterize a Java program over which stack implementation it uses, you need to do dependency injection on the StackFactory type defined above, something which is much easier to do if you first think about how to do it with modules and then translate.

Mais je pense que l’article est aussi à mettre en perspective de ce que propose le site qui l’héberge :

htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext
htmx is small (~14k min.gz’d), dependency-free, extendable, IE11 compatible & has reduced code base sizes by 67% when compared with react

En somme, ils proposent un package permettant de faire en sorte que l’interface html soit dotée de bien plus de capacités pour représenter les états du système sous-jacent, et donc réduire le bricolage en javascript en s'appuyant sur une sémantique web plus étendue.

Is slowness the essence of knowledge?

If emotions prompt rapid responses, cognitive reappraisal is the ability to more slowly re-evaluate our initial reaction. This slower process allows us to regulate our own emotions and respond more appropriately to situations. For instance, imagine we are walking down the street and we pass a friend. We lift our arm and wave to them and say hello, but they simply carry on walking as if they don’t know us. Our first, fast, reaction may be to suppose that they deliberately ignored us, perhaps prompting emotions such as anger or sadness, which can spiral into a negative mood. However, if we are able to reappraise the situation more slowly, and come to a more balanced view, we may be able to avoid the negative emotional consequences. Perhaps he just didn’t see us? Perhaps he was having a bad day and didn’t feel like talking? Reappraisal allows us to focus on the facts, considering more balanced opinions and thereby regulating our emotions.

[...]

As the ‘slow movement’ advocates a cultural shift towards slowing down life’s pace, so does the evidence. Slow processes, be it eating, cognitive reappraisal or slow thinking in the context of psychiatric disorder, are beneficial to us. Slowness may even be an index of recovery in mental health.

Speed is evidently important in many contexts. Quick reactions and instinctive responsiveness aid survival. But we also have a subsequent ‘slow’ response, which is conscious and deliberative, and may be beneficial for more complex social interactions and moral emotions. Perhaps ‘fast’ and ‘slow’ thinking are really two sides of the same coin – intrinsically related, but with their own independent virtues. In our fast-moving society that frequently prioritises speed, the importance of slowness should not be forgotten.

Un article de la British Psychological Society sur la nécessité d'intégrer le "fast thinking" avec le "slow thinking" sur divers aspect de notre vie. Cependant, je ne vois pas comment "ralentir la pensée" dans le contexte de mes missions : très souvent les clients réagissent à des évènements, et en vitesse, car ils ne sont pas maitres de l'environnement dans lequel ils évoluent, et souvent victimes du "Tir de couverture" de la concurrence que j'ai pu partager plus tôt.

Modern EU policies need the voices of the fourth sector

Post-industrial society comprises three sectors in the worldview undergirding the European Union

[…]

each fourth sector role will fuse together an aspect represented and an aspect confronted by any of the entities and roles dedicated to the three traditional sectors.

This means that a consumer association won’t advocate well for Open Source developers because an aspect of their existence is classified as commercial. A streamer won’t be well represented by a trade union because they embody both consumer and commercial aspects. And so on. As a result, existing consultation mechanisms used by legislators are guaranteed to fail. When they try to deal with Open Source by expressing the understanding they have gained of proprietary software, they will keep causing collateral damage — as we have seen in the Cyber Resilience Act (CRA) and many times previously. The need will increase as regulation tries to control, account for or promote the activities of the fourth sector without consulting it.

One significant reason this has been happening for such a long time already is the lack of a term to use to raise the issue. That’s why I am proposing to call this sector of European society the “fourth sector.”

Un court article et suggestion sur la représentativité des acteurs de l’Open Source lors des décisions de l’UE.

Splitting the Web

There’s an increasing chasm dividing the modern web. On one side, the commercial, monopolies-riddled, media-adored web. A web which has only one objective: making us click. It measures clicks, optimises clicks, generates clicks. It gathers as much information as it could about us and spams every second of our life with ads, beep, notifications, vibrations, blinking LEDs, background music and fluorescent titles.

[...]

Think about it! That whole "MBA, designers and marketers web" is now optimised thanks to analytics describing people who don’t block analytics (and bots pretending to be those people). Each day, I feel more disconnected from that part of the web.

[...]

It’s not me. It’s people living for and by advertising who are the outsiders. They are the one destroying everything they touch, including the planet. They are the sick psychos and I don’t want them in my life anymore. Are we splitting from those click-conversion-funnel-obsessed weirdos? Good riddance! Have fun with them.

Je suis d’accord sur le constat de scission, et je me sens aussi de plus en plus déconnecté de la partie commerciale, en revanche pas du tout d’accord sur la suggestion. Je pense que continuer dans cette scission ne fera que renforcer les monopoles, qui, comme les états, ne se privent pas de standardiser et verrouiller les usages, et progressivement l'infrastructure. D'un point de vue systémique, la tendance ira à l'étouffement d'un web libre si un effort volontaire n'est pas fait pour sensibiliser ceux qui naviguent dans l'écosystème sans en comprendre les mécanismes, et pour réguler les actions de ceux qui les exploitent.

Liens du 25 août 2023

Fri, 25 Aug 2023 00:00:00 GMT

Par manque de temps, je ne vous propose que 3 articles cette semaine !
Structuring your Infrastructure as Code, The basic reasons I expect AGI ruin, Zero dependancy Pub / Sub system with PostgreSQL

Structuring your Infrastructure as Code

how do I structure things in a way that scales well and stands the test of time? […] In my day to day role as a Solutions Engineer at Pulumi I get to answer this question a lot.

[…]

This blog post is designed to detail my high(ish) level thoughts on the concepts and principles I like to use, and why. As we explore these concepts, I’ll talk about some of the lessons I learned from my time in configuration management and the myriad IaC tools I’ve used before today.

A lot of the concepts in this post are focused on Pulumi, but lots are broadly applicable to other tools.

La structure au delà de Pulumi m’intéresse, mais je sais que l’un d’entre utilise précisément cette techno ^^

Si vous avez loupé la nouvelle et vous demandez à quoi fait l’auteur faire allusion en disant « everything is great in the IaC world now, right?! », voici un lien.

The basic reasons I expect AGI ruin

I’ve been citing AGI Ruin: A List of Lethalities to explain why the situation with AI looks lethally dangerous to me. But that post is relatively long, and emphasizes specific open technical problems over “the basics”.

Here are 10 things I’d focus on if I were giving “the basics” on why I’m so worried

Un article alarmiste sur les STEM-capable artificial general intelligence, et malgré l’intention de l’auteur, le résumé est encore long ^^’
J’ai malgré tout trouvé intéressant chacun des points qu’il soulève, notamment car l’auteur reste plutôt réaliste quant à l’état actuel des IA, et que les projections sont intéressantes même sous l’angle de la fiction
(attention les notes de bas de page représentent le tiers de la longueur totale de la page, mais ne sont pas inintéressantes)

Zero dependancy Pub / Sub system with PostgreSQL

What I'm proposing at our company is that we leverage the technologies we already have (PostgreSQL & NodeJS) in order to not increase system complexity - as opposed to using a tool such as RabbitMQ (not to say that RabbitMQ is bad).

By using PostgreSQL's LISTEN / NOTIFY features, you have everything you need in order to have a high-performance, fault-taulerant pub / sub system.

Petit article sur un choix d’architecture pas déconnant pour leur contexte. L’auteur semble bien avoir en tête l’impact des coûts de maintenance d’une nouvelle dépendance, et trouve un moyen simple à mettre en place et surtout à maintenir dans le temps.

Liens du 1 septembe 2023

Fri, 01 Sep 2023 00:00:00 GMT

CLI tools you can't live without 🔧, Measuring developer productivity? A response to McKinsey, Web Scraping for Me But Not for Thee

CLI tools you can't live without 🔧

As developers, we spend a lot of our time in the terminal. There's a lot of helpful CLI tools, which can make your life in the command line easier, faster and generally more fun.

This post outlines my top 50 must-have CLI tools, which I've come to rely on.

Ça se scroll assez vite pour trouver des outils intéressants. Une liste au top !

D’autres articles de son blog sont tout aussi intéressants, j’en citerai probablement à l’avenir.

Measuring developer productivity? A response to McKinsey

4 out of the 5 new metrics suggested by McKinsey’s measure effort or output

What’s wrong with this approach? First, the only folks who care about these metrics are the people collecting them. Customers don’t care. Executives don’t care. Investors don’t care. Second, and most crucially, collecting & evaluating these metrics interferes with the team delivering on the measures downstream folks actually do care about, like profitability.

Why is McKinsey adding ways to measure effort? One reason is that it’s the easiest thing to measure! But the McKinsey approach ignores an important truth: the act of measurement changes how developers work, as they try to “game” the system.

The earlier in the cycle you measure, the easier it is to measure. And also the more likely that you introduce unintended consequences.

Au cas où vous ne l’auriez pas déjà vu lasser.

Pour les mesures d’effort et output je suis depuis assez longtemps convaincu de leur danger, hors des mains des équipes comme entre leurs mains. Mais pour la mesure de l’outcome, je plaide coupable pour la diffusion de framework depuis l’étage C-Level.

Laissez la responsabilité des moyens et de leur efficience à vos équipes, car s’assurer du contrôle c’est prendre le contrôle et les responsabilités qui vont avec. Vous ne ferez jamais mieux qu’une intelligence collective qui s’alimente du terrain et qui s’intéresse à ses propres pratiques.

Web Scraping for Me But Not for Thee

And this is where the hypocrisy comes in: the breach-of-contract-as-property legal regime has no legal requirement for intellectual honesty or consistency. It has no requirement to respect others’ IP akin to trademarks or patents in the same way that you do your own. Companies are free to press their advantage on what is deemed “proprietary” on their sites while simultaneously asserting what is free for the taking on others. It is easy to criticize this, but this is what smart lawyers and legal teams do.

[…]

I’m picking on Microsoft, as it is the most flagrant offender here. But I could pick on hundreds of others who are also hypocritical on this issue. Notably, Meta is also famously suing a company right now for scraping and selling its public content, even though Meta once paid the same scraper to scrape public data for them.

Et ça n’ira pas en s’arrangeant 😬

Liens du 8 septembe 2023

Fri, 08 Sep 2023 00:00:00 GMT

Incompetent but Nice, Surfacing Worldviews in Design, Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle

Incompetent but Nice

What do you do about someone who’s really nice but can’t seem to do the work?

The proximate answer is fairly easy: you try to help them level up: pay for classes, conferences, and/or books; connect them with mentors or coaches; figure out if something’s in the way and remove the blocker. Sometimes folks in this category just need to learn, and because they’re nice it’s easy to give them a lot of support and runway to level up. Sometimes these are folks with things going on in their lives outside work and they need some time (or some leave) to focus on stuff that’s more important than work. Sometimes the job has requirements that can be shifted or eased or dropped – you can match the work to what the person’s good at. These situations aren’t always easy but they are simple: figure out the problem and make a change.

But occasionally I run into people who seem somehow resistant to change. You can’t identify any particular reason why they’re struggling – and, more importantly, neither can they. Any changes you make are ineffective: they just can’t seem to get work done.

Une entrée en deux bandes, suite à cet article qui détaille le problème, un autre article relate toutes les réactions qui suivi le premier article avec pas mal de matière : Follow-ups to “Incompetent but Nice”

Surfacing Worldviews in Design

Design choices carry along the worldviews of the designer. This often is not apparent, especially when design ideas are for obvious technical improvements. Let’s look into a design challenge faced by a fictional Maker Lab.

Un court article qui enseigne par l’exemple ce qu’une vision du contexte peut avoir comme impact sur la résolution de problèmes. Je pense qu’on a souvent vu le premier scénario de d’approche par la tech.

Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle

Many practitioners and academics believe in a delayed issue effect (DIE); i.e. the longer an issue lingers in the system, the more effort it requires to resolve. This belief is often used to justify major investments in new development processes that promise to retire more issues sooner.
This paper tests for the delayed issue effect in 171 software projects conducted around the world in the period from 2006–2014. To the best of our knowledge, this is the largest study yet published on this effect. We found no evidence for the delayed issue effect; i.e. the effort to resolve issues in a later phase was not consistently or substantially greater than when issues were resolved soon after their introduction.

Je vous le partage ici parce que ça va à contre courant de ce qu’on (je) raconte sur les defects, et que j’aimerais votre avis. Je me plante ou bien l’échantillon est biaisé par à la fois une source (personne) et des projets utilisant uniquement un framework dont la propriétaire revient à l’université qui a mené l’étude ? Aussi, dans les définitions il est dit que le coût et l’effort sont confondus ce qui me parait pas une bonne idée puisque d’un contexte à l’autre on arbitrera pas de la même façon selon ces deux axes.

Pas de liens mais …

Fri, 15 Sep 2023 00:00:00 GMT

Pour éviter de vous noyer avec plus de liens au retour des congés, j’ai préparé un petit questionnaire pour améliorer cette newsletter. Pour s’adapter au temps de chacun•e, il n’y a que 2 questions qui me tiennent à cœur et des bonus si vous avez un peu plus de temps à m’accorder. À vot’ bon coeur : lien vers le questionnaire

Si le questionnaire ne vous convient pas ou que vous désirez passer par des canaux plus directs, vous savez où me trouver !

Liens du 22 septembre 2023

Fri, 22 Sep 2023 00:00:00 GMT

Making Teams Effective At Remote Work, Reducing Toxicity in Language Models, Different – Review

Making Teams Effective At Remote Work

After reviewing 40+ resources, spending hours absorbing and summarizing them, and boring my friends and colleagues about it, I thought I’d put everything into a nice little package to share what I’ve learned with others. This is what his article is.

The article is geared towards managers on how to adapt teams and organizations to become effective at remote work, and not so much on how to be a more productive individual within a remote setup.

If you’re an individual contributor, you will find interesting ideas in this article nonetheless, and also ideas on how to convince your manager to help your team and organization be effective at remote work, so read on!

Une liste qui peut expliquer les manques des entreprises qui ont tenté la transition durant la pandémie et se retrouvent à vouloir faire marche arrière (sans nécessairement y arriver vu l’évolution des mentalités des employés sur le remote). Si vous vous retrouvez dans la situation du mode hybride, cet article peut vous donner des pistes sur le pourquoi ça pêche (dans le cas où ça pêche). Sans trop de surprise, on retrouve essentiellement les pratiques éprouvées de GitLab. Il y a des prérequis culturels assez forts, qui feront que certaines pratiques, comme celle du style de management, ne seront tout simplement pas applicables.

Reducing Toxicity in Language Models

Large pretrained language models are trained over a sizable collection of online data. They unavoidably acquire certain toxic behavior and biases from the Internet. Pretrained language models are very powerful and have shown great success in many NLP tasks. However, to safely deploy them for practical real-world applications demands a strong safety control over the model generation process.

Overall, toxicity is a broad term to describe several types of unsafe content. Methodologies in this post can be applied given some form of definition of toxicity; e.g. presented in the instruction for annotators. How to properly define the concept of toxicity and thus collect accurate annotation labels is out of the scope of this post.

Weng, Lilian. (Mar 2021). Reducing toxicity in language models. Lil’Log.

Long post, très intéressant. Je n’ai eu aucune difficulté à comprendre les différentes techniques sans avoir de formation ou expérience en LLM.

Different – Review

Tim Kastelle, who writes on innovation, was also struck by what I would describe as the key graphic in the book. It shows what happens when you benchmark yourself against your competitors. Over time, everybody starts to look the same. A radical, and different, approach would be to emphasize your strengths and ignore, or even celebrate, your weaknesses.

The herd mentality is to keep up with the competition, but as the author writes, ” … if you’re looking for a unique solution, the last thing you should do is ask for a vote”.

[…]

Just being different is not enough for business success though. The difference has to have meaning, such as Harley Davidson creating a real community of bikers, numbering over a million. Difference has to resonate, not just be superficial.

Ça me rappelle Fire and motion que je vous ai partagé il y a un moment : sous le feu des fonctionnalités pondues par la concurrence, les entreprises courent après les balles pour tenter de se mettre à niveau, et deviennent de fait trop occupées pour se démarquer.
En y repensant, le modèle de Kano pourrait servir à déterminer quelles fonctionnalités « méritent » un plus gros investissement que les autres et reprendre la maîtrise de la trajectoire du produit.

Dans la même veine, mais plus profond que les produits, je vois ça chez mes clients lorsqu’ils me demandent « l’état de l’art des pratiques de delivery » par exemple. Et invariablement, chacun d’entre eux tente de reproduire les pratiques selon le modèle de comparaison (notez que je n’ai pas dit « reproduire les pratiques de la concurrence » … la carte et le territoire …). Clairement ce n’est pas faute d’expliquer que tout ne fonctionne partout, et peut même leur causer du tort (livrer tous les jours une nouvelle version n’est pas la meilleure des idées pour utilisateurs lorsqu’il s’agit d’une app mobile par exemple). Mais je pense que, d’une part, ces organisations ont perdu leurs moyens d’apprendre, c’est à dire de prendre le risque de faire différemment, d’analyser les conséquences, et de juger le processus (plutôt que les gens) face aux échecs rencontrés. Et d’autre part, c’est tellement plus simple et rassurant de suivre la direction que d’autres ont pris, surtout quand avant de se démarquer on aimerait déjà que notre orga fonctionne.

Liens du 29 septembre 2023

Fri, 29 Sep 2023 00:00:00 GMT

Some notes on Local-First Development, “Agile with ‘Idiots’”, Being Glue

Some notes on Local-First Development

The web feels ready for a major upgrade. We had tightly coupled web frameworks in the Rails/Django years and lost them with the shift to API-powered SPAs. The developing database-grade sync technology will tightly recouple our application stacks allowing for a new era of framework innovation.

I see “local-first” as shifting reads and writes to an embedded database in each client via“sync engines” that facilitate data exchange between clients and servers. Applications like Figma and Linear pioneered this approach, but it’s becoming increasingly easy to do. The benefits are multiple:

Simplified state management for developers

Built-in support for real-time sync, offline usage, and multiplayer collaborative features

Faster (60 FPS) CRUD

More robust applications for end-users

[…]

To fully replace client-server APIs, sync engines need robust support for fine-grained access control and complex write validation.

The most basic use case for an API is state transfer from the server to the client. The client wants to show information about an object so reads the necessary data through the API.

Local-first tools all handle this perfectly. They ensure the latest object data is synced correctly to the client db for querying from the UI.

But while reads are generally easy, support for complex writes is still immature in local-first tooling. Clients tend to have unrestricted write access and updates are immediately synced to other clients. While this is generally fine for text collaboration or multiplayer drawing, this wouldn’t work for a typical ecommerce or SaaS application.

[…]

But in general, I’d still be wary of using local-first outside real-time / multiplayer / offline use cases. Local-first is definitely still bleeding-edge. You will hit unexpected problems. A good community has rapidly developed, but there’ll still be some stretches on the road where you’ll have to solve novel problems.

Un article de taille moyenne/longue sur le paradigme « local-first ». Si comme moi vous n’en aviez pas encore entendu parlé, je vous recommande de le lire ! L’auteur va au déla des use cases actuels et développe sur les limites et territoires inconnus de l’approche. Il cite également quelques technologies intéressantes pour mieux appréhender les possibilités.

Le concept n’étant pas développé au début de l’article, voici un petit marche-pied pour la lecture : plutôt que d’interagir avec des APIs de gestion pour faire fonctionner vos clients web, ceux-ci se reposent sur une BDD locale, et cette dernière se synchronise en arrière plan directement avec une base centrale.

Ce qui est amusant c’est que c’est le type d’approche que j’adopte pour mes projets perso. Le plus gros étant un outil de gestion de cartes avec états temporels (la carte évolue selon l’année sélectionnée) qui permet une synchro entre différents consommateurs (le type de use case partagé dans l’article). Je ne me reposait pas sur un protocole de synchronisation propre à la DB, j’avais tout de même un backend (ne connaissant pas les techno citées dans l’article), mais celui-ci ne connaissait rien du métier : ni la logique, ni les données. Gérer les migrations de données était alors assez particulier, j’en suis même venu à le faire du côté front avec mon propre système d’update (oui j’ai bien dit que c’était particulier ^^´).

Et un autre exemple plus récent et plus simple : l’outil que je me suis fait pour la collection de liens de cette newsletter :)

“Agile with ‘Idiots’”

As IT coaches and consultants, we often have to deal with “idiots” when trying to implement agile in some organisations.
“Embrace change!” we say, “For disruption is good”
“Talk with each other more!” we say, “For collaboration is good”
“Visualise your work!” we say, “For exposure is good”
And the idiots won’t.
“Let’s try a game!” we say.
And the idiots scoff.

Post pas bien long, mais qui fait mouche. La répartition des « adopters » sur la courbe de Bell me fait me demander où nous en sommes aussi nous, les coachs et consultants.

Being Glue

Your job title says "software engineer", but you seem to spend most of your time in meetings. You'd like to have time to code, but nobody else is onboarding the junior engineers, updating the roadmap, talking to the users, noticing the things that got dropped, asking questions on design documents, and making sure that everyone's going roughly in the same direction. If you stop doing those things, the team won't be as successful. But now someone's suggesting that you might be happier in a less technical role. If this describes you, congratulations: you're the glue. If it's not, have you thought about who is filling this role on your team?

Every senior person in an organisation should be aware of the less glamorous - and often less-promotable - work that needs to happen to make a team successful. Managed deliberately, glue work demonstrates and builds strong technical leadership skills. Left unconscious, it can be career limiting. It can push people into less technical roles and even out of the industry.

Retranscription d'un talk sur la nécessaire posture de "glue" que prennent certaines personnes, et des problèmes que cela peut leur poser dans leur carrière.

Attention réflexion tout haut bien personnelle, mais je crois connaître des gens qui se posent les mêmes questions : je crains de tomber dans cette ornière depuis un moment. Si j’ai bien compris une chose sur mon approche au travail c’est que je n’arrive pas me contenter du rôle qu’on me donne : je me pose toujours la question de l’intégration des tâches et responsabilités de mon rôle (indépendamment de ma personne) au sein du tout dans lequel j’agis. C’était le cas durant mon stage d’observation de 3eme, et ça m’a permis de décrocher un job d’été sur plusieurs années. C’était le cas lors de mon stage de première année d’études, et ça m’a permis de jeter ma tâche initiale en Windev (qui n’aurait servi à rien) et de faire du C embarqué pour le département de R&D. C’était le cas de mon premier boulot, et ça a permis au moins pour un temps d’améliorer les relations entre dev et run. C’était le cas lors de nombreuses missions, et ça m’a valu la confiance de plusieurs clients, un burnout, d’appartenir à une équipe de marginaux génialissimes et d’autres situations où je dépassais les limites du contexte en flirtant avec les miennes. « Pour me préserver », j’ai entendu plusieurs fois le conseil de « prendre du recul » , ou encore « si tu ne peux pas changer les choses, change toi toi-même », mais ce que les gens ne semblent pas saisir c’est qu’il ne s’agit pas d’un moyen dont j’userais pour accomplir mon travail, mais de la façon dont je perçois le monde. Si je pense que le monde tournerait mieux en se parlant, en s’inquiétant des impacts de ses actes au delà de notre périmètre, alors lâcher prise sur tout cela reviendrait à devenir ce que je critique. Ce ne serait pas seulement malhonnête, ça me rongerait. Mais de fait, en persistant à me poser des questions aux frontières plutôt que sur une spécialité, je crains de me retrouver dans un cul de sac inqualifiable pour les frameworks d’entreprise.

Liens du 6 octobre 2023

Fri, 06 Oct 2023 00:00:00 GMT

Career narratives., Navigating personal information with care, Tech layoffs in 2023, A timeline.

Et sinon, on reste à 3 liens ou on revient à 4 ?

Career narratives.

If you took ten minutes to ask a dozen folks about their immediate career goals, I suspect that for eleven of them it would center on either getting promoted or switching companies to reach the next evolution of their current job. This doesn’t mean that climbing the career ladder is bad, that’s what it’s designed for, but it has the side effect of funneling most folks towards a constrained pool of opportunity.

What I’ve slowly but increasingly come to believe is that there is much more opportunity outside career ladders than within them, and by including those opportunities you’ll make and feel more progress. Better yet, you’ll find far more opportunities to partner with your peers, no longer competing for limited promotion slots.

[…]

Managers tend to have a strong sense of the business’ needs, and that gives them the superpower of finding the intersection of your interests and the business’ priorities.

Je vous partagerais à nouveau des liens de ce blog. Je l’avais découvert il y a longtemps, et je le redécouvre maintenant : une superbe mine d’apprentissages/outils, notamment sur le management.

Ici le conseil d’attaquer sa carrière en diagonale de ce que proposent les frameworks habituels m’a forcément intéressé. Et remet Being Glue en perspective. Le dernier paragraphe de la citation est une pratique en laquelle je crois fermement et que je tente d’appliquer un max au boulot. Le manager est un représentant de la relation employé-entreprise, et doit considérer et rejoindre à la fois les intérêts de l’entreprise ET de l’employé. Un intérêt majeur de cette approche est que l’on doit travailler avec les différences de chacun, et c’est finalement le meilleur moyen (le plus opérationnellement réaliste et activable) de tirer parti de la diversité présente au sein de chaque individu et de la mettre en valeur.

Navigating personal information with care

Accessing personal information from customers is a serious matter. With the launch of HEY in 2020, we developed some technology and processes to support a very simple principle: employees shouldn’t have access — intentionally or unintentionally — to personal information from our users without their explicit consent. In this post, I’ll show what this looks like in practice.

Un post pas bien long, bien illustré. Ça donne envie d’avoir le même workflow et outils !

Tech layoffs in 2023: A timeline

The problem: Big Tech went on a hiring binge during the pandemic when lockdowns sparked a tech buying spree to support remote work and an uptick in e-commerce, and now they face revenue declines.

Continuing supply chain issues, inflation, and the war in Ukraine are also having an impact on both business and consumer spending, leading to fears of recession.

[…]

According to data compiled by Layoffs.fyi, the online tracker keeping tabs on job losses in the technology sector, 1,012 tech companies have laid off about 235,639 staff so far this year, compared to 164,411 layoffs last year

Ouch. L’explication du problème menant aux licenciements me paraît plutôt logique. La liste est assez impressionnante, avec des effectifs licenciés plus moins importants. Étrangement, chaque boite n’a pas licencié la même population (techos, « fonctions support », biz, …) mais je n’ai pas vu de « panachage ». J’imaginais peut-être de façon simpliste que si on revenait à des niveaux de demande pré-pandémie, alors les entreprises licencieraient des personnes sur l’ensemble des rôles.

Liens du 13 octobre 2023

Fri, 13 Oct 2023 00:00:00 GMT

Company culture is the last 50 days, Death by a thousand microservices, Learn to Read Causal Loop Diagrams

Company culture is the last 50 days

There's nothing complicated about company culture.

Culture simply happens. It's emergent behavior. There's nothing to do, it just is.

A company's culture is a 50-day moving average. It's what you've been collectively doing as a company over the last 50 days.

Très court ! J'imagine que 50 jours sont suffisants pour la taille de 37signals. Selon leur CEO Jason Fried, ils étaient 80 en 2022. Je pense qu'en terme d'échelle on est pas si loin de ce nombre de jours, ce qui correspond à ce que j'ai déjà pu entendre sur les "transformations" :

un changement n'a pris que lorsque chaque personne dans l'organisation l'implémente.

Et vous, combien êtes-vous ? À quelle vitesse vos changements se propagent-ils ?

Death by a thousand microservices

Trigger warning: Some people understandably got salty when I name-checked JavaScript and NodeJS as a source of the problem

[…]

There are a few events in recent history that may have contributed to the current state of things. First, a whole army of developers writing JavaScript for the browser started self-identifying as “full-stack”, diving into server development and asynchronous code. JavaScript is JavaScript, right? What difference does it make what you create using it - user interfaces, servers, games, or embedded systems. Right? Node was still kind of a learning project of one person, and the early JavaScript was a deeply problematic choice for server development. Pointing this out to still green server-side developers usually resulted in a lot of huffing and puffing. This is all they knew, after all. The world outside of Node effectively did not exist, the Node way was the only way, and so this was the genesis of the stubborn, dogmatic thinking that we are dealing with to this day.

[…]

Back in the days when the tech industry was not such a bloated farce, distributed systems were respected, feared, and generally avoided - reserved only as the weapon of last resort for particularly gnarly problems. Everything with a distributed system becomes more challenging and time-consuming - development, debugging, deployment, testing, resilience. But I don’t know - maybe it’s all super easy now because toooollling.

There is no standard tooling for microservices-based development - there is no common framework. Working on distributed systems has gotten only marginally easier in 2020s. The Dockers and the Kuberneteses of the world did not magically take away the inherent complexity of a distributed setup.

[…]

There are multiple pitfalls to building with microservices, and often that minefield is either not fully appreciated or simply ignored. Teams spend months writing highly customized tooling and learning lessons not related at all to the core product. Here are just some often overlooked aspects…

Un peu de microservice bashing parce que ça me manquait. Le trigger warning du début m’a fait penser que je n’étais probablement pas le seul à avoir pensé que certains devs node avaient réinventé la roue.

La liste des problèmes cités est connue de longue date, notamment parce que tous les articles critiques en parlent, mais surtout car il s’agit de systèmes distribués. J’ai cependant pas mal aimé le rappel des grosses boites à succès qui ont décollé (et parfois encore persisté) sur des monolithes.

J’ai aussi aimé le passage sur le doute des autres dev/ingés, je l’ai eu également. Quand la majorité de la masse part dans la même direction, on peut légitimement se demander si on a raison.

Learn to Read Causal Loop Diagrams

Most of our posts include causal loop diagrams because some things are better expressed with a visual model than in words alone. Systems thinking takes on complex, dynamic systems and how they behave over time, which calls for a different sort of language. This quick tutorial will teach you the basics about reading causal loop diagrams through a Population model.

Le type d'outil que j'utilise quand je ne sais pas par quel bout attaquer un système. Une chose que j'ai apprise dans cette page, c'est la représentation des délais dans les boucles de feedback. En bas de page il y a tout un paquet de use cases et autres tuto pour appréhender le system thinking !

Liens du 20 octobre 2023

Fri, 20 Oct 2023 00:00:00 GMT

Get your work recognized, write a brag document, Intelligence artificielle , la CNIL dévoile ses premières réponses pour une IA innovante et respectueuse de la vie privée, Le travail vivant, Surprising things happen when you put 25 AI agents together in an RPG town

Get your work recognized: write a brag document

One thing I’m always struck by when it comes to performance review time is a feeling of “wait, what did I do in the last 6 months?“. This is a kind of demoralizing feeling and it’s usually not based in reality, more in “I forgot what cool stuff I actually did”.

I invariably end up having to spend a bunch of time looking through my pull requests, tickets, launch emails, design documents, and more. I always end up finding small (and sometimes not-so-small) things that I completely forgot I did, like:

mentored an intern 5 months ago

did a small-but-important security project

spent a few weeks helping get an important migration over the line

helped X put together this design doc

etcetera!

And if you don’t remember everything important you did, your manager (no matter how great they are!) probably doesn’t either. And they need to explain to other people why you should be promoted or given an evaluation like “exceeds expectations” (“X’s work is so awesome!!!!” doesn’t fly).

So if your manager is going to effectively advocate for you, they need help.

C'est ce qui fait la différence entre les évaluations de gens qui ont gardé la trace ce qu'ils ont réalisé des autres, mais tout le monde ne le sais pas. Dans ma boite on a un outil interne qui permet d'ajouter des notes publiques à l'échelle du mois, je m'en sers comme d'un journal.

Intelligence artificielle : la CNIL dévoile ses premières réponses pour une IA innovante et respectueuse de la vie privée

Les échanges de ces derniers mois ont fait remonter des inquiétudes : selon certains, les principes de finalité, de minimisation, de conservation limitée et de réutilisation restreinte résultant du RGPD freineraient voire empêcheraient certaines recherches ou applications de l’intelligence artificielle.

La CNIL répond à ces objections, en confirmant la compatibilité des recherches et développements en IA avec le RGPD, à condition de ne pas franchir certaines lignes rouges et de respecter certaines conditions.

C’est à croire que ceux qui se plaignent de la RGPD demandent à ce qu’on les laisse commercialiser tranquillement ce qui ne leur appartient pas.
La façon dont j’interprète le message de la CNIL : « Oh regardez on a tout décliné pour vous faciliter la vie avec "vos technos innovantes". Quoi ce sont les mêmes règles qu’avant ? Bien vu. On va tout de même pas autoriser le vol parce que vous avez la flemme de trier, non ? »

Le travail vivant

Le travail n’est jamais neutre vis-à-vis de la santé, de la santé mentale. Il peut générer le pire : des pathologies mentales que j’essayais de décrire (et cela va aujourd’hui jusqu’au suicide sur les lieux du travail), mais il peut aussi générer le meilleur. Le travail peut devenir tellement important dans une vie que c’est grâce au travail que non seulement on solidifie, on renforce sa santé, mais peut-être même, on la constitue. C’est le travail comme médiateur de la construction de la santé. Personne n’échappe à cette centralité du travail pour le psychisme.

[…]

La définition du travail, je vais vous la donner. Le travail vivant, ça vient de la confrontation entre la psychanalyse et l’ergonomie. Dans le laboratoire de Wisner, les ergonomes démontrent qu’il existe toujours un décalage entre le travail prescrit et le travail effectif. Ça, c’est la grande découverte fondamentale de l’ergonomie, qui est abyssale en réalité, parce que c’est là que se concentrent toute l’énigme et tout le processus absolument passionnant et bouleversant du travail vivant. Tout travail est encadré par des prescriptions, des procédures… Ce qu’ont trouvé les ergonomes, c’est que les gens ne font jamais ce qui est prescrit. Il y a toujours un décalage entre le travail prescrit et le travail effectif. La tâche, c’est ce qu’il faut faire. Ce que les gens font effectivement, c’est l’activité. Tout le problème, c’est ce décalage-là. Pourquoi il existe, de quoi est-il fait et surtout, comment les gens traitent ce décalage. S’ils étaient totalement obéissants et s’ils exécutaient exactement les ordres qu’on leur donne, ça ne marcherait plus ! Aucune industrie, même pas une chaine de montage, ne peut fonctionner si les gens obéissent strictement aux ordres.

Une interview qui m’a laissé songeur. Je repense mes douleurs au travail, mon burnout, … je repense à ce que j’ai pu faire et mobiliser comme énergie, et je me demande en quoi j’ai pu penser que les conditions de réussite n’étaient pas suffisantes pour vouloir m’investir autant.

Je pense que mon style de management évite aux personnes que j’accompagne d’avoir à résoudre le creux inconsciemment et corps et âme entre les moyens donnés et ceux qu’ils doivent investir. Je pense pouvoir réduire la tension en dédramatisant les attentes, et aussi j’espère réussir à repérer les ponts les moins long entre leurs forces et les attentes de la boite / client.

Le passage sur la domination m’a rendu perplexe, mais après avoir fouillé je pense qu’il donnait une perspective freudienne pas très construite. Mais c’était surtout une parenthèse bâclée car trop grosse à ouvrir dans l’espace d’une si petite interview.

Surprising things happen when you put 25 AI agents together in an RPG town

In the paper, the researchers list three emergent behaviors resulting from the simulation. None of these were pre-programmed but rather resulted from the interactions between the agents.

These included "information diffusion" (agents telling each other information and having it spread socially among the town), "relationship memory" (memory of past interactions between agents and mentioning those earlier events later), and "coordination" (planning and attending a Valentine's Day party together with other agents).

During the Valentine's Day experiment, an AI agent named Isabella Rodriguez planned a Valentine's Day party at "Hobbs Cafe" and invited friends and customers. She decorated the cafe with the help of her friend Maria, who invited her crush Klaus to the party.

Un ami m’avait transmis le papier correspondant, mais je suis tombé sur cet article bien plus petit et digeste d’Ars Technica si vous manquez de temps. En gros, ce groupe de chercheur a réalisé un RPG à partir d’openAI dans lequel les agents sont autonomes et construisent leur vie à partir d’un narratif, une sorte de Westworld !

Liens du 27 octobre 2023

Fri, 27 Oct 2023 00:00:00 GMT

Augmenter les IA génératives sur étagère à l’aide de services et de connaissances contextuels, AutoGen, Hard to work with.

Hard to work with.

What I’ve found effective in these cases is to lead with constructive energy directed towards a positive outcome. Even if you can’t get your peer’s performance addressed directly, you can often overcome your peer’s bad performance by generating excitement in the direction you want to go. Enough excitement will give the resolution avoidant manager a way to solve their problem without actually engaging with the situation that they’re unwilling to address.

I know that folks don’t want this advice: it is unfair to be forced to overcome a peer’s poor performance, that’s the manager’s job, but work isn’t a perfect place. Success is finding a path forward among the options that actually exist. Grinding yourself down in frustration about paths not existing doesn’t solve anything. It may take a few tries to learn this lesson, I certainly devoted quite a few years to learning it the hard way.

J’allais dire que je connais quelques personnes ici qui sont dans cette situation, mais en y réfléchissant bien je pense que c’est presque la norme d’être confronté à ce cas quand on se trouve dans une organisation où les compétences de management n’ont pas été entretenues.

AutoGen

AutoGen is a framework that enables the development of LLM applications using multiple agents that can converse with each other to solve tasks. AutoGen agents are customizable, conversable, and seamlessly allow human participation. They can operate in various modes that employ combinations of LLMs, human inputs, and tools.

Pas encore testé mais ça me démange ! Dans une discussion parallèle j’évoquais la possibilité de coordonner des agents pour rattraper les maj de dépendances front par exemple. La partie la plus frustrante de migration jeu de versions vers un code fonctionnel pourrait être réalisée, en laissant le dev ajuster pour conserver la maintenabilité du code produit.

Augmenter les IA génératives sur étagère à l’aide de services et de connaissances contextuels

L’objectif de cet article est de proposer un tour d’horizon des techniques disponibles pour contextualiser une IA générative par l’intégration de données externes et de services spécialisés dans son modèle de langue.

Un bon recap, cheat sheet, de personnalisation des GenAI. Si vous n’avez pas tout suivi ou de façon éclatée c’est un bon condensé !

Liens du 3 novembre 2023

Fri, 03 Nov 2023 00:00:00 GMT

Next slide please, A brief history of the corporate presentation, Two Person Teams, Why Twitter Didn’t Go Down, From a Real Twitter SRE

Next slide please: A brief history of the corporate presentation

The sound of slides clacking is deafening. But it doesn’t matter, because the champagne is flowing and the sound system is loud. The 2,500 dignitaries and VIPs in the audience are being treated to an hourlong operetta about luxury travel. Onstage, a massive chorus, the entire Stockholm Philharmonic, and some 50 dancers and performers are fluttering around a pair of Saab 9000CD sedans. Stunning images of chrome details, leather seats, and open roads dance across a 26-foot-tall screen behind them. The images here are all analog: nearly 7,000 film slides, carefully arranged in a grid of 80 Kodak projectors. It’s 1987, and slideshows will never get any bigger than this.

Before PowerPoint, and long before digital projectors, 35-millimeter film slides were king. Bigger, clearer, and less expensive to produce than 16-millimeter film, and more colorful and higher-resolution than video, slides were the only medium for the kinds of high-impact presentations given by CEOs and top brass at annual meetings for stockholders, employees, and salespeople. Known in the business as “multi-image” shows, these presentations required a small army of producers, photographers, and live production staff to pull off. First the entire show had to be written, storyboarded, and scored. Images were selected from a library, photo shoots arranged, animations and special effects produced. A white-gloved technician developed, mounted, and dusted each slide before dropping it into the carousel. Thousands of cues were programmed into the show control computers—then tested, and tested again. Because computers crash. Projector bulbs burn out. Slide carousels get jammed.

[…]

At this scale, PowerPoint’s impact on how the world communicates has been immeasurable. But here’s something that can be measured: Microsoft grew tenfold in the years that Robert Gaskins ran its Graphics Business Unit, and it has grown 15-fold since.

Un peu d’histoire sur un des outils centraux de la comédie professionnelle : les slide shows. Et comprend d’autant plus ce que fait le mot show là dedans avec cet article. L’histoire est moyennement longue mais se lit très facilement.

Two Person Teams

(03:49): We do not have sort of a, we used to call it the, the Photoshop wall now, I guess it’s the Figma wall where you throw Figma files around and then someone has to cut that up and turn it into the actual code. No, the designers at 37signals go, if not straight to HTML, then very quickly to HTML and not just to HTML, but to JavaScript and even a bit of Ruby. You’re working in the same code base. There’s not a translation layer. Not only is there not, um, sort of a human translation layer, there’s not a technical translation layer either cutting all those translation layers out and getting the most direct bandwidth between two people. I don’t think people realize how big of a difference it makes. In fact, um, we had a funny incident a few months ago, I think it was where we were, was it five programmers on Basecamp?

(04:44): And we were like, it’s too many. It’s too many. We can’t actually do product management for Basecamp with five teams at the same time. We cut that down to three teams. So we’d have three programmers at that time working on Basecamp at any one time with three other, uh, programmers. And that was it. That was all we needed. I talked to startups all the time who think they need 5, 7, 10 programmers to do anything at all. And when I tell 'em, Hey, do you know what Basecamp, the thing that’s like paying for 37 signals has been pushing this whole company forward for 20 years. It consists of like three teams of two. Like they blow their minds. And this is what is odd to me, is we have shared everything about how we built. We share our tools, we share Ruby on Rails, we share our process, we share Shape Up, we share every single approach how we run this company.

[...]

Encore 37signals qui sort du lot. Et pour avoir testé quelque chose de similaire en taille/fonctionnement, ça peut effectivement aller très vite. Le pré-requis c’est la responsabilité / autonomie sur les décisions, ce qui implique aussi que la vision et les principes directeurs métiers et techniques soient partagés et compris.Oui, d’un coup ça réduit le nombre de contextes dans lesquels c’est possible.

Why Twitter Didn’t Go Down: From a Real Twitter SRE

Twitter supposedly lost around 80% of its work force. What ever the real number is, there are whole teams with out engineers on it now. Yet, the website goes on and the tweets keep coming. This left a lot wondering what exactly was going on with all those engineers and made it seem like it was all just bloat. I’d like to explain my little corner of Twitter (though it wasn’t so little) and some of the work that went on that kept this thing running.

Un vieil article que je n’avais pas vu passer, qui donne une partie de l’histoire, celle de la Cache Team, sur les raisons pour lesquelles Twitter tient encore après avoir perdu bon nombre de ses ingénieurs.

Liens du 10 novembre 2023

Fri, 10 Nov 2023 00:00:00 GMT

Computing Within Limits, Time and energy., What to learn

Computing Within Limits

The LIMITS workshop concerns the role of computing in human societies situated in a world of limits*. As an interdisciplinary group of researchers, practitioners, and scholars, we seek to reshape the computing research agenda, grounded by an awareness that contemporary computing research is intertwined with ecological limits in general, and climate- and climate justice-related limits in particular.

For example, limits of extractive logics, limits to a biosphere's ability to recover, limits to our knowledge, or limits to technological "solutions".

Pas un article, une conf. Je vous la partage car dans les programmes des années précédentes se trouve un bon paquet de ressources, questions, tentatives, perspectives visant à changer notre vision et notre approche de l’informatique pour un développement et usage cohérent avec notre contexte écologique.
Voici quelques titres à travers les années (chacun pointe vers un papier/article):

A User-Centered Lens into Digital Excess: Exploring the Superfluity and Environmental Burden of the Digital World
Computing as Ecocide
Exploring inner transition: Expanding computing for sustainability
How realistic are claims about the benefits of using digital technologies for GHG mitigation? Why this matters and where research is missing
The Richness of Designing for Eco-Social Change: Creative Practice, Transformative Futures and Living within Limits
Experimenting with Novel Forms of Computing: The case of the Swedish Citizen Observatory for Water Quality Conservation Teresa Cerratto Pargman, Somya Joshi (Stockholm University), Uta Wehn (IHE)

Time and energy.

Nonetheless, I still find myself longing for more time, and dreaming fondly of my life as it existed three or four years ago. It simply had so much space in it. Time that made it easy to fill so many different buckets in my life. Now I fill each bucket knowing that it means that another two will stay dry. The good news is that I imagine things will get much easier in a few years as the kiddo gets a bit older. Until then, the question that echoes in my head is, “Should I get better at living in this new world, or wait until the old world hopefully returns?”

Worse yet, I know the answer. It’s time to get growing.

What to learn

If you watch an anime or a TV series "about" fighting, people often improve by increasing the number of techniques they know because that's an easy thing to depict but, in real life, getting better at techniques you already know is often more effective than having a portfolio of hundreds of "moves".

[…]

I've personally found this to be true in a variety of disciplines. While it's really difficult to measure programmer effectiveness in anything resembling an objective manner, this isn't true of some things I've done, like competitive video games (a very long time ago at this point, back before there was "real" money in competitive gaming), the thing that took me from being a pretty decent player to a very good player was abandoning practicing things I wasn't particularly good at and focusing on increasing the edge I had over everybody else at the few things I was unusually good at.

This can work for games and sports because you can get better maneuvering yourself into positions that take advantage of your strengths as well as avoiding situations that expose your weaknesses. I think this is actually more effective at work than it is in sports or gaming since, unlike in competitive endeavors, you don't have an opponent who will try to expose your weaknesses and force you into positions where your strengths are irrelevant. If I study queuing theory instead of compilers, a rival co-worker isn't going to stop me from working on projects where queuing theory knowledge is helpful and leave me facing a field full of projects that require compiler knowledge.

One thing that's worth noting is that skills don't have to be things people would consider fields of study or discrete techniques.

[…]

A lot of career advice I see is oriented towards career or success or growth. That kind of advice often tells people to have a long-term goal or strategy in mind. It will often have some argument that's along the lines of "a random walk will only move you sqrt(n) in some direction whereas a directed walk will move you n in some direction". I don't think that's wrong, but I think that, for many people, that advice implicitly underestimates the difficulty of finding an area that's suited to you, which I've basically done by trial and error.

Un article sur l’apprentissage qui résonne bien avec l’évolution de carrière « en diagonale » dans un article que je vous avais partagé le 6 octobre. Ça va dans le sens d’un article qu’on m’a partagé récemment qui donne des justifications plus scientifiques à ces approches, et que j’enverrai certainement la semaine prochaine.

Liens du 17 novembre 2023

Fri, 17 Nov 2023 00:00:00 GMT

0x4 reasons to write and publish, Artificial intelligence technology behind ChatGPT was built in Iowa — with a lot of water, Why You Need Systemic Reasoning

0x4 reasons to write and publish

There are many types of brain out there. They all click in different ways. Chances there are people who click like you do. If you take the time to explain something difficult in your own way, it will without a doubt help others.

Ultra-court. Je crois que je répète assez souvent ce que dit la citation.

Artificial intelligence technology behind ChatGPT was built in Iowa — with a lot of water

In a paper due to be published later this year, Ren’s team estimates ChatGPT gulps up 500 milliliters of water (close to what’s in a 16-ounce water bottle) every time you ask it a series of between 5 to 50 prompts or questions. The range varies depending on where its servers are located and the season. The estimate includes indirect water usage that the companies don’t measure — such as to cool power plants that supply the data centers with electricity.

L’article n’est pas long et parle également des augmentations de la conso globale chez plusieurs cloud providers. J’ai hâte de voir le papier sous-jacent une fois publié.

Why You Need Systemic Reasoning

Content management software defined the boundaries of a website. Individual people and large organizations installed a single piece of software to create a lovely digital space. They encouraged users to visit there and interact.

Now, many people and organizations want to COPE: create (content) once and publish (it) everywhere. A website is only one of many digital tools used for sharing, displaying and consuming information. Users are everywhere, interacting. Information from one piece of software is purposefully intermixed with information from others (though they are often incompatible) and then shared with still more.

The impact of this change is profound. Developing emerging digital systems requires expertise in 10Xs as many technology tools as the software alone did. And often, a very different mindset for everyone involved.

Yet, we transfer our linear thinking models and processes to our systems building. We might, for example, maintain feature-driven development, outlining “requirements” and model a conveyor belt of delivery. We concretize workflows rather than make them more fluid and flexible. We focus on designing linearly-governable parts while ignoring the relationships between the parts. We continue to stratify strategic decision making and structure people into silo’d teams to deliver it. We add more people to control the people doing the work. We attempt to mitigate all risk before taking any action. We accept “technical debt”, the impact of our successes, as a fact of life.

But what happens as complexity increases – when our software becomes one part of a larger system? When the relationships between software become complex? We invest a tremendous amount of energy into creating interrelated software systems using linear approaches. A feat that simply can not be accomplished.

We adopt new “modern” tools to move from software to systems … then build the exact same software.

Diana Montalion écrit et forme sur des compétences permettant d’approcher et réfléchir aux systèmes complexes. Dans cet article elle identifie certaines des raisons pour lesquelles notre mode de pensée linearisant nous rend incapable de maîtriser nos systèmes, et ce à quoi peut ressembler une équipe qui intègre une pensée complexe. Je vous enverrai bientôt la vidéo d’un des workshops auquel j’ai assisté avec un collègue, puis d’autres ressources autour de ça.

Dans la même lignée d’outils, je vous avais déjà partagé il y a quelques semaines un article sur les diagrammes de causalité (un site complet sur le sujet en fait)

Liens du 24 novembre 2023

Fri, 24 Nov 2023 00:00:00 GMT

Cloud dark pattern, The Feedback Fallacy

Cette fois je ne vous propose que deux articles, parce qu’ils sont plutôt longs, et surtout intéressants.

Cloud dark pattern

In this paper, we present an exploratory study of the cloud and edge paradigm with regards to sustainability. Inspired by dark patterns in UX, we introduce the concept of unsustainable patterns that we formalize into a Pattern Model. Then, we present and analyze a set of 27 unsustainable patterns resulting from the analysis of two focus groups. We also identify countermeasures and discuss takeaways in order to pave the way for further studies in this area.

Le résultat d’un groupe de travail, pas extrêmement long (pour un format style papier de recherche), mais qui propose une technique de catégorisation originale des services cloud en fonction de leur impact écologique en suivant le principe des Dark Patterns. Les Dark Pattern dont il est question sont des modèles d’UX qui incitent l’utilisateur à réaliser des actions qui étaient hors de ses intentions initiales. À travers ce prisme, le groupe de travail a tenté de modéliser les types de services qui par leur design mènent à un résultat écologique négatif.

The Feedback Fallacy

For years managers have been encouraged to candidly praise and criticize just about everything workers do. But it turns out that feedback does not help employees thrive. First, research shows that people can’t reliably rate the performance of others: More than 50% of your rating of someone reflects your characteristics, not hers. Second, neuroscience reveals that criticism provokes the brain’s “fight or flight” response and inhibits learning. Last, excellence looks different for each individual, so it can’t be defined in advance and transferred from one person to another. It’s also not the opposite of failure. Managers will never produce great performance by identifying what they think is failure and telling people how to correct it.

Que vous soyez manager ou non, cet article est pour vous.

Enfin de quoi confirmer mes intuitions. Cet article du Harvard Business Review expose le résultat de recherches sur les feedback dans le management. Il est long, mais très intéressant. Il y a de quoi faire réfléchir sur les situations qu’on rencontre tous les jours en management.

Liens du 9 février 2024

Fri, 09 Feb 2024 00:00:00 GMT

Diluting DORA, How Marketers and Consultants Bastardize Engineering Best Practices, I miss human curation, Use the index, Luke !, Test Cases Are Not Testing

Long time no see, uh ? J’avais besoin d’un break avant les fêtes de fin d’année, et à partir de là les choses n’ont tout simplement pas baissé en rythme et charge avant que je parte un mois en congés jusqu’à mi février. Je profite d’un moment de mou pour vider un peu du backlog de liens. Ce n’est cela dit qu’un post irrégulier, il faudra encore attendre avant la vraie reprise !

I miss human curation

Especially now that Twitter is kind of a mess (I won’t get into other social networks, but they all feel like this lately), the networks of people that I know are really hard to navigate. I can’t really swing from profile to profile of friends like I did before. The Algorithm wants me to see content relevant to me, not my friends. We don’t have “affiliate links” in our website footers anymore to go down rabbit holes of other websites, and I rarely see a little corner of the internet that I can bookmark and check on regularly. Those spaces do exist, but they’re just much, much harder to find.

As I noodled on this, I realized that in addition to my missing humans curating the content for me, it’s also me curating what I want to see, when I want to see it, better. There was an interesting note in Alexander Obenauer’s lab notes about notifications, and this line stuck out to me: “fundamentally, the way notifications work in modern OSes is backwards: someone else decides when (and how often) my device wakes up to interrupt what I’m doing.”

Un article pas bien long, similaire à ce que j’ai déjà pu partager sur le sujet du « bon vieil internet ». Et je repartage ce type de contenu parce que c’est précisément ce genre de choses qui m’a poussé à tenir cet endroit, et que si l’on veut que notre connaissance ne soit pas complètement maitrisée par des tiers aux intentions bien connues (d’un point de vue systémique notre système économique emmène vers une forme d’attracteur géant qui focalise tout le monde au même endroit, le nombre de chemins alternatifs réduit à mesure que l’on se concentre sur le mainstream, un jour je prendrai le temps de pondre un truc plus complet la dessus), on doit se rappeler périodiquement et collectivement qu’il n’appartient plus qu’à chacun d’entre nous d’entretenir un peu de sérendipité.

Use the index, Luke !

A site explaining SQL indexing to developers—no crap about administration.

SQL indexing is the most effective tuning method—yet it is often neglected during development. Use The Index, Luke explains SQL indexing from grounds up and doesn’t stop at ORM tools like Hibernate.

Use The Index, Luke is the free web-edition of SQL Performance Explained.

Je partage ici parce que je dois distribuer ce lien tous les ans. J’ai dû découvrir ce site en 2014 je crois. Plus sûr de qui me l’avait recommandé, mais c’est depuis tout ce que j’ai eu à savoir pour utiliser une base relationnelle avec la bonne hygiène. À lire avant d’accuser votre architecture logicielle, de vouloir utiliser un cache (misère), ou de payer un DBA.

Test Cases Are Not Testing

Can an algorithm exist that will guarantee we find all the important bugs? No. This is a matter of basic computing theory (see the Halting Problem) and the fact that bugs are socially constructed by users rather than being something to do with the essence of the product. Bugs are not “in” the product. Bugs are about the relationship between the product and the people who desire something from it. It’s possible for a bug to be created or resolved just by changing the stakeholder. And apart from every other problem, a total bug identification algorithm would require a complete, unambiguous, and up-to-date specification that is accepted by all stakeholders... and when was the last time you saw one of those?

When we test we are exploring the relationship between the product and values about the product. To do so, we must make many social judgments, including judging the importance of testing a specific situation, and judging the meaning and importance of potential problems.

Un article top sur les tests, et notamment les tests exploratoires. Un bon complément pour cet épisode de podcast sur les tests que nous avons enregistré avec un collègue.
J’ai particulièrement été sensible à la perspective selon laquelle les bugs n’existent que dans la relation entre le logiciel et les utilisateurs.

Diluting DORA: How Marketers and Consultants Bastardize Engineering Best Practices

I have a somewhat unique and fairly thorough understanding of how marketers and consultants do this, how they take useful technical best practices and bastardize them for their own gain. I have a Computer Science degree and started my career as a computer programmer. I moved up into a system administrator role – the spiritual predecessor to DevOps roles. Eventually, I decided to get an MBA and worked for Deloitte as a senior consultant and eventually manager on tech projects afterward. After Deloitte, I moved into product marketing, working at DirecTV and then at several tech companies including New Relic, Twilio Segment, and, now, Earthly. I have been the user, the buyer, the marketer, and the consultant at different points in my career. I’ve seen this pattern repeated over and over.

In this post, I’m going to focus specifically on DevOps Research and Assessment (DORA), what it is, why it matters, how marketers and consultants abuse it, and the negative impacts that abuse causes.

[…]

The organizational change required for DevOps to thrive and for DORA metrics to be their most useful has to come from within an organization. You can’t outsource it or ask an outsider to do it for you, because the hard part isn’t the right tool or metric, but the people and processes.

Le dernier morceau cité. Cet article m’a rassuré parce qu’en tant que consultant je ne vends pas DORA ou SPACE comme une solution (même si parfois c’est le client qui voudrait absolument que ce le soit, habitué à ce qu’on « installe » des solutions et hop « tout est réglé »). La dernière fois que j’ai pu utiliser cet outil, c’était pour factualiser une partie du vrai taf derrière, qui était d’accompagner une équipe dans son amélioration continue. À la fin la solution qui a marché (et ça on le découvre en même temps que le reste de l’orga) était d’apprendre à l’équipe à savoir mener des débats et prendre des décisions entre eux. Soudainement, à partir de là, ce n’est pas qu’on met un coup d’Accelerateur, mais on vire les freins et frictions, et juste ça file et s’emballe (et à quoi bon accélérer quand on a encore le frein à main n’est-ce pas ?).

Le tout est moins que la somme des parties

Fri, 23 Feb 2024 00:00:00 GMT

Oui, ce titre est légèrement provoc’ quand on a plus souvent entendu "Le tout est plus que la somme de ses parties". Et pourtant, comme nous allons le voir par la suite, il n’est pas moins vrai. Le but de cet article n’est pas de fournir des éléments immédiatement activables, mais d’ouvrir les perspectives sur ce qu’il se passe quand on ajoute des choses dans un système, qu’il soit humain, technique ou autre. Mais d’abord, …

Pourquoi entend-on "le tout est plus que la somme de ses parties"

Vous êtes sûrement déjà tombés dans des situations où la logique de gouvernance d’un système est qu’en ajoutant une chose ou en retirant une autre, alors on ajoute ou retire des "capacités" à ce dit-système. Par exemple, ajouter un testeur à cette équipe pour augmenter la qualité de ce qui est produit par l’équipe. On suppose alors que le simple fait d’ajouter cette personne suffira à ce que l’ensemble du système qu’est l’équipe soit doté de cette capacité. Même exemple avec une application, il suffit d’ajouter une fonctionnalité à celle-ci pour que le système que l’on nomme application soit tout simplement et uniquement doté des qualités de la fonctionnalité.

Un des angles morts de ce raisonnement est que l’ajout d’un élément au système peut faire "émerger" de nouvelles capacités. Émerger dans le sens où aucune des pièces ou composantes du système n’est initialement en possession de cette capacité, mais que celle-ci "nait" de par l’organisation des composants entre eux. L’organisation n’est pas seulement "comment sont positionnés ou agencés ces composants", mais aussi "comment ils interagissent", "comment ils se réagencent suite à l’ajout", et "comment ils modifient et se font modifier au sein de leur environnement".

Si on reprend l’exemple de l’ajout d’un testeur au sein s’une équipe, le mode de pensée critique inhérent à ce rôle va "filtrer" des défauts, il dotera donc effectivement l’équipe d’une capacité supplémentaire de filtre de ce qui est jugé être un défaut de l’application, ce qui résultera d’une meilleure qualité produite par ce système. Le testeur étant doté de cette capacité, son ajout à l’équipe "ajoute" de fait cette qualité. Mais les bénéfices ne s’arrêtent pas là.

Par exemple, les interactions entre le testeur et les développeurs peuvent avoir un autre impact : Par l’apport de ce mode de pensée critique, l’équipe observera probablement des patterns qui mènent à la production de défauts du même type, et alors l’équipe se dote d’une capacité d’analyse et prévention de certains défauts dès la conception. Avant l’apparition de ce testeur, cette capacité de design prévenant certains défauts n’existait ni chez le testeur, ni chez les développeurs, qui vont certes tenter ce qu’il peuvent pour prévenir les défauts mais de façon incomplète comme cela se produit souvent lorsque l’on est à la fois juge et parti. Cette capacité de prévention de défauts apparait alors de l’organisation entre les développeur et le testeur, car le testeur arrive après la production des développeurs. Il constate ce qui a été réalisé et utilise la capacité qu’il possédait déjà avant. Mais elle "nait" aussi de la nouvelle interaction entre le testeurs et développeurs, puisqu’en présentant les défauts et discutant de la typologie des défauts passés, les développeurs peuvent constater des patterns liés à leur façon de produire et concevoir.
C’est une capacité émergente aussi car si nous "désassemblons" cette équipe, nous perdrions cette capacité dans le sens où aucune personne n’en est seule porteuse. Le testeur ne l’aura pas car le développement ne fait pas partie de son travail — il doit garder une distance pour rester critique — et que les développeurs n’auraient que la connaissance des patterns qu’ils ont rencontré par le passé, et n’auraient pas, seuls, la capacité de rester totalement critiques sur ce qu’ils produisent

Et c’est bien souvent pour expliquer en ce sens qu’une équipe est plus que la somme des personnes qui la composent que l’expression "le tout est plus que la somme de ses parties" est utilisée. On veut transmettre le fait qu’en tant qu’humains nous avons la capacité de nous organiser et interagir pour faire "naître" de nouvelles capacités d’équipe, que nous ne sommes pas des "ressources" ou "composants" individuels qu’il suffit d’ajouter ou déplacer, et que notre organisation et nos interactions nous permettent bien plus en tant qu’équipe.

Mais cet usage fréquent de l’expression "le tout est plus que la somme de ses parties" en fait parfois un argument qu’on mobilise à tout va, mobilisé comme une règle nébuleuse devant interrompre les débats entre la perception "assemblage de composants" versus "système complexe", ce qui nous empêche à la fois d’avoir du recul sur tous les effets, mais aussi de comprendre les mécanismes sous-jacents des propriétés d’une équipe. En décortiquant l’exemple précédent on peut remarquer certaines choses, notamment que pour que cette capacité émerge, il y a aussi des conditions. Par exemple, si l’équipe est agencée de façon à ce que le testeur arrive après le développement, mais qu’il ne communique que par la remontée de tickets de défauts observés, l’équipe n’aurait pas les conditions nécessaires d’une conversation riche et moins structurée entre testeur et développeurs lui permettant de déceler des typologies de défauts. Pire encore, elle pourrait même perdre certaines capacités portées par ses membres qui font qu’on peut aussi dire que …

Le tout est moins que la somme de ses parties

Car si la communication entre testeur et développeurs est perdue, ou bien se résume à un sens unique sous forme de tickets, ou encore que l’organisation fait sentir que la qualité est le problème du testeur, alors la nature des tâches de ce dernier va changer. C’est à dire que le testeur, qui jusque là utilisait sa pensée critique pour trouver par exemple des failles de parcours, tomberait plus facilement sur des problèmes récurrents ou de qualité technique, et serait ralenti dans sa tâche de détection de défauts plus complexes et occasionnels, voire réduit lui-même à remonter les régressions élémentaires et récurrentes qui s’accumuleraient. L’équipe, composée notamment du testeur et de sa capacité de pensée critique, réprimerait alors de par son organisation et ses règles d’interaction la capacité de l’un de ses membres. Le tout serait alors moins que la somme des parties.

Un autre exemple dont on connait l’adage, ajouter des gens à un projet en retard aura pour résultat de retarder encore plus le projet. Quand bien même l’équipe serait dotée de "bras supplémentaires" et d’un "cerveau en plus", le projet ralentirait par "l’ajout" d'une personne. Par exemple parce que chaque tâche nécessiterait un fort taux de coordination pour être réalisée, ce qui réprimerait alors les capacités de "production" de chaque membre.

Idem en logiciel, l’ajout successif de fonctionnalités peut à la fois faire naître et réprimer des capacités. Dans une base de code où l’on "empile" les fonctionnalités sans remettre en question l’organisation et l’interaction des composants, l’entropie s’accumule et réduit la capacité à faire évoluer le programme. Tandis que dans une base de code où le refactoring fait partie des pratiques courantes de développement, les réflexions et apprentissages ont le potentiel d’accélérer le développement par une meilleure compréhension du domaine et de la façon dont on devrait y répondre par l’organisation et l’interaction d’éléments du code.

Ces exemples montrent des effets de répression de capacité que l’on peut considérer comme négatif. Mais dans certains systèmes, la répression peut être un effet voulu. Très simplement : introduire une règle ou loi au sein d’un collectif peut changer le mode d’organisation et d’interaction de façon à réprimer des comportement non désirés. Ou encore, ajouter une quality gate dans un pipeline de Continuous Integration pourrait réprimer l’apparition de certaines propriétés, bugs, comportements dans la suite du workflow.

Cependant, on peut encore aller bien plus loin en questionnant ces expressions, car dire que le "tout est plus ou moins que la somme de ses parties", …

Ça dépend de ce qui est souhaité et/ou souhaitable

L’expression, contenant les mots "plus" et "moins", est plus souvent utilisée pour décrire des effets souhaitables ou non que des ajouts ou suppression de capacités.
Dans certains cas, l’apparition d’une capacité ou propriété peut être un effet bénéfique pour le système, dans d’autres, cette même capacité peut être défavorable au système. Par exemple, ajouter un comité de validation de tous les changements que subit une application a des chances de ralentir le processus de développement, de retarder la mise en production qui mettra à l’épreuve cette application. Ce pourrait être un effet défavorable, car dans le cas où cette application a besoin d’évoluer fréquemment pour obtenir du feedback du marché, les hypothèses contenues dans le système pourraient vite devenir obsolètes à cause de la vitesse d’évolution de ce marché. Dans un autre contexte, comme dans le développement de systèmes médicaux, ce garde-fou serait d’une valeur inestimable car il protègerait des vies. "Plus" ou "moins" dépend alors de ce que l’on recherche. Et le simple fait de considérer ce qui est souhaitable ou non influe sur notre décisions d’ajouter ou retirer des éléments d’un système.

La réflexion ne peut donc s’arrêter à "un composant = une capacité pour le système", ni à "un composant modifie les propriétés du système", mais doit encore s’étendre pour comprendre "ce qui est voulu ou non". C’est à dire qu’il faut également considérer le contexte dans lequel le système s’intègre, et qui lui-même ajoutera, réprimera, ou fera émerger des propriétés. Car considérer que quelque chose est souhaitable ou non, c’est aussi établir une règle qui modifiera notre façon de concevoir le système, et donc qui réprimera ou fera émerger des capacités dans la conception du système.

Conclusion

Quand on dit donc "Le tout est plus que la somme des parties", on doit donc considérer que ce "plus" peut vouloir dire quelque chose de différent pour chaque participant de la conversation, et que si l’on ne se met pas d’accord sur l’objectif de ce tout on ne se comprendra pas en parlant de ce tout. Cette première question devrait donc déjà enrichir le débat (ex: Que doit accomplir ce code ? Que doit accomplir cette équipe ?). On peut ensuite se poser les questions complexes de ce que réprimeraient ou feraient émerger la modification de ce tout, non seulement en ajoutant ou supprimant des parties (ex: ajouter ou supprimer du code ? embaucher des devs en plus ou non ?), mais aussi en modifiant l’organisation et les modes d’interactions de ces parties pour modifier les propriétés du tout (ex: refactoring de code, nouvelle gouvernance, …). De quoi mettre la puce à l’oreille la prochaine fois qu’on vous jettera un "le tout est plus que la somme des parties".

Liens du 8 mars 2024

Fri, 08 Mar 2024 00:00:00 GMT

Interesting work happens at the edges., TBM 274, How Capable Leaders Navigate Uncertainty and Ambiguity, The Update, The Vent, and The Disaster, Turning todos into tadas.

Cette semaine c’est spécial management, notamment parce que ça concerne quelques personnes ici et que ça fait partie des choix de carrière. Et pour bien informer ce choix, ces articles donnent à voir sur le métier, qui ne devrait pas être la suite logique d’une évolution de carrière. Le management vu comme une promotion est une vision qui mine le milieu professionnel et à l’origine de nombreux drames humains car manager implique d’avoir un minimum d’intérêt et de respect pour l’espèce humaine et sa variété d’individus. Dans une réunion récente avec des managers, nous avons présenté les exigences de bases que nous regarderions pour évaluer la « performance managériale », une des remarques qui a été faite était : « mais si on a tout ça à réaliser et peu d’avantages c’est presque un sacerdoce ». En substance : oui. Je pense que la clé d’un meilleur management dans notre industrie est de miser sur la motivation intrinsèque des managers à répondre aux attentes de l’entreprise à travers les attentes des employés, et ce au détriment d’aucune de ces parties, y compris le médiateur qu’est le manager.

Je suis intéressé par toute remarque vis à vis ou non de ce contenu, et si vous avez des attentes sur le sujet, dites moi ! Vous pouvez me pinguer en réponse au mail qui part avec ce billet ou par tout autre canal dont vous avez connaissance.

Interesting work happens at the edges.

group management is a very different job than team management, and is often both less rewarding and less likely to facilitate ongoing learning.

[…]

Fast growing companies generate a huge amount of change, and the primary function of group managers in those organizations is to absorb change effectively. However, they often lack much control over that change, and end up with the underwhelming choices of pushing the chaos to their team or personally absorbing it. The former violates the manager’s pact–you’re there to help–and the later is a reliable path to burnout.

On stretch un peu sur le management, mais ça donne à réfléchir sur les choix de carrière.

TBM 274: How Capable Leaders Navigate Uncertainty and Ambiguity

That’s the question Tom (author of the Innovation Tactics card deck) and John posed themselves in a recent conversation. These skills are typically lumped under “soft skills” and “culture fit”.

But what if we made them explicit?

We started by describing general behaviors (“What would we observe?”) and then wrote definitions in the standard “the ability to…” format. We tried to keep the descriptions reasonably lingo-free.

Une forme d’index de « capabilities » manageriales qui me parlent, et me rappellent en partie ce lien que j’avais partagé il y a un moment.

The Update, The Vent, and The Disaster

You get exactly what you expect from The Update — its status. These are my projects, and these are my people, and this is how it’s going down. Most folks consider this type of 1:1 a success, and they’re wrong.

A 1:1 is not a project meeting. A 1:1 is not a status report. See all those project managers scurrying to and fro? Their job is the maintenance of the facts and the discovery of project truth. If you’re drawing the line for success in your 1:1 as the discussion of data you could find in a status report, you’re missing the point.

Je pense que j’ai trouvé ma chambre d’écho sur le sujet. Ce moment est le coeur du réacteur managérial.

Turning todos into tadas

I’m trying to shift my mindset away from todo lists. It’s easier said than done, but I’m doing a little :%s/o/a/g in my brain when it comes to todos (which for non-vim normal humans, replaces the os with as, to turn “todos” into “tadas”). I want to focus less on “this is what I have to check off for the day” to feel like I have things managed and under control, and more on, “these are the things I did today, tada!”

Oui on s’éloigne du management, mais pas vraiment. Quand vous passez manager, votre todolist risque de prendre des formes étranges, et certaines périodes risquent de vous mettre incomparablement plus à l’épreuve que d’autres (la variabilité peut être démente) et vous mettront au pied du mur: vous devrez choisir vos combats, et parfois saisir ce qui vient sans que ça suive le plan ! C’est un shift que j’opère petit à petit. J’ai constaté que bien souvent mes todos se rallongent, et que bien souvent ce qui s’y trouve ne mérite pas ou plus de rester dans ma charge mentale par rapport à d’autres choses immédiatement à portée. Et ces tâches facilement à portée ne sont pas nécessairement des quick-win, ce sont parfois des choses dont on verra les résultats que bien plus tard, mais de petites actions à effet levier. Ce qui fait que je nettoie finalement pas mal ces todos, et me satisfait d’avoir accompli certaines choses qu’elles soient planifiées ou non. La clé pour moi est d’avoir une bonne vision sur les grands sujets et d’être toujours à jour sur le contexte général pour savoir reconnaître chaque opportunité. Je vois passer un bon nombre de « merci » récemment, c’est que je ne dois pas faire complètement fausse route ?

Management & Systémique - Accept We Are Part of the Problem

Fri, 15 Mar 2024 00:00:00 GMT

Pourquoi cet article

J'ai souvent entendu que les concepts de cybernétique ou systémique étaient peu activables ou difficile à mobiliser. Et dans la dernière suite de liens, focus sur le management, un des articles m'a spécialement tapé dans l’œil : "How Capable Leaders Navigate Uncertainty and Ambiguity". En lisant chacune des "capabilities" je me suis dit qu'il y avait un angle "systémique" à aborder, de la même façon que pour "Le tout est moins que la somme des parties". Une manière d'illustrer ces mécanismes dans un contexte qu'on peut observer quotidiennement en milieu professionnel. Je tente alors en décortiquant une première "capability", et vous me direz si ça vaut une suite sur les autres.

Accept we are part of the problem

"The ability to recognize and accept one's role in creating, contributing to, or perpetuating the current situation."

Interview Question:

Can you share a specific instance when you recognized your contribution to a problem? What led to this realization, and how did it influence your actions in the future?

La science du contrôle

Dans l'histoire de la cybernétique, deux mouvements ont eu lieu. Le premier est ce qui a donné naissance à ce que l'on appelait la cybernétique de 1ᵉʳ ordre. Elle a rassemblé de nombreuses disciplines scientifiques qui ont tenté de mettre en évidence des concepts communs entre elles, modélisant la façon dont l’information permet à un système de s’articuler, se commander. Ces disciplines étaient très variées, et rassemblaient des disciplines de la biologie, la sociologie, la physique… De là, la notion de "système" s'est définie autour de l’information, la commande et la régulation. L'objectif scientifique derrière ce mouvement était notamment d'améliorer la compréhension de chacune des disciplines à travers ce prisme commun, mais aussi de comprendre comment un système, animal ou machine, se contrôle. Selon Wikipedia :

Wiener déclare avoir fait dériver le mot cybernétique « du mot grec kubernetes, ou pilote, le même mot grec dont nous faisons en fin de compte notre mot gouverneur »
Un second mouvement eu lieu quelques dizaines d'années plus tard, la cybernétique de second ordre. Bien qu'aujourd'hui elle soit absorbée par la systémie, les découvertes notables de ce mouvement ont perduré : l’auto-organisation, l'émergence, et, finalement, la considération que l'observateur fait partie du système. Et c'est exactement cette considération sur laquelle insiste le principe managérial mit en évidence par l’article « Accept we are part of the problem ».

L'observateur fait partie du système

De nombreux rôles omettent ce principe, non qu'ils se sentent simples observateurs, mais parce qu'ils sous-estiment l'impact de leur présence au sein de ces systèmes. Vous les connaissez. Les architectes, les managers de tout niveau, les consultants, et cetera. Quand un problème est observé, ces personnes vont considérer au mieux que le système observé est "malade", au pire que la « faute » de l'échec du système est due à l'une de ses parties, et qu’il faut agir ou informer depuis leur position pour que le système « guérisse ». Dans un système humain, par exemple une équipe, une erreur ou échec à réaliser une tâche ou atteindre un objectif sera attribuée à l'une des parties, voire à l'ensemble des parties, et mènera au blâme d'une ou plusieurs personnes, et/ou à une "correction" de son comportement. Ils s'attendent alors, suite à ces actions punitives ou correctrices, à ce que tout rentre dans l'ordre. Bien souvent, le problème est ailleurs, les causes sont même multiples, et une part des causes revient justement… au manager. Car si le système, l'équipe, peut être observé, c'est qu'il n'est pas complètement fermé. On en reçoit au moins des signaux, des informations, il nous impacte de façon directe ou indirecte, "quelqu'un nous a raconté que ..." ou "le chiffre d'affaires est ...". Le manager va donc recevoir ces signaux, et va réagir à ceux-ci par une ou des actions plus ou moins conscientes, que ce soit directement ou à travers un intermédiaire. Et cette action aura donc des effets sur l'équipe. Et à son tour l'équipe sera altérée, ce qui pourra être perçu à travers d'autres signaux. L'observateur fait partie du système.
Tentons d'illustrer ce propos à travers un exemple.

Les coûts du blâme

Un manager s'inquiète de la performance de son équipe, car les objectifs ne sont jamais atteints aux échéances. Il va donc chercher des informations supplémentaires pour confirmer son intuition, mais ne fait pas confiance à son équipe. Il veut alors pouvoir s'informer par le biais de métriques censées représenter l'activité d'équipe. Les indicateurs sont d'abord mauvais, mais après que le manager leur ait bien montré qu'ils devaient s'améliorer selon ces métriques, ces dernières s'améliorent très vite. Cependant, à l'échéance suivante, l'équipe a cumulé un retard encore plus important.

De "son côté", l'équipe, qui a déjà remonté des problèmes à son manager, a compris que celui-ci les blâmerait pour chaque erreur ou problème qui lui serait communiqué. L'équipe a donc cessé de remonter ce type d'information négative, par exemple qu'un prestataire bloquait l'avancement sur certaines de leurs tâches. Quand les métriques ont été mises en place, le manager a fait part de son mécontentement à l'équipe, bien content de constater que son intuition était vraie : ça n'avance pas. Elle a ensuite compris la façon dont ces métriques pouvaient être positivement influencées, donnant le feedback erroné au manager que la situation était saine, alors que l'équipe cumulait les problèmes.

Le manager, par sa réaction aux feedbacks de l'équipe, a saboté sa structure de communication, comme le disait G. Weinberg. L'équipe étant blâmée lorsqu'elle remonte des difficultés, elle fait désormais en sorte de ne remonter que des choses positives, privant ainsi le manager et elle-même de tout levier d'amélioration de la situation.
Les symptômes ou conséquences les plus visibles de ce type de phénomène sont une demande d’audit et/ou d’accompagnement de la part de la hiérarchie, le recrutement d’autres rôles pour « maîtriser la situation », c'est-à-dire toujours plus de contrôle.

Questions d'interview

Les questions d'interview posées sont donc exactement ce qu'il faut rechercher. A-t-on affaire à un manager qui sait qu'il est dans le système et donc un des facteurs des problèmes qu'il observe ? La différence d'expérience entre un manager qui connait son impact envers son équipe et un manager qui ne le connait pas sera notable. Car cette réalisation a le potentiel d'impacter toutes les pratiques managériales, du one-to-one à la revue de performance en passant par la gestion de carrière et encore la capacité d'emmener une équipe vers un objectif. Pour un manager qui sait prendre ce recul, ses réflexes aux situations managériales courantes seront donc très différentes de celles d'un manager qui ne s’est pas encore considéré comme faisant partie du système, des réflexes qui prennent du temps à être acquis

Liens du 22 mars 2024

Fri, 22 Mar 2024 00:00:00 GMT

The web I want, Why You Can’t Yoga Your Way Out Of Burnout, Trusted peers network, Guide To Root Cause Analysis – Steps, Techniques & Examples

Trusted peers network

Being in a TPN has a drawback: when you have a set of unofficial shortcuts that enable you to make things done, it can be tempting to rely on it as much as you can and thus to only use the official processes when you can’t escape it.

People have valid reasons to do it, but it can be bad for the system as a whole.

People in a TPN often have some political weight in the organization because of their TPN membership but also because of the same characteristics that allowed them to be part of it.

When an official process is not working as intended, or when its becoming worse

Un article qui pose des mots sur quelque chose qui me chiffonnait, notamment parce que j'ai été sensibilisé par "The tyranny of structurelessness" (lien que j'ai dû relire et refiler un nombre incalculable de fois). Mais je pense avoir eu une approche pas trop déconnante depuis plusieurs mois : je peux faire avancer, débloquer, certaines choses parce que je connais du monde dans la boite, ce qui fait que je peux obtenir l'aide et le conseil au moment où j'en ai besoin. Quand je vois que quelqu'un se trouve face à un mur, que la personne n'arrive pas à mobiliser les bonnes ressources pour faire son boulot, je tente de mobiliser ce réseau pour :

répondre à la demande immédiate
documenter publiquement le moyen de trouver de résoudre le problème

La réaction de certaines personnes est : "encore des process". Oui, mais des process qui libèrent.

Why You Can’t Yoga Your Way Out Of Burnout

I burned out during the last year of my law practice, and I spent a lot of time wondering what I did to cause it. I assumed that I had poor stress management skills or that something else about me needed to be fixed or changed. That’s the message that many people are left with in the burnout discussion – that it’s simply an individual issue that can (and should) be fixed with self-care strategies. As I learned, it’s not that simple.

Le burnout abordé sous la perspective de la relation employé-entreprise plutôt que employé seul. Attention, vous risquez de reconnaitre des situations vécues, par vous ou vos collègues (si c'est le cas, suivez le process interne correspondant ou contactez quelqu'un qui puisse vous orienter sur la démarche à suivre dans votre entreprise).
Le papier en lien dans l'article sur les "six job demands" est ce que j'ai lu de plus complet sur le sujet. Si l'article vous a plu, ce papier vous intéressera d'autant plus.

The web I want

The web I want is powered by passion, not money.

Court.

Guide To Root Cause Analysis – Steps, Techniques & Examples

RCA (Root Cause Analysis) is a structured and effective process to find the root cause of issues in a Software Project team. If performed systematically, it can improve the performance and quality of the deliverables and the processes, not only at the team level but also across the organization.

Je cherche un article qui développe l'analyse systémique des causes de bugs. Je suis tombé sur ça qui parle du fishbone et 5 whys, avec des exemples. C'est pas mal, mais il me manque du détail sur l'analyse des causes, ou probablement plus d'exemples. J'aimerais aussi que ça mette en évidence les patterns entre bugs (ici je pense que comparer les fishbones peut être une approche). Je n'avais jamais vu le fishbone avant, et ça me parait pas mal à tenter, notamment parce que ce modèle considère qu'il peut y avoir des causes multiples à un problème. Il manque aussi une mise en garde pour les 5 whys ici, on ne cible personne. Traitons les procédés et les processus pour que n'importe qui dans l'équipe puisse réussir.

O3 cheat sheet

Tue, 26 Mar 2024 00:00:00 GMT

Pourquoi cet article

La question du contenu du One on one (O3) revient souvent. La façon dont je les fais vient autant de mes managés, que de ce que j'ai pu lire sur le net, que de ce que j'ai pu expérimenter avec mes managés (et leur accord !). Le souci, c'est qu'il y a autant d'explicite que de tacite, et n'ayant jamais vraiment structuré la pratique jusque-là, je tente la mise à plat ici pour clarifier le discours. Je tenterai d'actualiser cette page.

Pourquoi c'est important

C'est le point crucial de votre vie managériale. Sans lui, vous êtes passés à côté de tous les petits détails qui mènent aux gros désastres. Mais si ces désastres, vous savez, ces moments où on constate que nous sommes passés à côté de nos objectifs, ou bien ces moments où une personne s'effondre de fatigue, ou qu'un conflit irrémédiable déclenche une démission. Si seulement vous aviez pu détecter le moment où un feedback aurait suffi à calmer la situation. Tout le but donc, c'est que le managé et le manager puissent orienter la barque par petites touches et ne rien laisser moisir.

Ce point régulier est un espace de parole dédié à chacun dans cette relation, managé et manager. C'est un des moments privilégiés où vous entendrez les premiers signaux faibles d'un burnout, mais aussi où vous pourrez écouter, rassurer, recadrer, sans le biais de la présence d'autrui qui fausse la relation. L'essentiel de la conversation de l'O3 devrait être porté sur l'employé dans son contexte, pas sur la progression de son activité. Ce que fait le managé quotidiennement, vous le savez parce qu'il y a un daily le matin, ou bien parce que vous collaborez sur le même sujet. Si vous n'êtes pas son manager opérationnel, la personne qui gère le courant des activités de son équipe, connaitre les grandes lignes est important pour avoir du contexte, mais le détail précis des tâches quotidiennes importe peu.

La logistique

toutes les semaines
30 minutes minimum
toujours le même jour à la même heure
c'est plus important que la plupart de vos autres points, réguliers ou ad hoc
des notes sont prises dans un doc partagé exclusivement entre le managé et le manager

Comment ça se passe

Vous arrivez à l'heure (à 5 min près) pour bien montrer que vous êtes là pour la personne, que son temps est précieux. Vous ouvrez le document partagé avec la personne pour prendre des notes, un journal, sur cette session. Peut-être votre managé a-t-il ajouté des notes entre les deux O3 pour se rappeler d'un sujet à discuter (et si ça n'arrive pas, invitez-le à le faire) ? Peut-être que vous-même, vous avez ajouté des notes pour parler d'un sujet avec votre managé ? Quoi qu'il arrive durant la session, c'est vous, manager, qui notez, et le managé qui parle. Le principe est qu'il soit concentré sur ce qu'il vous dit, et que vous, à l'écoute, notiez les points saillants, les évènements, les ressentis. En prenant en charge l'écriture, vous serez concentrés sur la bonne compréhension de ce qui est dit, et si vous doutez de ce que vous allez formuler, vous poserez des questions. En bref, vous serez en écoute active.
Le début du point est à peu près toujours le même, et correspond à un début classique de conversation : "comment ça va ?"
Aussi anodine que paraisse cette question, c'est le point de départ de l'analyse de la situation. C'est le moment d'être attentif à son Spidey-sense, et ces remarques devraient vous faire réagir, ou en tout cas creuser un peu plus :

Je me suis bloqué le dos -> excès de fatigue / charge ?
On se chamaille encore avec Machin, ça dure depuis 3 semaines -> abcès qui pourrit ?
Je n'ai pas trop la motivation en ce moment -> excès de charge / tâche ou objectif flou ?
Cette semaine, j'ai réussi ça -> fait d'arme qui se défend en évaluation ou féliciter publiquement la performance ?
J'ai beaucoup réfléchi à la feature x ce week-end -> déconnexion numérique ou charge mentale importante ?
Je n'aurai pas le temps d'assister à la formation y je dois ... -> les formations c'est un engagement, et devrait servir le plan de carrière et les besoins de la boite, que se passe-t-il ?
Je prends des congés la semaine prochaine -> tout le monde est au courant et saura gérer ?

Et, tout ça, vous l'aurez difficilement si on se contente de vous dire : "j'ai bossé sur le ticket 213, et là je suis sur le 215, tout va bien". Ce que vous cherchez, c'est :

si le managé est dans un rythme soutenable de travail (ils n'en sont pas toujours conscients)
s'il a tous les moyens nécessaires pour faire son boulot (formation, mentoring, etc)
si ses objectifs sont clairs et compris
si l'entreprise devrait s'inquiéter de la trajectoire que la personne prend (désalignement entre les attentes de part et d'autres)

Mais, vous cherchez aussi à valoriser le travail de la personne, d'une part pour qu'elle continue de faire ce qu'elle fait bien, et d'autre part pour chercher à amplifier les effets de ses réussites (ex : "j'ai fait un long message Slack qui explique les basics de tel outil, ça a plu", pourquoi pas en faire une sessions "hands on" et/ou le documenter de façon pérenne et/ou le communiquer à d'autres équipes).

Néanmoins, si vos managés ont encore peu d'expérience, ou que leur expérience managériale s'est arrêtée au suivi opérationnel, il est possible que la personne persiste à vous parler de ses activités quotidiennes. Dans ce cas, prenez les gens là où ils sont, rebondissez, creusez sur ce qu'on vous donne :

C'était difficile pour toi ?
Qu'est-ce que tu as fait pour t'en sortir ?
Cette feature est critique pour notre stratégie produit, penses-tu que vous avez les meilleurs moyens pour la sécuriser ?
Que te faudrait-il pour que tu te sentes confiant sur tel aspect ?
Tu t'es senti comment après ce feedback ?

Secret sauce : parlez ressenti, émotions. Le but n'est pas de jouer les psys, mais de faire prendre conscience à la personne que ses sens et émotions lui indiquent des choses sur ses compétences, ses envies, ses limites. Les connaitre, c'est s'équiper pour savoir comment réagir, que ce soit pour détecter la venue de désastre, mais aussi pour savoir s'en servir quand elles nous submergent. Si vous êtes deux à être attentif à cela, vous avez encore un coup d'avance pour orienter la barque. “Et quand on trouve une émotion, on en fait quoi ?”. De l’émotion, rien. Elle s’est factuellement produite chez la seule personne qui peut l’identifier. Donc en premier lieu, pas de “sois heureux”, ou de “tu ne devrais pas le prendre comme ça”, ni autre injonction qui nierait le ressenti de la personne. En revanche, c’est un indicateur de son besoin, et ça vous pouvez travailler avec. “Pourquoi étais-tu en colère quand il a critiqué le code que t’as écrit ?”. L’objectif est d’aider la personne à comprendre ce dont elle a besoin. Et, à partir du moment où le besoin est identifié, vous pouvez revenir à vos pratiques habituelles pour doter la personne des bons moyens pour atteindre ce besoin. Si vous connaissez le format OSBD de la Communication Non Violente, c’est effectivement ce dont je m’inspire.

Arrivés à la fin de la session, si vous (managé ou manager) sentez qu'il vous faut plus de temps pour comprendre ou creuser, voyez si vous pouvez continuer maintenant ou s'il faut réserver un créneau ad-hoc. Si la session suffit, vous aurez peut-être noté des choses saillantes pour se rappeler ce qu'il se produisait pour cette personne à cette époque, peut-être aussi des choses à revérifier la prochaine fois, ou bien des actions pour vous ou votre managé. Vous aurez probablement aussi partagé des liens vers des ressources internes ou externes, comme un lien vers la page décrivant la stratégie de la boite. Pourquoi pas la recette des Cookies ? C'est votre relation que vous entretenez, votre discussion, votre document, faites-en ce que vous voulez.

Si c'est la première fois que vous conduisez vos O3 de cette façon, vos débuts risquent d'être un peu robotiques ou étranges, mais surtout pour vous. Votre managé jouera le jeu la plupart du temps, et il faudra peu de pratique répétée pour que tout ça devienne plus organique et opportuniste. Pour cette personne, ce ne sera plus le point barbant du "status report", mais un créneau qui l'interroge, et durant lequel elle pourra se faire conseiller sur sa carrière et comment développer au mieux son potentiel dans l'entreprise.

Ne vous privez pas de parler de vous. Il s'agit avant tout d'une relation. En tant que manager, vous représentez la relation entreprise-managé, vous tentez d'autonomiser le managé dans cette relation et tentez de concilier les deux. Mais, n'oubliez pas que vous donnez l'exemple. S'ouvrir, c'est montrer aux autres que c'est possible et souhaitable ; faire preuve d'esprit critique et être constructif sur le fonctionnement de l'entreprise, c'est montrer que c'est possible et souhaitable ; suivre les consignes de son propre manager, c'est montrer que c'est possible et souhaitable. Quoi que vous envisagiez de faire ou de montrer ou non en O3, dites-vous que vous influencerez la perception de ce qui est acceptable ou non dans votre culture d'entreprise.

Quelques ressources qui en parlent

Un template de document d'O3 : si vous avez besoin de quoi booter un doc avec quelques exemples. Je vous conseille de faire votre déclinaison en entreprise sous l'outil qui vous convient le mieux, mais je vous déconseille de catégoriser plus. Le contenu doit suivre la conversation
The Update, The Vent, and The Disaster : Pour aller plus loin dans la façon d'aborder, creuser un O3 selon la posture de votre managé, mais aussi quelques tips. Son blog parle beaucoup de management en général.
Do You Want To Be A (Better) Manager : Un des bouquins les plus acides de Weinberg, et qui challenge à la fois les ambitions managériales qu'il vous outille pour tirer le meilleur parti de votre relation avec votre propre manager
The Manager's Path : A Guide for Tech Leaders Navigating Growth and Change : un guide de carrière sur les attendus et obligations managériaux au sein d'entreprise de toutes taille et pour plusieurs niveaux de management

Management & Systémique - Encourage new interaction patterns

Fri, 29 Mar 2024 00:00:00 GMT

Cet article suit le même modèle que le précédent : "Accept we are part of the problem". Le principe : étudier des "capabilities" managériales pour découvrir la systémique.

Encourage new interaction patterns

"The ability to encourage new interaction patterns within an environment rather than solely attempting to change (or remove) individuals. Help individuals connect and become exposed to new information and experiences."

Interview Question:

Describe a situation where you facilitated new ways for people to interact or share information. Or a situation where you exposed people to new kinds of information or experiences. What prompted you to make the change, and what was the outcome?

Régulateur et modèle

Probablement l’un des plus complexes de la liste, pas nécessairement dans la pratique, mais dans la compréhension. D’un point de vue systémique, il s’agit de comprendre que l’organisation de composants peut drastiquement changer un système, et avant tout de façon imprévisible. Si vous connaissez Cynefin, le mot « complexe » pour décrire la dynamique de système qu’implique cette "capability" est plutôt bien choisie. Aucun regroupement d’expert ne peut vous dire quelle est la solution en observant le système. Mais il reste possible d’expérimenter et d’observer et d’en tirer des conclusions a posteriori. Pour comprendre cela, il faut également savoir que chaque composant du système peut agir de façon différente, et particulièrement dans un système humain, chaque personne peut tenir des rôles officiels et des rôles implicites, parfois même inconscients pour ces mêmes personnes.

Un des rôles connus au sein des systèmes est celui de régulateur. D’un point de vue téléologique, finalité, le régulateur contribue à rectifier quelque chose, à garantir une stabilité du système. La soupape d’une cocotte remplie cette finalité. Quand la pression devient trop élevée, elle évacue pour que la cocotte n’explose pas. Votre chef également à cette fonction, dans le but de réguler les comportements qui permettent au système, l’équipe, l’entreprise, de fonctionner dans les bonnes conditions.
Cependant, ce qui n’apparaît probablement pas très clairement dans ces deux exemples, c’est que « pression trop élevée » comme « bonnes conditions » implique que cet élément régulateur « sait » quels sont les paramètres optimaux. Dans le cas de la soupape, c’est le designer qui a développé un modèle, basé sur les mathématiques et la physique selon des théories éprouvées, permettant de concevoir un régulateur qui réagira toujours de la même façon au même niveau de pression. Dans le cas du manager, son modèle mental est le fruit des interactions avec sa direction, son équipe, son contexte. Quand bien même on pourrait maximiser l’alignement des modèles mentaux de chaque manager, in fine, l’unicité de cette personne, de son expérience personnelle, font que son modèle mental est unique. Elle ne régule donc pas uniquement selon des règles explicites de son entreprise, mais aussi ses propres règles personnelles, conscientes ou pas, qui lui indiquent comment réagir. Et en l’exposant de cette façon, on peut bien imaginer qu’il n’est pas nécessaire d’être manager, rôle officiel de régulateur, pour l’être soi-même au sein d’une équipe. Chacun peut être régulateur selon les conditions, et… chacun a un modèle mental unique qui conditionne ses actions.
Ce qui conditionnera l’activation ou l’inhibition des compétences et actions de ces personnes dépendra alors de ce à quoi elles sont confrontées. Des problèmes techniques qu’elles connaissent ou non, des personnalités compatibles ou non, « je suis d’accord / je ne suis pas d’accord », des processus et interactions avec lesquelles elles ont familières ou non, tout ça la fois et d’autres causes également. Connaître ces paramètres a priori est impossible. Même si d’une situation à une autre, des comportements, événements, organisations se ressemblent, il faut se prémunir d’une conclusion trop hâtive. Face à un système complexe, il faut agir pour comprendre comment le système réagit dans son ensemble.

Approches de résolution de conflits

Dans cet exemple, une équipe de développement réalise un produit avec difficulté. Elle a de nombreux bugs et incohérences d'une fonctionnalité à une autre, et quand on regarde le code, il est très hétérogène. Un peu comme si plusieurs équipes avec différents standards avaient fait des changements sans aller au bout de leurs idées, ou sans en avoir eu l'occasion ou les moyens. Les développeurs étaient vus comme des personnes peu capables par la hiérarchie : certains étaient des experts, mais bossaient dans leur coin, et d'autres étaient plutôt moyens ou aux compétences peu reconnues, et il était dit qu'il fallait nécessairement repasser derrière ces derniers. La stratégie de la hiérarchie était jusque-là de changer les consultants par d'autres à l'issue de leur contrat en espérant améliorer la situation. Cependant, même si quelques recrutements ont pu apporter des modifications intéressantes, la qualité générale, elle, n'évoluait pas, et les mêmes catégorisations de bons ou mauvais développeurs avaient lieu.

Après avoir échoué avec tous ces renouvellements, la solution de la hiérarchie a été d'ajouter une personne, dans le but qu'elle enseigne une fois pour toutes les bonnes pratiques à l'équipe. Cependant, cette fois-ci, cette personne a préféré observer le système avant de commencer à lui infliger ses connaissances.

Ce qui lui a sauté aux yeux était la façon dont les développeurs se répartissaient le travail : jamais une seule fois ils ne se retrouvaient sur le même ordinateur pour s'occuper d'une fonctionnalité. Pas de mob programming, ni de pair programming, et très peu de revue de code synchrone. Pas même lorsqu'il s'agissait d'une nouvelle fonctionnalité qui aurait bénéficié de plusieurs cerveaux pour en poser les fondements. En regardant les commits des différents développeurs, il a également observé qu'ils avaient chacun des standards différents au sein de l'équipe. De tout ce qui était présent, il n'y avait pas de standard meilleur qu'un autre, mais leur hétérogénéité rendait la lecture de la base de code difficile. Par exemple, la manière d'appeler un service dans une partie du code était souvent différente dans une autre partie. Et, systématiquement, l'intervention d'un développeur dans une partie du code dont il n'avait pas été à l'origine donnait un résultat mixte de standards. Ainsi, lors du parcours du code, on pouvait être surpris d'une solution différente pour les mêmes types de problèmes. De même, lorsqu'un travail de design avait lieu, seul un, ou bien la même poignée de développeurs, faisait le travail, et les autres continuaient leurs tickets. En observant la qualité de leurs interactions, on pouvait voir de nombreux conflits, le plus souvent résolus soit par l'idée d'une personne qui avait une autorité reconnue, par exemple, le tech lead, soit par la décision seule de la personne qui devait implémenter l'idée, et en ignorant le résultat du débat.

Plutôt que de définir « la » bonne pratique pour chaque problème de la base de code, il a alors exposé le constat à l'équipe. Celle-ci a bien répondu que cela lui semblait juste, mais elle ne voyait pas quoi en faire. Pour tenter de faire émerger des standards d'équipe dans un cadre propice à ce type de décisions, il les a invités à faire du mob programming, une session de développement où toute l'équipe développe sur le même ordinateur, en prenant comme sujet de nouveaux domaines de l'application. L'équipe a accepté de suivre la méthode.
Au premier essai, la matinée a été épuisante pour tous. Les échanges très conflictuels étaient encore de mise durant la session, et quand bien même ils s'entendaient parfois sur des standards, tout était à discuter puisqu'aucun standard n'avait jamais été partagé jusque-là. Le conducteur du mob programming, la personne qui tenait l'unique clavier du groupe, n'hésitait pas à décider lui-même de ce qu'il allait écrire, faisant fi des avis des autres, et donc des règles de la session. Le nouvel arrivé, en posture de facilitateur, a tenu le cadre, parfois en les incitant à suivre les règles sans trop réfléchir, mais également en invitant chaque personne à rappeler à l'ordre ses coéquipiers, un type d'interaction qu'ils connaissaient déjà auparavant et ne se gênaient pas d'appliquer. Session après session, les membres devenaient autonomes sur la bonne exécution des règles du mob programming et, progressivement, les débats se sont trouvés confrontés à l'unique issue possible en suivant ces règles : des décisions partagées par l'équipe. C'est-à-dire que quel que soit le type de consensus, l'équipe était capable d'accepter le résultat d'un débat à partir du moment où tout le monde suivait le mode de décision. Par la répétition du geste durant chaque séance, l'équipe a fini par trouver sa fluidité dans ce mode d'interaction : le facilitateur n’intervenait plus. Dès la quatrième session, elle a même pu réaliser une journée entière de mob programming sans se fatiguer. Un des membres a même dit lors des sessions : « j'ai compris que ce n'était pas grave si ce n'était pas mon idée ». Par la suite, l'équipe réussissait même à réaliser des ateliers de design ensemble en parvenant à trouver des solutions avec beaucoup moins de frictions. Les conditions pour que des standards partagés émergent étaient désormais en place.

« Calque systémique »

Si on réduit le système à son état initial, chaque membre est porteur d'idées, de gestes, qui lui sont propres et applique ce qu'il sait à la base de code. Lorsque deux membres ou plus doivent échanger sur la même portion de code, le conflit débute, car leurs idées et leurs gestes sont incompatibles. De même, quand une personne modifie une portion de code qu'elle n'a pas créé ni modifié auparavant, elle est confrontée aux altérations d'une autre personne – altérations qui ne lui conviennent pas, parce qu'incompatibles avec ses idées et ses gestes – et donc modifie la base de code selon ses propres standards. Chacun se comporte comme un régulateur des standards de la base de code, mais personne ne partage les mêmes règles, donc pas le même modèle mental. Chaque régulateur va réprimer les actions non voulues, mais dans ce cas précis les actions de chaque membre sont régulées par chaque membre. Le système s’étouffe alors dans l’indécision, il change continuellement sa direction sans pouvoir converger vers un état cible.

Durant les premières séances, les membres avaient tendance à reproduire le schéma qu'ils pratiquaient d'ordinaire : chacun applique immédiatement une décision lorsqu’il a analysé un écart. Sans étape intermédiaire, chaque membre juge et agit sans tenir compte des autres, ce qui les empêche collectivement d'avancer puisque la base de code, le résultat de la succession de décisions, est partagée entre tous.

Le facilitateur régule alors lui-même de plusieurs façons :

il invite chaque membre à faire respecter les règles du mob programming
il interpelle les personnes qui prennent trop d'espace, et celles qui ne se sont pas ou se sont peu exprimées, et invite chaque membre à interpeler les autres
il met en avant et amplifie les avis et solutions des personnes les moins écoutées, pour en même temps confirmer le modèle mental de chacun auprès des autres membres du groupe, ce qui renforce la légitimité de chaque avis, et questionner les incohérences ou incompatibilités observées en demandant au groupe de choisir, ce qui finit par aligner le modèle mental de chacun

De nouveaux gestes et automatismes pour conduire un dialogue de groupe se mettent alors en place. Chaque voix doit avoir pu s'exprimer, ce qui permet de s'assurer que chaque personne est avec nous, mais également qu'on bénéficie du point de vue de chacun. Ainsi, chaque avis doit être étudié pour valider le modèle mental de chacun et trouver les points incompatibles. On exploite donc au maximum la variété des points de vue, ce qui augmente de fait la capacité totale de l’équipe à pouvoir répondre à des problèmes. Tout ce processus introduit alors une étape intermédiaire entre l’analyse d’un écart par l’un des membres et la décision qu’il prend : rechercher l’alignement avec les autres parties avant l’action.

Chaque membre du groupe reste alors régulateur, à la fois sur le comment discuter, et aussi sur le comment on a décidé de résoudre un type de problème. Mais il retarde l’action tant qu’il n’a pas trouvé de résolution aux écarts de règles avec les autres. Une fois ces automatismes ancrés, l'équipe a acquis la compétence de réconcilier le modèle du problème et de la solution entre ses membres. La solution coule alors de source, car le système converge vers un état compris et voulu par chacun.

Mais attends, c’est le fait d’ajouter une nouvelle personne qui débloque la situation là. Le management avait donc raison de suivre une logique d’ajout / retrait de personnes

Touché. Même si, on l’a vu, tester de nouveaux modes d’interactions n’était pas dans les intentions du management. J’ai présenté cet exemple parce qu’il illustre pour moi au mieux les effets de nouveaux modes d’interactions, et qu’il ne dépend pas nécessairement d’un changement de la composition d’équipe. Mais ici, il aura fallu un nouvel arrivé. Cependant, si personne au sein de l’équipe n’avait le recul, le modèle mental, la sensibilité pour guider le système dans la bonne direction, où pouvait se trouver la réponse ? Eh bien c'est très certainement pour ça qu'ont été conçues les questions qui suivent.

Questions d'interview

Il serait malhonnête de dire que la nouvelle personne avait analysé la situation avec autant de détails sur le moment et en calquant des concepts systémiques pour analyser le système. Cependant, ces concepts lui étant connus, elle a inévitablement été influencée dans sa manière d'analyser les évènements, d’analyser les membres et leurs interactions. Et à mesure que la situation avançait, le système et ses interactions sont devenus plus évidents.
La question « what prompted you to make the change » suppose alors d’avoir une analyse au moins partielle de la situation avant de déclencher de nouveaux modes d’interaction. On construit un modèle mental à partir de ce qu’on observe, même s’il est faux ou incomplet.
Mais elle est également suivie par « what was the outcome » qui suppose que l’effet peut avoir été inattendu. Comme l'illustre bien la modification progressive des interactions de l'équipe à travers la pratique du mob programming, les effets sont difficiles à déterminer à l'avance. Ils sont complexes et résultants de plusieurs cycles d'interactions et de correction entre chaque membre. De nombreux évènements auraient pu donner un résultat décevant :

Des membres de l’équipe auraient pu quitter la salle en colère dès les premières sessions
L’équipe aurait pu ne rien apprendre et partager si la présence de chacun avait été trop variable
Si le temps de transformation avait été trop lent, la direction aurait pu interrompre le processus pour exiger des résultats sur les pratiques mêmes

Encourager de nouveaux types d’interactions implique d'agir sur un système complexe, avec donc pour conséquence des résultats peu prédictibles. Cette capability implique d’agir par petites itérations et d’observer les effets pour réajuster. A contrario donc : méfiez-vous des managers trop prompts à appliquer de nouveaux modes d’interactions telles des recettes toutes faites, spécialement lorsque l'ensemble des changements à appliquer est trop conséquent. Et pour donner un exemple qui devrait vous parler : "on va utiliser le modèle de squads Spotify".

Liens du 5 avril 2024

Fri, 05 Apr 2024 00:00:00 GMT

Systems Thinking for Software Professionals - Diana Montalion - Explore DDD 2024, LLocalSearch, Anti-If, The missing patterns

Systems Thinking for Software Professionals - Diana Montalion - Explore DDD 2024

« We need a hierarchy to support mastery and knowledge flow […]. In a system the higher level is all about paraphrasing non system thinking language, making life good for the lower levels activities. It is about creating an ecosystem in which lower levels activities can scale and thrive, it is not about command and control. The best systems function without need for central executive control. […] And this would lead to patterns that create initiative driven development, meaning we understand what we need think to do, and think about, and care about, and then we can work together and inventing our own processes, or following tried and true processes to be able to do hard things together. And when that is happening, every day you work you increase your value, because you gain experience, you gain expertise, you’ve tested your critical thinking »

Une vidéo ! Tout à fait possible de la suivre sans l'image. J'en regarde peu, mais celle-ci donne un bon aperçu des travaux de Diana Montalion. Dans celle-ci plus spécifiquement, elle donne une bonne idée de l'impact des modèles mentaux sur les systèmes (socio et techniques).

Je suis Diana Montalion depuis seulement quelques mois. Je l'ai découverte par son bouquin "Learning Systems Thinking", que je n'ai pas terminé, et dont les premières pages m'ont mis une belle claque. J'ai également suivi un de ses workshops avec un collègue, orienté autour des effets de l'écriture sur notre façon de penser. Le workshop n'est pas nécessairement allé loin, mais donne à voir sur un autre bouquin et d'autres workshop à ce propos.

LLocalSearch

LLocalSearch is a completely locally running search aggregator using LLM Agents. The user can ask a question and the system will use a chain of LLMs to find the answer. The user can see the progress of the agents and the final answer. No OpenAI or Google API keys are needed.

😮

Un équivalent local de Perplexity.ai !

Anti-If: The missing patterns

Around 10 years ago I encountered the anti-if campaign and found it to be an absurd concept. How on earth would you make a useful program without using an if statement? Preposterous.

But then it gets you thinking. Do you remember that heavily nested code you had to understand last week? That kinda sucked right? If only there was a way to make it simpler.

The anti-if campaign site is sadly low on practical advice. This post intends to remedy that with a collection of patterns you can adopt when the need arises. But first let’s look at the problem that if statements pose.

Pas des tonnes de patterns dans cet article, mais suffisamment pour illustrer le contexte et inciter à se poser la question : y a-t-il un autre moyen de représenter des comportements alternatifs de mon application que par de fragiles if.

Guerre informationnelle, et nous dans tout ça

Wed, 17 Jul 2024 00:00:00 GMT

Vous n’en pouvez certainement déjà plus d’entendre parler de politique. La toxicité du milieu de l’information, que ce soit les journaux ou les réseaux sociaux, vous frappe ? Alors pour changer, on va parler de ce qu’il y a autour de la politique, pour comprendre pourquoi l’environnement actuel semble être de l’ordre du conflit, pourquoi les débats deviennent de moins en moins buvables, les opposés encore moins réconciliables, et en quoi la GenAI fera encore pire que de ne rien résoudre.

Lessons from the meme war in Ukraine

Underlying Lasswell’s work were two sets of insights. One is that the mass public played a key role in political outcomes, such as success and failure in war. Second, that those public attitudes could also be manipulated. Scaling to the mass-level, however, required simplicity. This included the use of symbols and slogans that were memorable, such that they could frame “pictures”—or, cognitive shortcuts—that the public recalled when engaging elected officials to shape certain policies.
[…]
First, memes are not used in isolation from a particular military operation on the battlefield, such as an offensive or counter-offensive. Rather, they are concurrent and complementary to these military efforts, suggesting that they are meant to play a supporting role. Second, memes do not seem intended to directly influence diplomacy, but may further diplomatic efforts indirectly by bolstering popular support for the war. Third, memes target a diverse array of audiences, including Ukrainian citizens, expatriate audiences abroad, and Russians, especially soldiers’ families. This suggests that those creating and posting memes assume that success is a function of both domestic resolve as well as foreign material support.
[…]
memes are meant not to replace hard power on the battlefield but instead to provide a psychological dividend to the successful application of hard power.

Un article intéressant sur l’usage des mèmes en temps de guerre, spécifiquement dans le contexte de la guerre russo-ukrainienne. La réflexion que je me fais en lisant le début de cet article c’est que, auparavant il fallait que la Russie déploie des efforts considérables pour influencer les opinions à l’échelle internationale (ça vaut son clic), et aujourd’hui des outils utilisables pour de la propagande de masse sont de plus en plus accessibles à n’importe qui et de moins en moins coûteux. Ça permet autant à un individu de créer un mouvement en peu de temps, qu’à un état d’en déstabiliser un autre sur le long terme. Un commodité qui, comme vous le verrez probablement dans certains liens de cette page, a également grandement bénéficié à la manipulation des/aux sphères complotistes.

La guerre informationnelle dopée à l'intelligence artificielle

OpenAI, le créateur de ChatGPT, avait indiqué fin mai que des groupes d'influence russes, chinois, iranien ainsi qu'une "entreprise commerciale en Israël" avaient utilisé ses programmes pour tenter de manipuler l'opinion d’autres pays.
Les contenus fabriqués traitaient d'une "large palette de sujets, notamment l'invasion de l'Ukraine par la Russie, le conflit à Gaza, les élections indiennes, la politique européenne et américaine ainsi que des critiques du gouvernement chinois par des dissidents".

S’il fallait trouver un autre défaut à l’avènement de la GenAI… mais sans être anti-progressite, je pense que ça démontre une nouvelle fois l’inadéquation de nos systèmes de sensibilisation et légifération. Je vais même aller plus loin, si nous avions été mieux équipés pour informer et réguler les usages de nouvelles technologies, nous aurions déjà depuis longtemps collectivement coupé les budgets de projets d’usages délirants de la GenAI (notamment à destination de systèmes déterministes) pour booster ceux où cette technologie aurait eu les impacts les plus efficaces et bénéfiques. Si vous voulez creuser plus, voici un thread de David Colon à propos d’un papier de Google sur en quoi certains usages de la GenAI aujourd’hui permet de « fausser la compréhension collective de la réalité sociopolitique ou du consensus scientifique ».

David Chavalarias. Minuit moins dix à l’horloge de Poutine: Analyse de réseaux des ingérences étrangères dans les élections législatives de 2024.

Nous avons donc là une stratégie de division globale du Kremlin sur long terme, visant à raviver les tensions communautaires en France. Le conflit israélo-palestinien est dans ce contexte une aubaine. Deux courants contraires sont amplifiés : le pathos des personnes préoccupées par le sort des Palestiniens et la montée
de l’islamophobie ; et le pathos de celles préoccupées par le sort des Israéliens et la montée de l’antisémitisme. Ces deux phénomènes sont bien réels mais leur perception est amplifiée par des actions sur les terrains numériques pour pousser chaque camp –ainsi que l’extrême-droite raciste et antisémite–
à sur-réagir. Ceci provoque un phénomène d’auto-renforcement qui rend ces montées incontrôlables. Pour visualiser ces ‘courants’, nous avons analysé le discours sur l’antisémitisme et Israël et identifié les comptes de la twittosphère politique les plus touchés par cette problématique. Il est par ailleurs possible de calculer
la sphère d’influence de @FRN, c’est à dire les comptes les plus susceptibles d’avoir été exposés à ses vidéos.
En théorie, rien n’interdit que ces deux sphères puissent se recouvrir. On peut tout à fait être préoccupé par les horreurs commises par le Hamas et le Gouvernement de Natanyaou au Proche- Orient et par la montée de l’antisémitisme et d’attitudes hostiles envers l’Islam en France. En pratique il n’y a presque aucun recouvrement

Un article du CNRS, plus précisément de l’institut dès systèmes complexes, qui expose une analyse de la division de groupes politiques dans le temps sur le réseau X. Le ton n’est pas fou, mais les données, analyses du macroscope et autres faits exposés comblent en partie les causes des divisions toujours plus marquées entre les idéologies portées par les différents partis politiques, et aussi de l’influence de l’astroturfing sur la campagne des législatives.
Si cela vous intéresse, il a été partagé durant une commission d’enquête du Sénat sur les influences étrangères, en présence d’autres spécialistes venant témoigner de ces pratiques qui ont déjà été mises en évidence depuis 2013 par l’auteur du papier. Une des mesures proposées est de rendre possible l’audition des plateformes par des instances indépendantes, une mesure d’autant plus critique que l’on sait que les mécanismes de promotion de contenus sont parfois politiquement orientés, et même asymétriques entre pays comme décrit dans cet article de Public Sénat : TikTok : les stratégies d’influence de la Chine sont « de plus en plus sophistiquées », selon le chercheur Paul Charon.

Bonus : alors que fait-on lorsqu’on utilise ces réseaux ?

Cette partie vous concerne surtout si vous utilisez de tels outils, et si cela vous affecte de près ou de loin. S’il fallait faire un récap de ce en quoi cela nous concerne, la guerre informationnelle nous touche : soit indirectement parce que les zones virtuelles ne distinguent pas ou peu nos localisations géographiques, soit directement parce que nous faisons partie des populations cibles.

Sur certaines plateformes de partage de contenus, les techniques de base de cette guerre consistent à créer du contenu suscitant suffisamment de réactions (ou faire en sorte que d’autres victimes s’approprient le message sous-jacent) pour qu’il soit visible dans les fils d’actualité des plateformes, et affaiblisse ou renforce les opinions des populations ciblées, ou de créer du contenu de façon à amplifier les opinions d’un groupe particulier afin d’augmenter la scission au sein de sociétés.

En quelques sortes, toute plateforme affichant un flux de contenus collaboratifs favorisant les contenus qui provoqueraient le plus de réactions sont des zones propices à la guerre informationnelle. Ces plateformes, pour certaines neutres vis à vis des forces qui s’affrontent, tirent néanmoins le bénéfice des interactions suscitées par ces contenus. On est donc plus proche du mutualisme, des interactions bénéfiques pour les attaquants et les plateformes, que du commensalisme, des interactions bénéfiques que pour l’une des deux parties. La conséquence est simple, les plateformes ne sont très peu mobilisées dans la résolution des dangers auxquels elle exposent les états, que ce soit sous couvert de secret d’affaires, liberté d’expression ou de prétendue neutralité.
S’il fallait donner des exemples de plateformes de ce type : 9gag, Facebook, LinkedIn, Reddit, TikTok, X, YouTube.

Les contenus de ces plateformes finissent par nous avoir à l’usure. Pas nécessairement en nous convaincant des messages promus ou en nous opposant au reste du monde, mais parfois aussi en nous plongeant dans la négativité ou en développant notre fatigue.

Le moyen le plus radical pour sortir de ces zones de conflit qui augmente la division et le mal-être de nos sociétés est tout simplement de les quitter. Si vous y étiez pour vos familles, créez des groupes dans des messageries instantanées. Si vous y étiez pour du contenu spécifique, agrégez les flux RSS des sources de ces contenus (blogs, news, …).

Mais si vous ne pouvez trouver tout cela en dehors de ces plateformes (certains groupes familiaux étendus ne peuvent être atteints autrement), quittez les flux générés, et ne suivez plus que les sources auxquelles vous êtes abonnés. Vous remarquerez cependant que malgré cela, certains contenus toxiques vous parviendront car vos sources elles-mêmes n’ont pas cette hygiène, et subissent et réagissent à ces contenus. Autant que possible alors, utilisez les filtres de mots clés ou d’utilisateurs que ces plateformes vous proposent pour masquer le éléments potentiellement toxiques, et mettez les à jour régulièrement.

Et pour ce qui est de la désinformation, en cas de doute, n’hésitez pas à consulter, voire même à vous abonner, à des sources de fact-checking tels que Factuel de l’AFP ou les revues de presse de ConspiracyWatch (je vous recommande au passage leur cartographie des sites français relayant tout type de désinformation). Vous vous préserverez alors vous-même, mais vous préserverez aussi votre entourage lorsqu’il vous fera part de fake news que vous auriez pu identifier sur ces sites.

Liens Glue work et sérendipité

Wed, 25 Sep 2024 00:00:00 GMT

Long time no see uh ?

Pour ce coup, je vous partage des éléments de veille qui m’ont fait réfléchir et m’aide à comprendre ma position dans la boite, typiquement sur des activités du type glue work. Si jamais vous avez de la matière sur le sujet, je prends !
Les deux autres liens sont probablement le début d’un article que je rédigerai sur la façon dont je trouve mes liens, non pas que je pense que la méthode soit efficiente, mais je pense qu’elle tente de contrebalancer des modèles mentaux que pourrait m’imposer le système. Et je serais curieux de savoir si ces liens et sujets partagés ont une ou des caractéristiques que vous retrouveriez ou non ailleurs.

Glue Work in Design

The first thing I learnt from my interviews is the understanding of two categories of glue work; “task-oriented” glue work and “relationship-oriented” glue work. While these were identified while speaking to design leads and designers, they can also be applied widely to any team in other industries.

[…]

When both categories of glue work are handled consistently and professionally, it results in a better, more efficient, and more enjoyable workplace. From my interviews and desk research, I have observed how glue work can:

Prevent teams from making the same mistakes

Quicken work flows

Reduce friction in teams

Reduce burnouts for individuals

Retain team members

Promote a collaborative environment rather than competitive

Cultivate psychological safety at work

Parmi les articles que j’ai pu trouver sur le glue work, c’est jusque là le seul qui ne parle pas que d’un point de vue personnel et qui tente une analyse structurée à partir d’une recherche.La catégorisation est intéressante, et le détail d’exemples de ces activités aussi, notamment pour mieux répondre à ces sujets par des compétences spécifiques. Par exemple si un coup de collier est à mettre sur la catégorie relationnelle, je pense que la séniorité est un atout à la fois pour savoir identifier les trous orga, dans le mode de fonctionnement de l’entreprise, connaître les bonnes personnes pour faire les ponts les plus impactant, et savoir gérer les conflits.
C’est aussi l’un des rares articles qui parle d’analyser le glue work pour systématiser des réponses et améliorer durablement le milieu.
Personnellement je me retrouve à gérer les deux catégories, et je me suis donné comme objectif d’améliorer le système à travers ce rôle et la perspective que ça me donne. La tâche est complexe et m’a convaincu que le glue work n’est pas un type d’activité qu’on devrait déléguer à des employés qui n’ont pas encore assez d’expérience. D’une part parce que cela ne permet pas ou peu le développement de la légitimité de compétences de la personne (déjà acquise ou presque par quelqu’un d'expérimenté), mais aussi parce que cette expérience permet de comprendre ce dont une entreprise a besoin et ce qu’il est possible d’y faire pour ne pas se retrouver noyé dans l’input d’activité sans réfléchir (on est vraiment pas loin de la notion de toil et de la façon de l’adresser).

TMB 42/52: The Integrator Burden

I invested an incredible amount of time in trying to help everyone involved. After work chats. Walks. Helping with retrospectives. Coaching people 1:1. Smoothing things over. And yes, I burned out. On reflection, part of the challenge is that I didn't recognize how atypical my role was! I assumed that everyone must see these things. And that if they did nothing, it was pure negligence. What I realize now is that my perspective was UNIQUE. I was connecting dots others were not connecting. And that came at a steep cost.

Un des articles qui alimentent ma réflexion sur mon rôle actuel. Je sens que je comble des gaps, et plus précisément un système bureaucratique encore récemment sorti d'une réorganisation, donc avec plein de processus et autres modalités d'interactions non définies. Ce que je n'avais pas explicitement en tête, bien que le sentais et ce qui m'a poussé à sortir de la donnée pour confirmer/infirmer nos modèles mentaux, c'est que je créé aussi des ponts de communication entre différents échelons (ou ceux en charge de la gouvernance vs ceux en charge de l’opérationnel, une séparation déjà étrange en soit). D'une part j'écoute et comprend les gens sur le terrain qui eux me font confiance, ce qui me permet de remonter des feedbacks parfois inaudible car pas regroupés, ou bloqués par peur (ou encore autre raisons). Et d'autre part, dans l'autre sens, j'écoute et comprend la direction qui me fait également confiance, ce qui me permet de mieux expliquer ou traduire leurs décisions pour les gens du terrain qui n'ont pas la possibilité de baigner aussi longtemps et profondément dans la gestion interne (iels sont essentiellement en mission). Je ne l'ai que récemment conscientisé, même si je faisais ce pont déjà avant, ce qui fait que récemment j'investis plus de temps à rétablir la communication. Une forme de béquille, mais nécessaire pour le démarrage (surtout suite à des big bang comme des reorg) car tant que les gens ne se comprennent pas et pensent être opposés ou "désalignés", ils n'iront pas se chercher les uns et les autres (du moins dans l'écoute). J'espère rétablir assez d'empathie et d'écoute pour rétablir les canaux qui permettront à la machine de fonctionner.

Take a random walk

There’s this phenomenon that you might have heard people advise you to exploit: when presented with a choice, if you are really unsure which option to take, convince yourself to put it up to chance. After feeling like you are locked in to that future, you’ll usually find out which option you are more comfortable with.

[…]

Psychogeography is the exploration of urban environments that emphasizes interpersonal connections to places and arbitrary routes. It was developed by members of the Letterist International and Situationist International, which were revolutionary groups influenced by Marxist and anarchist theory as well as the attitudes and methods of Dadaists and Surrealists. (Wikipedia)

The dérive is one of the main Situationist practices, a method of drifting through space to explore how the city is constructed, as well as how it makes us feel. Guy Debord defined the dérive as “a mode of experimental behavior linked to the conditions of urban society: a technique of rapid passage through varied ambiances.”

As the dérive’s goals include “studying the terrain of the city, and emotional disorientation”, it seems like letting chance decide where to go next could help one to move towards those goals.

Un article plutôt bien pour explorer des curiosités, donner des idées, ou simplement décrocher de ce qui vous occupe la tête.
On est pas loin de la pratique qui me permet de tomber sur les liens que je partage, dont celui-ci !
Il m’est arrivé de faire une chose similaire pendant mes entraînements de course à pied, mais sans dé, plutôt en choisissant n’importe quel autre chemin que celui qui m’attire le plus, et en notant la moitié du temps ou distance de course pour revenir en arrière. Très pratique pour découvrir une ville. J’ai également déjà fait ça lors de quelques marches nocturnes, ce qui m’a valu une histoire de course poursuite que vous connaissez peut-être déjà ^^’

Folk search engines

Finally, in order to be seen at all, good actors bend over backwards to cater to the algorithms, too. Participate or perish. Authenticity becomes not only silenced, but perverted.

The resulting product, despite its good intentions, is a search engine that surfaces websites that were written to be optimized for a search engine. You are not the audience; the algorithm is.

We don’t need a better large search engine. Instead, we need to cultivate what I would call “folk search algorithms,” a set of tools and practices that, whether by chance or design, are not influential enough to move markets

Un article qui parle brièvement de l’effet standardisant / nivellant des algos de moteurs de recherches populaires. Mais qui parle aussi de technique pour améliorer la sérendipité. J’utilise certains de ces moteurs alternatifs et techniques de recherche, et couplées à des principes comme dans le lien Take a random walk je tombe sur des choses étranges qui font voyager, qui me sortent de la bulle corpo et m’alimente des nutriments nécessaires à la créativité et à entretenir un minimum un modèle mental du monde plus complet que celui de l’élite étouffée par son propre conformisme corpo.

Liens en vrac - Curation, grep, tests et Toyota

Fri, 25 Oct 2024 00:00:00 GMT

Creation and Curation; Greppability is an underrated code metric; How to Fix a Bug, Tests, Hypotheses, Timeboxes; What Really Makes Toyota’s Production System Resilient

Creation and Curation

Who knows, maybe with a digital world filled with low-quality garbage we’ll find refuge in old-school printed magazines.

Ça parle bien sûr de GenAI. Longue vie à la curation !

Greppability is an underrated code metric

It turns out that splitting up, or dynamically constructing identifiers is a bad idea

Un court article. Aucune citation particulière, tout se trouve dans les titres intermédiaires. Ce n'est pas que l'article est particulièrement éclairant, mais "chaines" à rendre "greppable" peut servir d'aide mémoire. J'ai souvent beaucoup bénéficié d'un nommage homogène et explicite pour des audits de code. Mais, sur ma dernière mission, j'ai eu d'autant plus besoin de telles caractéristiques pour faire émerger un schéma d'architecture d'un ensemble de 50 microservices (chacun dans son repository git). Parce que certaines chaines étaient répétées avec la même structure, j'ai pu faire émerger un fichier au format c4 model qui m'a généré le schéma en question (et m'a de fait réaliser qu'on était dans une belle galère).

Seul point de l'article qui m'hérisse les poils :

You’re better off biting the bullet and returning the object directly

Comment casser un découplage utile. C'est une bonne façon de se faire très mal sur la durée.

How to Fix a Bug: Tests, Hypotheses, Timeboxes

“There is never enough time to do it right, but there is always enough time to do it over.”

— John W. Bergman

That said, I find that for complicated bugs, this process avoids a lot of diving into the wrong rabbit holes, chasing wild geese, doggedly unnecessarily rewriting entire chunks of code with your head in the sand. Instead of these animal metaphors, you can be rational about bugs. The group mind identifies better hypotheses; priorities and timeboxes avoid getting into a flow state for the wrong hypothesis.

Démarrer par un test je l'avais, mais pas tout le process qui suit. L'idée de faire échouer à la CI par un test, je dirais que ça dépend aussi de la criticité : si le bug provoque un incident en prod, alors peut être qu'on voudrait explicitement arrêter d'empiler du code, arrêter le flux de production, le temps de résoudre le problème ? Ça m'a fait penser aux chaines de production Toyota, qu'on arrête quand il y a un problème dans la production, et où l'amont, l'aval et d'autres services peuvent rejoindre le groupe pour aider à apprendre et résoudre le problème.

What Really Makes Toyota’s Production System Resilient

The Toyota Production System is an organizational culture as much as it is a factory operating system. Its core philosophy — to motivate and develop people so that they can surface and solve problems quickly and build a culture of continuous improvement — obviously extends beyond the company’s own walls to include its suppliers.

Ce que je retiens : Le système socio-technique (gens, software, hardware d'usine) n'est pas seulement conçu pour un résultat de production, mais aussi et peut-être surtout pour l'apprentissage à atteindre de meilleurs résultats de production.

Les modèles d’organisation produisent nos modèles culturels

Wed, 11 Dec 2024 00:00:00 GMT

“We shape our buildings and afterward our buildings shape us,” said Mr. Churchill, addressing Parliament on the subject of plans for rebuilding the bombed-out House of Commons. He had a lot of good reasons for wanting to keep the British legislature just as it used to be—a rectangular chamber instead of a semicircular one, so that the dividing line between Liberal and Conservative could be marked by an aisle a man would think twice before crossing…

– The New Yorker, novembre 1943

On dit « Culture is everything », ou qu’elle précéde tout. Cet énoncé hiérarchisant, linearisant, peut nous aveugler sur ce qui produit la culture. J’ai déjà vu de nombreuses structures où les gens de bonne intention ce sont affrontés parce que la structure les a forcés dans des modèles d’interactions. Changer les gestes n’y suffit donc pas.
Notre organisation et les processus qui régissent nos interactions sont également des causes de l’apparition de dysfonctionnements, de blâme, de créativité.

Dans cet article les raisons pour lesquelles ces structures sont mises en place ne seront pas abordées, car elles sont variées et souvent indépendantes du résultat de ces structures. On peut simplement garder en tête que l’enfer est pavé de bonnes intentions.

Culture Pathologique

La classique tour d’ivoire, traditionnellement attribuée aux architectes mais qui peut être généralisée à n’importe quelle spécialité, voire personne, est une structure orientée pouvoir. À plus petite échelle, quand un tech lead prend la main sur la résolution des problèmes, les fusions de code, le design de nouvelles parties du code, on peut dire de la culture de l’équipe qu’elle est orientée pouvoir.

La structure orientee pouvoir centralise la responsabilité, mais aussi l’activité du design, privant ainsi cette structure de points de vue différents, et privant le reste de l’organisation de l’apprentissage qui rendrait à long terme son intervention plus pertinente.
Une tour d’ivoire ne pourra transmettre qu’un modèle incomplet, et pourra difficilement éviter la perte due à la traduction de ses intentions lors de la réalisation. Le système résultant sera incompris lors de sa réalisation, frustrant à réaliser, et opposera les gens le subissant entre eux mais opposera aussi ces mêmes personnes et la tour d’ivoire. L’apprentissage pour les exécutants n’aura pas lieu, car l’écart entre les modèles mentaux à l’origine du design et la réalité sera inconcevable. Il leur manquera le point de départ. Il ne pourront que constater qu’ils n’arrivent pas à destination.

La structure de pouvoir, elle-même aveugle sur les écarts entre les concepts et l'implementation, jugera que les exécutants n'ont pas les compétences pour réaliser le plan, et renforcera la déresponsabilisation, et ce qui aura pour conséquence future d'augmenter la place du blâme : les architectes qui prennent des décisions hors sol, les exécutants incapables.

Culture Bureaucratique

La séparation des responsabilités entre Devs et Ops, Métiers et Tech, UI et Dev, etc, prévient la possibilité de la partie de droite de mettre à l’épreuve la partie de gauche, et inversement. C’est une structure orientée bureautie, « chacun son métier et les vaches seront bien gardées », une forme de distribution du pouvoir, rationalisée, où chacun possède son pré carré, et où les responsabilités et l’intégration entre les parties sont prédéfinies.

La communication, sa quantité et sa qualité, est elle-même prédéfinie et structurée de façon à ce qu’une expertise « passe le relais à une autre ».
Quand bien même chaque partie peut apprendre à mieux opérer dans son domaine, l’intégration entre les parties n’a aucune souplesse. Chaque groupe d’une même responsabilité a le pouvoir d’optimiser localement, mais le tout est condamné à s’organiser systématiquement de la même façon. Le système social est prédisposé à reproduire son modèle d’intégration sur le système technique.

Ne voyant pas ce qu’il se passe au delà de son pré carré, chaque partie pourra reprocher à l’autre de lui imposer des contraintes qui gênent leur travail. Les commerciaux qui bouleversent notre planning, le métier qui ne comprend pas ce qui est réalisable, les devs qui se fichent de ce qu’ils livrent en production, les ops qui nous empêchent de … La structure de communication ne permet pas la production d’un tout dont l’intégration entre les parties est optimisée de façon globale, et prévient aussi de fait toute émergence différentiante.
La réaction de chaque partie sera alors d'augmenter le coût de la communication avec les structures amont en imposant des prérequis, et de réduire le coût de communication aval pour réduire l'énergie nécessaire à réaliser leurs tâches, ou en imposant un contrôle de la suite des opérations. Les processus gagnent alors en friction, et augmente leq difficultés à agir, ce qui aura pour conséquence de renforcer les mesures de contrôles, les mesures préventives et les prérequis à la collaboration, renforçant la culture bureaucratique.

Si vous avez déjà entendu du Beer Game, évoqué notamment dans la Cinquième Discipline, c’est typiquement ce qu’il s’y produit entre le producteur, le grossiste et le vendeur.

Culture Générative

La co-construction de l’ensemble des concepts par un ensemble des représentants de « la chaîne de valeur » est une structure générative. Le résultat d’une telle co-construction est un alignement sur le langage, donc peu de perte de traduction, mais aussi un alignement le problème à résoudre, et sur les effets connus que les composants de la solution auront les uns sur les autres, donc une meilleure intégration. Elle est générative au sens où elle permet des émergences, c’est à dire des propriétés du système qui ne peuvent se manifester, exister, que part l’interaction entre certaines de ses parties.

Par exemple : la capacité d’un système à livrer un tout cohérent à tout moment, et satisfaisant pour l’ensemble de ses intervenants, résulte d’une coordination juste entre ces derniers, pas d’un effort démesuré d’un sous-groupe à se plier aux contraintes définies par un autre sous-groupe. C’est le résultat d’allers-retours pour ajuster une trajectoire, d’une négociation entre les contraintes pour qu’elles produisent un effet fonctionnel, et donc d’une quantité et qualité de communication adaptée et continuellement ajustée au besoin. Au vu de l’intensité de la communication entre les parties, la définition du périmètre sur lequel la structure agit sera une des clés pour qu’elle ne s’effondre pas sous l’information.

À la fin, la qualité du système dépend de la culture qui l’aura produite, qui elle-même dépend de la structure qui la nourrit.

"We get brilliant results from average people managing brilliant processes - while our competitors get average or worse results from brilliant people managing broken processes"

– Fujio Cho

Chrononutrition, acidité, hydratation et sommeil

Sun, 05 Oct 2025 00:00:00 GMT

Après avoir beaucoup trainé, voici enfin l'article.

TL;DR

Avec ce qui suit, j'ai résolu : surpoids, sensibilité aux maladies courantes, fatigue générale, douleurs articulaires, sécheresse de peau, stabilité émotionnelle, fatigue post-repas. J'ai commencé tout ça en février 2025, et je crois me rappeler avoir atteint mon poids cible en 2 mois (86 -> 78), les symptômes que j'ai cité ont dû disparaitre en quelques jours, et je ne suis plus jamais tombé malade depuis, même pas un rhume, et j'ai pourtant serré des pinces et fait la bise à des gens pas en forme.

Le « programme » :

Matin (moyen) : protéines et féculents le matin
Midi (beaucoup) : protéines et féculents le midi
16h (peu) : oléagineux, fruits et/ou peu de sucre
Soir (peu voire pas) : protéines et/ou légumes, peu voire pas de féculents

Vous pouvez vous écarter de ces recommandations jusqu'à 2 repas par semaine.

Par exemple :
Matin : 3 tranches de pain complet + beurre + fromage, 1 bonne poignée noix de cajou, 1 bonne poignée d’amandes
Midi : pommes de terre / pâtes (bonne dose), viande/poisson/autre source de protéines, poêlée de légumes, pas de dessert
16h : 30g noix de cajou, 30g d’amandes
Soir : omelette de légumes et/ou champignons et noix de muscade (2 oeufs max)

Equilibrez l'acidité de vos repas avec des aliments alcalinisants. Les légumes verts ça marche bien, les fruits à coque aussi.
Hydratez vous à hauteur de ~30 x votre poids, pas moins (ex: 30*80 = 2400mL).
Pas d'écran dans les 20min qui précèdent le sommeil, et dormez à rythme régulier, entre 7 et 8h par jour.

Si vous avez le temps pour quelques explications

Fonctionnement de la chrononutrition

Le corps s'est formé à travers le temps sur la base de cycles jours/nuits. Les cycles circadiens sont bien connus à ce propos. Votre métabolisme est conçu pour être aussi bien rythmé qu'une horloge (ce n'est pas réellement que le corps est équipé d'horloge mais que ces cycles métaboliques en sont eux-même). Si vous n'avez pas d'heure de sommeil, ou de repas réguliers, votre corps devra constamment gérer des déséquilibres, une forme de stress qui l'incitera à vous protéger, notamment par plus de stockage d'énergie, et des moments d'endormissement/engourdissement peu adaptés à votre rythme de vie.

La chrononutrition est le fruit d'un bon nombre d'études de cycles métaboliques parvenant au constat que les repas doivent être pris régulièrement, aux mêmes heures d'un jour à l'autre, et en consommant les bons aliments au bon moment.
Par exemple, il a été trouvé que le corps régulait mieux ses pics glycémiques durant la journée si l'apport principal de protéines avait lieu au petit-déjeuner et au déjeuner. Il sera en revanche bien trop sollicité en cas de consommation de glucides complexes le soir, l’incitant à continuer le stockage d’énergie au moment où il devrait en relâcher pour, certes, maintenir vos fonctions vitales, mais aussi déclencher des processus métaboliques réparateurs et de croissance lors du sommeil.

Glucides, Gras et insuline

Chose à savoir et qui n’est pas propre à la chrononutrition, l’absorption de sucre ou aliments à indice glycémique élevé augmente la quantité de glucose dans le sang, ce qui déclenche la production d’insuline, et l’insuline commande le stockage de ce glucose. Si vous mangez beaucoup de glucide et/ou du gras au moment où le taux d’insuline est élevé, alors vous stockerez ! Donc règle simple : évitez un maximum de manger sucré quand vous mangez du gras et/ou des glucides en quantités.
Avec la chrononutrition, si vous voulez du sucre ou d'autres aliments à indice glycémique élevé, c’est sur un créneau réservé, le goûter. Si vous respectez bien les consignes sur les deux premiers repas, c'est le moment de la journée où le corps gèrera au mieux une forte glycémie.

Pour rappel, le riz blanc, le pain blanc et tout type de céréales raffinées ont un indice glycémique élevé, c’est à dire un potentiel de faire sécréter de l’insuline. Pour manger des féculents sans trop en subir les conséquences, préférez des céréales complètes (riz complet, pain complet, etc), plus complexes, qui ont donc un indice glycémique bas. Sachez aussi que l'indice glycémique augmente avec l'intensité de la cuisson.

En gérant bien le sucre et les principes de chrononutrition, vous serez rassasiés dès le matin, et entretenant de façon dégressive l’énergie nécessaire au corps pour la journée (La collation de 16h doit être respectée). Et gérant les aliment et leur indice glycémique, plus de poids sur le ventre et plus de fatigue après les repas (ciao la chute de la glycémie), et plus de fringale à l’approche des repas (qui vous feront manger en dehors de vos heures, et souvent n'importe comment).

Équilibre acido-basique

Notre alimentation est très souvent trop acidifiante. Le déséquilibre vers l’acidité a, à terme, des conséquences inflammatoires sur le corps : douleurs articulaires, dégradation de la vue, calculs réneaux, troubles divers de la digestion, stress (lui même ayant une action acidifiante sur le corps), troubles du sommeil, etc. Couplée à une faible hydratation, les effets sont démultipliés.
Peu importe que les aliments soient acides ou alcalins à l’origine, la réaction métabolique, c'est à dire le produit final de la digestion, acidifiante ou alcalinisante en est indépendante.
On va donc surtout faire attention à l’acidification. Pour ce faire, on peut se référer à plusieurs sites sur le net qui fournissent des tableaux ou des pages plus complètes.
Attention au conseil généralement donné d’équilibrer avec des légumes, ils ne sont pas tous alcalinisants : les légumes farineux comme les poix sont acidifiants, les légumes verts sont souvent très alcalinisants, la tomate cuite est acidifiante, etc.
Indice : si vous ressentez de l’acidité gastrique dans les 2h suivant un repas, c’est qu’il était probablement trop acide. Vous pourriez diminuer la quantité d’aliments acidifiants, ou aussi ajouter des aliments alcalinisants. C’est la raison pour laquelle, le matin, je prends des noix de cajou et amandes (alcalinisants) avec le fromage et le pain (acidifiants).

Hydratation

La déshydration à long terme vous causera des troubles similaire à l'acidification : douleurs articulaires, troubles de la vue, des maux de têtes fréquents, des sécheresses diverses (peau, cheveux, yeux...), des calculs réneaux, etc.
La consigne des 1,5 litres est un minimum. J'en suis personnellement à plus de 2 litres d'eau par jour. Vous pouvez calculer votre cible en multipliant votre poids par 30, ce qui donnera le nombre de millilitres. Si vous préférez une façon plus précise de déterminer l'hydratation nécessaire, suivez ce calcul. Et comme l'indique le lien précédent, si vous faites du sport, un demi-litre supplémentaire sera nécessaire.
Tout type de boisson convient, même s'il faut prendre en compte les autre effets de leurs composants (ex: l'eau gazeuse est acidifiante).
Indice : l'urine doit être réellement très peu colorée (cf palette de couleur).
Astuce : si vous êtes chez vous et que vous bougez peu, utilisez votre plus grosse carafe à côté de votre bureau. Estimez quelle part de votre hydratation elle comble (pesez la vide, puis remplie, rappel 1kg d'eau = 1litre d'eau), et buvez autant de carafes que nécessaire dans la journée. Au travail, même estimation pour votre gourde.
Vous remarquerez que l'astuce de la grosse carafe vous fera tout de même bouger. Quand on a jamais bu autant par jour, il est normal d'aller vous soulager aussi fréquement. Curieusement, j'ai remarqué qu'avec les mêmes quantités dans la durée, je n'avais pas autant besoin de me lever par la suite.

Sommeil

Je crois qu'on vous a aussi souvent rabâché l'intérêt d'un bon sommeil, à heures régulières. Je rappelle alors quelques détails. Il aide aussi à réguler tout un ensemble de votre métabolisme, et donc également la qualité de votre digestion, de votre production d'insuline, etc. Il va aussi aider à réguler votre système immunitaire qui, dans le cas contraire va favoriser des inflammations avec toutes les conséquences que j'ai cité précédement.

Mini-système, "Success to the successful"

Tue, 21 Oct 2025 00:00:00 GMT

Ou comme dirait une collègue « La loose entraine la loose, et la gagne entraine la gagne ».
Cet article fait partie d'une série introduite par ici.

Success to the successful.

Qu'est-ce ?

Très simplement, un tel système repose sur une ressource limitée, permettant à ses individus (ou éléments) de renforcer leur capacité à capter la même ressource. Donc, plus vous captez de ressources (relativement à quelqu’un d’autre), plus vous serez capables d’en capter. En conséquence, elle devient moins disponible pour d'autres, qui deviendront alors moins capables de capter cette ressource.

Comment repérer ce système

Déséquilibre d'activité / résultats entre équipes : par exemple, imaginez que des équipes de recherche dépendent d'une équipe de communication pour publier leurs recherches. L'équipe de communication a une capacité limitée. Si cette équipe n'est sollicitée qu'à l'initiative des équipes de recherche, alors plus une équipe publiera, plus elle sera efficace et efficiente dans son cycle de recherche et publication. Elle accèdera alors plus fréquemment à la capacité de l'équipe de communication, augmentant les chances que cette équipe ne soit pas disponible pour d'autres.
Injustice : par exemple, année après année, les mêmes personnes sont récompensées pour leur travail, tandis que d'autres se sentent lésées.
Single point of failure / rôle = personne : quand une compétence ou connaissance devient l'exclusivité d'une personne.

Sur papier

Ce type de système vous évoque-t-il une situation à laquelle vous êtes confronté ?
Si oui, je vous suggère de saisir un crayon et de reprendre l’illustration en replaçant les labels génériques par ceux de la situation à laquelle vous pensez.

Exemples

Dans un système social, on peut naturellement penser aux ressources financières et patrimoniales. Mais il existe des exemples moins palpables et pourtant répandus. Par exemple, si les occasions de développer ses compétences sont limitées, et que l’occasion se saisit plus facilement à mesure que l’on devient compétent, alors ces occasions, qui sont la ressource, deviendront moins accessibles pour d’autres personnes, qui développeront alors encore moins leurs compétences.

Échappatoires

Si l’équité est un résultat souhaitable, alors seule une forme de régulation dans ce système peut permettre d’enrayer la machine. Une façon directe pourrait être d’introduire une règle d’éligibilité d’accès à la ressource, dépendante par exemple de l'historique des accès. Exemple, plus une personne utilise une ressource, moins elle est prioritaire pour la mobiliser.

Une autre, plus soft, mais pas impossible, est d’incarner cette régulation dans les comportements, jusqu’à la culture. Si les leaders montrent l’exemple, ils peuvent entraîner le comportement du reste des agents du système, ce qui leur donnera également la légitimité de corriger les comportements inadéquats en explicitant aussi simplement un « on ne fait pas comme ça ici ».

Sur papier

Si vous imaginez une solution potentielle à la situation que vous avez dessiné plus haut, tentez de la dessiner. Le système au global produit-il les résultats souhaités ? Imaginez que les effets des flèches produisent leur contraire, que se passe-t-il ?

Références

Ce système est cité dans « la cinquième discipline » de Peter Senge, et « Thinking in systems » de Donella Meadows.

Mini-systèmes, une introduction

Wed, 22 Oct 2025 00:00:00 GMT

Hier, vous avez reçu un article (cassé par mail, sorry) qui a dû vous sembler étrange, voire incompréhensible, merci pour le feedback ! Il était court, sans contexte, avec une structure, mais probablement décousu sans préambule. Pour remédier à cela, voici un court article chapeau pour vous permettre de ne pas louper trop de marches.

J'aimerais vous parler d'un thème, d'un outil, qui m'est cher : la systémie. Grâce à cela, j'ai pu comprendre à la fois des problèmes courants dans mon quotidien, des suites d'évènements dans le contexte mondial, d'anticiper des situations à toute échelle, et surtout de trouver ma place et mes moyens d'actions dans tout ça. Au final, je pense que de tout ce que j'ai appris, c'est le domaine le plus versatile, et qui me donne le plus de perspective sur ce qui m'entoure. En somme, je comprends mieux où je mets (ou mettrai) les pieds, j'y gagne en patience et en compréhension, voire compassion, et je sais adapter mes actes à la bonne vitesse et niveau pour qu'ils aient de l'impact. Ça doit encore vous sembler cryptique, mais globalement je peux dire que c'est du relativisme pragmatique, un bon remède au cynisme, et un bon guide pour doser mon influence sur tout type de situation sans m'épuiser, ni patauger.

Si vous n'avez jamais abordé la systémie, ce discours doit ressembler à ce que pourrait vous dire l'archétype du charlatan. La réalité est que le parcours permettant de se l'approprier n'a absolument rien de simple, rien de définitif, et nécessite une pratique régulière. Coup de chance, vous avez constamment l'occasion de mobiliser ce que vous apprendrez. Car, oui, la matière qui peut être manipulée à partir de ce sujet nébuleux est vaste. Elle va du plus petit élément concret connu de notre univers à l'univers lui-même, en passant par tout ce qui est de l'ordre de la vue d'esprit, c'est-à-dire le monde des idées, et autres abstractions. In fine, tout est système. Notre société est système(s), vous êtes système(s), les atomes sont système(s), vos émotions sont système(s), les conflits le sont, les jeux en tout genre, le soleil, les mauvaises herbes, et aussi le café (oui, j'ai des livres pour ça, mais je vous épargnerai). Pour faire plus court, rien n'est exclu d'un système, et tout peut-être "décomposé" en systèmes. Si ça peut être perçu ou pensé, c'est système(s).

Quand je parlais du parcours, personnellement, j'ai commencé il y a quasiment une décennie à m'y intéresser en cherchant à comprendre le terme cybernétique, la racine historique la plus explicite de tout ça. Je me suis alors perdu dans de nombreux noms qui avaient contribué à la discipline, certains de leurs écrits, des papiers de recherche, des blogs abscons, des livres qui font exploser la tête comme la Méthode d'Edgar Morin, puis des livres un peu plus structurés sur ce sujet comme la Cinquième Discipline, Thinking in Systems, Learning System Thinking, etc. Très décousu donc, et comme je pense qu'on vivrait tous bien mieux avec cette corde à notre arc, je me frustre à tenter de trouver un angle, un ensemble de chemins, me permettant d'embarquer des gens dans cette aventure. En réalité, je tente de concevoir un système qui vous permettra de mieux comprendre les systèmes.

Dans mes tentatives les plus explicites sur le thème :

Et dans les moins explicites Les modèles d’organisation produisent nos modèles culturels, ainsi qu'un bon paquet de liens éparpillés.

Je vais donc tenter une structure :

un parcours de différents archétypes de systèmes que j'introduirai : le but est de commencer à voir des dynamiques de systèmes dans notre environnement, premier pré-requis à un début de prise de conscience, voire de pratique. Ces archétypes ont pour atout d'être suffisamment courants pour pouvoir en repérer un bon nombre, et donc de nécessiter peu d'efforts pour être modélisés.
un langage et une façon de modéliser les systèmes : que j'aborde en second temps pour que vous ayez une vue concrète avant la théorie. L'idée est de pouvoir assembler les patterns précédents, voire d'assembler des choses que vous ne sauriez classer dans ces patterns. À partir de là, vous commencerez à voir des dynamiques plus complexes en marche.
des signaux, tips, permettant de développer une intuition qu'un système doit être modélisé, et par où commencer, voire quelques dérivés des archétypes : surtout utile pour la vie de tous les jours. J'hésite encore à le mettre en deuxième position, avant la modélisation.
un exemple de mise en pratique de tout ça dans un contexte maitrisable : davantage pour un aperçu de l'articulation de la pratique à ma manière plutôt que d'étudier le système en question. Cela dit, avec la pratique, c'est votre propre démarche qui sera la plus optimale.
des études de cas : à la fois pour vous entrainer à la modélisation, mais aussi pour aborder différents types de complexités.

Pas mal de bouquins tentent de transmettre cette notion. La différence ici est que vous allez les recevoir à un rythme, je l'espère, soutenable, et dans un volume et une forme abordable au sein de votre quotidien déjà bien chargé.

C'est ambitieux pour un blog perso. Tenir tout ça sera difficile. Si j'ai sorti l'article précédent et celui-ci, c'est parce que j'ai pris des congés. Cela dit, j'espère que de m'être lancé et d'avoir anticipé la structure me facilitera la tâche pour la suite. La clé sera de faire court, à la fois pour moi, mais aussi pour vous.

N'hésitez pas à formuler tout type de feedback. Si c'est difficile, c'est très probablement que j'ai loupé un moyen d'accrocher ce que je veux transmettre avec ce que vous savez? Aucun de nous n'a suivi le même parcours, donc j'ai besoin de savoir quand j'ai loupé une marche pour mieux faire.

NB : l'adresse de la newsletter ne fonctionne plus, et l'hébergeur (Gandi.net) ne semble fournir aucun feedback. Donc, contactez-moi par tout autre moyen qu'une réponse mail à la newsletter (mon adresse pro, perso, discord, etc).

Mini-système, "Escalation"

Fri, 31 Oct 2025 00:00:00 GMT

Quand l'épée rencontre le bouclier.
Cet article fait partie d'une série introduite par ici.

Escalation

Qu'est-ce ?

Souvent incarné dans des relations conflictuelles, dans ce système, des individus ou groupes développent des réponses relativement à d'autres individus ou groupes. L'action d'un premier groupe, déclenche une réaction plus forte d'un autre. Le premier voyant l'autre agir, il amplifie son activité. Et ainsi de suite.

Comment repérer ce système

"C'est l'autre qui a commencé"
Toute relation politique impliquant du terrorisme et/ou une forme de sabotage matérielle ou morale
Un conflit qui n'en termine pas : vous avez probablement en tête un bon nombre d'exemples parmis les conflits internationaux, entre entreprises, inter-équipe, ou intra familaux
Des moyens d'attaque ou de défense qui ne cessent de se développer : on le voit par exemple en cybersécurité, à mesure que la défense s'améliore, l'attaque fait de même
Surenchère, dans le cadre d'innovations, négotiations, etc

Sur papier

Exemples

Les exemples sont légion. Une entreprise est en compétition avec d'autres. Elles développent des services et offres relativement à leurs concurrents. Si un concurrent apporte de la nouveauté, dans son exécution, le résultat, le prix, etc, alors les compétiteurs tenteront d'aller plus loin sur l'un de ces aspects. "Si seulement ils n'essayaient pas constamment de nous devancer, on pourrait lever le pied". Malheureusement, ce type de compétition peut aussi avoir lieu au sein d'une même entreprise, pour le pouvoir, le budget, ou toute autre ressource tangible ou non.

Échappatoires

Soit vous pouvez trouver un bénéfice commun, soit vous pouvez faire en sorte que l'autre se sente moins menacé (en explicitant à quel point les activités de chacun sont orthogonales par exemple). Quoi qu'il arrive, l'écoute active est clé, car il faut comprendre les besoins de part et d'autre, et ce qui est perçu comme une menace. Ce n'est pas aussi évident que ça en a l'air.

Si vous êtes gérant des activités de ces individus ou parties, il peut être utile de se demander pourquoi ces différentes parties sont entrées en compétition. Est-ce le résultat d'une incentive, un privilège, de moyens, de progression de carrière, etc.

Dans le cas où cela dépend d'une ressource commune pour laquelle les parties sont entrées en compétition, et que vous pouvez poser des règles sur son acquisition, vous pourriez faire en sorte que cette ressource ne dépende pas de l'activité des différentes parties, ou ajuster les règles. Un médiateur peut être nécessaire pour que le dialogue se renoue, et que l'écoute prenne la place de la peur.

Sur papier

Références

Ce système est cité dans « la cinquième discipline » de Peter Senge, et « Thinking in systems » de Donella Meadows.

Réorganisations et opportunités

Fri, 07 Nov 2025 00:00:00 GMT

Les structures de communication formelles s'en retrouvent chamboulées (évidemment, puisque la réorganisation restructure), mais également les structures informelles, car elles créent de nouvelles distances entre les personnes et changent les besoins de collaboration qui permettaient au système précédent de fonctionner. Ce qui liait les individus dans leurs activités n’existe plus. Ce qui les séparait non plus.

S’ensuit alors une longue période avant que les personnes présentes, parce qu’elles sont indifférentes, ont eu le courage de rester, ou la crainte de partir, réapprennent à évoluer dans le système et à l’incarner à leur façon. Chacune fini par comprendre, ou en réalité elle découvre d'elle-même, ce qu’on attend supposément d’elle, avec qui collaborer, et comment gérer les exceptions, qui sont au final la norme dans les débuts.

Car si la réorganisation définit de nouvelles équipes et parfois leurs responsabilités, elle précise rarement comment celles-ci devront agir, quels seront exactement leurs objectifs, et comment elles devront interagir avec le reste de l’organisation. L’organisation ne prend vie que lorsque les « pièces » bougent ensemble de manière coordonnée, lorsque certains rouages en entraînent d’autres, lorsque certaines collaborations sont activement maintenues.

Cette part du design, les interactions, la gestion des exceptions, les nouvelles connexions informelles... en bref tout ce que l’on ne voit pas sur un schéma, n’affichant souvent que des boîtes sans flèches annotées, sont les failles qui font que le système deviendra, in fine, ce que les équipes en feront. Et ce quelles que soient les intentions ayant initié cette réorganisation.

Un système social n’est pas un schéma, ni un ensemble de règles, ni un processus aboutissant à un artefact matériel. Ce n’est pas non plus ce que l’on en raconte. C’est ce que les individus qui le composent incarnent. Les règles effectives sont celles qui font partie des modèles mentaux des individus. Le pouvoir de certains n’est possible que parce que d’autres le reconnaissent. Les prophéties autoréalisatrices sont le produit de modes de pensée. Si je pense que la situation est irrattrapable, qu’elle le soit ou non, je contribue inconsciemment à ne pas trouver d’issue favorable.

Les modèles mentaux sont le code de nos systèmes sociaux, et tout évènement est traité à travers ces prismes. Si je pense que cette réorganisation ne fonctionnera pas, il y a des chances que mes actions contribuent à faire dysfonctionner l’ensemble. Si je pense que c’était mieux avant, il y a des chances que l’ancien modèle corrompe le nouveau. Comme l’a dit Peter Drucker, « culture eats strategy for breakfast ».

Le corollaire est que si vous vous placez en position de faire fonctionner ce nouveau système, vos modèles mentaux influenceront probablement la direction qu’il prendra de façon positive, au moins de votre point de vue.

Personne (ou presque) n’aime le flou. Or, tout le monde ressent au début d’une réorganisation qu’il existe de grands vides. Et on a vite fait de demander à toute notre chaîne de supérieurs hiérarchiques de prendre des décisions sur la manière de résoudre la situation. Il est compréhensible de demander aux personnes ayant décidé de rebattre les cartes, ou souvent celles qui les représentent, de prendre la responsabilité de réparer ce qui a été cassé. Vous avez probablement déjà essayé, la demande se perd dans toute la dispersion d'énergie demandée par une réorganisation. Vos chefs directs n'ont peut-être pas voulu eux-mêmes tout ce mouvement. Et pour tout dire, aussi ficelé que soit le design de cette organisation, la carte n'est pas le territoire, et c'est vous qui rencontrerez, les contingences, les "défauts", les jeux entre les pièces, qui ne pouvaient s'observer que par la pratique. C'est peut être alors une opportunité pour vous.

L’organisation précédente ne vous convenait pas ? Celle-ci ne présage rien de bon ? L’organisation est un système dynamique, en devenir constant, et qui n'est à un instant T que ce que ses membres en auront fait. Vous avez dès maintenant l’opportunité d’influencer le cours des choses vers des modes de fonctionnement plus acceptables. Les vides sont inévitables, béants. Et si vous proposez une manière de faire qui réponde aux attentes des gens, qui résolve les incertitudes et tente de faire fonctionner la réorganisation, alors chacun suivra naturellement ce qui apporte le plus de clarté. Demandez-vous ce dont vous avez besoin. Quel serait, à votre échelle, votre mode de fonctionnement idéal. D'autres pourraient être intéressés par cette réflexion ? Embarquez-les. Alors le système convergera progressivement vers les solutions que vous aurez proposées.

Vous aurez des chances de voir les choses s’articuler comme vous l’entendez, et la hiérarchie sera ravie de voir des employés engagés, et son plan en passe de fonctionner.

Mini-système, "Shifting the burden"

Fri, 14 Nov 2025 00:00:00 GMT

Quand on met la poussière sous le tapis.
Cet article fait partie d'une série introduite par ici.

Shifting the burden

Qu'est-ce ?

Ce système implique la résolution d’un problème par une solution qui vient travailler sur les symptômes plutôt que sur la source du problème, provoquant parfois un enlisement, et un besoin de nouvelles solutions palliatives.

Comment repérer ce système

Une solution semblait tout résoudre, quand soudain on se retrouve dans la même situation qu’à l’origine
Un problème récurent est régulièrement traité de différentes façons
« On a déjà essayé XYZ »
Une situation rend l’utilisation d’un moyen addictive

Sur papier

Exemples

C’est, de mon point de vue, un type de système si répandu qu’il est facile à observer sous différentes formes.

On peut imaginer une application pleine de bugs, et qui ne semble pas plus se stabiliser. Plus il y a d’incidents, plus on passe de temps à en résoudre, et donc plus on se précipite pour les résoudre car on doit aussi développer de nouvelles fonctionnalités.

Un autre exemple peut être une entreprise mobilisant des consultants pour résoudre un type de problème. Les contextes n’allant pas en se simplifiant, plus le temps passe, plus l’entreprise devient incapable de résoudre ce type de problème, et plus elle se repose sur des consultants.

Dans ce dernier exemple, on remarque d’ailleurs qu’en prenant un écosystème plus large que l’entreprise demandant conseil, et en incluant l’entreprise de conseil, on retrouve un archétype « Success To The Successful ». Cet archétype mettra alors en évidence là où la compétence se renforce et là où elle s'affaiblit. En revanche, elle ignorera la différence entre problème(s) de fond et palliatif spécifiquement chez l'entreprise comme le ferait l'archétype "Shifting the burden". Un choix de perspective.

On peut aussi imaginer l’effet de tout aide à notre mémoire. Plus on se repose sur un support particulier pour mémoriser des choses (liste de rappel, carnet de contacts…), moins on devient capable de les mémoriser. Vous avez peut-être d'ailleurs déjà fait le lien avec l'assistance par la GenAI.

Échappatoires

Cet archétype est pour moi le meilleur argument à une formation à la pensée systémique. Car bien que facile à identifier, il est difficile d’en trouver la « root cause », pour la raison précise que la systémie en révèle de multiples origines, et à considérer les patterns plutôt que les événements.

Dans le cas du logiciel, plus l’on corrige de bugs en surface, moins on a de temps pour en corriger l’origine. Dans le cas de l’entreprise demandant conseil, plus elle se repose sur un conseil externe, moins elle devient autonome.

Dans le cas de la mémoire, moins on la sollicite, plus il devient difficile de la solliciter spontanément.

Dans ces cas, « la solution » serait bien entendu d’y investir du temps. Cela dit, si c'était si simple, nous l'aurions fait dans de nombreuses situations. Qu’est-ce qui nous en empêche ? Le manque de tests ? Le manque de compétence ? L’urgence ? La pression d’une partie prenante ? Le manque de financement ? Bien entendu, l’issue d’une résolution profonde serait satisfaisante pour tout le monde. Ce qui pose problème, c'est l'impact de l'investissement préalable, devenant toujours plus important à mesure que la situation s’enlise. Elle ne peut alors être résolue sans considérer l’ensemble de ces contraintes grandissantes.

Si vous aboutissez à la conclusion que « La » cause (unique) est une personne ou une équipe, considérez que vous avez échoué. Les personnes, majoritairement de bonne intention, font ce qu’elles font bien souvent parce qu’elles ont été amenées à ces agissements. La question doit plutôt être, comment composer avec, ou résoudre ce qui les pousse à cela.

Un exemple de plus pour l’illustrer : si l’on détermine qu'un incident au sein d'un système technique provient des agissements d’une personne fatiguée le jour où elle l’a manipulé, considérez qu’une autre personne sera inévitablement fatiguée un autre jour, et qu’il faut plutôt concevoir une façon permettant de mieux gérer les oublis, les erreurs, ou d’y être plus résiliant. On peut par exemple imaginer de l'automatisation (ex: tests, monitoring...), des checklists, etc.

Sur papier

Références

Ce système est cité dans « la cinquième discipline » de Peter Senge, et « Thinking in systems » de Donella Meadows.

Mini-système, "Balancing process with delay"

Fri, 21 Nov 2025 00:00:00 GMT

Quand on mange trop vite.
Cet article fait partie d'une série introduite par ici.

Balancing process with delay

Qu'est-ce ?

Dans ce système, une action correctrice est appliquée à répétition, faute de changement dans les résultats, ou d'une trop lente évolution. Les effets de l'action correctrice se produisant à retardement, il arrive un point où, soit l'action correctrice, bien que correcte, est abandonnée, soit, malgré l'atteinte du résultat, le système semble être pris dans une forme d'inertie jusqu'à être déstabilisé.

Comment repérer ce système

Une solution mobilisée régulièrement semble avoir peu ou pas d'effet
Un problème semble s'être transformé en un autre problème (parfois l'opposé de la situation initiale)
Des résultats en apparence "chaotiques", parfois l'opposé de la situation initiale, parfois d'autres états.

Sur papier

Exemples

Un exemple de la vie de tous les jours peut-être lorsque nous mangeons. Vous avez très faim, et vous vous mettez à manger vite. Malgré la quantité ingérée en peu de temps, la faim est toujours présente, car le sentiment de satiété est un processus lent et complexe qui met 15 à 30 à minutes à se manifester (délai), alors vous mangez plus. Au bout d'un moment, la satiété vient, et vous sentez même que vous avez beaucoup trop mangé.

En entreprise, ça peut être la remontée d'un besoin de recrutement. Tant qu'il y a un besoin d'effectifs, il peut être demandé à une équipe dédiée de recruter. Toute activité de recrutement prend du temps, de l'identification des caractéristiques recherchées, au ciblage, à la rencontre et l'aboutissement potentiel du processus vers la signature du contrat. Si les initiateurs de la demande ne sont pas conscients de l'étendue de ce délai, ils peuvent continuer à demander à recruter. Arrivés au moment où les effectifs répondent au besoin, il existe encore des personnes en cours de recrutement qui finiront par augmenter les effectifs au-delà de la cible. Par ailleurs, cette cible est probablement mouvante, et avec des délais probablement différents de ceux du recrutement. La conséquence est un surcoût pour les besoins de production qui tend, entre autres, à orienter l'entreprise vers des difficultés économiques, un manque de capacité à accompagner les nouveaux venus et donc des écarts de pratiques, etc. Ce type de situation ressemble au jeu de la bière (notamment décrit dans « la cinquième discipline » de Peter Senge) dans lequel des joueurs portent les rôles de vendeur, distributeur et producteur de bière, avec des délais dans les processus.

Échappatoires

Le problème essentiel est que le délai n'est pas pris en compte. Si personne ne l'a envisagé, l'absence de résultat immédiat devrait déclencher la question de l'existence d'un délai. Si ce délai est connu, mais que vous n'avez pas d'indicateur, tenter des mesures, finales ou intermédiaires, pour le déterminer, même approximativement. Et que vous puissiez le mesurer ou non, armez-vous de patience.

Dans le cas du repas, cela implique de ralentir, en étant conscient du délai classique avant satiété.

Dans le cas des recrutements, les initiateurs et l'équipe de recrutement doivent régulièrement se partager leurs indicateurs de besoin de recrutement et les candidats en cours de processus de recrutement. Les conditions pouvant évoluer dans les deux sens à la fois du côté des besoins, et des potentiels recrutés, la meilleure méthode est simplement de prévoir avec ce que l'on sait, et d'ajuster en prenant en compte les délais.

Sur papier

Références

Ce système est cité dans « la cinquième discipline » de Peter Senge, et « Thinking in systems » de Donella Meadows.

StrykerJS plante avec "Fatal JavaScript invalid size error"

Wed, 14 Jan 2026 00:00:00 GMT

Si vous exécutez des tests de mutation StrykerJS et que vous rencontrez ce crash :

Fatal error in , line 0
Fatal JavaScript invalid size error 169220804 (see crbug.com/1201626)

#FailureMessage Object: 0xffffe38d83a0
----- Native stack trace -----
 1: 0xd09208  [stryker]
 2: 0x1f8b930 V8_Fatal(char const*, ...) [stryker]
 3: 0x1072c70 v8::internal::FactoryBase<v8::internal::Factory>::NewArrayList

Stryker tente probablement de copier des fichiers volumineux dans son répertoire sandbox.

La cause

Stryker copie les fichiers de votre projet dans un sandbox .stryker-tmp avant d'exécuter les mutations. Si votre projet contient des fichiers volumineux (core dumps, artefacts de build, fichiers média), V8 peut planter en tentant de les manipuler, particulièrement sur ARM64 où ce bug V8 se déclenche plus facilement.

Dans mon cas : un fichier core dump de 1,3 Go traînait à la racine du projet.

La correction

Ajoutez ignorePatterns dans stryker.config.json :

{
  "ignorePatterns": [
    "reports",
    "core",
    "*.log",
    "dist",
    "build"
  ]
}

node_modules, .git et quelques autres sont déjà ignorés par défaut.

Diagnostic rapide

Vérifiez la taille de votre projet hors node_modules :

du -sh * | sort -h | tail -10

Si vous voyez des répertoires ou fichiers anormalement volumineux, ajoutez-les à ignorePatterns.