On p etre developpeur mem a 50 ans kesk ca p fair
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
part
On p etre developpeur mem a 50 ans kesk ca p fair
Au sein d'une entreprise, la considération passe par le salaire. Evidemment que les développeurs devraient être bien mieux considérés (donc mieux payés).Envoyé par nirgal76
Ce genre de commerciaux ou chefs de projet qui garantissent aux clients une livraison expresse de leur demande, ça se retrouve aussi ailleurs qu'en informatique. Avant de (bien) tourner et de devenir (professionnellement) développeur, j'ai eu différents postes en industrie. Il est arrivé que des commerciaux survendent une production de cordons bleus... Le lundi suivant ils se sont retrouvés sur la chaîne de production, histoire qu'ils comprennent les capacités de production.
heuuuu, je suis le seul à mettre mes outils à jour tous les 1, 2 ans pour être au fait des technos, à me former constamment aux nouvelles technos, et il y en a un paquet ???
Je ne vois pas trop comment on peut être architecte/... sans se mettre à jour et pratiquer avec aisance (ce qui implique de coder souvent)
Quand je décris mon boulot je dis souvent que je suis un internel étudiant... alors oui des fois c'est usant mais c'est passionnant
Mais on ne doit pas vraiment travailler dans le même milieux ...
ps : 38 ans et 13 ans d'experience
Au fil des expériences en développement, j'ai rencontré différentes visions sur la différence analystes (souvent assimilés CP) et programmeurs. Surtout en SSII. Il valait mieux ne pas rester programmeur trop longtemps, sinon c'est qu'on était pas capable d'évoluer. Il y a aussi le besoin des SSII de vendre des prestations, mais bon, je n'ai pas envie de les défendre pour autant.
Maintenant, j'ai un poste chez un utilisateur final, et je suis développeur à tous les niveaux : analyste, concepteur, programmeur, sur toutes les couches : BDD, Appli, Web, et j'apprends tous les jours à tous ces niveaux, et d'autres (architecture de plus en plus complexe, intégration à d'autres applis, ...).
Quant aux usines à code, style MDA, auraient-elles fait un flop ? Ceux qui les ont promues ont juste oublié que le développement logiciel est une activité créative, que l'on peut en partie automatiser, mais juste à la marge (structure de classes par exemple).
Ce qui fait l'intérêt de ce boulot, c'est justement tout cela : apprendre et créer. La partie paperasse, je la laisse volontiers au chef de projet !
Je n'enlève rien à ce que tu dis, mais simplement, à ce stade c'est de la politique d'entreprise, plus du dev ou du management. C'est regrettable d'en arriver là, à devoir se couvrir—ce qui encore une fois, ne signifie pas qu'on puisse s'en passer dans le monde réel.
"c'est faux", je ne comprends même pas ce que ta réponse peut signifier. Tu dis donc que c'est bien, ce n'est pas regrettable, que l'on doive dépenser une fortune pour contrôler que les gens fassent leur boulot?
Quand tu bosse dans ton entreprise oui mais chez un client, l'info positive remonte rarement à ta boîte et si c'est le cas, t'en sauras rien
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.et si c'est le cas, t'en sauras rien
Problème Franco-Français ?!
Certainement...
Même au Québec ou je suis, je vois pas ça.
Un développeur senior peut-être bien mieux payé d'un chef de projet.
Pis un senior pourra toujours être le "chef" de quelq'un en prenant sous son aile des juniors.
Après, je pense qu'un passionné termine plutôt en tant que directeur technique, architecte ou lead developper.
Ou bien, il est à son compte
J'ai l'impression que tu prend ce fil de discussion comme une attaque personnelle.
Je ne pense pas que la plupart soit contre les chef de projet, les analystes, et les architectes, qu'ils les trouvent inutiles ou quoique ce soit du genre.
Il est juste dit qu'il soit dommageable de voir une carrière comme une pyramide où les échelons n'ont qu'un seul et unique échelons supérieur. Un développeur est condamné à devenir chef de projet s'il veut évoluer.
Tout comme tu disais plus haut qu'un chef de projet n'a pas à savoir développer, un développeur n'a pas à savoir comment gérer un projet (je caricature quand même un peu).
Ce qui est surtout regrettable avec cette vision de la carrière, c'est qu'on finis toujours a avoir des développeurs jeunes avec peu d'expérience, avec de grands risques sur les choix techniques et les implémentations réalisées dans les projets.
Investir dans le management de projet ? surement que c'est bien.
Et investir dans l'expérience de dizaines d'années de développement pour réaliser plus rapidement, et avec moins de risque de dysfonctionnement une solution informatique; est ce bien ?
J'ai beaucoup de respect pour toi, Caro999. Contrairement à la plupart des grands chefs que j'ai pu écouter, tu me semble, généralement, tenir un discours basé sur la réalité et non pas sur la pensée magique. Ne te sens pas visée(en tous cas pas par moi) quand on fait du chef-bashing.
MAIS
J'aimerais que nous nous mettions d'accord sur certains termes. En fait, essentiellement, sur le mot process. Pour moi, un process, c'est un petit manuel à suivre bêtement. Et c'est exactement ce qu'il ne faut pas faire. La maturité d'une entreprise logicielle(ou autre), c'est sa capacité à répondre rapidement au besoin du client(interne ou externe, on s'en fout, ici).
Au contraire, le système, c'est le pouvoir - et les responsabilités - qu'on donne aux gens. A l'instar de Mary Poppendieck, mon expérience me pousse à penser qu'un système qui considère les process comme secondaires, et donne la priorité aux gens sur le terrain pour prendre les décisions, est le plus efficace.
Ce que j'aimerais savoir, c'est si pour toi le PBO(que je ne connais pas), c'est juste un système dans lequel les gens peuvent bosser et grandir, ou si c'est un carcan de process qui nous force à suivre un petit manuel forcément subotpimal(et surtout qu'on a pas le droit d'améliorer) ?
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Quelqu'un qui a tout compris... En France, il vaut mieux être artiste, écrivain ou présentateur télé, trader, ça en jette... mais c'est pas avec eux que la société avance, ils ne travaillent que pour eux. C'est culturel, il est vrai que le monde entier admire notre exception culturelle...
Le problème des grandes écoles en France, on enseigne des choses comme :
- la forme prévaut sur le fond.
- tu seras chef parce que tu es inscrit dans notre école et qu'on est les meilleurs... en fait, il faut bien justifier le prix exorbitants des inscriptions dans les grandes écoles. Après le lobbying de celles-ci fait le reste pour les + grandes.
M E N S . A G I T A T . M O L E M
Debian 64bit, Lazarus + FPC -> n'oubliez pas de consulter les FAQ Delphi et Pascal ainsi que les cours et tutoriels Delphi et Pascal
"La théorie, c'est quand on sait tout, mais que rien ne marche. La pratique, c'est quand tout marche, mais qu'on ne sait pas pourquoi. En informatique, la théorie et la pratique sont réunies: rien ne marche et on ne sait pas pourquoi!".
Mais Emmanuel Kant disait aussi : "La théorie sans la pratique est inutile, la pratique sans la théorie est aveugle."
pour faire rigoler tout le monde
http://www.ifrap.org/ENA-petite-hist...meur,1021.html c'est sur les énarques, mettre chef ça va aussi, vous aurez une idée du fonctionnement de l'informatique à la Française... Ce n'est pas vrai dans toutes les boîtes mais tellement fréquent.
M E N S . A G I T A T . M O L E M
Debian 64bit, Lazarus + FPC -> n'oubliez pas de consulter les FAQ Delphi et Pascal ainsi que les cours et tutoriels Delphi et Pascal
"La théorie, c'est quand on sait tout, mais que rien ne marche. La pratique, c'est quand tout marche, mais qu'on ne sait pas pourquoi. En informatique, la théorie et la pratique sont réunies: rien ne marche et on ne sait pas pourquoi!".
Mais Emmanuel Kant disait aussi : "La théorie sans la pratique est inutile, la pratique sans la théorie est aveugle."
Caro999
Je pense que personne ici n'attaque en quoi que ce soit les chefs de projets (exceptés les pourris. J'ai en effet eu un chef de projet qui ne connaissait pas le projet car il passait ses journées sur de la paperasse (des documents Excel) pour tout justifier.
Pour moi, le développeur est tout aussi important que le chef de projet. Le développeur connaît le projet en profondeur, toutes les problématiques liées à chaque demande, est le mieux placé pour donner des délais ou proposer les meilleures solutions ou des améliorations. Le chef de projet maîtrise le fonctionnel et les cahiers des charges, est là pour manager l'équipe (qui fait quoi), faire la passerelle entre le développeur et le client, donner les lignes directrices et récupérer des feedbacks autant côté client que développeurs. Le dialogue est indispensable.
C'est une aberration de dire que le développeur, c'est le bas de l'échelle et que Chef de Projet ou Expert, c'est une évolution de carrière. Ce sont des jobs différents, complémentaires, que l'on placerait au même niveau.
Et donc, un développeur passionné veut le rester parce que créer, résoudre des problématiques du mieux possible avec les moyens techniques dont il dispose, c'est ça qui l'intéresse.
Notre travail n'est simplement pas connu dans les sommets de la hiérarchie. On nous considère comme des ouvriers pisseurs de code (il y en a pas mal c'est vrai), tout en bas de l'échelle, et donc on délocalise les développements (avec des résultats dégueulasses). Il y a peu de reconnaissance en effet.
Mais on oublie qu'il y a des vrais savoir faire, des gens que l'on pourrait qualifier de micro-architectes, prenant en compte d'autres problématiques que simplement coder un truc qui marche en suivant bêtement une spec. Et ces personnes là sont primordiales pour la réussite d'un projet, qu'elles aient 20 ou 55 ans. C'est elles qui anticipent les problèmes, structurent de telle sorte que ça soit fiable, performant, maintenable. Par contre, c'est aussi elles qui râlent quand on leur demande de faire quelque chose de telle façon alors que ça pourrait être mieux fait ou de ne pas corriger tel bug (haaaa l'argent...), et le chef de projet a également pour rôle d'établir des dialogues et calmer le jeu dans ces cas là.
En ce qui me concerne, je suis aux anges quand j'ai un projet à mener de bout en bout. Recueil des besoins, cahier des charges, spécifications techniques et fonctionnelles, développement, tests et livraison.
Bref, l'évolution de carrière pour un informaticien en France relève de l'aberraton.
Tout à fait, il est à remarquer que si le développeur doit maîtriser la technique (normal) et une partie du métier de ses utilisateurs, l'inverse n'est pas vrai, alors pourquoi le développeur n'aurait-il pas droit à un petit plus ?
Le métier de développeur a ses difficultés propres, notamment il faut une certaine agilité intellectuelle et beaucoup de ténacité voire du mordant ou de l'abnégation.
Delphiste à l'origine, je suis réduit à faire du cobol actuellement, ça m'ennuie plus qu'autre chose mais je m'efforce de faire au mieux, selon les SSII qui ne comprennent pas ce qu'elles vendent, un développeur qui comprend la POO en Delphi est trop "con" (c'est pas dit comme ça mais c'est tout comme) pour passer à Dot.Net par exemple.
Autre remarque: je ne comprends toujours pas pourquoi on réduit les développeurs à utiliser des outils aussi mutilant intellectuellement parlant (E. W. Dijkstra en avait une bonne à ce sujet).
M E N S . A G I T A T . M O L E M
Debian 64bit, Lazarus + FPC -> n'oubliez pas de consulter les FAQ Delphi et Pascal ainsi que les cours et tutoriels Delphi et Pascal
"La théorie, c'est quand on sait tout, mais que rien ne marche. La pratique, c'est quand tout marche, mais qu'on ne sait pas pourquoi. En informatique, la théorie et la pratique sont réunies: rien ne marche et on ne sait pas pourquoi!".
Mais Emmanuel Kant disait aussi : "La théorie sans la pratique est inutile, la pratique sans la théorie est aveugle."
Ca, c'est tout à fait discutable, la documentation est utile mais en quantité raisonnable. Si le projet part en live, peut-être à cause de la doc, et ce n'est pas en en rajoutant qu'on le sauve. Cela me fait penser aux saignées dans les siècles passés qui faisaient crever le patient. Assez souvent, la doc ne sert qu'à rassurer la hiérarchie et à noyer le poisson. Si on passe 90% du temps à pondre des docs, la production du code dans les 10% restants va en prendre un coup.
En outre, quand on se retrouve face à des mégas de documentation, c'est franchement dissuasif pour un nouveau venu surtout en phase de maintenance corrective où l'ion gère trop souvent dans l'urgence la négligence, voire l'incompétence, dans les développements initiaux.
Quand on demande aux développeurs de plus pratiquer Word Excel et autres PowerPoint, il ne faut pas s'étonner que les développeurs ne connaissent pas leur outils de développement, ils n'ont plus le temps.
M E N S . A G I T A T . M O L E M
Debian 64bit, Lazarus + FPC -> n'oubliez pas de consulter les FAQ Delphi et Pascal ainsi que les cours et tutoriels Delphi et Pascal
"La théorie, c'est quand on sait tout, mais que rien ne marche. La pratique, c'est quand tout marche, mais qu'on ne sait pas pourquoi. En informatique, la théorie et la pratique sont réunies: rien ne marche et on ne sait pas pourquoi!".
Mais Emmanuel Kant disait aussi : "La théorie sans la pratique est inutile, la pratique sans la théorie est aveugle."
Ce qui est grave, c'est justement que les auditeurs auditent la doc et pas le code, au moins le code est concret, c'est pas avec la doc que le comptable va entrer ses écritures, c'est bien avec un programme.
M E N S . A G I T A T . M O L E M
Debian 64bit, Lazarus + FPC -> n'oubliez pas de consulter les FAQ Delphi et Pascal ainsi que les cours et tutoriels Delphi et Pascal
"La théorie, c'est quand on sait tout, mais que rien ne marche. La pratique, c'est quand tout marche, mais qu'on ne sait pas pourquoi. En informatique, la théorie et la pratique sont réunies: rien ne marche et on ne sait pas pourquoi!".
Mais Emmanuel Kant disait aussi : "La théorie sans la pratique est inutile, la pratique sans la théorie est aveugle."
Quand tu bosse dans ton entreprise oui mais chez un client, l'info positive remonte rarement à ta boîte et si c'est le cas, t'en sauras rien
Des fois qu'il te vienne l'envie d'une augmentation...
M E N S . A G I T A T . M O L E M
Debian 64bit, Lazarus + FPC -> n'oubliez pas de consulter les FAQ Delphi et Pascal ainsi que les cours et tutoriels Delphi et Pascal
"La théorie, c'est quand on sait tout, mais que rien ne marche. La pratique, c'est quand tout marche, mais qu'on ne sait pas pourquoi. En informatique, la théorie et la pratique sont réunies: rien ne marche et on ne sait pas pourquoi!".
Mais Emmanuel Kant disait aussi : "La théorie sans la pratique est inutile, la pratique sans la théorie est aveugle."
Je suis un peu vache avec les chefs, mais c'est vrai pour certains, j'en ai eu des excellents aussi, j'ai bien apprécié d'ailleurs.
M E N S . A G I T A T . M O L E M
Debian 64bit, Lazarus + FPC -> n'oubliez pas de consulter les FAQ Delphi et Pascal ainsi que les cours et tutoriels Delphi et Pascal
"La théorie, c'est quand on sait tout, mais que rien ne marche. La pratique, c'est quand tout marche, mais qu'on ne sait pas pourquoi. En informatique, la théorie et la pratique sont réunies: rien ne marche et on ne sait pas pourquoi!".
Mais Emmanuel Kant disait aussi : "La théorie sans la pratique est inutile, la pratique sans la théorie est aveugle."
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager