Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec Nicolas Vérinot, Nicolas bonjour.
Salut Benoît.
Écoute, c'est intéressant parce que dans la préparation de cet épisode,
tu me disais que tu avais envie de sortir un petit peu de ta casquette iOS Swift,
que tu vivais comme un carcan.
C'est curieux d'en savoir un petit peu plus.
Qu'est-ce que tu entends par là ?
En fait, j'ai envie d'élargir mes horizons en étant capable de proposer des solutions logicielles complètes,
donc de l'idée qu'un client peut avoir jusqu'à la réalisation de ce logiciel
et de pouvoir choisir les technologies et les techniques, les langages qui vont bien
par rapport au problème que je suis amené à résoudre.
Aujourd'hui je suis spécialisé à iOS, donc on me fait appel à moi uniquement pour ça
et ça m'emmette un peu parce que moi ce qui m'intéresse, c'est le spectre global
d'un problème donné et d'une solution à trouver.
Et voilà, c'est pour ça que j'ai un petit peu envie de sortir de cette spécialisation-là.
Pour aller un petit peu plus loin, il y a un super article de Jean-Baptiste Dussault
qui est sorti en août 2017, donc il y a déjà un petit peu un an.
Il s'appelle de l'État du marché du développement et il parle notamment de différents profils
de développeurs et notamment de l'expert local.
L'expert local, c'est justement la personne qui va se donner une expertise
et qui va bosser que dans une seule techno sur une seule plateforme,
par exemple développeur.net ou développeur iOS en suive,
et qui va faire ça pendant 40 ans et qui va être un petit peu l'expert.
Et finalement, en ayant ce type de profil-là,
on aura tendance à apprendre les problèmes qu'on nous soumet
et à les faire rentrer un petit peu aux choses pieds dans ce qu'on sait faire.
Et ça, ça ne me plaît pas trop.
En même temps, je pourrais t'opposer à deux choses.
Je pourrais t'opposer d'abord qu'à un point de vue business,
dire je suis développeur Swift à US,
je pense que c'est beaucoup plus incisif, percutant que dire je fais des apps
qui a été mon positionnement pendant quelques années.
Je me rends compte que c'est complètement contre-intuitif,
mais plus on se spécialise et plus le discours passe,
mieux c'est compris et plus c'est facile.
Déjà, tu trouves du travail plus facilement.
Quand tu vas élargir, tu vas forcément diluer ton positionnement
et ce sera moins évident, trouver du taf, non ?
Oui, clairement.
C'est la réalité du marché aujourd'hui.
Est-ce que c'est une bonne chose ?
Je ne pense pas.
Je suis un peu contre ce phénomène-là
qui finalement s'alimente lui-même,
qui est de dire j'ai commencé à développer mon soft
en Java, donc j'ai besoin automatiquement de développeurs Java.
Par contre, par rapport au problème donné,
au problème que j'ai aujourd'hui, au problème que j'aurai demain,
peut-être que Java ce n'est pas la technique qui est plus adaptée,
ou alors on peut aller un peu plus loin avec certains frameworks,
comme Ruby on Rails, par exemple, que tu affectionnes.
Ce n'est pas forcément la technique la plus adaptée
pour répondre à certaines problématiques.
Bien sûr que si, Ruby on Rails résout tous les problèmes.
Oui, c'est évident.
Oui, c'est ce qu'on appelle le syndrome du marteau.
Quand tu as un marteau, tous les problèmes ressemblent à la déclou.
Oui, c'est ça.
J'ai un peu envie de faire bouger les lignes à ce niveau-là.
Est-ce que je vais y arriver ?
Je ne sais pas, pas tout seul en tout cas,
mais je sais qu'on est plusieurs à penser comme ça,
qui est de dire aujourd'hui,
les clients n'ont pas besoin de développeurs Rails,
ils ont besoin de trouver des solutions à leurs problèmes.
Et malheureusement, ils s'enferment dans des technologies,
et ça fait que forcément, ils m'ont recherché dans ces technologies.
Et du coup, les développeurs vont devoir adapter leur offre à ça,
puisqu'il y a de la demande dans ces techniques,
donc on va créer des profils spécialisés dans ces techniques-là.
Alors que le fond du problème,
ce n'est pas ça, le fond du problème,
c'est faire des bons logiciels en mettant les bonnes techniques
en face des bons problèmes.
Et voilà, et ça se tôt alimente,
parce que moi, en tant que client,
je n'y connais rien en logiciel,
et j'ai besoin de...
je sais que un logiciel peut m'aider dans mon boulot,
peut améliorer la productivité,
peut m'apporter une valeur,
peut apporter de la valeur,
faire du business.
Donc je vais faire appel à une société de services,
par exemple, voire des frilances,
qui vont eux me proposer ce qu'ils savent faire,
par rapport à mon problème.
Et là, le cercle va commencer à se créer,
où j'ai une première société
qui va me faire un logiciel imaginant Rails.
Du coup, comme je vais avoir de l'investissement
dans ce logiciel en Rails,
je vais devoir chercher après une autre société
qui fait du Rails,
d'autres développeurs qui font du Rails,
si je veux changer un petit peu de prestataire,
ou si je vais recruter en interne.
Et du coup, je vais rester enfermé dans Ruby on Rails,
alors que pour certains problèmes donnés,
peut-être que ce n'est pas la meilleure technique,
mais la meilleure approche.
Et après, ça marche à tous les niveaux, ça.
Pour des petites boîtes.
Oui, mais là, tu parles en guerre
contre juste la manière dans le marché,
ce truc-là.
Exactement.
Je pense que c'est...
C'est...
Oui, oui, non.
Après, il faut des gens audacieux
pour changer les choses.
Et jusqu'au plus bas, alors qu'elle est limite,
parce que si tu regardes bien moins,
j'ai une théorie,
que je questionne en ce moment.
Tu vois, je me pose beaucoup de questions.
Pendant longtemps,
j'ai pensé que c'était une mauvaise chose
de s'éparpiller sur plusieurs techno.
D'où moi le choix d'avoir concentré mon énergie
ces dernières années sur Infraimwork.
Parce que je pense que justement,
l'expertise sur Infraimwork
vient à cette concession
de réduire un peu le scope de techno concours.
À côté de ça, j'ai essayé,
puisque d'acquirer ces compétences,
d'aller chercher dans les compétences,
d'agréger des compétences.
Et finalement, à un moment donné,
il faut mettre une barrière,
il faut mettre une limite.
Tu vois, typiquement,
on a cherché pendant quelque temps
jusqu'au moment où on allait sur le X-Design.
Est-ce que c'était une prestation qu'on fournissait ?
Est-ce que c'était quelque chose qu'on allait chercher ?
Même question sur un sujet aujourd'hui
qui m'intéresse beaucoup,
sur lequel je ne suis pas compétent,
mais où j'aimerais le devenir,
tout ce qui touche à l'intelligence artificielle.
Il y a toujours une frontière, en fait.
Dans le champ de compétences que tu peux acquérir,
tu peux difficilement être expert
de deux langages, de deux frameworks mobiles,
d'un framework web, d'un framework d'IA,
de...
Où tu mets la barrière ?
Tu mets la barrière sur
ta capacité d'apprendre les bonnes technologies
au bout-moment, je dirais.
Après,
j'en avise assez tranché sur la question
qui est de dire que, finalement,
au niveau des compétences de Dev,
ce qui est le plus dur à apprendre,
ce n'est pas le langage,
ce n'est pas le framework,
parce que ça, ça évolue
et ça change régulièrement.
Je veux dire, tous les 5-10 ans,
voire même moins,
il y a des nouveaux langages qui sortent
et des nouvelles tendances.
Donc ça, c'est...
Enfin, à mon sens,
ça peut s'apprendre relativement facilement,
il y a pas mal de ressources,
ce serait ce que la documentation est guide officielle.
Par contre, ce qui est long à apprendre,
c'est
trouver le bon problème du client.
C'est créer un logiciel
dont le client a vraiment besoin,
les utilisateurs finons ont vraiment besoin.
Donc pour moi, ça fait sens,
cette partie UX Design,
parce qu'il y a cette partie conversation
avec l'utilisateur qui est fondamentale.
Il y a aussi tout ce qui est
bonne pratique de développement,
savoir créer un logiciel
qui soit à la fois suffisant
pour le problème au JORGY
et facilement évolutif
pour demain,
pour ne pas se fermer des portes demain.
Plus, après, il y a la tendance
des microservices,
mais là on digressera un petit peu,
mais on va choisir
la bonne techno pour le bon sou problème.
Et ce genre de choses-là.
Je valorise beaucoup plus
les compétences transverses
comme créer un logiciel robuste
et évolutif,
notamment par la pratique du TDD
et du Père pour Aming,
plus que la maîtrise
de telle ou telle langage.
A titre d'exemple,
je suis passé de l'objectif C
au C-Sharp avec Xamarin
dans la première boîte
dans laquelle j'étais.
Ça devait être en 2012,
si je dis pas de bêtises,
ou 2013.
J'ai mis à peu près 5 jours
à apprendre de C-Sharp
et quelques jours à apprendre
de framework,
framework Xamarin,
les petites choses,
les petites particularités du framework.
C'était relativement rapide.
Pareil qu'en appel à sortie Swift,
j'ai mis deux jours
à apprendre Swift
en venant de l'objectif C et du C-Sharp.
C'est quand même des choses
où ça s'apprend plutôt vite,
plutôt facilement.
Donc voilà, je vois pas trop le...
Je préfère
demain recruter
un bon développeur C-Sharp
qui sait pratiquer du TDD,
qui a une
une grande sensibilité business et client
pour faire du Swift, par exemple,
plutôt que de recruter un développeur Swift
qui est complètement expert
dans sa techno et qui veut surtout pas en sortir.
Je bois tes paroles avec
beaucoup de plaisir
et je te propose que ce soit le mot de la femme.
Merci d'être venu.
Ça marche, merci à toi.
Si les auditeurs ont envie d'en savoir plus,
ils peuvent venir ou ?
Alors il y a le site de ma société,
il s'appelle RIFACTO,
donc RIFACTO.fr
et sinon, on est sur les réseaux sociaux,
LinkedIn et Twitter, principalement.
Qu'en t'as-tu à toi, chère auditeur ?
Écoute, l'occasion est trop belle
de mettre en avant la formation
qui vient de sortir, qui s'appelle...
Je sais pas encore comment elle s'appelle
en fait, au moment où j'enregistre le podcast,
mais ce qui est sûr, c'est comment,
où ça sera diffusé ?
Elle sera dans les bacs
et c'est justement...
On parle de ça, on parle de comment
acquérir des compétences profondes
et notamment dans comment structurer son code,
comment éviter d'en faire une espèce
de grande boule de boue
et comment arriver à avoir quelque chose
de souple et d'agréable pour travailler au quotidien.
C'est dans la Maison des artisans,
sur maison.artisanddeveloper.fr.
Je te dis à demain.