Discussion :

[Folgore]

Les développeurs bien qu’étant des personnes assez intelligentes

Perso suis loin d’être intelligent: quand il s'agit d’écrire des algo optimal de tri ou recherche (les arbres par exemple ^^) ou réfléchir sur des solution complexes, c'est pas trop ma tasse de thé.

Bref, suis juste un passionné, professionnel tout de même, et qui aime l'informatique et toutes les nouvelles technologies de développement surtout mobile en ce moment, déçoit rarement le client, sauf retards de livraison

Après j'en voit qui sont très intelligent mais qui ne savent pas coder proprement et utiliser un outils efficacement, pire, quand on leur demande de créer des applications assez riches, il y arrivent pas parce que eux, sont très doué pour taper des algos assez bien compliqués, afficher pleins de résultats style debug dans la console... mais, pas concevoir un produit fini et fonctionnel au client constat dans ma promo, simple constat

Bon ca ma suciter une tel remarque en lisant cette phrase, je retourne glander va

[galyathee]

Tout cela demande plus de polyvalence, et plus de compétences. C'est à dire comprendre à la fois, ton client, mais aussi la technique sous-jacente, à son souhait, pour que ton développeur puisse faire son travail.

D'ailleurs les bons consultants métiers, sont généralement diplômés en informatique appliquées à la gestion. Et leur bagage théorique à la fin de leur cursus est bien plus polyvalent que celui du developpeur.

Je bondis quand j'entends cela! C'est n'importe quoi, il faut "surtout" ne rien comprendre pour pondre ce genre d'analyse.

Un consultant, ou toute entité managériale n'est rien sans le produit. Si le produit n'existe pas, on peut certes le vendre mais il faut le coder ensuite et faute de "technicien" on a vendu du vent.

Le consultant métier sait de moins en moins de quoi est capable une technologie, se contentant de faire confiance à 2 lignes en gras dans un magazine où tel framework vend la lune et tel autre les étoiles.

Excusez du peu, mais si coder une application revient - selon les paroles même d'un polytechnicien peu ragoutant - à "pisser du code", alors oui, le consultant est sans doute celui qui prend le plus de risque dans l'affaire et mérite certainement son salaire et les coups de batons qui suivront.

Malheureusement pour ces consultants, et le cas du dvt des ERP en est un très bon exemple, les développeurs sont de plus en plus polyvalents, à même de critiquer, évaluer, développer les solutions eux-même et se passant parfaitement des quelques "globalités" qu'un manager non avancé lui prodiguera. On n'ajoute pas une fonction dans un ERP sans en connaître la logique métier et donc sans connaitre ce à quoi la fonction est destinée.

Allez dire aux concepteurs d'ERP que leur collègue présent depuis 10 ans dans la boite et responsable exclusif - par économie sans doute - de X modules s'en va ... qui va le remplacer sans devoir se taper la lecture du code à l'heure où les managers ne veulent pas entendre parler de surcout pour cause de mise à jour de la doc technique?

Analyse {fonctionnelle, d'impact}, design, estimation de cout, division du travail, code, tests {unitaires, de régression, d'intégration}, documentation, intégration, analyse des états des {bases, logs, mémoire système, connexions réseaux, profils de synchro, etc ...} => sans compter l'aspect "modulable" et "réutilisable" des solutions.

-> on veut encore parler de la polyvalence ?

à bon entendeur...

[tp1024]

La question de fond ressemble vraiment à : quand on construit une maison, les architectes sont bien mieux payés que les maçons, pourtant, il y a pas mal de maçons qui font bien leur métier et ont même souvent plus de connaissances que les architectes. Ces gens là, qui sont payés comme des maçons "classiques", ne devraient-ils pas être payés au moins à la hauteur des architectes, qui, eux, finalement, ne mettent jamais les mains dans le cambouis ?

Sauf qu'un maçon ne fait pas les mêmes études qu'un architecte.
Pour coder, il faut apprendre le métier d'informaticien.
Pour faire fonctionnel, être ingenieur voir avoir de l'experience dans le domaine suffit. Bref, un développeur avec un peu d'experience peut très bien remplacer l'expert fonctionnel, s'il en a envie.
En voulant reprendre ta caricature, le PB de l'informatique, c est qu'actuellement on demande au maçon de construire les plans et à l'architecte d'empiler les blocks (et corriger les plans pour que la construction ressemblement à ce qui a été vendu au client).

[souviron34]

