Sans te connaitre, j'ai l'impression à lire ta prose que tu rentres dans la catégorie des codeurs frustrés de ne pas recevoir la considération qu'ils estiment leur être due.
Personnellement, je considère que algorithmie et programmation sont deux activités différentes. Elles peuvent être réalisées par la même personne sur un certain nombre de projets ou sur des éléments déterminés, mais cela reste des activités distinctes. D'ailleurs, j'ajouterai volontier dans le lot une troisième activité tout aussi importante que les deux autres, et qui consiste à faire la transcription du besoin entre les utilisateurs, pas spécialement au courant de ce qui est possible d'un coté ("Ah bon ? On peut automatiser le traitement de mon document Excel ?") et les informaticiens pur et dur à l'autre ("Y'en a encore qui ne connaissent pas les macros dans Excel ?").
Et pourtant cette distinction n'est pas nécessairement dégradante : faire une implémentation propre, performante et prenant en compte les spécificités de l'environnement d'exécution le cas échéant est un vrai travail à part entière et respectable en tant que tel.
Malheureusement, je vois trop souvant dans mon boulot (bioinfo) des codes dont algo et implémentation ont été fait par la ou les mêmes personnes, et on obtient souvant des choses sous-optimales dans au moins une des deux catégories.
Alors c'est vrai que ce n'est pas toujours important, surtout lorsque l'on parle d'applications pour le poste de travail pour laquelle passer de 5% à 10% d'utilisation CPU ne va pas changer la face du monde, mais dans le cas d'application de calcul ou d'applications critiques, ce n'est pas tout à fait la même chose.
Pour reprendre ton exemple sur les jeux vidéos, je ne pense pas que les hard gamer soient les meilleurs programmeurs sur PS3 (et inversement), mais ils peuvent être de très bons concepteurs de jeux en terme de gameplay, de création des univers....
Enfin, concernant le métier d'ingénieur, je pense que sa fonction est plus souvant dans la gestion de projet que dans le management qui en est un des éléments mais pas le seul, loin de là.
Et encore. Je pense que dans bien des cas, son boulot consiste en mettre ensemble des éléments prééxistants et trouver la "colle"qui permettra de faire de l'ensemble des pièces un tout cohérent et qui correspond au besoin (et aux contraintes).
Pour reprendre ton exemple de l'avion, le but n'est pas de savoir dessiner un boulon, mais de savoir quel boulon il faut mettre à quel endroit : en gros, un travail digne d'un Meccano géan. Il y a par exemple eu des études assez poussées lors de la conception de l'A380 pour en faciliter la maintenance (par exemple, mettre un boulon un peu plus gros que nécessaire à tel endroit parce que cela permet de diminnuer le nombre d'outils nécessaires). Ce n'est pas du calcul mathématique et pourtant c'est tout de même de l'ingénieurie.
Quand à la phrase de Marcel Dassault, je la comprends comme le fait que concevoir un avion qui vol, c'est bien, mais si on veut en faire voler beaucoup (et donc bien les vendre), la technique seule ne suffit pas.
Après, vouloir limiter le travail de l'ingénieur technique au fait de pouvoir pondre du code, c'est soit être frustré, soit vouloir le remplacer à terme par des BTS sous peu ;-)
[^] # Re: Informaticien ?
Posté par sobek . En réponse au journal Le chercheur, l'ingénieur et l'informaticien. Évalué à 3.
Personnellement, je considère que algorithmie et programmation sont deux activités différentes. Elles peuvent être réalisées par la même personne sur un certain nombre de projets ou sur des éléments déterminés, mais cela reste des activités distinctes. D'ailleurs, j'ajouterai volontier dans le lot une troisième activité tout aussi importante que les deux autres, et qui consiste à faire la transcription du besoin entre les utilisateurs, pas spécialement au courant de ce qui est possible d'un coté ("Ah bon ? On peut automatiser le traitement de mon document Excel ?") et les informaticiens pur et dur à l'autre ("Y'en a encore qui ne connaissent pas les macros dans Excel ?").
Et pourtant cette distinction n'est pas nécessairement dégradante : faire une implémentation propre, performante et prenant en compte les spécificités de l'environnement d'exécution le cas échéant est un vrai travail à part entière et respectable en tant que tel.
Malheureusement, je vois trop souvant dans mon boulot (bioinfo) des codes dont algo et implémentation ont été fait par la ou les mêmes personnes, et on obtient souvant des choses sous-optimales dans au moins une des deux catégories.
Alors c'est vrai que ce n'est pas toujours important, surtout lorsque l'on parle d'applications pour le poste de travail pour laquelle passer de 5% à 10% d'utilisation CPU ne va pas changer la face du monde, mais dans le cas d'application de calcul ou d'applications critiques, ce n'est pas tout à fait la même chose.
Pour reprendre ton exemple sur les jeux vidéos, je ne pense pas que les hard gamer soient les meilleurs programmeurs sur PS3 (et inversement), mais ils peuvent être de très bons concepteurs de jeux en terme de gameplay, de création des univers....
Enfin, concernant le métier d'ingénieur, je pense que sa fonction est plus souvant dans la gestion de projet que dans le management qui en est un des éléments mais pas le seul, loin de là.
Et encore. Je pense que dans bien des cas, son boulot consiste en mettre ensemble des éléments prééxistants et trouver la "colle"qui permettra de faire de l'ensemble des pièces un tout cohérent et qui correspond au besoin (et aux contraintes).
Pour reprendre ton exemple de l'avion, le but n'est pas de savoir dessiner un boulon, mais de savoir quel boulon il faut mettre à quel endroit : en gros, un travail digne d'un Meccano géan. Il y a par exemple eu des études assez poussées lors de la conception de l'A380 pour en faciliter la maintenance (par exemple, mettre un boulon un peu plus gros que nécessaire à tel endroit parce que cela permet de diminnuer le nombre d'outils nécessaires). Ce n'est pas du calcul mathématique et pourtant c'est tout de même de l'ingénieurie.
Quand à la phrase de Marcel Dassault, je la comprends comme le fait que concevoir un avion qui vol, c'est bien, mais si on veut en faire voler beaucoup (et donc bien les vendre), la technique seule ne suffit pas.
Après, vouloir limiter le travail de l'ingénieur technique au fait de pouvoir pondre du code, c'est soit être frustré, soit vouloir le remplacer à terme par des BTS sous peu ;-)