Je n'arrive pas à m'en rendre compte mais cela fait déjà quasiment un an que je suis devenu un développeur web professionnel (après une reconversion professionnelle où avant j'avais plutôt un profil multi-casquettes dans l'industrie du jeu vidéo).

Et je dois dire que j'ai déjà appris beaucoup durant cette année et que j'ai encore énormément à apprendre, cependant je me dis que je peux déjà partager une partie que j'ai intégré, les erreurs à éviter si possible ou encore à quoi s'attendre quand on débarque dans un nouveau projet en tant que développeur junior. Je tiens cependant à préciser que ceci ne ressort que d'une expérience personnelle, donc je ne prétends pas détenir la vérité universelle, surtout que cela dépends du type de projet et de l'équipe dans laquelle on travaille.

C'est normal de ne pas comprendre grand chose quand on arrive sur un nouveau projet

Et je dirais que c'est particulièrement vrai quand on arrive sur du code (très) legacy (=  vieux) car il faut d'abord comprendre l'architecture des fichiers du projet (la nomenclature des dossiers, si c'est divisé en bundle fonctionnel ou de domaine de code, ou se place le code du front s'il y en a un, etc...).

Personnellement cela m'a demandé environ trois mois pour arriver à naviguer avec aisance dans le projet de ma boite (c'est un projet initié par des alternants/stagiaires il y a 4 ans, structurellement c'est le bordel), c'est à dire à savoir où se trouve les fichiers directement de tête ou de pouvoir deviner où ils se trouvent et surtout de ne pas découvrir une nouvelle partie du projet au détour d'une carte (c'est comme cela qu'on appelle les tâches de développement dans mon équipe).

Ensuite il faut arriver à lire le code fait par d'autres développeurs (plus ou moins bons), qui parfois ont quittés l'entreprise depuis des années, de comprendre pourquoi un code a été écrit de telle ou telle manière alors que ça semble aberrant (et de savoir par la suite si cela a une raison ou non).

Cependant cela est très utile, car on apprends beaucoup de cette manière, sur les choses qu'on doit faire, qu'on ne doit pas faire, de reconnaitre le style d'écriture de code d'un collègue, de découvrir de nouvelles techniques. Par exemple c'est en lisant du code du projet que j'ai appris à utiliser certains design patterns car bien que j'avais un peu regardé cela avant d'entrer en poste, je n'ai jamais réellement trouvé d'exemples pratique d'utilisation, mais plutôt des micro-exemples sans vraiment de contexte (d'ailleurs c'est le même délire pour trouver des exemples pratiques de TDD ou DDD (à ne pas confondre avec l'architecture hexagonale) en PHP).

Ne pas hésiter à proposer des améliorations

Évidemment ce type de remarque est valable quand on travaille dans une équipe qui est ouverte à la discussion et à condition que ce qui est proposé est potentiellement pertinent.

Après cela peut sembler "ballsy" comme approche, surtout provenant d'un développeur junior, mais il faut prendre en compte que ces suggestions peuvent permettre un gain réel car l'équipe en place peut avoir l'habitude d'un process ou d'outils qui ne sont pas forcément optimum pour les nouveaux venus et surtout de pouvoir gagner du temps sur les intégrations des futurs collègues.

Par exemple quand je suis arrivé dans ma boite,  ils venaient tout juste de conteneuriser l'environnement de développement, le problème c'est que cela avait plein d'effets de bords qui prenaient du temps à être réglé (des problèmes de droits, des extensions php manquantes dans le conteneur php), surtout pour ceux qui n'avaient aucune expérience sur Docker (par chance j'en avais fait un peu avant de rejoindre l'équipe). Du coup je me suis mis à la tâche d'améliorer le Dockerfile pour lisser le comportement du stack.

Au final ce sont des améliorations qui pourront apporter beaucoup à votre équipe et qui feront gagner du temps à tout le monde sur le long cours.

Vos estimations seront éclatées

Quand vous commencerez à travailler sur vos cartes/tickets, il va forcément arriver un moment où votre senior/lead/PO (Product Owner) va vous demander dans combien de temps votre tâche va être terminée, dans ce cas utiliser la Règle de Scotty :

La scène continue après indiquant qu'il annonce généralement le double de temps dont il a besoin pour sa tâche. La différence avec le propos de Scotty c'est que dans notre cas il n'est pas question de se faire passer pour quelqu'un de super efficace si on termine notre tâche avant le temps que l'on a donné, mais simplement parce qu'on va systématiquement se planter dans l'estimation, et c'est normal en réalité.

Car déjà on ne connait pas sa propre  vélocité dans un projet que l'on connait que peu, qu'il est possible (voir même probable) qu'on tombe sur des difficultés qu'on avait pas prévu à la base (un effet de bord provoqué par son code, la refacto d'un service qui devient nécessaire pour le développement de la tâche, un imprévu technique nécessitant la modification du stack technique, l'action nécessaire d'un tier, des réunions qui popent, etc...).

J'irais en plus encore plus loin que Scotty en vous conseillant de multiplier par trois le temps que vous pensez nécessaire pour réaliser votre développement, au moins les premiers mois (et au tout début, de dire simplement "je ne sais pas"). Au mieux vous avez (en partie) de la chance et passer pour un développeur efficace (ça c'est le cadeau bonus), au pire vous limitez le drift et ne devriez pas trop sortir du worst case scenario. Vous pourrez ensuite baisser ses estimations une fois que vous aurez une meilleure connaissance du projet et que vous connaitrez votre vélocité.

Vous allez vous prendre des murs

