Un développeur devrait-il maitriser plusieurs langages de programmation ?
Pour un sénior, c'est une « une mauvaise idée »
Le 2015-04-07 23:43:12, par Amine Horseman, Expert éminent sénior
Dans un billet de blog publié sur Core Java Interviews Question, Sam Atkinson, blogueur et directeur de développement à HSBC nous explique son point de vue sur les développeurs polyvalents qui aiment essayer de nouveaux langages et pourquoi c’est « une mauvaise idée » selon lui.
En effet, Sam Atkinson affirme que les langages bien mûrs comme java sont suffisants pour faire le travail, et il n’est pas nécessaire pour un développeur maîtrisant ce langage d’apprendre de nouveaux : cela « va être un cauchemar de maintenance », même si « vous connaissez déjà le langage en question » prévient-il.
« Java est utilisé depuis longtemps et a un ensemble incroyable d'outils et de bibliothèques autour de lui » ajoute Atkinson en citant l’exemple d’IntelliJ. « Un outillage de ce type n’existe pas de façon mature dans les autres [nouveaux] langages [...] Il y a aussi le manque de documentation et de soutien en ligne ». Toutefois, ce n’est pas le fait de maîtriser plusieurs langages qui pose problème selon lui; bien au contraire, il affirme que ceci est « nécessaire » pour avoir un bon CV et que c’est « une excellente façon de changer sa manière de penser concernant le style de codage ». Cependant, ce qui lui pose problème c’est le fait que les développeurs profitent souvent des projets qu’ils réalisent pour apprendre ces nouveaux langages.
Pour illustrer ce dernier point, il cite un article de Yegor Bugayenko, co-fondateur et directeur de technologie à teamed.io, qui avait écrit dans son blog que « chaque projet de logiciel est un business, et nous, les développeurs, sommes ses ressources ». Par conséquent, si on utilise les projets pour apprendre : « ça sera du vol », et un bon gestionnaire de projets ne doit jamais accepter, car « ce n’est pas une école ».
Bugayenko nous explique ensuite que si on contacte un plombier pour installer un système de drainage dans notre maison, et que celui-ci nous dit qu’il n’a jamais travaillé sur une telle tâche, nous n’accepterons jamais de dépenser notre argent pour qu’il puisse se former. De la même façon, en tant que développeurs, « nous voulons apprendre, mais nous ne voulons pas dépenser notre propre argent pour ça. Nous ne voulons pas rester à la maison pendant quelques années pour apprendre toutes les technologies possibles avant d'entrer dans le marché du travail […] Nous voulons apprendre sur le tas ». Or, un programmeur qui ne possède pas les compétences adéquates est « une ressource non fiable » et « aucun projet ne prendrait une telle ressource depuis le début ».
Concernant Sam Atkinson, nous pouvons néanmoins discuter les gains apportés par l’utilisation de nouveaux langages par rapport aux coûts nécessaires à leur apprentissage, et rester toujours prêts à nous reconvertir dans ces langages si cela est plus avantageux.
Source : Article de Sam Atkinson, Article de Yegor Bugayenko
Pensez-vous qu’apprendre plusieurs langages est une mauvaise chose ?
Que pensez-vous de l’avis d’Atkinson et de Bugayenko ?
En effet, Sam Atkinson affirme que les langages bien mûrs comme java sont suffisants pour faire le travail, et il n’est pas nécessaire pour un développeur maîtrisant ce langage d’apprendre de nouveaux : cela « va être un cauchemar de maintenance », même si « vous connaissez déjà le langage en question » prévient-il.
« Java est utilisé depuis longtemps et a un ensemble incroyable d'outils et de bibliothèques autour de lui » ajoute Atkinson en citant l’exemple d’IntelliJ. « Un outillage de ce type n’existe pas de façon mature dans les autres [nouveaux] langages [...] Il y a aussi le manque de documentation et de soutien en ligne ». Toutefois, ce n’est pas le fait de maîtriser plusieurs langages qui pose problème selon lui; bien au contraire, il affirme que ceci est « nécessaire » pour avoir un bon CV et que c’est « une excellente façon de changer sa manière de penser concernant le style de codage ». Cependant, ce qui lui pose problème c’est le fait que les développeurs profitent souvent des projets qu’ils réalisent pour apprendre ces nouveaux langages.
Pour illustrer ce dernier point, il cite un article de Yegor Bugayenko, co-fondateur et directeur de technologie à teamed.io, qui avait écrit dans son blog que « chaque projet de logiciel est un business, et nous, les développeurs, sommes ses ressources ». Par conséquent, si on utilise les projets pour apprendre : « ça sera du vol », et un bon gestionnaire de projets ne doit jamais accepter, car « ce n’est pas une école ».
Bugayenko nous explique ensuite que si on contacte un plombier pour installer un système de drainage dans notre maison, et que celui-ci nous dit qu’il n’a jamais travaillé sur une telle tâche, nous n’accepterons jamais de dépenser notre argent pour qu’il puisse se former. De la même façon, en tant que développeurs, « nous voulons apprendre, mais nous ne voulons pas dépenser notre propre argent pour ça. Nous ne voulons pas rester à la maison pendant quelques années pour apprendre toutes les technologies possibles avant d'entrer dans le marché du travail […] Nous voulons apprendre sur le tas ». Or, un programmeur qui ne possède pas les compétences adéquates est « une ressource non fiable » et « aucun projet ne prendrait une telle ressource depuis le début ».
Concernant Sam Atkinson, nous pouvons néanmoins discuter les gains apportés par l’utilisation de nouveaux langages par rapport aux coûts nécessaires à leur apprentissage, et rester toujours prêts à nous reconvertir dans ces langages si cela est plus avantageux.
Source : Article de Sam Atkinson, Article de Yegor Bugayenko
-
el_slapperExpert éminent séniorLes deux articles sont fort différentes l'un de l'autre.
Celui de Yegor Bugayenko, en gros, dit qu'on ne devrait pas avoir à apprendre au cours d'un projet. Point. Celui de Sam Atkinson dit, lui, que Java permet de résoudre tous les problèmes, et est standard, donc aucun autre langage n'est utile.
Je ne suis d'accord avec aucun des deux articles. Le développement est une activité hautement fluide, contrairement à la plomberie prise en comparaison. Si un plombier met une heure à installer un lavabo(chiffre complètement au pif, je n'y connais rien), il mettra à peu près dix heures pour en installer dix similaires. Peut-être 9 et demi avec l'effet d'expérience. Si un développeur met 10 heures à coder un envoi de mail, pour les 9 autres, il réutilise le code, voire l'encapsule, et ne mettra pas beaucoup plus de temps.
Surtout, si on encapsule proprement, on gagne beaucoup de temps pour la suite du projet - et pour la maintenance. Un contenu informatique n'est pas comme un bâtiment, c'est très vivant, et ça change tout le temps. Prendre le temps d'enseigner les spécificités dudit ensemble, ça permet de gagner du temps tout de suite - le programmeur sera plus opérationnel - et plus tard - on aura un ensemble cohérent. Chaque projet est différent, et croire qu'il suffit d'en maitriser un pour maitriser les autres me parait hautement illusoire.
Pour ce qui est du Java, c'est effectivement un langage qui permet de tout faire. Mais la contrepartie est qu'il n'est pas spécifiquement à adapté à tel ou tel besoin. Il est généraliste. Pour des sujets spécialisés, d'autres langages survivent ou même se développent. J'ai souvenir d'un batch comptable réalisé dans une banque de taille moyenne dont les grands chefs rêvaient de "tout Java", et qu'on m'a fait faire en Cobol. Parceque j'étais deux fois moins cher.
Ca ne veut pas dire que Java est toujours un mauvais choix, mais comme toute création humaine, il a ses limites, et affirmer de but en blanc que c'est toujours le bon choix, c'est à la limite de la croyance religieuse.le 08/04/2015 à 7:39 -
Haseo86Membre éclairéLe décalage entre le contenu de votre article et le titre que vous lui donnez est surprenant, pour ne pas dire dérangeant, sans parler de l'amalgame fait entre les deux articles sources.
En gros l'un fait la pub pour son petit langage préféré (langage que j'utilise au quotidien personnellement, avec d'autres, Java ne saurait résoudre tous les problèmes), et l'autre dit que profiter d'un projet de développement pour apprendre n'est pas honnête, parce que ce n'est pas pour ça que le projet est financé.
Donc aucun rapport entre les deux, mais un débat très intéressant en perspective sur l'intérêt/la possibilité d'apprendre sur le tas en développant. Comme ça a déjà été dit dans les commentaires, il est illusoire de penser que l'on ne passera pas une seule seconde à apprendre au cours d'un projet, et que tout nous est déjà connu avant. Même quelqu'un qui fait du Java depuis 10 ans continue à apprendre, ne serait-ce que parce que les langages évoluent, et évoluent rapidement.
Prendre 50% du temps d'un projet de développement pour se former est très certainement discutable, mais penser que 100% de ce temps sera utilisé à coder est illusoire. Dans le cas contraire c'est que le développeur se contente de ses acquis, ce qui est je pense bien plus mauvais que de passer un peu de temps régulièrement à se mettre à jour.le 08/04/2015 à 13:56 -
fatbobMembre éclairéle 08/04/2015 à 14:04
-
fatbobMembre éclairéMoi non plus, je ne suis pas d'accord avec ces articles.
Pour ce qui concerne Java, j'ai essayé et je n'ai jamais réussi à m'y mettre vraiment. J'ai toujours trouvé le développement en java d'une lourdeur sans égale dans les autres langages que j'ai pu tester (peut-être C++ ?). Il est évident que pour un développeur chevronné dans ce langage, ce point doit s'amenuiser avec le temps mais quand même. Pour la lisibilité et la maintenance, pour ma part, je préfère python (de loin).
Par ailleurs, il faudra m'expliquer comment faire une appli web sans utiliser au moins deux langages (sans compter html et css).
Quant à l'apprentissage au cours d'un projet... Je ne vois même pas comment on peut faire pour ne pas apprendre à chaque projet.
Chaque développement un peu trapu entraîne des choix et des expériences qui sont des apprentissages. Ceux qui ne fonctionnent pas bien entraineront d'autres choix la fois d'après qui nécessiteront sans doute également une part d'apprentissage.
Le plombier a des normes fixes (relativement) là où un développeur travaille sur des environnements mouvants. Un développement de deux ans et la base de donnée a de nouvelle fonctionnalités, le framework a changé de version majeure, le langage a évolué notablement et le contrat suivant est déjà signé... Où apprend-on dans ce cas ?
Au contraire de l'article, je pense que le développeur DOIT se former en permanence, sur tous les projets qu'il fait. Ça fait partie intégrante de son boulot. Celui qui ne le fait pas ne peut pas tenir plus de dix ans avant d'être complètement dépassé sauf à considérer que l'apprentissage des techniques du métier sont un loisir. Je ne vois pas pourquoi un client ou un employeur n'aurait pas à se soucier de cette partie du travail. C'est un peu facile de demander des types de bon niveau, formé aux dernières technologies, sans prendre en compte la nécessité pour ces ressources d'une formation véritablement continue.le 08/04/2015 à 9:45 -
TheLastShotMembre extrêmement actifPour moi ces deux personnes sont probablement des gens qui n'ont absolument jamais travailler eux-même sur des projets réels. Ils ont peut-être géré des projets et dirigé un équipe de développeur. De plus, l'exemple choisi par ce monsieur Yegor Bugayenko montre bien la stupidité de son raisonnement.
Je cite : "si on contacte un plombier pour installer un système de drainage dans notre maison, et que celui-ci nous dit qu’il n’a jamais travaillé sur une telle tâche, nous n’accepterons jamais de dépenser notre argent pour qu’il puisse se former"
C'est totalement absurde. En effet on n'aura probablement jamais un plomber seul pour ce genre de tâche, mais lorsque ceux-ci sont formés c'est évidemment par l'expérience. Et c'est la même chose en programmation, c'est d'ailleurs ce à quoi servent (ou plutôt sont censé servir) les stages en entreprise.
De plus, je trouve qu'il est très important (en tout cas c'est mon point de vue) d'apprendre quelque chose lorsque je travail sur un projet, sinon je ne vois aucun intérêt dans sa réalisation.
En ce qui concerne ce cher Sam Atkinson (dommage, il ne lira probablement pas ceci), je voudrais lui signaler que Java n'est pas (mais pas du tout) le meilleur langage au monde. Il existe plein de concept absent de ce langage (ou apparu très/trop tardivement) tels que la surcharge d'opérateur et les paramètres par défaut, qui me semblent être des concept relativement basique dans le paradigme sur lequel se base Java. Et j’enchaînerais justement sur la chose suivante: il existe beaucoup de paradigmes (POO, fonctionnel, procédural, pour ne citer que les plus connus) et le fait de maîtriser plusieurs langages, basés sur différents paradigmes, permet justement d'enrichir sa culture et de pouvoir appréhender la résolutions de problèmes sous différents angles.
Bref, je déteste quand on essaie de faire croire que le travail de développeur se résume à accomplir une tâche de manière automatique, sans réfléchir, à la manière d'un robot incapable d'étudier les différentes solutions qui s'offrent à lui et incapable d'évoluer. Le vrai problème chez les développeurs, c'est d'être dirigé par ce genre de personne.le 08/04/2015 à 11:37 -
_skipExpert éminentJ'ai lu l'article de Sam Atkinson et je pense que son propos sur java fait entièrement du sens. C'est juste qu'il vous est rapporté entièrement sorti de son contexte.
Envoyé par Sam Atkinson
Donc lorsqu'il en arrive à son argumentaire comme quoi Java est le meilleur choix parmi ceux-ci, c'est pas dans le sens "C++, javascript, php, .net et tout le reste du monde c'est de la merde" comme on pourrait le croire dans les fragments repris en français de ce topic. Déjà en limitant le scope de son affirmation aux langages pour la JVM, son propos a tout de suite moins l'air d'une bêtise, sachant que les langages destinés à produire du bytecode pour la JVM adressent généralement les mêmes besoins et sont dans la plupart des cas *relativement* interchangeables.
En gros ce qu'il dit :- Qu'aucun langage pour la JVM n'est aussi bien servi question outillage que java, c'est objectivement assez vrai.
- Que java c'est globablement du terrain connu et qu'on a des chances de trouver les réponses (forte communauté), c'est vrai
- Qu'introduire un autre langage comme Scala ou Groovy accroît les risques de maintenance et ne devrait pas être pris à la légère, c'est largement défendable aussi.
- Qu'il faut donc des arguments vraiment solides pour justifier l'emploi de ces langages alternatifs en entreprise dans le contexte particulier de son projet sous peine que ça vous retombe lourdement dessus en cas de problème, c'est plutôt vrai aussi.
Donc pour commencer, avant de lâcher des pavés du style "Qu'il essaie de faire XX avec son java de merde" ou encore "si on l'écoutait, on ferait du Cobol", franchement allez lire la source.le 09/04/2015 à 9:03 -
tanatielMembre régulierC'est tellement vrai. La seule vraie formation que j'ai eu dans ma carrière remonte à 15 ans, depuis j'ai toujours eu droit au fameux "pas de formation sans projet"
Alors oui, rien ne vaut la pratique mais tout de même, les SSII sont dans l'extrême pour la plupart. Et j'ai vu plus d'un projet lancé en mode rock'n roll et que c'est au bout de 3 moi de dèv fait par des juniors qu'on se rend compte qu'on a des problèmes de techno non maîtrisée. Parce que connaître un langage ce n'est pas connaître les différents frameworks qui ont été développés dessus, par exemple.le 14/04/2015 à 16:30 -
dfiad77proMembre expérimentéUn peu outré par les conclusions de cet article
:
- un dev qui n'apprend qu'un seul langage se retrouve mis à la porte lorsque ce langage n'est plus à la mode et qu'il n'a pas su se renouveler
- comment fait-on pour se renouveler si l'entreprise nous cloisonne dans un environnement. ( Je parle pour les dev qui ont des enfants et ne peuvent pas se renouveler chez eux au détriment de l'éducation) « une ressource non fiable » et « aucun projet ne prendrait une telle ressource depuis le début ».
Bref avec ce genre de considération , beaucoup de DEV quittent la technique pour passer dans le management, c'est une perte considérable !le 08/04/2015 à 12:26 -
kolodzModérateurEn premier lieu, je tiens à noté que cela fait plaisir d'avoir le premier commentaire d'un article qui est allé lire les sources.
En second lieu, les deux articles ont deux problématiques différentes et donc deux points de vue différents. L'article de Sam Atkinson parle principalement des langages alternatifs et utilisations dans des projets professionnels sans bonne raison. Ce qui posera forcement des problèmes de maintenances (Si cela n'en pose pas pendant le projet en lui-même). L'article de Yegor Bugayenko, lui parle de la relation de l’apprentissage "des bases" dans une équipe de développement pendant un projet.
Pour le détail, je vais commenté ce que j'ai lu :
Ce n'est pas ce qu'explique Sam Atkinson, en particulier quand sa conclusion inclus : I think being able to program in multiple languages is an absolute must and is something I look for on a CV."
L'idée du choix de l'apport d'un nouveau langage dans un projet devant suivre cette logique : But you need to be able to properly justify this up front with strong reasoning. The answer shouldn’t be “I fancied trying something new”.
Cela soulève deux argument selon moi.
En premier lieu, il faut bien comprendre que l'argument de Yegor Bugayenko est de dire que si tu es sur un projet utilisant le langage X, et que tu es développeur en Y. C'est le manageur qui a fait une boulette et c'est à lui d'assumer la connerie et non à toi : Ask the project manager to fix this.
En second lieu, il ne pas confondre travail et projet. Un emploi ne se résume pas à un ou plusieurs projets. Si tu as un jour un manageur un minimum compétent, tu verra que celui-ci n'affecte pas directement une personne à un projet. En générale, celle-ci a un temps de formation.. En particulier quand une personne rejoins une entreprise.
D'ailleurs, cela est l'une des raisons qui fait qu'un projet ne finit pas "dans les temps", simplement parce que le temps de formation s'est retrouvé dans le temps du projet. Alors, que c'est bien autre chose...
Au final, je dirai qu'il faut aussi bien comprendre le degré d'incompétence ciblé est "Je n'ai pas la moindre idée de ce qu'il faut faire." et non "Je ne suis pas sûr d'une chose."
Et encore, encore une fois, ne pas confondre projet, travail et emploie.
Il y a deux possibilités :
- changer d'entreprise
- Être payer plus et donc avoir la possibilité financier de se re-former
Beaucoup de "dev" passent dans le management, simplement parce qu'il n'y a pas filière "management technique". La plus part des manageurs actuels sont des anciens développeurs.Envoyé par LSMetag
J'ai un ami qui est formateur sur COBOL... IBM maintient un plug-in eclipse pour développer en COBOL. Et oui, c'est pour du bancaire. L'évolutivité, il y a certains moment où tout le monde l'en veux pas. En particulier, quand tu apprends que l'une des versions de PHP avait un problème sur les calculs sur le nombre flottant.
Je ne te reprends pas sur la confusion général que tu réalise entre ton "chef de projet" et ton "supérieur hiérarchique"....
Envoyé par LSMetag
Ce qui est basiquement ce que tu vient de dire... Visiblement, tu n'es pas une personne sur le terrain en ce qui concerne cette article !
Cordialement,
Patrick Kolodziejczyk.le 08/04/2015 à 16:12 -
Laurent 1973Membre chevronnéLe problème viens plutôt de la relation client-prestataire d'avant vente.
Si le client dit: "je veux et j'exige que mon application soit fait en Fortran 77", c'est son choix.
Là, le prestataire devra alors trouver une équipe de développement spécialiste en Fortran 77 s'il veut emporter le marché - le client accepte aussi de ne pas avoir trop le choix de l'équipe et donc du prix.
Mais si le client dit "je veux la meilleur solution au moindre coût pour mon application".
Là, le prestataire fera une proposition technologique en fonction des compétences de son équipe disponible afin de rentrer dans le budget du client - et la concurrence peut être plus féroce.
Et puis, il peux y avoir des nuances entre ces deux situations, avec une négociation technologique entre le SI du client et les développeurs.
Mais c'est sur que si les deux, client et prestataire, ne sont pas d'accord sur la technologie choisi, on va au crash.le 15/04/2015 à 9:54