L’échec peut mener au succès, mais la complaisance irréfléchie est un certain tueur de carrière pour les développeurs.

Vous ne trouverez pas de pénurie de phrases de motivation de carrière entourant l’échec: Échouer rapidement, l’échec construit le caractère, la clé du succès est l’échec, les erreurs vous font grandir, ne jamais avoir peur d’échouer. Mais l’idée de prendre votre chemin vers le sommet de l’industrie du logiciel est probablement malsaine. Chaque développeur aura sa part de faux pas dans une carrière, mais pourquoi ne pas apprendre de l’expérience des autres – et éviter les erreurs les plus coûteuses?

C’est ce que j’ai fait: j’ai discuté avec un certain nombre de professionnels de la technologie qui m’ont aidés à identifier les domaines où les erreurs peuvent être facilement évitées. Pas étonnant, la clé d’une carrière de dev solide implique de la symétrie: ne pas rester trop longtemps avec la même stack technique ou le même job, mais aussi ne pas changer de langages et d’employeur si souvent que vous soulevez des drapeaux rouges.

Voici quelques-uns des pièges de carrière les plus remarquables pour les ingénieurs – un champ de mines que vous pouvez facilement éviter lorsque vous naviguez sur un marché qui change constamment.

Erreur n ° 1: Rester trop longtemps

De nos jours, il est rare d’avoir des décennies de développement en tant que développeur dans une entreprise. À bien des égards, c’est un insigne d’honneur qui montre votre importance pour l’entreprise ou, du moins, votre capacité à survivre et à prospérer. Mais ceux qui ont construit une carrière dans une seule entreprise peuvent soudainement se retrouver dans la mauvaise direction en termes de réduction des effectifs ou de «déstabilisation», selon le mot à la mode choisi à l’époque.

Les opinions varient sur combien de temps vous devriez rester dans une entreprise. Salaahadine, un consultant technique que j’ai rencontré à la banque de france a passé 10 ans en tant que développeur, n’a pas peur de jeter quelques chiffres.

«Plus longtemps tu resteras dans un poste, plus tes compétences et ton salaire stagneront», dit Salah. « D’un autre côté, si vous changez plusieurs emplois en moins de deux ans, cela envoie un drapeau rouge. Dans ma propre expérience, je suis resté trop longtemps sur un emploi où j’ai travaillé pendant 8 ans – j’aurais dû partir après 5 ans. J’ai quitté d’autres postes après une moyenne de quatre ans, ce qui est probablement juste ». Je vois deux inconvénients majeurs à rester trop longtemps au même endroit. D’abord, vous courez le risque de limiter votre exposition à de nouvelles approches et techniques, et d’autre part, votre réseau professionnel ne sera pas aussi profond ou aussi varié que quelqu’un qui change d’équipe ou d’entreprise.

Se concentrer trop sur la stack technique utilisée par votre employeur actuel est évidemment bon pour l’entreprise, mais peut-être pas pour vous. C’est un avantage pour les autres employeurs à la recherche d’un ensemble de compétences très spécialisées, et chaque entreprise est différente. Mais cela peut limiter votre croissance et vos connaissances dans d’autres domaines. Évidemment, rester quelques mois à chaque emploi n’est pas une bonne idée non plus pour votre curriculum vitae, mais le turn-over est assez élevé actuellement et les employeurs s’attendent à ce que les jeunes diplômés se déplacent un peu avant de rester à long terme dans une entreprise.

Erreur n ° 2: Changer d’employeur trop fréquemment

Regardons le revers: bougez-vous trop? Si c’est une préoccupation, vous pourriez vous demander si vous obtenez vraiment ce dont vous avez besoin de votre temps dans une entreprise. Ceux qui changent trop vite ne verront surement pas tout le cycle de vie du projet.

