Discussion :

[remi_inconnu]

j'ai commencé à coder à 17 ans par passion, et à 48 je code toujours même si je suis responsable technique. Le code est un art, savoir architecturer une appli correctement demande de réelles compétences, qu'aucun diplôme n'apportera jamais. Et puis j'avoue m'amuser beaucoup plus à écrire des lignes de codes, qu'à faire des power point, excel, réunion stérile... C'est pour moi infiniment plus créatif de coder, je prends plaisirs et avoir comme retour la satisfaction des clients qui apprécient que ce que j'ai livré marche comme une horloge suisse, facile à utiliser et bien documenté, ces retours valent plus qu'une belle promotion dans lequel j'aurais l'impression de perdre mon temps dans des futilités. Bref 31 ans de codage et fière d'être encore un grouillot...

[Matthieu Vergne]

Pour ainsi dire, avec les outils de génération automatique de code dans le langage qu'on veut, c'est pas plus la compétence de programmeur qui perd de son attrait que le poste même de programmeur qui perd de son intérêt (financier, je précise). Aujourd'hui, on préfère faire des beaux schémas UML ou que sais-je, ce que les non programmeurs savent lire à peu près et discuter en réunion, puis lancer la moulinette qui va traduire tout ça en code où il ne restera plus qu'à mettre la logique métier derrière, en supposant qu'on n'ait pas aussi une description quelque part qui nous permette de générer aussi la logique métier. C'est que ça bosse dur sur les transformations : http://www.zeitnews.org/applied-scie...inary-language

[kindo.amadou]

je suis africain et j'ai 48 ans ! analyste-programmeur depuis 25 ans et en suis fiers ! Bien sûr qu'aujourd'hui vu mes fonctions actuelles, je "code" de moins en moins! Mais mon sentiment est que l'on constates aujourd'hui que les logiciels et produits sont de moins en moins stables, fragiles et sujets à de nouvelles versions et patchs incessants ! A mon mon avis de "dynosaure codeur", cela est du en partie au fait que les "news développeurs" ne codent plus et se font largement assister par les outils. Les résultats sont certes plus rapides, mais quelque part, on n'a pas la maitrise totale et absolue de la chose!
Nostalgique, vous direz ! mais le code avec les langages de 3ème géné. a fait ses preuves et en continue encore! J'ai encore des codes qui datent de 1994, écris en Fox pro (sans souris s'il vous plait) et qui font encore la fierté et l’orgueil de leurs utilisateurs.....................
@++

[Mat.M]

On a les modèles que l'on veut bien se donner... A part Wozniak, les autres ne sont que des marketeux ou au mieux des commerciaux, donc l'admiration ce sera pour une autre fois. Est-ce que les milliards de dollars qu'ils ont accumulés ont rendu l'humanité meilleure ? Je vais être vache mais Jobs ne les a pas emportés avec lui. Cette course au billet vert en rime à rien et nous perd tous.

là je suis déçu par ce genre de message il faudrait peut-être revenir à la réalité...
on est dans une économie de marché le but d'une entreprise c'est tout de même de gagner de l'argent ça permet d'embaucher des gens et de faire tourner l'économie.
Je sais qu'on a vraiment du mal dans la mentalité française ( c'est peut-être la raison du marasme économique en France) l'argent en France c'est tabou..
mais s'il y avait des Steve Jobs ou des Zuckenberg en France ça contribuerait à améliorer le fonctionnement de l'Economie.
Si on prend rien que Facebook France ça fait déjà une centaine d'emplois en France c'est pas si mal que ça
Et tout ça parce qu'un ado américain attardé a crée une entrerprise qui vaut des milliards.

Pour ce qui est d'Apple la capitalisation de l'entreprise c'est des milliards; d'accord ils sous-traitent à Foxconn en Chine mais ça contribue tout de même à la croissance de l'Economie américaine.

Désolé si je m'écarte du sujet principal

[Matthieu Vergne]

