Discussion :

[stendhal666]

C'est merveilleux Dilbert!
Merci vraiment de m'avoir fait connaître!

[Saverok]

Je pense que si l'on est pas ouvert sur d'autres technologies, on s'enferme dans le langage dans lequel on bosse, et on est moins réceptif et imaginatif aux problèmes du client.

En quoi les choix technologiques sont un frein aux réflexions métier ?

Je dirai même que c'est l'inverse.
Si tu es à l'aise avec ta techno car tu la maîtrise à fond, ça te libère du temps pour t’intéresser aux problèmes de fond du métier car tu passes moins de temps sur des problématiques purement techniques (donc le client se contrefout royalement)

Le temps que tu passes à maîtriser une nouvelle techno et/ou à résoudre des problèmes techniques, c'est du temps que tu ne peux pas passer à réfléchir aux besoins et problématiques de tes utilisateurs.

[JCB001]

J'ai lu l'article de Bugayenko, c'est intéressant en particulier quand il relate que chaque bug trouvé est récompensé financièrement... c'est une excellente motivation.
Par contre quand il dit que le travail n'est pas une école... oui... mais il faut quand même se former... il ne s'agit pas de passer d'un extrême à l'autre.
En effet les technologies bougent, il est souvent dans l'intérêt d'un projet d'utiliser des nouveaux outils, on ne peut pas changer une équipe comme si les salariés étaient de simple outils comme des marteaux et des tournevis...
Il y a quelques années je suis arrivé sur un projet java ancien où aucun test unitaire n'existait, chaque MEP était truffée de bugs.
Alors on a mis en place JUNIT, je m'y suis frotté, j'ai appris les bases rapidement, cela a demandé plusieurs heures initialement puis d'autres heures pour avoir une architecture à peu près propre.
Cela a permis d'avoir un produit de meilleure qualité.
On aurait pu embaucher temporairement un développeur connaissant JUNIT mais cela aurait couté plus cher (rien que de sélectionner un candidat, faire passer des entretiens c'est des heures, lui fournir un nouveau PC, lui expliquer l'architecture du projet... ) pour un outil relativement simple et dans tous les cas il faut faire un transfert de connaissance avec les autres membres de l'équipe et donc les former....


Autre exemple : changement de version d'un langage, comment Bugayenko fait si le nouveau langage apporte des plus réels ? il change toute l'équipe avec toute sa connaissance acquise depuis des mois sur l'entreprise, le projets parce qu'il vaut mieux travailler sur java 8 que java 7 et que personne sur place ne connait java 8 ? c'est ridicule (attention je ne dis pas qu'on change de version à la légère non plus, encore moins au milieu d'un projet).

Un bon marteau n'importe quel magasin de bricolage en a en stock, un ingénieur avec les bonnes compétences c'est différent... et on ne remplace pas un ingénieur comme on remplace un marteau... un marteau n'a ni connaissance ni expérience, un développeur oui.

[Laurent 1973]

J'ai lu l'article de Bugayenko, c'est intéressant en particulier quand il relate que chaque bug trouvé est récompensé financièrement... c'est une excellente motivation.

Oula, très pervesif comme pratique.
Enfin, heureusement, aucun développeur ne va s’amuser à rajouter exprès des bug afin de se toucher une prime pour corriger sa "boulette"

En dehors de l'agissement "frauduleux", cela peux avoir une tendance faire changer dans le mauvais sens l’intérêt des développeur pour le produit.
"A non, je n'ai pas ajouter la nouvelle fonctionnalité que l'on devait livrer hier au nouveau client, hier j'ai corrigé 3 fautes d'orthographes dans le logiciel - au faite, la prime, c'est toujours 100€/bug? "

En général, de donner une prime à quelqu'un pour qu'il fasse correctement son travail, c'est la meilleur façon de casser une métrique qui pourrait être intéressante:

• Donnez une prime à un développeur pour avoir un ratio code/commentaire élevé dans vos sources: et vous retrouverez l’œuvre intégrale d'Alexandre Dumas (père et fils) dans git.
• Donnez une prime à un manager pour réduire les nombres de tickets "critiques": et les nouveaux bug se retrouvent déclasser.
• Donnez une prime à un commercial, et il vous vendra une fonctionnalité infaisable dans les délais.

