« Honte à ceux qui promettent aux gens qu'ils vont devenir dev pro en quelques semaines »

Citation:

---

Envoyé par Mat.M

oui mais quand on travaille comme chirurgien on n' a pas le droit à l'erreur ; la moindre action est calibrée sinon c'est l'errreur médicale...

---

Juste pour dire que quelques sinon beaucoup d'informaticiens n'ont pas droit à l'erreur, que des vies peuvent en dépendre de la même façon que pour un chirurgien, que les enjeux peuvent parfois être colossaux.
Et on peut vraiment penser à plein de domaines, que ce soit des outils de monitoring pour la santé, des logiciels de pilotage de robots ou de machines telles que des voitures, des outils de trading automatisés...

Les erreurs ne se voient pas forcément à la compilation et le bug que tu corrigeras sera peut-être au prix de ...

Pour relativiser bien sur, perso je ne suis guère dans ce cas. Mais je stocke de l'info confidentielle, et les enjeux financiers ou concurrentiels peuvent être importants.

Se cache derrière à mon sens des obligations de moyen ou de résultat : je crois qu'il est plus admis une erreur de chirurgien qui n'a pas réellement d'obligation de résultat : https://www.vocabulaire-medical.fr/e...on-de-resultat
Alors que l'informaticien a des obligations de résultats : cahier des charges, recettes, garanties, maintenances répondent à cette obligation il me semble

Citation:

---

Envoyé par xav67

Apprendre un langage c'est comprendre sa manière de fonctionner et ses spécificités, ça requiert bien plus que quelques heures.
.

---

1-comme je l'écris précédemment, quel est le sujet de la discorde ? Merci d'être précis dans sa réponse et de faire preuve de clareté car je ne comprends pas vraiment la finalité du débat
2-ehhh je n'ai jamais affirmé le contraire...peut-être faudrait-il comprendre les messages que j'écris.

Citation:

---

Envoyé par xav67

Si apprendre un langage se limite à savoir faire un if, déclarer une variable et faire une boucle dans ce cas n'importe qui peut se prétendre expert dans n'importe quel langage.

---

Je n'ai jamais affirmé le contraire !
D'accord mais un expert dans un langage pour moi ça ne veut rien dire.
Un langage informatique est un moyen pas une finalité.
Si la conceptualisation en amont d'un programme informatique est défaillante eh bien le projet va connaître un échec

Citation:

---

Envoyé par fredoche

Juste pour dire que quelques sinon beaucoup d'informaticiens n'ont pas droit à l'erreur, que des vies peuvent en dépendre de la même façon que pour un chirurgien, que les enjeux peuvent parfois être colossaux.

---

en quoi des informaticiens n'ont pas le droit à l'erreur ? Les tests ça sert précisément à ça je suis parfaitement placé pour le savoir car j'ai travaillé sur un logiciel médical utilisé en salle d'opération

Citation:

---

Envoyé par fredoche

Les erreurs ne se voient pas forcément à la compilation et le bug que tu corrigeras sera peut-être au prix de ...

---

il faut un peu de bon sens : sur un projet informatique ( qui est bien fait ) il y a des phases de test qui sont destinées à cela, non ?

Citation:

---

Envoyé par Pill_S

Complètement pas d'accord. Analogie rapide: faut pas faire 6 ans d'études pour préscrire des antibios (tâche principale de 90% des médecins).

---

1- quel est le sujet du désaccord ? Tu peux l'exprimer de manière précise s'il te plait car là je ne comprends vraiment pas
2-je n'ai jamais parlé de médecins qui prescivent des antibios j'ai parlé de chirurgiens notamment qui réalisent des opérations très délicates, il faudrait faire preuve de nuance et de discernement peut-être

Citation:

---

Envoyé par Pill_S

On conçoit des choses très compliquées.
Quand tu connaitras tous les frameworks et outils utiles

---

des choses compliquées ?
J'ai plus de 15 ans d'expérience en développement informatique et des choses compliquées je n'en ai pas vue beaucoup ou alors j'ai pas fait les bonnes entreprises
Ensuite l'utilisation d'un framework c'est totalement compris de travers un framework c'est fait essentiellement pour simplifier la vie...et donc ne pas réinventer la roue

