Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Stéphane le calme

0PARTAGES

15  0 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de garn
Expert confirmé https://www.developpez.com
Le 05/06/2015 à 15:50
/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
9  0 
Avatar de FraocH
Membre régulier https://www.developpez.com
Le 05/06/2015 à 16:49
Citation Envoyé par bruneltouopi Voir le message
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"
9  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 08/06/2015 à 11:32
Citation Envoyé par Jitou Voir le message
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.
8  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 05/06/2015 à 16:41
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.
7  0 
Avatar de garn
Expert confirmé https://www.developpez.com
Le 15/06/2015 à 15:16
Ca me rappelle ma 1ere expérience en chef de projet. Contexte : regie dans une équipe de 4 personnes de la même SSII (dont moi)
Il nous faut une ressource de plus pour combler un départ. Boulot d'AMOA (comprendre un contexte métier, tests fonctionnels...) sur un contexte ETL (comprendre un ETL, SQL...)

On m'a filé un jeune, BAC+5 sortie d'école, alternance faite dans la SSII, en periode d'essai dans son CDI suite alternance. Le type avait déja fait ami ami avec le directeur du département, déja touché a plein d'ETL
Il a RIEN foutu en 3 mois de mission; il nous a meme donné plus de boulot en faisant des erreurs qu'il n'a réussi a en corriger. Il avait demandé à la boite à faire de l'AMOA pour tester, ca lui a pas plu, il a abandonné le projet. En restant au meme poste bien sur. Il était en période d'essai mais ayant copiné avec la hierarchie de la SSII il se savait en sécurité, parfois moins de 3h de boulot par jour il disparaissait, refusait de rendre des comptes...Je l'aurais tué
j'ai remonté les problemes, ca a pris près de 3 mois pour le sortir proprement, entre temps l'équipe a du combler sa part du boulot. Le type avait eu le culot de se plaindre que c'était emmerdant comme travail
A noter que le travail "emmerdant" est la plus grosse expérience de ma carrière pour l'instant, refonte complète de SI d'un gros gros client, mais bref.

A la place le commercial de la SSII, me file un senior, avec en commentaire "celui la tu pourras lui filer n'importe quoi en travail il t'emmerdera pas", consultant +40 ans qui cherchait un travail en interne, ne pouvait pas partir de la SSII car famille à gérer, malgré le fait qu'on lui filait de la merde en mission. Un pur technique dont le profil correspondait pas à de l'AMOA, mais j'ai pas eu le choix. Le gars s'est révélé devenir notre meilleure recrue : il a eu un peu plus de mal à comprendre le fonctionnel, respecter les procédures, mais sur ce qu'il connaissait il a pris l'initiative de refaire des macros pour automatiser. Il a juste fallu le former, etre derrière lui pendant un temps, mais à coté de ca, esprit d'initiative, bonne analyse, aucun problème a être formé sur quelque chose de contraire à son métier de développeur

A la base je sais très bien que la SSII m'avait donné ce type de profil pour m'emmerder parceque j'avais fait sortir leur super junior

N’empêche que j'ai jamais autant ressenti la différence entre le jeune imbu de lui même qui en début de carrière se permet de ne pas travailler, et un sénior qui en a vu de toutes les couleurs, connait la difficulté de la vie, et a tiré de cette expérience autant de chose qu'on a pu apprendre de lui
7  0 
Avatar de eulbobo
Membre chevronné https://www.developpez.com
Le 09/06/2015 à 10:23
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.
5  0 
Avatar de Tr0n33
Membre actif https://www.developpez.com
Le 12/06/2015 à 11:11
Citation Envoyé par arkhamon Voir le message
Je rejoins (un peu) la personne qui disait qu'il fallait des "vieux" pour encadrer des "jeunes". La sagesse sachant piloter la fougue donnera à mon avis un taux de réussite élevé. Pour peu que chacun aitr un peu de diplomatie (ça faut encore que j'apprenne ).
Un peu juste ? (cétait moi, sniff) Oui l'interaction sociale, le lien entre les individus et la diversité de compétences/caractères, sont les meilleurs moteurs pour beaucoup d'activités.

Dernier point, il faut arréter de considérer ue développeur est "une phase entre le débutant et le CP". Il faut reprendre à l'esprit un fil d'il y a quelques temps qui critiquait cette manie de vouloir a tout prix faire évoluer les gens. Certaines personnes très compétentes dnas un domaine deviennent incompétentes dans celui "au dessus". Un bon développeur ne fera pas forcément un bon CP, laissons le alors faure du bon boulot de dev.
Alors ça... C'est ce que j'évoquais rapidement. La fameuse voix royale et le fameux principe que j'adore : Principe de Peter, et c'est tellement vrai. D'ailleurs je suis développeur, je deviens expert et formateur (avec une touche de ressources humaines) et certainement pas Chef de Projet. J'en avais discuté avec un RH qui m'avait refusé quand j'étais jeune. Je ne rentrais pas dans la bonne case avec ma réponse qui disait que je ne voulais pas devenir CP ou Manager d'équipe.

