Pas mal ce format à côté de celui de todo.txt que j'utilise au quotidien depuis… des lustres !
Pour todo.txt, je suis aidé du logiciel Sleek.

Mais pour ce format [x]it!, je suis curieux de savoir si cela serait + pertinent pour mon usage ; et si les logiciels associés sont utiles.

À la base, je cherchais un outil qui puisse me sortir des stats sur mes volumineux fichiers todo.txt…

La gestion ultime de son travail. Au fil des années, je suis arrivé naturellement au système décrit. J'ai peut-être encore des détails à apprendre ou ajuster.

Citation originale : “A mistake repeated more than once is a decision.”

via un sujet sur la qualité au travail

1. Loi de Murphy : « Tout ce qui peut mal tourner va mal tourner » (“Anything that can go wrong, will go wrong”). Autres noms : loi de l’emmerdement maximum (LEM), loi de la tartine beurrée, effet démo (avec sa variante sous-culturelle : l’effet Bonaldi), loi de Bouchard, loi du fatal error, loi de Finagle…
2. Loi de Parkinson : « Le travail s’étale de façon à occuper le temps disponible pour son achèvement ». Autres noms : loi des gaz appliquée au travail, loi de la pyramide sans fin. A ne pas confondre avec l’autre loi de Parkinson du même auteur, autrement appelée « loi de la futilité » ou « loi du local à vélos ».
3. Loi de Carlson : « Un travail réalisé en continu prend moins de temps et d’énergie que lorsqu’il est réalisé en plusieurs fois ». Cela signifie que les interruptions sont mauvaises pour la productivité. Autre nom : Loi des séquences homogènes.
4. Loi de Douglas : « Plus on a de place dans son bureau, plus on étale ses affaires ».
5. Loi de Illich : « Au-delà d’un certain seuil, l’efficacité humaine décroît, voire devient négative ». Autre nom : loi des rendements décroissants.
6. Principe de Pareto : 80% des effets sont le produit de 20% des causes. Dans une entreprise par exemple, cela veut dire que 80% des résultats découlent de seulement 20% du travail. Autres noms : loi de Pareto, règle des 80/20, loi des 80/20.
7. Loi de Laborit : le comportement humain nous incite à faire en premier ce qui nous fait plaisir. Au travail nous avons tendance par instinct à « chercher la satisfaction immédiate » et à « fuir le stress ». Autre nom : Loi du moindre effort.
8. Loi de Hofstadter : « Les choses prennent plus de temps que prévu, même en tenant compte de la Loi de Hofstadter. ». Autre nom : Loi de glissement de planning.

Avec la traduction (via DeepL)

Au début de ma carrière, lorsque je travaillais comme ingénieur, mon patron avait mis en place un processus selon lequel l'équipe d'ingénieurs devait rendre compte de l'état d'avancement du projet. Il insistait pour que nous suivions les étapes suivantes, dans l'ordre indiqué :

1. Phrase clef : Les faits ; pas d'adjectifs, d'adverbes ou de modificateurs. "Le jalon 4 n'a pas été atteint à temps et nous n'avons pas commencé la tâche 8 comme prévu". Ou encore : "La charte a été approuvée comme prévu".
2. Situation actuelle : Comment l'énoncé de la chute affecte le projet. "En raison de l'étape manquée, le chemin critique a été retardé de cinq jours."
3. Prochaines étapes : La solution, le cas échéant. "Je pourrai rattraper trois jours au cours des deux prochaines semaines, mais j'aurai toujours deux jours de retard."
4. Explication : La raison de la chute. "Deux des cinq jours de retard sont dus à la découverte tardive d'un problème d'interface matérielle, et les trois jours restants sont dus au fait que j'ai été appelé à aider le personnel du service d'assistance à la clientèle pour un problème de production."

