Discussion :

[Stéphane le calme]

Les profils junior, intermédiaire, senior, devraient-ils se limiter aux années d'expérience ?
Un développeur présente sa vision des choses

Une bonne organisation est cruciale pour mener à bien un projet. Plusieurs profils se dessinent au sein des équipes de développeurs, reflétant chacun des niveaux de connaissances et compétences différentes. Si certains sont suivis par des adjectifs derrière lesquels peuvent se cacher des années pendant lesquels l’individu a gagné en expérience (par exemple dans la manipulation du code), est-ce toujours le meilleur facteur pour établir une hiérarchie afin d’obtenir le meilleur d’une équipe ?

Matt Briggs, développeur senior, estime que les classifications ne devraient pas se limiter aux « années d’expérience ». Il se propose alors de contextualiser les niveaux d’expérience accordés aux développeurs dans une perspective qui lui est propre.

Un développeur junior, fraîchement sorti de l’école, pense tout savoir. Tout d’un coup la réalité s’impose à lui : il réalise qu’en fait ce qu’il a appris à l’école n’était qu’une (piètre) préparation pour le type de problèmes qu’il allait rencontrer. Peu à peu la théorie pure se dissipe, laissant progressivement émerger le royaume des compromis qui laisse peu de place aux suppositions. Ce changement de contexte devrait être la source d’apprentissage des développeurs junior qui ont alors besoin d’être encadrés, supervisés, éclairés par des personnes qui sont passées par là sous peine de se voir patauger pendant longtemps. « Vous pouvez donc dire que cette période est réservée à l’acquisition de tactiques, de techniques journalières » estime Briggs qui voit dans les développeurs juniors des personnes focalisées sur le code et non sur le développement et qui, d’ailleurs, n’arrivent souvent pas à faire la différence.

Au fil du temps, le junior devient intermédiaire. A ce stade, il commence à repérer les modèles d’échec (souvent issus de sa propre expérience) et réalise qu’il faut bien plus que se focaliser sur des tâches spécifiques pour proposer quelque chose qui marche. Il est arrivé à un niveau où il pourrait regarder un code dont il était fier auparavant et réaliser qu’il n’avait vraiment rien de spécial.

Le développeur intermédiaire est celui qui cherche à savoir COMMENT concevoir les choses de la MEILLEURE FAÇON. Pour se faire, il se fie à son expérience, il se documente, ils discute avec d’autres développeurs. Cette étape consiste à apprendre une théorie sur la conception d’un logiciel, au lieu d’apprendre une théorie sur la conception du code (qui est apprise à l’école). Un développeur junior vous fournira une pile d’algorithmes qui fonctionnent plus ou moins, tandis qu’un développeur intermédiaire vous donnera des Design Patterns et des Domain Driven Design. Aussi, si en général les développeurs intermédiaires sont plus habilités à concevoir des systèmes qui fonctionnent plus longtemps que ceux des développeurs juniors, il faut quand même se préparer à des conséquences négatives. « La triste réalité c’est que la grande majorité des développeurs seniors et des chefs d’équipe sont en fait des développeurs intermédiaires. La plupart ne le réalise pas et, bien qu’ils nourrissent les meilleures intentions du monde, ils n’ont tout simplement jamais travaillé avec quelqu’un qui est à un plus haut niveau » estime Briggs. Pour lui, les développeurs intermédiaires sont assez conscients de leur rôle au sein de l’entreprise ainsi que de la valeur qu’ils apportent. Un bon développeur intermédiaire comprend comment utiliser un le code pour résoudre un problème est un moyen pour parvenir à une fin, et non la fin elle-même. Cependant, ils sont toujours enfermés dans leur idée de quête de la MEILLEURE FAÇON de développer des logiciels.

Puis vient le développeur senior, un développeur qui prend conscience de ses propres échecs. Il évalue les probabilités de succès et d’échec lorsqu’il fait face à un problème avec une honnêteté intellectuelle. Il s’éloigne de la complexité, qui est préférée par le développeur intermédiaire, pour rechercher le simple. Il arrête de ranger les développeurs sous des catégories en se basant sur leur niveau de connaissance, mais comprend plutôt qu’il y a un spectre de forces et de limites. D’ailleurs il a plus conscience de ses propres forces et limites que quiconque.

Un développeur senior pense en termes de « contexte » lorsqu’il veut appliquer une théorie. Il comprend qu’il n’y a pas de MEILLEURE FAÇON de développer des logiciels, mais que la seule façon de faire de bons logiciels est d’adapter la théorie afin qu’elle réponde aux besoins du client, de l’équipe, de l’entreprise.