Le problème n'est pas tant de rassembler de l'argent, c'est surtout de rassembler de l'argent pour rassembler de l'argent. Si ça favorise l'économie, ça ne favorise pas les peuples : ceux qui sont riches le sont encore plus, ceux qui sont pauvres le sont encore plus. Ça favorise l'économie dans le sens où l'argent bouge, mais il faut voir comment il bouge : entre les riches, et de pauvres à riche (les pauvres n'ayant rien à vendre que les riches ne veulent, voire les riches ayant suffisamment d'influence pour l'obtenir sans dépenser un rond pour les pauvres).

L'objectif d'une entreprise c'est de faire de l'argent, par définition, et c'est ce qu'on apprend quand on prend des cours d'entrepreunariat. Et toutes les techniques qu'on peut mettre en place visent donc à faire du profit (y compris des techniques visant à favoriser l'humain, qui se contentent juste d'augmenter la durée de vie des entreprises en leur donnant une bonne image). Mais faire du profit ne devrait pas être un objectif, en plaçant le côté humain comme moyen d'en faire, ça devrait être l'inverse. L'objectif devrait être sur l'humain (e.g. augmenter les moyens des salariés, augmenter l'offre pour les clients). En plaçant le profit comme objectif, on ne fixe rien au niveau humain (il y a des techniques pour, d'autres contre, libre au patron de décider laquelle il applique), et donc forcément c'est à ceux qui ont le pouvoir de décider ce qu'on en fait de cet argent. Et le fait que ce soit moralement acceptable ne dépend donc que de ceux qui veulent bien s'en donner la peine.

[Pierrot_FR]

Écrire du code est-il une tache ingrate ?

Quel est votre ressenti sur la question ? Comment voyez-vous le métier de développeur ?

Dans la majeure partie des cas, écrire du code est une tâche ingrate.
En général, on part du principe qu'un développeur n'est pas là pour réfléchir mais pour coder des idées, analyses effectuées par les chefs de projet ou analystes.
Pourtant un développeur devrait réfléchir sur "comment coder" de façon efficace... Car il y a programmer et programmer....
Malheureusement, du moment que le résultat est là.... la méthode importe peu.
Il est vrai que la puissance des machines et des langages de programmation font que l'on ne s'attache pas en premier lieu de l'efficacité du code.
(Rappelez vous les anciens quand on comptait le nombre d'octets pour rendre une application la moins gourmande en taille...)

Cette attitude est à mon sens une hérésie..... Car si à court terme cela passe.... Il y a un moment où le manque d'optimisation est flagrante et peut faire capoter un projet. (Combien d'applications sous-estiment le volume de données à traiter ... ?)

Ensuite socialement, le développeur est au bas de l'échelle des salaires en informatique.... Raison pour laquelle beaucoup de développeurs veulent évoluer vers une rémunération plus importante et finissent par migrer vers des fonctions "moins productives" mais plus "encadrantes".

Tant que la société sera orientée finance.... car il ne faut pas se voiler la face, en France et dans beaucoup de pays, l'esprit financier est plus que partie prenante dans la vie de tous les jours.... Et bien tant que cela sera comme cela.... Il est fort à parier que l'avenir des développeurs...et surtout des jeunes développeurs n'est pas très rose...

C'est une vision plus que pessimiste mais tellement vraie....

Et juste pour finir, est ce que les développeurs pourraient faire évoluer les mentalités ?
En fait c'est compliqué, car rappelez vous qu'un développeur a un petit salaire si en plus il se met à se rebeller.... son avenir est plus que compromis...
Il n'y a que l'union de tous les développeurs qui pourrait faire changer les choses....
Mais il y aurait des dommages collatéraux.... Alors la question est : Jusqu'où sommes nous prêts à aller pour un monde meilleur :-)

J'arrête là car après ca dérappe en politique car là aussi... ils ont une grande part de responsabilité de ce qui nous arrive... ;-)

[LSMetag]

J'ai 75 ans,je suis à la retraite depuis des lustres et depuis une douzaine d'années j'occupe mes loisirs comme informaticien bénévole d'une association nationale.
Pour moi les trois vont de pair, je programme toujours avec plaisir ce que j'ai conçu. Je pense qu'en faisant les trois tout seul on peut optimiser pas mal de choses. L'inconvénient est de ne pas pouvoir profiter de l'expérience des autres.
Tout ce que je pourrais vous dire à vous qui avez l'age de mes enfants, c'est que nous avons un métier passionnant, en perpétuelle évolution et qui nécessite une adaptation continue: nouveaux langages, nouveaux outils et même nouveaux systèmes d'exploitation.
Avec Internet (un grand merci à Developpez.com) on trouve tout ce que l'on veut pour se mettre à jour, et c'est dans cet effort d'adaptation, dans cette curiosité intellectuelle que réside l'intérêt de notre métier.
Se contenter de coder et dans un seul langage est certainement lassant, vivre uniquement sur l'acquis mène droit au mur.

C'est beau. Franchement j'espère être comme vous quand j'aurai votre âge.

[LSMetag]

Pour ainsi dire, avec les outils de génération automatique de code dans le langage qu'on veut, c'est pas plus la compétence de programmeur qui perd de son attrait que le poste même de programmeur qui perd de son intérêt (financier, je précise). Aujourd'hui, on préfère faire des beaux schémas UML ou que sais-je, ce que les non programmeurs savent lire à peu près et discuter en réunion, puis lancer la moulinette qui va traduire tout ça en code où il ne restera plus qu'à mettre la logique métier derrière, en supposant qu'on n'ait pas aussi une description quelque part qui nous permette de générer aussi la logique métier. C'est que ça bosse dur sur les transformations : http://www.zeitnews.org/applied-scie...inary-language

Justement, c'est de l'architecture. Ne pas faire de schémas Merise ou UML est une hérésie si tu veux créer une application structurée, réutilisable, maintenable, et je dirais même fiable et performante (sans parler du gain de productivité et du travail en équipe). L'intérêt dans le développement c'est le raisonnement. Après ok, tu peux générer tes classes avec une base d'ORM mais ça s'arrête là. Ca évite justement ce genre de tâches rébarbatives qui consistent à pisser du code et faire des copier/coller modifiés. Après on retouche si on trouve certains choix des outils perfectibles.

Le travail d'un développeur consiste également à être capable de choisir/créer des outils performants selon son besoin.

Bref, tu prônes le boulot de pisseur de code, pas de développeur.

[LSMetag]

là je suis déçu par ce genre de message il faudrait peut-être revenir à la réalité...
on est dans une économie de marché le but d'une entreprise c'est tout de même de gagner de l'argent ça permet d'embaucher des gens et de faire tourner l'économie.
Je sais qu'on a vraiment du mal dans la mentalité française ( c'est peut-être la raison du marasme économique en France) l'argent en France c'est tabou..
mais s'il y avait des Steve Jobs ou des Zuckenberg en France ça contribuerait à améliorer le fonctionnement de l'Economie.
Si on prend rien que Facebook France ça fait déjà une centaine d'emplois en France c'est pas si mal que ça
Et tout ça parce qu'un ado américain attardé a crée une entrerprise qui vaut des milliards.

