Une sélection de ce que j’ai écouté, vu ou lu et qui a marqué ma semaine (ou aurait dû) ! Comme le remarque mon collègue Thomas dans un billet, c’est représentatif de ma bulle informationnelle ! Vous êtes prévenus !

Ecouté

  • J’ai particuièrement apprécié l’écoute de Unproven Tech with Sean Allen (et le transcript). Ce que j’ai trouvé intéressant est que ce podcast retrace le raisonnement autour du choix de l’outil approprié pour construire un outil avec des besoins et contraintes spécifiques. C’est vraiment une écoute pertinente pour tout tech lead ou tout architecte, et c’est un plaidoyer pour choisir le bon outil pour une tâche précise en se basant sur les contraintes et les objectifs techniques. Ce qui est important ce n’est pas tant ce qu’ils ont fini par choisir comme langage pour faire leur implémentation, c’est comment et pourquoi ils en sont arrivés là. C’est aussi un rappel qu’un langage de programmation est un outil comme un autre pour accomplir une tâche.

    • Basically programming languages are tools. It’s not about ergonomics, it’s not about developer experience, it’s not about all the things that we normally talk about, it’s about getting the job right. For whatever that means it’s a means to an end. (Sean Allen paraphrasing Sylvan Clebsch).

  • Cela rappelle aussi ce que les choix techniques ce sont des compromis (pas que par rapport à des contraintes techniques d’ailleurs dans beaucoup de cas) et qu’il faut choisir sa douleur, rien n’est jamais gratuit et sans conséquences pouvant être perçus comme négatives.
  • Avec la sortie prévue pour la fin d’année d’un film adaptant le roman Dune de Frank Hebert, plusieurs podcast sur ce thème
  • Si vous développez en écrivant des tests unitaires en Python, cet épisode de Test & Code (ou cet épisode de TalkPython) est un indispensable qui présentent 15 plugins incoutournables pour PyTest. Ces 2 Podcasts sont dans ma liste d’écoute, mais c’est ce tweet qui a attiré mon attention rapidement dessus.
  • Le Podcast #272 de NoLimitSecu est dédié à l’OSINT(Acronyme de Open Source INTelligence, en français on écrirait ROSO pour Rrenseignement d’Origine Sources Ouvertes). J’avoue que je ne savais même pas que cela existait : comme souvent avec ce podcast, que j’écoute essentiellement pour cette raison, j’ai découvert un truc complètement nouveau pour moi.

Vu

  • Je suis un sportif du dimanche, je ne me classe même pas dans la catégorie amateur. Néanmoins, j’essaie de faire de l’exercice régulièrement et surtout correctement, mon objectif est vraiment l’entretien (surtout à mon âge, quand on a passé la quarantaine, c’est important de s’entretenir un minimum !). Bref, même si j’ai des objectifs humbles, j’essaie de faire les exercices correctment pour éviter les blessures et être efficace. Du coup je suis différente chaîne YouTube comme Calisthenicmovement et j’ai bien aimé une de leur dernière vidéo sur ce grand classique que sont les pompes : Everything Wrong With Push-Ups!. J’apprécie leur approche scientifique et les explications qu’ils donnent. Comme quand on fait des choix techniques ou des choix d’architectures, il est important d’avoir des objectifs clairs de ce que l’on souhaite atteindre et optimiser, pour faire les choix appropriés.

Lu

  • Cette semaine je continue mon exploration de Dart. Après avoir récupéré le HS #108 de Linux Magazine , j’en commencé la lecture avec un focus sur Dart.
    • Néanmoins, en dehors du dossier sur Dart, j’ai bien aimé l’article sur les challenges informatiques pour progresser. CodinGame ou Exercism ne sont pas cités (les sites de challenges informatiques sur lesquels je suis), mais il y en a différents autres qui sont cités dont le mystérieux Foobar Challenge de Google auquel on est convié sur invitation seulement si Google estime que vous en êtes digne… Ainsi, sont cités le Projet Euler que je connaissais déjà (j’ai fait quelques problèmes et je dois m’inscrire il y a longtemps même si je n’ai pas été très assidu), Coderbyte, LeetCode et HackerRank.
    • Les sites de ce type sont des outils pour préparer les entretiens d’embauche ou de mission, mais de mon côté je les utilise plutôt pour explorer un nouveau language sur des problèmes suffisamment significatif pour que cela soit intéressant et fun mais suffisamment petits pour que vous puissiez traiter la chose manière discontinue sur votre temps libre. J’apprécie particulièrement Exercism notamment car certaines de vos solutions sont revues par un pair plus expérimenté que vous dans le langage, ce qui vous permet de recevoir des feedbacks et de vous améliorer en produisant du code plus idiosyncratique au langage en question.
  • J’ai trouvé la lecture de cet article très enrichissante. C’est grâce (comme très souvent !) à un tweet de @riduidel que cet article a été porté à mon attention.

    • Les juniors aiment mettre en place des solutions, les seniors aiment résoudre des problèmes

      • C’est cette phrase qui est au centre de la réflexion que développe cet article. J’aime bien ce qui développe l’auteur et qu’au final avec l’expérience on apprend mieux à rationaliser et présenter des choix techniques au management ou au métier de sorte d’être écouté et suivi. Quand on répète qu’apprendre à communiquer est important !
      • En y réfléchissant, je me dis que j’ai dû m’assagir ou du moins perdre mes illusions ou mon fighting spirit, car si j’ai des marottes et des technos/langages que j’aimerais pousser dans un contexte professionnel, je ne me vois pas essayer de les pousser à tout prix, surtout dans les contextes professionnels dans lesquels j’ai évolué et j’évolue actuellement. Après avoir fait beaucoup de TMA et être passé par des rôles d’architecte, je mesure le risque de sortir des standards d’un SI… mais en même temps, j’ai souvent vu faire les mauvais choix techniques parce qu’on ne voulait pas sortir du standard. L’équilibre à trouver est difficile mais parfois sortir du standard, de la norme de l’entreprise c’est pertinent, et parfois pas du tout… le problème c’est que cela demande de réfléchir à la question et de traiter chaque cas comme un cas particulier et que souvent on est dans l’urgence pour décider et on se repose sur des normes édictées qui peuvent elles-mêmes être dépassées. C’est une raison pour lesquelles j’apprécie particulièrement les ADR : lorsque l’on prend une décision on devrait toujours être explicite et avoir conscience du contexte de cette décision et des conséquences positives et négatives de cette décision. Les contextes changent et l’impact des décisions et choix changent également avec eux. Il faut pouvoir se réajuster.
      • Je trouve qu’il est également intéressant d’aborder cet article sous l’angle des biais cognitifs.
      • Bref, cet article m’a fait réfléchir et j’en recommande chaudement la lecture.

Sur mes radars