Un développeur senior comprendra que son travail est de fournir des solutions a des problèmes, pas d’écrire du code. A cause de cela, un développeur senior pensera toujours à ce qu’il fait en termes de valeur ajoutée à l’entreprise et aux clients et non en termes d’efforts qu’il fournira.

Un développeur senior comprendra que vous ne pouvez pas tout faire de vous-même et que son rôle principal est d’aider l’équipe à être meilleure de la même façon que chacun des membres de l’équipe cherche à s’améliorer.

Briggs estime que « si vous n’avez pas au moins un développeur senior à la tête d’une équipe, votre projet est voué à l’échec. Une équipe de bons intermédiaires vous mènera loin, mais les jours des logiciels que vous avez développés sont nombreux, et le résultat final sera soit fermer boutique soit des réécritures onéreuses / à risque. Un développeur senior est la SEULE personne pleinement qualifiée pour choisir la technologique et les plateformes, alors ne pas en avoir un depuis le PREMIER JOUR vous sera dommageable ».

Briggs estime que les jeunes fraîchement diplômés sont des atouts pour l’entreprise au même titre que ceux qui ont acquis 15 à 20 ans d’expérience sur le terrain. « Nous devons arrêter d’embaucher en nous basant sur les stéréotypes » conseille-t-il aux entreprises.

Source : blog Matt Briggs

Et vous ?

Que pensez-vous de son approche ?

Retrouvez-vous votre profil dans ses explications ?

[garn]

/mode cynique

En même temps, en SSII, t'es expérimenté après 1 an et sénior après 3

/mode cynique off

[dk]

oula à 3 ans t'es expert

[el_slapper]

L'article original en Anglais est plein de choses sympa, comme "A senior developer is intimately familiar with their own failure" ou encore "A senior developer has fallen out of love of the complexity which dominates the intermediate, and is obsessed with simplicity", et mon préféré "A senior developer thinks in terms of “context” when applying theory".

Mais j'ai connu, dans ce classement, des seniors de 25 ans et des débutants de 50. C'est le seul reproche que je peut faire à l'article original. Sinon, il appuie sur les points importants. Bon article, merci du lien.

[bruneltouopi]

Je ne sais pas s'il faut vraiment se considerer senior avec le nombre d'années d'expériences ou avec le niveau de compétence.
Mais vendre son profil ou d'auto-proclamer parce qu'on a X années d'expérience n'est pas idéal.
Il en est de même pour des noms tels que "expert" ou "architecte".
Je suis aussi très amusé par le jeune qui sort de l'école et qui croit tout savoir avec des nouvelles technologies qu'il a découvert en faisant des petits projets dans sa chambre.Face à des problèmatiques d'entreprise c'est souvent terrible.Soit il se referme sur lui même par orgueil,soit il comprend rapidement qu'il devra commencer à apprendre à travailler.

[FraocH]

oui enfin 3 ans expert....
au moment de demander une augmentation, 3 ans ou 30 ans, par contre la, on te dis qu'il te manque encore de l'XP

[FraocH]

Je ne sais pas s'il faut vraiment se considerer senior avec le nombre d'années d'expériences ou avec le niveau de compétence.
Mais vendre son profil ou d'auto-proclamer parce qu'on a X années d'expérience n'est pas idéal.
Il en est de même pour des noms tels que "expert" ou "architecte".
Je suis aussi très amusé par le jeune qui sort de l'école et qui croit tout savoir avec des nouvelles technologies qu'il a découvert en faisant des petits projets dans sa chambre.Face à des problèmatiques d'entreprise c'est souvent terrible.Soit il se referme sur lui même par orgueil,soit il comprend rapidement qu'il devra commencer à apprendre à travailler.

je me rappelle d'un pote a un petit cousin a moi qui commençait ses études.... les profs lui ont dit qu'il toucherai 5000 euros par moi en sortant de l'école....
Il a été vexé quand j'ai éclaté de rires ^^
je lui ai répondu "tu commenceras a 1800 euros par mois, tu pisseras du code et toutes les belles theories que tu as apprises on te dira tu te les mets ou je penses, mais il faudra faire vite pour vendre vite"

[bruneltouopi]

je me rappelle d'un pote a un petit cousin a moi qui commençait ses études.... les profs lui ont dit qu'il toucherai 5000 euros par moi en sortant de l'école....
Il a été vexé quand j'ai éclaté de rires ^^
je lui ai répondu "tu commenceras a 1800 euros par mois, tu pisseras du code et toutes les belles theories que tu as apprises on te dira tu te les mets ou je penses, mais il faudra faire vite pour vendre vite"

