Discussion :

[sevyc64]

Je me reconnais très bien dans ce que dit ce Steven Benner autant dans le premier que dans le second post.

Si j'en crois son classement, certes exagéré mais pas si loin de la réalité que ça, je suis à la fois dans la première et dans la cinquième catégorie, suivant les circonstances, avec une préférence pour la cinquième et une haine viscérale de la quatrième catégorie que l'expérience mais surtout l'age n'arrange pas.

Il revient à ma mémoire une définition d'un de mes professeurs. C'était dans un autre contexte, mais c'est applicable à l'opinion de Steven Benner.

Face à un problème :

- Les mauvais développeurs croient connaitre la bonne méthode

- Les bons développeurs connaissent déjà la bonne méthode

- Les grands développeurs ne connaissent pas la bonne méthode, mais savent comment la trouver

Je suis donc un grand développeur, alors

JE hais les tests qu'il faut parfois passer en entretien, pondre un bon de code, comme ça sur le pouce sans pouvoir préparer, ni réfléchir, comme si on avait tout en mémoire, comme si développer c'était comme réciter les tables de multiplications à l'école primaire.
Et généralement j'échoue.

[el_slapper]

autant son premimer post me parait caricatural au possible, autant j'apprécie le fond du deuxième : l'important, c'est de savoir s'adapter. Se couler dans les pratiques locales, ou du moment.

Pour les tests : j'ai été amené à en faire, et à réfléchir au sujet, face à une hiérarchie traumatisée(à juste titre) par quelques recrutements hautement malheureux. J'aurais aimé pouvoir testé l'adaptabilité des gens, mais j'avais pour contrainte "un QCM, pas plus de 15 minutes, on est pas là pour faire chier les gens pendant 2 heures". Je me suis donc limité à un petit test sur les bases techniques utilisées en local, juste pour vérifier que les gens qui annoncent "15 ans d'expertise dont 12 en COBOL" sont capables de comprendre un code basique dans ledit langage.

Eh bien ça a suffit à éliminer la moitié des candidats..... Pour l'autre moitié, ceux qui n'avaient pas bidonné leur CV(parceque mon test, il ne vole vraiment pas haut), ils ont gardé la méthode "standard" : le courant doit passer(en bref, à la tête du client). C'est évidemment suboptimal, mais il est difficille d'évaluer réellement quelqu'un en quelques minutes.

D'ou ma conclusion : un test pour éliminer les boulets, c'est pertinent. Un test pour trouver la perle rare, c'est de la clownerie.

[ymajoros]

Je ne sais pas ce qu'est un vrai développeur, mais je sais ce qu'est un vrai bloggueur de seconde zone ;-) C'est du n'importe quoi : que des avis (stéréotypés), pas de faits.

Sur le fond : prétendre que les théoriciens sont à éviter... C'est un peu simpliste.

[dtravailloux]

Un vrai développeur, puisque c'est de ça qu'il s'agit est celui qui sait souffrir..en silence..

[mode 10ème degré]
pris entre les demandes délirantes des commerciaux, les délais du chef de projet intenables, un salaire de misère, une reconnaissance proche de zéro....il doit faire preuve d'abnégation ou tout envoyer bouler et faire autre chose...

Après tout, il m'a fallut 4 ans pour me rendre compte de la situation et cela fait déja 6 ans déja que je suis parti vers d'autres horizons. Maintenant que je suis de l'autre côté, j'ai pas l'impression que cela ait changé beaucoup...
[/mode 10ème degré]

bon courage les gars !

[Astraya]

Quelle est votre définition du « vrai développeur » et comment le trouvez-vous ?

Un vrai développeur ça serai avant tout un développeur qui ne ce dit pas tout savoir, fait des erreurs, les comprends, les corriges et en refait d'autres etc... Un personne qui avance par l'échec, pas en lisant des articles...

[ymoreau]

En même temps, un perfectionniste reste perfectionniste, quel que soit le budget ou le temps alloué.
Les perfectionnistes sont d'éternels frustrés, qui finissent par en avoir rapidement marre des pratiques de leurs collègues.

Mince je m'y retrouve totalement, et je ne suis pas sûr que ça soit une bonne chose ^^

