Quand devriez-vous vous appeler développeur senior?
Duplicata possible:
Quelle est la différence entre les développeurs Entry Level/Jr/Sr?
Je suis curieux de savoir ce que signifie développeur principal, car apparemment, la définition ne signifie pas ce que je pensais. Je continue de voir ces adolescents à 22-23 ans qui se disent développeur X senior ou développeur Y senior. Pour moi, une personne âgée doit avoir une dizaine d'années d'expérience en programmation pour s'appeler "senior". J'ai vu beaucoup de ces adolescents ici (d'où la question). Ai-je tort? Pourquoi?
Vous pouvez vous appeler un senior lorsque:
- Vous pouvez gérer l'intégralité du cycle de vie du développement logiciel, de bout en bout
- Vous dirigez les autres ou d'autres se tournent vers vous pour obtenir des conseils.
- Vous pouvez gérer vous-même vos projets
Le développement de logiciels est une créature curieuse contrairement à d'autres domaines.
Parfois, un nouveau punk sortant de l'université peut faire le tour des vétérans qui ont plus de 20 ans "d'expérience". La programmation est un monde bizarre où le code est roi.
Certains atteignent ce qui précède en 2 ans ou moins, d'autres prennent 10 ans.
Quand j'entends "développeur senior", je pense à quelqu'un qui maîtrise la programmation. Je pense à une personne qui peut concevoir, coder et tester un système. Ils peuvent parler d'architecture système ou de conception de composants. Ils comprennent et utilisent les modèles de conception. Cette personne peut anticiper les goulots d'étranglement des performances, mais sait ne pas pré-optimiser. Cette personne tirera parti de la programmation asynchrone, de la mise en file d'attente, de la mise en cache, de la journalisation, de la sécurité et de la persistance, le cas échéant. Lorsqu'on leur demande, ils peuvent donner une explication détaillée de leur choix et des avantages et inconvénients. Dans la plupart des cas, ils maîtrisent la programmation et la conception orientées objet, ce n'est pas un absolu, d'autres langages tels que Javascript, F #, Scheme sont puissants et ne sont pas orientés objet. Ils sont adeptes de la gestion des risques et, surtout, ils peuvent communiquer ce qui précède à leurs pairs.
Qu'est-ce que la maîtrise? Il y a une idée généralement acceptée, que pour maîtriser n'importe quelle compétence, il faut 10 000 heures de répétition pour que le corps et l'esprit humain saisissent et intériorisent une compétence. Ceci est écrit en détail dans le livre de Malcolm GladWell Outliers . Lorsque l'auteur d'origine a parlé de maîtriser un domaine, il se référait pour atteindre le sommet d'un domaine hautement compétitif prendrait 10 000 heures.
Voici quelques exemples de valeurs aberrantes de Malcolm GladWell:
Mozart son premier concerto à l'âge de 21 ans. Ce qui semble au premier abord jeune, mais il écrit de la musique depuis l'âge de 11 ans.
Les Beatles ont d'abord été évités. On leur a dit qu'ils n'avaient pas de moutarde et qu'ils devraient envisager une autre ligne de travail. Ils passent 3 ans en Allemagne à jouer environ 1200 fois sur différents sites, chaque fois de 5 à 8 heures. Ils sont réapparus comme les Beatles que nous connaissons et aimons aujourd'hui.
Et enfin, Bill Gates à 20 ans a quitté Harvard pour fonder Microsoft. Pour certains, cela peut sembler stupide, mais considéré à 20 ans, il avait passé près de la moitié de sa jeunesse à programmer. En 1975, seulement peut-être 50 personnes dans le monde ont eu l'expérience qu'il a vécue. Son expérience lui a donné la prévoyance de voir l'avenir de Microsoft.
Peter Norvig discute également de la règle des 10 000 heures dans son essai " Teach Yourself Programming in Ten Years ".
Dans le livre Mastery de George Leonard, de grands détails sont donnés sur la façon de maîtriser une compétence. On doit pratiquer la compétence encore et encore et encore. Plus la répétition est importante, plus vous vous rendez compte des différences dans chaque répétition. Ce n'est qu'avec cette perspicacité que vous pouvez devenir meilleur.
Les titres de l’industrie du logiciel (Junior, Mid-Level 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, juste qu'ils se sont assis devant un ordinateur pendant 5 ans. En travaillant avec ces gens, beaucoup d'entre eux n'avaient pas encore saisi la programmation orientée objet - pourtant ils étaient considérés comme des développeurs seniors.
Il doit y avoir une meilleure façon plus objective de mesurer l'ensemble des compétences d'un ingénieur logiciel. John Haugeland a publié la matrice de compétences d'un programmeur informatique. C’est un moyen objectif de mesurer un niveau de compétence du programmeur , qui autrement est laissé à l’intuition.
Lorsque je regarde les ingénieurs logiciels, je vois 4 niveaux de compétences: Luminary, Senior, Mid-Level et Junior.
Luminary (10+ ans) est celui qui a maîtrisé une compétence et a entrepris d'améliorer leur discipline respective. Quelques exemples: Ted Neward , Oncle Bob Martin , Donald Knuth, Oren Eini , Peter Norvig , Linus Torvalds . Les luminaires changent en fonction de vos compétences.
Senior (7 à 10+ ans, niveau 3) est celui qui a passé les 10 000 dernières heures à programmer dans un genre spécifique. Il existe une solide compréhension des modèles de conception. Ils tirent parti de la programmation asynchrone, de la mise en file d'attente, de la mise en cache, de la journalisation, de la sécurité et de la persistance, le cas échéant.
Il est très possible qu'un Senior n'atteigne jamais le Luminaire. On trouve souvent des luminaires qui parlent et écrivent. Ils essaient activement d'avoir un impact sur leur discipline.
Le niveau intermédiaire (4 à 6 ans, niveau 2) est celui qui comprend la programmation quotidienne. Ils travaillent indépendamment et créent des solutions robustes. Cependant, ils n'ont pas encore expérimenté la création ou la maintenance de systèmes volumineux ou complexes. En général, les développeurs de niveau intermédiaire sont parfaits pour le développement au niveau des composants.
Junior (1 à 3 ans, niveau 1) est celui qui comprend les bases de la programmation. Ils sont soit diplômés en génie logiciel ou en informatique, soit autodidactes. Leur code est continuellement révisé. Des conseils sont donnés en ce qui concerne les algorithmes, la maintenabilité et la structure.
"Quand devriez-vous vous appeler développeur senior?" - Quand j'ai commencé à encadrer des développeurs juniors.
J'ai remarqué la même tendance. L'autre jour, l'une des questions portait sur un développeur senior avec 2-3 ans d'expérience pour devenir architecte.
Vous pouvez appeler un gland un arbre, mais cela ne change pas ce que c'est.
La seule conclusion logique est que "senior" signifie autre chose:
- rang relatif, comme dans "senior au gars qui vient de sortir de l'université"
- pauvres orthographes espagnols, c'est-à-dire qu'ils voulaient mettre le señor
- orthographe sudiste, comme dans "senior butt-crack, pull up them pants"
De nos jours, c'est juste un titre de poste, et peut ou ne dit rien sur l'expérience relative de l'industrie.
vous manquez le point.
Senior ne veut rien dire. Junior ne veut rien dire. Les titres ne veulent rien dire. Mon titre - Directeur adjoint des systèmes commerciaux. Mes responsabilités - gérer tout ce qui concerne l'informatique, du développement de logiciels internes à l'infrastructure, en passant par la sécurité, jusqu'aux sites Web des clients. Mon expérience en développement logiciel - autodidacte. Mon expérience de réseau - autodidacte. Mes capacités générales dans le domaine informatique - pires que les vôtres.
Ma capacité à gérer et à diriger - discutable, mais mon caractère et ma personnalité m'ont donné le poste et me font réussir.
Les titres ne signifient rien de capacité et d'effort signifie tout. Je ne suis pas le meilleur - et le croire serait arrogant.
Oubliez vos accrochages sur les titres et prouvez votre valeur!
Je pense la meilleure réponse a été donnée par Darknight .
Je ressens le besoin de souligner ce qui suit.
2-3 ans d'expérience en programmation (travail + personnel ensemble) ne sont tout simplement pas suffisants pour avoir vu un nombre suffisant de projets et traité un nombre suffisant de problèmes. Ne fonctionnera tout simplement pas. Vous avez besoin de temps pour laisser les choses passer par votre tête, pour réfléchir sur votre expérience et pour passer mentalement à un niveau de pensée supérieur. Ça n'arrive pas du jour au lendemain.
Je dirais que sous 5-7 ans de pratique (encore une fois en travaillant + personnel ensemble), un miracle n'est pas à prévoir. On peut acquérir beaucoup d'expérience avec certains langages et frameworks, mais pas encore passer à un nouveau niveau de pensée.
L'autre chose est la maturité globale d'un individu. À mon avis, il se rapproche d'abord de 30 ans. Avant cela, notre cerveau peut fonctionner à une fréquence d'horloge plus élevée, mais il traiterait des déchets indésirables, car il manque suffisamment de données dans la mémoire pour voir une image plus grande. Notre expérience de vie générale ajoute quelque chose de subtil mais réel à notre façon de penser et de travailler, donc à la programmation comme un autre type de travail.
Mon acceptation personnelle d'une personne âgée: quelqu'un d'au moins 27 ans avec au moins 7 ans de pratique . Avant cela, je serais personnellement sceptique (mais toujours ouvert d'esprit, cela m'apportera juste plus de preuves).
Martin Fowler a récemment publié un bon article de blog. Les choses que j'en retire sont:
Cela n'a rien à voir avec combien de temps vous travaillez pour quelqu'un. Vous travaillez depuis trois ans et vous devenez développeur senior. Que se passe-t-il après six ans? Devenez-vous développeur senior senior?
Les développeurs seniors ne vous regardent pas de haut et ne pensent pas qu'ils sont meilleurs que vous. C'est très important. Une fois que vous avez laissé votre ego vous gêner, vous avez des ennuis.
Les développeurs seniors ne passent pas le blâme. Ils anticipent les problèmes et les abordent de manière positive.
Les gens veulent travailler avec des développeurs seniors. C'est une clé pour moi. Je veux que les gens travaillent avec moi et je veux qu'ils aiment travailler avec moi.
Les développeurs seniors ne sont pas les ingénieurs les plus intelligents. Ils ne travaillent pas sur les problèmes les plus complexes. Leurs compétences ne concernent pas uniquement la programmation. Leurs compétences en communication jouent un rôle tout aussi important.
Les développeurs seniors sont bons pour estimer.
Les développeurs seniors se soucient toujours de ce qu'ils font. Ils comprennent que les tâches ennuyeuses doivent être effectuées avec la même qualité que toute autre tâche potentiellement plus intéressante.
Juste pour clarifier
Les compétences que j'ai énumérées ci-dessus sont ce que je crois qu'un bon ingénieur logiciel senior devrait avoir en plus des compétences et des pratiques fondamentales en génie logiciel.
Lorsque vous en avez encadré beaucoup, et la plupart vous en ont remercié des années plus tard après avoir été en désaccord avec vous au début, n'hésitez pas à ajouter "Senior" à tout titre que vous pourriez commander.
Jusque-là, "plomb" est probablement un terme plus descriptif.
Pour moi, le terme "senior" dénote un point culminant d'expérience pratique ET de sagesse face aux personnes et à leurs attentes arbitraires. Tenez compte de ce scénario:
16 programmeurs dans une équipe, chacun avec exactement 1 an d'expérience de plus que les autres. Cela signifie que le 16e programmeur a plus de 16 ans d'expérience. Huit des membres les plus expérimentés sont tragiquement tués lorsqu'un bus claque dans un magasin. Le gars avec la moitié de l'expérience serait-il considéré comme un développeur senior? J'espère que non, j'espère que l'entreprise remplace rapidement les vides par des personnes de calibre égal ou supérieur à ce qu'elles viennent de perdre.
Je déteste introduire le terme ' compagnon ' dans la programmation, mais certains s'appliquent. Le terme "senior" n'est pas quelque chose que je donnerais à quiconque ayant moins de 15 ans d'expérience, car il va bien au-delà des connaissances techniques.
Je trouve ce titre "Développeur Junior/Senior" faux et trompeur car il n'y a pas de véritable unité de mesure pour cela. Nous sommes tous des développeurs de logiciels avec moins ou plus d'expérience pratique. N'essayez pas de créer une hiérarchie pour les développeurs de logiciels, cela ne sert à rien et cela peut nuire au principal objectif: une excellente équipe de développement de logiciels.
Quand vous regardez en arrière votre travail précédent et réalisez de quelle merde c'était. Et vous comprenez que vous vous êtes amélioré mais qu'il reste des kilomètres à parcourir et que l'apprentissage est pour toujours.
Parfois, je regarde d'autres professions et je me demande pourquoi la programmation logicielle ne se standardise pas. Cette question ne servirait à rien car il y aurait une norme acceptée pour obtenir certains niveaux. Puis je me suis rendu compte: "Qui est mort et les a laissés roi?"
Nous savons tous que l'expérience, l'éducation, les certifications et les titres permettent à tous les autres d'avoir un aperçu très basique des capacités des programmeurs. Soit vous savez ce que vous faites, soit vous ne le savez pas. Vous pouvez soit sentir votre propre genre ou vous ne pouvez pas.
"WHAAAT .... UNIT TEST !!!! Je suis un programmeur senior ... Je n'ai plus besoin de tester mon code"
J'ai entendu ça avant .... Ainsi, il laisse les "Juniors" corriger ses bugs et le tester.
"Nous allons engager un architecte ... non, pas Mr X, nous voulons quelqu'un de beaucoup plus ancien, quelqu'un qui ne code plus"
plus tard dans l'interview:
alors quels langages de programmation connaissez-vous?
ahem ... J'ai utilisé COBOL et FORTRAN mais maintenant c'est surtout MS Word, Excel et PowerPoint.
Excellent ... quand pouvez-vous commencer?
Vraiment senior n'est qu'une question de perspective, un titre comme dirait Steven. Cependant, je souhaite pouvoir dire qu'en fin de compte, c'est le code que vous écrivez qui compte, mais malheureusement dans de nombreux cas, le costume et la cravate ont un impact plus important, surtout lorsque vous n'êtes plus mesuré par des réalisations concrètes (code), mais comment vous convainquez bien les hiérarchies de votre caractère essentiel.
Quand les autres vous appellent développeur senior. Il n'y a pas de définition unique. Ses changements d'entreprise à entreprise. Dans une entreprise bien établie, les recrues reçoivent moins de travail et leur courbe d'apprentissage est lente. Dans la start-up, un nouveau peut prendre de nombreuses responsabilités et apprendre beaucoup de choses en moins de temps. J'ai vécu cette expérience de première main. Malheureusement, seules les autres personnes expérimentées peuvent calculer la profondeur de vos connaissances en examinant la qualité de votre code ou de votre travail. Et je suis sûr que tout le monde obtient son titre lorsque son temps est écoulé.
Et si vous ne changez pas de société. :-)
C'est un titre comme beaucoup d'autres titres. Ces "adolescents" ici pourraient même avoir un doctorat, cela ne signifie pas nécessairement quoi que ce soit. Mais cela leur donnera clairement un salaire plus élevé. Il en va de même pour le développeur principal ou l'architecte principal. Ou le chef de projet senior, etc.
Compte tenu de ce fait, il vaut mieux être appelé "notre développeur principal" par vos collègues de travail, plutôt que d'ajouter ce titre à votre propre carte après quelques années d'expérience - ce que j'ai fait quand j'en ai eu l'occasion. :-)
En dehors de cela, je dirais que 10 ans est un minimum (y compris les études collégiales ou autres).
J'ai vu récemment des offres d'emploi à la recherche d'un diplômé CS avec moins d'un an d'expérience. Cela me semble une folie, même si ce n'est qu'un titre. D'une part, il suggère un édulcoration du titre. Je suis sûr que les deux sociétés que j'ai vues avec ces publications ont un autre titre de "super-senior" pour désigner les vrais seniors. Ce n'est pas une mauvaise stratégie d'embauche, je suppose. Le titre n'est pas tout, mais toutes choses étant égales par ailleurs entre deux emplois, je prendrais probablement celui avec le titre de "Master Chief Developer".
Le point où le "Master Chief Developer" (ou quelle que soit cette position élevée, "senior" ou autre) est effectivement justifié, mais est difficile à cerner. Je ne pense pas que nous puissions être trop objectifs pour le quantifier. En guise de formule approximative, je dirais qu'ils devraient être appelés seniors s'ils sont généralement les meilleurs de la salle et que la salle contient au moins 8 développeurs professionnels. Cela donnerait à penser qu'un aîné se situe au 87e centile au minimum. Bien que je dirais que ces développeurs seront probablement ceux qui auront le plus d'expérience, je ne dirais certainement pas que cette expérience == "senior", ou même proche. Dans le même temps, même si je suis sceptique quant au fait que le nombre de vrais seniors de moins de 7 ou 8 ans doit être excessivement petit, il n'est pas impossible pour quelqu'un avec moins que cela d'être maître.
Ayant 22 ans, je tombe certainement dans la catégorie "peu probable d'être un maître". Bien que je sois dans certains de ces types de "10 (ou 30) ans de 1 an d'expérience" et que je suis honnêtement tenté de penser que je vais mieux, j'essaie de me rappeler que ces personnes, même si elles n'ont fait aucun effort pour des décennies à apprendre, ont encore probablement acquis plus de connaissances que moi sur une grande variété de sujets grâce à l'osmose pure. Il n'y a tout simplement aucun moyen que je puisse en savoir autant qu'eux sur le cycle de vie complet du projet. Je travaille avec une personne dont le projet est plus âgé que moi! Il serait assez présomptueux de ma part de vraiment penser que j'en savais plus sur le maintien d'un projet de cette envergure que lui.
L'autre chose à garder à l'esprit est que si vous commencez à vous appeler senior à 22 ans, que ferez-vous à 32 ans? C’est un peu un mauvais service à votre avenir de supposer que vous êtes déjà au sommet. Beaucoup de gens se tournent vers la règle des 10 000 heures pour déterminer si quelqu'un est un expert. Dans le livre de Malcom Gladwell où l'idée est proposée, il est assez clair que les experts ne sont pas simplement les meilleurs, mais ils jouent un certain rôle. Les novices ne sont en aucun cas les pires, mais c'est une description de la méthode encore plus que la capacité. Les novices peuvent apprendre les trucs farfelus rapidement, mais ont souvent du mal à faire certaines des choses les plus courantes aussi rapidement que quelqu'un qui est un expert. Les experts peuvent faire les choses de routine avec une précision et une vitesse extrêmes, et savoir quelles choses rechercher qui pourraient dénoter des problèmes, mais ont souvent du mal à réagir au changement ou à apprendre des choses qui sont en dehors de leur zone de confort. Dans cet esprit, je ne veux même pas encore être un expert. Je voudrais absorber autant d'informations que possible, aussi longtemps que possible avant de m'installer dans un domaine stable.
Cela pourrait avoir quelque chose à voir avec l'argent.
Certaines entreprises suivent un plan de salaire fixe. Ils ne peuvent pas vous mettre au milieu de l'échelle des développeurs, à cause de certaines règles. Mais ils peuvent vous mettre au bas de l'échelle des "développeurs principaux".
Personnellement, je trouve étrange qu'une personne reçoive un titre senior dès la sortie de l'université, mais de l'autre côté - qui s'en soucie? Je suis "développeur" depuis une dizaine d'années maintenant, et même si j'obtiens un titre "senior" lorsque je change de lieu de travail maintenant, cela ne veut rien dire. Je serai toujours un étudiant de première année dans le nouveau domaine - au moins pendant un certain temps ...
La première fois que vous obtenez un emploi basé sur au moins une session d'entretien qui n'est pas de nature "entretien technique classique" (c'est-à-dire, parler d'architecture, de concepts, de design, de vue sur l'entreprise, d'expérience, etc.)
Mon expérience (limitée) est que les développeurs juniors sont généralement embauchés uniquement sur la base des performances dans la batterie standard de questions d'entrevue, et les seniors basés sur une variété d'autres interactions.
10 années ?? Tu te moques de moi. Ok, comment définissez-vous 10 ans? Disons que quelqu'un a commencé la programmation à l'âge de 15 ans mais est devenu professionnel à 25 ans?
L'industrie ne fonctionne pas de cette façon. Je pense que différentes entreprises permettent aux gens de les appeler Senior Dev X ou Y à tout moment entre 5-8 ans. Beaucoup d'ancienneté dans l'Organisation ne vient pas uniquement des capacités, cela a beaucoup à voir avec l'initiative qu'un individu prend et le type de responsabilités qu'il est prêt à partager. La plupart du temps, les personnes ayant des compétences raisonnables et une forte motivation deviennent des pros seniors.
BTW 22 ans n'est pas adolescent ;-)