Pour ce qui est d'Apple la capitalisation de l'entreprise c'est des milliards; d'accord ils sous-traitent à Foxconn en Chine mais ça contribue tout de même à la croissance de l'Economie américaine.

Désolé si je m'écarte du sujet principal

Ouais mais y a des limites au capitalisme. Oui une entreprise est là pour gagner de l'argent. Sauf que de nos jours, on veut gagner le plus possible à tout prix. Et pour cela, on sacrifie la qualité.
Voir on fait comme aux USA, pays adorateur de l'argent, on spécule et on escroque pour gagner de l'argent, jusqu'à provoquer une crise mondiale.

L'argent c'est bien, il en faut pour faire tourner l'économie et pour vivre. Mais à mes yeux, quand on en a déja suffisamment pour vivre/faire confortablement, c'est déja très bien. Le capitalisme d'aujourd'hui, c'est en vouloir toujours plus, par tous les moyens.

[LSMetag]

Dans la majeure partie des cas, écrire du code est une tâche ingrate.
En général, on part du principe qu'un développeur n'est pas là pour réfléchir mais pour coder des idées, analyses effectuées par les chefs de projet ou analystes.
Pourtant un développeur devrait réfléchir sur "comment coder" de façon efficace... Car il y a programmer et programmer....
Malheureusement, du moment que le résultat est là.... la méthode importe peu.
Il est vrai que la puissance des machines et des langages de programmation font que l'on ne s'attache pas en premier lieu de l'efficacité du code.
(Rappelez vous les anciens quand on comptait le nombre d'octets pour rendre une application la moins gourmande en taille...)

Cette attitude est à mon sens une hérésie..... Car si à court terme cela passe.... Il y a un moment où le manque d'optimisation est flagrante et peut faire capoter un projet. (Combien d'applications sous-estiment le volume de données à traiter ... ?)

