Les questions à la con - Page 224

Hmm donc si j'essaie de résumer, ça rejoint la première hypothèse que je mettais en ./6656, à savoir que la somme de connaissances est trop grande pour qu'une seule personne la couvre efficacement ? C'est probablement une partie du problème, d'ailleurs je pense qu'on ne différencie pas assez ces métiers et que ça contribue à entretenir cet effet. Ceci dit j'ai l'impression de constater le phénomène même sans des branches plus restreintes, c'est pour ça que je citais uniquement les développeurs (même si bien sûr ça reste également pas très précis).

Tu cites l'exemple du développeur qui hurle pour des accolades en fin de ligne, et même si c'est un peu caricatural ça reste des réactions qu'on voit aujourd'hui, avec des gens qui vont soutenir qu'une solution est mauvaise en se basant uniquement sur des critères qui se résument à "c'est différent de ce à quoi je suis habitué". Là-dessus je veux bien croire que ce soit un réflexe défensif qui n'est pas du tout limité au domaine de l'informatique.

Zeph (./6691) :
d'ailleurs je pense qu'on ne différencie pas assez ces métiers et que ça contribue à entretenir cet effet.

Attention à l'effet inverse ! L'ultra cloisonnage a existé dans l'informatique... "Ok, t'es sénior AS400 sur clavier azerty pour l'assurance mais là on est une banque suisse, nos claviers sont qwertz, de combien d'expérience tu peux justifier sur cet environnement ?" (autrement dire qu'à part avoir déjà travaillé chez eux, la seule réponse est "0")

Et en évolution de carrière, un cloisonnage trop serré peut vite être frustrant (en prenant moins "caricatural", imaginez le dév qui est rentré dans une boite pour faire du front et qui aimerait passer sur du back et en fait hors de question parceque "son job c'est dév front")

En l'occurrence ton dernier exemple est sujet à débat justement : depuis quelques années le développement web s'est énormément complexité (est-ce que c'est une bonne choses ou pas, c'est une autre question). Au boulot en ce moment on recherche des devs ayant des compétences front pour les rares tâches qui en comportent, sauf qu'on en a pas vu qu'on en a jamais vraiment eu besoin et que mettre des devs back dessus marche assez mal (ça ne leur plait pas plus que ça, le résultat est moyen, à contre courant des technos actuelles, etc.). Peut-être que si on avait cherché des "vrais" devs front un peu plus tôt ça aurait mieux fonctionné, en tout cas j'ai l'impression qu'il reste une sacré marge aujourd'hui avant de tomber dans un cas de cloisonnement extrême.

Zeph (./6693) :
en tout cas j'ai l'impression qu'il reste une sacré marge aujourd'hui avant de REtomber dans un cas de cloisonnement extrême

y'a 15 ans (je commençais à bosser), c'était le cas et en SSII ta première mission définissait ta "spécialité" advitam

OK, je ne peux rien dire, mon expérience ne remonte pas assez loin ^^

Zeph (./6693) :
depuis quelques années le développement web s'est énormément complexité (est-ce que c'est une bonne choses ou pas, c'est une autre question).

C'est une très bonne chose pour l'innovation. En revanche, c'est une catastrophe pour le recrutement. Les recruteurs vont se figer sur une techno particulière populaire, et les candidats vont devoir apprendre les technos les plus populaires, même si elles viennent à être dépassées. Ou à l'inverse, les recruteurs vont taper dans ce qui est le top pour eux en ce moment, et ils auront du mal à embaucher tant les candidats sont dispersés sur les compétences.

Tiens par exemple, Angular : bonne idée, soutenue par Google, envoyez. Peu après, Angular 2 "mieux pensé", mais on envoie à la poubelle toute la compétence Angular 1, changement majeur. Et justement, on vient de passer à Angular 4, youpi ! 4, déjà ? mais le 3 ? le 3 n'existe pas, il n'est jamais sorti, because fuck you.
Maintenant on a les devs qui ont commencé à prendre de la compétence sur le 1, ceux qui sont péniblement passés au 2 (ou ont commencé par le 2), et les recruteurs vont avoir besoin de devs "2" pour leurs nouveaux projets mais de devs "1" pour maintenir les précédents.