Concernant l'article, comme dans beaucoup de caricatures, ça part d'un fond de vérité. Il y a évidemment des gens plus nuancés, mais les tendances énoncées ne sont pas fondamentalement fausses non plus je trouve.

[danbo52]

J'aime le développeur qui ne sait pas forcément tout, mais qui a l'idée d'aller puiser les bribes de solutions pour en faire un beau joujou, restant toujours homme du terrain.

Je reste d'accord sur la priorité de la mise en pratique, même si c'est moche, mais tant que ça marche à merveille, on y va!

Un bon développeur pense son travail et aux utilisateurs, voilà ce que j'y vois après des années à constater des défaites en terme de produits ERP en particulier.

[Virgil Scipion]

Je vois pas la différence entre la 1ère et la 4ème catégorie...

Moi je me baserai sur un autre critère : le souci du mec qui passe derrière. Certains font des trucs ultra porc parce qu'ils ne se posent pas de questions, et d'autres perdent du temps à faire des choses claires en pensant aux types qui reprendra leur code (et parfois c'est eux mêmes ce type )

En tout cas, les architectures ultra carrées, super propres, respectant à la lettre la conception de haut niveau, ça fait joli mais c'est atroce pour ceux qui doivent s'y soumettre. Surtout quand on a connu uniquement du code fait à l'arrache et dans l'urgence, modèle tellement horrible qu'on dirait le fils caché d'Elephant Man et de Quasimodo

[Flaburgan]

Je vois pas la différence entre la 1ère et la 4ème catégorie...

Le travail du premier marche de manière efficace, je dirais.

[notia]

Quelle est votre propre définition du vrai développeur et comment faites-vous pour les dénicher ?

Question bien difficile.
Il existe des personnes ayant plus d'expérience dans le développement que d'autres. Il existe des personnes qui décident de consacrer plus de temps à un apprentissage perpétuelle que d'autres.
Faut-il pour autant éjecter ceux qui font de l'informatique que durant leurs horaires de travail, ceux qui ont peu d'expérience, ceux qui se disent qu'il y a peut-être une autre vie en dehors de l'informatique ?

Dans une équipe de développeur, même le mec de niveau moyen peut apporter quelque chose de positif à l'équipe. Il peut être le comique de service qui apporte une ambiance conviviale ou encore le bosseur fou qui une fois la tache complexe expliquée se mettra au travail.

De plus, avec un peu de recule, chacune des classes définies par Benner, peut trouver sa place au sein d'un projet.
Option 1
5 et 3 -> Conception : ils pourraient pondre les grandes lignes de l'application
1 et 2 -> developpement : avec la confrontation des différents points de vue il y a une chance de voir apparaitre 1) un code maintenable et 2) des délais respectables
4 -> correction de bug.

Option 2
1 -> chef de projet
2 -> Conception
3 et 4 -> développement
5 -> Fonctionnelle ou testeur

Etc...

[pcaboche]

Dans une équipe de développeur, même le mec de niveau moyen peut apporter quelque chose de positif à l'équipe. Il peut être le comique de service qui apporte une ambiance conviviale ou encore le bosseur fou qui une fois la tache complexe expliquée se mettra au travail.

Le pire, c'est qu'on peut les 2 à la fois : le comique de service et pourtant un mec compétent. Parce que quand on arrive à un certain niveau de compréhension et qu'on voit tout ce qu'il se passe dans la profession informatique (développement, conduite de projets, RH, commercial, etc) on se dit que tout cela n'est qu'une vaste blague. Et on finit par tout prendre à la légère comme si rien n'avait vraiment d'importance.

En face, par contre, vous avez des gens qui se prennent vraiment au sérieux sans avoir conscience de leur propre médiocrité, d'où un certain regard condescendant et réprobateur : "mais c'est qui ce type ?". - "Ce *type*, c'est celui qui a optimisé nos systèmes et les a rendus utilisables, entre autres..."

Par contre pour le côté "bosseur fou", je ne suis pas trop d'accord. On m'a toujours appris que la plus grande qualité d'un développeur, c'est d'être paresseux. Sinon pourquoi on passerait autant de temps à expliquer à des machines comment travailler à notre place, hein ?

[pseudocode]

