REX, d'étudiant à developpeur web

Cet article, j’aurais personnellement aimé le lire quelques années plus tôt quand je pensais que savoir écrire du code était le but ultime du développeur. Et peut être qu’il rendra service à d’autres personnes qui sont actuellement dans cette situation.

Le but n’est pas juste de raconter une expérience, mais c'est surtout d’en sortir des idées qui aideront peut-être à devenir ou être un meilleur développeur (le niveau est relatif bien sûr). Ce n’est pas un tuto non plus, mais ce sont les enseignements acquis au fil de mon expérience pro qui ne fait d’ailleurs que commencer au final...

La première partie de mon parcours : résumé

Commençons en faisant brièvement une passe par mon parcours scolaire. J’ai intégré une école à Paris qui proposait un BTS SIO. Je me suis vite aperçu que j’étais mal tombé. Profs Absents, programme non respecté, on s’est même déjà retrouvé avec plusieurs semaines vides sans cours. Le résultat, 12% de réussite au BTS et l’école a fermé. Mon arrivée dans le monde de l’informatique et plus précisément du développement était donc un peu ratée.

Mais bon, disons que c’était un faux départ. Je me suis donc ré-inscrit pour un Bachelor en 3 ans. Je négocie pour rentrer directement en 3ème année espérant qu’ils prendront en compte mes deux ans de BTS avant. Ce qu’ils ont fait ! le problème en revanche, c'est que pendant que les autres avaient accumulé plein de connaissances au cours des deux dernières années, j’avais pour ma part accumulé pas mal de retard...

De plus, il fallait, pour rentrer dans l'école, une alternance dans une entreprise. J’ai donc cherché une entreprise, que j'ai fini par trouver après quelque temps, pour une mission de développement en interne.

Mettre son temps à profit

Dans cette mission, il s’avère que je n’ai pas de référent technique, autrement dit, je suis le seul développeur et la stack n’est pas du tout en adéquation avec les dernières technologies et ce qu’on peut nous apprendre à l’école. Mais ça, en fait, on s’en fiche. J’avais une école, une entreprise, et surtout, comme les besoins n’étaient pas urgents en interne, j’avais du temps ! Du temps pour me former, faire de la veille, tester des choses, bref. C’était l’occasion de rattraper le retard. J’ai donc suivi tous les tutos possibles et imaginables, j’ai testé plusieurs langages, et j'ai aussi pu en profiter pour travailler pour l’école. Et puis, il y a quand même un avantage à être le seul développeur. On est potentiellement le seul à avoir une connaissance technique en informatique dans l’entreprise. Donc les gens font confiance, ce qui m’a permis de tester beaucoup de choses, de faire mes propres choix, et aussi et bien sûr, mes propres erreurs. Au final j’avais réussi à combler mon retard, j’avais une école, et un boulot qui me donnait une première expérience dév sur le CV, ce qui est très valorisable. La machine était lancée.

Le fond de cette (courte) histoire, c’est qu'il faut savoir rester pragmatique, et savoir tourner le mauvais en bon. Si l’école ou le travail ne vont pas, c’est que c’est sûrement l’occasion pour se bouger ! J’ai rencontré beaucoup de personnes qui s'inquiétaient de ne pas trouver tout de suite quelque chose de super en pro ou en scolaire. Mais ce qu’il faut savoir, c’est que c’est OK de ne pas passer par la grande porte, le chemin est juste un peu plus long et on apprend plein d’autres choses différentes au final.

Viser toujours plus loin

Maintenant que tout ça était fait, il fallait passer à la prochaine étape, celle qui était pour d’autres une étape initiale : trouver une entreprise où je serais dans une vraie équipe de développement, avec de vraies problématiques et un environnement vraiment orienté dév.

HERE COMES THE REAL GAME

C’est en plein cours d’agilité (pas le parcours canin), que je reçois un mail d’ Eleven Labs qui me propose de discuter et de voir si je suis intéressé par une autre expérience professionnelle. Et de prime abord, c’est le fait de travailler dans un environnement Agile qui m'attire le plus.

Passons à l’essentiel, 5 mois après, je suis un astronaute ! Me voilà dans un milieu très technique, orienté dev, avec des gens extrêmement compétents et expérimentés. Et rapport à l’agilité tiens ! J’allais enfin travailler dans un environnement agile, chose que je n’avais vue jusqu'à présent qu’en cours. Mais alors qu’est-ce qu’on apprend lorsqu’on travaille en équipe et avec des profils expérimentés ?

Ce qui rend les seniors “seniors”

Bah première découverte, on apprend pas à coder. Alors indirectement si ! Mais on apprend que coder est la dernière étape du développement (ou pas loin). Avant, il y a tout un processus de conception, des notions d’architecture... On apprend à comprendre pourquoi on fait certains choix techniques, on n’apprend pas à coder de telle manière mais on apprend à comprendre pourquoi on l’a fait comme ça et pas autrement.