.
Pour faire fonctionnel, être ingenieur voir avoir de l'experience dans le domaine suffit. Bref, un développeur avec un peu d'experience peut très bien remplacer l'expert fonctionnel, s'il en a envie.

Ben voyons..

C'est peut-être pour ça que les ingénieurs Arts et Métiers sont si cotés

Moi Super-Programmeur peut faire n'importe quel boulot, car Moi Seul ait eu besoin de faire des études

Te rends-tu compte de ce que tu dis ????

[el_slapper]

Ben voyons..

C'est peut-être pour ça que les ingénieurs Arts et Métiers sont si cotés

Moi Super-Programmeur peut faire n'importe quel boulot, car Moi Seul ait eu besoin de faire des études

Te rends-tu compte de ce que tu dis ????

Je pense qu'il parle des MOA, alors que toi tu parles des utilisateurs finaux. Pour les MOA il a souvent raison(sauf que ce n'est pas le niveau d'études qui fait le programmeur, mais passons). Les vrais gens du métier, eux, ont souvent des années de bouteille et/ou d'études pour arriver à une compréhension correcte de leur domaine.

Les agents back-office avec qui j'ai bossé par le passé n'avait d'ailleurs en général pas plus que le bac(quand ils l'avaient). Mais ils avaient quasiment tous plus de 30 ans de maison, et il était hors de question de leur apprendre leur boulot. La MOA, elle, soit a elle aussi 30 ans de maison(et tout se passe bien), soit vient du coté programmation(ce que les devs apprécient, mais ça pose des problèmes culturels de l'autre coté), soit sort d'école de commerce, et c'est, hum, aléatoire.

Ce qui pose problème, aussi, c'est quand la MOA se permet de définir des éléments techniques (exemple vécu récemment, et qui a posé plein de problèmes : voici les données que va recevoir votre batch, et voici les formats de fichiers. Ma réponse : euh, c'est pas possible, il faut un format de données unique, en plus c'est plus facile aussi pour vous, sinon on va quadrupler les couts de maintenance. Leur réponse : ta gueule, sombre vermisseau, tu n'as pas droit à la parole. Conclusion de ma hiérarchie : arrête d'embeter la MOA, s'il te plait). Leur métier, à mon sens, est de nous dire le quoi(ici, nous allons recevoir des éléments marketing, et devons en faire quelque chose d'utilisable, selon des règles définies par leurs soins). Le notre, c'est de définir le comment.

Quand tu parlais de polyvalence, mon problème ici est que la MOA se croit polyvalente. Elle prétend comprendre l'essentiel du métier des markéteurs(c'est possible, mais je ne suis pas en mesure de le vérifier). Elle prétend savoir homologuer nos traitements(c'est faux, j'ai été homologateur, je n'étais pas forcément le meilleur, mais ils ne m'arrivent pas à la cheville). Elle prétend dicter nos choix techniques, et c'est une catastrophe. Elle est payée beaucoup plus que nous, et a tous les droits.

A ce titre, j'ai de la sympathie pour le message de TP1024 : si il a rencontré le même genre de zigotos que moi, il peut avoir un sentiment légèrement négatif vis-à-vis de ce genre d'imposteurs. Même si il faut savoir rester à sa place, et ne pas inventer les besoins du client parceque c'est plus facile à coder(erreur qu'il m'est arrivé de commettre, je l'avoue).

[souviron34]

ce qui confrme ce que je disais dans les autres threads : la MOA ou AMOA est non seulement une inventon et spécificité française, mais une aberration.. et due en grande partie à l'influence gigantesque des banques et assurances/mutuelles sur le dev informatique en France..

[SurferIX]

Sauf qu'un maçon ne fait pas les mêmes études qu'un architecte.
Pour coder, il faut apprendre le métier d'informaticien.
Pour faire fonctionnel, être ingenieur voir avoir de l'experience dans le domaine suffit. Bref, un développeur avec un peu d'experience peut très bien remplacer l'expert fonctionnel, s'il en a envie.
En voulant reprendre ta caricature, le PB de l'informatique, c est qu'actuellement on demande au maçon de construire les plans et à l'architecte d'empiler les blocks (et corriger les plans pour que la construction ressemblement à ce qui a été vendu au client).

