Date originale d'écriture : 3/01/16 - Arnaud Duforat
Dans de nombreux secteurs, l'accession aux postes à responsabilité est principalement basée sur le nombre d'années d'expérience. Mais qu'est-ce qui définit exactement un "développeur senior" ? J'ai dû me poser cette question à de nombreuses reprises. Par exemple pour recruter d'autres personnes, en rencontrant d'autres développeurs ou en me posant la question pour moi-même pour décider de me définir comme senior. Ce terme n'est pas anodin. Nous connaissons certaines de ses caractéristiques générales, mais les détails restent importants. Et cela fait une différence, car le titre du poste détermine non seulement le salaire, mais aussi les perspectives de carrière. Quelqu'un fait peut-être du "travail de développeur senior", mais s’il veut devenir architecte de logiciels, cela peut lui porter préjudice de ne pas avoir le titre. D'un autre côté, si on me dit que nous recherchons un développeur senior et que la personne qui, à mon avis, convient pour le poste, n'en est pas un, je le regretterai.
Pour commencer avec la terminologie Senior vs Junior : je n'aime pas très bien ces descriptions / titres. Il y a toujours quelqu'un de plus senior et toujours plus de junior avec une grande diversité de compétences.
Je préfère les désignations d'apprenti / compagnon / maître qui proviennent des artisans - quoique je ne tienne pas en très haute estime le mouvement de "l'artisanat as code", j'en parlerai certainement dans un autre article. Je ne laisserai pas un apprenti travailler seul. Si l'on doit impacter significativement le système, deux apprentis pourront travailler ensemble. Ils n’apprendraient pas non plus aussi rapidement que s’ils travaillaient avec une personne plus qualifiée.
Je considère également ces désignations pour diverses spécialités au sein du développement logiciel. Vous pouvez par exemple être un maître en informatique, un compagnon en SQL et un apprenti en concurrence / architecture distribuée.
Voici quelques-unes des qualifications de base qu'un développeur senior devrait posséder : un nombre d'année important d’expérience dans le domaine de la programmation, une solide connaissance de la théorie et d'excellentes aptitudes au débogage. Il devrait également pouvoir : travailler en étroite collaboration avec l'architecte logiciel pour suggérer des améliorations dans le cadre de la vision globale du projet ; poser des questions concernant l'architecture ; et servir de conseiller et de mentor pour les développeurs moins expérimentés. Vous devriez également pouvoir lui faire confiance pour transformer un ensemble de diagrammes de classes en code de qualité avec un minimum de suivi.
Mais est-il préférable d'avoir, par exemple, un développeur senior avec quatre ans d'expérience de Java et huit ans d'expériences diverses plutôt qu'un développeur ayant fait uniquement du Java ? J'imagine que 12 années de travail avec Java ont certainement fait de cette personne un expert de Java. D'autre part, quelqu'un qui a passé ces 12 mêmes années à rebondir autour de Java, C++, JS et C# dispose d'un éventail d'expériences beaucoup plus vaste. Personnellement, je suis attiré par ce dernier simplement parce que cela ressemble plus à ma propre expérience, mais je pense que le premier itinéraire présente également de nombreux avantages.
En outre, une personne qui passe autant de temps sur des applications client / serveur traditionnelles que sur des applications Web a-t-elle le même poids que celle qui a passé le même temps à travailler exclusivement avec des applications Web ? La personne client / serveur a accès à de nombreuses solutions aux problèmes des applications Web, mais la personne exclusivement Web peut avoir une vision unique des bizarreries bizarres du développement Web. Encore une fois, il existe un compromis entre un spécialiste et un généraliste, les deux ayant une durée égale dans le secteur.
J'aimerais pouvoir ignorer l'aspect autodidacte par rapport à l'aspect d'éducation formelle, et c'est ce que je fais habituellement. Seulement être développeur senior demande une quantité suffisante de théorie et il s'agit d'un sujet plus facile à apprendre à l'école que seul. Il faut donc veiller à ce que les autodidactes qui ont appris trop de mauvaises habitudes en contexte d'entreprise et les personnes qui ont dormi pendant leurs études aient intégrés les fondements théoriques nécessaires.
Le dernier obstacle majeur concerne les personnes qui ont passé suffisamment de temps sur le marché du travail pour être considérées comme des seniors, mais qui n'ont jamais travaillé sur quelque chose de plus compliqué qu'une simple application CRUD. Pour autant que je sache, ils ont été tellement ancrés dans cette application CRUD qu'ils connaissent parfaitement son métier, que leur projet soit bien documenté ou non. Ils ont souvent une connaissance pratique avancé des différents enjeux d'un projet mais n'ont pas forcement eu l'occasion de les remettre en cause. Et cette remise en cause est un élément marquant de l'apprentissage d'un développeur senior.
Par ailleurs, je ne voudrais pas oublier les gens d'expérience qui sont indirectement liés à la programmation et pourtant très utiles. Par exemple, j'ai constaté que les connaissances d'administration système et réseau étaient essentielles pour le débogage de nombreuses applications et pour le déploiement. Comment l'expérience hors du développement s'inscrit-elle dans le poste de développeur senior ?
En laissant de côté cette dernière considération, il y a la question de la personnalité. Suis-je disposé à supporter quelqu'un qui n'a pas une personnalité agréable mais qui possède des compétences techniques incroyables ? Ou bien les responsabilités de leadership d'un développeur senior permettent-elles à quelqu'un qui est un "candidat idéal" de compenser une lacune technique ?
Après avoir dit tout cela, vient la question de lister les compétences attendues d'un développeur senior :
Avant de terminer, j'aimerais mettre en avant un énorme écueil : le mythe du nombre d'années d'expériences.
Ce mythe toxique et contre-productif a imprégné l'industrie du logiciel aussi longtemps que je me souvienne. Imaginez combien de brillants éditeurs de logiciels ont faillis exploser en vol parce qu’ils sont complètement obsédés par la recherche de personnes qui correspondent, à la lettre, à une liste très spécifique de compétences.
D'une certaine manière, ils ont oublié que ce que les développeurs font de mieux, c'est d'apprendre. Les employeurs devraient être à la recherche d'auto-éducateurs passionnés, motivés et flexibles, et de leur proposer des projets intéressants dans lesquels ils peuvent s'engager - je parle d'auto-éducateurs plutôt que d'autodidactes car je ne remets pas en cause les études.
Il a été démontré à maintes reprises qu'il n'y avait pas de corrélation entre des années d'expérience et des compétences en programmation. Après environ six à douze mois de travail dans une technologie donnée, vous la connaissez ou non. Peu importe combien d'années d'expérience un autre programmeur a à son actif, il y a même des chances qu'il n'ait aucune idée de ce qu'il fait. C'est pourquoi j'ai appris rapidement à voir mes pairs avec un certain degré de scepticisme. Peut-être est-ce la seule réponse rationnelle lorsque le fossé entre l'expérience et les compétences est si omniprésent dans le domaine du génie logiciel.
Cela signifie que vous, en tant que candidat, pouvez utiliser des exigences telles que "3-5 ans pour utiliser cette technologie" comme indicateur de la connaissance de l'embauche de la société. Plus leurs exigences en termes d'années de service dans une technologie donnée sont élevées, plus elles sont susceptibles de rechercher toutes les mauvaises choses chez leurs candidats, et donc il est plus probable que le reste de l'équipe soit choisi par leurs comparses pour les mauvaises raisons.
Je ne dis pas que l'expérience n'a pas d'importance dans le développement logiciel. Mais considérons toute la gamme de l'expérience d'un développeur et réalisons que le temps investi n'est pas automatiquement synonyme de compétence. Sinon, vous rejetterez peut-être d'excellents ingénieurs en logiciels simplement parce qu'ils manquent "(n) d'années d'expérience" dans votre petit créneau technologique étroit - et c'est vraiment dommage.
Autre point à se rappeler, peu importe ce que vous vous considérez être, c'est ce que les autres pensent de vous qui déterminera si vous êtes senior.
Si vous êtes un programmeur qui ne peut rien faire par lui-même, ne peut pas se débrouiller tout seul et qui produit du code bogué, alors vous ne serez jamais senior.
Si vous faites preuve d'initiative, que vous accomplissez des tâches importantes, que vous aidez les autres, que vous avancez continuellement dans vos connaissances, même si vous écrivez ce type de code pour la première fois, les gens commenceront à vous respecter.
J'ai souvent entendu dire qu'il faut 10 000 heures de pratique pour être expert en quelque chose - j'en reparlerai plus bas. Cependant, toutes les heures d'expérience ne sont pas égales. Si vous passez une heure à faire quelque chose en dehors de votre zone de confort, vous en apprendrez beaucoup plus que si vous passiez cette heure à faire quelque chose de facile ou que vous avez souvent fait. Donc, dans la plupart des cas, les 3 à 7 ans de maison ont raison.
Les gens qui aiment la programmation et les nouveaux défis y arriveront plus rapidement. Les personnes qui considèrent la programmation comme un travail temporaire prendront plus de temps. Les personnes qui évitent les nouveaux défis peuvent ne jamais y arriver du tout.
En fin de compte, le temps est moins important que la connaissance. Je pense que vous pouvez vous considérer comme développeur senior lorsque vous avez travaillé sur un assez grand nombre de projets et que vous connaissez bien tous les composants que vos programmes touchent (langages, système d'exploitation, SQL, réseau, etc.) suffisamment pour que vous puissiez prendre connaissance d'un nouveau projet et dire : "Nous pouvons le résoudre avec X, Y ou Z et voici les risques et les avantages de chacun".
Si vous souhaitez tout de même vous baser sur la durée d'expérience, quelle durée est nécessaire pour devenir senior ?
Que veut dire maîtrise ? Il est généralement admis que pour maîtriser toutes les compétences, il faut 10 000 heures de répétition du corps et de l'esprit pour saisir et intérioriser une compétence. Ceci est écrit en détail dans le livre Outliers de Malcolm Gladwell. Lorsque l'auteur original a parlé de maîtriser un domaine, il pensait qu'il faudrait 10 000 heures pour atteindre le sommet d'un domaine très concurrentiel.
Voici quelques exemples issus d'Outliers :
Mozart crée son premier concerto à l'âge de 21 ans. Cela semble au premier abord jeune, mais il composait depuis l'âge de 11 ans.
Les Beatles ont d'abord été mis de côté. On leur a dit qu'ils n'avaient pas le style et qu'ils devraient envisager un travail différent. Ils décident alors de passer 3 ans en Allemagne à jouer environ 1200 fois dans des lieux différents, chaque fois pour une durée de 5 à 8 heures. Ils sont alors devenus les Beatles que nous connaissons.
Enfin, Bill Gates, âgé de 20 ans, a quitté Harvard pour fonder Microsoft. Pour certains, cela peut sembler idiot, mais à 20 ans, il avait passé près de la moitié de sa vie à programmer. En 1975, seulement une cinquantaine de personnes dans le monde avait l'expérience qu'il avait acquise. Son expérience lui a permis d'assurer la position qu'il avait dans Microsoft.
Peter Norvig discute également de la règle des 10000 heures dans son essai "Apprenez à programmer en dix ans".
Dans le livre Mastery de George Leonard, de nombreux détails sont fournis sur la manière de maîtriser une compétence. Il faut pratiquer la compétence maintes et maintes fois. Plus vous répétez, plus vous prenez conscience des différences entre chaque répétition. Ce n'est qu'en le remarquant que vous pouvez devenir meilleur.
Les titres de l’industrie du logiciel (débutants, intermédiaires et seniors) sont trompeurs et incohérents d’une organisation à l’autre. J’ai travaillé avec des entreprises qui ont défini un développeur senior comme une personne ayant 5 ans ou plus d’expérience. Il n’y a aucune mention de la qualité de l’expérience. Il faut s'assoir devant un ordinateur pendant 5 ans.
Nous travaillons dans une industrie étrange. Le besoin de développeurs est bien plus grand que l'arrivée de nouveaux développeurs sur le marché du travail. Ce problème existe depuis des années et il s'aggrave de jour en jour.
Nous manquons cruellement de talents pour répondre à la demande, mais notre industrie est vraiment très jeune. La plupart des projets logiciels de l'industrie échouent. Les budgets sont rarement respectés. Le meilleur conseil que nous ayons à ce sujet de la part des leaders intellectuels se résume à : "Il existe des moyens de résoudre ces problèmes, mais nos solutions ne fonctionnent souvent pas. Par conséquent, la seule chose que vous pouvez vraiment faire est d'essayer et de voir si cela fonctionne pour vous".
La réalité dans laquelle nous vivons est que "développeur senior" désigne une personne qui code depuis plus de 3 ans. Ces personnes occupent des postes à responsabilité et, généralement, les choses se déroulent comme prévu - très mal.
Les systèmes construits par des développeurs intermédiaires non supervisés vont échouer pour des raisons complètement différentes de celles des systèmes construits par des juniors. Un junior construira à partir d’algorithmes simples. Un bon intermédiaire construira à partir de "Design Patterns" et de "Domain Driven Design". Bien que les livres du domaine soient excellents pour apprendre à construire de grands systèmes OO, l’application directe de ce type de théorie donne des systèmes trop sophistiqués, flexibles d’une manière qui n’a pas d’importance et inflexibles dans les cas utiles.
Vous pouvez faire confiance à un intermédiaire pour construire des systèmes qui fonctionneront bien plus longtemps qu'un junior, mais qui entraîneront un autre type de catastrophe à l'avenir. La triste réalité est que non seulement la grande majorité des développeurs expérimentés, mais également les chefs d’équipe sont des développeurs intermédiaires. La plupart ne le réalisent pas et ont les meilleures intentions, mais ils n'ont tout simplement jamais travaillé avec quelqu'un qui se situe à un meilleur niveau.