Remarquez l'ordre presque inverse de ces points par rapport au style de rapport habituel dans lequel les membres de l'équipe commencent par une longue explication des raisons pour lesquelles les choses se sont mal passées. En suivant les quatre étapes décrites ci-dessus, le chef de projet apprend d'abord les informations les plus importantes, puis les informations complémentaires qui l'aideront à compléter l'histoire.
Au début, il n'était pas facile de rendre compte de cette manière. Cela nous obligeait à aller à l'essentiel rapidement et à ne pas recourir à l'obscurantisme. Mais je n'ai pas seulement appris à pratiquer ce style de rapport de situation au bureau, je l'ai aussi enseigné à mes enfants.

Cette méthode a été mise à l'épreuve quelques années plus tard. Il était minuit passé, bien après l'heure à laquelle mon fils Raj, alors âgé de 17 ans, aurait dû rentrer à la maison. Il conduisait pour la première fois et la nuit était orageuse. Sa mère et moi étions anxieux et soucieux de son bien-être. Finalement, le téléphone a sonné. C'était Raj, et il a dit : "Papa, je vais bien ; le taureau est mort".
Dieu merci, mon fils allait bien, mais le commentaire sur le taureau mort m'a intrigué. Nous ne possédions pas de taureau. Où était-il ? Comment le taureau était-il mort ? Et pourquoi m'en parlait-il ?
Puis il a dit : "La voiture est endommagée mais utilisable."
D'accord. Il avait eu un accident, la voiture n'était pas une perte totale et il y avait un taureau mort (ce qui reste une grande énigme). Je me suis demandé si notre assurance automobile couvrait les taureaux morts.
Il m'a ensuite expliqué le lieu de l'accident et m'a informé qu'une personne à proximité avait appelé la police et qu'il (Raj) avait pris quelques photos de la scène de l'accident.
À ce moment-là, ma femme s'est réveillée et m'a demandé : "C'est Raj, et il va bien ?". Je lui ai répondu : "Il va bien, le taureau est mort". Cela a attiré son attention et elle était maintenant bien réveillée.
Bien qu'un peu fâchée que Raj soit rentré si tard et qu'il ait eu un accident, j'ai été impressionnée par son comportement calme et sa capacité à garder son sang-froid. Raj a poursuivi en disant : "Tu n'as pas besoin de te presser. Je vous expliquerai quand je vous verrai." J'ai raccroché le téléphone et j'ai commencé à me préparer à me rendre sur les lieux de l'accident.
A ce moment-là, ma femme, toujours intriguée par les informations qu'elle avait reçues, m'a demandé des détails. Je lui ai répété : "Il va bien, le taureau est mort et il m'expliquera les détails à mon arrivée". Un peu agacée, elle m'a dit : "C'est l'une de vos histoires à chute, n'est-ce pas ?".

J'ai été très impressionné par la façon succincte dont Raj m'a donné la bonne information dans le bon détail, sans entrer dans des explications inutiles. En journalisme, c'est ce qu'on appelle la pyramide inversée, qui commence par la conclusion, suivie des faits les plus importants et, enfin, des détails. Ce style contraste avec la rédaction académique, qui commence par l'énoncé du problème, développe le contexte, discute des facteurs d'influence et enfin énonce les conclusions. Lorsque l'approche académique est utilisée pour présenter des rapports sur l'état d'avancement d'un projet, les personnes qui attendent encore la chute prient silencieusement : "S'il vous plaît, mon Dieu, tuez-moi maintenant". C'est précisément la raison pour laquelle je commence par la chute.

Pour de nombreux membres de l'équipe de projet, commencer par la chute peut être déconcertant, mais nous avons constaté qu'une fois qu'ils s'y sont habitués, ils apprécient vraiment la clarté du message et le temps gagné pour faire passer le message.

Essayez-le, vous l'apprécierez.

Lors de la planification de votre journée, dressez la liste de toutes les tâches que vous devez faire et ordonnez les selon la logique suivante :

• Une tâche « A » est une tâche importance avec des conséquences significatives
• Une tâche « B » est une tâche que vous devriez faire mais qui a des conséquences limitées
• Une tâche « C » est une tâche qui serait sympa à faire mais sans conséquences
• Une tâche « D » est une tâche que vous pouvez déléguer à quelqu'un d'autre
• Une tâche « E » est une tâche que vous pouvez éliminer sans aucune conséquence