Excuse moi, mais je ne vois pas la chose de la même manière :
En voulant reprendre ma caricature, le problème de l'informatique, c'est qu'actuellement on se demande comment il est possible qu'un bon maçon qui a de l'expérience puisse construire lui même tout seul ses maisons en se passant d'un ingénieur, et qu'à l'inverse, les architectes, effectivement, pètent un câble, parce qu'après avoir grossièrement (et en informatique le terme est faible) dessiné une caricature de maison au fusain sur une planche de bois et avoir été payé des dizaines de milliers d'euros, ils ne comprennent pas (et en informatique le terme est une réalité concrète sur le terrain) que le maçon, qui en a ras la casquette d'être payé au RMI à travailler 12 heures par jour pour cet architecte, se barre en plein milieu du chantier.

Dans ce genre de cadre qui, ramené à l'informatique, n'est presque pas de la caricature, l'architecte qui ne comprend rien parce qu'il est tout simplement incompétent techniquement (et le terme est faible), essaie systématiquement de tout ramener à la faute du maçon, et va vite en chercher un autre qui acceptera, comme le précédent, le cinéma "RMI à travailler 12 heures par jour".

Et dans tous ça le client voit quoi ? Bah c'est simple : il ne discute qu'avec les architectes. Donc inévitablement, le client croit l'architecte lorsque ce dernier lui dit que les maçons sont des incompétents, voire de crétins, qu'ils ne comprennent rien à leurs directives, et qu'à l'inverse, les architectes des demi-dieux qui pensent toujours à tout.

Donc je comprends parfaitement le ras-le bol des maçons compétents.

Et j'insiste sur ce dernier mot, parce que lorsqu'ils ne le sont pas, effectivement, tu as raison.

Petit HS : vas demander à la plupart des manuels qui font du béton ciré pour les grosses boites, ce qu'ils pensent des architectes, et tu verras que finalement, cette caricature n'est pas si éloignée de la réalité que ça...

[den77eu]

Je rejoins l'avis de punkoff.
Un dev sur une plateforme ERP va nécessairement accumuler de la connaissance fonctionnelle avec les années et pourra, à terme, prendre son propre envol sur certaines définitions des besoins métier.
Après tout, une des caractéristiques du métier de développeur (en Gal), c'est de chercher à assouvir régulièrement son besoin de connaissance.
Définir des règles métier, ça va bien pendant un temps: penser test et qualité, évolutivité, coût de réa et centralisation des outils/données (ou pas), ça demande un certain recul technique, que n'ont pas forcément les gens qui se cantonnent au spec métiers.

Actuellement, on parle de déporter du besoin IT vers le "Cloud" et on voit certains consultants métiers/gestionnaires de projet/comme on veut les appeler, se manger méchamment avec leur définition de besoin. Inutile ici, d'évoquer les effets de tels choix de solutions, si elles ne sont pas envisagées côté technique très rapidement et certainement, avant toute mise en œuvre. Ce n'est qu'un exemple...
A mon sens, plus tu évolues dans ta carrière de développeur, plus tu prends du bagage de tous les côtés et plus tu amènes de valeur à ta fonction. A la base, difficile de dire qui doit être payer plus que l'autre, mais assez vite, c'est le développeur qui va bouffer le gars métier, en terme de compétence.

Enfin ici, je pense, comme vous autres, que c'est un problème franco-français, qui tiens plus à la manière de segmenter les fonctions. ça n'est pas réservé au dev info d'ailleurs. Je dirais plutôt que ça tient à la manière dont on considère les gens dans leur travail, par chez nous.

[lepinekong]

Il y a un grand écart entre un programmeur qui fait juste de l'assemblage dans une SSII ou chez un Grand Compte et un programmeur chez Apple ou Google ou des startups qui font des produits grands publics.

Il y a aussi un grand écart entre un jeune diplômé qui est nommé chef de projet sans aucune réelle expérience ou une personne mono-projet mono-domaine mono techno et une autre qui a fait des dizaines et des dizaines de projet sur x projets, domaines, technos.

Il y a donc des programmeurs des vrais qui seront mieux payés que des chefs de projet débutants mais la plupart ne sont que des assembleurs non parce qu'ils ne sont pas capables d'en faire plus mais parce qu'avec les frameworks d'aujourd'hui on ne leur en demande finalement pas plus.

J'ai connu une époque ou un centralien devenait et restait programmeur toute sa vie. A l'époque ce n'était pas que de l'assemblage sans doute.

[Model_T101]

Bonjour, je vois que c'est pareil dans tous les domaines...

Citation : "Pourquoi il n'y a pas de Google, Microsoft, Apple, Facebook, Paypal ? Parce qu'en France on ne privilégie ni le talent ni l'esprit d'entreprise. Il vaut mieux donc être salarié en France..."

