Discussion :

[GeoffreyOnRails]

Là je rejoint en partie des commentaires précédent : on parle d'évidence. Quoi que... Si on prend une population d'individus notés entre 0 et 10, avec une moyenne disons à 4, ça ne veut pas nécessairement dire que la majorité sont proches de 4. Dire que la plupart des gens sont moyens revient à dire que l'écart-type est petit. La moyenne seule ne permet pas de le dire (on peut avoir 60% de gens à 0 et 40% de gens à 10, personne n'est proche de la moyenne qui est pourtant toujours 4).

Déterminer le niveau, c'est ordonner les gens, X est meilleur que Y, d'une manière absolue. La notion d'écart-type dans la compétence des gens, ça n'a juste pas de sens, si ça n'est pas associé à une mesure précise (et on est assez d'accord pour dire qu'il y en a pas de bonne). Prenons l'exemple des élèves en prépa math à Louis le Grand. L'écart-type de leur note est math au bac est très faible, les notes s'échelonnent de 18 à 20. Sur le premier devoir de math de l'année, les notes vont s'éparpiller de 0 à 20. Les élèves n'ont pourtant pas fondamentalement changés entre le mois de juin et celui de septembre. L'ordre est sans doute le même, la mesure est tout autant valide. Mais l'écart-type est très différent.
Généralement, la seule chose que l'on demande à une mesure, c'est de fournir une relation d'ordre pour pouvoir comparer les gens. A partir de ça, sans changer les gens ni leur classement, je peux bisouiller mon écart-type en calculant les notes autrement. Un problème que personne n'a su résoudre? Noté sur 5, les notes vont de 0 à 15. Sur 15, de 0 à 5. Sur 0, de 0 à 20. Idem dans l'autre sens pour une question que tout le monde a su faire.