Ajoutez une lettre devant chacune de vos tâche et ordonnez les en ajoutant un numéro, exemple :

• A1 - Écrire un article
• A2 - Publier l'article
• D1 - Faire ma comptabilité
• E1 - Acheter un poster

La règle veut que vous ne fassiez jamais de tâche de type B lorsqu'il reste encore une tâche de type « A » à accomplir.

J'aime bien l'idée. À caler avec un todo.txt qui va bien. Et puis l'appli pter sur Ubuntu ainsi que Simple Task (pour Nextcloud) sur Android.

Intéressant :

En 1944, l’OSS (ancêtre de la CIA) proposait un petit manuel de sabotage des organisations à la portée de tous. J’ai essayé de synthétiser ça en 10 points avec mes propres mots :

1. Insistez systématiquement pour que les procédures en place soient respectées et suivies à la lettre. Ne laissez jamais personne prendre une initiative qui pourrait accélérer le processus.
2. Soyez verbeux, à l’oral comme à l’écrit. Multipliez les références et les anecdotes, attirez l’attention sur des problèmes secondaires et abstenez-vous de résumer votre avis ou vos recommandations.
3. Remettez toujours la légitimité de votre instance de décision en question : faites valider chacune de vos décisions par la hiérarchie et multipliez les comités consultatifs aussi larges que possible.
4. Montrez-vous extrêmement prudent sur tous les sujets, insistez sur le fait que toute erreur pourrait avoir de graves conséquences et invitez régulièrement le groupe à reconsidérer des questions déjà tranchées.
5. Convoquez fréquemment des réunions, multipliez les participants (au motif que leur avis pourrait être utile) et insistez pour que la réunion se fasse en présentiel pour que tout le monde perde autant de temps que possible.
6. Récompensez les meilleurs opérationnels en leur offrant (ou en appuyant leur candidature pour) des postes prestigieux mais pour lesquels ils ne sont pas compétents et qui les éloignent le plus possible du terrain.
7. Montrez-vous aussi pointilleux que possible sur les questions de vocabulaire mais insistez sur le fait que les délais impartis ne permettent pas d’organiser des réunions spécifiquement dédiées à ce problème.
8. Privilégiez systématiquement les échanges écrits, même pour les choses les plus anodines, et demandez toujours (par écrit) le plus de précisions possibles avant de commencer à travailler effectivement.
9. Assignez toujours les tâches critiques (i.e. potentiellement bloquantes) à des collaborateurs peu compétents ou lents et exigez que leur travail soit parfait avant de passer à l’étape suivante.
10. À chaque dysfonctionnement, organisez une réunion (cf. point 5) afin d’établir une nouvelle procédure (cf. point 1) et discutez-en par écrit (cf. point 8) avec votre hiérarchie (cf. point 3).

Je vais tenter de traduire en français ce Minifesto :

Texte original

1. Fight for Pareto's law, look for the 20% of effort that will give you the 80% of results.
2. Prioritize, minimalism isn't about not doing things but about focusing first in the important.
3. Perfect is enemy of good, first do it, then do it right, then do it better.
4. Kill the baby, don't be afraid of starting all over again. Fail soon, learn fast.
5. Add value. Think constantly how you can help your team and position yourself in that field/skill.
6. Basics, first. Follow always a top-down thinking starting by the best-practises of CS.
7. Think different. Simple is harder than complex, which means you'll need to use your creativity.
8. Synthesis is the key of communication. We have to write code for humans not machines.
9. Keep it plain. Try to keep your designs with few layers of indirection.
10. Clean kipple and redundancy. Minimalism is all about removing distractions.

Traduction personnelle