Dans le domaine de la programmation, l'imagination est la seule limite. Linus Torvald à écrit quelques lignes de code et Linux est mondial, combien d'argent faut il pour écrire sur PC ? Facebook ? un blog avec données croisées, temps réel, sous une interface utlisateur graphique... Je ne sais pas comment est le marché du travail dans votre domaine, mais il me semble plus ouvert et plus riche de possibilités... Combien de VLC, de CCleaner, SuSE, Instagramm...

[MiaowZedong]

Dans le domaine de la programmation, l'imagination est la seule limite. Linus Torvald à écrit quelques lignes de code et Linux est mondial, combien d'argent faut il pour écrire sur PC ? Facebook ? un blog avec données croisées, temps réel, sous une interface utlisateur graphique... Je ne sais pas comment est le marché du travail dans votre domaine, mais il me semble plus ouvert et plus riche de possibilités... Combien de VLC, de CCleaner, SuSE, Instagramm...

Voila bien pourquoi tant de startups échouent: on a bonne idée, on se dit qu'il suffit de quelques lignes de code, et on lance sa startup.

La majorité des startups coulent par insuffisance technique.

Pour faire Google ou Facebook, c'est vrai qu'on peut se lancer sans beaucoup d'argent. Mais le génie et le travail demandés sont énormes: Google c'est avant tout une batterie d'algorithmes pointus que 99% des programeurs (y comprit sans doute beaucoup de leurs salariés actuels) ne comprendraient pas. Facebook ne se repose pas sur jQueryUI et un CMS open-source, ils ne sont pas hebergés par OVH ou GoDaddy. Pour délivrer autant de fonctionnalités, avec une bonne qualité de service, il faut tout faire soi-même.

Donc non, il ne suffit pas d'avoir une bonne idée et d'"écrire quelques lignes de code" pour lancer une multinationale IT.

[lepinekong]

Le marché est devenu de masse et donc est tiré par les prix et non plus par la qualité à cause des services achats qui ne s'y connaissent pas, les Managers Opérationnel eux-même s'y connaissent de moins en moins ...

Un très bon développeur aujourd'hui a énormément d'opportunités mais il faut qu'il prenne des risques par exemple le cas remarquable de Jonathan Blow http://www.theatlantic.com/magazine/...us-gamer/8928/, il a passé 3 ans à designer et coder son jeu tout en faisant un job de consulting à mi-temps jusqu'à ce que son jeu ait finalement du succès.

Le risque a été récompensé mais lui se savait suffisamment bon pour le prendre. Si on est vraiment très bon, on le sait, les idées ça ne manque pas, si on n'est juste bon comme beaucoup il faut subir la loi du marché mais le job est tranquille donc il faut pas trop pleurer non plus.

Moi je ne suis pas développeur (je connais assez bien les caractéristiques avancés de tous les langages mais de là à aligner des kms de code non), mais si je l'avais été au début j'aurais cherché à devenir l'un des meilleurs dans une plateforme.

Je constate chez beaucoup de développeurs d'aujourd'hui un manque de passion et en général cela signifie déjà pour moi que le développeur en question n'est pas très bon potentiellement.

[Model_T101]

On pense à la multi-nationale quand elle arrive à maturité après des années, mais de "Hello world" à Redhat, Debian, Ubuntu... il à fallu partir crescdendo.

Si aujourd'hui les SSII prennent des commandes, facturent leurs clients, c'est qu'il y'a des programmeurs qui codent les lignes qu'on leur demande pour réaliser ce qui au départ n'est qu'un projet. S'il avait fallu s'arreter à la premiere ligne Photoshop n'existerait pas. Evidemment il faut gérer le projet correctement, mais à mon avis tout pars d'une idée, ensuite on la développe et puis on la propose, les premieres retombées, on corrige on re-publie...Android, iOS combien d'appli et le telephone n'est pas le seul débouché.

[SurferIX]

Linus Torvald à écrit quelques lignes de code et Linux est mondial...

Euh là trouve moi combien de Français, voire de personnes dans le monde qui s'enfermeraient l'intégralité de leurs vacances sans sortir, jour et nuit (à tel point que ses copains lancaient des cailloux sur ses volets pour le forcer à les ouvrir et pour savoir si tout allait bien), à lire des protocoles et à tenter de les appliquer en codant ?

Je crois que tu n'as pas choisi le bon exemple pour dire "la seule limite c'est l'imagination". Il faut aussi à la fois la passion et le temps, deux choses qui s'égrennent au fil du temps. Principalement le temps .

