Le Développeur Full Stack n’existe pas

WTF !? Quel est le problème

Le problème prend deux formes. La plus évidente :

 

Full stack se positionne pas loin de Growth Hacker et Business Developer dans le bestiaire startup. Au dessus, vous retrouvez une compilation de posts venant de facebook et de jobboard startups.

Vous remarquerez que l’on trouve plein de choses avec Full Stack, JS, PHP, Stage, Sénior, Swift, Prestashop, RoR et Python, RWD.responsive. Le dernier est un peu wtf, mais c’est un cas extrême. On a pas encore bien compris.

Symétriquement, tous les développeurs juniors sont full stack. Faute de spécialisation et d’expertise, on est toujours FullStack !

Full stack n’est pas fondamentalement mal, le problème c’est quand Fullstack a le même sens que « Homme à tout faire qui sait coder ». On a personne dans l’équipe aujourd’hui, du coup on a besoin d’un Full stack !

Le but n’est pas de tirer sur l’ambulance.
Sur WeLoveDevs.com aussi on trouve des postes de « Développeur Full stack ».
Mais il faut bien comprendre que ma démarche ici, c’est d’aider nos utilisateurs à se distinguer. Quand vous êtes sur un site à audience large, comme Indeed ou Monster, une annonce pour un développeur Full stack ça se distingue de la fiche de poste pour caissier, chauffeur de bus ou même celle du planneur stratégique. Mais sur un site spécialisé comme le nôtre, il faut être plus précis, au risque de ne pas se distinguer.
S’il y a déjà 3 annonces de dev Full stack, vous êtes là 4e, est-ce qu’elle va cliquer ?

Dans le fond c’est quoi un Full stack ?

On retrouve souvent plusieurs assertions :

« C’est un dev qui fait du Front et du Back »

On a le droit à des schemas du style :

Ou encore, sur une fiche métier trouvée sur un jobboard :

Il est capable de travailler avec le Product Manager, le designer, les ops, … un véritable couteau suisse !

On a même vu le terme de Full stack Marketeur utilisé par des gens qui touchent à tout en terme de Marketing. Une forme de parallèle à la com360.

 

Full stack n’est pas une compétence

Un développeur qui travaille dans un environnement MeteorJS/React et maitrise les deux compétences est dit “Full stack”.
Ce développeur change de métier et rejoins une entreprise où l’existant est principalement en DotNet, mais on cherchait des gens qui font des choses avec React. Et dans ce contexte, il n’est plus Full stack.
Full stack n’est pas un attribut qui suit le développeur mais qui dépend de son environnement de travail.

Pourquoi tu n’es pas un Full stack Developer

Maitriser correctement toutes ces technos, ça demande d’une part beaucoup de séniorité, mais également beaucoup d’entrainement. Faire des requêtes SQL complexes, réfléchir à des solutions de fragmentation horizontale à base d’algèbre relationnelle, il faut pratiquer tous les jours, sinon quand on s’y remet ça pique (c’est pas du vélo !). Faire du Flexbox, du CSS, de l’intégration, même combat.
Les journées ne durent que 24h et on ne peut pas maintenir un niveau d’expertise aussi bien sur Ansible, React Native et MongoDb et Asterisk dans la même journée.

Pourquoi tu ne dois pas embaucher de Full stack Developer

Si jamais un tel développeur existait :
– Il serait tellement rare que ça prendrait un 5 à 10 ans pour le trouver
– Il serait tellement demandé que Google/Facebook lui proposeront 80K de prime à l’embauche et il serait très dispendieux

Je vous propose d’en lire plus ici, ça parle du mythe du dev qui est 10x plus productif que les autres. C’est un cousin du Dev Full stack.

 

Il y a bien des gens qui aiment toucher à tout !

Oui ! Et c’est important de sortir de sa zone de confort, cela nous permet d’apprendre plein de choses. Ce n’est pas parce que ta zone de confort c’est le back, qu’il faut refuser de faire de l’intégration.
Il y a aussi des développeurs qui aiment faire du Haskell, mais aussi du Javascript ou du Python. On peut avoir fait du Rails pendant des années et trouver agréable de faire une implémentation avec Django ou même avec Play framework !

Ich bin Polyglotte

On a vu ça dans plusieurs postes décrire le profil des candidats comme « plus ou moins » polyglottes. Et ça c’est plutôt clair. Cela désigne quelqu’un qui n’a pas envie de s’enfermer dans une techno ou dans un environnement.

Full stack est une posture

Dans une gestion de projet agile, un développeur, Romain, doit pouvoir prendre une User Story et l’amener jusqu’à l’état Done. Si l’état « Done » correspond à « Déployé en production », on pourra peut-être même parler de DevOps. Cela signifie que Romain doit être capable d’agir sur tous les tiers de l’infrastructure. Si le gros de la fonctionnalité est vertical sur une architecture client-serveur, avec un client en Qt et un serveur en Node.

C’est à ce moment que Romain devra intervenir sur les deux tiers.

Et pourtant, Romain n’a pas besoin d’être un expert sur les deux technologies pour développer la fonctionnalité.

