Discussion :

[yann2]

Salut

Il manque quand même une qualité primordiale à ce très bon programmeur : il doit savoir travailler en équipe - et aimer ça. Parce que, aussi doué soit-il, il ne pourra pas tout faire tout seul !



Parce que là, vu comment il est décrit, j'ai l'impression que le bon programmeur est, certes, très bon, mais méga relou avec ses collègues qui sont un peu moins vifs et derrière qui il doit passer pour remettre le code au propre selon sa vision des choses

Certains disent même qu'il faut privilégier les personnes ayant un bon sens de l'équipe (ce qui exclut donc les asociaux arrogants, qu'ils soient mauvais ou bon).

Je ne comprend pas du tout pourquoi le sujet n'est pas abordé !

Yann

[mdelanno]

j'imagine s'il s'agissait de construction automobile , batiment , aéronautique , production d'énergie nucléaire , médecine ...

à part les prévisions météorologiques , existe-t-il un autre secteur où on puisse se permettre de tels chiffres ?

on est dans une industrie du luxe tout de même

Dans tous les domaines du génie (et oui ça s'appelle comme ça), il y plein de projets qui accouchent d'une souris. Je viens de l'industrie mécanique, j'ai vu plein de systèmes qui ont coûté très cher à concevoir et qui n'ont jamais été utilisés ou qui n'ont pas atteint leurs objectifs. L'informatique est une industrie comme une autre.

[maske]

Je ne comprend pas du tout pourquoi le sujet n'est pas abordé !

Parce que clairement l'auteur manque de recul et raconte des imbécilités.

"Les six vérités de l'informatique".... pff...

[martopioche]

Quoi qu'il en soit, je trouve que mesurer sa contribution à un projet en lignes de code c'est juste débile. En plus avancer un chiffre c'est assez gonflé.

Non mais comme je le disais, c'est surtout un héritage qu'on se traine qui ne veut rien dire. Un perlmonger te fera tenir ton application en une ligne (ok j'exagère ). En Java, l'ajout d'un attribut génère 6 lignes supplémentaires systématiquement (get/set, vive la génération de code...) même si elles ne servent jamais. Donc en effet, "12 lignes de code" fait plus réagir qu'autre chose mais l'idée qui s'en dégage est que la partie de production d'un développeur se retrouvant dans le produit fini (et y restant) est assez infime.

Et employer des solutions existantes pour ne pas avoir besoin de réinventer la roue c'est bien, cependant quand je vois des sites web tout simples de gestion de contacts faits avec plein de frameworks qui font de la réflexion, de l'injection de dépendances, des trucs qui confinent à la magie noire et qui laissent des stacktrace de 25m incompréhensibles en cas d'erreur d'initialisation, ça me fait doucement rire.

Elle m'a bien fait rire celle là car c'est bien notre monde moderne et les applications surarchitecturées...

[Xper4net]

On parle de "mauvais" et de "bons" programmeurs, comme les "bons" et les "mauvais" chasseurs ??

Il y a surtout des programmeurs bien ou mal encadrés.
Un programmeur bien encadré, c'est un programmeur qui :

- Travaille avec un architecte qui répond clairement à ses questions, et qui lui apporte une solution technique quand il est bloqué,
- Travaille avec un document de design et des diagrammes UML complets,
- Ne refait pas deux fois la même chose parce que le design a été changé en cours de projet.

..et si malgré tout ça il ne s'en sort pas, puisqu'il est bien encadré, on le voit tout de suite et on le remplace...

A quoi reconnait-on un programmeur bien encadré ? Il a la banane, et qd il fait des heures sup, c'est parce qu'il est passionné par ce qu'il fait, et non parce qu'il est en retard...

Pour une construction, on parle de bons ou mauvais architectes, et non pas de bons ou mauvais maçons.... Pour un logiciel, c'est pareil.

Ceux qui n'ont pas compris ça sont des bleus bites... soit ils changeront d'avis, soit, lassés des échecs, ils changeront de métier.

[Arnard]

@Génoce : j'ai déjà entendu des chiffres similaires durant mes années d'études, et le fait qu'un bon programmeur soit 100 fois plus efficace qu'un mauvais ne me choque pas :
- le mauvais va prendre les specs et les réaliser, plus ou moins bien, les tester de la même manière. Et en intégration tu découvres des .
- Si ça devient galère, et que la composante de code est essentielle, on envoie quelqu'un de plus compétent pour redresser la barre => Ce qui veut dire que le temps investit par le mauvais programmeur a été mal investi, et en plus on consomme le temps d'autres tâches... Mon faible vécu m'incite dans ce sens...

[CIFQ_Drew]

Les 6 vérités de la programmation, se vérifient-elles autour de vous ?

- Un programmeur passe entre 10 et 20% de son temps à coder, et écrit en moyenne 10 à 12 lignes de code par jour qui seront incluses dans le produit final (peut importe leur niveau). Les bons programmeurs utilisent le temps qu'il leur reste à penser, rechercher et faire des tests pour parvenir au meilleur design possible. Les mauvais quant à eux passent ces 80 à 90% de temps à debugger leur code en faisant des essais au hasard puis en regardant si cela fonctionne.

Je meterais un petit bémol a ce niveau. J'ai eu à produire quelque projet de moyenne envergure (principalement du Web, mais quelque projet Java et VB éparpiller un peu partout) et notre structure de travail était non sans failles mais tout de même efficace. Nous pensions raisonnablement beaucoup mais selon les principes Agile (pas tous, celles qui nous plaisaient). Nos projet sont, a part le premier, tous facile à modifier, raisonnablement bien documenter et qui plus est fonctionnelle . Je me considère comme un bon programmeur.

Cependant j'ai depuis quelques temp commencer un nouveau travail avec un nouveau language avec trois projets ayant environ 35000-40000 ligne de code chaque. Le créateur s'en va et me donne une formation ultra rapide d'une journée. Le langage est C#. Je réussi à faire kelke modification au début tranquillement. Puis de nouvelle. J'essaie d'adapter le code et respecter la philosophie du programmeur mais je ne m'y plait aucunement (aucune DAO, des instructions SQL vers la base de données pour les mêmes élément (par exemple une entité Utilisateur lié à une table "utilisateur" peut avoir 3 à 5 classes qui fait des requête directement à la base de données vers utilisateur). Bref je ne n'ai ni le temps ni les ressources pour réécrire le code, mes patrons ne me le permettront évidemment pas faute de budget. Alors j'essaie de trouver les pistes de solution en ajoutant ici et là des instructions que je crois logique, mais je ne sais pas les effets qu'ils engendrent parce que toutes modification d'un coté peut altérer le comportement d'un autre élément qui ne sont a priori non lié.

Si vous avez des pistes de solution pour mon problème hormis ma démission, je suis tout ouïe!!!

[Marco46]

(par exemple une entité Utilisateur lié à une table "utilisateur" peut avoir 3 à 5 classes qui fait des requête directement à la base de données vers utilisateur).

En tant que jointure ou en tant que table principale de la requête ?

Ya pas de couche persistance dans cette appli ?

[el_slapper]

(.../...) Si vous avez des pistes de solution pour mon problème hormis ma démission, je suis tout ouïe!!!

90% des projets ressemblent à ça. Si tu démissionnes, tu retrouveras probablement le même genre d'horreurs à maintenir. Ca fait 10 ans que c'est mon quotidien.

[chemanel]

Je meterais un petit bémol a ce niveau. J'ai eu à produire quelque projet de moyenne envergure (principalement du Web, mais quelque projet Java et VB éparpiller un peu partout) et notre structure de travail était non sans failles mais tout de même efficace. Nous pensions raisonnablement beaucoup mais selon les principes Agile (pas tous, celles qui nous plaisaient). Nos projet sont, a part le premier, tous facile à modifier, raisonnablement bien documenter et qui plus est fonctionnelle . Je me considère comme un bon programmeur.

Cependant j'ai depuis quelques temp commencer un nouveau travail avec un nouveau language avec trois projets ayant environ 35000-40000 ligne de code chaque. Le créateur s'en va et me donne une formation ultra rapide d'une journée. Le langage est C#. Je réussi à faire kelke modification au début tranquillement. Puis de nouvelle. J'essaie d'adapter le code et respecter la philosophie du programmeur mais je ne m'y plait aucunement (aucune DAO, des instructions SQL vers la base de données pour les mêmes élément (par exemple une entité Utilisateur lié à une table "utilisateur" peut avoir 3 à 5 classes qui fait des requête directement à la base de données vers utilisateur). Bref je ne n'ai ni le temps ni les ressources pour réécrire le code, mes patrons ne me le permettront évidemment pas faute de budget. Alors j'essaie de trouver les pistes de solution en ajoutant ici et là des instructions que je crois logique, mais je ne sais pas les effets qu'ils engendrent parce que toutes modification d'un coté peut altérer le comportement d'un autre élément qui ne sont a priori non lié.

Si vous avez des pistes de solution pour mon problème hormis ma démission, je suis tout ouïe!!!

Moi je vois deux solutions "rapides" qui t'éviteront pas mal de problème ...

1. Pour l'accès a la db : Travailler avec une couche style NHibernate ou LinQ, tu ne devras plus coder une seule requete SQL et la relation entre les tables et tes objets C# sont défini de manière ferme et structurée dans des fichiers de définitions (xml)
2. Pour ton problème de modifications qui altère d'autre choses : Tu ne travaille pas avec des tests unitaires ? Il va falloir t'y mettre...

[maske]

A quoi reconnait-on un programmeur bien encadré ? Il a la banane, et qd il fait des heures sup, c'est parce qu'il est passionné par ce qu'il fait, et non parce qu'il est en retard...

Pour une construction, on parle de bons ou mauvais architectes, et non pas de bons ou mauvais maçons.... Pour un logiciel, c'est pareil.

Ceux qui n'ont pas compris ça sont des bleus bites... soit ils changeront d'avis, soit, lassés des échecs, ils changeront de métier.

Je n'ai pas compris ça (j'imagine que je suis un bleu donc...).

Ce que je comprend, c'est que quand on est placé sur un projet déjà en retard, avec un budget très restreint, on a pas forcément le temps d'être encadré, on ne fait pas des choses toujours très propres et on fait des heures sup' parce qu'on est en retard comme tout le monde.

Ce que je comprend aussi, c'est que l'informatique, c'est ça : des projets en retard (et s'ils ne le sont pas encore, ils le seront, parce que de toutes façons les commerciaux promettent toujours plus que la Lune aux clients).

Dès lors, quand on embauche un ingénieur, on attend de lui qu'il soit capable de se débrouiller sans avoir à être constamment chapeauté par un "architecte" et qu'il soit naturellement bon. Comme il sera en retard, cette notion de "bon" ou "moins bon" sera forcément discutable.

[CIFQ_Drew]

En tant que jointure ou en tant que table principale de la requête ?

Ya pas de couche persistance dans cette appli ?

Exactement habituellement j'utilise un pattern DAO pour l'accès au donnée car très souvent j'ai 2 voir 3 sources de données (comme c'est la cas où je travail).

Pour expliquer un peu mieux le problème je vous donne un exemple.

Disons l'entité "Utilisateur" possèdant une table avec {id, name, passwd}.

J'ai une classe "Utilisateur" qui va s'occupé de faire les "update" et les "select top 1" par exemple.

J'ai une classe Utilisateurs qui va s'occupé de faire le chargement tous les utilisateurs (principalement que des select mais également les delete et insert).

Mais pire j'ai un formulaire (un Windows Form) dans lequel j'ai retrouvé une requête qui allait chercher les noms des utilisateurs !

Le problème c'est que je ne suis pas autorisé à faire les changements qui s'impose parce que nous avons des bons de commandes et le système n'est pas encore stable. Je dois donc "patcher" le plus possible !!!

[bigben62]

Un bon programmeur ça ne doit pas exister. Car cherchant continuellement à progresser il se retrouve en permanence en situation d'incompétence.

Un programmeur qui pense être bon et en fait mauvais.

[jpclabaux]

Je ne sais pas si je suis un bon programmeur (en tout cas j'aime ce que je fais), mais je pense être un bon père de famille donc quand je suis à la maison je ne pense pas au boulot et inversement.

[SWOTR]

Je sais pas pourquoi mais cet article me laisse un peu sur ma faim, j'ai l'impression de ne pas saisir tout le sens de la démarche, quel est le but de cette publication à l'origine?

Je sais pas, mais si ça pouvait passer entre les mains de quelques patrons et leur ouvrir les yeux sur ces "vérités", ça ferait sans doute du bien à pas mal d'équipes...

[ravakhasina]

like it!!!!
Par contre :

Bon, ok, beaucoup de choses sont déjà écrites, mais pour les retrouver, ce n'est pas d'un programmeur dont on a besoin, mais d'un documentaliste !
Le "bon" ne deviendra alors jamais "compétent", parce qu'entre ces 2 idées, c'est un revirement non ? A quoi bon passer 80% de son temps à trouver ce qui existe déjà pour gaspiller "constamment" son temps à le réécrire ?

lol ... que font les documentalistes des schémas?
Sinon, je suis aussi contente de ne pas être la seule obsédée par l'optimisation d'un code jusque dans la douche XD XD

[chaplin]

+1

- Un bon programmeur est dix fois plus productif qu'un programmeur lambda. Un excellent programmeur, lui, est de 20 à 100 fois plus productif que ce dernier. Des études l'ont montré, et ce, depuis les années 60. Un mauvais programmeur quant à lui, n'est pas seulement non productif, en plus de ne rien créer d'utile, il génère des heures de travail et de maux de tête pour ses collègues (qui devront réparer ses erreurs).

De l'aspirine SVP!

[antalata]

Il me semble exact que l'on passe 2/3 de son temps au design ou à la convivialité, 'selon le nom que l'on préfère).
Nous ne sommes finalement qu'au service de l'utilisateur final et aussi ..... aux autres programmeurs qui doivent maintenir nos applications.

[cyberic]

Bonjour,

Moi je développe en COBOL et en UFO, et pour ma part. Généralement quand j'ai un truc a développer j'ai déjà une spécification fonctionnelle et technique, qui oriente le programmeur. Donc le programmeur n'a pas a ce poser des milliards de question existentielle comment il va faire ses Algo, ils sont déjà pré-maché. Tout ce qu'il a faire c'est écrire du code qui soit lisible maintenable par n'importe quel développeur (avec un minimum de commentaires) et qui s'intègre dans l'existant. Pour ce qui est de la ré-utilisabilté sur le projet c'est quasiment nul, faute au langage , et la création de sous programmes n'est utilisé avec l'accord du client que dans des cas particulier. Après je code bien des parties qui réutilisable dans d'autres programmes, pas de librairies, merci le copier coller.
Les programmes sont donc des monolithes de code. Ensuite il faut se créer les cas de tests dans les bases, "bidouiller" les tables BD2 pour tester tous les cas triturer son code, car aucun outil n'a été développer pour.
Pour ce qui est de l'ergonomie, sur un mainframe, il y a pas des masse a faire.
Généralement, je n'ai pas le temps matériel de peaufiner mon code, de chercher excellence, le temps de lire la spec de comprendre, de regarder l'existant de mettre son code sans tout casser, de créer ses cas de test de tester, pour que cela fasse ce qui écrit.
Pour autant, je ne pense pas être mauvais développeur, ni la prétention d'être un bon, mais j'essaye de faire ce qui est demandé au mieux. Et je veux bien réfléchir a du code dans ma salle de bain, mais a la fin je n'aurai rien en retour de la part de mon employeur, j'ai passé des nuits a pas dormir a me réveiller en pensant a du code au bug j'avais, a comment faire simple lisible et fonctionnel, et correspondant au besoin.
Je demande a travailler sur de la nouvelle techno, a faire de l'embarqué, mais rien, alors je ne vois pas pourquoi je continuerai de me prendre la tête a faire une technologie que je n'aime pas, et dont mon travail n'est pas reconnu.

[Gouyon]

Je suis toujours dubitatif devant la notion de bon et mauvais programmeur (ou quoique ce soit d'autre). Car c'est sauf cas flagrant toujours difficile à juger. Quand je parle de cas flagrant j'ai en tête l'exemple d'un ex collègue qui a pondu 2 lignes de codes en 6 mois de travail et en plus ça ne fonctionnait pas.
J'ai eu aussi le cas lors de mon stage de fin d'étude d'un étudiant de ma promo qui faisait son stage dans la même entreprise que moi qui passait 100% de son temps à me poser des questions et qui me demandais quasiment de faire son boulot Ça n'a pas duré longtemps mon chef de stage est intervenu assez brutalement ensuite j'a été tranquille.

Ceci dit il y a quelques bonnes vérités ici telle que:

• Bien réfléchir à ce qu'on veut faire et à la manière de le faire avant de se lancer dans le code
• Ne pas réinventer la poudre surtout pour des fonctions qui ont été étudiées en long et en large comme les tris ou les algo de recherche dans des listes.

En gros être méthodique

Mais pour moi le "bon" programmeur est celui qui connaît bien son langage de programmation et surtout son environnement et comment fonctionne son OS.