Par contre, donner une prime sur quelque chose dont ce n'est pas le métier à un salarié, ça deviens intéressant: prime de vente pour un développeur qui trouve un nouveau client, prime de cooptation pour l'arriver d'un collaborateur, ...

Et sinon, ce que je pense qui marche le mieux: un intéressement direct au vente du produit sur lequel on travail.
Là, si l'équipe touche une prime sur les bonnes ventes, elle deviens très motivé à ce que le produit deviennent encore meilleur.

[Mystcreater]

Moi, je n'ai qu'une citation en mentionné qui résume toute ma pensée à ce sujet:

“You should plan on working 60 hours per week. The first 40 are for your employer. The remaining 20 are for you. During this remaining 20 hours you should be reading, practicing, learning, and otherwise enhancing your career.”
— Robert C. Martin

Ok, ça demande d'avoir un peu moins de vie car c'est pas tout le monde qui est prêt à s'investir tout au long de sa vie pour sa profession mais ceux qui le font devienne indéniablement respecté dans leur domaine par leur professionnalisme.

[exe2bin]

J'aimerai bien qu'on m'explique comment faire du développement web en ne maîtrisant qu'un seul langage ...

Entièrement d'accord !!
Comment de passer d'HTML, de JavaScript,des CSS,de PHP,XML etc ...

[GeoffreyOnRails]

En général, de donner une prime à quelqu'un pour qu'il fasse correctement son travail, c'est la meilleur façon de casser une métrique qui pourrait être intéressante:

• Donnez une prime à un développeur pour avoir un ratio code/commentaire élevé dans vos sources: et vous retrouverez l’œuvre intégrale d'Alexandre Dumas (père et fils) dans git.
• Donnez une prime à un manager pour réduire les nombres de tickets "critiques": et les nouveaux bug se retrouvent déclasser.
• Donnez une prime à un commercial, et il vous vendra une fonctionnalité infaisable dans les délais.

Par contre, donner une prime sur quelque chose dont ce n'est pas le métier à un salarié, ça deviens intéressant: prime de vente pour un développeur qui trouve un nouveau client, prime de cooptation pour l'arriver d'un collaborateur, ...

Et sinon, ce que je pense qui marche le mieux: un intéressement direct au vente du produit sur lequel on travail.
Là, si l'équipe touche une prime sur les bonnes ventes, elle deviens très motivé à ce que le produit deviennent encore meilleur.

Je suis assez en désaccord sur ce point, malgré le nombre de pouces verts. (pas taper )

Au contraire, je pense que lorsque c'est possible, la prime doit être au plus près du travail de la personne. Une prime sur le résultat de mon entreprise qui contient dix milles salariés, ça n'est pas ce qui me pousse dans mon quotidien. Sur des cycles de développement un peu long, l'impact de mon travail sur la vente de mon produit peut ne se faire sentir que dans quelques années, le temps qu'une release sorte, que les clients l'utilisent, qu'ils en parlent autour d'eux, qu'une décision d'achat soit prise suite à ça...

Le problème, selon moi, c'est plutôt l'absence de métrique objective permettant de juger de la qualité du travail d'un développeur à l'instant t (ou d'un commercial, d'un manager...). La qualité (ou plutôt la non-qualité du code), on la ressent souvent longtemps après le travail réalisé.. Du coup, soit on a une mesure objective (par exemple : ratio code/commentaire élevé) mais mauvaise ou très incomplète, et on se retrouve avec un effet pervers (les oeuvres de proust dans git), soit on est obligé de donner la prime en fonction du travail perçu par le manager, avec tous les problèmes que ça pose (se faire bien voir risquant de devenir le plus important que bien faire, et si le manager ne comprend rien à la technique ou n'a pas le temps de vérifier ce qui se passe, c'est la cata).

Ceci dit, les primes ne sont pas les seules sources de motivations, et ne sont pas les non plus seules à pouvoir produire ce genre d'effet délètère. Je me souviens d'une histoire (il me semble chez Microsoft il y a très longtemps, mais je voudrais pas dire de bêtises) où les devs étaient extremement préssés pour sortir de nouvelles fonctionnalités, mais avaient plus de temps pour réparer les bugs (priorité du management). Du coup, pour une fonction qui retourne la taille de police, ils mettaient une valeur pour passer le test (return 12; ), la qualité disait "on a trouvé un bug", et ils implémentaient tranquillement la fonctionnalité en "bug fix". Eviter la pression du management conduisait au même effet qu'aurait pu avoir une prime sur le temps mis pour implémenter une feature ou le nombre de bugs corrigés.



