4 conseils pour bien commencer

L'alternance c'est fini. Je ne pourrais pas faire la liste de tout ce que j'ai appris... J’ai eu la chance d’être très bien encadrée, je veux dire : être entourée de gens non seulement compétents (dans mon entreprise, à l’école, avec mes ami.e.s), mais aussi à l’écoute et qui avaient vraiment envie de me transmettre leurs compétences.

Je sais que toutes les alternances ne se passent pas forcément comme ça, donc voici une liste de conseils que j'ai reçus ou que j'aurais aimé recevoir.

1. Simple, basique : "écris du code".

C’est un conseil que je ne tiens pas vraiment de mon alternance, mais d’un peu avant et que je donnerais même aux gens qui ne sont pas en entreprise ou qui viennent de commencer à coder. Si je pense qu’on a tous et toutes nos rythmes pour apprendre à coder, et nos préférences - tutos, cours, expérimentations, projets perso, etc. - je suis intimement persuadée qu’il y a un truc à coté duquel il ne faut pas passer : écrire du code. Ça parait simple, mais je fais un constat depuis que j’ai commencé à coder: c’est assez facile et ça arrive vite de ne plus coder. De lire de la doc. De faire des schémas. De discuter avec des gens de comment faire. De réfléchir. De poser des questions. De copier coller des bouts de code de ChatGPT. De continuer à réfléchir. D’hésiter. Et voilà, tout d’un coup on se retrouve après 6 mois, à ne plus avoir codé une ligne et à avoir peur de le faire. Attention, je ne dis pas qu’il faut coder comme un.e sale toute la journée, juste pour coder. Non. C’est bien de réfléchir, de lire de la doc, tout ca. Mais n’en fais pas une échappatoire.

Tape du code sur ton clavier. Prends le problème, si tu ne sais pas par où le prendre et que ça fait trois jours que tu hésites sans savoir par où commencer.

Commence.
Par.
Un.
Bout.

Whatever lequel, on s’en fout. Ça n'est peut-être pas très catholique/orthodoxe/... (raye la mention inutile), mais sinon tu vas arrêter de coder et tu vas finir dans les tréfonds de ta tête en mode Bambi paralysé.

Pour la petite histoire, pas plus tard qu'il y a trois jours, quelqu'un m'a remerciée d'avoir été un peu cash (oui, je ne suis pas connue pour ma subtilité) sur ce sujet en lui ayant dit "ton problème avec le code, c'est que tu ne codes pas.". Elle m'a dit : "c'était exactement ça le problème.".

2. Oui, tu vas péter des trucs

Alors oui je sais, le conseil précédent parait facile, mais souvent quand on n’écrit pas, c’est qu’on a une bonne raison et moi j’en ai souvent une très bonne : je suis une noob. Il y a 98 chances sur 100 que ce que je fais ne soit pas du tout ce qu’il faut faire, pire, que ça ajoute des problèmes au problème actuel. Pour moi, c’est très, très lié à une peur que j’ai eue dès le début de mon alternance : casser des trucs.

Ben oui, quand on commence en entreprise, on est sur un vrai produit, avec des gens qui l’utilisent. Alors certes, la plupart d’entre nous n’envoyons pas des fusées sur la lune ni ne sauvons des gens de la mort, mais quand même, on est sur une autre échelle que celle de la to-do list React.