Du coup, dire que la majorité des développeurs sont moyens, ben c'est tout au plus un ressenti, par rapport à sa propre mesure subjective. De mon expérience personnelle, je constate de très grandes différences entre différents développeurs, que ce soit dans la qualité du code, la compréhension du métier ou la vision de l'architecture. Mais ça reste mon ressenti, basé sur l'idée que je me fais du temps que j'estimerais nécessaire pour atteindre leur niveau (ma mesure, qui vaut ce qu'elle vaut, à savoir pas grand chose).

Par contre, je trouve plus stimulant de dire qu'il y a beaucoup de bons développeurs et beaucoup de mauvais, plutôt que tout le monde est moyen, en tout cas ça m'incite plus à me dépasser. Maintenant, je peux aussi comprendre que ça intimide des gens, et les décourage de tenter leur chance, surtout ceux qui ont du mal à s'identifier à un bon développeur célèbre. Mais c'est là un autre sujet

[captaindidou]

Il y a un biais cognitif très présent dans les métiers de l'IT : l'effet Dunning-Kruger, une fois qu'on a compris ça, on voit les gens sous un jour différent, ça évite bien des mauvaises surprises.
Et par conséquent on comprend mieux pourquoi Jacob Kaplan-Moss se dit médiocre

En effet, je comprends mieux la réponse de certains, manquant d'à propos.

[B.AF]

Moi j'en connais pas mal de très médiocres qui s'imaginent super bon.
Faut dire qu'a chaque nouveau développement ils ont réinventé la persistence, les tests unitaires.
Le vraiment mauvais de toute façon il a une gimmick aujourd'hui : il ne parle que d'architecture trois tiers, de couche metier, et il a toujours un composant technique a re-inventer.
Tu lui dis qu'il y a une fonctionnalité a livrer, il sait deja qu'il faut du MVVM avant même de comprendre le sujet.
Combien de fois j'ai vu des mecs ré-ecrire une couche d’accès aux données....
En bref, le mauvais développeur, c'est celui qui ne sait pas que le permis de conduire existe, mais qui veut acheter une voiture.

C'est la capaciter a modeliser qui fait un bon développeur. Le reste, c'est de la programmation.

[Matthieu Vergne]

Amen.

[Aeson]

Comme disait l'autre.. Il y a 4 type de programmeur :

Le Junior => Il trouve des solutions compliquées a des problèmes simple
Le Medior => il trouve des solutions compliquée a des problèmes compliqués
Le Senior => Il trouve des solutions simple au problèmes compliqués

La RockStar => il fait disparaître les problèmes. Quand en temps que chef d’équipe tu as a gérer un développeur de ce genre il faut le cassé le plus vite possible car un jour il aura trop confiance en lui et fera une grosse connerie et se brulera les ailes. C'est eux les plus compliqué a gerer.

[Matthieu Vergne]

Comme disait l'autre.. Il y a 4 type de programmeur :

Le Junior => Il trouve des solutions compliquées a des problèmes simple
Le Medior => il trouve des solutions compliquée a des problèmes compliqués
Le Senior => Il trouve des solutions simple au problèmes compliqués

La RockStar => il fait disparaître les problèmes. Quand en temps que chef d’équipe tu as a gérer un développeur de ce genre il faut le cassé le plus vite possible car un jour il aura trop confiance en lui et fera une grosse connerie et se brulera les ailes. C'est eux les plus compliqué a gerer.

RockStar, alias politicien ou futur patron. Donc oui je peux comprendre que le chef d'équipe ait envie de le casser rapidos. {^_^}

[Aeson]

Quand t'es chef d’équipe un qu'un développeur fait échouer le projets ou crasher la version en prod a cause qu'il se croit le plus fort, ta responsabilité c'est de le faire redescendre de son trip au plus vite. Du moins le garder un minimum sous contrôle et garder un œil attentif sur lui. C'est lui rendre service.

[Matthieu Vergne]

Ah mais celui là c'est pas celui qui fait disparaitre les problèmes, c'est celui qui cherche des solutions à des problèmes inexistants. Pas la même chose. Sinon c'est celui qui fait disparaitre les solutions, et non les problèmes. Parce que faire disparaître les problèmes c'est possible aussi, en particulier les transformer en opportunités.

[marsupial]

Ah mais celui là c'est pas celui qui fait disparaitre les problèmes, c'est celui qui cherche des solutions à des problèmes inexistants. Pas la même chose. Sinon c'est celui qui fait disparaitre les solutions, et non les problèmes. Parce que faire disparaître les problèmes c'est possible aussi, en particulier les transformer en opportunités.

C'est d'ailleurs l'origine de l'impression 3D. Pensé au service technique face à des cas de défauts d'impressions laser tellement récurrents que l'idée vient d'une blague : sculpter un objet à partir d'une imprimante de la marque que je ne citerai pas mais leader sur son marché

Comme il n'y a pas de bons ou mauvais motards, il n'y a que de vieux développeurs.

[vinmar]

De mon point de vu, un programmeur qu'il soit expert ou débutant est avant tout un élève en apprentissage perpétuel.

Je pense que tout est dit dans cette phrase. L'inconvénient de le monde de l'informatique restera que beaucoup de gens s'imaginent être au-dessus du lot et je pense que Jacob Kaplan-Moss ne dit pas autre chose.

[GrandFather]

Il y a un biais cognitif très présent dans les métiers de l'IT : l'effet Dunning-Kruger, une fois qu'on a compris ça, on voit les gens sous un jour différent, ça évite bien des mauvaises surprises.
Et par conséquent on comprend mieux pourquoi Jacob Kaplan-Moss se dit médiocre

L'effet Dunning-Kruger est présent dans tous les métiers à prédominance intellectuelle, ce n'est pas spécifique à l'IT. Et quand il se dit « médiocre », il ne faut y voir qu'un peu de provocation, un petit effet pour attirer l'attention de son auditoire. Il est évident que pour lui être « moyen » n'a aucune connotation péjorative.

En fait, il y a un mot qu'il évite soigneusement de prononcer, et qui est pourtant au centre de son argumentation, c'est « élitisme ». Qu'est-ce qu'une tendance à classer les développeurs de manière binaire, entre bons et mauvais, sinon de l'élitisme ?

[Laurent 1973]

Mais peut être que dans un projet informatique, l'important n'est pas l'individu mais le collectif.

Si vous enfermez un groupe de "génies" pour vous pondre un super projet, il n'est pas sur que vous en sortez quelque chose de fonctionnelle.
Ces génies savent peut être très bien développer, mais savent-ils travailler ensemble.
Là, rien n'est moins sur: Un "génie" est orgueilleux, plein d'idées arrêtées.
Saurait-il échanger correctement avec d'autre personnalité aussi forte que lui?

Je pense que le mieux, c'est de constituer une équipe de développeurs plus "moyen" mais ayant un cohérence entre eux.
Qu'ils soient motivé, ouvert, complémentaire sur des compétences humaines et intéressé par le projet que l'on leur propose.
Là, si on arrive à les faire bien collaborer ensemble, nous pourrons obtenir de grandes choses de leur part.

L'association des intelligences d'un groupe est supérieur à la somme des intelligences de chaque individu.(cf http://fr.wikipedia.org/wiki/Intelligence_collective)

Je me demande si ce n'est pas à cela que veux faire référence Jacob Kaplan-Moss.
Finalement, si Django a le succès actuelle, c'est peut être plus sur le travail collaboratif d'un groupe de gens que de celui d'un "génie"

[4sStylZ]

Je ne vois ni comment un bon project leader peut se passer de connaissance fondamentales sur les framework récents (même si pour ça il doit demander à des dev leurs avis), ni un architecte se passer de connaissances sur les matériaux.

Un architecte doit se soucier des matériaux qu'utiliseront les maçons :*
- Les reflets et les ombres que peuvent donner une surface ou une autre peuvent métamorphoser le rendu d'un batiment.
- Les métariaux utilisés peuvent rendre la maintenance innaccessible :*Je n'aimerai pas à avoir à installer des prises supplémentaires dans les murs d'une maison en paille et terre battue.
- La structure peut être plus solide avec un matériau plutôt qu'une autre.

Dans le domaine du service il a aussi plutôt intérêt à orienter ses équipes vers des technos qui possèdent d'importante parts de marché.

[Lyons]

Pour revenir sur ce point qui semble faire débat:

La vérité selon lui est que la programmation n’est pas une passion ni un talent, ce n’est qu’un ensemble de compétences que tout le monde peut apprendre. [...]

Être passionné par son métier est effectivement un gros plus mais je ne comprends pas cette levée de bouclier. Je pense que l'auteur voulait mettre en avant le fait que programmer est un métier et non un hobby pratiqué par quelques geeks en marge de la société (image malheureusement trop souvent véhiculée dans les médias).
Tout le monde conçoit qu'un assureur, banquier, mécanicien (...) puisse travailler uniquement pour gagner sa vie, sans pour autant y prendre du plaisir. Pourquoi donc un programmeur devrait-il impérativement être passionné?
J'ai l'impression qu'au sein même de la profession celle-ci est vue comme "à part". C'est pas comme ça qu'elle sera démistifiée...

[abriotde]

L'homme, intelligent par nature, est avant tout compétent dans le domaine ou ils s'investit... et pas seulement au travail. Pour cela il doit y a voir de la passion et un brin de talent.

Etre le meilleur ne sert a rien s'améliorer et devenir bon dans un domaine est ce qui importe. Je déteste pour cette raison l'esprit de compétition.

L'informatique est très théorique et technique et donc intéresse peu de gens : très peu de femme et avec l'age beaucoup s'en lasse. Pour être informaticien il suffit d'avoir de la passion et de la persévérance... mais certains sont informaticien pour le salaire qui reste élevé car il n'y a pas assez de passionné.

[abriotde]

Tout le monde conçoit qu'un assureur, banquier, mécanicien (...) puisse travailler uniquement pour gagner sa vie, sans pour autant y prendre du plaisir. Pourquoi donc un programmeur devrait-il impérativement être passionné?

Non je ne conçoit pas travaillé sans être passionné. Un banquier doit avoir une passion pour l'argent et les manipulation, un assureur pour les cas catastrophique... sans pour autant en être des fous. Mais si un banquier ne parle pas de son métier avec passion dans sa vie personnelle, ou n'a pas un rêve sur son métier alors il faut qu'il en change. Cela ne veut pas dire que l'on doit sauter de joie en allant travailler. Mais avoir une fierté/plaisir a accomplir son travail. Il n'est pas de travail que l'on ne puisse aimé.

[GrandFather]

Tout le monde conçoit qu'un assureur, banquier, mécanicien (...) puisse travailler uniquement pour gagner sa vie, sans pour autant y prendre du plaisir. Pourquoi donc un programmeur devrait-il impérativement être passionné?

On peut prendre du plaisir à ce qu'on fait sans être passionné pour autant.

Il existe beaucoup - j'oserai même dire une forte proportion - de développeurs qui retirent un sentiment fort d'accomplissement à créer quelque chose d'utile à d'autres, et le plaisir ou la satisfaction qu'ils en retirent dépasse celui apporté par l'acte de développer lui-même. Ils n'en sont pas « mauvais » pour autant. Et je pense que c'est parmi cette catégorie qu'on trouvera les développeurs qui répugneront le moins à se qualifier de « moyens », sans en faire un complexe d'infériorité pour autant.

[Invité]

Je trouve ça déprimant de lire ce genre de trucs. Si c'est pas une passion, il faut peut-être se demander si on a choisi la bonne orientation professionnelle. C'est la passion qui permet à des développeurs de s'élever au dessus du lot. Ceux qui ne sont pas passionnés peuvent être bons, mais ils seront rarement exceptionnellement bons.

C'est un point de vue qui n'est pas partagé par tout le monde : http://www.20minutes.fr/societe/6851...t-plein-cadres .
Mais d'un autre coté, la difficulté de définir une échelle pour juger la qualité des développeurs fait que l'on s'attache à quelque chose de plus floue : la passion.
Etre bon est plutôt bien de nos jours, je trouve.

Et je suis très dubitatif sur le fait que "tout le monde peut apprendre" le développement : tout le monde peut s'initier, certes, mais pour aller au delà des bases, ça demande une forme d'esprit que tout le monde n'a pas. J'ai vu beaucoup de gens par ailleurs très intelligents qui n'ont jamais été capables d'aligner 3 lignes de code, même en suivant des cours.

Pourquoi une telle remarque sur l'informatique, on fait bien faire de la physique, des mathématiques jusqu'à bac+2 au moins.
L'informatique ne pourrait être pratiquée que par des gens prédisposés contrairement à d'autres activités?

[bretus]

Quand t'es chef d’équipe un qu'un développeur fait échouer le projets ou crasher la version en prod a cause qu'il se croit le plus fort, ta responsabilité c'est de le faire redescendre de son trip au plus vite. Du moins le garder un minimum sous contrôle et garder un œil attentif sur lui. C'est lui rendre service.

Elles sont bizarres tes rockstars...

Accessoirement, quand j'ai un bug qui arrive en prod; en tant que responsable technique, c'est plutôt à moi que je m'en prend... Si le projet est intégralement planté : Idem. Ce n'est pas pour rien qu'il existe des notions de merge request et de protection de branche dans les gestionnaires de code source.

Si un développement plante en production, c'est le responsable technique qu'il faut allumer : Il n'a pas mis en place un processus qui permette de valider le code avant le passage en production (intégration continue, test & revue de code).

De même, si des geeks font pulluler les dépendances dans le projet et que ce dernier devient ingérable, c'est le responsable technique qu'il faut allumer puisqu'il n'a pas fixer de règle simple du type : Toute nouvelle dépendance doit faire l'objet d'une discussion.

Après, si le chef d'équipe passe plus de temps à casser les quelques types qui pourraient lui piquer sa place qu'à faire en sorte qu'un hack dégueulasse ne puisse pas arriver en production, c'est le chef d'équipe qu'il faut allumer...

Garder un oeil sur des personnes en particulier ne sert à rien si les méthodes de travail ne sont pas au point : Les plus expérimentés peuvent faire des boulettes comme les débutants. Sans un minimum d'instrumentation et de règle de travail pour valider avant les passages en production, la loi de Murphy s'appliquera plus souvent.

[CodeurPlusPlus]

Il y a un profil type de développeur qui est critiqué dans ce fil de discussion, c'est le génie auto-proclamé.

Celui qui se croit génial alors qu'il fait souvent n'importe quoi.

Celui qui se croit productif alors qu'il fait perdre du temps à tout le monde.

Celui qui pense être plus intelligent à lui tout seul que tous les autres réunis.

Celui qui n'écoute pas l'avis des autres.

Celui qui a toujours raison, et qui ne cherche pas à prouver qu'il a raison, puisque de toute façon les autres sont trop bêtes pour comprendre.

Celui qui, de coup, bosse dans son coin comme il l'entend, puis met les autres devant le fait accompli.

Celui qui réinvente tout le temps la roue en moins bien (en pensant réinventer la roue en mieux).

Celui qui s'enferme dans ses certitudes acquises jadis, au lieu de pratiquer la veille technologie, la curiosité et l'ouverture d'esprit.

Celui qui pense que tout le temps passé à faire autre chose que coder est du temps perdu.

Celui là, on n'a pas besoin de le cadrer ou de le surveiller.

Parce qu'on le voit arriver en entretien de recrutement avec la lourdeur d'un éléphant entrant dans une fabrique de porcelaine.

Et donc on ne le recrute même pas.