Citation:

---

Envoyé par Pill_S

Si je t'explique seulement ce qu'est une boucle tu sers à rien en entreprise. ,

---

et si tu m'expliques comment utiliser tel ou tel framework ça sera la même chose et tu ne serviras à rien non plus car un indien à Bangalore ou un Ukrainien le fera aussi bien.
Sauf à travailler dans la Recherche et Développement ce qui est quelque chose à part.
Désolé d'être brutal et direct mais c'est la vérité :mrgreen:
Le conseil que je peux donner c'est de surveiller vos arrières, à bon entendeur ! :mrgreen:

Citation:

---

Envoyé par Pill_S

Un expert c'est ça: quelqu'un capable d'expertise au sens large. Pas quelqu'un capable d'écrire une boucle quand on lui dit d'écrire une boucle.

---

comment peut-on parler d'expertise alors que les outils utilisés dans un projet informatique d'une part ne sont pas développés en Europe ( donc majoritairement américains ) et qui constituent économiquement des valeurs ajoutées intermédiaires ?

Citation:

---

Envoyé par Mat.M

en quoi des informaticiens n'ont pas le droit à l'erreur ? Les tests ça sert précisément à ça je suis parfaitement placé pour le savoir car j'ai travaillé sur un logiciel médical utilisé en salle d'opération

---

Je te l'ai expliqué et ça tient à l'obligation de moyens ou de résultats. Quand tu paies tes assurances professionnelles, tout cela peut être évalué, que tu sois informaticien ou éditeur de logiciel ou constructeur de n'importe quelle machine avec du soft à l'intérieur.
Si quelque chose merde toi informaticien développeur, comme l'admin sys ou le DBA... peuvent être directement responsable de cette erreur. Tu risques ta place sinon parfois la survie de l'entreprise. Un chirurgien en cas d'erreur même manifeste ne sera pas forcément tenu responsable si tout au moins l'obligation de moyen a été respectée. L'erreur est admise pour ce type d'activité.

L'obligation de résultat c'est une constante dans le monde professionnel, que ce soit pour la réparation automobile, le bâtiment, nombre de services à la personne, nombre de services du tertiaire. C'est plutôt l'obligation de moyen qui est une exception.

Citation:

---

Envoyé par Mat.M

il faut un peu de bon sens : sur un projet informatique ( qui est bien fait ) il y a des phases de test qui sont destinées à cela, non ?

---

