Hello there
Juriste devenu développeur Rails, je note ici ce que j'apprends, ce qui me surprend, et parfois ce que je n'ai pas encore compris.

Je m'appelle Thomas, je suis développeur Ruby on Rails. Ici, je note ce que j'apprends, ce qui me surprend, et parfois ce que je n'ai pas encore compris.
Avant ça, un mot sur mon parcours qui explique le ton de ces notes.
D'un code à l'autre
J'ai d'abord fait du droit, qui mène à tout1, jusqu'à un M2 en propriété industrielle. L'entrepreneuriat remplissait déjà mes listes de lecture, alors j'ai enchaîné avec un mastère spécialisé à l'EMLyon, puis deux ans à Tel-Aviv. J'y aidais des entreprises et des startups françaises à protéger ce qu'elles inventaient, en pleine start-up nation. J'y ai vu la frénésie entrepreneuriale, et l'unfair advantage de ceux qui savent coder.
1 La preuve : un de mes meilleurs amis de M2 est aujourd'hui rédacteur en chef adjoint de Charlie Hebdo.
En fin de mission, mon meilleur ami, product manager, m'a parlé du Wagon. J'ai alors compris ce qui me frustrait : un impact trop peu concret, et une carrière trop balisée. Je m'y suis inscrit pour devenir product manager chez Doctrine. J'ai finalement adoré construire des produits de mes mains, et décroché un premier poste de développeur.
Après un passage formateur à la Mairie de Paris2, j'ai rejoint Getaround, une marketplace de location de voitures présente dans plusieurs pays. J'y ai trouvé une équipe talentueuse, ambitieuse et bienveillante (un mot souvent galvaudé, mais ici les gens le sont vraiment). À la fois développeur et manager de trois développeurs seniors, j'ai vécu l'intégration de l'app américaine dans notre monolithe Rails européen, et mené l'import des voitures de leur base vers la nôtre. Puis Getaround a fermé ses opérations aux États-Unis, s'est recentré sur l'Europe et est devenu rentable 🎉. Je suis redevenu développeur à plein temps, au moment où les LLM fracassaient nos habitudes de travail.
2 Oui, paris.fr tourne sur Ruby on Rails.
Le soir, quand ma femme et mon fils dorment, je continue d'apprendre et de construire, pour progresser techniquement et pour tester les idées qui me passent par la tête3. Le reste du temps, je joue au tennis, je lis de l'histoire et je regarde du foot.
3 J'en reparlerai sûrement.
Pourquoi écrire
Pour trois raisons, plus égoïstes qu'elles n'en ont l'air.
D'abord, pour partager. Mon profil mélange trois métiers : le droit, le produit et le code. Je ne suis ni ingénieur ni manager de formation. J'apporte un recul business et un product mindset, et pour la technique, j'apprends à l'envers, du langage de haut niveau vers les fondamentaux de l'informatique, pour rejoindre des collègues sortis d'écoles d'ingénieurs. J'expérimente, je fais de la veille, et j'accompagne volontiers des développeurs juniors, souvent passés par un bootcamp comme moi4. Ce que je découvre en chemin peut servir à d'autres.
4 Un exemple ici.
Ensuite, pour éviter de refaire les mêmes erreurs. Réexpliquer un problème avec mes mots, c'est vérifier que je l'ai compris ; quand je n'y arrive pas, je sais ce qu'il me reste à apprendre. Et le jour où je retomberai sur la même race condition ou le même bug de fuseau horaire, la réponse sera déjà là.
Enfin, pour cultiver ma communication, par déformation professionnelle : le droit m'a appris le poids de l'écrit. Bien écrire facilite le travail avec mes collègues, et désormais avec l'IA : meilleur est l'input, meilleur est l'output5.
5 Garbage in, garbage out : avec une consigne floue, l'IA rend une réponse médiocre.
Ce que vous trouverez ici
Des notes, rangées par thèmes :
- l'ingénierie : Rails, les bases de données, l'art de garder un logiciel simple, et les fondamentaux d'informatique découverts sur le tard ;
- l'IA telle que je l'utilise vraiment, pour mieux travailler et pour construire des fonctionnalités d'un nouveau genre ;
- le produit, avec l'utilisateur final comme boussole ;
- mes expériences ;
- et quelques réflexions qui ne rentrent nulle part ailleurs.
Pas de rythme promis. J'écrirai quand j'aurai quelque chose à dire. C'est une promesse plus facile à tenir.
Et si vous avez l'œil, regardez le bureau autour de la feuille (sur grand écran). Le canard de debug change de tenue selon la saison, et met son bonnet de nuit en mode sombre. Il écoute tous mes problèmes sans juger, et m'oblige à les expliquer simplement. C'est mon binôme le plus fidèle, et il ne consomme aucun token.
Merci d'avoir pris le temps de me lire. Pour me répondre, me contredire ou me signaler une coquille : LinkedIn ou GitHub.