Ben voyons... Il prend quoi, comme risque, le chef de projet ?

Je veux bien qu'un développeur qui passe chef de projet se retrouve avec plus de boulot, ce qui peut justifier un salaire augmenté (bien que ce ne soit que rarement l'explication des inégalités salariales), mais ça n'entraîne aucun risque supplémentaire.

Si ce n'est deux choses : faire capoter le projet (des développeurs n'ont pas forcément la capacité de faire chef de projet (principalement le fait de savoir comprendre la hiérarchie et faire appliquer sans problème)) et (pire) perdre son job car c'est lui qui gère tout un projet, et il a pas intérêt à foirer. Alors que quand on est dans une équipe de dix développeurs, même si tu fais de la daube, il y aura toujours d'autres développeurs soit pour corriger le tir, soit pour t'aider si tu rame.

C'est bien dommage de ne pas se consacrer au developpement de projets personnels meme en commun avec des collègues...

Google donne des objectifs, et ses employés font comme bon leur semble, et il autorise même un peu du temps d'entreprise aux passions (une après midi par semaine je crois) (à moins que cette règle n'ait changé). Essaie d'expliquer ça aux patrons qui ont la trique en lisant le salaire moyen d'un développeur Marocain qui n'est jamais payé en heures supplémentaires et dont le salaire moyen mensuel pour un ingénieur informaticien est de 986 euros net.

[Model_T101]

je suis d'accord avec toi, mais Rome ne s'est pas faite en un jour, et rien de grand en ce monde n'a été fait sans passion. On se demande pourquoi l'executant est moins payé que le donneur d'ordre, je dis juste que le cordonnier est encore le pus mal chaussé et qu'il peu etre son propre donneur d'ordre. ça vaut pour tous les domaines, ce n'est qu'une idée mais elle vaut ce qu'elle vaut.

[deuz59]

je suis d'accord avec toi, mais Rome ne s'est pas faite en un jour, et rien de grand en ce monde n'a été fait sans passion. On se demande pourquoi l'executant est moins payé que le donneur d'ordre, je dis juste que le cordonnier est encore le pus mal chaussé et qu'il peu etre son propre donneur d'ordre. ça vaut pour tous les domaines, ce n'est qu'une idée mais elle vaut ce qu'elle vaut.

Tout le monde peut être son propre donneur d'ordres, la responsabilité de l'être pour un ensemble et d'assurer la cohérence et l'atteinte de l'objectif global est tout autre...c'est peut être pour ça qu'y a moins de monde pour le faire ...et moins de demande => meilleure rémunération CQFD

[Model_T101]

debian est une oeuvre coordonnée par tous les participants ce n'est pas le seul exemple collaboratif, une reunion du syndic de copro, une reunion d'assemblee generale d'une entreprise... il est vrai que la structure verticale, un capitaine des marins est la plus repandue.

[boz74]

Tout le monde peut être son propre donneur d'ordres, la responsabilité de l'être pour un ensemble et d'assurer la cohérence et l'atteinte de l'objectif global est tout autre...c'est peut être pour ça qu'y a moins de monde pour le faire ...et moins de demande => meilleure rémunération CQFD

Plus de demande et moins d'offre (et non pas le contraire), c'est effectivement la principale raison qui explique, sans pour autant le justifier, que le CdP gagne plus que le dev. Le reste est au mieux secondaire au pire du pipeau.

[I_believe_in_code]

Le manager risque de :

(...) perdre son job car c'est lui qui gère tout un projet, et il a pas intérêt à foirer. Alors que quand on est dans une équipe de dix développeurs, même si tu fais de la daube, il y aura toujours d'autres développeurs soit pour corriger le tir, soit pour t'aider si tu rame.

Peut-être mais le développeur en question risque aussi de perdre son travail, sans doute précisément à la demande du chef de projet qui aura intérêt à agir de la sorte pour ne pas risquer lui-même de perdre sa place.

Bref, s'en sortent le mieux ceux qui :

- sont bons et sont leur propre patron ;
- sont bons et n'ont que d'autres bons au-dessus d'eux dans la hiérarchie.

[SurferIX]

Bref, s'en sortent le mieux ceux qui :

- sont bons et sont leur propre patron ;
- sont bons et n'ont que d'autres bons au-dessus d'eux dans la hiérarchie.

100 % d'accord. Mais c'est très rare, et tellement rare, que, justement, on en arrive à l'aberration qui fait qu'on est sur le sujet dont on parle (par extension du problème).