Discussion :

[yento]

Au téléphone
Moi : - Il faudrait que tu testes puis après tu valides la Request For Change
Utilisateur : - C'est bon je valide
Moi : - Heu, il faudrait que tu testes avant.
Utilisateur : - Oui c'est bon j'ai testé je valide.
Moi : - ... Il faudrait peut-être que tu me demandes avant de te donner les accès à la base de recette... (histoire qu'on livre pas n'importe quoi et que tu m'engueules que les résultats sont pas bons...)

Pareil dans l'autre sens


Développeur: J'ai une revue de code qui t'attend. Un petit truc.
Moi: *ouvre la revue, ca modifie quelques fichiers pas important sur un projet ou il bosse en ce moment*
Moi: J'ai deja 4 autre revues en cours la. Ca te va si je clique accepter sans tout lire? T'es confiant dans ce que t'as fais, et t'as teste hein?
Développeur: Euh...


Je précise que je suis en banque donc si ca affecte pas $1 millard ou 1000 applications, c'est pas important. Et on a review obligatoire et 50% de code coverage pour push.

[Ecasla]

Je suis encore halluciné, en 2020, qu'il y ait des gens qui aient ouvert leur PC, leur navigateur, sont allés sur leur moteur de recherche favori, sont arrivés sur developpez, ont créé un compte (rempli un captcha ? je sais pas, j'ai créé mon compte y a 15 ans...), puis postent leur question sur VBA dans la section présentation... et sont pas capables de trouver la section VBA...

Je sais bien qu'on ressort la blague de T'es informaticien, tu pourrais réparer mon imprimante ? mais bon là t'as quand même une structure dans ta tête...

C'est un taquet à propos d'une conversation ahurissante sur du consulting ERP?

[Ekolamar]

Mon père, dans le métier depuis 1972, m'a dit plusieurs fois : "aller chercher l'information, si il le faut avec les dents, ça fait partie intégrante de ton boulot"

Ca c'est aussi en partant du principe que tu peux récupérer les informations : Ca doit marcher dans les petites boites mais dans les grands groupes tu oublies tout de suite. J'ai récupéré tout ce que j'ai pu, encore une fois, j'avais déjà quasiment tout modélisé et je savais où était les info nécessaires.

Mais quand tu demandes à l'équipe qui a l'info juste d'avoir l'accès (lecture seule en plus...) et qu'elle ne répond que c'est pas possible, c'est pas le process et que tu insistes mais "oui mais non, on est en pleine refonte là donc on ne peut pas te donner"

Alors que la vérité est beaucoup plus pragmatique : La donnée n'existe pas, leur référentiel est vide/troué et ils ne veulent pas que ça se voit, donc ils ne donnent l'accès à personne et quand un manager demande une info, ils récupèrent à la main et te file un excel...
Et de toutes façon il n'y a rien que tu puisses faire, même avec les dents : Dans beaucoup de cas personne ne te répond sans mettre un manager en copie, et aucun manager n'ira contre quelqu'un de son équipe, donc tu dépends de la bonne volonté des personnes, ce qui dans un groupe groupe revient à peu de chose car la bonne volontée elle disparait après quelques mois à te forcer à participer à une guerre politique bon gré mal gré (et parfois même à la demande de ton propre manager qui te dit de ne pas aider/répondre à X ou Y parce qu'il ne peut pas le blairer).

[fredoche]

Toi qui parle de "jargon"... programmer n'est pas dur ; c'est développer qui l'est.
Être dans un contexte de mon du travail, un seul incompétent suffit à foutre le travail ou la réputation d'une équipe en l'air. Et des projets qui prennent l'eau à cause d'un seul boulet de canon tiré au mauvais endroit au mauvais moment et qui fait un trou béant dans la coque...

C'est une des dimensions de ce qui me semble important dans la notion d'environnement.
Développer une application ou un applicatif c'est une palanquée de contraintes et d'enjeux qui va bien au delà d'écrire du code.

Oui Mat_mat_bi, le grand voulait faire du C++ pour son stage de DUT. Personnellement je trouve ça juste nul et complètement dépassé. Ou quelque part vouloir s'emmerder avec les pires outils alors qu'ils en existent tant de bien meilleurs et plus puissants offerts aujourd'hui.
Mais bon c'est son choix.
Ce serait du C encore, je pourrais comprendre.
C'est là où je trouve que l'enseignement est à la ramasse comparé à l'actualité du métier dans le monde