Pour revenir au sujet de l'article, il faut voir dans quel contexte est l'auteur : leurs "salariés" sont plutôt des freelance payés au ticket, et toute tâche se résume en la complétion de petits tickets et/ou la création de nouveaux tickets pour demander quelque chose. Aucune communication entre personnes travaillant sur le projet en dehors d'un commentaire sur un ticket. C'est du travail à la chaîne. Outre les inquiétudes sur les comportements que cela peut introduire (personne ne fera mieux que la qualité/performance/maintenabilité minimale vérifiée et passer les tests, sans même parler de malveillance/tricherie), leur hypothèse derrière ça est de considérer que les employés peuvent partir du jour au lendemain, et que tout investissement sur eux est perdu.

C'est assez différent d'une société qui considère ses employés comme des ressources sur lesquelles on peut investir, que ce soit à l'occasion d'un projet ou sur des formations, car on considère qu'elles vont rester un certain temps, et que du coup les gains de productivités créés pourront être rentabilisés.

Pour moi, cela peut se justifier quand on fait appel à des experts freelance au prix fort sur un délai court, mais pas pour la plupart des gens, ni en continu. Et encore, je trouverai bien souvent plus pertinent d'être payé un peu moins, et de considérer que 10 ou 20% du temps de travail servira à monter en compétences (trouver une nouvelle librairie pertinente, échanger à la machine à café avec l'expert d'à côté), que de séparer strictement apprentissage et réalisation.

Mais si ils trouvent des gens qui sont satisfaits de bosser dans ce contexte, très bien, en tout cas je trouve l'expérience intéressante... de l'extérieur

[Laurent 1973]

Je suis assez en désaccord sur ce point, malgré le nombre de pouces verts. (pas taper )

Pas de souci, c'est aussi le but de ce forum, confronté des opinions différents.

vous retrouverez l’œuvre intégrale d'Alexandre Dumas (père et fils) dans git.

les oeuvres de proust dans git

C'est vrai que là, on est en désaccord: tu es Proust, moi plutôt Alexandre Dumas

soit on est obligé de donner la prime en fonction du travail perçu par le manager, avec tous les problèmes que ça pose (se faire bien voir risquant de devenir le plus important que bien faire, et si le manager ne comprend rien à la technique ou n'a pas le temps de vérifier ce qui se passe, c'est la cata).

La valorisation financière, je le vois aussi passé par l'augmentation.
C'est en cela aussi que je n'aime pas distribué des primes sur tel ou tel point parfois difficile à mesurer (ou facile à corrompre).
Si tu apportes un réel plus à un projet, c'est que tu vaux plus mensuellement, pas seulement une fois.
Par contre, je suis aussi pour la carotte et le bâton: si tu n'es pas à la hauteur des attentes => zéro augmentation + projet placard voir la porte.

C'est sur que si seul le manager décide de récompenser un collaborateur, cela peux favoriser une politique du lèche-bottes.
Mais on travail le plus souvent en équipe, un manager peux aussi discuter avec les membres des équipes.
Par exemple, demandé à chacun de son équipe de désigner une personne avec qu'il aime travailler le plus et pourquoi (être sur du positif, évitons les règlement de compte en demandant la pire personne).

Après, être un manager d'équipe nécessite des vrais compétences en RH afin de bien évaluer ses collaborateurs.
Cela nécessite aussi de les rencontrer souvent et pas seulement 1 fois par an le jours de la rencontre annuelle obligatoire.

[landry161]

Chaque projet est différent, et croire qu'il suffit d'en maitriser un pour maitriser les autres me parait hautement illusoire.

Très illusoire

[yotta]

Bonjour à vous,