Romain n’a pas besoin de le faire seul !
Il peut demander de l’aide à un collaborateur. Peut-être que pour chaque Tiers, un référent est désigné, il a la responsabilité du tiers et il pourra aider Romain à implémenter sa fonctionnalité avec assurance, dans une démarche qualitative.

Romain va apprendre en cours de route. J’ai appris pas mal de choses sur Spring et JPA quand je faisais de l’iOS chez Tripndrive. Parce que Nicolas et Léo étaient très cool, ils m’ont appris beaucoup de choses et leur code était particulièrement clair et compréhensible, je pouvais le comprendre et le reprendre rapidement. Mais clairement dès que ça devenait un peu trop compliqué, je demandais de l’aide. Ne me demandez pas de poser un Spring à partir de 0. Je n’utiliserais pas spontanément Spring pour résoudre un problème. Bref, en un mot : Je n’ajouterai pas Spring en compétence sur Linkedin (Par contre, tu peux me recommander pour ma compétence en ? > Seriously).

Bref, apprendre c’est cool ?

Développeurs, apprendre est notre métier
C’est une chose passionnante dans notre métier. Depuis que j’ai commencé à étudier, j’ai l’impression de n’avoir jamais…

En un mot, Full stack, c’est pas un état, mais une posture. C’est le fait d’être prêt à apprendre, prêt à rentrer dans n’importe quel code pour livrer une feature.

Un poste peut être Full stack ?

C’est pour ça qu’il y a une différence entre « Poste de développeur Full stack » et « je cherche un dev full stack ». Dans une annonce, on peut utiliser Full stack pour décrire l’auto-organisation de l’équipe.
« Tous les membres de l’équipe sont Full stack, et vous le serez aussi ! » ✅
Mais ce n’est pas approprié pour donner les pré-requis d’un candidat.
« Le candidat idéal est full stack » ⛔️

 

Dans une annonce, il faudra donc prioriser :
① Le PoC a été fait avec PHP, on va rester sur cette techno
② Symfony est une bonne idée, avoir une première expérience sur ce framework c’est mieux.
③ On déploie avec Docker, si vous avez des expériences sur ce sujet, c’est encore mieux.
④ Notre traffic est très mobile, avoir une bonne maitrise de flexbox, media query et des bonnes notions en RWD, c’est très apprécié. On a pas d’outils de type Bootstrap ou Foundation en place, mais ça peut être une bonne idée.
⑤ On voudrait faire une WebApp sur certaines parties, avoir une expérience sur VueJS c’est une bonne idée ! (Ou React, ou Angular)

Pour le candidat, ça veut dire que même si on est particulièrement passionné par le front, on peut être intéressé et postuler à un poste Full stack.

Comment on Scale en Full stack ?

Dans la Startup-Nation, on se pose toujours la question : « Mais comment ça Scale ? ».

C’est un vrai sujet en fait. C’est très agréable de pouvoir travailler dans ce type d’environnement. Par contre, il y a toujours un moment où ne peut plus tout faire. C’est important de bien être clair sur le cadre, le périmètre, la notion de « Done ». Par exemple, certaines équipes expliquent clairement que le front est accessoire, Bootstrap ou un UIKit suffisent pour le moment.

Rapidement, on voit des formes de cloisonnement arriver. LA séparation entre Dev et Build&Run est historiquement la plus répandue ! « Done » devient « ça marche sur ma machine » pour l’équipe Dev. Et l’équipe Build&Run est en mode pompier. Est-ce que quelqu’un a mentionné le MCO ?

Très couramment on voit chez les éditeurs des cloisonnements par tiers. Une équipe est responsable d’une API, de son Dev/Build/Run. L’autre est responsable du backoffice. On a également la team qui fait l’appli iOS dans la pièce à coté. Au moins, le paradigme DevOps est encore là. Mais souvent, on voit apparaitre des couches de managements qui viennent spécifier les interfaces entre les équipes. Ainsi que des intégrateurs qui vont venir assembler les briques pour envoyer chez le client.

Enfin, les Craftmans prôneront les features teams et la mise en place de tribus transversales. Les Features teams sont hétéroclites. On n’y trouve rarement deux profils similaires. Pourtant chaque individu, le SysAdmin barbu par exemple, fera parti d’une tribu de SysAdmin qui va se mentorer et le stimuler pour être le meilleur dans cette verticale.

L’outillage est aussi une partie de la solution. Pas les moyens d’investir dans une équipe DevOps / Build&Run ? Est-ce que Clever Cloud peut résoudre le problème ? (met le PaaS que tu veux à la Plaas)
On va pas recoder un système de facturation, on prend ce bon vieux Stripe !
Est-ce que Zapier peut faire le job pour ça ?
Intégrer des formulaires c’est relou, on peut pas s’en sortir avec Typeform ?
J’ai mentionné Asterisk plus tôt, mais c’est évident que tu devrais utiliser Twilio.

Les outils coûtent de l’argent, mais permettent aux humains de se concentrer sur le métier et créer de la valeur pour les utilisateurs. ?

Bref, au final, tout le monde peut être Full stack ?

Cet article a été publié en 2017 sur Medium, le lien est ici.