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.

On a rencontré une anomalie qui nous a donné du fil à retordre fin mars. J’ai envie de raconter cette histoire parce que je trouve intéressant de partager certains éléments que j’utilise pour m’aider dans ces situations. Je vais essayer de ne pas donner trop de détails futiles. Tout commence lorsque notre PO, vient nous voir pour nous montrer un problème avec la liste des offres mises en favoris. Pour une catégorie d’offre en particulier, l’icône favori n’est pas dans le bon état.

On est entouré de principes, de lois, de modèles, de méthodes et d’un tas d’autres concepts. C’est utile pour construire des choses complexes comme des logiciels - on a besoin d’être aidé. Pour autant, je conseille de garder un minimum de recul et de questionnement face à ces grands écrits - ce ne sont pas des vérités absolues en toutes circonstances. Notre cerveau est plus que jamais important. J’aime considérer les principes (& co) comme des guides.

Hier soir me vient une idée sous la douche (ma source intarissable pour l’inspiration). Une idée et une envie : écrire des articles courts. Je divague. Je visualise des tips que je pourrais publier, concis et efficace. Pour partager des trouvailles utiles. Je visualise des petites histoires également. Avec l’envie de raconter des choses courtes, de partager une pensée qui me traverse l’esprit, une réflexion. Le mot brève me vient.

Pour mon premier article de 2023, j’ai envie de parler d’un changement survenu l’année dernière : mon passage d’iOS à Flutter. Mon intention ? Partager mon REX et au passage démystifier quelques légendes. Je trouve intéressant de partager cette expérience parce que je vois qu’il y a encore beaucoup de réticences à passer d’une technologie mobile native (un développeur écrit directement du « code iOS » ou du « code Android ») à une technologie cross-plateform (un développeur écrit « un seul code » qui permettra d’avoir à la fois une application Android et iOS).

Je n’ai pas publié depuis quelques mois. Je pourrais me dire “je n’ai pas eu le temps”. Mais, est-ce vraiment un manque de temps ? Je l’ai ce temps. D’ailleurs, on a tous le même temps - 7 jours dans la semaine, 24 heures dans la journée, 60 minutes dans l’heure. C’est invariable¹. Pourtant, on entend et utilise souvent cette excuse, “je n’ai pas le temps”. Une affirmation incorrecte, qui ne veut pas dire grand-chose.

Nul besoin d’avoir un passé de développeur, ou de savoir coder. Mon intention ici est de faire découvrir des pratiques tech reconnues dans l’industrie. C’est un sujet que je souhaite rendre accessible à tous, que l’on soit tech ou non, pour améliorer le quotidien des équipes, devenir meilleur dans la technique et dans le business. J’ai été invité par Fleur Saillofest à speaker dans le meetup Beyond Scrum Mastering. Très rapidement, une trame intéressante a émergé lors de nos échanges : celle de reconnaître des problèmes au sein de l’équipe et y associer certaines pratiques tech qui pourraient aider.

Un développeur a-t-il besoin d’une permission pour écrire des tests ? Pratiquer le Test-Driven Development ? Faire du refactoring ? Travailler en Pair Programming ? Faut-il un permis à l’image de la légendaire licence to kill de James Bond ? Ma réponse est NON (sans surprise, comme la plupart des articles qui commencent avec une grande question fermée). Un développeur doit être autonome et décider de lui-même pour ce genre de pratiques.