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."
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."
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."
C'est un procès d"intention. Tu parles de choses que tu ne connais pas.
Le PMI ça sert à professionaliser la pratique des chefs de projets.
Y'a pas de waterfall dans le PMI. Le PMI ça sert pour tous les types de projets, c'est à dire toutes les activités qui possèdent une dose certaines d'inconnu et qui requièrent un processus d'élaboration progressive et je pèse mes mots.
Et il n'y a pas de méfiance à l'égard des intervenants des projets. Il n'y a pas de flicage ou quoi que ce soit. Bien au contraire, le PMI étudie les relations entre parties prenantes et prône le respect, le partage d'info et la communication entre les membres des équipes, le team building, envisager la juste rétribution des équipes.
Tu me parles de Toyota. Le PMI reprend les grands principes des processus de qualité à la japonaise, Kaisen, l'amélioration continue, etc... Il explique les outils à disposition des Pm: Roue de Deming, le diagramme d'ishiwara, etc...
Tu crois vraiment qu'un truc qui fliquerait les intervenants genererait ce niveau d'adoption mondiale?
Allez, c'est pas la peine que je continue... Ca sert à rien.
Au delà de la gestion de projet, coder occupe toujours une partie de mon temps et c'est pour moi toujours aussi gratifiant : il suffit que le code soit bien conçu et tourne bien pour mon bonheur. Je précise que les applications que nous devellopons ont un objectif plus scientifique ou technique qu'un aspect gestion;
Etant en fin de carrière, si je devais postuler pour un nouvel emploi, mes goûts me porteraient à accepter de réduire significativement mon salaire (jusqu'à -50%) pour être "simple" programmeur plutôt que chef de projet.
" Le croquemitaine ! Aaaaaah ! Où ça ? " ©Homer Simpson
Si, si "vous êtes meilleurs que les autres", ils y croient. En tous cas, les notres y croyaient. L'un d'entre eux a frôlé la crise cardiaque le jour ou il a assisté à un entretien d'embauche, quand il s'est aperçu que les élèves de son école n'étaient pas meilleurs que ceux des autres écoles(pas pires non plus, hein, c'était du très bon niveau partout - mais pas sans faiblesses). En plus, c'était une école publique, donc les frais de scolarité.....
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.
Je vais avoir l'air d'un vieux dinosaure... mais tant pis, j'avoue être toujours intéressé par le développement et le codage à presque 50 ans.
Évidemment, en plus de 2 décennies, tout à changé, ou presque , mais c'est aussi ce qui est motivant ; apprendre.
Je ne vais faire qu'une remarque de vieux , depuis quelques années je rencontre de plus en plus de jeunes développeurs, plein de morgue et pas encore sevrés, qui ne veulent plus prendre la peine de comprendre un existant ( toutes ces lignes de code écrites par le cerveau d'un has been, beurk ! ) mais tout réécrire.
Incompétence ou égo démesuré ?
Un seul dicton ( d'un directeur de projets ) : ' on ne touche pas à du code qui fonctionne '
"L'humanité se divise en trois catégories : ceux qui ne peuvent pas bouger, ceux qui peuvent bouger, et ceux qui bougent."
- Benjamin Franklin
De l'aide en Javascript , consultez la FAQ JS.
De l'aide sur le FrameWork JS DHTMLX : posez vos questions sur le forum des Bibliothèques & Frameworks JS.
je comprend le point de vue. Il est vrai que le besoin de réécriture n'est pas toujours impérieux mais cela arrive, l'accumulation de couches de modificaitons rend les programmes difficilement lisibles. Mais une réécriture a un coût important qui ne se limite pas à celui du codage, il faut tester, documenter, valider, encadrer ...
Ceci dit, je travaille depuis 2 ans en Cobol (mainframe) et le discours selon lequel il faut toujours tout réécrire n'a pas du tout le même impact qu'en micro-informatique, on est beaucoup mouins exhubérant, on va dire.
La maintenance n'a pas la cote, c'est pourtant l'essentiel du travail en
développement. Je dirai que c'est par la maintenance corrective qu'il faut commencer, à voir des conneries écrites par ses prédécesseurs, cela incite à coder correctement. enfin, je vois la chose comme ça. Je dois être un vieux dinosaure (pléonasme), pas grave, j'aime la paléontologie et les dinosaures.
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."
J'ai 25ans donc j'ai encore le temps de changer d'avis mais...
Je n'ai aucune volonté d'évoluer vers un poste de chef ou approchant.
Cela ne m'intéresse pas.
J'aime coder, par contre je n'aime pas pisser du code...
« Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
« Le watchdog aboie, les tests passent »
J'abonde dans le sens étudiant, je dis toujours qu'il y a 3 métiers où tu étudies toute ta vie : Médecin, Homme de loi et Développeur.
Par contre un architecte n'a pas forcément besoin de connaitre toutes les dernières technos, sdk et api en vogue. Ils doit à mon sens comprendre les problématiques du projet et mettre en œuvre une architecture qui y répond. Plusieurs patterns ou design répondent déjà à des nécessités d'architecture, il faut les connaitre et savoir quand les appliquer, la réside sa force à mon sens. Une api ne fera que simplifier certains points...
Effectivement, l'environnement système ne permet pas toujours de pouvoir réécrire sans une lourde charge, mais c'est très drôle de voir un 'petit jeune' arriver dans une équipe et dire qu'il vaut mieux refaire le modèle de données car mal conçu ou mutualiser telle ou telle fonction pour une meilleure maintenance... sans tenir compte des facteurs d'origine et des objectifs d'exploitation.
Je crois en effet que les développements ne sont plus 'nouveaux' mais des extensions des SI en production et que la connaissance commence par la compréhension de l'existant. Et puis chercher et corriger un bug dans une appli conçue par des gens qui ne sont plus en place, avec une doc minimaliste ; quel challenge et quel pied !
Totalement d'accord ! Le côté compréhension de code est très intéressant et nécessaire je pense pour progresser. En Mainframe typiquement je pense qu'avoir fait de la maintenance est indispensable pour développer correctement et comprendre/ intégrer les enchaînements (notamment dans les loooooongues chaînes BATCH).
Je suis à moitié d'accord avec ça. Oui on ne touche pas à un code qui marche dans une application d'entreprise ! Car le risque de créer des régressions (qui ne seront pas testées) n'est pas négligeable. Et les régressions, c'est très mal vu et surtout ça peut avoir des conséquences graves ! Et comprendre un existant est très important pour monter en compétence.
Par contre, je ne suis pas d'accord pour qu'on se la ferme quand on voit quelque chose de dégueulasse, qui risque d'entraîner des bugs, des problèmes de performances ou simplement une difficulté de maintenance.
Il faut savoir sonner des sirènes d'alarme auprès des chefs quand le problème n'est pas encore trop étendu. S'il ne s'agit pas de réécrire toute l'appli, ça peut se négocier.
Les jeunes qui arrivent sont enthousiastes et déchantent quand ils voient la gueule d'un code en entreprise...
Ce fut le cas pour moi et c'est vrai qu'au début j'étais comme ces jeunes qui disaient "ça c'est pourri il faudrait le refaire", mais je n'avais pas du tout le recul pour comprendre le fonctionnement en entreprise.
Le problème, c'est qu'une bonne partie des développeurs codent pour que ça marche (job alimentaire), peu importe comment ça marche, si ça va marcher dans l'avenir, si ça va être facile à maintenir, si ça va pouvoir s'interfacer avec une éventuelle appli que le demandera, si quand un bug se produira on pourra le débusquer,...
C'est pour ça que je préfère les startup qui démarrent sur des projets pas trop gros, malléables, et surtout en général sont passionnés et font des choix techniques intéressants.
Dans les plus grosses entreprises, t'as toute une machinerie assez rigide. Et c'est pas vraiment les développeurs qui conçoivent leur appli, mais plutôt des commerciaux.
T'as aussi un historique qui colle à la peau de l'entreprise et rend toute évolution difficile. Les applications ont souvent pas mal d'années.
J'ai 40 passé et je code toujours avec autant d'enthousiasme que lorsque j'avais 20 ans !
J'ai pourtant essayé de me faire à l'idée que les années passant je devais être chef de projet car c'était dans l'ordre des choses et ma direction m'a toujours poussé en ce sens et bien rien à faire dès que je peux je mets les mains dans le cambouis c'est viscéral, c'est ce que j'aime le plus et je n'envisage pas une seconde aller au taffe faire des trucs chiants donc...
Aujourd'hui je sais faire les deux, coder dans les règles de l'art, gérer une équipe projet, prodiguer des conseils en archi et faire de l'analyse fonctionnelle. D'ailleurs j'aime bien alterner mes missions pour toujours avoir du pure développement dans mon travail. Sinon je regarde toujours un peu d'un oeil médusé mes collègues architectes fonctionnel ou chef de projet si éloignés de la technique et qui pour certains savent à peine se servir d'Excel, se sont souvent ceux-là qui méprisent les développeurs (pendant ma carrière j'en ai entendu des vertes et des pas mûres) ...
après toutes ces années je sais une chose, c'est que chef de projet c'est d'abord gérer les problèmes et la merdes des autres (en plus de la sienne) car malheureusement j'ai vu le niveau des développeurs considérablement baisser en 10 ans, donc plus de bugs et de malfaçons grossières, des délais largement dépassés sont à déplorer dans les projets et qui doit aller au feu, faire des heures à n’en plus finir pour calmer le client mécontent et sa propre direction impatiente ? Non je n'envie pas les chefs de projet d'aujourd'hui, je préfère encore créer et me taper de la conception UML à réfléchir sur la meilleur manière de répondre à un pb donné, perdu dans mes abstractions, d’ailleurs je ne conçois pas la programmation comme un travail mais plutôt comme un loisir ;-)
Dans ce métier je regrette juste une chose c'est le salaire des développeurs qui s'est réduit au fil des ans et ce en raison de l'arrivée massive de jeunes diplômés sur le marché qui acceptent sans rechigner le premier job à 2000e net. Mais cela va changer dans les années à venir lorsque l'industrie informatique arrivera enfin à maturité.
2000€ net ? En tant que jeune diplômé, quand tu demandes 2000€ net, t'as l'impression de demander la lune !
Les recruteurs tirent les prix vers le bas. Certains acceptent malgré tout. Parmi ceux qui acceptent, t'en as des tellement mauvais qu'ils se font jeter au bout de 6 mois...
Pour le reste, je suis d'accord avec toi (sutout pour les architectes fonctionnel et chefs de projet qui ne savent pas se servir d'Excel et méprisent les développeurs).
"On en a vu poser les armes avant de se tirer une balle dans le pied..."
-- pydévelop
Derniers articles:
(SQL Server) Introduction à la gestion des droits
(UML) Souplesse et modularité grâce aux Design Patterns
(UML) Le Pattern Etat
Autres articles...
à force de le dire on va finir par le penser, et ce thread va y contribuer un peux plus, ça me désole.À tel point qu’en France, être encore développeur à plus de 30 ans est pratiquement synonyme d’échec
Quand je lis :J'avais fait un billet un peu sur ce sujet, alors pour moi un chef de projet ou encore pire, un Architecte, sont des personnes avec des connaissances approfondies de leur métier, avec beaucoup d’expérience. Comment peut ont penser devenir Architecte logiciel sans avoir codé ?Les réponses seront diversifiées entre les gros noms comme « Chef de projet, Architecte, etc. »
Un métier ingrats ? Non, C'est un métier passionnant, et de passionné. Je ne parle pas du code Cobol qu'on nous demande de faire évoluer pour prendre en compte la loi n° 17623, ou faire une DAO à la main.. Si vos journée consiste à ça, premièrement je ne sais pas si on peu vous appeler développeur (si vous transformez du pseudo-code en code sans trop réfléchir dans des programmes qui ont 10 ans), j’appellerai plutôt ça un traducteur ou un ouvier, puisque ça tout le monde saura le faire, étude ou pas, tout à déjà été pensé par d'autre équipe. Le développeur est capable lui de concevoir un programme de A à Z, de se former sur les technologies qu'il doit mettre en œuvre, de mettre en place des paternes de plus en plus évoluer au fil de ça carrière, comme un compagnon qui doit parcourir la France pour apprendre différentes techniques en 10 ans puis réaliser un chef d’œuvre, il faut bien quelques années à un développeur pour découvrir les langages qu'il aime, puis encore quelques années pour se perfectionner dans ces langages. Ce n'est pas un métier qui s’apprend dans les livres ou dans des vidéos, il faut le pratiquer quotidiennement, être curieux des techniques des autres, partager.. etc pour qui aime faire partie d'une communauté, c'est peut être la plus grande communauté qui existe dans un domaine, avec beaucoup de partage et de savoir faire, dans le monde entier.
Alors, mon point de vue se résume à ça : un développeur à 30 ans, il commence à savoir bien coder.
Est-ce que faire du CRUD est enrichissant ? Car quand on parle de pisseur de code, le CRUD représente une part assez importante, et pas la plus fun.... Pour peu qu'on ait un outil pour générer une partie du code à la main, il reste quoi ?
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.
Partager