Sinon je suis désolé, donner des instructions à une machine, quel que soit le langage, c'est plutôt simple. Je fais partie de ces gens qui programmaient des centres d'usinage numérique avec un porte-outils d'une douzaine d'outils pour la création de pièces mécaniques en utilisant un langage dont j'ai même pas le souvenir qui transcodait ensuite sous forme de bandes perforées. C'était au lycée, en 1ère.
Le mytho c'est plutôt celui qui se raconte son langage et sa belle qualité d'expression syntaxique dans celui-ci.
Le métier de programmeur existe depuis facile 50 ans, il est aujourd'hui pratiqué par des millions de gens à travers le monde.

Et donc si mes enfants veulent coder, ils auront somme toute peu de valeur ajoutée sur le marché, sinon une valeur très commune. C'est ce que je leur dis

[Chezkele]

Oui Mat_mat_bi, le grand voulait faire du C++ pour son stage de DUT. Personnellement je trouve ça juste nul et complètement dépassé.

Je travaille dans un domaine qui (il me semble, empiriquement) est assez peu représenté sur cette partie du forum: le développement de codes scientifiques. Et ce que je constate, c'est que le C++ est extrêmement utilisé dans ce domaine. Ce que me dit mon expérience, c'est que c'est le langage que l'on choisit généralement pour réécrire des codes/chaînes de calcul dont les premières versions ont été développées (très souvent en fortran, qui est encore lui aussi un langage pour lequel il y a un marché) il y a quelques décennies. Ce qui me semble au final assez logique, le C++ étant à la fois objet/performant/à la syntaxe proche des langages procéduraux utilisés dans le domaine.
Dans ma boîte, il y a des choses qui ont été (ré)écrites en python et je trouve ce langage moins adapté, bien qu'il soit considéré comme plus "moderne". Perso (j'insiste, je ne me considère pas comme étant particulièrement qualifié pour la ramener) j'utilise/utiliserais python pour faire des scripts de taille réduite, d'abord et avant tout.

Et donc si mes enfants veulent coder, ils auront somme toute peu de valeur ajoutée sur le marché, sinon une valeur très commune. C'est ce que je leur dis

La question n'est pas "sais-tu coder"? Mais "que sais-tu coder"? Le code, c'est son origine historique, est un outil qui permet de faire des calculs (et maintenant d'autres tâches) plus rapidement. Ces calculs/tâches ont un objectif qui s'inscrit dans un métier. Pour faire du dev en mécanique des fluides, savoir coder est un prérequis, mais d'abord et avant tout il faut s'y connaître en mécanique des fluides (équations de Navier-Stokes et tout le toutim). Savoir coder est équivalent à savoir son texte pour un comédien: c'est indispensable mais cela n'a aucune valeur si on l'isole du reste du travail. La question à se poser pour un étudiant est d'abord et avant tout: dans quel domaine est-ce que je veux utiliser la programmation. Et selon le domaine choisi, on peut être une denrée rare et extrêmement demandée.

Mais bon, il me semble que j'enfonce des portes ouvertes...

[Mat.M]

Savoir coder est équivalent à savoir son texte pour un comédien:

oui cependant le comédien sur les planches lui il faut pas qu'il ait des trous de mémoires
Si mettons Francis Weber ou Francis Huster sont sur les planches,dans des tirardes de Cyrano de Bergerac ils ont des trous ça la fout mal comme dirait l'autre.
Et moi en tant que programmeur je ne me souviens pas d'un truc en quelques secondes par exemple pour .NET je consulte le MSDN

Quant à "coder" pour moi c'est un truc un peu dépassé en entreprises notamment pour des projets de gestion étant donné qu'il existe des ERP.
Il faut plus parler de paramétrage qu'autre chose.
Le gros avantage d'un ERP c'est de se concentrer majoritairement sur le conceptuel

[Glutinus]

C'est un taquet à propos d'une conversation ahurissante sur du consulting ERP?

Y a lui et plusieurs autres tellement gratinés que même six ou sept ans après, je me souviens encore de la conversation...

Alors que la vérité est beaucoup plus pragmatique : La donnée n'existe pas, leur référentiel est vide/troué et ils ne veulent pas que ça se voit, donc ils ne donnent l'accès à personne et quand un manager demande une info, ils récupèrent à la main et te file un excel...
Et de toutes façon il n'y a rien que tu puisses faire, même avec les dents : Dans beaucoup de cas personne ne te répond sans mettre un manager en copie, et aucun manager n'ira contre quelqu'un de son équipe, donc tu dépends de la bonne volonté des personnes, ce qui dans un groupe groupe revient à peu de chose car la bonne volontée elle disparait après quelques mois à te forcer à participer à une guerre politique bon gré mal gré (et parfois même à la demande de ton propre manager qui te dit de ne pas aider/répondre à X ou Y parce qu'il ne peut pas le blairer).