1. Se battre pour la loi de Pareto ; chercher les 20% d'effort qui apporteront 80% de résultats.
2. Prioriser ; le minimalisme ce n'est pas ne pas faire les choses, mais c'est se concentrer d'abord sur les choses importantes.
3. La perfection est l’ennemi du bien ; d'abord le faire, puis le faire bien, enfin le faire mieux.
4. Tuer le bébé ; ne pas être effrayé par tout recommencer. Échouer tôt, apprendre vite.
5. Ajouter de la valeur ; penser constamment comment aider son équipe et se positionner dans ce cadre.
6. Les bases, d'abord ; toujours suivre une approche descendante en commençant par les bonnes-pratiques en informatique.
7. Penser différemment ; simple est plus dur que complexe, ce qui signifie que l'on a besoin de sa créativité.
8. Synthétiser est la clef de la communication ; on doit coder pour des humains, pas des machines.
9. Rester simple ; essayer de garder sa conception avec peu de niveaux de redirection.
10. Nettoyer le bazar et la redondance ; le minimalisme c'est juste supprimer les distractions.

Traduction DeepL

1. Luttez pour la loi de Pareto, recherchez les 20% d'efforts qui vous donneront les 80% de résultats.
2. Fixez des priorités, le minimalisme ne consiste pas à ne pas faire certaines choses mais à se concentrer d'abord sur ce qui est important.
3. Le parfait est l'ennemi du bien, faites-le d'abord, puis faites-le bien, puis faites-le mieux.
4. Tuez le bébé, n'ayez pas peur de tout recommencer. Échoue vite, apprends vite.
5. Apportez de la valeur ajoutée. Pensez constamment à la manière dont vous pouvez aider votre équipe et positionnez-vous dans ce domaine/cette compétence.
6. Les bases, d'abord. Suivez toujours un raisonnement de haut en bas en commençant par les meilleures pratiques de CS.
7. Pensez différemment. Le simple est plus difficile que le complexe, ce qui signifie que vous devrez faire appel à votre créativité.
8. La synthèse est la clé de la communication. Nous devons écrire du code pour les humains et non pour les machines.
9. Restez simple. Essayez de garder vos conceptions avec peu de couches d'indirection.
10. Éliminez les distractions et les redondances. Le minimalisme consiste à éliminer les distractions.

Six manières de recréer des discussions de bureau rapides et informelles dans un monde où le travail est décentralisé.

1. Organiser des permanences dans n’importe quel canal
   Historiquement, bon nombre de responsables et de directeurs ont pratiqué la politique de la porte ouverte. Dans ce nouveau monde axé sur le numérique, cela se manifeste fréquemment par un créneau horaire libre où chaque collaborateur disposant du lien d’appel vidéo correspondant peut se connecter pour discuter de ses principales préoccupations. Les appels d’équipe sont une solution alternative plus inclusive.

J'aime bien cette idée : ouvrir un canal de télé-conférence type « permanence porte ouverte » d'une équipe pour échanger sans but prédéfini.
Dans les autres conseils sur la page, il y a :

2. Les sessions de réflexion après les réunions
3. Une programmation en binôme rapide et simplifiée
4. Répondre aux commentaires de dernière minute d’un intervenant
5. Un dépoussiérage hebdomadaire pour régler les derniers détails
6. Des rencontres sociales

Règle 4
Aucune fonction ne doit être plus longue que ce qui peut être imprimé sur une seule feuille de papier, dans un format de référence standard, avec une ligne par instruction et une ligne par déclaration. En règle générale, cela signifie qu’il n’y a pas plus de 60 lignes de code par fonction.

Ayant parfois affaire à des fichiers Excel de quelques centaines de lignes, et parfois plusieurs dizaines de colonne, ça me rend fou.
Donc j'aime bien cette règle : maximum 60 lignes. À cela on peut ajouter une des règles du PEP-8 Python qui préconise pas + de 79 caractères par ligne.

Voir aussi la RFC 2223 qui indique :

3a. ASCII Format Rules
[…]
Each page must be limited to 58 lines followed by a form feed on a
line by itself.
Each line must be limited to 72 characters followed by carriage
return and line feed.

Cela donne un formatage un peu surprenant mais cela donne une bonne idée de ce qui est humainement révisable.

Édition 2024-09-26

Finalement ces « 10 règles pour écrire du code sécurisé » s'inspire/a inspiré les règles de codage du JPL de la NASA 👇

