Expérience pro

Les principales erreurs que j’ai faite en tant que développeur

Les principales erreurs que j’ai faites en tant que développeur

On est tous amené à faire des erreurs un jour au l’autre, que ce soit au niveau des choix techniques, des clients qu’on choisi ou encore de sa carrière. Il faut faire des erreurs pour avancer et surtout pour réussir, mais il y en a certaines qu’on aimerait éviter ou qui auraient pu être évitées.

Ê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 en tout 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’application 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 ses raisons, pourquoi je suis 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 ne pas commettre cette erreur : écouter 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 une chance de faire un métier où il y a énormément d’offres sur le marché qu’il saurait dommage de s’en priver et de se faire du mal 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, 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 et que je pouvais tout réaliser et que rien ne m’arrêterait. Encore une fois, j’avais faux 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 connais rien et je suis un noob !

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 des façons.

Tu te dis certainement comment j’ai pris conscience de ça ? C’est en partie liée 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 et tout aussi passionnante. Mais ce qui a enfoncé le clou c’est lorsque j’ai commencé à réaliser des entretiens que je me suis aperçu 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 rester 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 en temps normal.

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

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

Je pense qu’énormément de développeurs commettent cette erreur. Et même si dans la plupart des cas, on finit par comprendre les choses on perd un temps précieux en ayant adopté la bonne stratégie.

Les causes peuvent être multiples et différentes d’un développeur à un autre, mais celle qui revient le plus souvent c’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’est 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 jusque là.
  • J’étais dans le rush et je manquais de temps et d’expériences pour prendre conscience que je n’adoptais pas la bonne tactique pour apprendre.

Je tentais 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 respecter les bonnes pratique. En fait, je n’avais pas vraiment idée de ses notions à l’époque et je pense que je n’en aurais pas préoccupé : je voulais 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 faille 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 le cow-boy 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 les 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 la confiance et vous sentir poussé 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éveloppeur en dehors de votre entreprise en est une.

Participez à des meetings, à des conférences ou constituez-vous un groupe de développeur 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’il fasse l’expérience par eux même. C’est beaucoup plus enrichissant et je gagne leur respect d’une certaine façon s’il vérifie 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.

Epilogue

Voilà les principales erreurs que j’ai commises. En faîtes, c’est celle qui m’ont le plus marqué et qui, je pense, peuvent être commise par n’importe qui ! Peut-être que je sauverais une partie de votre temps ou de votre expérience.

Partager ce contenu
  • 10
    Partages

Leave a Comment

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.