Ensuite socialement, le développeur est au bas de l'échelle des salaires en informatique.... Raison pour laquelle beaucoup de développeurs veulent évoluer vers une rémunération plus importante et finissent par migrer vers des fonctions "moins productives" mais plus "encadrantes".

Tant que la société sera orientée finance.... car il ne faut pas se voiler la face, en France et dans beaucoup de pays, l'esprit financier est plus que partie prenante dans la vie de tous les jours.... Et bien tant que cela sera comme cela.... Il est fort à parier que l'avenir des développeurs...et surtout des jeunes développeurs n'est pas très rose...

C'est une vision plus que pessimiste mais tellement vraie....

Et juste pour finir, est ce que les développeurs pourraient faire évoluer les mentalités ?
En fait c'est compliqué, car rappelez vous qu'un développeur a un petit salaire si en plus il se met à se rebeller.... son avenir est plus que compromis...
Il n'y a que l'union de tous les développeurs qui pourrait faire changer les choses....
Mais il y aurait des dommages collatéraux.... Alors la question est : Jusqu'où sommes nous prêts à aller pour un monde meilleur :-)

J'arrête là car après ca dérappe en politique car là aussi... ils ont une grande part de responsabilité de ce qui nous arrive... ;-)

D'accord avec toi, le pessimisme en moins ^^. J'ai arrêté les SSII aussi parce que justement on décide tout à notre place, et nous on a juste à coder ça comme on nous a demandé pour que ça marche. La moindre remarque sur l'existant sera au mieux prise en compte et notée sur un calepin pour être ressortie s'il finit par y avoir une anomalie grave ou bloquante dans l'application concernant cette remarque.
Mais dans la grande partie des cas, tu n'as aucun pouvoir, car tout vient d'en haut, tout est lié aux coûts et à la facturation à la tâche.
Tu peux même te faire engueuler/virer si tu as le malheur d'améliorer l'application sans qu'on te le demande.

Heureusement, dans les PME type startup, la place à l'individualité, au dialogue, au raisonnement et aux remises en question est bien plus grande. Et là tu peux vraiment développer.

En SSII, il n'y a guère qu'au niveau d'Architecte (10 ans d'expérience) que tu as officiellement le droit de prendre des décisions (et encore t'as toujours le client qui n'y connait rien sur les bras pour te dire "non je veux du WebSphere Portal parce qu'on a été partenaire avec IBM", ce qui ensuite donne une mauvaise image des développeurs et une mauvaise communication car les utilisateurs ne sont pas contents (ça rame, c'est buggué, c'est pas user friendly,...)).

[negstek]

Pour moi la source du problème c'est les salaires, un expert technique touche pas beaucoup alors qu'un gratte planning adepte des réunions avec la direction touchera le jackpot ce qui est paradoxal car c'est lui qui va ralentir les projets en prenant des décisions hasardeuses et non pertinentes alors que pour moi c'est l'expert technique le pilier du projet qui le mènera à terme. Pourtant ce n'est pas lui qui sera le plus récompensé au final.

"Le monde est en train de devenir cinglé !" (Walter Sobchak, The Big Lebowski)

C'est pour ça que les jeunes ne veulent pas être développeur, ils cherchent le steak comme quasiment tout un chacun !