Oui
Le bon sens c'est aussi de ne pas trop vivre avec des certitudes, sans vouloir t'offenser.
La compilation, les tests de tous types te donnent vraiment toutes certitudes dans tous les contextes ?
Des informaticiens ne sont pas seulement ceux qui conçoivent les logiciels, il ne faut pas perdre de vue tout ce qui tient à l'exploitation, et au facteur humain, car ces informaticiens ne sont pas des robots. Et des conneries ça arrive tous les jours, voir Tchernobyl qui serait à la base une erreur humaine, pas d'un informaticien pour le coup :(

Enfin je ne sais pas je n'ai jamais eu en propal un SLA à 100% tu vois ?

On se donne des tas de garanties, redondances, tests, procédures bétons, mais on est jamais qu'un rouage du système non ?

Il y a une liste CVE qui contient plus de 100 000 entrées si je ne m'abuse

T'as des histoires de Spectre et Meltdown qui concerne l'informatique sur tout le globe

Il y a bien des informaticiens derrière tout ça ? Il y a bien des enjeux de différents types ?

Juste pour l’anecdote, sur un projet de sécurisation, on devait crypter des données dans une BDD sans interrompre le service (sinon, c'est pas marrant :) ), le dev qui possède une connaissance certaine du langage employé (ils sont tagués experts) pour ce projet, nous a pondu un code qui mettait environ trois jours pour à peu près 100 millions d'entrées dans la base.
Pour les besoins d'avoir une base de bench avec le même nombre d'entrées que celle de la production et sans connaissance du dev en cours, j'avais développé (si on peut dire, car je ne suis pas développeur), un petit script shell/perl d'une quarantaine de ligne qui faisait le même boulot mais en 3 heures.

Ce qui est marrant dans l'histoire, c'est que je me suis presque fait engueulé par ma direction car il n'ont eu connaissance de ce script "légèrement plus rapide" que le dev officiel qu'après avoir passé tout les bans de tests.

Et je ne dénigre pas le dev en question, car ici il a réellement une connaissance approfondi du langage qu'il utilise.

Citation:

---

Envoyé par Pill_S

Quand tu connaitras tous les frameworks et outils utiles, leurs avantages et leurs limitations, que tu sauras t'intégrer et t'interfacer avec le reste d'un SI avec tout un tas de protocoles nouveau ou ancien, standards ou exotiques, tout en garantissant l'intégrité des données manipulées, que tu sauras diagnostiquer efficacement les problèmes et tout un tas d'autres détails, tu commenceras vaguement à servir à quelque chose..

---

C'est de la branlette de mec planqué en SSII qui n'a pris aucun risque de faire son métier ailleurs, dans d'autres conditions, d'autres contextes. Quand tu débarqueras dans une équipe où il n'y a aucun moyen technique, qu'il faut développer avec tes propres outils, avec la même pression et des délais des merdes, et que dès que tu parles frameworks et méthodes, on te regarde comme un Hobbit qui doit bien se prendre la tête dans la vie pour réussir à produire une page web, on en reparlera. Et quand malgré cela, ton projet tourne nickel depuis 15 ans chez le client, ben en fin de compte, tu te dis que les mecs qui nous bassinent avec leurs méthodes, leurs standards et leurs outils appris en école, comme-ci c'était la seule et unique façon propre de coder parce que c'est la seule qu'ils connaissent, tu leur ris au nez, et tu les plains. Car, ils doivent pas s'éclater dans leur job.

zecreator, par curiosité, quelles « méthodes » de développement considères-tu comme inadaptées à ton contexte alors qu'elles sont considérées comme « la seule et unique façon propre de coder » par certains ? Je pose la question pour les méthodes, pas pour les outils et frameworks.

Dans mon contexte, y a pas 36 méthodes, tu prends les besoins du client, tu définis un planning de dev avec les phases de livraisons. Tu valides les specs techniques avec leur DSI, tu te retrousses les manches, et tu codes.

Y a pas de bonnes ou mauvaises méthodes à partir du moment où le client est satisfait et que le produit fonctionne tel que prévu.

Ce qui m'agace ceux sont les développeurs qui pensent que si on développe autrement que les standards établies par les grosses firmes et les SSII, on ne mérite pas le titre de développeur. Genre, ils sont au-dessus de la pile. C'est l'élite. Alors que s'ils devaient développer sans frameworks, ils en seraient incapables.

Y a pas que les SSII qui ont le monopole des métiers de l'informatique.

Citation:

---

Envoyé par zecreator

(.../...)Y a pas de bonnes ou mauvaises méthodes à partir du moment où le client est satisfait et que le produit fonctionne tel que prévu. (.../...)

---

Dans mes bras!!!!!

Bon, je rajouterais "qui est maintenable par autre que son créateur", quand même. Dans le temps, j'avais une petite réputation de savoir dépatouiller des codes illisibles, mais il y en a quand même quelques uns sur lesquels je me suis brisé les dents. J'aurais bien pendu leurs auteurs par les tripes, même si dans le temps, ça avait marché comme demandé. Mais sinon, amen. Objet, procédural, fonctionnel, natif ou framework, ce n'est pas le problème. Comme le dit Joel Spolsky, ce qui compte, c'est d'avoir des gens de qualité(et de ne pas les empêcher de bosser).

Citation:

---

Envoyé par el_slapper

Dans mes bras!!!!!

Bon, je rajouterais "qui est maintenable par autre que son créateur", quand même. Dans le temps, j'avais une petite réputation de savoir dépatouiller des codes illisibles, mais il y en a quand même quelques uns sur lesquels je me suis brisé les dents. J'aurais bien pendu leurs auteurs par les tripes, même si dans le temps, ça avait marché comme demandé. Mais sinon, amen. Objet, procédural, fonctionnel, natif ou framework, ce n'est pas le problème. Comme le dit Joel Spolsky, ce qui compte, c'est d'avoir des gens de qualité(et de ne pas les empêcher de bosser).

---

En 20 ans de carrière de développeur, j'ai bossé pour différents projets, sur différentes technos, et pour des clients très divers (de la TPE jusqu'au client du CAC 40). J'ai eu tous les cas de figures possibles en termes de projets IT, et j'ai toujours bossé de la même manière. J'ai rencontré des passionnés du code et des psycho-rigides de la procédure et des méthodes. J'ai bossé pour des petits éditeurs comme pour des sociétés de services qui affichaient fièrement leurs milliards de CA en tête de leur page web.

J'ai vu des jeunots passionnés par le dev, quitter le métier parce que des mecs venus d'école "reconnues" lui imposaient des manières de coder qui faisaient de lui un robot qui n'apprenait plus trien. J'ai vu des idiots ne rien comprendre au code et à la logique de développement, devenir Directeur Tech parce qu'ils ont sû "manipuler" leur monde et avaient le réseau qu'il allait avec.

Je ne sais pas si mes méthodes de développement sont bonnes ou mauvaises, juste que depuis 20 ans que je les utilises, y a aucun de mes clients, de mes employeurs ou des mes collaborateurs qui est venu se plaindre. Et je suis fier de voir que, malgré mon parcours atypique, étant à la base autodidacte, beaucoup d emes projets développés il y a 15 ans, sont toujours utilisés aujourd'hui, et que d'autres développeurs n'ont aucun problème à les maintenir et à les faire évoluer.

Faut arrêter de croire qu'il n'y a QU'UNE seule et bonne méthode de développement. Tous les développeurs ne sont pas en SSII. Et ce n'est pas parce qu'en SSII on vous impose une manière de faire, que c'est la manière absolue de coder.

J'ajouterai que les vrais passionnés du développement ne s'enferment pas dans des conformismes, et prennent des risques. Restés en SSII pour toujours faire les mêmes types de projets, avec les mêmes méthodes et les mêmes technos, j'appelle cela "se planquer".

Le genre de mec qui en cas de guerre, vont plutôt rester au QG, plutôt que de venir sur le terrain.

Citation:

---

Envoyé par zecreator

J'ajouterai que les vrais passionnés du développement ne s'enferment pas dans des conformismes, et prennent des risques. Restés en SSII pour toujours faire les mêmes types de projets, avec les mêmes méthodes et les mêmes technos, j'appelle cela "se planquer".

Le genre de mec qui en cas de guerre, vont plutôt rester au QG, plutôt que de venir sur le terrain.

---

Ce qui me rappelle un des rares entretiens que j'ai planté(je suis plutôt bon dans l'exercice). Le gars me demande de décrire un projet à succès que j'ai mené. Je parle d'un succès, un batch qui tourne toujours nickel des années après.
"_Et quelle est votre méthode?
_Je n'ai pas de méthode préférentielle, je m'adapte. Dans ce cas précis, les circonstances m'ont poussé à....
_Vous n'avez pas de méthode? Et vous voulez que je vous fasse confiance???"