« Le danger est de devenir un mercenaire, et vous manquez l’opportunité d’avoir un sentiment d’appartenance à un groupe ou pour un produit et de construire des relations durables avec les gens ». Ceci n’est évidemment vrai que pour les salariés. Peu importe votre talent et votre compétence en tant que technologue, vous avez toujours besoin de pouvoir voir les choses du point de vue d’un utilisateur, et il faut du temps pour connaître les besoins des utilisateurs auxquels s’adresse votre logiciel et comment ils utilisent votre produit.

Erreur n ° 3: Accepter une promotion sans réfléchir

Il y a un point dans la vie de chaque développeur où vous vous demandez: Si vous aimez coder plus que manager, vous pourriez vous demander si rester en place pourrait bloquer votre carrière.

Passer à la direction devrait être une décision prudente et réfléchie. Le management est un changement de carrière – pas la progression logique d’un technologue – et nécessite un ensemble différent de compétences. En outre, j’ai vu de nombreuses entreprises pousser de bons talents techniques dans la gestion parce que la société pense que c’est une récompense pour l’employé, mais cela se révèle être une erreur à la fois pour ledit employé et l’entreprise.

Erreur n ° 4: Etre concentré uniquement sur sa progression technique

Une erreur moins évidente pourrait être de rester trop concentré sur votre propre carrière sans tenir compte des développeurs juniors dans votre bureau. Ceux qui se joignent à de jeunes programmeurs sont fréquemment sollicités lorsqu’une équipe a besoin de leadership.

J’ai découvert que le mentorat de jeunes développeurs m’a permis d’améliorer mon travail parce que vous vous améliorez profondément en enseignant que par n’importe quelle autre méthode. Et ceci quelque soit le domaine. En outre, comme les développeurs ont souvent des difficultés avec les compétences interpersonnelles, le mentorat offre de grandes opportunités pour vous permettre de vous améliorer dans ce sens. En d’autre terme, si l’expérience est le meilleur enseignant, enseigner aux autres ne fera qu’approfondir vos connaissances sur le sujet.

Erreur n ° 5: Rester collé à la même stack technique

Votre expertise en une stack technique peut vous rendre inestimable pour votre lieu de travail actuel – mais est-ce que cela aide votre carrière?

Pour ma part je pense que non, il n’y a pas de rôle de génie logiciel moderne dans lequel vous utiliserez une seule technologie pour la durée de votre carrière. Si vous prenez un développeur Java qui travaille en Java depuis 10 ans, et que tout d’un coup ils commencent à travailler sur une application JavaScript, ils l’écriront différemment de quelqu’un ayant des années d’expérience similaire en tant que développeur Python. Chaque technologie que vous apprenez influence vos décisions. Certains diront que ce n’est pas une bonne chose – si vous adoptez une approche orientée objet Java vers un langage mal typé comme JavaScript, vous essaierez de lui faire faire des choses qu’il n’est pas censé faire.

Chaque stack technique aura une culture et un point de vue différent qui lui est propre, ce qui permettra d’élargir et d’accélérer la croissance de votre carrière. Par exemple, je trouve que beaucoup de développeurs C # sont seulement conscients de l’écosystème de Microsoft, quand il y a un monde beaucoup plus large. Java a, sans doute, le meilleur écosystème, et je trouve souvent que les développeurs Java font les meilleurs développeurs C # parce qu’ils ont des perspectives plus large.  »

Moi je suis de ceux qui pensent que la compétence – mais pas la maîtrise – avec une stack technique devrait être la référence avant de passer à une autre. Il est temps de passer à autre chose lorsque vous y êtes doué et habile, mais pas nécessairement excellent. Comprenez moi bien. Je ne préconise pas la médiocrité, juste le contraire. Je dis qu’avant de partir pour apprendre une nouvelle compétence, assurez-vous d’être bon, compétent ou supérieur à la moyenne à cette compétence avant d’envisager d’aller de l’avant.

Évitez le piège des préjugéq selon lesquels chaque nouveau langage est simplement l’ancie avec une syntaxe différente. Les développeurs de C  et Java qui tentent de forcer JavaScript dans une approche orientée objet classique ont causé beaucoup de dégats.