Mais le souci va plus loin : les grilles de salaire ont un gap entre le CP et le développeur expert. Vous avez toujours une marge plus importante de progression côté CP. J'en ai récemment discuté avec un Manager, et j'avoue gueuler de plus en plus auprès des syndicats sur ce sujet lui aussi bien français. En France, un développeur de 50 ans est une peur pour la hiérarchie. Aux USA, c'est une mine d'or et un trésor d'expérience. Pour vous rassurer, non, à 50 ans, on est encore jeune dans notre société (malgré tout ce qui se dit, je cite souvent l'exemple de ma modeste maman, qui a 51 ans a repris ses études, qui à 61 ans cette année, qui est devenu de secrétaire au comité d'entreprise de la SNCF à doctorante en civilisation et langue arabe, et qui est désormais une experte reconnue de l'armée andalouse du 13e siècle. Croyez moi, elle réfléchit bien mieux que 95% des jeunes de l'université. Les exemples sont légions en réalité, et c'est le poids de la société qui fait croire qu'on est cramé à 50 ans. Je n'y crois pas un seul instant.).
5  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 22/06/2016 à 14:22
Citation Envoyé par Grogro Voir le message
Mais comment les développeurs java faisaient leur qualification sur l'environnement de recette ? Chez nous on a un environnement de dev, un environnement de pré-prod + la prod, la mise en pré-prod est faite par le CP en une heure sans avoir à demander d'autorisation (par contre côté web services et bdd c'est plus long), et il nous est arrivé d'en faire 4 par jour à l'approche d'une mise en production.
Ils souffraient. Pas le droit à l'erreur - ou alors on prend une semaine dans la vue. Le pire, c'est que les grands chefs voulaient mettre en place le même processus niveau COBOL, soi-disant pour maitriser le process de livraison. Le seul résultat, c'est que quand la MOA a demandé le même devis au JAVA et au COBOL, le COBOL était deux fois moins cher... et avait un taux moyen de retard deux fois inférieur, aussi. Mais je ne crois que ça n'était ni lié à la qualité des développeurs(dusse mon orgueil en souffrir), ni aux qualités intrinsèques des langages(même si j'adore le COBOL et que je déteste le JAVA, c'est purement subjectif et de mauvaise foi).

La logique derrière ce genre de connerie, c'est "le process doit être maitrisé". Ca ne prend pas en compte l'extrême complication des logiciels internes - qui sont juste trop gros pour entrer dans une tête, même une tête de programmeur. Permettre au programmeur de rattraper rapidement ses conneries, donc, au final, tolérer qu'il en fasse, c'est juste accepter qu'il est humain et ne peut pas tout planifier d'un coup. Même moi(voire surtout moi), j'ai des limites cognitives bien en dessous de ce qu'il faudrait pour que tout soit bon du premier coup. Mais pour les grands chefs, c'est inacceptable. On doit maitriser le process, ne jamais être surpris, avoir tout planifié, et ne jamais improviser. Et la marmotte, elle fait la mise en production sans casse, sans surprise, tel que ça a été conçu, à la virgule près.

Sans compter le confort mental : j'ai fait une connerie? du Dev à la prod en passant par l'intégration et l'homologation, j'ai 4 livraisons de une minute chacune(chrono en main). Je sais que je peux retomber sur mes pattes. J'ai confiance. Le dev JAVA, il a peur - parcequ'à la moindre boulette, il en a pour une semaine pour réparer - et la peur est mauvaise conseillère.

Je répète : on avait des devis deux fois plus courts, et des dépassements moyens de 5 à 10%, là ou ils frôlaient les 20%. Juste à cause de ça. J'aurais détesté être à leur place.
5  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 23/06/2016 à 12:15
Citation Envoyé par Laurent 1973 Voir le message
Si je comprend bien ton retour d’expérience, les deux équipes étaient surtout différenciées par leur processus d'organisation.
Pas seulement. La plupart ds cobolistes(même si il ya des exceptions) ne sont pas des informaticiens diplômés. La plupart des Javaïstes le sont. C'est une manière différente d'aborder les problèmes.

Citation Envoyé par Laurent 1973 Voir le message
Là où vous étiez très responsabilisé en COBOL avec une démarche DevOp bien intégrée, les Javaistes étaient englués dans une organisation lourde, bureaucratique et fastidieuse.
Disons que la bureaucratie avait reculé devant la rébellion de mes prédécesseurs(et des MOA qui trouvaient bien pratique de pouvoir faire passer un truc imprévu en loucedé, si il n'était pas trop gros). "être responsabilisé", dans un grand compte, ça veut dire en prendre plein la gueule quand ça va mal. Pas avoir la liberté dons nous jouissions plus par inadvertance que par décision des grands chefs.

Citation Envoyé par Laurent 1973 Voir le message
(.../...)Si tu pouvais plus détailler un peu plus les 2 processus, cela serait très instructif je pense.
En JAVA : les gens font leurs développements, puis ils les confient à la cellule d'intégration, qui prépare un livrable, qui le confie à une autre équipe, qui fait le build, le tout avec des piles effroyables de documents à chaque étape. En plus, ils n'avaient pas le droit de créer de classes. Il devaient faire avec l'existant, avec interdiction de dépasser, ou alors attendre que l'urbaniste les autorise à créer une nouvelle classe(avec, là aussi, des montagnes de paperasses signées par un nombre à deux chiffres de chefs).

En COBOL : la MOA passe un coup de fil au développeur, qui demande un mail avec sa chef en copie(oui, tous les chefs étaient des dames). 30 minutes plus tard, mail en main, il commence le développement. Si c'est un truc rapide, 2 heures plus tard, c'est en intégration, ou le dev teste, et 2 heures plus tard, c'est en homologation, ou la MOA teste. Puis la MOA envoie un mail de validation(si c'est bon, hein). 5 minutes plus tard, le composant est en prod. La chef a reçu 2 mails, et le développeur ne sait même pas si elle les a lus. Personne d'autre n'est intervenu.

c'était plus compliqué quand il fallait intervenir sur les JCL(nos scripts), ou sur les SPITAB(nos tables de référence). Là, il fallait faire des demandes aux équipes techniques. Pour le coup, généralement, ion évitait au maximum de les changer. Mais on avait de la chance : le délai pour les JCL officiel était de 15 jours, généralement, c'était fait en deux jours ouvrables. Par contre, pour les SPITAB, c'était long et douloureux, donc on trichait souvent: nos tables de paramétrage étaient en dur dans les programmes, c'était bien plus facile et rapide à modifier que des tables de paramétrage propres.

C'est horrible, hein? Mais il faut comprendre la MOA : entre "tu as la main pour faire comme tu veux les paramètres que tu veux, mais ça sera pris en compte dans 3 semaines", et "donne nous les nouveaux paramétrages, ça sera pris en compte dans 3 heures", la voie de la facilité est difficile à éviter.

Citation Envoyé par Laurent 1973 Voir le message
J'imagine aussi que l'ambiance de travail devait être radicalement différente dans ces deux équipes.
oui. Après, eux, ils avaient le droit de recruter en masse, pas nous. Mais heureusement.....

Citation Envoyé par Laurent 1973 Voir le message
Ça donnerai même presque envie de se mettre au COBOL pour rejoindre ton équipe
Bof, tout ceci a été dissous et confié à un prestataire extérieur. Mais quoique JAVA aurait fait joli sur mon CV, à aucun prix je n'aurait accepté d'en faire dans ces conditions. Parceque quand les MOA nous demandaient des trucs en urgent, généralement, ils avaient de très bonnes raisons. Et pouvoir répondre au quart de tour, c'était quand même sacrément confortable.

Le truc, c'est qu'avec une bonne gestion de conf(et nous en avions une excellente), TOUT ce que nous faisions était traçé. Donc un contrôle a postériori était toujours possible. Ce qui faisait que non, nous n'étions pas des cowboys. Nous étions des professionnels, surveillés comme il se doit dans un établissement qui gère des sous. Toute erreur devait être expliquée, et pouvait être traçés par un tiers. Toute faute était facile à démontrer. Dans ces conditions là, pourquoi demander à des chefs qui de toutes façons n'avaient pas de compétences techniques de tout valider? Ma chef me donnait mes priorité, et vérifiait que le backlog d'incidents était géré avec professionnalisme. Le reste? On réglait nôtre linge sale en famille. Ca aidait aussi beaucoup que nous étions tous des vétérans, des survivants. Un pack de débutants mal encadrés aurait sans doute été peu efficace, dans ces conditions.

En en fait, on en arrive à la vraie raison de la bureaucratie : les chefs partent du principe qu'ils ont des nullards, qu'il faut cornaquer fortement pour avancer un peu. C'est un mauvais calcul : les nullards n'avancent pas du tout, même fortement cornaqués. Et les bons sont juste freinés quand on les cornaque. Et les moyens sont rares, en fait, ils deviennent vite bons...ou chefs.
5  0 
Avatar de
https://www.developpez.com
Le 27/06/2016 à 16:38
L'expérience consiste en intensité, non en durée.
Thomas Hardy

Et pour éclairer le débat junior/sénior et le écarts de salaires qui peuvent écarter les seconds des rangs des SSII, je dirai que l'essentiel et de justifier cet écart.
Je vais employer des mots qui sont peut-être durs mais je suis quadra et donc ça s'applique à moi également.
Personne, je dis bien personne n’accepte de payer plus cher le même service.
Essayez d'aller vendre le même pain que le boulanger d'en face ne serait-ce que 20% plus cher. Vous en vendrez beaucoup ?
On accepte ce surcoût car le service/bien est plus joli, fiable, classe, bon, valorisant, ... mais en aucun cas sans raison.
Si nous (quadra/quinqua) voulons mériter cette surcote il faut la mériter.
Rester à l'écoute des techno, du marché et compenser une hypothétique baisse d'intellect par la sagesse, l'instinct, l'expérience, la claivoyance, l'aura, ...
Et je doute que le mensonge et la manipulation, comme j'ai pu le lire dans ce post, soient les valeurs dont notre société a besoin.
5  0