Maturité professionnelle en TI : qu'est-ce qui sépare un Junior d'un Senior ?

Lorsqu’on parle de professionnels de la technologie, la discussion éternelle est de savoir à quel moment on passe d’un niveau à l’autre, combien de niveaux il y a, et ce qu’implique d’être à l’un ou à l’autre.

Niveaux en ingénierie. Où en suis-je ?

La première chose à clarifier est que, de manière générale, chaque entreprise a sa propre définition de ce qu’est un senior selon son échelle interne, et souvent, elles ont leurs propres niveaux. Certains systèmes, par exemple, gèrent :

Ingénieurs : L1, L2, L3, L4, L5
Stagiaire, Junior, Intermédiaire, Senior
Engineer I, Entry Level, Mid Level, Senior Engineer, Staff Engineer, Principal Engineer
Software Engineer, Senior Engineer, Staff Engineer, Principal Engineer, Distinguished Engineer / Fellow

Certains sonnent plus ronflants que d’autres, mais au final, ils ne veulent représenter qu’une chose : le niveau de maturité en tant qu’ingénieur logiciel, qui peut être mesuré par sa capacité à résoudre des problèmes de manière autonome, sa puissance d’analyse, sa pensée critique, sa compréhension des outils technologiques, ses connaissances en conception de systèmes, etc.

La première chose que je tiens à clarifier est que c’est un processus. On ne peut pas passer de manière accélérée d’un niveau initial à un niveau Senior sans avoir expérimenté et rencontré différentes problématiques.

Ici, sans vouloir entrer dans la polémique, il y a beaucoup de discussions autour de ceux qui se sont développés en autodidactes et ceux qui sont passés par une carrière professionnelle dans une université ou un institut. Au final, le résultat dépendra réellement de chacun.

J’ai rencontré des ingénieurs diplômés d’université qui en savaient très peu, tout comme des autodidactes qui pouvaient surpasser le meilleur élève de n’importe quelle institution éducative.

Compétences par niveau

Pour simplifier la compréhension, voici, de manière générale, ce que représente chacun des niveaux.

Junior

Nécessite une supervision.
Possède des connaissances de base en logiciel et matériel.
Maîtrise au moins un langage de programmation.
Participe à la planification initiale du projet.
Travaille sur des fonctions et outils logiciels internes.

Intermédiaire

Capable de réaliser des tâches techniques avec moins de supervision.
Comprend clairement le processus de développement, y compris l’analyse, le développement, l’implémentation, etc.
Peut configurer un environnement de développement par lui-même.
Identifie les erreurs lors de l’analyse de code, peut participer aux revues de code (peer reviews).
Peut implémenter des tests unitaires simples.

Senior

Peut superviser et diriger un groupe de développeurs.
Est capable de comprendre la portée d’un projet, de planifier et d’estimer le niveau d’effort.
Est un mentor pour les développeurs juniors et intermédiaires.
Prend en charge les revues de code de ses pairs.
Améliore la structure et la qualité du code.

Que faut-il apprendre pour avancer dans sa carrière ?

Bien que certaines choses ne puissent être acquises que par l’expérience, d’autres ont un chemin de croissance professionnelle assez clair. C’est d’ailleurs vers cela que de nombreuses entreprises cherchent à créer leurs niveaux d’ingénierie, afin de savoir comment orienter et faire progresser les professionnels sur cette voie.

Sans trop compliquer l’explication, voici quelques-unes des compétences que vous devez acquérir pour passer à un niveau supérieur :

Conception de systèmes
Analyse de la complexité d’un algorithme (Big-O)
Considérations d’évolutivité (Scalability)
Outils d’amélioration des performances

La première chose que certains vont probablement dire est : et quel langage dois-je apprendre ? Ou dois-je être expert dans un langage de programmation pour être senior ?

La réponse est : on vous embauche pour votre capacité à résoudre des problèmes, pas pour un langage spécifique, ou un diplôme accroché au mur.

Avec le temps, vous pouvez devenir « expert » dans un domaine ou une technologie, mais ce n’est pas une condition préalable pour être « Senior ». C’est plutôt l’expérience professionnelle et, ce que je considère personnellement comme le plus important, la clarté des concepts de base.

Dans l’une des entreprises où j’ai travaillé, on m’a dit : ce que nous recherchons, ce sont uniquement de bons ingénieurs ; le reste, je sais qu’ils pourront l’apprendre (en supposant que la première chose est vraie, qu’ils sont de bons ingénieurs). Et c’est vrai, avec de bonnes bases, le reste vient facilement.

Et par de bonnes bases, je me réfère à des éléments tels que :

Bien connaître la gestion des structures de données et des algorithmes.
Si c’est pour le web, connaître l’ingénierie web en profondeur.
Comprendre la gestion de SCM (Software Configuration Management) et le contrôle de versions.
Comprendre les patrons de conception (design patterns).
Connaître les principes du code propre et comment développer quelque chose de maintenable sur le long terme.

Tous ces concepts sont applicables à n’importe quel spectre, que ce soit avec une technologie spécifique ou un rôle dans un domaine particulier, que ce soit en front-end ou en back-end.

Mais ce n’est pas une simple question de temps, de dire qu’en 3, 5 ou 10 ans je serai senior. C’est aussi une question de s’exposer à davantage de situations où il faut apprendre plus et mettre ces choses en pratique.

Dans mon histoire personnelle, je le dois à ma grande curiosité, mais aussi au fait d’avoir travaillé longtemps dans des agences de développement, ce qui nous obligeait à connaître de nombreux scénarios et situations différents.

Seniority vs Spécialisation

Pour finir, ce qui est souvent confondu et que je mentionnais précédemment, c’est le fait d’être spécialisé dans un outil, un framework, un langage ou quelque chose de similaire.

Par exemple, si je travaille depuis 5 ans avec React et que je me suis spécialisé dans le développement d’applications headless, suis-je un Senior en React ? En théorie, c’est très probable, mais ce n’est pas une garantie, car cela dépendra du type d’expériences que l’on a eues pendant cette période.

Voici quelques questions qui me viennent à l’esprit pour y répondre :

Connaissez-vous en profondeur l’outil / le framework / le langage ?
Êtes-vous capable de prendre des décisions concernant la conception architecturale d’une application basée sur cette technologie ?
Connaissez-vous les problèmes courants et les solutions au sein de ce type de développements ?
Avez-vous une vision claire des avantages d’implémenter quelque chose en utilisant cet outil par rapport à n’importe quel autre, ou simplement sans l’utiliser ?

Ce ne sont peut-être pas les questions parfaites, mais si vous pouvez y répondre sans difficulté, alors oui, vous êtes un senior spécialisé dans cet outil ou langage spécifique.