Je l'ai tellement vécue, cette guerre... Tous les échanges mails étaient stockés, décortiqués, pour mettre en défaut une équipe si elle nous faisait chier. Ca faisait autant de skeud sous le coude, et s'ils nous attaquait c'était "Vous souvenez pas ? Il y a deux semaines dans le mail du ... à telle heure, vous avez dit de charger le fichier A alors que c'était le C".

Le plus drôle, c'est que j'ai bossé avec un vrai terrier : le mec, il savait déterrer l'information partout. On va dire que le communautarisme aide, car il avait de nombreux défauts : présente mal, arrive à 12h (mais part à 22h pour faire de la lèche à notre CP), très mauvaise communication écrite. Et surtout, cavalier seul, s'engage auprès d'autres équipes, voire chope leur travail histoire de se donner de la charge de travail. Ca aurait pu marcher dans d'autres situations, mais mon client (une petite structure dans une grosse) c'était comme les 12 coups de midi, ton but c'était d'éliminer une autre équipe pour récupérer son boulot, la notoriété qui va avec et les ETP... heu non, finalement les ETP c'était pas ça, le client pensait que magiquement en virant une équipe le boulot se ferait tout seul

[Glutinus]

Quant à "coder" pour moi c'est un truc un peu dépassé en entreprises notamment pour des projets de gestion étant donné qu'il existe des ERP.
Il faut plus parler de paramétrage qu'autre chose.
Le gros avantage d'un ERP c'est de se concentrer majoritairement sur le conceptuel

Depuis que je bosse, beaucoup veut essayer de bosser sur du SAP, notamment FI/CO.
Mais, est-ce vraiment que du paramétrage ? La réputation est qu'il y a beaucoup de code derrière pour faire du spécifique.

[Chezkele]

Quant à "coder" pour moi c'est un truc un peu dépassé en entreprises notamment pour des projets de gestion étant donné qu'il existe des ERP.
Il faut plus parler de paramétrage qu'autre chose.
Le gros avantage d'un ERP c'est de se concentrer majoritairement sur le conceptuel

Dans le domaine du dev de codes scientifiques, on code directement. Il n'existera jamais d'application à qui on pourra demander d'introduire telle façon de résoudre telle équation différentielle dans telle partie du code.

[Ecasla]

Depuis que je bosse, beaucoup veut essayer de bosser sur du SAP, notamment FI/CO.
Mais, est-ce vraiment que du paramétrage ? La réputation est qu'il y a beaucoup de code derrière pour faire du spécifique.

