Comment devenir un développeur junior, intermédiaire ou senior ?

Par Rédacteur de l'équipe - il y a 2 mois / avr 2020
Comment devenir un développeur junior, intermédiaire ou senior ?

J'ai travaillé à la refonte des feuilles de route - en divisant l'ensemble des compétences en fonction des niveaux d'ancienneté pour les rendre plus faciles à suivre et ne pas effrayer les nouveaux développeurs. Comme les feuilles de route ne porteront que sur les connaissances techniques, j'ai pensé que ce serait une bonne idée de répéter et de publier un article sur ce que je pense des différents rôles d'ancienneté.

J'ai vu de nombreuses organisations décider de l'ancienneté des développeurs en donnant plus d'importance qu'il ne faut aux années d'expérience. J'ai vu des développeurs étiquetés "Junior" faire le travail de développeurs seniors et j'ai vu des développeurs "Lead" qui n'étaient même pas qualifiés pour être appelés "Senior". L'ancienneté d'un développeur ne peut pas être simplement déterminée par son âge, ses années d'expérience ou les connaissances techniques qu'il a acquises. D'autres facteurs entrent en jeu : leur perception du travail, leur interaction avec leurs pairs et leur façon d'aborder les problèmes. Nous discutons en détail de ces trois facteurs clés pour chacun des niveaux d'ancienneté ci-dessous.

Différents titres d'ancienneté

Les différents organismes peuvent avoir des titres d'ancienneté différents, mais ils se répartissent principalement en trois catégories :

  • Développeur junior
  • Développeur de niveau intermédiaire
  • Développeur principal

Développeur junior

Les développeurs juniors sont normalement de jeunes diplômés et soit ils n'ont pas, soit ils ont une expérience minimale de l'industrie. Non seulement ils ont de faibles compétences en matière de codage, mais il y a aussi d'autres choses qui font que les développeurs juniors sont perdants :

  • Leur principal mantra est de "faire en sorte que ça marche" sans accorder beaucoup d'attention à la manière dont la solution est obtenue. Pour eux, un logiciel qui fonctionne et un bon logiciel sont équivalents.
  • Elles nécessitent généralement des orientations très spécifiques et structurées pour parvenir à quelque chose. Ils souffrent d'une vision étroite, ont besoin d'être supervisés et guidés en permanence pour être des membres d'équipe efficaces.
  • La plupart des développeurs juniors essaient simplement d'être à la hauteur de leur rôle et, lorsqu'ils sont bloqués, ils peuvent quitter leur travail pour un développeur senior au lieu d'essayer au moins de tenter quelque chose.
  • Ils ne connaissent pas le côté commercial de l'entreprise et ne réalisent pas comment la direction/les ventes/le marketing/etc pensent et ils ne réalisent pas combien de travail, d'efforts gaspillés et d'aggravation de la situation de l'utilisateur final pourraient être évités en apprenant à connaître le domaine commercial.
  • La suringénierie est un problème majeur, qui entraîne souvent la fragilité et les bugs.
  • Lorsqu'ils sont confrontés à un problème, ils essaient souvent de régler le problème actuel, c'est-à-dire de régler les symptômes au lieu de régler le problème à la racine.
  • Vous remarquerez peut-être chez eux le comportement "Problème de quelqu'un d'autre".
  • Ils ne savent pas quoi ou combien ils ne savent pas, grâce à l'effet Dunning-Kruger.
  • Ils ne prennent pas d'initiatives et peuvent avoir peur de travailler sur une base de code inconnue.
  • Ils ne participent pas aux discussions d'équipe.