Évidemment, je me suis retrouvé le bec dans l'eau. La méthode que j'avais appliqué dans ce cas(un comparateur logiciel pour vérifier sur un mois de production tous les écarts de valeurs fonctionnelles entre l'ancienne chaine et la nouvelle) ne marchait que parce qu'il s'agissait d'une refonte iso fonctionnelle(seule différence, les 31 Juin et le 31 Septembre était désormais bannis, détail que j'ai inclus dans mon comparateur logiciel de test). Pour le projet d'après, je n'avais pas du tout fait ça, c'était une refonte aussi, mais avec à peu près tout qui changeait au niveau du détail. Donc les résultats qui étaient bons dans l'ancienne chaine étaient faux dans la nouvelle. Donc j'avais fait autrement. Et ça, c'était la preuve que j'étais un minable incapable de structurer son travail.

Bien heureux de m'être fait bouler, sur le coup. :aie:

Comment le conformisme des SSII à tué la passion et le côté créatif du développeur. Les mecs en SSII ne rendent même plus compte qu'ils sont devenus de simples outils de production.

Citation:

---

Envoyé par fredoche

Oui
Le bon sens c'est aussi de ne pas trop vivre avec des certitudes, sans vouloir t'offenser.

---

je n'ai pas de certitudes en particulier... la chose toute bête que je voulais affirmer c'est qu'en informatique il n'y a pas de problèmes il n'y a que des solutions :mrgreen:
Pour ce qui est d'avoir des certitudes il faut en avoir obligatoirement je dirais même que les certitudes conduisent obligatoirement à l'objectivité ( bref de mener à bien un projet informatique ).

L'esotérisme ça n'existe pas en informatique à mon sens toute chose,tout object conceptuel ( par exemple une classe d'objet en Java ) doit être défini ou alors je n'ai rien compris à l'informatique si c'est le cas il faut me le préciser.
Puisque l'informatique par essence même n'est que pure logique

Citation:

---

Envoyé par fredoche

La compilation, les tests de tous types te donnent vraiment toutes certitudes dans tous les contextes ?

---

se poser la question quant à des certitudes à avoir c'est que le traitement informatique ne produit pas des vérités "vraies",bref c'est avoir des doutes
Mais je pense que c'est autre sujet :D

Citation:

---

Envoyé par zecreator

Comment le conformisme des SSII à tué la passion et le côté créatif du développeur. Les mecs en SSII ne rendent même plus compte qu'ils sont devenus de simples outils de production.

---

bien d'accord cependant pour se faire "l'avocat du diable" les SSII sont soumise à rentabilité ( économique) donc exprimer et cultiver sa passion et sa créativité me parait parfois incompatible.
Là aussi ça peut-être un autre débat à lancer

Citation:

---

Envoyé par Mat.M

pour se faire "l'avocat du diable" les SSII sont soumise à rentabilité ( économique) donc exprimer et cultiver sa passion et sa créativité me parait parfois incompatible.
Là aussi ça peut-être un autre débat à lancer

---

C'est effectivement une autre débat. Je soulignais juste que ce n'est pas parce que les SSII sont les premiers employeurs en informatiques, qu'il faut croire que leurs méthodes devraient être les seules utilisables. On peut réussir un projet IT durable, autrement.

Il faut penser que beaucoup d'autres développeurs travaillent très bien dans d'autres structures, avec LEURS méthodes, et sont très heureux. N'en déplaise aux conformistes.

zecreator, tu critiques beaucoup le fait que certains développeurs soient formatés sur leur manière de travailler, mais tu ne donnes aucun exemple précis. Quels exemples as-tu en tête ?
Développement agile ? Programmation orientée objet ? TDD ? Jamais de break ou continue dans une boucle ?

Citation:

---

Envoyé par Pyramidev

zecreator, tu critiques beaucoup le fait que certains développeurs soient formatés sur leur manière de travailler, mais tu ne donnes aucun exemple précis. Quels exemples as-tu en tête ?
Développement agile ? Programmation orientée objet ? TDD ? Jamais de break ou continue dans une boucle ?

---

Je ne critiques pas leur manière de travailler, juste leur certitude que leurs méthodes et leurs outils soient les seuls capables de produire des projets IT fiables et durables. Et cette imposition systématique de leur propre vérité parce que c'est la seule qu'ils connaissent.

Citation:

---

Envoyé par zecreator

Je ne critiques pas leur manière de travailler, juste leur certitude que leurs méthodes et leurs outils soient les seuls capables de produire des projets IT fiables et durables. Et cette imposition systématique de leur propre vérité parce que c'est la seule qu'ils connaissent.

---

Je pense quand même que tu fais fausse route sur la raison initiale. Le gars qui m'a considéré comme nul parce-que je n'avais pas de méthode préférentielle était un client final. Les SSII ne font que servir la soupe qu'on leur achète. Les clients veulent des méthodes fiables, éprouvées, et qui fonctionnent à tous les coups, alors les SSII leur vendent ce qui s'en rapproche le plus(à savoir une illusion).

Je l'ai déjà dit sur d'autres fils, mais le problème fondamental des SSII en France, c'est le client. Client qui (1) a la pétoche de se planter, et (2) n'y connait rien, et (3) va plaquer de fausses équivalences provenant du bâtiment(ou déjà la réalité est bien plus compliquée que ce qu'on veut bien croire, il ne suffit pas de suivre le plan pour finir un bâtiment). Si le client savait ce qu'il faisait, il agirait tout autrement. Mais il est ignorant, et pense tout savoir. Sa croyance erronée la plus dévastatrice est "l'informatique, ce n'est que de la technique". Or la technique n'est que le support de notre véritable métier : formaliser des suites de décisions. Mais une autre croyance est dévastatrice aussi, et c'est celle qui nous intéresse sur le sujet des méthodes : "il suffit de suivre le petit manuel pour réussir"(ce qui serait pertinent si la problématique était purement technique...et encore).

Donc, ils vont signer des contrats seulement à des gens qui les rassurent par leurs certitudes concernant leurs méthodes qui conviennent tout le temps. Pour être le plus convaincant, il faut généralement être soi-même convaincu. Donc ceux qui gagnent, sont ceux qui ont la certitude de détenir la vérité sur la méthode ultime. CQFD.

Alors là, je suis tout à fait d'accord avec tes propos, c'est exactement ça :ccool:

Et il ne faut surtout pas hésiter à remettre à leur place, les gens qui le disent (je parle des idées dévastatrices), en leur faisant bien comprendre que si c'était vraiment le cas, ils n'auraient pas besoin de gens comme nous.

Citation:

---

Envoyé par el_slapper

Je pense quand même que tu fais fausse route sur la raison initiale. Le gars qui m'a considéré comme nul parce-que je n'avais pas de méthode préférentielle était un client final. Les SSII ne font que servir la soupe qu'on leur achète. Les clients veulent des méthodes fiables, éprouvées, et qui fonctionnent à tous les coups, alors les SSII leur vendent ce qui s'en rapproche le plus(à savoir une illusion).

Je l'ai déjà dit sur d'autres fils, mais le problème fondamental des SSII en France, c'est le client. Client qui (1) a la pétoche de se planter, et (2) n'y connait rien, et (3) va plaquer de fausses équivalences provenant du bâtiment(ou déjà la réalité est bien plus compliquée que ce qu'on veut bien croire, il ne suffit pas de suivre le plan pour finir un bâtiment). Si le client savait ce qu'il faisait, il agirait tout autrement. Mais il est ignorant, et pense tout savoir. Sa croyance erronée la plus dévastatrice est "l'informatique, ce n'est que de la technique". Or la technique n'est que le support de notre véritable métier : formaliser des suites de décisions. Mais une autre croyance est dévastatrice aussi, et c'est celle qui nous intéresse sur le sujet des méthodes : "il suffit de suivre le petit manuel pour réussir"(ce qui serait pertinent si la problématique était purement technique...et encore).

Donc, ils vont signer des contrats seulement à des gens qui les rassurent par leurs certitudes concernant leurs méthodes qui conviennent tout le temps. Pour être le plus convaincant, il faut généralement être soi-même convaincu. Donc ceux qui gagnent, sont ceux qui ont la certitude de détenir la vérité sur la méthode ultime. CQFD.

---

Je ne suis pas tout à fait d'accord. Oui, au début ceux sont les clients qui ont poussé à "standardiser" les méthodes de développement. Mais par la suite, ces méthodes sont devenues les seules acceptables sur le marché du travail car les SSII, étant les premiers employés dans l'informatique, ont fini par ne plus accepter que ça. Et cela a eu un effet "dévastateur" sur le métier de développeur et son apprentissage, car toutes les formations en développement se basent sur ces méthodes, considérant sans doute qu'il n'y aura pas de boulot de développement ailleurs qu'en SSII et que l'avenir d'un développeur est là-bas.

Tous ces facteurs ont fait que le développeur est devenu un outil de production, ne se différenciant pas d'un autre développeur dans sa manière de travailler. On a perdu la passion du métier et sa créativité. Il existe un tas de développeurs talentueux qui ne peuvent plus bosser autrement qu'en indépendant, juste parce qu'ils ne rentrent pas dans le moule des SSII (et donc des clients), et ne trouvent pas de boulot.

J'ai jamais bossé en SSII, par choix, car j'ai toujours refusé d'être figé dans telle ou telle techno, ou telle ou telle méthode. J'ai besoin d'avoir un espace de recherche, d'expérimentation et de création. Et je suis heureux de faire ce choix depuis 20 ans.