Pour commencer, je ne suis pas un professionnel dans le monde merveilleux de l'ingénierie informatique. Donc, je n'ai jamais travaillé autrement que "seul dans mon garage".
Pour autant, cela ne m'empêche pas d'avoir mon point de vue sur la chose, un point de vue différent, celui d'un amateur.
Bref, pour moi, il existe deux sortes de "programmeurs". Les programmeurs "productifs", et les programmeurs "chercheurs". J'entends par là l'industrie logicielle, et la recherche.
Il me semble évident qu'un programmeur qui œuvre dans la recherche, doit être spécialisé et s'investir à 100% dans la technologie étudiée.
En contre-partie, un programmeur productif doit lui être polyvalent. Plus il "parlera" de langues différentes, plus le nombre de personnes avec qui il pourra communiquer sera grand. Dans l'industrie logicielle, par définition, on se veut capable de concevoir des solutions pour tous les corps de métiers, et ces derniers les amènent donc naturellement à couvrir plusieurs technologies, donc, fatalement, plusieurs langages. De plus, la dimension économique définie des contraintes incontournables.
Et puis de toute façon, que je sache, il n'existe pas trente-six solutions, personnellement, je n'en connais que deux, la programmation orienté objet, et la programmation fonctionnelle. Si ces principes sont maîtrisés, alors le langage est "secondaire", ce n'est qu'une question de spécifications techniques que l'expérience du développeur "productif" représente, et un accès à la documentation de l'API. Ce qui n'empêche pas ce dernier de laisser ses loisirs investirent les autres langages...

[Laurent 1973]

Et puis de toute façon, que je sache, il n'existe pas trente-six solutions, personnellement, je n'en connais que deux, la programmation orienté objet, et la programmation fonctionnelle. Si ces principes sont maîtrisés, alors le langage est "secondaire", ce n'est qu'une question de spécifications techniques que l'expérience du développeur "productif" représente, et un accès à la documentation de l'API. Ce qui n'empêche pas ce dernier de laisser ses loisirs investirent les autres langages...

