Le terminal, c’est une sorte de couteau suisse pour les développeurs. Il permet de faire énormément de choses - presque tout d’ailleurs - et on s’en sert très souvent. Alors quand le temps de lancement du terminal s’allonge, je ne vous cache pas que c’est très embêtant. C’était mon cas avec iTerm2 + oh-my-zsh, et on va voir comment trouver les problèmes à la source. Identifier les causes Je n’ai pas forcément fait attention au moment exact où mon terminal a commencé à être capricieux pour se lancer.

De nos jours, il est rare de trouver une application qui ne communique pas du tout avec l’extérieur. La majorité des applications que l’on utilise font des requêtes vers un ou plusieurs serveurs - pour demander des données, les afficher dynamiquement, et pour en envoyer. J’ai fait le test avec mon téléphone, j’ai eu du mal à trouver une application qui ne faisait aucune requête (en tout cas en apparence, je n’en suis même pas sûr à 100%).

Je suis dans une équipe qui travaille souvent à distance, et pourtant, j’ai la sensation d’avoir mes collègues à côté de moi. Cette petite tape sur l’épaule venant d’une personne qui passe dans les bureaux pour demander de l’aide ou discuter, vous voyez ? Eh bien, je l’ai même quand je suis seul à mon domicile, et je ne suis pas fou - enfin, pas complètement ;). Pour poser un peu de contexte, nous sommes une vingtaine dans l’équipe, composés de multiples profils (tech, produit, terrain, design, …).

Et s’il suffisait de passer à non un paramètre pour désactiver une fonctionnalité qui pose problème en prod ? Ou de changer un chiffre pour modifier le nombre d’éléments de la page d’accueil d’une application mobile ? Sans avoir à modifier du code et sans passer par la case déploiement bien entendu, parce qu’on a envie d’agir rapidement. On pourrait simplement changer des valeurs sur une interface web par exemple.

Simple, compliqué, complexe, chaos. Et si on déterminait dans lequel de ces lieux se situe une user story, une epic, une idée ? Ça ouvrirait des discussions et des questions très intéressantes pour que l’équipe s’adapte - elle n’a pas besoin de traiter les stories tout le temps de la même manière. Je pense par exemple au flux que la story doit traverser, aux process, aux pratiques tech et produit, à la façon de communiquer et de collaborer, etc.

Le monde est changeant et incertain, et les applications mobiles ne sont pas épargnées. On a un besoin de s’adapter rapidement. Parce qu’on veut expérimenter en production, pour réagir à une nouvelle fonctionnalité provoque des crashs, pour intégrer continuellement, ou parce qu’on s’est planté sur une hypothèse. On a cependant deux barrières de taille au changement rapide dans le développement mobile : les stores (App Store et Google Play), et les utilisateurs.

En ce moment, j’essaie d’aider des collègues à créer du contenu qu’ils partageraient ensuite. Article, talk, podcast, vidéo, … peu importe le format. L’intention est de se lancer et de casser quelques croyances limitantes. Les histoires sont en nous, et on en a tous à raconter. Alors allons en chercher quelques-unes. Des croyances limitantes Quand on se lance dans l’aventure, on peut rencontrer ses premières embûches assez tôt. Ici, ces sont les croyances limitantes qui peuvent nous empêcher de démarrer.

Je considère mon blog comme un journal imparfait qui m’aide pour réfléchir et à travers lequel je souhaite aussi partager mes expériences. L’essentiel est dit dans cette phrase. Je vais un peu la décomposer. Lorsque j’ai créé ce blog, je voulais un espace personnel d’expression. J’avais envie d’écrire ce qui me venait à l’esprit, faire de l’introspection, et partager des histoires. Je ne voulais pas faire un site web pour parler d’actualités technologiques, ni pour faire des tutoriels ou décortiquer dans les moindres détails une techno / langage.

Ruby, Python, Rust, Node.js, Flutter, … Comme tout objet dans le monde, les langages, frameworks et outils sont amenés à changer avec le temps. Version mineur par-ci, version majeure par-là. Comment jongler facilement entre les versions ? Quand on est développeur, on utilise tout un tas d’outils et de SDK. Parfois sur plusieurs projets, qui utilisent des versions différentes bien évidemment. Je peux avoir besoin de Node.js 19 pour le front web et de Node.

Récemment, mon prof de guitare me disait « T’inquiètes pas, à force de pratiquer, de nouvelles connexions vont se créer dans ton cerveau. Elles seront de plus en plus nombreuses, rapides, et ça deviendra automatique ». Je suis en phase, et ça m’a inspiré pour écrire sur l’apprentissage. Aujourd’hui, je réfléchis encore beaucoup pour jouer de la guitare. Pour ce nouvel accord, je dois mettre mon doigt 3 sur la corde 1 en case 3 + le doigt 2 sur la corde 2 en case 2 + le doigt 4 sur la corde de 6 en case 3.