Une autre chose que vous allez forcément vous prendre à un moment ou un autre, c'est un mur. C'est à dire une tâche que vous pensiez qui allait prendre une semaine, peut-être deux au pire, mais qui termine par prendre 2-3 voir 4 mois à cause de différents facteurs (le périmètre du développement qui a été mal défini ou non anticipé, création d'un algorithme assez complexe, apparition d'effets de bord difficiles à identifier/isoler, etc...)

Et cela peut potentiellement devenir stressant, surtout si votre senior/lead/PO revient de plus en plus régulièrement aux nouvelles pour savoir comment avance la carte.

Le mieux à faire, mais le plus compliqué aussi (car on ne s'en rends pas compte avant qu'il ne soit trop tard et surtout que souvent à l'impression d'être sur le point de débloquer la situation), c'est de prévenir vos supérieurs pour les prévenir que ça risque de sévèrement drifter.

La productivité ne se résume pas à coder

À priori on se dit quand lorsqu'on est engagé pour développer, notre productivité se résume au nombre de cartes/tickets qu'on descends et que donc si on passe une journée sans coder ou très peu, c'est qu'on a pas fait grand chose et que cela risque d'être mal vu le lendemain matin lors du daily.

Et bah vous avez tort (dans un cadre de travail responsable).

Un développeur est là pour résoudre des problèmes en premier lieu et non pas pour coder stricto sensu. Écrire du code n'est qu'un moyen pour résoudre un problème. Cela signifie que vous pouvez parfaitement mettre bien plus de temps pour réfléchir à la manière de résoudre efficacement le problème que d'effectivement le régler (via le code) et c'est parfaitement valable comme situation (normalement).

Votre senior/lead/PO va vous demander de régler un problème (que ce soit de fixer un bug ou de développer une nouvelle fonctionnalité), mais après c'est libre à vous (plus ou moins) de la marche à suivre pour faire ce qui vous a été demandé. Allez-vous le faire de façon "quick & dirty", ou au plus simple ou alors développer tout un nouveau système afin d'anticiper des demandes qui pourront arriver plus tard mais où votre implémentation rendra la chose bien plus facile à faire par la suite ? Ce qui amène ensuite aux éventuelles classes et méthodes que vous allez créer et comment vous allez les implémenter au sein du projet.

Tout ça pour dire qu'il y a fixer un problème et fixer un problème, de même qu'il ne faut pas croire que c'est un drame si vous n'arrivez pas à coder certains jours (car ça peut arriver que le cerveau ne suive pas de temps en temps) ou ne pouvez pas des masses coder (voir pas du tout en fonction de ce qui peut arriver dans votre journée).

Il faut vous reposer

Là c'est plus un truc que j'ai vu (à mon boulot actuel et dans mon précédent) que quelque chose que j'ai expérimenté (du moins à ce poste). C'est potentiellement votre cas, mais lorsqu'on commence un nouveau job, particulièrement si on est nouveau, on veut montrer à quel point on est motivé et donc on a tendance à faire plus que nécessaire sauf que cela peut amener à quelques dérives.

Même si notre poste n'est pas physique, notre cerveau carbure pas mal tout au long de la journée pour trouver des solutions et faire les algos, ce qui fait qu'au bout d'un moment il commence à fatiguer à performer de cette manière. Mais qu'est ce qui se passe quand on commence a être fatigué ?

Incapacité à se concentrer (ce qui est embêtant pour réussir à faire ses algos), plus  de faute dans le code, irritabilité, au final vous n'arrivez plus à rien. Donc ne dépassez pas (trop souvent) vos horaires de travail, en plus du fait que vous travaillez gratuitement pour votre employeur mais également d'éviter de travailler le weekend (par contre vous êtes libre de bosser sur des projets personnels).

D'ailleurs relatif à ce point, si vous vous trouvez bloqué sur un développement, il y a trois chemins possible :

  • Demander de l'aide à un collègue
  • Si ce n'est pas possible, prendre une pause (15-20min à faire quelque chose non relatif au travail)
  • Passer sur une autre carte et revenir dessus le lendemain

Personnellement j'ai plutôt tendance à prendre les solutions 1 et 3 surtout que généralement quand je suis bloqué, je trouve les réponses soit durant la nuit, soit au réveil le lendemain matin. C'est pour cela que généralement j'ai toujours une ou deux cartes en backup pour switcher quand j'ai besoin de changer de sujet.

Poser des questions, encore et toujours

Quand on arrive on veut toujours (normalement) faire bonne impression et montrer qu'on est un minimum autonome mais autant le dire dès maintenant, il n'y a (quasiment) pas de questions idiotes. Vaut mieux poser une question dès le moment où l'on ne comprends pas quelque chose (en particulier si cela a attrait à une classe ou élément du projet) au lieu de chercher pendant des heures/jours et donc de finir une carte en six heures au lieu d'une.

De même vaut mieux demander à répéter les choses que vous n'avez pas compris au lieu de faire mine d'avoir compris pour se planter plus tard ou de tenter de réassembler les morceaux dans son coin, ça ne profite à personne (et même au contraire cela peut vous être négatif). Et cela fonctionne à n'importe quel niveau de "séniorité" : alternant, junior, confirmé ou senior, surtout quand on arrive sur un nouveau projet.

Ça va vite, très vite

Au final je ne l'aurais pas vu passer cette première année, c'est allé vite, très vite et je ne me rends pas encore compte de tout ce qui s'est passé durant cette période, j'ai l'impression d'avoir commencé il y a six mois.

J'espère que ce billet vous aura aidé à moins stresser si vous venez d'entrer en poste ou que vous allez bien l'être et espérer que cela vous aidera à éviter certaines déconvenues 😄

Les prochains billets traiteront de ce que j'ai appris plus techniquement (entre autre) et qui pourrait permettre de comprendre des principes de développement qui sont peu ou mal expliqués (surtout en PHP) !