Discussion :

[calvaire]

je ne crois pas en cette étude.

des personnes compétentes/talentueuse j'en ai croisé mais j'ai toujours vue ces problèmes :

La boite refuse d'embaucher la personne avec un salaire à la hauteur de ces compétence
Elle trouve 1000 excuse pour ne pas l'augmenter
La boite ne le fera pas monter en grade et/ou sa hiérarchie le minore, du coup il reste avec peu de responsabilité et manque de challenge

du coup les mecs compétents se casse et vont voir ailleurs. Reste les stagiaires, les personnes moins bonne dans l'équipe et les nouveaux arrivants.
J'ai constaté cela dans beaucoup d'entreprises dont surtout les plus grosses SS2I de France (Capgemini et Atos notamment)

Les entreprises doivent comprendre qu'un salarié expérimenter payer 50000e peut être plus bénéfique à l'entreprise qu'un junior payer 25000e
Que répondre favorablement à une augmentation peut être mieux que de devoir embaucher un nouveau.
Et enfin faire plus confiance à des salariés sur le terrains que des managers dans les centres décisionnel à Paris.
De ma vision d'une personne pas compétente, les personnes que je considère plus compétente que moi suive en tous cas le schéma que je décrit plus haut.

Et enfin je refuse d'etre vue comme une personne compétente car compétent en entreprise ne veut pas dire bien faire son travail mais rester tard le soir a faire fonctionner un bout de code jusqu’à 23H parfois.
j'ai l'informatique mais j'aime aussi rentrer chez moi le soir et le weekend et faire autre chose qui n'a rien a voir avec l'informatique.
Je suis pas un esclave, je suis payé pour faire 36H alors je fais juste mes 36H, si le projet foire iou a du retard je m'en moque je serais quand mème payer pareil à la fin du mois. Je rentre pas dans un stress extrême comme les personnes compétentes qui s'investisse a fond dans le projet de l'entreprise.
on donne aussi du travail bonus aux personnes compétentes : assurer le support auprès des clients pas content, ou encore faire des "voyages" pour rencontrer les clients (qui n'ont rien a voir avec des vacances), je préfère rentrer chez moi le soir encore une fois.

J'ai toujours vue dans mes expériences que une personne compétente rimait avec personne faisant aussi beaucoup d'heure (non payé)

Et a l'école même chose, pourquoi travailler dure quand un simple 10/20 de moyenne suffit pour avoir un doctorat ? J'ai toujours eux des moyennes entre 10/20 et 13/20 et je suis aujourd'hui aussi bien payé voir plus que des majors de promos qui bossait tous le temps.
si rien ne t'encourage a bosser forcément tu te contente du strict minimum aussi.

et aussi si aujourd'hui on me proposait de travailler plus pour gagner plus je refuserais.
j'ai déja un salaire confortable qui me permet de partir en voyage 4 fois dans l'année, j'ai une famille qui manque de rien, une maison, une voiture. J'ai pas besoin de plus.
Avec un meilleur salaire, au lieu de rouler en casserole je pourrais rouler dans une Tesla, bouffer du caviar tous les jours, avec une tv 8K HDR et une RTX 2080Ti pour jouer mais je suis déjà bien assez heureux avec ce que j'ai.

[Ekolamar]

je ne crois pas en cette étude.

des personnes compétentes/talentueuse j'en ai croisé mais j'ai toujours vue ces problèmes :

La boite refuse d'embaucher la personne avec un salaire à la hauteur de ces compétence
Elle trouve 1000 excuse pour ne pas l'augmenter
La boite ne le fera pas monter en grade et/ou sa hiérarchie le minore, du coup il reste avec peu de responsabilité et manque de challenge

du coup les mecs compétents se casse et vont voir ailleurs. Reste les stagiaires, les personnes moins bonne dans l'équipe et les nouveaux arrivants.
J'ai constaté cela dans beaucoup d'entreprises dont surtout les plus grosses SS2I de France (Capgemini et Atos notamment)

Les entreprises doivent comprendre qu'un salarié expérimenter payer 50000e peut être plus bénéfique à l'entreprise qu'un junior payer 25000e
Que répondre favorablement à une augmentation peut être mieux que de devoir embaucher un nouveau.
Et enfin faire plus confiance à des salariés sur le terrains que des managers dans les centres décisionnel à Paris.
De ma vision d'une personne pas compétente, les personnes que je considère plus compétente que moi suive en tous cas le schéma que je décrit plus haut.

Et enfin je refuse d'etre vue comme une personne compétente car compétent en entreprise ne veut pas dire bien faire son travail mais rester tard le soir a faire fonctionner un bout de code jusqu’à 23H parfois.
j'ai l'informatique mais j'aime aussi rentrer chez moi le soir et le weekend et faire autre chose qui n'a rien a voir avec l'informatique.
Je suis pas un esclave, je suis payé pour faire 36H alors je fais juste mes 36H, si le projet foire iou a du retard je m'en moque je serais quand mème payer pareil à la fin du mois. Je rentre pas dans un stress extrême comme les personnes compétentes qui s'investisse a fond dans le projet de l'entreprise.
on donne aussi du travail bonus aux personnes compétentes : assurer le support auprès des clients pas content, ou encore faire des "voyages" pour rencontrer les clients (qui n'ont rien a voir avec des vacances), je préfère rentrer chez moi le soir encore une fois.

J'ai toujours vue dans mes expériences que une personne compétente rimait avec personne faisant aussi beaucoup d'heure (non payé)

Et a l'école même chose, pourquoi travailler dure quand un simple 10/20 de moyenne suffit pour avoir un doctorat ? J'ai toujours eux des moyennes entre 10/20 et 13/20 et je suis aujourd'hui aussi bien payé voir plus que des majors de promos qui bossait tous le temps.
si rien ne t'encourage a bosser forcément tu te contente du strict minimum aussi.

et aussi si aujourd'hui on me proposait de travailler plus pour gagner plus je refuserais.
j'ai déja un salaire confortable qui me permet de partir en voyage 4 fois dans l'année, j'ai une famille qui manque de rien, une maison, une voiture. J'ai pas besoin de plus.
Avec un meilleur salaire, au lieu de rouler en casserole je pourrais rouler dans une Tesla, bouffer du caviar tous les jours, avec une tv 8K HDR et une RTX 2080Ti pour jouer mais je suis déjà bien assez heureux avec ce que j'ai.

Je crains que tu te fourvoie dans ton analyse : Les gens les plus compétents sont fainéants (du moins en informatique), c'est même à ça qu'on les reconnait ! (tu peux trouver des citations de Bill Gates ou des fondateurs de Google si tu cherches).
En gros le compétant c'est le gars qui sait ce qu'il fait, comment il faut le faire ou ne pas le pas le faire, c'est celui qui te dit :
-"Mais pourquoi tu fais ça ? Fais plutôt ça, ça va plus vite et c'est plus simple"
Avant de s'en aller...

Les gens qui restent tard sont souvent ceux qui sont moins bons, ils n'arrivent pas à finir dans les temps car pas assez rapides ou alors veulent se faire bien voir (ou alors ils sont surchargés de travail, possible aussi) là où un bon se barrerait vite fait si on le surcharge et peut facilement retrouver ailleurs (conséquence logique connue maintenant lors des plans sociaux : Les premiers à partir sont les meilleurs, car accueillis à bras ouverts par les concurrents car...ils sont bons, justement).

Ps : Les gens les plus compétents sont les plus humbles sur leur compétence, tu peux regarder l'Effet Dunning-Kruger, qui porte sur le biais entre la compétence et son auto-évaluation de sa compétence : https://fr.wikipedia.org/wiki/Effet_Dunning-Kruger
La difficulté de l'auto-évaluation étant bien évidemment, en s'évaluant, de tenir compte de ce biais. On peut être bon et arrogant mais ça reste assez rare. Tu verras rarement un chercheur spécialisé dans un domaine de pointe dire des phrases autrement que "en théorie", "cela devrait se comporter comme...", "sur le principe le comportement sera..." avec bien souvent des "pas toujours" ou "pas tout-à-fait" quand tu poses une question
Maintenant compare avec un manager/politique/directeur, tu vas voir la différence : On ne leur demande pas d'être compétent, juste d'être convaincants

[tanaka59]

Bonsoir,

Les gens qui restent tard sont souvent ceux qui sont moins bons, ils n'arrivent pas à finir dans les temps car pas assez rapides ou alors veulent se faire bien voir (ou alors ils sont surchargés de travail, possible aussi) là où un bon se barrerait vite fait si on le surcharge et peut facilement retrouver ailleurs (conséquence logique connue maintenant lors des plans sociaux : Les premiers à partir sont les meilleurs, car accueillis à bras ouverts par les concurrents car...ils sont bons, justement).

Je ne conclue rien, je préfère te poser la question avant ...

Dois je en conclure que pour toi les CDD / Intérimaire sont par définition "moins bon" ?

Si c'est ce que tu penses ou essaye d'affirmer , je trouve que ce type de raisonnement est particulièrement gonflé et culotté !

Parce qu'on est CDD / Intérimaire et qu'on fait des "taches" et non plus un "travail" on est par définition des travailleurs de seconde catégorie / moins compétent ? Elle serait bien bonne celle la ...

[foetus]

Les gens qui restent tard sont souvent ceux qui sont moins bons, ils n'arrivent pas à finir dans les temps car pas assez rapides ou alors veulent se faire bien voir (ou alors ils sont surchargés de travail, possible aussi) là où un bon se barrerait vite fait si on le surcharge et peut facilement retrouver ailleurs (conséquence logique connue maintenant lors des plans sociaux : Les premiers à partir sont les meilleurs, car accueillis à bras ouverts par les concurrents car...ils sont bons, justement).

Il y a 1 cas à prendre en compte (mais je ne sais pas si c'est proche de la réalité ) : le gars qui travaille tard, c'est parce qu'il fait le travail de plusieurs personnes (au hasard, maquette, ergonomie, tests) et s'il charbonne c'est parce qu'il sait/ espère qu'après la mise en production il prendra du grade. Dans les petites boites (où l'équipe technique est très réduite et donc souvent elle n'a pas son mot à dire), il faut des fois s'imposer et c'est souvent avec des choses concrètes.
Cela peut être aussi le cas d'un junior qui veut peser dans l'équipe technique

[Invité]

un simple 10/20 de moyenne suffit pour avoir un doctorat

Peux-tu nous indiquer une étude ou un rapport qui montre ça ?

[Ekolamar]

Bonsoir,

Je ne conclue rien, je préfère te poser la question avant ...

Dois je en conclure que pour toi les CDD / Intérimaire sont par définition "moins bon" ?

Si c'est ce que tu penses ou essaye d'affirmer , je trouve que ce type de raisonnement est particulièrement gonflé et culotté !

Parce qu'on est CDD / Intérimaire et qu'on fait des "taches" et non plus un "travail" on est par définition des travailleurs de seconde catégorie / moins compétent ? Elle serait bien bonne celle la ...

Je ne vois pas le rapport avec la choucroute : Le sujet est la difficulté de recrutement dans les entreprises (ie : CDI). Mon point de vue est justement ce cas : Les CDI ou personnes étant en poste.

Evidemment qu'on ne peut juger le travail d'un intérimaire (sauf si il est éternellement reconduit) de la même façon, et c'est un peu le cas aussi d'un freelance.

Dans le cas d'un CDD/Intérim/Prestation, on prend quelqu'un pour réaliser une tâche/mission et qui est censé savoir le faire et s'en-aller. Il ne peut pas y avoir progression ni remise en cause des compétences/salaire par rapport à la boite cliente.
Et comme partout il y a des intérimaire ultra-bon (qui s'apparente à des freelances, certains sont intérimaire par choix, car ça rapporte plus à temps équivalent, il ne faut pas l'oublier) et des employés nuls, et inversement.

Il y a 1 cas à prendre en compte (mais je ne sais pas si c'est proche de la réalité ) : le gars qui travaille tard, c'est parce qu'il fait le travail de plusieurs personnes (au hasard, maquette, ergonomie, tests) et s'il charbonne c'est parce qu'il sait/ espère qu'après la mise en production il prendra du grade. Dans les petites boites (où l'équipe technique est très réduite et donc souvent elle n'a pas son mot à dire), il faut des fois s'imposer et c'est souvent avec des choses concrètes.
Cela peut être aussi le cas d'un junior qui veut peser dans l'équipe technique

C'est pas bête, mais ici nous sommes encore dans des gens qui montent en compétence (ou essayent de se faire (re)connaître). Ils n'ont donc pas encore "l'aura" leur permettant de s'imposer et qui ferait dire à leur chef "lui il faut que je le garde"...et surtout ils ne sont pas encore blasés du non-respect des compétences techniques des boites françaises, qui était mon propos initial, au bout de quelques années à ce rythme sans rien au-bout, soit tu changes de domaine, soit tu fais le minimum, soit tu deviens un mercenaire

[tanaka59]

Bonsoir,

Je ne vois pas le rapport avec la choucroute : Le sujet est la difficulté de recrutement dans les entreprises (ie : CDI). Mon point de vue est justement ce cas : Les CDI ou personnes étant en poste.

Un CDD est tout comme un CDI ... salarier du groupe (bien qu'en contrat temporaire).

Evidemment qu'on ne peut juger le travail d'un intérimaire (sauf si il est éternellement reconduit)

C'est la ou je tique avec ce type de réflexion. CDD/Intérim font dans 99% des cas un bout de projet/renfort/support/assistanat ...donc on va plutôt parler de tache ou de mission que de vrai travail. Résultat des courses un CDD/Intérim qui fait plusieurs de ces contrats de travail à la suite = tache + tache + tache + ... = tache (???) # travail (???)

Dans le cas d'un CDD/Intérim/Prestation, on prend quelqu'un pour réaliser une tâche/mission et qui est censé savoir le faire et s'en-aller. Il ne peut pas y avoir progression ni remise en cause des compétences/salaire par rapport à la boite cliente.
Et comme partout il y a des intérimaire ultra-bon (qui s'apparente à des freelances, certains sont intérimaire par choix, car ça rapporte plus à temps équivalent, il ne faut pas l'oublier) et des employés nuls, et inversement.

Et c'est la tout le problème ... Celui qui fait des "taches" pourquoi le juger ou perdre son temps avec ... il ne fait pas de "travail" ... mais des "taches" . Avec ce type de raisonnement CDD/Intérim sont vus comme des pestiférés ... Puis quand il y a une merde sur un projet , ceux sont les premiers à payer les pots cassés ...

Résultat un CDD/Intérim ou le contrat se passe mal chez A puis veut aller chez B. B peut se dire "boff , chez A il a eu un mauvais retour , il sait pas faire des taches donc ne sait pas travailler" > du coup le CDD/Intérim pourquoi devrait on l'embaucher ?

Ou comment simplement tenir le marché vers le bas par l'humiliation ... C'est déjà merde sur le marché du travail, avec ce type d'epais de damoclése pas étonnant que bon nombre , de personnes inscrites à pole emploi galère a trouver du taff ...

[calvaire]

Peux-tu nous indiquer une étude ou un rapport qui montre ça ?

disons que c'est mon expérience, je me suis contenter d'un diplôme d'ingénieur bac+5 et non d'un doctorat car il n'y a pas d'amélioration de salaire entre un bac +5 et un bac+8 mais j'aurais pu en faire 1 dans mon entreprise (mon maitre de stage en entreprise et a l'école n'était pas contre)
et a chaque semestre je me contentais juste d'avoir la moyenne en révisant juste 1 semaine avant les partiels.
Je vois pas l’intérêt de bosser tous les soirs et être major de promos...

Je crains que tu te fourvoie dans ton analyse : Les gens les plus compétents sont fainéants (du moins en informatique), c'est même à ça qu'on les reconnait ! (tu peux trouver des citations de Bill Gates ou des fondateurs de Google si tu cherches).
En gros le compétant c'est le gars qui sait ce qu'il fait, comment il faut le faire ou ne pas le pas le faire, c'est celui qui te dit :
-"Mais pourquoi tu fais ça ? Fais plutôt ça, ça va plus vite et c'est plus simple"
Avant de s'en aller...

Ps : Les gens les plus compétents sont les plus humbles sur leur compétence

bah c'est mon cas alors... je suis toujours a proposé les solutions les plus rapides.
Je me considérais comme un incompétent jusqu’à aujourd'hui car je propose des solutions rapide (mais pas les plus élégantes loin de la) mais les mecs que je considère comme compétent justement propose eux des solutions plus complexes largement plus longue a coder (et donc plus couteuse en argent/temps) mais plus propre en revanche que mes solutions. C'est eux évidement qui reste tard le soir par contre moi je me casse.
Et aussi leurs soliutions a la fin sa deviens des trucs incompréhensible et très difficile a débugger (le code est propre c'est juste l'architecture qui est vraiment très très compliqué et rend la fonctionnalité incompréhensible)
bon après que je sois effectivement compétent ou incompétent je m'en moque, j'ai mon salaire à la fin du mois et tant que ma hiérarchie ne me fais pas trop chier sa me conviens.

[Invité]

disons que c'est mon expérience, je me suis contenter d'un diplôme d'ingénieur bac+5 et non d'un doctorat car il n'y a pas d'amélioration de salaire entre un bac +5 et un bac+8 mais j'aurais pu en faire 1 dans mon entreprise (mon maitre de stage en entreprise et a l'école n'était pas contre)

Bien-sûr. Moi pareil, j'aurais pu être président de la république mais j'aime pas trop la vie parisienne alors j'ai laissé ma place à Macron.

[calvaire]

Bien-sûr. Moi pareil, j'aurais pu être président de la république mais j'aime pas trop la vie parisienne alors j'ai laissé ma place à Macron.

j'ai fais mon stage de fin d'étude dans une grosse boite dans une équipe de R&D et ils recrutaient des doctorats. J'avais demandé a mon tuteur d'entreprise et il m'a dit que c’était parfaitement possible.
Mais finalement j'ai préféré être embaucher dans cette entreprise en tant qu'ingénieur pour un salaire de plus de 2000€ plutôt que en tant que doctorat payer 1500€.
Il n'y a rien d'exceptionnel la dedans... et pour info je bosse pas a Paris et jamais j'irais dans cette ville qui pue le pot d'échappement et la pisse. Je préfère l'odeur de bouse de vache de la campagne dans ma vielle grange qui fait office de maison.

[walfrat]

disons que c'est mon expérience, je me suis contenter d'un diplôme d'ingénieur bac+5 et non d'un doctorat car il n'y a pas d'amélioration de salaire entre un bac +5 et un bac+8 mais j'aurais pu en faire 1 dans mon entreprise (mon maitre de stage en entreprise et a l'école n'était pas contre)
et a chaque semestre je me contentais juste d'avoir la moyenne en révisant juste 1 semaine avant les partiels.
Je vois pas l’intérêt de bosser tous les soirs et être major de promos...

Dans le même genre ici, puis bon le bachotage des examens des années d'avant, ça aide pas vraiment dans le monde professionel...

bah c'est mon cas alors... je suis toujours a proposé les solutions les plus rapides.
Je me considérais comme un incompétent jusqu’à aujourd'hui car je propose des solutions rapide (mais pas les plus élégantes loin de la) mais les mecs que je considère comme compétent justement propose eux des solutions plus complexes largement plus longue a coder (et donc plus couteuse en argent/temps) mais plus propre en revanche que mes solutions. C'est eux évidement qui reste tard le soir par contre moi je me casse.
Et aussi leurs soliutions a la fin sa deviens des trucs incompréhensible et très difficile a débugger (le code est propre c'est juste l'architecture qui est vraiment très très compliqué et rend la fonctionnalité incompréhensible)
bon après que je sois effectivement compétent ou incompétent je m'en moque, j'ai mon salaire à la fin du mois et tant que ma hiérarchie ne me fais pas trop chier sa me conviens.

Personnellement ça sens le framework maison ça et ce n'est pas nécessairement un bon signe.
Il y a un équilibre subtil entre faire la chose la plus rapide, et faire quelque chose de plus élaboré sans que ça devienne une usine à gaz.

A titre personnel j'évite les choses élaborés, car non seulement ce n'est pas si évident de faire un truc élaborés en restant simple mais aussi je sais que si je commence à utiliser quelque chose (au pif la gestion événementielle par exemple, ou de l'ORM) elle sera détourner par d'autres personne qui veulent juste que leur code marche rapidement. De fait tant que je n'en ai pas vraiment besoin j'en reste à un niveau qui fait le plus important et je fais déjà en sorte de bien l'utiliser.


Par exemple dans le cas de l'ORM, je met de l'Hibernate sans cache de niveau 2, et fait en sorte de ne pas avoir de problème de N+1 et je joue sur le type de jointure selon les cas. COmme ça je gagne déjà le plus gros avantages : ne pas écrire les INSERT/UPDATE/DELETE, ne pas écrire la plupart des requêtes de SELECT, à l'inverse à part le CASCADE DELETE, je faisais en sorte d'avoir des méthode de type "addChild/deleteChild" pour gérer cela tranquillement.

Oui on peut faire mieux que l'usage que j'en ai actuellement, mais :

• J'ai déjà vu un certain nombre d'applis ou cette base n'est même pas faite correctement
• Je ne suis pas confiant à le faire moi-même correctement sans me planter ou avec une méthode claire de développement qui ne laisse pas la place au doute de comment ça se passe en dessous
• Le confier à d'autres... mon expérience personnelle m'a rendu plutôt sceptique et je ne parle pas de reprendre mon code, juste de voir ce que d'autres ont pondus

[sergio_is_back]

Et aussi leurs soliutions a la fin sa deviens des trucs incompréhensible et très difficile a débugger (le code est propre c'est juste l'architecture qui est vraiment très très compliqué et rend la fonctionnalité incompréhensible)

Ta prose aussi est limite incompréhensible...
Sortir avec BAC+5 et pas savoir écrire une phrase sans fautes ça rejoint bien le sujet du post...
Console toi t'est pas le seul dans ce cas, comme l'a déjà signalé @SimonDecoline plus haut

[sergio_is_back]

A titre perosnnel j'évite les choses élaborés, car non seulement ce n'est pas si évident de faire un truc élaborés en restant simple mais aussi je sais que si je commence à utiliser quelque chose (au pif la gestion événementielle par exemple, ou de l'ORM) elle sera détourner par d'autres personne qui veulent juste que leur code marche rapidement.

Déjà pour faire des choses élaborés il faut partir de briques simples
Un bon développeur est capable de découper une tache compliquée en une séries de taches élémentaires beaucoup plus simples

De fait tant que je n'en ai pas vraiment besoin j'en reste à un niveau qui fait le plus important et je fais déjà en sorte de bien l'utiliser. Par exemple dans le cas de l'ORM, je met de l'Hibernate sans cache de niveau 2, et fait en sorte de ne pas avoir de problème de N+1 et je joue sur le type de jointure selon les cas. COmme ça je gagne déjà le plus gros avantages : ne pas écrire les INSERT/UPDATE/DELETE, ne pas écrire la plupart des requêtes de SELECT, à l'inverse à part le CASCADE DELETE, je faisais en sorte d'avoir des méthode de type "addChild/deleteChild" pour gérer cela tranquillement.

Quand on peut rester simple c'est mieux
Ne pas réinventer la roue si elle existe déjà c'est bien aussi
Mais :

Oui on peut faire mieux, mais :

• J'ai déjà vu un certain nombre d'applis ou cette base n'est même pas faite correctement
• Je ne suis pas confiant à le faire moi-même correctement sans me planter ou avec une méthode claire de développement qui ne laisse pas la place au doute de comment ça se passe en dessous
• Le confier à d'autres... mon expérience personnelle m'a rendu plutôt sceptique et je ne parle pas de reprendre mon code, juste de voir ce que d'autres ont pondus

Si tu n'est pas capable de faire une série de requêtes toi même sans être sur de ne pas te planter... Alors...

Quand à savoir ce qui ce passe en dessous, c'est le problème aujourd'hui... On a des développeurs qui utilisent un Framework, un Clicodrome (ça revient de plus en plus à la mode), et qui ne savent même pas comment fonctionne ce dernier... Du coup on reste sur du superficiel et on se retrouve avec des applis inutilisables, lentes, et parfois même difficiles à maintenir.
Tout ça dénote quand même un manque de culture informatique de base...

[walfrat]

Si tu n'est pas capable de faire une série de requêtes toi même sans être sur de ne pas te planter... Alors...

Quand à savoir ce qui ce passe en dessous, c'est le problème aujourd'hui... On a des développeurs qui utilisent un Framework, un Clicodrome (ça revient de plus en plus à la mode), et qui ne savent même pas comment fonctionne ce dernier... Du coup on reste sur du superficiel et on se retrouve avec des applis inutilisables, lentes, et parfois même difficiles à maintenir.
Tout ça dénote quand même un manque de culture informatique de base...

Tu as mal lu, comme j'ai dis, j'utilise les fonctions de base de mon ORM (Hibernate en l'occurence) en évitant par exemple le "piège" du N+1 requêtes propre aux ORM. Et je reproche que bien des projets le fasse déjà de travers, alors qu'il s'agit bien du tout début de ce qu'un ORM comme Hibernate peut faire.

Je n'ai aucun problème à faire une série de requête, en SQL en JDBC (avec curseur s'il le faut) ou en Hibernate ou du Criteria API avec filtrage des colonnes de résultats, jointures et sous-requêtes s'il le faut (sans partir sur des trucs délirant qu'il vaudrait mieux faire en SQL bruts quand même).

Je suis pas un pro mais je suis familier sur la chaîne des éléments impliqué par exemple sur un Select fait via du JPA

• Allocation d'une connexion du pool de connexion (si ce n'est pas encore le cas)
• Démarrage d'une transaction (si besoin et si pas de transaction active)
• Traduction du JPQL en HQL puis SQL par Hibernate (oui cette double étape existe)
• Envoie du SQL
• Traduction du SQL par le SGBDR
• Calcul du plan de requête : éventuellement déjà en cache ou alors calcul d'un nouveau plan usage des indexs quand c'est possible. (Cache mieux utiliser sur Prepared Statement plutôt que l'utilisation de valeurs brutes).
• Exécution du plan de la requête
• Récupération des résultats
• Mapping du résultat de la BDD en ORM + Mise en cache de niveau 1 (transacitonnel) en cas de transaction
• ...Autres opérations SQL plus tard
• COMMIT ou ROLLBACK en cas de transaction
• Libération de la connexion du pool (qui généralement reste maintenue un certain temps afin d'éviter la pénalité de la connexion TCP + Authentification SGBDR)

Quand j'ai parlé des choses sur lesquelles je n'étais pas sur car je n'avais pas compris entièrement comment Hibernate gèraient cela c'était des fonctions plus avancées, Par exemple :

• Gestion du cache de second niveau en Hibernate
• Gestion des cascades pour les mises à jours (merge sur plusieurs niveaux)
• ...

Ces éléments là peuvent être gérés avec de l'Hibernate, sauf que c'est déjà un autre niveau de connaissance de la technologie et qu'au moment où j'avais regardé, je n'étais pas entièrement confiant sur le sujet ni même sur le fait d'en avoir vraiment besoin.

Ce que tu dis sur le fait que des développeurs n'ai absolument aucune idée de ce que ce passe sous le capot n'est pas sans raison, mais j'ai bien peur que tu as sauté un peu trop vite sur mon post.

[Invité]

j'ai fais mon stage de fin d'étude dans une grosse boite dans une équipe de R&D et ils recrutaient des doctorats. J'avais demandé a mon tuteur d'entreprise et il m'a dit que c’était parfaitement possible.

Oui voilà, "ton tuteur t'a dit que c'était possible". Sauf que tu ne l'as pas fait et que tu n'as aucune étude sérieuse indiquant qu'un "simple 10/20 de moyenne suffit pour avoir un doctorat". Et pour avoir travaillé quelques années dans le milieu, ce n'est pas du tout ce que j'ai constaté.

[L33tige]

Tu as mal lu, comme j'ai dis, j'utilise les fonctions de base de mon ORM (Hibernate en l'occurence) en évitant par exemple le "piège" du N+1 requêtes propre aux ORM. Et je reproche que bien des projets le fasse déjà de travers, alors qu'il s'agit bien du tout début de ce qu'un ORM comme Hibernate peut faire.

Je n'ai aucun problème à faire une série de requête, en SQL en JDBC (avec curseur s'il le faut) ou en Hibernate ou du Criteria API avec filtrage des colonnes de résultats, jointures et sous-requêtes s'il le faut (sans partir sur des trucs délirant qu'il vaudrait mieux faire en SQL bruts quand même).

Je suis pas un pro mais je suis familier sur la chaîne des éléments impliqué par exemple sur un Select fait via du JPA

• Allocation d'une connexion du pool de connexion (si ce n'est pas encore le cas)
• Démarrage d'une transaction (si besoin et si pas de transaction active)
• Traduction du JPQL en HQL puis SQL par Hibernate (oui cette double étape existe)
• Envoie du SQL
• Traduction du SQL par le SGBDR
• Calcul du plan de requête : éventuellement déjà en cache ou alors calcul d'un nouveau plan usage des indexs quand c'est possible. (Cache mieux utiliser sur Prepared Statement plutôt que l'utilisation de valeurs brutes).
• Exécution du plan de la requête
• Récupération des résultats
• Mapping du résultat de la BDD en ORM + Mise en cache de niveau 1 (transacitonnel) en cas de transaction
• ...Autres opérations SQL plus tard
• COMMIT ou ROLLBACK en cas de transaction
• Libération de la connexion du pool (qui généralement reste maintenue un certain temps afin d'éviter la pénalité de la connexion TCP + Authentification SGBDR)

Quand j'ai parlé des choses sur lesquelles je n'étais pas sur car je n'avais pas compris entièrement comment Hibernate gèraient cela c'était des fonctions plus avancées, Par exemple :

• Gestion du cache de second niveau en Hibernate
• Gestion des cascades pour les mises à jours (merge sur plusieurs niveaux)
• ...

Ces éléments là peuvent être gérés avec de l'Hibernate, sauf que c'est déjà un autre niveau de connaissance de la technologie et qu'au moment où j'avais regardé, je n'étais pas entièrement confiant sur le sujet ni même sur le fait d'en avoir vraiment besoin.

Ce que tu dis sur le fait que des développeurs n'ai absolument aucune idée de ce que ce passe sous le capot n'est pas sans raison, mais j'ai bien peur que tu as sauté un peu trop vite sur mon post.

Surtout que même si on mets de coté des informations, ça permet d'en faire abstraction afin de e concentrer sur d'autres problématiques, ça serait comme de dire que les langages de plus haut niveau que le siens c'est le mal, s'il fallait tout faire à la main on serait pas sorti du jus de canne berge.

[calvaire]

Oui voilà, "ton tuteur t'a dit que c'était possible". Sauf que tu ne l'as pas fait et que tu n'as aucune étude sérieuse indiquant qu'un "simple 10/20 de moyenne suffit pour avoir un doctorat". Et pour avoir travaillé quelques années dans le milieu, ce n'est pas du tout ce que j'ai constaté.

bon si tu préfère, un simple 10/20 suffit a avoir un poste d'ingénieur voila, j'en suis la preuve vivante.
peut être que je suis une exception.

[sergio_is_back]

Quand j'ai parlé des choses sur lesquelles je n'étais pas sur car je n'avais pas compris entièrement comment Hibernate gèraient cela c'était des fonctions plus avancées, Par exemple :

• Gestion du cache de second niveau en Hibernate
• Gestion des cascades pour les mises à jours (merge sur plusieurs niveaux)
• ...

Ces éléments là peuvent être gérés avec de l'Hibernate, sauf que c'est déjà un autre niveau de connaissance de la technologie et qu'au moment où j'avais regardé, je n'étais pas entièrement confiant sur le sujet ni même sur le fait d'en avoir vraiment besoin.

Ce que tu dis sur le fait que des développeurs n'ai absolument aucune idée de ce que ce passe sous le capot n'est pas sans raison, mais j'ai bien peur que tu as sauté un peu trop vite sur mon post.

Je n'avais sans doute pas exactement compris le sens de ton propos il me semble... Ce n'était cependant pas très clair d'un prime abord... Mais tu as bien fait de me reprendre. Désolé

[Invité]

bon si tu préfère, un simple 10/20 suffit a avoir un poste d'ingénieur voila, j'en suis la preuve vivante.
peut être que je suis une exception.

Bah c'est pas que je préfère, c'est juste que l'information n'est pas "un simple 10/20 de moyenne suffit pour avoir un doctorat" mais "un simple 10/20 de moyenne à une école d'ingénieur suffit pour avoir un diplôme d'ingénieur". C'est pas vraiment la même chose.

[disedorgue]

bon si tu préfère, un simple 10/20 suffit a avoir un poste d'ingénieur voila, j'en suis la preuve vivante.
peut être que je suis une exception.

Bah, moi, je dis qu'il faut tout de même un sacré travail sur soi pour ce prendre la tête à n'avoir que 10/20 si sans effort on peut avoir plus...