Quand on commence en entreprise, on a du code qui est (censé) être bien testé, on a des process qui font passer ou non le code, on a des alertes pour dire “oulah pas ouf ce que tu viens de faire” (tu voulais faire un truc incognito, c'est raté).

Quand j’ai commencé, j’avais peur d’ouvrir une PR parce que je me disais, ca va être rouge partout. Spoiler : ça l’était. Mais on m’a dit plusieurs trucs au fil de mon alternance qui m’ont bien aidée :

→ "Une CI, c’est fait pour péter" : le rouge partout, c’est fait pour éviter des problèmes, et non éviter que tu codes. Le développeur qui code à coté de moi toute la journée m’a dit : "si t’as peur de péter la CI, tu ne vas rien coder". Alors, je n’irais perso pas jusque là, mais maintenant je remercie plutôt la CI de péter pour m’avertir que j’ai loupé un test, que j’ai oublié un type… c’est mieux maintenant que plus tard, non ?

→ “T’as cassé la prod” : lors d'un point avec mon tuteur, il m’a demandé ce qui me faisait peur. J’ai dit : ‘péter la prod'. 3 semaines plus tard il m’a appelée pour me dire “tu te souviens le truc que t’as fait ? Ben c’est tout cassé en prod". Bon heureusement, c’était des og, ça n’a pas mis en péril toute l’app, mais je ne sais pas, une fois que ça été fait et dit, et que j’ai remarqué que ca n’avait pas mis le monde à feu et à sang, je me suis sentie mieux. C’est pas grave en fait : on casse, on répare (parfois c’est un juste un moment de honte à passer).

→ “PR approuvée, faute partagée” : si un truc que tu fais casse quelque chose de plus gros (genre une mise à jour qui fait des écrans bleus sur tous les appareils qui utilisent microsoft, à tout hasard), le problème ne vient pas de toi, mais plutôt du process qui permet à tout ça d’en arriver là : normalement, ton code n’est pas censé arriver directement en production, normalement d’autres personnes le relisent, il y a des tests, différents environnements,… Si personne n’a vu le bug que ça allait produire, c’est sûrement que le bug n’est pas vraiment lié à toi et à tes compétences et la responsabilité est collective (ca n’enlève pas les bugs).

3. Tu n’éviteras pas les conflits

Moi j’aime beaucoup git, je ne sais pas pourquoi. Mais je sais que ce n’est pas le cas de tout le monde et, on va se le dire en face : il y a quand même une grande chance que tu l’utilises en entreprise. Je pense que c’est une des choses sur lesquelles je suis le plus montée en compétence pendant l’alternance et pour une raison assez simple : git (et ses outils que ce soit github, gitlab, etc.) prennent tout leur sens quand on travaille réellement a plusieurs sur les mêmes projets, voire pire, les mêmes fonctionnalités.

A nouveau, sur la todo list React qu’on fait à trois pendant ses études, il y a peu de chances que les enjeux sur git soient très élevés et on ne rencontre pas beaucoup de cas problématiques. Git c’est surtout là pour versioner et sauvegarder. Et quand je rencontrais des cas problématiques - par exemple, sur un projet où on était en groupe de 10 personnes - on se disait qu’on avait mal utilisé git. On pestait sur les conflits à régler. On se disait qu’on avait dû louper une manière de faire (on aurait dû merger avant, ou brancher depuis là, ou... bref). En entreprise j’ai compris un truc avec git : git n'est pas là pour éviter les conflits, il est là pour nous aider à les résoudre plus efficacement/facilement. Quand dix dev travaillent sur le même truc, c’est sûr qu’il y aura un conflit à un moment. Mais ce n’est pas grave. Comme n’importe quel problème de code : on le prend par un bout et on le règle.

Donc vraiment, si tu n’aimes pas faire de diff et régler les conflits, trouve un moyen qui te convient (il y en a plein : dans ton éditeur de code, dans ton terminal, en remote), car tu vas en faire pléthore. Et c’est bon signe.

4. Communiquer pour gérer les changements d'échelle (et tout le reste)

Le point git est lié à une des grandes différences entre apprendre du code tout seul, à l'école et l’apprendre dans une boite : l’échelle.

En entreprise, tout est plus grand : le nombre de personnes avec qui on travaille, le code déjà existant, le nombre d’outils… Tout est multiplié par 2, 10 ou 100 selon la boite dans laquelle on se retrouve. Et là, il n’y a pas de secrets : pour apprendre, pour éviter de casser des trucs, pour minimiser les conflits git, il faut faire une chose : communiquer. Parler avec ses collègues dev (”t’as déjà fait ça ?", “C’est quand la prochaine release ?", “est-ce que quelqu’un a deja eu tel bug ?", “qui sait comment on ajoute XXXX sur l’outil YYY?" ?), communiquer avec les gens qui te donnent les tâches (”est-ce que c’est important si je fais ça/pas ça ?", "est-ce que par 'xx' tu veux bien dire 'xx' ou 'yy' ?"), demander de l’aide, dire où tu en es, où tu vas. C’est plus facile à dire qu’à faire et on a tous nos affinités avec ça. Moi, je sais que pour bien communiquer, j’ai besoin de savoir à qui je m’adresse et de connaitre mon équipe. Du coup j’ai essayé de mettre ça en place (proposer des verres, discuter avec les gens, etc.).

Trouve le moyen qui te met en confiance pour bien communiquer et le reste suivra ❤️.