Discussion :

[filandre]

Pour moi : c'est provocant... surtout pour les jardiniers

[Crazyfaboo]

Qui sera le premier à oser marquer "jardinier-informaticien" sur son CV ?

[ctxnop]

Voilà une comparaison qui ne manque pas de pertinence et qui plaira aux développeurs sachant prendre du recul et se remettre en question.

Il y a effectivement une part de provocation dans ce texte, mais elle n’aiguillonnera que ceux qui méprisent les jardiniers, et fera tout au plus sourire les autres.

Sauf que jusqu'ici, les réaction "hostiles" a la comparaison sont plutot contre la comparaison avec les ingénieurs qui construisent des ponts et des gratte-ciels.
Absolument pas contre la comparaison avec les jardiniers.
Je crois que personne n'a nié le fait que les développeurs travaillent avec beaucoup de facteurs non prévisibles, ont une part importante de créativité, etc...

[Bruyneel]

Pour ma part, étant ingénieur de formation, je trouve cette comparaison assez réaliste. Mais comme plusieurs intervenants l'ont fait remarqué, il y a aussi de mauvais ingénieurs qui ont comme tout le monde le droit de se tromper. Mais pour moi, il y a plusieurs considérations qui différencient les ingénieurs et les "informaticiens".
- Un ingénieur, on lui apprend avant tout à apprendre et à utiliser autrement , à recombiner ce qu'il connait. Beaucoup de développeurs se contentent d'appliquer des recettes mises au point par d'autres. Penser qu'un ingénieur applique bêtement des formules, c'est ignorer ce dont est fait ce métier.
- Comme il a été dit, pondre des lignes de codes est à la portée de bien des gens. Concevoir une application fonctionnelle et dans les temps nécessite du talent.
- Choisir le métier d'ingénieur est généralement une question de vocation, tandis que bien des gens atterrissent dans le monde de l'informatique parce que là il y a du travail et que trop de gens pensent que ce métier est facile.
- Par contre, penser que le jardinier évolue toujours dans un environnement changeant, et pas l'informaticien, c'est probablement mettre sur un pied destal les jardiniers en ignorant la folle évolution des technologies de l'informatique.

A méditer par beaucoup en tous les cas

[Donafriou]

http://t0.gstatic.com/images?q=tbn:A...hZPlZX_vIwTehQ

[el_slapper]

Ca c'est un argument un peu facile. Bien sur, qu'on parle de gens "normaux". Si on devait en plus comparer les incompétents!

Je parle de ce que je vois. Et il y a des incompétents partout, donc il faut les prendre en compte, je crois.

Mais en fait, si je comprends ce que tu dis, c'est que finalement les formations informatiques sont inutiles?

Il y a un certain tri qui est fait quand même, et ce qui est appris n'est plus à apprendre. Donc non ça n'est pas inutile. Mais ça n'est pas obligatoire non plus, ni une garantie de qualité. C'est un bonus appréciable.

Je réagissais à un message qui sous-entendait que seuls étaient habilités à programmer les gens qui avaient fait leurs études là-dessus. C'était faux au début(il n'y avait pas de formation de programmeurs, et pourtant il y en avait déjà quelques fameux, genre Hopper ou Knuth), et c'est toujours faux. Je vois des petits jeunes qui sortent d'école d'info, les meilleurs ne sont pas forcément ceux qui sortent des meilleures écoles. Et on croise encore quelques autodidactes(même si ça devient très rare), qui ne sont pas tous mauvais, au contraire.

[Yanos]

je parles pour l’Amérique
un développeur n'a pas nécessairement une formation d'ingénieur

tu peux très bien faire une formation universitaire de 3 ans en informatique et ne pas être ingénieur.....

tu as le choix en fait en ingénieur en génie informatique, ingénieur en génie logiciel ou bien l'équivalent sans être ingénieur.... en gros tu auras pas de cours de physique, chimie, gestion personnel....

même si j'ai une formation en génie logiciel, je vois pas cette discipline comme faisait partie réellement de l'ingénierie

c'est trop jeune, c'est trop imprécis, la réussite des projets est vraiment trop base

En fait j'allais mettre ce commentaire

Développeur ne veut pas dire Ingénieur
Pour se dire développeur il faut maitriser au moins un langage de programmation, pour être ingénieur il faut le diplôme qui va avec.

Donc l'ingenieur serait plutôt l'architecte en bâtiment et le développeur l'ouvrier. Sans architecte et maitre d'oeuvre votre gratte-ciel n'ira pas gratter grand chose.

Bien entendu construire un gratte-ciel semble plus impressionnant que de sortir un nouvel OS. Pas le même coût non plus d'ailleurs...

[shenron666]

j'aurai plutôt comparé le métier de développeur avec le métier de musicien / compositeur
mais pas à un jardinier qui plante, plante, plante...

[tigunn]

Oh l'insulte aux jardiniers !