vanilla JS + jQuery ftw quand même, c'est un truc qui marche partout depuis des années.

Le bordel qu'est devenu le web est clairement une mauvaise chose. C'est aussi un problème côté client, parce que les exigences des sites montent sans arrêt. Même jQuery fait partie du problème, à chaque version majeure, ils virent radicalement le support pour tous les navigateurs non-dernier-cri. Et au-delà des exigences en fonctionnalités récemment introduites, celles en mémoire et en vitesse d'exécution de JavaScript ne cessent pas non plus d'augmenter dans tous les frameworks. Mais c'est sûr que c'est aussi un problème pour les développeurs d'être sans arrêt sous pression d'utiliser une nouvelle technologie totalement différente qui wrappe le JavaScript d'une nouvelle manière incompatible nécessitant de réécrire tout le code.

Zeph (./6656) :
J'ai l'impression que le développement en informatique est un domaine dans lequel tout le monde est persuadé d'être très bon, ou en tout cas très largement au-dessus de la majorité de ses pairs.

Je ne sais pas jusqu'à quel point c'est vrai en fait... il y a beaucoup de gens pour critiquer le travail des autres, mais dès qu'il s'agit de libérer le code, de le faire auditer ou quoi que ce soit, les gens vont avoir tendance à dire "oui, mais non, mais en fait, là, tu vois, j'ai pas eu le temps, c'est pour ça que c'est sale".
Perso (mais je sais que je ne suis pas une généralité ^^), j'ai plutôt tendance à trouver que, par rapport à [l'image que j'ai de] bien des gens ici, je développe plutôt pas hyper bien. Ca a plein d'explications (je suis seul développeur, je dois faire développeur/intégrateur/assistance/DBA/technico-fonctionnel...), mais il n'empêche que je sais très bien que je ne suis pas "bon" (mon code n'est pas adapté aux tests unitaires, je reconnais qu'il n'est pas assez éprouvé au niveau sécurité, il y a des pans entiers pour lesquels je ne prends pas le temps de factoriser, etc.). Puis bon, je ne fais plus que du SQL, du PHP et du JS (et encore, mon JS est relativement primaire, uniquement front-end, et majoritairement vanilla)... enfin voilà, j'ai clairement conscience de mes limites ^^

Ca me fait penser... le développement front-end est-il devenu un bordel sans nom ??

Et comme d'habitude, les derniers CommitStrip correspondent bien à la discussion en cours ^^

Oui,

Zeph (./6691) :
Hmm donc si j'essaie de résumer, ça rejoint la première hypothèse que je mettais en ./6656, à savoir que la somme de connaissances est trop grande pour qu'une seule personne la couvre efficacement ?

Certains y arrivent quand même plus que d'autres (surtout l'3l33t de yN, bien évidemment ).
Mais au-delà du niveau propre des gens, il y a à mon avis un facteur aggravant qui est l'entourage professionnel. Un gars qui sort d'école et qui tombe dans une boîte super pro (avec des procédures super cadrées, des normes de code au top, etc.) n'aura rien à voir avec le même gars qui tombe dans une boîte où il sera tout seul à tout faire. Malheureusement, les boîtes super pro ne sont peut-être pas la majorité — je ne connais pas forcément bien le privé, mais c'est l'impression que j'en ai. À nouveau, je ne pense pas qu'aux boîtes d'info, mais aussi aux petites boîtes qui ont un ou deux développeurs (comme pour Arvi).

Mais bon, je reste persuadé que travailler correctement en informatique (pas que le dév, donc) sera de plus en plus facile avec le temps.