Parce que quand on arrive à un certain niveau de compréhension et qu'on voit tout ce qu'il se passe dans la profession informatique (développement, conduite de projets, RH, commercial, etc) on se dit que tout cela n'est qu'une vaste blague. Et on finit par tout prendre à la légère comme si rien n'avait vraiment d'importance.

Autant de lucidité à 30 ans, imagine avec 8 de plus.

[pcaboche]

Autant de lucidité à 30 ans, imagine avec 8 de plus.

Dans 8 ans, je pense que j'en aurai eu marre de l'info et que j'aurai ouvert un bar à putes en Thaïlande...

Du coup, quand on me pose la question "où vous voyez-vous dans 10 ans ?", je me sens obligé de mentir, de peur de ne pas être pris au sérieux...

[pseudocode]

Dans 8 ans, je pense que j'en aurai eu marre de l'info et que j'aurai ouvert un bar à putes en Thaïlande...

Je savais bien que j'avais loupé un tournant décisif dans ma carrière.

[_skip]

Parce que quand on arrive à un certain niveau de compréhension et qu'on voit tout ce qu'il se passe dans la profession informatique (développement, conduite de projets, RH, commercial, etc) on se dit que tout cela n'est qu'une vaste blague. Et on finit par tout prendre à la légère comme si rien n'avait vraiment d'importance.

Ou alors, comme moi, on déserte tout ce qui est administrations, services publics et grosses structures pour travailler dans des petites start-up et des plus petites équipes.
On gagne moins d'argent mais ça évite d'avoir à passer sa langue sur des surfaces velues ainsi que de développer des pulsions psychopathes à terme, surtout si on supporte pas le gaspillage et les process interminables et inefficaces.

[teppyogi]

Il ne manque pas l'artiste qui, à force de revoir ses specs, de rendre son code plus propre, etc. finit par ne rien livrer ? Je me serais bien classé dans cette catégorie

[professeur shadoko]

Totalement d'accord ! Le développement, c'est la loi de l'évolution : si tu restes sur tes acquis, tu meurs (ou tu va faire de la bureaucratie/du management, autre forme d'évolution). Les développeurs d'il y a plus de 20-25 ans ont dû laisser le Fortran, le COBOL et autre Lisp de côté pour rester dans la course. De même, les développeurs actuels devront dire un jour adieu à Java, C# et Python (voire C++ ?) pour peut-être le langage D et Google Go.

Étrangement, il n'y a que le C qui arrive à traverser les époques. Jusqu'à ce qu'il soit décrété comme étant "trop vieux pour l'Informatique" ?

pas totalement d'accord: je fais partie de ceux qui apprennent lentement (surtout parce que je ne tiens jamais rien pour acquis et que , ayant mauvais esprit, je m'interroge sur les motivations de tout ) ... ça m'empêche pas de rebatir sans cesse sur des acquis anciens ....
En terme d'efficacité de codage je me considère comme un "lent à l'allumage" ... j'aurais jamais pu opérer en SSII mais chez des éditeurs de produits ça a super bien marché.

Mon conseil pour les chefs de projet: pour faire un bon ragout il faut de la viande et des légumes .... la diversité dans les équipes est une richesse.

[mortapa]

Parce que quand on arrive à un certain niveau de compréhension et qu'on voit tout ce qu'il se passe dans la profession informatique (développement, conduite de projets, RH, commercial, etc) on se dit que tout cela n'est qu'une vaste blague. Et on finit par tout prendre à la légère comme si rien n'avait vraiment d'importance.

Si seulement c'était valable uniquement dans le domaine de l'info le monde serai un vrais bonheur.

Dans 8 ans, je pense que j'en aurai eu marre de l'info et que j'aurai ouvert un bar à putes en Thaïlande...

j'aurais enlever pute et remplacé par concert, enlever Thailande pour un pays moins trash mais grosso modo l'idée est là

[skandhal]

Ah là là j'adore!

Je pense, pour reprendre les termes de _skip que je me verrais dans la catégorie des artistes incompris

Sérieusement y a des messages à mourir de rire

[lordrt]

l'option 3 n'est pas mal, pourquoi se prendre la tête pour développer quelque chose qui existe déjà et qu'on peut adapter à son besoin