Discussion :

[phili_b]

@e-ric

Quoi donc? Le PMI? Se battre contre est un combat d'arrière garde. C'est un truc completement établi dans les grosses boites. Tu ne présentes pas de chef de projet certifié, ta propal est moins bien regardée.

Je ne savais même pas qu'il y avait des certifications de chef de projet, en tout cas en informatique, mais vu que tu répètes le mot PMI sur plusieurs messages. C'est sûr que ça peut s'apprendre sur le tas, mais quand on voit le nombre de brasseur d'air, ça rassure en fait qu'il existe des formations: en fait ce sont plein de gens qui ont été nommées sans rien savoir à la gestion de projet.

D'un autre côté ça veut dire que si on est formé on n'a plus de chance d'y arriver ?

ça parait être des lapalissades ce que je dis, mais en ssii on a l'impression que c'est de la génération spontanée alors qu'en fait ça s'apprend. Et c'est pour cela qu'il y autant de mauvais chef de projet: on leur a tout simplement pas appris et une minorité d'entre eux savaient gérer un projet sans avoir été formé.

Par quoi commencer? Etre coordinateur de projet (poste informel, avec moins d"influence qu'un chef de projet), ou assistant chef de projet ou intervenir en AMOA/MOE. Moi j'ai commencé parce que j'étais consultant fonctionnel en charge de clients et qu'on avait besoin d'un chargé de projet à temps partiel dans le cadre de projets dans lesquel j'intervenais avec lesdits clients.

Après c'est comme le reste en ssii, même si c'est formateur d'y travailler, on est censé passer de dév à CP, d'étudiant en informatique à expert en programmation (être une brute ne suffit pas), utilisateur d'un outil (mainteneur d'un langage) à expert dans l'outil/langage alors que la meilleure façon d'apprendre c'est de travailler avec un tuteur au départ. C'est comme ça qu'on voit des projets poubelles d'agence dans toutes les ssii où chaque nouvelle génération d'étudiant fait tout ce qu'il ne faut pas faire, sans savoir qu'il ne faut pas le faire, puisqu'on les laisse seuls sans les cornaquer.

Et donc effectivement être CP sans formation et sans avoir été tutoré c'est un non-sens. Une fois j'ai été nommé CP sans connaitre le langage en question, ni le management, et évidemment sans aide sauf pour m'expliquer comment remplir les 40 pages du logiciel de suivi mais sans la méthodologie de CP. J'ai demandé à dégager de cette fonction au bout de qq jours.

Finalement tu comprends pourquoi les CP ont mauvaise presse auprès des développeurs et autre non CP. Beaucoup ont l'air d'être insuffisamment formés et comme toujours donne une mauvaise image à la fonction en général, et ça fait fuir ceux à qui on le propose, sauf ceux qui vont vers cette fonction uniquement pour le pouvoir et pas pour faire avancer les choses, être facilitateur de projet.

[I_believe_in_code]

(...) il faut former les salariés aux bonnes pratiques, tous les salariés surtout les s*l*uds à dents longues .

Les s*l*uds, faut les virer, pas les former

[herve4]

D’abord, je trouve curieux de se demander si coder est une tache ingrate sur un site de ce genre ...
Je dirais plutôt que c'est l'analyse UML ou l'élaboration du cahier des charges qui est une tache ingrate.

Personnellement, je suis en dernière année d'école ingénieur et je n'ai pas vu la spécialité « programmeur passionné ». Dommage ??
J’ai pris l'option "Chef de projet" mais je continuerais à coder même si ca peut faire "le chef de projet qui a raté sa carrière."
J’estime qu’on ne peut pas manager une équipe informatique si on ne sais pas ce qu’elle fait techniquement, ou encore palier une urgence si on ne sais pas faire soi-même ce que l’on demande.

[pcaboche]

Et le chef de projet y veut du à l'ail ?

Je sais pas, mais pour les projets, il veut qu'on reste "groupir".

[nirgal76]

Si ta boîte, n'a pas un minimum de retour sur la satisfaction client, c'est pas top...


Si le management est bon (ce qui est la cas dans ma boîte), bien sûr que ce genre de remonté doit arriver jusqu'aux développeurs.

ben si le client remonte la satisfaction, ton patron t'augmente ? si il t'augmente, le prix de la prestation aussi, et le client n'est plus content. C'est mécanique.
Bon c'est généraliste, perso, j'suis dans une bonne boîte et chez un bon client, je n'ai pas ces soucis.

[el_slapper]

(.../...)Concernant l'idée de process: le PMI dans son PMBOK (corpus des connaissances en management de projet - la désormais bible des certifiés ou aspirants certifiés en management de projet) definit 47 process organisés en 5 areas (initiating, planning, controling, closing) avec en input des données, dans la boite noire des tools et techniques et en sortie des outputs bien sur. En fait, ils ont formalisé la plupart des choses qu'un bon chef de projet doit connaître et faire. Tous les processes ne doivent pas être systématiquement implémentés et la méthode doit être adaptée à l'environnement et à la taille des projets mais le fait de les connaitre donne à tout chef de projet une armature, un squelette, une base solide sur laquelle le chef de projet peut s'appuyer pour implémenter les bonnes pratiques et avoir les bons réflexes dans la pratique de son job. Ca inclut également un code éthique et de bonne conduite (si si).

Ah, maintenant on parle le même vocabulaire. J'ai eu une formation PMI de 5 jours en Avril dernier. Le formateur a glissé, entre deux process, la phrase suivante : "Le PMI s'est penché sur le cas des développements agiles. Pour l'instant, ils ne sont pas parvenus à les gérer". Et c'est normal.

PMI, c'est bien pour les projets linéaires : on sait ou on est, on sait ou on va, et on découpe le chemin de l'un vers l'autre. Ca n'est pas forcément facile. Exemples de projets linéaires : le viaduc de Millau, les normes bancaires Bâle2/Bâle3. Pas des faciles, hein, mais

Seulement, une majorité des problèmes informatiques sont tordus. Exemples de projets tordus : améliorer un modèle de voiture, mettre en place un logiciel de gestion.

Un problème tordu, pour ceux qui ont la flemme de lire l'article(c'est un tort), c'est un problème qui :
(1)n'a pas de formulation définitive
(2)n'a pas de top simple qui permette de savoir qu'on a fini
(3)a pour solution non pas du vrai-faux mais du bon-mauvais
(4)n'a ni test immédiat ni de test ultime
(5)toute solution a des conséquences, souvent irréversibles
(6)n'a pas de liste complète de solutions
(7)est essentiellement unique
(8)peut être considéré comme le symptôme d'autres problèmes
(9)a des causes qu'on peut expliquer de nombreuses manières différentes
(10)le planificateur n'a pas le droit à l'erreur

Les principales méthodes efficaces pour gérer un problème tordu sont de :
(1)reconnaitre que c'est un problème tordu
(2)le découper en plus petits éléments, pas forcément linéaires, mais au moins moins tordus(on notera que cette approche n'a aucun sens sur un problème linéaire : le viaduc de Millau relie, ou ne relie pas, les deux plateaux entourant la vallée; faire déjà un pilier pour voir, et pour l'exploiter, ça n'a pas de sens). Les éléments plus petits, idéalement, apportent chacun un plus fonctionnel, et peuvent être livrés séparément.
(3)appliquer une démarche adaptative pour les morceaux tordus insécables. Ca veut dire qu'on commence avec une feuille de route qui donne des principes généraux, on fait un prototype, on se donne les moyens de le changer drastiquement, et très régulièrement, les parties prenantes donnent leur avis. On le prend en compte, et on recommence. SCRUM marche à peu près comme ça(en plus formalisé).

Mon expérience personelle, c'est que 10% des projets importants sur lesquels j'ai bossé étaient linéaires(dont les deux actuels : une refonte purement technique, et un changement reglementaire - avant, je devait plutôt en être à 5%). Pour eux, le PMI et sa référence le PMBOK seront difficille à surpasser en termes d'efficacité.

Mais pour les autres 90%, c'est juste une catastrophe. A chaque fois qu'une MOA a essayé de décrire complètement toutes les fonctionnalités dont elle aurait besoin, ça a été une catastrophe. Tout simplement parceque c'est jouer aux devinettes. Ca ne rentre pas dans un cerveau humain. Donc, on met plein de trucs qui ne serviront jamais, et on oublie un tas de trucs qui seraient tellement utiles, et on fait un seul énorme projet qui sortira dans 5 ans, et on gèle dès le début une ergonomie qui est plus que foutraque.....

Un problème tordu, ça se comprend au fur et à mesure qu'on le résoud. D'ou l'aberration d'une méthode waterfall genre PMI pour le résoudre.

Mais tu as raison sur un point : tout le monde s'y met. C'est une catastrophe, qui est liée aux autres problèmes évoqués dans ce fil : on ne fait pas confiance au programmeur. Toyota fait confiance à chacun de ses ouvriers, et compte sur chacun d'entre eux pour améliorer le fonctionnement de l'usine. Toyota n'écrit pas un manuel long de 50 pages pour chaque poste de travail. Toyota exige des gens du terrain qu'ils réécrivent le manuel à leur sauce régulièrement - et que celui-ci ne contienne que le strict minimum. Ca ne leur a pas trop porté malheur.

Ce qui nécéssite :
(1)je fais confiance à tout le monde
(2)j'ai les moyens de vérifier la qualité à chaque poste
(3)je ne me sert pas de ces informations chiffrées pour juger les gens(i.e. pas de prime d'objectif individuel : l'ouvrier a une prime à la performance de l'usine, le directeur à une prime à la performance du groupe)

En d'autres termes, voir chaque maillon(humain) de la chaine comme un être pensant, intelligent, naturellement motivé à faire mieux, et le mieux à même de percevoir des défauts de la partie dont il a la responsabilité. Comme tu le soulignes, on en prend pas le chemin

[LSMetag]

D’abord, je trouve curieux de se demander si coder est une tache ingrate sur un site de ce genre ...
Je dirais plutôt que c'est l'analyse UML ou l'élaboration du cahier des charges qui est une tache ingrate.

Personnellement, je suis en dernière année d'école ingénieur et je n'ai pas vu la spécialité « programmeur passionné ». Dommage ??
J’ai pris l'option "Chef de projet" mais je continuerais à coder même si ca peut faire "le chef de projet qui a raté sa carrière."
J’estime qu’on ne peut pas manager une équipe informatique si on ne sais pas ce qu’elle fait techniquement, ou encore palier une urgence si on ne sais pas faire soi-même ce que l’on demande.

Pas du tout d'accord. A mes yeux, c'est de l'architecture. Tu fais tes choix et tu les exposes au client. Des projets sans analyse UML et cahier des charges, j'en ai eu. C'était le merdier...

[maxusn]

Des projets sans analyse UML et cahier des charges, j'en ai eu. C'était le merdier...

+1 je penses que c'est une partie importante d'un projet qu'il ne faut surtout pas négliger, même si personnellement c'est une partie qui ne m’intéresse carrément pas : je préfère largement coder mais sans "feuille de route" ça peut devenir très rapidement compliqué

[LSMetag]

Ah, maintenant on parle le même vocabulaire. J'ai eu une formation PMI de 5 jours en Avril dernier. Le formateur a glissé, entre deux process, la phrase suivante : "Le PMI s'est penché sur le cas des développements agiles. Pour l'instant, ils ne sont pas parvenus à les gérer". Et c'est normal.
...

Personnellement je préfère largement bosser en Agile. Malgré tout t'as des specs, tu connais les fonctionnalités à intégrer pour chaque livraison, tu es en relation directe avec le client (par téléphone ou non par écrit avec un logiciel de Bug Tracking avec une MOE et MOA), tout les matins le CP fait un point et donne la ligne directrice de la journée, quand tu vois un bug, t'as pas besoin de passer par toute la hiérarchie pour le corriger,...

Au contraire je n'aime pas les projets linéaires où tout est chiffré, où tu n'as aucune latitude. Je préfère bosser au résultat. Après évidemment il faut avoir un bon CP.

[erwanlb]

D’abord, je trouve curieux de se demander si coder est une tache ingrate sur un site de ce genre ...
Je dirais plutôt que c'est l'analyse UML ou l'élaboration du cahier des charges qui est une tache ingrate.

Personnellement, je suis en dernière année d'école ingénieur et je n'ai pas vu la spécialité « programmeur passionné ». Dommage ??
J’ai pris l'option "Chef de projet" mais je continuerais à coder même si ca peut faire "le chef de projet qui a raté sa carrière."
J’estime qu’on ne peut pas manager une équipe informatique si on ne sais pas ce qu’elle fait techniquement, ou encore palier une urgence si on ne sais pas faire soi-même ce que l’on demande.

Un ingénieur doué de bon sens et de raison ? Nan c'est une blague ?

[megahertz77]

Ecrire du code est-elle une tache ingrate ?
- C'est comme pour tous les jobs, c'est sympa quand c'est créatif ou innovant, mais chiant quand c'est du code redondant, ou quand il n'y a aucune stimulation intellectuelle.
- Si je devais écrire du code chez le client et changer de client ou de projet tous les 6 mois, oui ça deviendrait un travail ingrat. Surtout si je devais avoir plus de 2h de transport par jour (c'est peut être ça au fond le problème de désaffection du métier).


Quel est votre ressenti sur la question ? Comment voyez-vous le métier de développeur ?
J'ai bientot 41 ans, et je n'ai pas l'impression d'avoir raté ma vie. Bac+2 a 3300€Net/mois, en simple programmeur (non ingénieur), et chef de personne.

Avec tout ça, vous imaginez bien que je ne suis pas chauve, que je ne me fais pas de cheveux blancs, et que je ride uniquement lorsque je lis ce genre d'analyse surréaliste sur la notion de "réussite" ou d'échec.

Je préfère me fier au curseur du bonheur, qu'à celui de la réussite. On peut très bien être heureux sans gagner 10.000€. Être "chef de", ça rapporte parfois beaucoup plus d'emmerdes que de bonheur. Être passionné pour son taf, ne nous dispense pas d'avoir une vie de famille, et de s'épanouir à titre personnel ! Or, je doute qu'un "responsable de" ait beaucoup de temps à consacrer à autre chose que son travail. D'ailleurs cela fait écho à cette analyse (article récent sur developpez.net), qui montre qu'au delà de 40h / semaine, on produit surtout des conneries.

Rester curieux, prendre du recul, apprendre, transmettre son savoir, apprécier ce qu'on fait, c'est pour moi beaucoup plus fondamental.

Si, comme le suggère cet article, personne ne veut plus devenir programmeur, et qu'on laisse faire ça à des débutants qui n'en ont pas non plus envie, et qui n'en ont pas forcément l'expérience, ce métier à d'autant plus d'avenir, et je n'ai aucun doute sur le fait qu'on emploiera toujours des gens, même passé 40 ans dans ce domaine, pourvu qu'ils donnent satisfaction.

Pour rappel, la majorité des gens qui ont plus de 45 ans aujourd'hui, n'ont pas fait d'études d'informatique. Car ce n'était pas un secteur très représenté il y a 25/30 ans dans l'éducation nationale, à part le bac H, dont personne ne se souvient plus, et qui était une voie de garage.

Les jeunes quadras d'aujourd'hui (40-43 ans) ont grandi avec les technologies de l'information. Ce qui fait qu'on ne peut pas les comparer avec les quadras de la décennie précédente statistiquement. (pour ma part, j'ai commencé la programmation a 13 ans tout seul avec un bouquin, des revues mensuelles et un amstrad en 1985, une époque ou l'on trouvait de nombreuses revues de programmation en kiosque, preuve que la programmation s'était démocratisée).

Peut-être dans la sphère parisienne y-a t'il un problème spécifique de la conception du recrutement ? Mais dans ce cas, ça dépasse le cadre de l'informatique, et peut être faudrait-il revoir les cursus et méthodes de formations des R.H.

[Moellen]

Amen, enfin du bon sens (pas les sous pour un amstrad, j'avais un schneider 464 à cassette donc )

Ecrire du code est-elle une tache ingrate ?
- C'est comme pour tous les jobs, c'est sympa quand c'est créatif ou innovant, mais chiant quand c'est du code redondant, ou quand il n'y a aucune stimulation intellectuelle.
- Si je devais écrire du code chez le client et changer de client ou de projet tous les 6 mois, oui ça deviendrait un travail ingrat. Surtout si je devais avoir plus de 2h de transport par jour (c'est peut être ça au fond le problème de désaffection du métier).


Quel est votre ressenti sur la question ? Comment voyez-vous le métier de développeur ?
J'ai bientot 41 ans, et je n'ai pas l'impression d'avoir raté ma vie. Bac+2 a 3300€Net/mois, en simple programmeur (non ingénieur), et chef de personne.

Avec tout ça, vous imaginez bien que je ne suis pas chauve, que je ne me fais pas de cheveux blancs, et que je ride uniquement lorsque je lis ce genre d'analyse surréaliste sur la notion de "réussite" ou d'échec.

Je préfère me fier au curseur du bonheur, qu'à celui de la réussite. On peut très bien être heureux sans gagner 10.000€. Être "chef de", ça rapporte parfois beaucoup plus d'emmerdes que de bonheur. Être passionné pour son taf, ne nous dispense pas d'avoir une vie de famille, et de s'épanouir à titre personnel ! Or, je doute qu'un "responsable de" ait beaucoup de temps à consacrer à autre chose que son travail. D'ailleurs cela fait écho à cette analyse (article récent sur developpez.net), qui montre qu'au delà de 40h / semaine, on produit surtout des conneries.

Rester curieux, prendre du recul, apprendre, transmettre son savoir, apprécier ce qu'on fait, c'est pour moi beaucoup plus fondamental.

Si, comme le suggère cet article, personne ne veut plus devenir programmeur, et qu'on laisse faire ça à des débutants qui n'en ont pas non plus envie, et qui n'en ont pas forcément l'expérience, ce métier à d'autant plus d'avenir, et je n'ai aucun doute sur le fait qu'on emploiera toujours des gens, même passé 40 ans dans ce domaine, pourvu qu'ils donnent satisfaction.

Pour rappel, la majorité des gens qui ont plus de 45 ans aujourd'hui, n'ont pas fait d'études d'informatique. Car ce n'était pas un secteur très représenté il y a 25/30 ans dans l'éducation nationale, à part le bac H, dont personne ne se souvient plus, et qui était une voie de garage.

Les jeunes quadras d'aujourd'hui (40-43 ans) ont grandi avec les technologies de l'information. Ce qui fait qu'on ne peut pas les comparer avec les quadras de la décennie précédente statistiquement. (pour ma part, j'ai commencé la programmation a 13 ans tout seul avec un bouquin, des revues mensuelles et un amstrad en 1985, une époque ou l'on trouvait de nombreuses revues de programmation en kiosque, preuve que la programmation s'était démocratisée).

Peut-être dans la sphère parisienne y-a t'il un problème spécifique de la conception du recrutement ? Mais dans ce cas, ça dépasse le cadre de l'informatique, et peut être faudrait-il revoir les cursus et méthodes de formations des R.H.

[valucard]

Personnellement, je préfère des tâches de plus en plus valorisantes qui se rapprochent de l'architecture de l'Entreprise/SI, l'intégration des systèmes d'informations, middlewares, l'urbanisme et qui permettent de monter en compétence dans ce sens. C'est la vocation de chaque développeur de se spécialiser dans l'architecture, l'urbanisme, le métier et l'analyse fonctionnelle, le management de projet, l'audit, ou carrément sortir du domaine informatique vers un autre domaine dont il est passionné.

[erwanlb]

Personnellement, je préfère des tâches de plus en plus valorisantes qui se rapprochent de l'architecture de l'Entreprise/SI, l'intégration des systèmes d'informations, middlewares, l'urbanisme et qui permettent de monter en compétence dans ce sens. C'est la vocation de chaque développeur de se spécialiser dans l'architecture, l'urbanisme, le métier et l'analyse fonctionnelle, le management de projet, l'audit, ou carrément sortir du domaine informatique vers un autre domaine dont il est passionné.

Qu'est ce que j'en ai a carré de ton urbanisme fonctionnelle d'analyse de projet audité !!!!!!!!!!!!!!!

[bugsan]

Architecture, urbanisme, cartographie applicative, MOE, MOA...
Quand est-ce qu'on va en finir avec ce vocabulaire ? C'est bien à cause de ces métaphores inappropriées qu'on est tous pris pour des ouvriers infantilisés ...

Coder est tout sauf une tache ingrate. Mais c'est bien le message qui est envoyé ici en France, depuis la hiérarchie, depuis ceux qui ont "su s'éloigner de la technique", et "évoluer". C'est à dire tout ceux qui détestent créer, et qui n'ont aucune imagination.
Effectivement, à leur place, je verrais ça comme une tache ingrate. Et tourner en rond dans les couloirs et préparer des réunions où rien n'avance, serait le summum de l'évolution de carrière.

[phili_b]

Personnellement, je préfère des tâches de plus en plus valorisantes qui se rapprochent de l'architecture de l'Entreprise/SI, l'intégration des systèmes d'informations, middlewares, l'urbanisme et qui permettent de monter en compétence dans ce sens. C'est la vocation de chaque développeur de se spécialiser dans l'architecture, l'urbanisme, le métier et l'analyse fonctionnelle, le management de projet, l'audit, ou carrément sortir du domaine informatique vers un autre domaine dont il est passionné.

C'est clair que la compréhension du métier et l'analyse fonctionnelle sont pour moi un vrai plus dans ma motivation. Pour moi un projet intéressant c'est un projet où il y a du technique et du fonctionnel. S'il y a du technique sans fonctionnel ça m'intéresse moins, et que de la doc fonctionnelle sans technique, sans code, ça me manque.

C'est pour cela que je préfère les projets pas trop gros où on peut tout faire.

[free07]

Personnellement, je préfère des tâches de plus en plus valorisantes qui se rapprochent de l'architecture de l'Entreprise/SI, l'intégration des systèmes d'informations, middlewares, l'urbanisme et qui permettent de monter en compétence dans ce sens. C'est la vocation de chaque développeur de se spécialiser dans l'architecture, l'urbanisme, le métier et l'analyse fonctionnelle, le management de projet, l'audit, ou carrément sortir du domaine informatique vers un autre domaine dont il est passionné.

C'est ton choix et il est respectable ( même si je ne le partage pas ).

Mais ce n'est pas une raison pour dévaloriser le travail de développeur ( ou pisseur de code pour certains ) car il est aussi respectable et autant important et précieux.
Pour ma part la vocation du développeur est la réalisation de projets qui aboutissent à une réussite.
( et en même temps, je comprends que l'on ai envie de faire autre chose que de l'info, il se peut que cela m'arrive aussi )

[ac_wingless]

Les 30 ans, je vais bientôt les atteindre... en termes de durée de carrière. Donc les rides, ça va, j'ai tout ce qu'il faut. Du haut des mes cheveux blancs, je puis partager généreusement une certaine expérience.

Eh bien la problématique de cette discussion est très européenne, sans que j'ai vu ce point abordé. En effet, ayant travaillé de nombreuses années aux USA, j'ai pu constater une vraie différence avec ce qui est évoqué ici.

On peut aux USA avoir une carrière très fructueuse en technique pure, terminant en ce qu'il est convenu d'appeler "Technical Fellow". Cela s'applique aussi à la programmation. Un "Technical Fellow" dans un grand groupe gagne typiquement plus de 200k sans parler des stock options, soit à peu près autant qu'un manager de 30 personnes. Mais surtout, il leur est souvent accordé un certain "domaine réservé", avec ou sans budget, avec ou sans personnel, mais ce domaine réservé est explicitement hors des critères de rentabilité s'appliquant au reste des activités. C'est ce qui retient certains à 75 ans et plus, ils s'éclatent sur des trucs, ça marche ou pas, mais si ça marche c'est le jackpot pour la boite, et tout le monde a conscience là-bas qu'un croulant peut apporter une vision stratégique technique qui échappe totalement aux ingénieurs et managers normaux.

Si quelqu'un se fait diriger vers le management à 30 ans aux USA, c'est qu'il n'est pas bon technicien, tout simplement. Cela ne veut pas dire qu'il sera mauvais manager, au contraire (s'il était "seulement" pas bon techniquement, il serait viré).

Quelques autres remarques sur les USA, liées au sujet:
- il est normal de douter de la loyauté des employés en général, et des programmeurs en particulier (l'emploi est un rapport de force, les employeurs étant tout aussi peu scrupuleux que les employés). Donc la programmation par paire est la règle sur les projets vitaux (évidemment on y met les formes, en parlant d'efficacité et de programmation agile, mais c'est bien un problème de manque de confiance, confirmé par le fait que les paires ne sont jamais stables dans le temps, on fait tourner). Dans ce cadre, les seniors sont perçus comme beaucoup plus fiables, il est donc courant de voir des 50 ans+ sur les projets techniques les plus difficiles.
- Inversement il y a l'effet Dilbert. Les ingénieurs ne sont pas respectés comme en Europe, et les moins bons sont placés dans des voies de garage comme le suivi de projet, pour laisser les pointures toucher au code. Par le simple effet mécanique d'une formation moins récente, d'une vie de famille plus exigeante, et peut-être aussi d'une motivation moins grande, ceux qui se trouvent mis sur la touche sont plus souvent les plus vieux. Contrairement à l'Europe, cette mise à l'écart avec l'age vers du faux management (PetitChef) n'est pas liée au mépris de la fonction de codeur, mais plutôt à la réalisation de son importance. Pour terminer Fellow, il faut passer cette phase délicate des 30-40 ans en maintenant sa place parmi les jeunes, et c'est considéré comme une performance, pas un échec comme en France.

[chris44000]

Je trouve que la comparaison avec un ouvrier dans le bâtiment est très bonne.

Un ouvrier qui participe à la construction d'un groupe d'immeubles de 10 étages n'aura pas son mot à dire et exécutera les taches définies selon le plan. C'est un travail de robot et je pense que personne ne rêve de faire ce travail.

Par contre un ouvrier à son compte ou dans une entreprise qui réalise des projets de taille 'humaine' pourra sans doute se faire plaisir dans son travail, développer sa créativité, etc.

c'est l'industrialisation contre l'artisanat. et comme tout dans la vie, chaque 'option' a ses avantages et ses inconvénients.
En France et j'imagine que dans beaucoup d'autres pays, tout est noir ou blanc..

l'éducation est en partie coupable...
dans les écoles d'ingé, quand on vous sort des phrases comme : "Vous êtes l'élite de la France" pendant 4 ou 5 ans, quel est le résultat ?
vous le savez tous..

[el_slapper]

Je trouve que la comparaison avec un ouvrier dans le bâtiment est très bonne.

jusque là, d'accord.

Un ouvrier qui participe à la construction d'un groupe d'immeubles de 10 étages n'aura pas son mot à dire et exécutera les taches définies selon le plan. C'est un travail de robot et je pense que personne ne rêve de faire ce travail.

Foutaises. Il y a toujours des trous dans le plan. Il y a toujours des décisions à prendre. Peut-être pas beaucoup, mais il peut y en avoir. Surtout, il faut avoir l'oeil pour déceler tout souci.

R0d avait raison : personne ne connait plus le monde ouvrier dans ce pays. Leur métier n'est certes pas facile, mais il y a de la technique et de la fierté parmi eux - et à raison.

Par contre un ouvrier à son compte ou dans une entreprise qui réalise des projets de taille 'humaine' pourra sans doute se faire plaisir dans son travail, développer sa créativité, etc.

Il y a des tendances, Certes. Ca dépend aussie de l'entreprise. Chez Toyota, l'ouvrier sur sa chaine a certainement plus d'initiative que certaines petites mains dans de petites boites.

l'éducation est en partie coupable...
dans les écoles d'ingé, quand on vous sort des phrases comme : "Vous êtes l'élite de la France" pendant 4 ou 5 ans, quel est le résultat ?
vous le savez tous..

Là, par contre, d'accord. "Vous êtes l'élite de la nation", c'est une foutaise gravissime. Le pire, c'est que les profs y croient vraiment(en tout cas, on a eu la preuve que les notres y croyaient vraiment).