dégage sale programmeur

[e-kiwi]

uh uh uh

http://codingly.com/2008/12/29/degage-sale-programmeur/

[j-mi]

ça me touche cet article

<< C’est une personne qui ne peut pas se reposer éternellement sur ses acquis.
C’est aussi une personne qui doit produire, et qui peut difficilement tricher.
Programmer est un métier à la fois compliqué et passionnant, dont on peut même penser qu’il demande du talent.
En fait, c’est probablement l’un des métiers les plus exigeants et intelligents qui soient. >>

[ortolojf]

A mon avis...

...Ce point de vue peut-être typiquement Français de la nullité du "codeur", tient peut-être au rebut viscéral que déclenche, chez les responsables des entreprises, l'attachement aux détails d'implémentation ( de programmes ), avec son côté "bêtement physique", c'est-à-dire "vulgaire".

En d'autres termes, les responsables sont naturellement attachés à "l'abstraction en tant que telle", qui leur paraît être le substrat de la supériorité de leur propre métier de responsable...

A mon avis, celà part de trois fausses évaluations de leur part :

- Les processus intellectuels à l'oeuvre lors d'un codage bien fait par un programmeur, n'ont enréalité, rien à envier aux abstractions pures des projets haut de gamme, qu'ils soient Merise, Programmation Orientée Objets ( me souviens plus du nom ), et autres dossiers technico-financiers d'encadrement, dont l'efficacité prévisionnelle, est toujours discutable.

- La volonté de leur part, d'avoir plus de visibilité sur l'ensemble des projets Informatique, associée à leur ignorance de la partie purement "codage", trop vite assimitée par eux, à de l'exécutif pur. Dans cet optique ( et la Programmation orientée Objet donne également cette illusion de la possibilité de gestion en amont du code, au niveau de la conception ), leur but serait de raccourcir au maximum, la distance entre les feuilles de l'arbre du projet Informatique, et sa racine, qui évidemment ne peut être que le Grand Manager. Voir mon commentaire ci-dessous.

- L'ignorance pure et simple des Managers, par rapport à la fonction "codage pur", Managers pour qui le mépris pour cette fonction, est aussi un justificatif de leur propre utilité, à eux Managers.

Mon commentaire :

Le concept même de "Cycles en V" présuppose, que la procédure souhaitable dans un projet Informatique, n'est pas une approche purement "top-down", où les managers manageraient, et les subordonnés obéiraient ( chacuns à leur place dans la hiérarchie ) à leur supérieurs immédiats. Cà, cà ne marche pas.

Ce concept de "Cycles en V" présuppose que l'impulsion est également donnée par la base vers le haut de l'échelle, et que donc il faut qu'il y ait un échange ( le plus riche possible sur le plan informationnel technique ) entre les différents étages de la hiérarchie.

Dans la conception jacobine de l'entreprise actuellement en oeuvre en France, la possibilité qu'un telle attitude soit adoptée dans une entreprise, dépend surtout du profil psychologique des "Chefs", et aussi de l'esprit général de l'entreprise, obtenu probablement par l'expérience.

En ce qui me concerne, j'ai eu à souffrir d'un problème similaire, en 1983, quand j'ai travaillé pour une boite d'Analyse Biologique Médicale...

Petite SARL, le Directeur me dit à mon entrée :

"Faites-moi une Base de données Tri QuickSort".

Je dis : "Je pense qu'il faudrait faire deux fichiers".

Il me dis : "allez-y" ou qqchose dans le genre.

La matériel était un micro-ordinateur PET CBM Commodore 8032, avec seulement un ( ou deux ?.... me souviens plus ) lecteurs de disquette.

Je me suis vite aperçu, que les lectures/écritures de fichiers en disquette, se faisaient enregistrements par enregistrements, sans aucune possibilité de bufferisation des entrées/sorties. Impossible de tirer partie de la bufferisation réelle faite par le système, car cette bufferisation n'était pas accessible.

Le tri QuickSort était donc infaisable, sauf à procéder enregistrements par enregistrements, avec longueur d'exécution longue, sinon très longue...

Aucun contrat de signé, période implicite d'essai, mais rien de signé.