C'est probablement une partie du problème, d'ailleurs je pense qu'on ne différencie pas assez ces métiers et que ça contribue à entretenir cet effet. Ceci dit j'ai l'impression de constater le phénomène même sans des branches plus restreintes, c'est pour ça que je citais uniquement les développeurs (même si bien sûr ça reste également pas très précis).

Malheureusement, différencier les métiers n'est tout simplement pas viable pour beaucoup de boîtes

Tu cites l'exemple du développeur qui hurle pour des accolades en fin de ligne, et même si c'est un peu caricatural ça reste des réactions qu'on voit aujourd'hui, avec des gens qui vont soutenir qu'une solution est mauvaise en se basant uniquement sur des critères qui se résument à "c'est différent de ce à quoi je suis habitué". Là-dessus je veux bien croire que ce soit un réflexe défensif qui n'est pas du tout limité au domaine de l'informatique.

./6696 : ça veut dire quoi, "c'est une bonne chose pour l'innovation" ? Innover n'est pas un but en soi, si ?
./6698 : de mon point de vue tu es vraiment une exception (enfin disons plutôt que tu es un profil "rare")
./6703 : oh je ne pense pas que ce soit aux boites de différencier les métiers, et effectivement les petites boites ne vont pas multiplier les postes pourtant, elles continueront à avoir des "hommes à tout faire" comme c'est déjà le cas pour d'autres métiers. Mais peut-être que ça clarifiera un peu mieux les attentes qu'elles peuvent avoir de ces gens à qui elles demandent de combler plusieurs manques simultanément (#pointnil# ?)

Zeph (./6704) :
./6698 : de mon point de vue tu es vraiment une exception (enfin disons plutôt que tu es un profil "rare")

Je pense pas que ca soit si rare que ça.
Je me reconnais tout a fait dans sa description ainsi que beaucoup de ceux avec qui j'ai travaillé.

Faire les choses bien, ça demande du temps et de l'attention, et quand il y a des choses plus urgentes ou que tu n'as pas vendu assez cher la prestation pour pouvoir prendre le temps de faire bien les choses, parfois tu ne met pas tout le soin que tu devrais. La plupart des gens ne zappent pas les bonnes pratiques par méconnaissance mais tout simplement parce qu'ils estiment qu'ils n'ont pas le temps ou les moyens de le faire, quitte a le regretter plus tard quand il faudra maintenir le code.

Zeph (./6704) :
ça veut dire quoi, "c'est une bonne chose pour l'innovation" ? Innover n'est pas un but en soi, si ?

Pour dire les choses grossièrement, comme le Commit Strip précédent l'a évoqué, chacun va y aller de sa petite ou grosse solution pour couvrir ses besoins, parce qu'aucune solution open-source ne lui convient vraiment (c'est ce que j'avais commencé à faire avec mon projet Little Writer), et de la mettre open-source ensuite parce que c'est si bien que tout le monde doit en profiter.
Une ou des solutions finissent par émerger de tout cela, gagnent le cœur de la communauté, et prennent en maturité pour devenir des outils acceptables pour le long terme. L'innovation, ici, n'est pas un but, c'est une conséquence de ce Not Invented Here constant.

C'est un argument très discutable, parce que la seconde phase (l'unification) ne se fait pas toujours. Du coup on se retrouve avec tout plein de solutions différentes qui ont toutes leurs propres défauts, alors qu'en mettant le boulot en commun il y aurait moyen d'en faire quelque chose de globalement meilleur. Y'a plein d'exemples comme ça dans le monde de l'open-source.

N'a tu pas remarqué que ce probleme n'existe (presque) que dans le monde de l'OSS?

Je ne suis pas d'accord, et pourtant je ne suis pas toujours tendre avec l'OSS

C'est vrai que c'est (très) répandu dans le monde de l'OSS, mais on voit la même chose dans certaines entreprises ou administrations où les services sont cloisonnés, du coup chacun bricole une solution bancale dans son coin.

Et par définition, ça semble beaucoup plus compliqué de mutualiser dans le monde du closed source...