C’est très frustrant de travailler avec des profils seniors. On passe 3 jours sur un problème, et quand on demande de l’aide, ils le résolvent en trois lignes de code. Je me suis alors demandé quelle était la vraie différence entre eux et moi. Moi aussi je sais écrire “ maVariable = 1”, pourquoi je prends plus de temps alors ? En fait, la différence n’est pas dans le code. Elle est avant.

Déjà, il y a une forte connaissance du produit. Connaître son produit, connaître les règles métiers, et maîtriser son architecture, représentent plus de la moitié du travail. C’est pour ça qu’il est important de faire de la conception avant même d’écrire une ligne de code. Et puisqu’on y est, plus on lit de code, plus on se rend compte que la lisibilité est importante, plus on fait attention à ce que l’on code par la suite, en se disant qu’il faudra sûrement le relire un jour. J’en profite pour glisser une image sur l'unité de mesure du code :

Il y a aussi la vision à long terme. Il ne faut pas simplement penser à la solution qui résout le problème a l’instant T. Il faut que la solution soit viable aujourd’hui, demain, et après demain ! Après demain l’application aura très certainement beaucoup changé, et il faut le prendre en compte dès maintenant. C’est comme mettre du scotch sur un tuyau qui fuit… c’est une solution, mais ça marche 10 minutes.

Et bien évidemment pour finir, et le plus évident, ils ont de l’expérience, donc ils pensent à des conséquences qu’on aurait même pas imaginées. Mais il faut garder en tête qu’ils ne sont pas devins, ils se sont juste cassés les dents avant dessus. Et ça c’est important pour le moral quand on passe des heures sur un problème qu'eux solutionnent en 10 minutes.

Architecture Architecture Architecture

Il y a une dernière chose sur laquelle je voudrais revenir, c’est l’architecture. Je n’avais aucune notion d’architecture avant, et j’ai vite compris qu’il fallait que je m’y mette car c’était très important. En tant que profil junior, on y pense très peu, et c’est pas si évident que ça à comprendre ou à mettre en place. Et pourtant, c’est l’une des choses les plus importantes. Il y a toujours une architecture évidemment, mais ça veut pas forcément dire qu’on la maîtrise. Pourquoi l’architecture est importante ? Elle permet de gérer le changement, d’anticiper les évolutions, de définir les contraintes d’implémentation et de mieux gérer les imprévus (liste non exhaustive, on pourrait encore en écrire 30 lignes).

Quelles sont les différences entre les types d'architecture et comment en choisir une ? L’exemple le plus simple qu’on m’ait exposé, c’est la comparaison avec une ville. Choisir une architecture c’est penser à :

• La taille : de la cabane à la ville
• Les Coûts : de 1€ à des millions
• Le temps : de 1 jour à 6 mois
• Du process : de l’improvisation à un planning préparé
• Des compétences : de l’imprévision à plusieurs métiers qualifiés
• Des risques : de l'égratignure à la vie d’une population entière
• Des contraintes : de aucune à beaucoup.

Et l’agilité dans tout ça ?

Oui parce que c’est ce qui m’avait un peu motivé à la base. Mais c’est très différent de ce qu’on peut vous présenter en cours par exemple. On nous présente toujours un côté extrêmement bisounours, où tout le monde s’aime dans le meilleur des monde, où ce n’est jamais la faute de personne, et que s'il y en a un qui ne fout rien c’est sûrement qu’il ne se sent pas bien… le pauvre… Et j’exagère à peine.

En vrai c’est un peu différent bien sûr et heureusement. Mais c’est toujours positif ! Le côté communauté est très motivant, ainsi que le côté travail en groupe, le soutien... Effectivement les moments de difficultés de chacun deviennent le problème de tout le monde, et ça ça aide beaucoup. Sans parler de l’organisation des tâches qui permet de suivre l'avancée de chacun.

J’ai surtout vu un intérêt d’un côté communication. Les stand-ups notamment permettent de toujours rester d’accord sur qui a fait quoi, qui va faire quoi, et si on ne fait pas fausse route par rapport aux besoins métier.

L’agilité couplée à un emploi du temps d’alternant peut cependant présenter des aspects négatifs. En effet, passer du temps sur une feature, progresser, et ne pas pouvoir la finir car elle aura été récupérée par un autre membre de l'équipe pendant une absence à l’école peut être frustrant. Mais c’est aussi cette organisation de suivi qui permet en cas d’absence à un autre développeur de pouvoir reprendre le travail et finir le ticket. Ce qui est essentiel d’un point de vue projet.

CONCLUSION

Bravo vous avez enfin atteint le statut de développeur ! Finalement c’était pas si dur que ça hein ! Plus sérieusement, j’espère que ce REX sur le début de mon parcours et les enseignements tirés vous ont plu, vous aideront, ou peut être que vous vous êtes reconnus dedans ! Rappelez vous que la chose la plus importante pour un développeur et quel que soit son niveau, c’est de savoir qu’il y a des choses que l’on ne sait pas.