Je complète à la fin du tri QuickSort, ce tri par un tri à bulles, je ne sais plus pourquoi, probablement à cause d'un problème de limites d'enregistrements... ;(

En cours de route, je veux aborder le Directeur dans son bureau, pour lui demander ce qu'il veut mettre dans sa base de données. Je n'avais fait qu'un seul tri avec un ou deux fichiers, pas une base de données, mais comment faire si je ne sais pas quoi y mettre ?

C'est l'exemple du peu d'échange d'informatiosn entre la hiérarchie et l'exécutant ( moi ) car le Directeur me dit, donc au bout de deux semaines : "Continuez, je verrai après".

Au bout d'un mois, il déclenche le tri, constate que c'est un peu long ( quelques secondes pour quelques enregistrements, ce sont des disquettes ) et dit :

"Ce n'est pas ça que je veux".

Quand j'ai vu ce degré de mauvaise foi et d'absence de communication, qui ne pouvait cacher que l'absence totale de connaissances en Informatique, laissant présager des heurts et conflits répétés sur les options techniques, je n'ai même pas cherché à lui expliquer que son micro-ordinateur était fait de telle manière qu'il était impossible de faire un tri QuickSort - un tri par fusion à la rigueur aurait pu marcher -, je lui ai dit :

"Si vous ne savez pas ce que vous voulez, moi je vous colle ma démission".

Stop et fin.

Comme quoi, la communication dans les entreprises, hein ?

En passant, le Directeur était Docteur en Médecine... ;(

C'était en 1983, depuis je n'ai jamais retravaillé, seulement deux stages supplémentaires ( brillants ) en 1983 et 1997.

Voilà où nous mène cette "culture du Chef en France".

Amicalement.

Jean-François Ortolo

[polweb]

Bien fait et sympa.

[Bellegarde-webb]

Le monde est ainsi fait. ça me rend triste car je sais que cet article dit malheureusement vrai! Être un bon programmeur demande beaucoup de qualités intellectuelles et une éducation que peu ont trouvé sur leur chemin d'études (je le sais). Le mépris de ce métier et des aptitudes qu'il requiert vient de cette éducation mal faite par des enseignants qui n'ont pas dominé (pas eu le temps de dominer) suffisamment le sujet pour savoir les capacités qu'il fallait vraiment développer chez leurs étudiants. La source du problème est l'efficacité car faire cela demande des heures de cours supplémentaires avec en plus des étudiants impatients qui veulent savoir à juste titre "a quoi cela va-t-il me servir ?" et qui veulent apprendre à coder point barre. Le problème du mépris est moins aigu aux USA car il n'y a pas ces hiérarchies au travail. Mais au niveau de l'enseignement, c'est la même chose et certainement encore bien pire (ou tout du moins ça l'était car mon expérience date à ce sujet. J'ai du fournir quelques "codeurs" pour microsoft il y a une vingtaine d'années et j'aime autant vous dire que les conditions de leur éducation de programmeur laissait à désirer d'où ma suspicion de tous les logiciels ainsi produits! )

[passion]

C'est aussi une question de personnalité.

Malheureusement le système de la société est fait pour produire de la connaissance.
Oui je parle de produire, comme si on était des oies que l'on gave pendant plusieurs années à coups de cursus scolaires de plus en plus poussés!
Mais le système a oublié dans son équation, le facteur humain.

Et un jeune qui sort tout juste de ses études se fera facilement "bouffé" car sa volonté de montrer que son employeur a fait le bon choix, finira par se retourner contre lui !!

Travailler pour un société ne doit pas être synonyme de soumission. Le fait de montrer que l'on a du répondant et aussi un signe de responsabilité. D'autant plus un métier comme le nôtre où nous sommes souvent amenés à nous déplacer chez le client !
Nous sommes représentatif de la société à l'extérieur et si un problème intervient avec le client, nous sommes en première ligne !! Donc si on chie dans son pantalon à la première occasion, il faut bien se rendre compte que l'employeur n'a pas fait le meilleur choix !
Et cela se répercute aussi sur la relation entre les autres collaborateurs !

Alors oui, certains collaborateurs peuvent se sentir rabaissés par les autres collaborateurs ou employeur mais c'est à eux de bouger !
J'ai arrêté récemment mon travail dans une SSII pour me mettre à 100% sur mes projets et malgré que j'étais un simple et basique analyste programmeur, je peux vous assurer qu'aussi bien le directeur du CSI ou de la direction jusqu'au PDG ne m'emmerdait pas !
Ils ont toujours été réglo avec moi car ils savaient jusqu'à donc dernièrement qu'il ne fallait pas me prendre pour un con
Mon travail était toujours exemplaire et une volonté de m'impliquer dans tous les projets de près comme de loin, je respectais autrui et j'en attendais de même !
Cela m'arrivait souvent d'être sollicité par les CP car ils souhaitaient avoir mon avis sur des domaines que je maitrise plus qu'eux !
Au moment de la pause, je n'aurai eu aucun problème pour remettre un responsable en place si cela aurait été nécessaire et ils le savaient pertinemment !
Encore une fois, c'est une question de personnalité !

C'était mon coup de gueule lol !

[HawkEye]

Proverbe:

"Si on te prend pour un con: casse-toi et utilise ton savoir-faire à meilleur escient."
HawkEye, vieux sage belge