Être un développeur junior dans l'équipe n'est pas nécessairement une mauvaise chose ; comme vous débutez, on n'attend pas de vous que vous soyez une personne qui sait tout. Cependant, il est de votre responsabilité d'apprendre, d'acquérir de l'expérience, de ne pas rester bloqué avec le titre de "Junior" et de vous améliorer. Voici quelques conseils aux développeurs Junior pour les aider à gravir les échelons de l'ancienneté :

  • Toutes sortes de problèmes peuvent être résolus si vous y travaillez suffisamment longtemps. N'abandonnez pas si le débordement de la pile ou un problème sur GitHub n'a pas de réponse. Dire "Je suis coincé, mais j'ai essayé X, Y et Z. Avez-vous des indications ?" pour vous guider est bien mieux que de dire "Cela me dépasse".
  • Lisez beaucoup de code, pas seulement le code des projets sur lesquels vous travaillez, mais le code source de référence/cadre, open-source. Demandez à vos collègues développeurs, peut-être aussi sur Reddit, de vous fournir de bons exemples de code source libre pour le ou les outils de votre choix.
  • Réaliser des projets secondaires personnels, les partager avec les gens, contribuer à la communauté open-source. Cherchez de l'aide auprès des gens. Vous serez surpris de l'ampleur du soutien que vous pouvez obtenir de la communauté. Je me souviens encore de mon premier projet open-source sur GitHub, il y a environ 6 ans. Il s'agissait d'un petit script PHP (une bibliothèque) qui récupérait les détails d'une adresse donnée à partir de l'API de géocodage de Google. La base de code était très compliquée, il n'y avait pas de tests, pas de linters ni de sniffers, et il n'y avait pas d'IC parce que je ne savais rien de tout cela à l'époque. Je ne sais pas trop comment, mais une seule personne a trouvé le projet, l'a bifurqué, l'a remanié, l'a "modernisé", a ajouté des doublons, a reniflé le code, a ajouté des IC et a ouvert la demande d'extraction. Cette demande m'a appris tellement de choses que je n'aurais peut-être jamais pu apprendre aussi vite par moi-même, car j'étais encore à l'université, je travaillais pour une petite société de services et je ne faisais que des petits sites web tout seul, sans savoir ce qui est bien et ce qui ne l'est pas. Ce reportage sur GitHub a été mon introduction à l'open-source et c'est à cela que je dois tout.
  • Évitez ce que l'on appelle le comportement du "champ de problèmes de quelqu'un d'autre".
  • Lorsqu'on vous donne un problème à résoudre, essayez d'en identifier la cause profonde et de la résoudre au lieu de régler les symptômes. Et n'oubliez pas que ne pas pouvoir se reproduire signifie que le problème n'est pas résolu. Le problème est résolu lorsque vous comprenez pourquoi il s'est produit et pourquoi il ne se produit plus.
  • Respectez le code qui a été écrit avant vous. Soyez généreux lorsque vous portez un jugement sur l'architecture ou les décisions de conception prises dans la base de code. Comprenez que le code est souvent laid et bizarre pour une raison autre que l'incompétence. Apprendre à vivre et à s'épanouir avec le code existant est une grande compétence. Ne jamais supposer que quelqu'un est stupide. Essayez plutôt de comprendre comment ces personnes intelligentes, bien intentionnées et expérimentées en sont arrivées à une décision qui est maintenant stupide. Approchez l'héritage du code avec un "esprit d'opportunité" plutôt que de vous plaindre.
  • Il est normal de ne pas savoir les choses. Vous n'avez pas à avoir honte de ne pas savoir les choses déjà. Il n'y a pas de questions stupides, mais posez toutes les questions qui vous permettront de travailler efficacement.
  • Ne vous laissez pas limiter par le titre du poste que vous occupez. Continuez à travailler à votre amélioration personnelle.
  • Faites vos devoirs. Prévoyez ce qui va arriver. Participez aux discussions de l'équipe. Même si vous vous trompez, vous apprendrez quelque chose.
  • Renseignez-vous sur le domaine dans lequel vous travaillez. Comprendre le produit de bout en bout en tant qu'utilisateur final. Ne faites pas d'hypothèses, posez des questions et clarifiez les choses en cas de doute.
  • Apprenez à communiquer efficacement - les compétences relationnelles sont importantes. Apprenez à rédiger de bons courriels, à présenter votre travail, à formuler vos questions de manière réfléchie.
  • Asseyez-vous avec les développeurs seniors, regardez-les travailler, trouvez un mentor. Personne n'aime les je-sais-tout. Maîtrisez votre ego et soyez assez humble pour prendre des leçons auprès de personnes expérimentées.
  • Ne vous contentez pas de suivre aveuglément les conseils des "experts", prenez-les avec un grain de sel.
  • Si l'on vous demande de fournir une estimation pour certains travaux, ne donnez pas de réponse à moins que vous ne disposiez de tous les détails pour faire une estimation raisonnable. Si vous êtes obligé de le faire, remplissez le formulaire 2 fois ou plus selon ce que vous ne savez pas sur ce qui doit être fait pour que la tâche soit marquée "fait".
  • Prenez un peu de temps pour apprendre à utiliser un débogueur. Les débogueurs sont très utiles pour naviguer dans des bases de données nouvelles, non documentées ou mal documentées, ou pour déboguer des problèmes bizarres.
  • Évitez de dire "ça marche sur ma machine" - oui, j'ai souvent entendu cela.
  • Essayez de transformer tout sentiment d'inadéquation ou syndrome d'imposteur en énergie pour vous pousser en avant et augmenter vos compétences et connaissances.

Développeurs de niveau intermédiaire

Le niveau suivant après les développeurs juniors est celui des développeurs de niveau intermédiaire. Ils sont techniquement plus forts que les développeurs juniors et peuvent travailler avec un minimum de supervision. Ils ont encore quelques problèmes à régler pour passer au niveau Senior.

Les développeurs intermédiaires sont plus compétents que le développeur junior. Ils commencent à voir les défauts de leur ancienne base de code. Ils acquièrent des connaissances mais ils se retrouvent piégés dans la chaîne suivante, c'est-à-dire qu'ils mettent la pagaille en essayant de faire les choses "de la bonne manière", par exemple en faisant des abstractions hâtives, en abusant ou en utilisant inutilement des Design Patterns. Ils peuvent être en mesure de fournir une solution plus rapidement que les développeurs junior, mais la solution pourrait à la longue vous mettre dans un autre trou de souris. Sans supervision, ils pourraient retarder l'exécution tout en essayant de "faire les choses correctement". Ils ne savent pas quand faire des compromis et ils ne savent toujours pas quand être dogmatique et quand être pragmatique. Ils peuvent facilement s'attacher à leur solution, devenir myopes et être incapables d'accepter un retour d'information.