C'est la dure réalité du métier.Mais il ne faut pas en vouloir les professeurs Tout le monde passe par là.Ce rêve qu'on nous vend lors de nos études.Mais bon de nos jours on a la chance de voir de plus en plus de SSII bondir sur des profils jeunes.Vous savez pourquoi

[CodeurPlusPlus]

J'ai remarqué que, à problème égal, j'ai tendance à apporter des solutions de plus en plus complexes. C'est donc la preuve que je régresse. Plus le temps passe et plus je deviens débutant.

[Spownik]

Cette sensation d'être un junior, notamment en stage pendant les études, c'est cette sensation qu'une fois arrivé dans l'entreprise, tous les modules et les cours que l'on a fait nous semble si minuscules et inutiles face à la réalité (en général, bien évidement), sauf pour mes deux expériences en laboratoire du CNRS, où là, clairement les cours et les connaissances prennent tous leurs sens (bien plus que dans une ESN/SSII). Ça nous rappelle clairement que la formation initiale est très incomplète sans expérience. Je trouve que c'est une évidence et ne comprend pas les gens qui se posent encore cette question quand au nombre d'années d'expérience. Seulement les recruteurs n'ont pas trouvé meilleure mesure pour nous évaluer et s'assurer que les candidats maîtrisent un peu un domaine/techno ou autre.... Et le nombre d'années d'expérience n'est pas le plus significatif, il y a une corrélation, certes, mais pas une relation totale. C'est plus complexe que ça. Je pense cependant qu'il y a une très grosse relation avec la passion d'une personne pour un domaine (genre tu aimes faire de l'application mobile ? Tu vas t'orienter naturellement vers cette discipline et obtenir cette expertise), et là on ne parlerait plus de junior, intermédiaire ou sénior en terme de temps, mais en terme d'investissement dans le travail.
C'est mon point de vue de junior pour le coup, donc totalement biaisé et hors de la réalité probablement

[Jitou]

Assez d'accord avec ce qui est dit dans l'article, cependant la réalité est que des développeurs senior il y en a très peu, du moins dans notre contexte franco français où les rémunérations des développeurs reste plafonnées très rapidement dans une carrière qui est vouée à être très courte dans ce poste. Donc il est extrêmement rare de trouver des développeurs avec 10 ans d’expérience sur les projets on est plutôt sur une moyenne de 0 à 5 ans de ma propre expérience.

[Laurent 1973]

Assez d'accord avec ce qui est dit dans l'article, cependant la réalité est que des développeurs senior il y en a très peu, du moins dans notre contexte franco français où les rémunérations des développeurs reste plafonnées très rapidement dans une carrière qui est vouée à être très courte dans ce poste. Donc il est extrêmement rare de trouver des développeurs avec 10 ans d’expérience sur les projets on est plutôt sur une moyenne de 0 à 5 ans de ma propre expérience.

Oui, c'est tout le problème de nos métiers: la carrière est aussi courte que des footballeurs de ligue 1 .... mais sans la même paye

On se trouve quant même dans des aberrations où des senior ne trouve plus de boulot passé 40 ans et des juniors galères, sans mentor, sur des problématiques déjà rencontré mainte fois dans le passé.
Peut-être qu'un jours les décideurs en auront marre de "plantouiller" des projets informatiques sans arrêt et d'investir enfin dans des équipes contenant plus de senior et d'expert technique.

Tant que les acheteurs conditionneront de penser que de faire une économie de 15% sur un développeur mais de prendre 25% de retard sur un projet est une bonne chose, le secteur ne changera pas.

[Luckyluke34]

C'est assez bien vu, mais en même temps on peut remplacer développeur par cuisinier/comptable/policier/chercheur/sportif/marin-pêcheur/ouvrier... des débutants disciplinés, des expérimentés sérieux et des senior impliqués il en faut partout.

[Tr0n33]

Très bon article qui met aussi le doigt sur deux problèmes des entreprises françaises dans le domaine de l'informatique :
1- Considérez l'expertise en développement comme une voix de garage par rapport au management, à la gestion de projet ou aux responsabilités.
2- Considérez l'échec comme un mur infranchissable qui est un boulet à traîner plutôt qu'un apport d’expérience.

