Développeur : erreurs que j'ai commises et à éviter.

Table des matières

Être resté longtemps dans une entreprise qui ne m’apportait plus rien

Il faut savoir que jusqu’à présent j’ai travaillé que dans 2 sociétés : celle où je suis actuellement et la précédente. Mon précédent job était dans une SSII en Belgique plutôt orientée réseau. J’ai intégré la structure en devenant le premier développeur en charge de la réalisation de l’ERP sur mesure.

Des opportunités ont fait que nous avons pu revendre l’expérience et la réalisation de l’ERP et nous avons fait grandir l’équipe pour arriver à 5 personnes jusqu’au moment de mon départ. Je suis resté 8 ans au total et j’avais de bonnes raisons d’y rester, car après tout j’ai été le premier développeur qui a permis d’embaucher d’autres développeurs.

J’ai participé grandement au développement de la cellule de développement. Je ne pouvais pas baisser les bras si facilement et abandonner au premier problème rencontré.

Et ça m’a coûté 3 ans !

Oui, tu as bien lu. J’aurais dû rester que 5 ans. Et quand j’y repense, je suis parti au bout de 8 ans pour les mêmes raisons qui me poussaient à partir au bout de 5 ans :

• Je m’ennuyais dans ce que je faisais et pour moi, j’avais fait le tour techniquement de ce que j’apprenais : je stagnais
• Le poste de soi-disant “Chef de projets” sur lequel j’ai évolué n’était pas valorisant et surtout assez fictif par rapport à mon travail
• L’infrastructure réseau n’était pas du tout adaptée au développement d’applications que l’on pouvait réaliser
• Je n’étais plus du tout en accord avec les valeurs et la vision de la direction de l’entreprise
• J’ai développé un mal-être et une haine envers mon job, tellement fort qu’à un moment donné j’ai dû me mettre en arrêt maladie

Alors, avec toutes ces raisons, pourquoi suis-je resté 3 ans de plus ? Tout simplement parce que comme j’étais le premier développeur et le responsable de la cellule, j’étais perçu comme le leader. Je ne pouvais pas quitter le navire comme ça. Et au-delà de ça, j’étais dans une certaine zone de confort.

En fait, je pensais même que c’était moi qui devais le quitter en dernier si cela devait arriver. C’est un raisonnement un peu bête quand on ne l’a pas vécu, mais je peux vous dire que cela vous tient.

Mais c’était une grossière erreur que j’ai faite ! Car au final, j’ai l’impression d’avoir perdu bêtement 3 ans d’expérience, car pendant cette période je n’avais plus aucune passion dans ce que je faisais.

Mon conseil pour éviter de commettre cette erreur : écoutez vos signaux d’alerte et votre instinct. Si vous n’avez plus la passion de vous lever le matin et que vous avez l’impression de perdre votre temps, alors ne vous forcez pas et changez. Nous avons la chance de travailler dans un secteur où il y a énormément d’opportunités sur le marché, il serait donc dommage de s’en priver et de souffrir pour rien.

Être resté dans sa zone de confort

Je disais précédemment que j’étais dans une certaine zone de confort dans mon ancien job. Pendant 8 ans, j’ai fait du PHP/MySQL, et je n’ai fait que cela. Bien sûr, j’ai exploré d’autres langages à titre personnel pour faire de la domotique, par exemple en faisant du Python, d’Arduino ou du Lua.

Autant vous dire que je touchais ma bille dans ces technos et j’avais une certaine confiance en moi en tant que développeur. Un putain d’ego de développeur 🔗 bien comme il faut en fait. À tel point que je me disais que j’avais un bon niveau, que je pouvais tout réaliser et que rien ne m’arrêterait. Encore une fois, j’avais tort sur toute la ligne.

En m’enfermant dans les mêmes technos et à toujours réaliser des choses semblables, je me voilais la face sur la réalité des choses : je n’y connaissais rien et j’étais un novice !

Pourquoi ? Tout simplement parce que je passais à côté de nouveaux concepts ou de nouvelles connaissances et je ne me remettais plus du tout en question. Et c’est un point fondamental pour progresser de la meilleure façon.

Tu te demandes certainement comment j’ai pris conscience de cela ? C’est en partie lié au point précédent : je m’ennuyais dans ce que je faisais.

De plus, en participant à des conférences, j’ai vu qu’il y avait de vastes choses à découvrir, toutes aussi passionnantes. Mais ce qui a enfoncé le clou, c’est lorsque j’ai commencé à réaliser des entretiens, j’ai compris que le niveau que je pensais avoir n’était qu’un doux rêve.

J’ai alors compris qu’en me reposant sur mes acquis et en me limitant à mon unique domaine d’expertise, je compromettais très sérieusement ma carrière de développeur.

Mon conseil pour ne pas commettre cette erreur : ne restez pas accroché à vos principes et vos acquis. N’hésitez pas à explorer d’autres connaissances et à surveiller ce qui se fait ailleurs sur des langages que vous n’utilisez pas habituellement.

La remise en question est le meilleur moyen de ne pas rester dans sa zone de confort et de ne pas s’enfermer dans ses principes et ses connaissances.

Avoir commencé à utiliser quelque chose sans avoir réellement compris comment cela fonctionnait.

Je pense qu’un grand nombre de développeurs commettent cette erreur. Et même si dans la plupart des cas, on finit par comprendre les choses, on perd du temps précieux en adoptant la mauvaise stratégie.