Les développeurs de niveau intermédiaire sont assez courants. La plupart des organisations les qualifient à tort de "développeurs seniors". Cependant, ils ont besoin d'un encadrement supplémentaire pour devenir des développeurs seniors. La section suivante décrit les responsabilités d'un développeur senior et comment vous pouvez le devenir.

Développeurs seniors

Les développeurs seniors sont le niveau suivant après les développeurs de niveau intermédiaire. Ce sont les personnes qui peuvent faire les choses par elles-mêmes sans aucune supervision et sans créer de problèmes à l'avenir. Ils sont plus mûrs, ont acquis de l'expérience en fournissant des logiciels, bons ou mauvais, dans le passé et en ont tiré des leçons - ils savent être pragmatiques. Voici la liste des choses que l'on attend normalement d'un développeur principal :

  • Grâce à leurs expériences passées, aux erreurs commises, aux problèmes rencontrés par les logiciels surconçus ou sous-conçus, ils peuvent prévoir les problèmes et persuader de l'orientation de la base de code ou de l'architecture.
  • Ils n'ont pas le syndrome du "Shiny-Toy". Ils sont pragmatiques dans l'exécution. Ils peuvent faire des compromis lorsque cela est nécessaire, et ils savent pourquoi. Ils savent où il faut être dogmatique et où il faut être pragmatique.
  • Ils ont une bonne idée du domaine, savent quel est le meilleur outil pour le travail dans la plupart des cas (même s'ils ne connaissent pas l'outil). Ils ont la capacité innée de prendre un nouvel outil/langue/paradigme/etc afin de résoudre un problème qui le nécessite.
  • Ils savent qu'ils font partie d'une équipe. Ils considèrent que cela fait partie de leur responsabilité d'encadrer les autres. Cela peut aller de la programmation en binôme avec des développeurs débutants à la prise en charge de tâches peu glorieuses comme la rédaction de documents ou de tests ou tout ce qui doit être fait.
  • Ils ont une connaissance approfondie du domaine - ils connaissent le côté commercial de l'entreprise et réalisent comment la direction/les ventes/le marketing/etc pensent et bénéficient de leur connaissance du domaine commercial pendant le développement.
  • Ils ne se plaignent pas en vain, ils portent des jugements fondés sur des preuves empiriques et proposent des solutions.
  • Ils pensent beaucoup plus que le code - ils savent que leur travail consiste à fournir des solutions aux problèmes et pas seulement à écrire du code.
  • Ils ont la capacité de s'attaquer à de grands problèmes mal définis, de les définir, de les décomposer et d'en exécuter les pièces. Un développeur senior peut prendre quelque chose de gros et d'abstrait et le faire fonctionner. Il proposera quelques options, en discutera avec l'équipe et les mettra en œuvre.
  • Ils respectent le code qui a été écrit avant eux. Ils sont généreux lorsqu'ils portent un jugement sur l'architecture ou les décisions de conception prises dans la base de code. Ils abordent l'héritage du code avec un "esprit d'opportunité" plutôt que de se plaindre.
  • Ils savent comment donner un retour d'information sans blesser personne.

Conclusion

Toutes les équipes sont composées d'un mélange de tous ces rôles d'ancienneté. Être satisfait de son rôle est une mauvaise chose et il faut toujours s'efforcer de s'améliorer pour l'étape suivante. Cet article est basé sur mes convictions et mes observations dans l'industrie. Beaucoup d'entreprises se soucient davantage des années d'expérience pour décider de l'ancienneté, qui est une mesure merdique - on n'acquiert pas de l'expérience simplement en passant des années. On l'acquiert en résolvant continuellement différents types de problèmes, quel que soit le nombre d'années passées dans l'industrie. J'ai vu de jeunes diplômés n'ayant aucune expérience de l'industrie se mettre rapidement à niveau et produire un travail d'ingénieur senior et j'ai vu des développeurs seniors étiquetés "senior" simplement en raison de leur âge et de leurs "années d'expérience".

Les traits les plus importants que vous devez posséder pour progresser dans votre carrière sont les suivants : ne pas se contenter de la médiocrité, avoir un esprit ouvert, être humble, apprendre de ses erreurs, travailler sur les problèmes difficiles et avoir un esprit d'opportunité plutôt que de se plaindre.

Cela dit, ce poste arrive à son terme. Que pensez-vous des niveaux d'ancienneté des développeurs ? N'hésitez pas à envoyer des améliorations à ce guide. En attendant la prochaine fois, restez à l'écoute !


Cet article a été initialement publié sur https://roadmap.sh le 3 décembre 2019 et a été écrit par Kamran Ahmed : https://roadmap.sh/guides/levels-of-seniority Veuillez noter que l'autorisation d'utiliser le contenu a été accordée à l'auteur sur Twitter avant la publication.





Rédacteur de l'équipe
Rédacteur de l'équipe
Blogs de curateurs pour cdrrazan.com ! Principalement code, linux et tech pour aider les étudiants et les professionnels.


commentaires alimentés par Disqus