Pour ceux qui veulent encore plus de flouze, je leur dirai de faire du data mining coté compta dans des gros ERP comme SAP assaisonné de stats (ce qui en répugne plus d'un) et de BI et là c'est le pactole garanti.

[phili_b]

BI et là c'est le pactole garanti.

La BI ce n'est pas le pactole garanti. La BI consomme beaucoup de monde à la conception et à la mise en place, mais en exploitation et gestion de tout les jours ça n'a besoin que d'une ou deux personnes.

Et donc si tu ne veux plus te déplacer à droite et à gauche ce n'est pas évident de tomber sur ces un ou 2 postes.

Et en plus à cause de cela, puisque c'est difficile de trouver des postes de sédentaires (prestataire ou interne), les ssii ont tendance à surchiffrer les projets BI. Autrement dit c'est bien d'essayer de placer plein de gens, mais on en vient à des projets usines à gaz de plusieurs mois beaucoup plus chers qu'ils ne devraient l'être.

En plus la BI est souvent mal compris des commerciaux en ssii. Si les commerciaux ne sont pas spécialisés en BI c'est très difficile d'en vendre. J'ai connu cela plusieurs fois où, du jour au lendemain quand un bon commercial BI se barrait, les commerciaux non au fait de la BI étaient infoutus de me placer ou dans des trucs qui n'avait rien à voir.

C'est difficile à vendre car si ce n'est pas vendu comme un outil d'aide à la décision, ce n'est compris que comme un centre de coût comme la cerise du gâteau car ce n'est pas de l'opérationnel directement. Une boite peut en théorie très bien se passer de BI contrairement à son logiciel opérationnel (vente, logistique, et...).

[Matthieu Vergne]

Justement, c'est de l'architecture. Ne pas faire de schémas Merise ou UML est une hérésie si tu veux créer une application structurée, réutilisable, maintenable, et je dirais même fiable et performante (sans parler du gain de productivité et du travail en équipe). L'intérêt dans le développement c'est le raisonnement. Après ok, tu peux générer tes classes avec une base d'ORM mais ça s'arrête là. Ca évite justement ce genre de tâches rébarbatives qui consistent à pisser du code et faire des copier/coller modifiés. Après on retouche si on trouve certains choix des outils perfectibles.

Le travail d'un développeur consiste également à être capable de choisir/créer des outils performants selon son besoin.

Bref, tu prônes le boulot de pisseur de code, pas de développeur.

Faux. Dans la programmation, il n'y a pas que la raisonnement abstrait qui compte. Tout ce qui est optimisation en particulier ne concerne que peu l'architecture abstraite que tu as dans tes diagrammes, mais avant tout le système concret sur lequel tu l'applique. Par exemple, en Java tu utiliseras un HashSet ou LinkedHashSet ou TreeSet selon l'utilisation que tu feras de ta collection, détail qui n'a aucune raison d'être dans tes diagrammes, mais qui peut avoir un impact notable sur les performances. Et ça c'est pas un pisseur de code qui va le trouver tout seul. Tes diagrammes permettent d'avoir une idée plus ou moins générale, selon le niveau de détails dans lequel tu descend, mais arrivé à un niveau très détaillé le diagramme devient fastidieux à faire et pas assez expressif pour tenir compte des détails nécessaire, donc tu passes au code.

C'est plutôt toi qui vit dans ton monde de bisounours en croyant qu'une fois que tu as fais tes jolis schémas tout est joué. La réflexion d'un vrai programmeur se trouve à tous les niveaux. C'est bien parce qu'on délègue l'architecture aux uns et "le reste" aux autres que ces derniers, n'ayant pas le choix sur l'architecture, doivent s'adapter comme ils peuvent et pisser le code générique qui devrait pouvoir marcher même s'ils ont pas forcément la maîtrise totale de l'architecture.

Enfin, faire de la conception avant le codage est évidemment une bonne chose, mais tu te plantes si tu penses que c'est ce que j'ai critiqué. Le fait est qu'on utilise aussi ces diagrammes pour faire de la génération de code, ce qui est certes un avantage à court terme mais pas à long terme si mal utilisé. En particulier, à partir d'une vision abstraite, on met en place une architecture qui pourra montrer des faiblesses une fois qu'on en arrivera au détail. Cela arrive notamment si on ne fait pas une conception d'ensemble (à tous les niveaux) mais uniquement les niveaux les plus haut et puis "allez c'est bon on génère le code et on voit ce que ça donne", ce qui est très tentant de faire quand on a des deadlines. On utilise alors la facilité de générer du code pour faire de multiples essais rapides et quand on est content du résultat on s'arrête, sans toujours avoir compris pourquoi celui là est mieux. C'est plus rapide, mais ça peut faire un code imbuvable (car les générateurs de code sont avant tout formel, pas humain, donc leur manière de coder est pas forcément intuitive et facile à reprendre) et être source d'un code pour le coup non maintenable car incompréhensible. Et dans ces conditions, on n'a pas d'autre choix que de pisser du code plutôt que de faire un truc optimisé, parce que de toute façon on ne maitrise pas assez la bête pour faire quelque chose qui marche mieux.

[LSMetag]

Faux. Dans la programmation, il n'y a pas que la raisonnement abstrait qui compte. Tout ce qui est optimisation en particulier ne concerne que peu l'architecture abstraite que tu as dans tes diagrammes, mais avant tout le système concret sur lequel tu l'applique. Par exemple, en Java tu utiliseras un HashSet ou LinkedHashSet ou TreeSet selon l'utilisation que tu feras de ta collection, détail qui n'a aucune raison d'être dans tes diagrammes, mais qui peut avoir un impact notable sur les performances. Et ça c'est pas un pisseur de code qui va le trouver tout seul. Tes diagrammes permettent d'avoir une idée plus ou moins générale, selon le niveau de détails dans lequel tu descend, mais arrivé à un niveau très détaillé le diagramme devient fastidieux à faire et pas assez expressif pour tenir compte des détails nécessaire, donc tu passes au code.

C'est plutôt toi qui vit dans ton monde de bisounours en croyant qu'une fois que tu as fais tes jolis schémas tout est joué. La réflexion d'un vrai programmeur se trouve à tous les niveaux. C'est bien parce qu'on délègue l'architecture aux uns et "le reste" aux autres que ces derniers, n'ayant pas le choix sur l'architecture, doivent s'adapter comme ils peuvent et pisser le code générique qui devrait pouvoir marcher même s'ils ont pas forcément la maîtrise totale de l'architecture.

Enfin, faire de la conception avant le codage est évidemment une bonne chose, mais tu te plantes si tu penses que c'est ce que j'ai critiqué. Le fait est qu'on utilise aussi ces diagrammes pour faire de la génération de code, ce qui est certes un avantage à court terme mais pas à long terme si mal utilisé. En particulier, à partir d'une vision abstraite, on met en place une architecture qui pourra montrer des faiblesses une fois qu'on en arrivera au détail. Cela arrive notamment si on ne fait pas une conception d'ensemble (à tous les niveaux) mais uniquement les niveaux les plus haut et puis "allez c'est bon on génère le code et on voit ce que ça donne", ce qui est très tentant de faire quand on a des deadlines. On utilise alors la facilité de générer du code pour faire de multiples essais rapides et quand on est content du résultat on s'arrête, sans toujours avoir compris pourquoi celui là est mieux. C'est plus rapide, mais ça peut faire un code imbuvable (car les générateurs de code sont avant tout formel, pas humain, donc leur manière de coder est pas forcément intuitive et facile à reprendre) et être source d'un code pour le coup non maintenable car incompréhensible. Et dans ces conditions, on n'a pas d'autre choix que de pisser du code plutôt que de faire un truc optimisé, parce que de toute façon on ne maitrise pas assez la bête pour faire quelque chose qui marche mieux.

Ok pour le dernier paragraphe. Je pensais que tu critiquais la phase de conception et ne jurais quelque part que par la technique et le code.
Pour moi être développeur, ce n'est pas être pisseur de code.
Les diagrammes/schémas permettent d'avoir une vision d'ensemble de l'application (notamment pour le nouveau venu) et de mettre en place un squelette assez fiable et reflétant la base métier, facilitant le travail d'équipe et de maintenance. Après, il faut que la phase de conception soit faite à fond d'abord, je suis d'accord.

Je suis aussi tout à fait d'accord que les compétences techniques pures sont tout aussi primordiales. Genre faire des StringBuilder et non des "+", choisir correctement ses structures de données, connaître les subtilités des langages pour des questions de performances, de stabilité,.... Techniquement également, il faut connaître son sujet (pas forcément le langage, mais les design patterns),...

Mais si on n'a pas ces 2 choses, le projet aura des problèmes. Et on les a trop rarement.

Des outils de génération, des frameworks, ce n'est pas forcément le mal. Ces outils ont été développés pendant des mois voire des années par des personnes en général plus expérimentées que nous, avec une communauté derrière. Donc quelque part, on part avec une probabilité de fiabilité meilleure. Mais il faut évidemment les compétences pour choisir un outil de qualité et adapté à notre besoin. Sinon, le créer. Ce sera bien plus productif que de devoir modifier toute l'appli de façon rébarbative à chaque micro changement de la base de données.

Ces outils sont là pour simplifier la vie, gagner en productivité, segmenter le code, et éviter des bugs. Mais ils ne remplace pas le boulot et la compétence du développeur.

Bref, en ce qui me concerne, je suis développeur mais je me sens comme un poisson dans l'eau quand je peux faire mes propres choix et structurer un projet, de A à Z, directement avec le demandeur.

Je ne suis pas forcément d'accord avec le fait que ce soit l'architecte qui conçoit et le développeur qui pisse le code. Même en première année d'IUT, on commence à faire de l'architecture. On est formés en partie pour ça, même s'il est clair qu'on n'a pas d'expérience professionnelle en la matière. Mais voila, en SSII, on considère le développeur comme un pisseur de code, dont on ne cherche pas à mettre en valeur et améliorer ses compétences en architecture...

Dans mon dernier job, le sois-disant architecte avait fait un truc ne correspondant pas aux besoins, avec des fautes grossières qui nous ont provoqués des anomalies bloquantes (sur une application critique ça fait tâche) difficiles à détecter (mauvaise gestion des transactions, chargements massifs rendant l'appli hyper longue à démarrer,...). Et c'est nous les petits pisseurs de code insignifiants qui avons rattrapé le bordel (le mec était plus là) et retapé un minimum l'architecture... (d'ailleurs l'un d'entre nous explosait déja n'importe quel prof d'Ecole d'Ingénieur à 14 ans, mais n'a que BAC+2 donc ne peut pas être vendu comme architecte...). On ne nous a pas fait confiance au début parce qu'on ne portait pas l'appellation "Architecte"...

[chiv]

C'est toujours la même chose, la compétence technique est complètement dévalorisée en france et la seule préoccupation est l'argent. Beaucoup trop de jeunes aujourd'hui ne réflechissent pas en se demandant "qu'est ce que j'aimerais faire dans la vie ?" mais en se demandant "qu'est ce que je dois faire pour gagner le plus d'argent possible le plus facilement possible ?" c'est complètement pervers. On produit des générations entières de gens qui ont pour objectif de porter un costume et une montre chère et de parler en se croyant important. Merci les écoles de commerce, ce fléau.
Le culte de l'argent est néfaste partout. Cette logique conduit à devenir une nation de traders. Ben oui si le seul but dans la vie est de gagner de l'argent, soyons tous traders ! En attendant on est surtout un pays de 40 millions de directeur marketing au chomage, sans industrie et sans créativité.
Encore la semaine dernière, j'entendais une réflexion qui me choque prodigieusement : "Qui voudrait être cuisinier ? Ca ne paye pas assez."
Ma philosophie me dit qu'une bonne raison de vouloir être cuisinier est d'aimer la cuisine et de trouver que c'est un beau métier, pas facile, qui nécessite un vrai savoir faire. Mais non, énormément de gens ne pensent qu'à la taille de la voiture qu'ils pourront s'acheter. C'est symptomatique de la disparition de toute valeur dans nos sociétés. Quand toutes les autres valeurs ont disparues, la seule valeur qui reste est l'argent.

Par contre, il est à noter que d'un point de vue purement égoïste, c'est tout benef pour nous. Comme l'écrasante majorité des jeunes veulent devenir chef de projet et s'orienter rapidement vers du management, il y a peu de développeurs expérimentés. En conséquence, dès que tu as 5 ans d'expérience et une vraie expertise technique, tu es un super senior développeur voir franchement un demi dieu que les entreprises s'arrachent et tu n'as pas ou peu de conccurents.
Moralité, ayez le bon goût de choisir la passion et la beauté de l'art plutôt que le costard cravate et la grosse voiture. Il est bien plus intéressant d'être un spécialiste technique de haut niveau que le chef de projet anonyme numéro 654890 parfaitement interchangeable avec n'importe quel autre. Tant pis pour le titre ronflant bidon sur la carte de visite !

[jeanjean6]

Je pense qu'il y a aussi une grosse ambiguïté avec le métier de Chef de Projet.

On le met à toute les sauces et tout le monde peut être Chef de Projet maintenant...

C'est un métier bien à part qui nécessite certes une bonne connaissance du technique mais un développeur n'est pas un CP ni l'inverse selon moi.

EDIT : Je dirais même que je vois des ingés dev passer CP après 3/4 ans ils ne connaissent rien au pilotage et toutes les subtilités qui y sont associées...

Et ce serais pareil pour moi si on me passais développeur confirmé du jour au lendemain !

J'ai fais un master gestion de projet IT avec un programme spécifique et chargé en pilotage pendant plus de 3 ans et quand je vois que beaucoup d'entreprises recrutent des CP débutant à bac+2 je trouve ça dommage..

Dans la tête des gens, j'ai aussi l'impression que le CP est hiérarchiquement "au dessus" des ingés dev.. Ce dont je ne suis pas d'accord. Actuellement je fais du pilotage de projet et il n'y a aucune différence hiérarchique entre les ingés dev et moi même. La vrai différence est simplement le métier. Je travail sur le pilotage car j'aime ça et ils dév car ils aiment ça, et ça fonctionne très bien....!

Sur ce, très bon article.

Cdlt,

[LSMetag]

Je pense qu'il y a aussi une grosse ambiguïté avec le métier de Chef de Projet.

On le met à toute les sauces et tout le monde peut être Chef de Projet maintenant...

C'est un métier bien à part qui nécessite certes une bonne connaissance du technique mais un développeur n'est pas un CP ni l'inverse selon moi.

EDIT : Je dirais même que je vois des ingés dev passer CP après 3/4 ans ils ne connaissent rien au pilotage et toutes les subtilités qui y sont associées...

Et ce serais pareil pour moi si on me passais développeur confirmé du jour au lendemain !

J'ai fais un master gestion de projet IT avec un programme spécifique et chargé en pilotage pendant plus de 3 ans et quand je vois que beaucoup d'entreprises recrutent des CP débutant à bac+2 je trouve ça dommage..

Dans la tête des gens, j'ai aussi l'impression que le CP est hiérarchiquement "au dessus" des ingés dev.. Ce dont je ne suis pas d'accord. Actuellement je fais du pilotage de projet et il n'y a aucune différence hiérarchique entre les ingés dev et moi même. La vrai différence est simplement le métier. Je travail sur le pilotage car j'aime ça et ils dév car ils aiment ça, et ça fonctionne très bien....!

Sur ce, très bon article.

Cdlt,

Et pourtant, dans toutes les boîtes où je suis passé, le CP est considéré comme supérieur à l'Ingénieur en Développement. Tu dois passer par ton CP pour absolument tout. C'est ton CP qui fait les rapports pour les uns et les autres à la direction, pour chaque action tu dois demander l'autorisation au CP, c'est le CP qui te dit quoi faire, quand, à qui, voire comment.
Et la paye n'est pas la même...

[Mat.M]

Voir on fait comme aux USA, pays adorateur de l'argent, on spécule et on escroque pour gagner de l'argent, jusqu'à provoquer une crise mondiale.

quel angélisme quelle naïveté !
Et en France il n' y a que des entreprises dont le but est d'être philantropique ?
En tout cas merci pour la réaction ça reflète bien la mentalité étriquée et médiocre française

[negstek]

quel angélisme quelle naïveté !
Et en France il n' y a que des entreprises dont le but est d'être philantropique ?
En tout cas merci pour la réaction ça reflète bien la mentalité étriquée et médiocre française

il ne faut pas tirer de généralités certes mais la plus grande place spéculative reste les us, les banques comme Goldman Sachs et les agence de notation dirige le monde et influe l'économie des pays. Il n'y a qu'a comparer les systèmes sociaux, médicaux et éducatifs français avec ceux des us pour voir que c'est le jour et la nuit. Nos deux cultures sont totalement différentes et le capitalisme se fait la vie belle aux us pendant que notre bon vieux socialisme (aux sens apolitique du terme) calenche tout doucement. Espérons qu'il ai la vie longue.

[sqwaly]

pendant que notre bon vieux socialisme (aux sens apolitique du terme) calenche tout doucement

la faute à la droite moderne qui piétine toutes les bonnes valeurs gaulliste!