Les causes peuvent être multiples et différentes d’un développeur à l’autre, mais celle qui revient le plus souvent est lorsque l’on doit mettre en place un concept ou une connaissance que nous ne possédons pas encore directement en pratique dans le feu de l’action.

Cela m’est arrivé pour la première fois il y a 8 ans lorsque j’ai utilisé un mécanisme de rechargement d’une donnée suivant une action utilisateur : Ajax. C’était l’une des plus grandes difficultés majeures que j’ai rencontrées pour la première fois. Pour dire, j’ai mis exactement 15 jours pour bien comprendre et surtout mettre en application quelque chose qui fonctionnait et que j’avais compris.

Mais pourquoi ai-je autant galéré ? Rétrospectivement, pour plusieurs facteurs :

• Je commençais mon premier job et j’étais directement dans le feu de l’action. Un débutant sans expérience qui se mettait une certaine pression pour arriver aux objectifs qu’on lui fixait et surtout qui avait peur de décevoir.
• Je débutais tout juste en JavaScript. Je n’étais qu’au balbutiement du langage. J’étais loin de le maîtriser et je devais apprendre en plus une nouvelle approche qui m’était inconnue jusqu’alors.
• J’étais pressé et je manquais de temps et d’expérience pour prendre conscience que je n’adoptais pas la bonne tactique pour apprendre.

J’essayais d’apprendre quelque chose et je bidouillais ce que j’apprenais dans l’architecture applicative que j’avais entre les mains. Je n’avais aucun recul sur ce que je faisais et je n’avais aucune idée si ce que je tentais de faire respectait les bonnes pratiques. En fait, je n’avais pas vraiment d’idée de ces notions à l’époque et je ne pense pas que j’en aurais été préoccupé : je voulais juste faire un truc qui fonctionne, point !

Avec l’expérience que j’ai acquise, je sais que ce n’est pas la bonne méthode et qu’il faut se faire violence pour prendre le temps de bien comprendre une nouvelle connaissance, même quand on ne l’a pas.

Mon conseil pour ne pas commettre cette erreur : même si cela vous paraît impossible et que vous êtes contraint par le temps, prenez quand même le temps qu’il faut pour bien apprendre et comprendre un nouveau concept.

Je sais que c’est difficile de prendre ce genre de décision quand on est sous pression, mais croyez-moi, vous passerez beaucoup moins de temps à faire comme ça qu’en jouant au cowboy en apprenant dans le feu de l’action. Et apprenez en mode bac à sable en vous faisant un petit projet test et pas directement dans le projet sur lequel vous travaillez.

Avoir commencé ma carrière de développeur dans une entreprise où j’étais le seul développeur

Avant toute chose, je tiens à dire que cela a été une bonne expérience et que si c’était à refaire, je le referais. J’ai su tirer profit de la situation pour en obtenir beaucoup d’avantages, même plus que d’inconvénients, mais il est important de connaître ses inconvénients qui vous permettront de ne pas commettre les erreurs que j’ai subies indirectement.

Programmer seul a de nombreux bénéfices. Si vous vous en sortez bien, vous commencez à prendre confiance et vous vous sentez pousser des ailes. Et vous risquez de ne plus vous remettre en question suffisamment pour pouvoir évoluer correctement.

Pire encore, vous n’avez aucun point de comparaison pour savoir si ce que vous faites est bien ou non. Vous vous enfermez dans votre monde au lieu de vous ouvrir et d’explorer tout ce qui peut être fait. C’est ce qui m’est arrivé en tous cas.

Le résultat : j’ai pris de mauvaises habitudes et mon travail n’était pas structuré pour travailler en équipe et de manière collaborative. C’est toujours plus simple et beaucoup plus facile d’avancer et de progresser à plusieurs plutôt que tout seul.

Mon conseil pour ne pas commettre cette erreur : comme vous l’aurez compris, être le seul développeur en entreprise n’est pas une erreur, mais ne pas s’entourer de développeurs en dehors de votre entreprise en est une.

Participez à des meetings, à des conférences ou constituez-vous un groupe de développeurs sur Internet ou avec certains de vos anciens camarades de votre promo. Ne tombez pas dans le piège de programmer seul sans confronter votre travail à d’autres développeurs pour pouvoir vous évaluer et progresser.

Ne pas imposer mes choix et mes idées

Je crois que ce dernier point est le plus important pour moi et c’est celui où je dois encore faire des progrès. J’ai énormément de mal à imposer mes choix et mes idées.

J’ai toujours été très humble et j’ai toujours fait en sorte de délivrer mes connaissances et mes idées en douceur. Mais je n’ai jamais voulu forcer les personnes à les suivre. Je préfère qu’ils remettent en cause ce que je leur délivre et qu’ils fassent l’expérience par eux-mêmes. C’est beaucoup plus enrichissant et je gagne leur respect d’une certaine façon s’ils vérifient que mes propos sont véridiques.

Je fonctionne comme ça : je propose mes idées et mes choix sans les imposer. Et je sais que je devrais plus imposer mes choix auprès d’autres développeurs compte tenu de mon expérience et de ma position.

Mon conseil pour ne pas commettre cette erreur : si vous avez l’expérience et le niveau pour proposer et faire valider vos idées auprès des autres, alors faites-le sans regret.

Épilogue

Voilà les principales erreurs que j’ai commises. En fait, ce sont celles qui m’ont le plus marqué et qui, je pense, peuvent être commises par n’importe qui ! Peut-être que je sauverai une partie de votre temps ou de votre expérience.