Et oui l'article anglais est plein de bonnes choses. L'expérience regroupe un tas d'informations comme : connaître les conséquences de choix, comment éviter certaines formes d'échecs, comment apprendre de certaines formes d'échecs, remise en question, conciliation entre le monde économique de l'entreprise et le désir de perfection, réactivité aux problématiques, niveau d'abstraction et capacité à la transformer en plus valu.

C'est humain donc difficilement déterminable comme réponse je pense. De mon job d'assistant RH, j'ai pu constater qu'un profil devenait vraiment bon à partir de 3 ou 4 ans et surtout, en fonction des problématiques qu'il a rencontré. L'environnement dans lequel il évolue est tout aussi important. L'expérience acquise sur un projet de migration d'architecture ne sera pas la même que sur un développement web de couches de présentation/navigation et métiers. Le profil est donc assez complexe à évaluer à la fois au niveau des connaissances, que des compétences. Un profil qui a 10 ans d'expérience chez le même client n'aura pas le recul équivalent à celui qui a eu 8 projets différents dans la même période.

Bref, très dur à évaluer dans la réalité. Pour les achats par contre, c'est simple : par grille et de manière très stupide (je veux un bac+5 avec 5 ans d'expérience pour faire... Du JS et du Webservice REST). Les achats considèrent que l'expérience est directement en lien avec l'abstraction acquise par le niveau d'étude et la pratique sur le terrain. C'est "généralement" juste mais dans beaucoup de cas, ils se plantent (à l'inverse la moindre pratique est sujette à expertise pour la vente...).

Débat fort intéressant en tout cas et sources très intéressantes aussi.

[el_slapper]

(.../...)
Bref, très dur à évaluer dans la réalité. Pour les achats par contre, c'est simple : par grille et de manière très stupide (je veux un bac+5 avec 5 ans d'expérience pour faire... Du JS et du Webservice REST). Les achats considèrent que l'expérience est directement en lien avec l'abstraction acquise par le niveau d'étude et la pratique sur le terrain. C'est "généralement" juste mais dans beaucoup de cas, ils se plantent (à l'inverse la moindre pratique est sujette à expertise pour la vente...).(.../...)

C'est le syndrome Excel : quand les gens ne sont plus considérés que comme des couts dans des cases, il devient difficile de les gérer de manière fine. Or, dès que le métier est un peu fin et demande des expertises particulières(et on doit être loin d'être le seul métier, je suis sur qu'en compta, conception industrielle ou peut-être même plomberie navale, il y a plein de finesses aussi)

Je ne dis pas de mal d'Excel, c'est un outil formidable et que j'adore. J'ai fait des trucs de fou avec, et j'en ai vu d'encore plus fous. Mais il impose un niveau d'abstraction que certains prennent pour la seule vérité. Avec l'humain, c'est toujours insuffisant.

[Tr0n33]

C'est le syndrome Excel : quand les gens ne sont plus considérés que comme des couts dans des cases, il devient difficile de les gérer de manière fine. Or, dès que le métier est un peu fin et demande des expertises particulières(et on doit être loin d'être le seul métier, je suis sur qu'en compta, conception industrielle ou peut-être même plomberie navale, il y a plein de finesses aussi)

Je ne dis pas de mal d'Excel, c'est un outil formidable et que j'adore. J'ai fait des trucs de fou avec, et j'en ai vu d'encore plus fous. Mais il impose un niveau d'abstraction que certains prennent pour la seule vérité. Avec l'humain, c'est toujours insuffisant.

Je suis on ne peut plus d'accord.

C'est ce qui fait la différence entre un RH Junior et son tableau Excel aux petits oignons et un RH Senior qui use de ses bonnes vieilles fiches informatisées.

[eulbobo]

Il existe une dernière catégorie : la catégorie des développeurs "patchwork".
Ils s'en foutent d'apprendre à bien faire et n'ont pas envie d'apprendre à mieux faire, et de manière générale ils n'apprennent pas, ni de leur erreurs, ni de ce qu'ils voient autour d'eux.

A chaque nouveau projet, ils ouvrent un autre projet et ne font que copier/coller les trucs qui marchent pour les appliquer dans le nouveau projet, en bidouillant et rajoutant verrues sur verrues sur un truc qui marchait pour que ça tombe en marche dans le nouveau système.
Le nouveau système qui marche avec des verrues devient la nouvelle norme à appliquer partout.
Une requête SQL renvoie telle donnée? Utilisons la dans un sous-select même si la requête n'est déjà qu'une imbrication de 40 sous-select.
Le projet précédent embarquait plein de libraires? On va les reprendre même si on ne sais pas à quoi elles servent ni si on en a besoin...


Parfois, un dev senior met en place une solution particulière qui répond à un besoin précis pour un projet. Et la solution se retrouve copiée/collée sans réflexion dans un nouveau projet, avec des fois des "évolutions" qui font froid dans le dos (du genre la méthode "générique" pour faire de la pagination avec 25 paramètres... Ou le "framework" maison pour faire de l'ajax qui demande plus de configuration que les EJB2 pour enregistrer un simple clic).


Bref, cette présentation parle du développement possible des développeurs qui ont tous un point commun : ils ont envie ! Envie d'apprendre, envie de connaitre plus, envie de s'améliorer, envie de faire mieux et plus vite, envie d'aller plus loin dans le défi qu'on leur a proposé.
C'est malheureusement TRES loin d'être le cas de tout le monde.

[Glutinus]

Haha, je vais faire des cauchemars, exactement une situation que j'ai déjà vécue ^^
Les mecs ils alimentent une table.
Rajout d'une colonne dans la table source ? On va faire un update pour la table cible.
Rajout d'une autre colonne ? On va faire un update pour la table cible.

Je ne rentre pas dans les détails c'est plus touchy que ça mais les traitements prenaient 5h30.
J'ai juste retaper le select avec quelques jointures qui vont bien => le traitement prenait quelques minutes après.
On m'a accusé d'avoir tout faussé, malgré les preuves en faisant des comparaisons avant / après
(bon, en réalité les lignes étaient pas pareil, parce que la "date insert" était différente )

[Invité]

je vais faire un peu l'avocat du diable.
Pour beaucoup l'âge d'or du développeur, c'est à dire au moment ou il est à son apogée, c'est vers les 30-35 ans, soit en gros 10-15 ans d’expérience. C'est peut être faux mais pas aberrant, la vivacité d'esprit, la motivation, tout ça... Hors le problème c'est que tu es payé selon ton expérience, donc du coup à un moment donné ton cout dépasse ta valeur ajoutée supposée.

Faut aussi avouer que la différence de niveau n'est pas toujours flagrante et que certains contextes n'aident pas. Il n'y a pas toujours de lien entre le niveau et l’expérience. Toutes les expériences ne se valent pas. Dans l'informatique de gestion il y a aussi beaucoup de choses à faire qui ne demande pas beaucoup d’expérience, soyons honnête.
Il y aussi l’émergence de nouvelles techno, et quand un petit jeune a eu des cours dessus et connais déjà un peu et que toi expérimenté tu n'as pas le temps, l'envie ou l’énergie d'ailleurs de t'y mettre. Y a pas de honte à ça, c'est humain, forcement le recruteur, pour lui y a pas photo.

Y aussi un autre problème, c'est que globalement la qualité du code et même les performances personne ne s'en préoccupe. Je parle surtout de l'informatique de gestion. Du coup beaucoup sont près à payer moins cher pour avoir un code moins bon et moins performant. A long terme, c'est mauvais, mais c'est pas son problème, le temps que le projet se finisse, il ne sera plus à ce poste ou dans cette boite.

Et puis bon, le pti jeune avec sa motivation, sa flexibilité, il arrivera quand même à faire quelque chose de passable, même si je suis d'accord qu'il y a des postes ou il faut clairement un dev expérimenté.

Objectivement, en terme de rapport qualité/prix, c'est difficile de concurrencer un JD. Et vu qu'on est gouverner par des comptables...
Je pense pas qu'il y ait réellement de solution au problème. Si on ne veut pas faire du management ou du commercial, je pense quil faut apporter une réelle expertise en freelance ou faire de la formation sur un domaine technique. Honnêtement se réorienter dans l’enseignement quand on aime la technique, c'est pas un mauvais plan.

[JackJnr]

Ah ah exactement la réflexion que je me faisais ces derniers temps (de junior à intermédiaire dans mon cas). Arriver à moins penser en terme de technique, sachant que la technique s'adapte au besoin, et non l'inverse. Enfin il m'aura fallu en passer par là pour arriver à allier performance/élégance et pertinence. Enfin l'expérience, et surtout la capacité à se remettre en question et accepter de se heurter à des murs. Comme le dit Tr0n33

"2- Considérez l'échec comme un mur infranchissable qui est un boulet à traîner plutôt qu'un apport d’expérience."

C'est cette mentalité qui fait qu'une personne n'évolue pas. Plus on essaie d'éviter l'echec moins on comprend les raisons qui nous y amènent. Tel que je l'ai ressenti on nous encourage souvent trop à performer plutôt qu'à essayer par nos propres moyens.