Un très bon article sur l'écriture, technique ou pas. Il y a certains conseils que je n'applique évidement jamais.
Un article d'introduction à l'influence en milieu professionnel. Oui, c'est de la politique. Oui, c'est du lobbying. Oui, c'est de la manipulation. Et oui, c'est égoïstement pour faire avancer mes idées.
Mais mes idées sont les meilleures 😅
Blague à part, la politique arrive dès que plusieurs personnes veulent avancer dans des directions différentes.
Evidement, je suis globalement d'accord avec cet article.
Eh oui, l'IA n'est pas un outil simple à manier ni à comprendre.
Il y a là-dedans quelques infos qui vont me servir.
Et pour une fois, la méthodologie est décrite et correcte. C'est vraiment la défense la plus professionnelle que j'aie vu depuis longtemps.
J'ai un projet pour lequel ça s'appliquera très bien.
Comme je dis bien souvent, si tu ne veux pas que ton POC aille en prod, ne le mets pas dans git
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
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.
Je n'avais jamais entendu parler de cette pratique, et je la trouve anti-productive : si les objets que vous manipulez sont un tant soi peu complexes, n'avoir qu'une seule assertion ne prendra pas en compte la complexité de vos objets.
Ca ressemble de plus en plus à ma méthode de travail idéale, ça
Ah, donc SAFe ne marche pas si bien ? Je tombe de ma chaise !
Le mode de communication des gens préférés : donner d'abord la conclusion, puis les arguments appuyant cette conclusion
C'est une bonne idée, surtout pour assumer nos décisions, mais aussi pour améliorer la relation commerciale
Une intéressante liste de contraintes liées à l'exploitation d'un logiciel. Il y a quelques idées intéressantes.
Hyper intéressant détail sur les modes de résolution de pedantix. Il en manque un : la force brute.
J'aime beaucoup ce concept de conférence où le but est vraiment de ne pas avoir d'effet Wow
J'aime beaucoup cette méthode, je pense qu'il va falloir que je m'y mette vraiment.
On va donc dire merci au précédent ministre de l'éducation nationale pour ce succès ...
C'est assez malin comme écriture d'article, et ça donne un bon aperçu des différents types d'entretien. En revanche, l'investissement en temps est délirant.
Décidément, je me reconnais beaucoup dans la philosophie classique
Comment faire des présentations percutantes, surtout pour les gens pressés
Une méthode permettant de mieux comprendre les différents éléments de la demande d'un interlocuteur.
C'est le mode d'écriture de la documentation des développeurs que je préfère. C'est simple, efficace, et ça garantit une documentation à jour ... pour peu que les développeurs soient des professionnels.
Heureusement que je n'utilise jamais ByteBuffer directement, parce que ce genre d'erreur aurait tendance à me faire bien pester (même si la covariance du type de retour inclue dans la signature est plutôt une bonne idée)
Cet article me donne une idée intéressante pour retourner un problème interne...
Alors ça c'est vraiment de bons principes d'architecture (et pas seulement pour de l'"architecture continue"
Les histoires d'horreur du monde du développement de jeux vidéos sont vraiment pathétiques.
Quand je lis ce document, j'ai l'impression de voir une autre forme de description d'architecture applicative se dessiner. C'est intéressant ...
Ca m'a l'air d'être une méthode d'identification des risques de sécurité qui sorte de "oulala, c'est grave, non mais tu te rends compte" tellement fréquent dans cet univers ...
Très bonne idée, à réutiliser dans tous les slides de question de conférence
Un intéressant article documentant un problème de management franchement commun