Je n'ai fait que survoler l'article, mais il me fait rudement réfléchir. Effectivement, résoudre les problèmes non triviaux mérite de s'interroger sur le problème, et sur les différentes manières de le résoudre, les bonnes comme les mauvaises.

C'est extrêmement intéressant comme mécanique de lifelogging

Ca m'a l'air d'une lecture très utile pour augmenter la documentation Rust

On dit qu'un blog meurt à partir de moment où l'auteur écrit un article sur pourquoi il blogue. Cet article n'explique pas pourquoi Julia blog, mais on en est pas très loin. Comme d'habitude, il est très bien écrit et mérite la lecture.

Archiver un magazine à grande échelle. C'est un travail de Romain. Et cet article explique assez correctement le processus.

Un article plutôt intéressant sur l'usage des notes. Je suis à la fois un peu d'accord et complètement pas d'accord. Un peu d'accord parce que. La plupart des notes sont effectivement utilisées comme des brind up, c'est-à-dire des façons de sortir de votre texte qu'il y a dedans. Et de l'autre, complètement pas d'accord parce que avec Shaarli, je continue à pouvoir utiliser des informations que j'ai stockées il y a des années. Mais est-ce que Charlie me permet de prendre des notes ? C'est une question.

Une très bonne règle de communication

1. Pas plus de trois idées par communication
2. Expliquer les idées difficiles de trois façon différentes
3. Répéter les idées importants trois fois

Une série de bons conseils aux ingénieurs

J'ai simplement survolé l'article, mais ce que j'y lis m'a l'air vraiment intéressant

Il va falloir que je le relise plus tard au calme

Ca m'a l'air d'une lecture hautement recommandable concernant la résolution de problèmes ...

Ah tiens, c'est marrant, parce que ça existe aussi côté interviewer pour comprendre ce que raconte la personne interviewée. Sauf que les catégories sont un peu différentes

Un article plein de nuance sur l'art délicat du management, avec toutefois une priorisation intéressante, et que je retiens pour l'avenir

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

Cet article parle de la Pologne, mais surtout du fait de créer une entreprise. Et certaines questions sont parfaitement relocalisables en France

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

Comment décommissionner un serveur ? Simplement en l'arrêtant de façon de plus en plus prolongée et en regardant quand les utilisateurs râlent

Oh j'adore, parce qu'en vieillissant, je me rends beaucoup mieux compte de certains contenus limite.

C'est marrant qu'une boîte ait choisi de supprimer toutes les réunions pour une semaine. C'est encore plus marrant qu'ils aient constaté que c'est une bonne idée, mais qu'ils n'étaient pas complètement chauds pour continuer sans réunions. Ca dit quelque chose de l'objectif dual des réunions : permettre de partager, certes, mais aussi permettre aux dirigeants de montrer leur pouvoir (beaucoup de personnes dans leurs réunions) et se rassurer sur leur sens dans l'entreprise

Personnellement, je disais beaucoup ça quand j'étais jeune. Et avec l'expérience, j'ai compris qu'il est assez facile de reproduire les fonctionnalités, mais plus difficile de reproduire les bugs. Sans compter toutes les fonctionnalités non documentées. Et de ce fait, quand on me propose de réécrire une brique, j'ai de plus en plus tendance à d'abord demander pourquoi tout réécrire.