En faite, il y en a plus de deux, je dirais au moins trois principale en rajoutant la programmation déclarative (voir http://fr.wikipedia.org/wiki/Paradig...ogrammation%29)

Mais, en effet, a partir que l'on maîtrise un de ces paradigmes, on peux s'adapter pour passer d'un langage à un autre: "juste" une grammaire et un vocabulaire un peut différent et quelques spécificités.

[Saverok]

Mais, en effet, a partir que l'on maîtrise un de ces paradigmes, on peux s'adapter pour passer d'un langage à un autre: "juste" une grammaire et un vocabulaire un peut différent et quelques spécificités.

Pour les opérations de bases, je suis d'accord
Mais dès que l'on tombe dans des opérations plus ardues, la richesse API et Frameworks disponibles en fonction des langages va avoir un impact extrêmement fort sur la productivité
En effet, en théorie, on peut tout "faire à la main", donc quelque soit le langage, on va savoir le refaire mais en combien de temps ? avec quel niveau de complexité ? quelle maintenabilité ? quelle perf ? combien de ligne de code ? quel niveau de sécu ? quelle robustesse ? etc.

En info, la factorisation est un axe majeure (on ne réinvente pas la roue)
Du coup, lorsque l'on développe dans un langage, on ne se contente pas de la syntaxe, il y a tous les à côtés sur lesquels s'appuyer qu'il faut connaître et maîtriser et ça, ça demande beaucoup de temps

[yotta]

Bonjour Saverok,
Très interressant votre précision sur la factorisation. Pourriez-vous éclairer ma lanterne et m'indiquer un lien qui me permettrait d'en savoir plus sur ce principe que ne me parle pas le moins du monde ?

[Logan Mauzaize]

http://fr.wikipedia.org/wiki/Factori...nformatique%29

Cela consiste (comme pour une opération mathématique) à mettre des éléments en commun (a(b + c + d + e)) plutôt qu'éparpiller aux quatre vents (ab + ac + ad + ae)

[Saverok]

@Logan Mauzaize
Je pense que yotta faisait de l'ironie, enfin, je l'espère
Mais merci pour lui lol

[el_slapper]

Après, sur une factorisation excessive, il y a des gens qui sont opposés à l'idée de réutilisation massive, totale, et sans contrôle, de ce qui a été fait par d'autres. Avec quelques arguments intéressants. Je trouve qu'il va un peu trop loin dans son raisonnement, mais j'aime bien sa conclusion :

If it's a core business function -- do it yourself, no matter what.

. Le reste, on peut ramasser ce qui existe déjà.


Mettons que je veuille faire un envoi de mail. Si je fais un logiciel médical, l'envoi de mail, je prends le truc du framework sans me poser de questions. Si je fais un logiciel d'envoi de mail, en revanche, j'ai intérêt à faire mieux que le framework pour avoir une valeur ajoutée.

[yotta]

Bonjour à vous,
Bien vu Saverok, c'était éffectivement ironique
Je n'ai pour autant pas manqué de jeter un oeil sur le lien...
Quoi qu'il en soit, je crois que l'on peut dire qu'en dehors de spécificités bien précises, il est préférable de s'interresser à tous les langages plutôt que de se limiter à un seul car je penses que c'est la nature d'un projet qui définit le ou les langages appropriés, pas l'inverse.

[Saverok]

Quoi qu'il en soit, je crois que l'on peut dire qu'en dehors de spécificités bien précises, il est préférable de s'interresser à tous les langages plutôt que de se limiter à un seul car je penses que c'est la nature d'un projet qui définit le ou les langages appropriés, pas l'inverse.

C'est la théorie et la bonne pratique.
Dans les faits, on est obligé d'être pragmatique et de tenir compte de pas mal de contraintes :
• L’équipe disponible
• Le temps et le coût de la formation
• Le niveau de criticité de l’application
• Le planning => même pour un développeur expérimenté, quand on change de langage, il y a une baisse de productivité dans un premier temps avant de revenir à un bon rythme de croisière
• La gestion de la TMA => il n’y a pas que l’équipe projet dont il faut tenir compte. Une fois l’application en production, il faut en assurer l’exploitation et se sont d’autres équipes, le plus souvent
• La fragmentation technologique au sein de l’entreprise => lorsqu’il y a trop de techno différentes, on ne s’en sort plus
• La rentabilité des investissements => si l’entreprise a investi dans des serveurs et des licences Oracle, on ne pas s’amuser à faire du Postgres (sauf si tu as envie de te mettre ton DSI à dos)
• Pour les SSII et intégrateurs surtout : les certifications et partenariats commerciaux => si l’on est certifié « expert premium Magento », on ne va pas répondre à un appel d’offre en soutenant une solution Hybris…
• Etc
• Etc
• Etc

[Logan Mauzaize]

@Logan Mauzaize
Je pense que yotta faisait de l'ironie, enfin, je l'espère
Mais merci pour lui lol

Lol trop l'habitude des débutants/étrangers J'avoue être passé à côté !

[Tr0n33]

Bonjour à vous,

Pour commencer, je ne suis pas un professionnel dans le monde merveilleux de l'ingénierie informatique. Donc, je n'ai jamais travaillé autrement que "seul dans mon garage".
Pour autant, cela ne m'empêche pas d'avoir mon point de vue sur la chose, un point de vue différent, celui d'un amateur.
Bref, pour moi, il existe deux sortes de "programmeurs". Les programmeurs "productifs", et les programmeurs "chercheurs". J'entends par là l'industrie logicielle, et la recherche.
Il me semble évident qu'un programmeur qui œuvre dans la recherche, doit être spécialisé et s'investir à 100% dans la technologie étudiée.
En contre-partie, un programmeur productif doit lui être polyvalent. Plus il "parlera" de langues différentes, plus le nombre de personnes avec qui il pourra communiquer sera grand. Dans l'industrie logicielle, par définition, on se veut capable de concevoir des solutions pour tous les corps de métiers, et ces derniers les amènent donc naturellement à couvrir plusieurs technologies, donc, fatalement, plusieurs langages. De plus, la dimension économique définie des contraintes incontournables.
Et puis de toute façon, que je sache, il n'existe pas trente-six solutions, personnellement, je n'en connais que deux, la programmation orienté objet, et la programmation fonctionnelle. Si ces principes sont maîtrisés, alors le langage est "secondaire", ce n'est qu'une question de spécifications techniques que l'expérience du développeur "productif" représente, et un accès à la documentation de l'API. Ce qui n'empêche pas ce dernier de laisser ses loisirs investirent les autres langages.

Il existe en réalité, comme il a été énoncé, bien d'autres types de programmation (le langage orienté prototype aussi bien qu'on le classe souvent - selon moi par erreur - parmi la programmation orienté objet; tu as la programmation orienté aspect, réactive etc.). Oui c'est le niveau d'abstraction d'un développeur et sa connaissance des problématiques de l'entreprise qui font une part de son expérience et de son adaptabilité. L'adaptabilité permet au développeur de se vendre dans notre monde et il est donc nécessaire d'un point de vue du salarié, qu'ils en apprennent le plus possible. D'un côté société de service et optimisation des plus valus, les écono-commerciaux-managers (comme on les voit dans ces deux articles) ne pensent qu'en terme de gain pour l'entreprise ou un projet spécifique et non pour l'individu. Ce sont des visions étriquées je trouve, et surtout qui font fi des problématiques futurs. Tous les arguments ont déjà été évoqués ici : besoins techniques sur plusieurs langages dans un même projet, évolution des technologies, etc.