Ils le font bien avec les standards

Le code non-libre n'est par définition pas partagé. Si une entreprise veut partager son code, elle le rend libre. Et si des développeurs closed source ont besoin de quelque chose, soit ils utilisent une bibliothèque libre sous une licence non-copyleft, soit ils l'implémentent eux-mêmes.

Kevin Kofler (./6712) :
Le code non-libre n'est par définition pas partagé.

euh… non ?

Pourtant il y en a plein du code non libre qui est partagé, j'en propose moi meme

Uther (./6705) :
Faire les choses bien, ça demande du temps et de l'attention, et quand il y a des choses plus urgentes ou que tu n'as pas vendu assez cher la prestation pour pouvoir prendre le temps de faire bien les choses, parfois tu ne met pas tout le soin que tu devrais. La plupart des gens ne zappent pas les bonnes pratiques par méconnaissance mais tout simplement parce qu'ils estiment qu'ils n'ont pas le temps ou les moyens de le faire, quitte a le regretter plus tard quand il faudra maintenir le code.

Très bonne remarque en effet. Je distingue deux cas : les travaux bâclés par manque de temps et les projets bâclés par manque de motivation, pourtant aucun des deux n'est un problème de compétence. Encore qu'a priori la compétence dans un métier ne peut pas apparaître sans motivation, mais peut-être qu'il y a des exceptions.

Tout depends de ce que tu apelle pas competence.

Si c'est "faire ce qui est a faire" je ne suis pas d'accord pas besoin de competences pour faire du travail a la chaine par exemple (que ca soit en usine ou de pisser du code qui est globalement identique tout le temps avec 2 ou 3 changement sans avoir besoin de reflechir)

Godzil (./6708) :
N'a tu pas remarqué que ce probleme n'existe (presque) que dans le monde de l'OSS?

Pas vraiment, en fait (et c'est même en général beaucoup plus critique quand on n'est pas dans le cadre de l'OSS). Il y a énormément de solutions d'infrastructure qui sont proposées par Oracle, IBM, Sun, RedHat, Apache, Microsoft, Novell, Apple... qui sont toutes basées sur des standards mais qui, au final, ont toutes leurs spécificités qui font que rien n'est compatible et rend toute migration ou interopérabilité soit très difficile à mettre en oeuvre, soit carrément impossible (pour parler de quelque chose que je connais, toutes ces boites ont leur service d'annuaire, basée sur LDAP et aucune n'est 100% compatible avec les autres... c'est la même chose pour les serveurs d'applications Java, d'ailleurs).
Autre exemple : la majorité ces boites a sorti un (ou des) langage(s) de programmation, tous avec des avantages, mais il n'y a aucune compatibilité entre eux, du coup on se retrouve avec exactement la même problématique qu'avec les framework JS : des compétences éparpillées, des guerres stériles, etc.

Zeph (./6656) :Mais quand même, quand je discute avec des gens qui travaillent dans des domaines très différents c'est un phénomène dont je n'entends jamais parler, donc je me demande si c'est une particularité ?

60 posts après on a toujours pas de réponse définitive. Bravo

Red Hat et Apache font du logiciel libre / OSS, je ne vois pas ce qu'ils font dans ta liste.

Et sinon, dans ta liste, Sun a été racheté par Oracle il y a longtemps, et les 5 premières entreprises que tu listes (qui ne sont en fait que 4) font toutes du Java. Red Hat est flexible et promeut aussi le Python et le C (et certains de leurs logiciels sont en d'autres langages comme l'OCaml), mais pour les entreprises, c'est le Java qui est proposé en premier. Donc ton histoire de guerres entre les langages de programmation ne colle pas avec ta liste.

Pourquoi les fabricants de disques dur et de cartes mémoire continuent de vendre de l'espace de stockage où sur la boîte 1 Ko = 1000 b. Ca n'a aucun sens, surtout aujourd'hui où on a des disques de 10 To, où en fait il "manque" 700 Go.