Alors, pour ne pas paraphraser (j'espère car je n'ai pas tout lu), sa métaphore est malheureuse.
Selon moi, la différence entre développeur et ingénieur vient principalement du niveau d'étude et de l'expérience.
Ils ne travaillent pas non plus au même niveau dans le projet: l'ingénieur, plus sur le prospect, l'analyse et la conception; le développeur, lui, s'occupe de coder et, d'après mon expérience, de contrôler l'analyse, chiffrage, cahier des charges (enfin, tout le pendant technique du projet). Donc un développeur peut arriver au statut d'ingénieur (ce qui est mon cas ).
Pour en revenir au jardinier, l'image est mal choisit et ouvrier aurait été plus juste; puisque je pense qu'il voulait dire que les ingé concoivent, alors que les developpeurs construisent, créent. Mais c'est très réducteur.
Enfin, je retourne cultiver mon jardin.

[F6LYON]

Bonjour,

Vérité en deçà des Pyrénées, erreur au-delà !

Les mêmes mots en Australie et ici ne décrivent pas la même réalité. L'ingénierie Anglo-Saxonne est complètement différente de la nôtre. Ici c'est l'entreprise qui doit faire les calculs et les assumer, là bas l'entreprise est un simple exécutant, et fait ce que l'ingénieur a planifié et rien d'autre.
De la compétence des jardiniers australiens, je n'en sait rien. Chris ne semble pas en dire que du bien.
En d'autres lieux, voyez ce jardin" zen" japonais et la centrale de Fucujima, je suis bien aise d'être développeur même amateur!

Cordialement

[OMNY 2.0]

