Peut-être que, comme moi, tu es développeur·euse. Développeur·euse web, applicatif lourd, mobile, embarqué, machine learning. Tellement de catégories qui sont plutôt logiques selon nos préférences et affections. Après, il existe aussi les devs front-ent, back-end, iOS, Android, etc. Si on enfonce la pelle un peu plus profondément, on va retrouver ceux-ci:
- Javascript
- Python
- Java
- C#.NET.
- [etc…]
Oui, il existe ce genre de dev. Sauf qu’on aime rarement qu’un seul langage. Personnellement, mon préféré est Python, j’aime beaucoup Ruby et Javascript avec parcimonie. On est tou·te·s comme ça. Rares sont les personnes qui ne connaissent qu’un seul et unique langage, du moins parmi les personnes qui ont suivi un cursus long comme un bac+3 ou un bac+5 et plus. En cours, j’ai appris une liste de languages longue comme le bras: C, Java (+ J2EE & Android), Javascript, PHP, SQL, Swift, NoSQL (Cassandra & MongoDB). On regarde même plus loin avec les cursus universaires ou en Haute-Écoles: design pattern, la programmation orientée objet en long, en large et en travers. Les bases de données avec les triggers, les vues. L’analyse fonctionnelle avec les use cases, user stories, les méthodologies agiles comme Scrum et d’autres un peu dépassées comme Waterfall mais aussi la gestion de projets (un peu en Hautes Écoles) comme la gestion de risques, l’écriture de documentation, UML, etc. Les développeur·euse·s “juniors” qui sortent de l’école connaissent parfois mieux Scrum que certain·e·s chef·fe·s de projets. Et sans déconner, ça fait parfois mal à voir.
Un truc super complet en fait. 🤷♀️
Sauf que voilà, depuis que j’ai commencé à travailler, j’ai appris une chose: on oublie 95% de notre cursus et on code. Non pas que je n’aime pas coder, très loin de là. C’est mon activité préférée avec l’écriture. Le problème, c’est qu’on est catégorisé·e.
On trouve un job en tant que développeur·euse, on en ne fait plus que ça. De manière assez exceptionnelle, on peut être ammené·e à estimer des projets qui vont arriver ou de corriger des use cases qui d’autres ont écrits. D’autres personnes qui n’ont pas forcément le même point de vue, voir un point de vue carrément pas technique. Alors que les développeur·euse·s connaissent et imaginent, même sans coder, comment une application fonctionnerait. Depuis que je travaille, je n’ai eu qu’une seule occasion de dépasser ma qualification de développeuse: au début d’un projet, on devait préparer le schéma de la base de données.
Alors oui, je suis d’accord. Dans le manifeste agile, il y a ceci:
Les individus et leurs interactions plus que les processus et les outils. Des logiciels opérationnels plus qu’une documentation exhaustive. La collaboration avec les clients plus que la négociation contractuelle. L’adaptation au changement plus que le suivi d’un plan.
Mais cela n’empêche pas une documentation en amont, avant qu’un projet ne commence à être coder. Ne fusse que pour valider les specs ou pour, au contraire, avoir une vue d’avance sur ce qui pose problème et comment résoudre le problème avant même qu’il n’apparaisse. Ce n’est pas l’écriture des specs et YOLO on code sans aucune vérification de leur validité en amont. Aujourd’hui, je suis catégorisée développeuse fullstack Javascript. Tout ça parce que je connais Node.js et Vue.js.
Cependant, je ne suis pas fullstack. Un·e fullstack, iel va te monter le serveur, créer des réplicatas pour que jamais la base de données ne tombe. Iel va aussi faire des tests de manière avancée, que cela soit avec des tests unitaires, d’intégrations, de régressions ou d’acceptances. Iel pourra te pondre les user stories à base des besoins du client, etc.
Au final, on est tellement divisé·e qu’on ne fait qu’une petite voire une infîme partie de nos qualifications de base. Et franchement, ça m’énerve beaucoup. Parce qu’au-delà du Javascript, je peux pondre une documentation vachement bien foutue, des diagrammes UML. Malgré que ma partie préférée soit le code, j’aime aussi énormément les parties qui sont en amont du code. Par contre, quand on devient analyste, on ne fait plus de code. Quand on devient testeur·euse non plus. Project owner ? Pareil.
Pour ma part je peux pondre n’importe quelle partie d’un projet. Si je ne connais pas une technologie, je l’apprends; c’est pour ça que j’ai été à l’école pendant 3 ans (ok, 4 ans en réalité). C’est pour apprendre le métier d’analyste-développeur·euse: tout ce qui englobe la réalisation d’un projet numérique. Non pas pour être codeuse toute ma vie. Et surtout, être codeuse uniquement Javascript. Parce que j’aime faire un back avec Django ou Ruby on Rails. On peut même faire un back en Java avec Spring, en Go ou même en C++ pour les plus guedins. Alors, pourquoi on nous catégorise développeur·euse {entrez un langage de programmation} ?
Parce qu’au final, c’est plus dérisoire qu’autre chose. Si je voulais faire codeuse, j’aurais fait une formation intensive en développement web et sortir en ne connaissant que le truc à la mode (actuellement Javascript) sans avoir de connaissances réelles de tout ce qui se passe au-delà du code.
Attention, je ne dis pas ça pour dénigrer les personnes qui ont suivies ce genre de formations. J’ai expressément suivi un cursus long pour avoir des compétences en amont. Être codeuse, je l’étais avant même de commencer l’école d’informatique.
Pour terminer, je me demande combien de temps cela va durer. Parce qu’être catégorisée, c’est pas vraiment mon kiff. Probablement pas le tien. Je suis développeuse web. Cela veut dire développeuse spécialisée dans les technologies du web. Ça ne veut pas dire développeuse javascript. Ça veut dire ceci:
Demande moi de faire un projet web, je peux te dire quelle est la meilleure technologie à employer et pourquoi, quelles seront les problématiques à affronter, les risques qu’on va devoir anticiper mais aussi, c’est avoir une expertise au-delà du code.
Source de l’image de couverture: Farzad Nazifi