1. Éviter les constructions de flux complexes, telles que goto et récursivité .
2. Toutes les boucles doivent avoir des limites fixes. Cela évite de créer involontairement des boucles infinis.
3. Éviter d'allouer de la mémoire sur la heap.
4. Limiter les fonctions à une seule page affichable sur un écran.
5. Utiliser un minimum de deux assertions par fonction.
6. Limiter la portée des variables au plus petit possible.
7. Vérifier la valeur de retour de toutes les fonctions non-void ou transformer en void pour indiquer que la valeur de retour est inutile.
8. Utiliser le préprocesseur avec parcimonie.
9. Limiter l'utilisation du pointeur à un seul déréférencement et ne pas utiliser de pointeur de fonction.
   10. Compiler avec tous les avertissements possibles actifs ; tous les avertissements doivent alors être pris en compte avant la publication du logiciel.

La fameuse cible (que je cherchais depuis hier…) ! On y retrouve :

1. Agresser physiquement = -4
2. Insulter ou menacer = -3
3. Attaquer la personne sur ce qu'elle est = -2
4. Attaquer la forme du propos = -1
5. Contredire sans argument = Taper ici = faire du surplace
6. Contredire en argumentant = +1
7. Réfuter une parole = +2
8. Identifier et réfuter la thèse centrale = +3

C'est directement inspiré de la "pyramide" de l'auteur.

Voir aussi une nouvelle sur LinuxFr.org qui parle de "comment réfuter".

« À vouloir donner la possibilité de réaliser des choses complexes, on complexifie inutilement la réalisation des choses simples. »

Intéressant cette structuration des dossiers personnels :

• work (projects I am working on right now)
• permanent (projects that are always active) : wiki, email, …
• archive (completed and inactive projects get moved here)
• library : music, books, papiers
• tmp (temporary files)

L’action crée ma motivation. Pas le contraire

shit!, toujours aussi bons ses articles !!

Cette méthode est très conceptuelle mais ses bases m'intéressent beaucoup. Au moins à titre de curiosité je penses que c'est pertinent de la découvrir.

via https://fego.github.io/2020/11/01/J%27ai-enfin-appris-%C3%A0-prendre-des-notes.html
via https://chezsoi.org/shaarli/?Cs89yg

Je cherchais la notion de GO/NOGO et en lisant ce document, j'apprends que le “No Go” est à la base une notion où l'avion est en bout de piste mais qu'il ne décollera effectivement pas. Ici c'est le fait d'emmener un patient au bloc et d'arrêter le processus d'opération avant de l'inciser.
Je découvre donc dans ce document « aide cognitive POuR – DÉCider » : « L’objectif […] est de fournir, face à une situation inattendue, un outil structuré pour la prise de bonnes décisions en cas d’absence de procédures ou de règles préexistantes et quand une mauvaise décision peut avoir des conséquences graves. »

Cette aide cognitive comporte 3 parties :

• la partie POuR : concerne le processus cognitif (réflexion) qui doit être mené.
• le trait d’union – reliant POuR et DÉCider représente le temps indispensable d'échange en équipe.
• la partie DÉCider : concerne le processus de décision et de mise en œuvre de la solution choisie.

Un surnom m’a un jour été donné : “Pompier du code”. J’aime cette notion. Un pompier c’est 50 % d’entraînement, 40 % de prévention et 10 % d’opération de secours.

Les étapes avant d'effectuer une performance (sportive) :

1. Mon projet est-il clair et précis ?
2. Suis-je vraiment opérationnel ?
3. Suis-je dans le bon état d’esprit ?
4. Suis-je prêt à forcer comme un phacochère ?
5. Quid de la sécu ?

Alors, comment puis-je choisir un problème sur lequel travailler ? C’est une heuristique complexe calculée à partir des facteurs suivants :

• Nombre d’utilisateurs concernés
• Gravité (« problème de sécurité » vs « faute d’orthographe »)
• Opportunité (ce qui signifie que je l’ai remarqué lorsqu’il a été déposé)
• Disponibilité (est-ce que je me concentre sur autre chose lorsque je remarque le problème ?)
• Plaisir possible et humeur du moment (eh oui, car je suis bénévole, ça vous dérange ?).