Le developpement logiciel est très jeune comme science, par contre le batiment date de plusieurs millenaires ( avant mm les pyramides d'egypte).
C'est difficil pour un developeur de se perfectionner dans un dommaine qui change tres vite, d'abord on a plusieurs language s de programmations a apprendre pour faire une seule chose ( pour un simple site web il faut en connaitre 3 au minimum: HTML/CSS JAVASCRIPT/AJAX PHP/MYSQL ou JAVA/JSP,)et les languages de programmation évoluent aussi vite java 1.0 java1.1 2.3 java5.1 et ++. Le temps de maitriser une achitecture, gérer les bugs, qu'une autre dite plus performante nait. Pourtant la formule de pythagore reste inchangée.
Comment voulons nous avoir de bon developpeurs si les outils du génie logiciel que sont les languages de programmations sont aussi instables ?:

[Bluedeep]

.
C'est difficil pour un developeur de se perfectionner dans un dommaine qui change tres vite, d'abord on a plusieurs language s de programmations a apprendre pour faire une seule chose ( pour un simple site web il faut en connaitre 3 au minimum: HTML/CSS JAVASCRIPT/AJAX PHP/MYSQL ou JAVA/JSP,)

C'est pas pour pinailler (enfin, si, un peu quand même ) mais HTML n'est pas un langage de programmation (essayer de coder en HTML l'algo pour calculer 1 + 1 , pas possible ); quant à AJAX et MYSQL ce ne sont pas des langages du tout.

[benzoben]

C'est pas pour pinailler (enfin, si, un peu quand même ) mais HTML n'est pas un langage de programmation (essayer de coder en HTML l'algo pour calculer 1 + 1 , pas possible ); quant à AJAX et MYSQL ce ne sont pas des langages du tout.

J'allais le dire! De plus, la méthode de travail n'est pas une question de language. Si on prend UML, il n'y a pas de notion de language, tout juste un paradigme objet.
De plus, je ne suis pas d'accord avec l'argument comme quoi l'informatique étant jeune, il n'y a pas de méthodes et de processus. Depuis le début, les acteurs de l'informatique se sont penchés sur son industrialisation. Les tests unitaires n'ont pas été inventés avec Spring, ni les interfaces avec Java. Je pense que ce sont les formations qui manquent, l'informatique manquant de gens qualifiés.

[lod101]

...Concevoir une application fonctionnelle et dans les temps nécessite du talent.

J'aurais dit "...nécessite des compétences, de l'expérience,...".

Il y a un certain tri qui est fait quand même, et ce qui est appris n'est plus à apprendre. Donc non ça n'est pas inutile. Mais ça n'est pas obligatoire non plus, ni une garantie de qualité. C'est un bonus appréciable.

- Moi, y' a un paquet de trucs que j'ai appris lors de ma formation, que j'ai oublié et que j'ai redécouvert bien après.
- J'aime bien le mot "bonus", c'est quand même grâce à ça que la PLUPART des gens chope un boulot, non ?

Selon moi, la différence entre développeur et ingénieur vient principalement du niveau d'étude et de l'expérience.

Pour moi Développeur c'est un métier, Ingénieur c'est un titre. Donc on peut être Ingénieur Développeur

...Ils ne travaillent pas non plus au même niveau dans le projet: l'ingénieur, plus sur le prospect, l'analyse et la conception...

C'est marrant, j'suis développeur et c'est que je fais au quotidien entre autre(hormis peut être le "prospect", faut voir ce que tu entends derrière ce mot)

Une chose me semble quand même évidente, c'est que le métier de jardinier est vachement plus valorisant que celui de développeur. Quand tu réalise un jardin qui en jette tu dois ramasser plus de félicitations (tout le monde peut juger) que quand tu écris un soft "élégament" (et qui tourne bien sûr) et que seuls tes pairs peuvent juger

[hegros]

Si on prend UML, il n'y a pas de notion de language, tout juste un paradigme objet.

Beh si UML c'est bien un langage et on peut l'utiliser pour modéliser des processus réels qui n'ont rien à voir avec un quelconque paradigme

De plus, je ne suis pas d'accord avec l'argument comme quoi l'informatique étant jeune, il n'y a pas de méthodes et de processus.

Beh si l'informatique c'est jeune Ce qui n'est pas jeune et qui existe depuis plus de 1000 ans ce sont les algorithmes que l'on utilise en programmation, programmation qui représente près de 70% d'un cycle de développement.

Pour l'aspect orchestration du développement aussi on ne se base pas uniquement sur ce qui est jeune : gestion des équipes, planification ou documentation cela existe bien avant l'informatique.

[benzoben]

Beh si UML c'est bien un langage et on peut l'utiliser pour modéliser des processus réels qui n'ont rien à voir avec un quelconque paradigme

Quand je dis qu'il n'y a pas de notion de language, je veux dire qu'un modèle UML n'est pas propre à C++ ou Java. Il permet néanmoins de modéliser des objets.

Beh si l'informatique c'est jeune Ce qui n'est pas jeune et qui existe depuis plus de 1000 ans ce sont les algorithmes que l'on utilise en programmation, programmation qui représente près de 70% d'un cycle de développement.

Je n'ai pas dit que l'informatique n'était pas jeune mais que ce n'est pas parce qu'elle est jeune qu'elle ne doit pas avoir de méthode.

Pour l'aspect orchestration du développement aussi on ne se base pas uniquement sur ce qui est jeune : gestion des équipes, planification ou documentation cela existe bien avant l'informatique.

C'est justement mon propos.

[Dark_TeToN]

Moi personnellement je trouve cela tout simplement MA-GNI-FI-QUE !

Bien sûr, pour comprendre l'auteur je pense qu'il ne faut pas non plus se "rabaisser" au rang de jardinier (je préfère mettre des guillemets parce que les diplômes qu'ont les développeurs en entreprise sont plus valorisant que ceux des jardiniers mais bon ce n'est pas là-dessus que je souhaite polémiquer, même si je pense que c'est pour cette raison que beaucoup de gens, je pense, le prenne mal).

Mais en terme de comparaison c'est tout à fait vrai ! Même si le génie logiciel gagne toujours de plus en plus en maturité, on est loin du bâtiment !
Il suffit de faire des comparaisons avec les grands chantiers et les grands projet logiciels : combien ont été abandonnés dans chacun de ces cas ? Et surtout combien ont été abandonnés alors qu'il avaient été réalisés ? Un bâtiment, une fois construit, est toujours utilisé ! Et si cela existe, c'est probable, cela doit être rare de voir un bâtiment construit inauguré et inhabité pour toujours !

Quant aux multiples aléas, ils sont bel et bien là ! Voyons, il suffit que chacun de nous réfléchisse un instant : qui de nous n'a jamais passé des heures, voire des jours, à essayer de trouver d'où venait un problème qui au final ne venait pas de son code mais d'un élément extérieur qui pose problème parce qu'il y a tellement de choses qui se passent en fond qu'il est impossible de tout connaitre ! Certes, ce genre de chose n'arrive peut-être pas souvent mais cela arrive ! Ne serait-ce que dans l'utilisation d'un framework (personnellement en faisant du SWING, combien de fois j'ai eu des problèmes pour rafraichir certain composants).

Après il suffit de simplement faire abstraction des différences entre un jardinier et un développeur, ce sont certes deux métiers très différents ! Mais dans cette métaphore je les trouve malgré tout très similaire d'un point de vue un peu plus "éloigné".

[hegros]

Il permet néanmoins de modéliser des objets.

C'est encore du chipotage mais non il ne permet pas exclusivement de modéliser des objets car il n'y a aucun paradigme objet dans un processus de facturation

[SirMcDuff]

Je pense surtout que les ingénieurs arrivent bien souvent à leurs fins grace aux logiciels développés par de vulgaires développeurs.

L'exactitude atteinte par les ingénieurs de la construction vient surtout du fait que le problème à resoudre reste simple face aux problèmes resolus par certains logiciels. L'utilisateur d'un pont ne va pas demander une mise a jour si il change de voiture. De plus, on voit bien que la reussite n'est pas automatique dès le moment ou les variables deviennent trop nombreuses sans pour autant atteindre le nombre de variables traitées par un logiciel.

Sinon ca fait au moins parler du métier, d'autre analogies sont tout autant pertinentes, alors j'attends la suite...

[benzoben]

C'est encore du chipotage mais non il ne permet pas exclusivement de modéliser des objets car il n'y a aucun paradigme objet dans un processus de facturation

Je ne vois pas le rapport entre le paradigme objet et un processus de facturation.

Par ailleurs, si ce ne sont pas des objets dans UML, je ne vois pas ce que représentes les fameux carrés jaunes! Ensuite que ton implémentation n'utilise pas de language objet, c'est normal car UML n'est pas propre à un language.