C'est un poil plus complexe que ça, et ça dépend énormément de la structure qui accueille l'ERP (quelque soit l'ERP).
Si c'est une petite entreprise qui n'a pas la compétence en interne, le développement spécifique est soit fait par l'éditeur, soit par l'intégrateur.
Si l'entreprise a des devs formés, le développement peut être fait en interne.

Après développement <> paramétrage, le développement, c'est le boulot du développeur, le paramétrage, c'est le boulot de l'administrateur (ou du chargé fonctionnel du domaine).

Et en général, pour qu'un ERP tourne convenablement dans une boite pour les utilisateurs et la direction, il faut la solution standard + paramétrage spécifique + développements spécifiques (pour gérer les flux scabreux souvent)

[Glutinus]

La question est plus la "proportion".
Ou la dérive : à partir de quand on se dit "ha merde, y a tellement de devs, ça nous coûte cher (que ce soit fait en interne ou par l'éditeur) on aurait dû faire une appli nous-mêmes".

[Ecasla]

La question est plus la "proportion".
Ou la dérive : à partir de quand on se dit "ha merde, y a tellement de devs, ça nous coûte cher (que ce soit fait en interne ou par l'éditeur) on aurait dû faire une appli nous-mêmes".

A aucun moment. Ce genre de réflexions sont plus un constat, toujours.
D'ailleurs, c'est souvent la phrase inverse que j'entends "Merde ! On s'est lancé dans une trop grande aventure, on aurait mieux faire d'adapter à notre sauce une solution du marché".

De plus, les SI évoluent avec et dans les structures qu'ils occupent.
Au début, il n'y a pas de besoins énormes donc c'est un produit maison avec des macros Excel et de l'huile de coude. Puis la société grandit et il se fait racheter (pas forcément). Les investisseurs veulent des chiffres et la solution maison n'arrive plus à fournir des données assez précises.

[Mat_MAT_BI]

De toute façon, imaginons que la multinationale du CAC ne fasse que 5 milliards et 900 millions d'euros de bénéfices au lieu de 6 milliards parce qu'elle a perdu 100 millions d'euros dans des projets SI pourris qui nous permettent de vivre..

Ce ne sera pas la fin du monde

Il faut bien que l'on vive, si tout était super nickel, on aurait moins de boulot...

[yento]

Et de toutes façon il n'y a rien que tu puisses faire, même avec les dents : Dans beaucoup de cas personne ne te répond sans mettre un manager en copie, et aucun manager n'ira contre quelqu'un de son équipe, donc tu dépends de la bonne volonté des personnes...

Ah bah ca va, c'est pas si mal que ca en avait l'air.

Tant que le manager defend son equipe, ca reste un environment decent. La vraie merde c'est quand le manager pourri sa propre equipe (et la c'est vraiment le signal de chercher ailleurs sans regarder en arriere).

[Ekolamar]

Ah bah ca va, c'est pas si mal que ca en avait l'air.

Tant que le manager defend son equipe, ca reste un environment decent. La vraie merde c'est quand le manager pourri sa propre equipe (et la c'est vraiment le signal de chercher ailleurs sans regarder en arriere).

Après faut pas trop rêver non plus, ici on parle par rapport à l'extérieur, car dire que son équipe fait de la merde revient à dire que lui fait de la merde...

Le comportement entre le manager et son équipe peut être totalement différent, surtout si il vient de recevoir de l'extérieur une demande justifiée restée lettre morte qu'il a dû trouver une justification pourrie ce qui l'a enervé car ça le met en porte-à-faux

Un peu comme la vie publique et la vie privée, parfois de l'extérieur une équipe à l'air horrible mais il peut y faire bon travailler car le manager est juste horrible avec "les autres"

[Mat.M]

dans des projets SI pourris qui nous permettent de vivre..

j'apprécie cette remarque: si les projets fonctionnaient à 100% donc pas de bugs à corriger ben pas de travail pour les programmeurs

[Glutinus]

Pas de TMA pour les SSII qui veulent refourguer du juju !
C'est une légende, et je ne sais pas si elle est si urbaine que ça : les SSII récupèrent des forfaits à prix cassés, les développeurs expérimentés (5 ans d'expérience) s'y cassent les dents, le tout est livré avec des bugs, et il faut bien justifier une TMA !

[Mat_MAT_BI]

Bien sur que c'est vrai

La SSII CIG Montpellier baisse son froc pour avoir le building d'une appli..

Après, ils récupèrent la TMA et facturent bien car le client est pris par les c****

C'est le jeu, ma pauvre Lucette, à faire de vouloir du pas cher, tu te fais limer tôt au tard..

Comme disait gégé la poche du PMU après son 3ième jaune.. "tu ne peux pas avoir un cheval pour le prix d'un âne"..

[GreatDeveloperOnizuka]

Bien sur que c'est vrai

La SSII CIG Montpellier baisse son froc pour avoir le building d'une appli..

Après, ils récupèrent la TMA et facturent bien car le client est pris par les c****

C'est le jeu, ma pauvre Lucette, à faire de vouloir du pas cher, tu te fais limer tôt au tard..

Comme disait gégé la poche du PMU après son 3ième jaune.. "tu ne peux pas avoir un cheval pour le prix d'un âne"..

ça à la limite je m'en tape que le client reçoit de la merde. Si il préfère rémunérer des marketeux au lieu d'aligner pour avoir un meilleur produit c'est son problème .

[Mat_MAT_BI]

pas cher pas cher pas cher... ben à la fin t'as un gros tas de M****

Tu croyais quoi pôv con