Pour rependre la fameuse analogie du plombier, il ne faut pas oublier que si un plombier ne sait pas refaire ses chiottes avec les matériaux qu'il a sur place, il est effectivement dans une impasse technique (il ne le sera pas vraiment car il... s'adaptera grâce à sa connaissance du métier). Le métier du développement nécessite justement de connaître les abstractions nécessaires à l'usage de tous les types de matériaux. Un développeur n'a pour moi pas "besoin" d'apprendre des tonnes de langages car il est censé (dans un monde merveilleux) s'adapter très rapidement à tous les langages. Rappelons que le langage est un outil de la programmation, pas une fin en soi. Certes il ne maîtrisera pas les subtilités mais il pourra les apprendre sur le projet. Perte de productivité ? Perte ponctuelle pour un gain temporel évident pour l'entreprise. Mieux vaut avoir un salarié qui s'est formé sur un petit projet pour le réutiliser par la suite qu'une sur-spécialisation.

Toujours dans l'analogie. Réparer une fuite, ou installer des chiottes, c'est faire un module particulier ou corriger un bug. Cela nécessite forcément un degré d'expertise sur un langage. Le développeur n'a donc pas le temps d'apprendre, et aucun client n'acceptera d'ailleurs ce fait. Certains semblent prétendre que oui, mais ce n'est pas le cas. Si l'on vous demande de corriger un Webservice SOAP qui fait appel à une transaction Cobol avec un framework spécifique, si vous ne connaissez pas le framework spécifique, vous mettrez des plombes, vous y arriverez et on ne vous reprendra jamais. Comme le plombier d'ailleurs. Par contre lors de la construction d'une maison, le plombier n'est jamais seul. Généralement ils travaillent à plusieurs, avec des apprentis, des expérimentés etc. Et croyez moi, sur un chantier beaucoup "apprennent" autre chose que leur spécialité. Les artisans ne sont pas si différents des développeurs. Ce n'est qu'une question d'appréciation selon moi. Nous dénigrons le plombier mais en réalité la tâche d'installation des chiottes, n'est pas la même que réparer une fuite et ne sera pas la même que construire les canalisations de tout un bâtiment. Pour le développeur c'est la même : corriger un bug sur un langage/serveur/environnement spécifique, ça n'est pas la tâche d'installer un produit éditeur et ça ne sera pas la tâche d'un grand projet de refonte d'un SI.

Je ne suis donc pas d'accord non plus avec ces deux articles. Apprendre de nouveaux langages sur un projet avec une légère perte de productivité initiale est un gain pour l'entreprise car elle divise très nettement le coût exorbitant (en France) d'une formation continue ou spécifique par la suite. Les gestionnaires ne voient que trop rarement ce gain car ils jouent sur des budgets à très courts termes et qui sont différents de ceux des formations. Bref, c'est un serpent qui se mord la queue et des pertes d'argent colossales à tous les niveaux. Ne pas apprendre plusieurs langages, ne pas les apprendre sur un projet, c'est comme être plombier et avoir une boîte à outils dans laquelle il manque des clous, des marteaux, des vis et des clés de 8, 9 et 10, des furets et des tuyaux. C'est aussi comme je l'évoquais au dessus, un problème de "sur-spécialisation". Ne connaître que le monde Java ne suffit pas à répondre à de très nombreuses problématiques de maintenance. Par exemple si je n'avais pas acquis quelques connaissances sur le Cobol et la gestion transactionnelle de vieux moteurs développés par IBM, si je n'avais pas appris quelques scripts en Python pour installer automatiquement un serveur Weblogic, si je ne savais pas faire un peu de ksh pour automatiser une installation de base de données sur Linux, si je ne connaissais pas un langage comme SQL, j'aurais de sacrés lacunes et je ne pourrais faire qu'un seul type de tâches. De mon point de vue, c'est la volonté de beaucoup de sur-spécialiser les individus pour leur faire des tâches dites industrielles (même dans la recherche). Moins vous réfléchissez, plus vous produisez. C'est un point de vue évidemment.