Interview de Yohann Gabory, lead développeur backend

Bluecoders
bluecoders
Published in
4 min readJun 26, 2018

Alban Launay, coach Node.js chez Bluecoders a interviewé Yohann Gabory, après avoir réalisé un talk chez Bluecoders avec la communauté PostgreSQL.

Yohann est lead développeur Python Django, il a découvert le PostgreSQL il y a peu de temps et il a adoré, il nous raconte comment il l’utilise et pourquoi il le conseille. En plus il donne de très bons conseils pour faire que les équipes commerciales et techniques s’entendent mieux.

Alban — Bonsoir Yohann et merci d’être là ce soir. Pourrais-tu te présenter ?

Yohann — Je m’appelle Yohann Gabory, je suis développeur Python-Django depuis une dizaine d’années. J’ai fait pas mal de boîtes différentes, surtout des startups. Aujourd’hui je travaille pour Kosk Telecom, un opérateur télécom qui vend de la fibre et du cuivre aux entreprises qui l’utilisent, et tout en python et Django comme je disais.

Alban — Du coup dans ta présentation, tu avais un message à faire passer, lequel est-ce ?

Yohann— Le message que j’essaie de faire passer c’est que durant mon expérience, je me suis longtemps limité à Python et Django, je ne me suis pas trop préoccupé de ce qui s’est passé ailleurs, alors bien sûr j’ai suivi un peu la tendance en faisant du Javascript, un peu de front end mais sans me préoccuper de la base de données.

Et en fait, je m’aperçois aujourd’hui que la base de données et le code en base de données, le SQL, peut résoudre énormément de problèmes et en particulier des problèmes qui sont extrêmement difficiles et spécialement en Django 7 Python, ou quel que soit le langage de back end que vous faites.

Du coup le message c’est de ne pas avoir peur à PostgreSQL, il faut peut-être commencer par une petite dose, observer un petit peu ce qu’il se passe, regarder comment est-ce qu’on peut faire, des contraintes un peu malines, peut-être des petites rigueurs qui peuvent être remplacées quelques codes un peu difficiles. Et après ça vient tout seul.

Le deuxième message c’est que ce code SQL ne doit pas être caché au fond de la base de données, ni caché aux yeux des autres développeurs. Au contraire, il doit être visible, dans ton git, quelque chose que tu dois traiter, commenter, que tu dois pouvoir modifier, exactement comme les autres langages.

Alban — Quand est-ce que tu as eu le déclic ?

Yohann — Au premier meetup : en fait, j’ai absolument rien compris, les gens parlaient de choses qui m’étaient complètement étrangères, mais la bière était bonne du coup j’y suis retourné.

Au bout de 2 ou 3 fois, il y avait des petits bouts que je commençais à comprendre, et puis, au fur et à mesure, non seulement j’arrivais à les comprendre mais en plus, ça répondait à des problématiques que je rencontrais au travail. Par la suite, j’ai un petit peu “geeké” chez moi sur des projets perso, pour voir si ça pouvait vraiment fonctionner, si ça pouvait s’adapter.

J’avais la chance de travailler déjà avec PostgreSQL depuis 10 ans, mais en vrai ça fait 2 ans que je m’en sers réellement comme elle peut être utilisée, que je vois ses progressions, tout ce que je peux faire de nouveau en SQL. C’est une base qui s’approche vraiment aux développeurs, parce que nous pouvons faire du no SQL, du dénormalisé, et c’est plutôt assez sympa.

Maintenant mon but c’est de faire partager ça, de montrer aux gens que c’est possible. Et parfois ça ne marche plutôt pas mal, il y a des juniors qui arrivent à faire du python vraiment sympa et du SQL au bout de quelques mois.

Alban — D’accord, tu es peu évangélisateur. J’ai une question qui a un moins de rapport, mais je pense que dans beaucoup boîtes c’est le cas : il y a souvent une petite tension entre la partie dev et la partie commerciale, peut-être à cause de l’incompréhension. Et sachant qu’une meilleure collaboration permettrait une meilleure réussite, aurais-tu un petit conseil à leur donner à une partie ou l’autre ?

Yohann — Je vais faire un parallèle entre le DBA et le dev, et puis le développeur et le commercial car c’est un peu la même chose, ils n’ont pas forcément envie de se parler alors qu’ils ont énormément à s’apporter mais ne s’en rendent pas forcément compte. Ce qu’il faut, c’est que l’un des deux aille vers l’autre, il faut tout simplement discuter, dialoguer, échanger, essayer de comprendre le métier de l’autre, et quand tu essaies de comprendre le métier de l’autre tu comprends mieux le tien.

En tant que développeur tu vas voir un commercial, tu vas discuter un peu avec lui, et là, tu vas te rendre compte que le truc pour lequel vous êtes en train de vous arracher les cheveux, que ce n’est pas livré au bout de trois mois et qu’il n’en peut plus, en fait ce n’est pas ça dont il a besoin réellement, lui, il veut un petit truc que tu pourrais lui faire rapidement qui le ferait sauver 1 ou 2 clients.

Juste au passage, le commercial est celui qui me donne à manger, sans lui, mon code ne vaut rien, c’est lui qui le vend.

Cette interaction-là, c’est ce qui va faire avancer les choses. Alors, je peux recommander aux développeurs d’aller voir leurs commerciaux et je conseille aussi aux commerciaux de s’intéresser au métier des développeurs, leurs problématiques, comment eux ils travaillent.

Et tout se passe beaucoup mieux quand on comprend le travail de l’autre.

Alban — Bah écoute, merci beaucoup, je ne sais pas si tu as un dernier message à faire passer ?

Yohann — Prenez du plaisir, dans tout ce que vous faites.

Alban — Merci beaucoup Yohann et je te dis à bientôt !

Abonnez-vous sur notre groupe meetup pour ne pas rater les prochains évènements.

Rendez-vous sur Bluecoders si vous souhaitez bénéficier d’un accompagnement personnalisé auprès d’un coach spécialisé sur une techno !

--

--