Discussion :

[Invité]

pour moi y a une grande différence entre la maitrise d'un framework et les bases techniques d'un langage. la non maitrise de spring, hibernate ou n'importe quel framework fait il de moi un mauvais développeur non je ne crois pas

Voilà tu y viens. Un bon développeur c'est maîtriser les bases techniques du langage de programmation mais aussi assurer sa veille technologique pour être au top et répondre au besoin du marché sans attendre à être dans le vif du projet. Va à un entretien où les gars recherchent quelqu'un qui maîtrise Hibernate et tu leur sors : "Hibernate je ne l'ai jamais utilisé mais je suis expert Java donc je n'aurai aucun problème à m'en sortir". La maîtrise de Hibernate ne dépend pas uniquement que tu maîtrises Java mais que tu ais la capacité à t'auto-former, à être curieux, être passionné pour découvrir des choses.
Un bon développeur doit être bon techniquement mais doit au moins se mettre à jour tous les jours en assurant sa veille. Un développeur est un éternel étudiant. Tu assures ta veille technologique alors tu es bon au jour le jour sinon à l'instant T où tu t'arrêtes d'étudier tu te dégrades techniquement.

[Logan Mauzaize]

Certaines choses sont pour moi indispensable quelque soit le contexte, et constitue un socle:
L'autonomie, la communication dans l'équipe, la capacité de s'auto-former

Je pense quelque sois le contexte, l'environnement le développeur a besoin du minimum de bagages techniques pour répondre aux besoins fonctionnels.

On parle pas du développeur minimum mais du "bon développeur", il ne faudrait pas confondre !

Vu que le besoin fonctionnel est contextuel, le minimum est alors contextuel !
D'ailleurs est-ce que tu inclus l'environnement technique dans le besoin fonctionnel ?

pour moi y a une grande différence entre la maitrise d'un framework et les bases techniques d'un langage. la non maitrise de spring, hibernate ou n'importe quel framework fait il de moi un mauvais développeur non je ne crois pas

Ne pas être "bon", ne veut pas dire qu'on est "mauvais" ...
Sur un projet connaître un framework sera vitale et sur un autre pas du tout. Exemple j'ai une application en Swing ou en SWT, il y a une certaine logique à avoir. Idem si je bosses avec Struts ou JSF.

Certains seront des billes techniquement mais fonctionnellement ils sont au top, ils ponderont quelque chose de plus fiable au final.

[omarcisses]

Vu que le besoin fonctionnel est contextuel, le minimum est alors contextuel !
D'ailleurs est-ce que tu inclus l'environnement technique dans le besoin fonctionnel ?

le minimum dont je parle est le background technique que doit disposer le développeur. on a beau eu les connaissances fonctionnelles, si elles ne sont pas accompagnées par ce background technique que j'appelle "le minimum" tu ne pourras jamais développer ces fonctionnalités. D'ailleurs c'est ce qui différencie un profil fonctionnel et un profil technique.

Sur un projet connaître un framework sera vitale et sur un autre pas du tout. Exemple j'ai une application en Swing ou en SWT, il y a une certaine logique à avoir. Idem si je bosses avec Struts ou JSF.

Qu'est ce que tu appelle vital?? Car y a des personnes capables de monter en compétences sur un laps de temps sur des frameworks dont il ignorait l’existence.

[lod101]

...on a beau eu les connaissances fonctionnelles, si elles ne sont pas accompagnées par ce background technique que j'appelle "le minimum" tu ne pourras jamais développer ces fonctionnalités.

Je pense que l'inverse est tout aussi "génant". Pour un développeur, ne pas savoir faire une analyse fonctionnelle correcte conduira à un développement non satisfaisant pour le client.

Même sans le qualifier de "bon", pour moi un développeur doit être capable de réaliser l'ensemble des tâches qui vont de l'analyse de besoins à la qualification. C'est ce que l'on m'a enseigné.

A mon avis, le travail du bon développeur n'est pas simplement de bien coder, il doit être aussi bon en analyse fonctionnelle que technique (je passe la communication, l'esprit d'équipe, ...). Si ce n'est pas le cas, je ne le qualifierai pas de "bon développeur".

Ensuite, je ne pense pas qu'un RH, puisse dire ce candidat est un bon développeur, c'est hors de son champ. Il dira éventuellement c'est un bon candidat, il semble avoir le bon profil...

[omarcisses]

Je pense que l'inverse est tout aussi "génant". Pour un développeur, ne pas savoir faire une analyse fonctionnelle correcte conduira à un développement non satisfaisant pour le client.

Même sans le qualifier de "bon", pour moi un développeur doit être capable de réaliser l'ensemble des tâches qui vont de l'analyse de besoins à la qualification. C'est ce que l'on m'a enseigné.

A mon avis, le travail du bon développeur n'est pas simplement de bien coder, il doit être aussi bon en analyse fonctionnelle que technique (je passe la communication, l'esprit d'équipe, ...). Si ce n'est pas le cas, je ne le qualifierai pas de "bon développeur".

Ensuite, je ne pense pas qu'un RH, puisse dire ce candidat est un bon développeur, c'est hors de son champ. Il dira éventuellement c'est un bon candidat, il semble avoir le bon profil...

On dit parfois avant de parler il faut tirer 7 fois la langue. Lis au début de cette discussion et tu saura que j'ai jamais dis que le développeur dois "pisser" du code. Ce moment là est révolu. le développeur n'est plus celui qui reste devant son bureau à coder déconnecter du monde. C'est aussi quelqu'un capable de comprendre les besoins fonctionnels afin de les traduire. Et j'ai jamais prétendu le contraire. là ou se situe le débat c'est est il suffisant de comprendre seulement les besoins fonctionnels ?? j'en crois pas. C'est pour cette raison je parler du background technique qui doit être au service du fonctionnel.

[lod101]

On dit parfois avant de parler il faut tirer 7 fois la langue. Lis au début de cette discussion et tu saura que j'ai jamais dis que le développeur dois "pisser" du code. Ce moment là est révolu. le développeur n'est plus celui qui reste devant son bureau à coder déconnecter du monde. C'est aussi quelqu'un capable de comprendre les besoins fonctionnels afin de les traduire. Et j'ai jamais prétendu le contraire. là ou se situe le débat c'est est il suffisant de comprendre seulement les besoins fonctionnels ?? j'en crois. C'est pour cette raison je parler du background technique qui doit être au service du fonctionnel.

Ma remarque n'avait pas pour but de te contredire ou de te contrarier, mais simplement de donner mon avis et de repartir de ton idée en disant :
"On a beau avoir les connaissances techniques, si elles ne sont pas accompagnées d'une certaine faculté d'analyse fonctionnelle tu ne pourras jamais répondre correctement au besoin du client".

Je tenais simplement à mettre l'accent sur cette aspect, qui me semblait discret (pas absent) dans cette conversation.

Comme nous sommes d'accord sur l'importance de cette notion et qu'elle est désormais bien abordée je suis rassuré...

[omarcisses]

Ma remarque n'avait pas pour but de te contredire ou de te contrarier, mais simplement de donner mon avis et de repartir de ton idée en disant :
"On a beau avoir les connaissances techniques, si elles ne sont pas accompagnées d'une certaine faculté d'analyse fonctionnelle tu ne pourras jamais répondre correctement au besoin du client".

Je tenais simplement à mettre l'accent sur cette aspect, qui me semblait discret (pas absent) dans cette conversation.

Comme nous sommes d'accord sur l'importance de cette notion et qu'elle est désormais bien abordée je suis rassuré...

Sois rassuré car je pense qu'on est tous d'accord pour dire que outre les connaissances techniques, il faut au développeur une certaine faculté d'analyse fonctionnelle.

Ma question partie d'une remarque faite par un recruteur était est ce le niveau des développeurs qui a baissé ou bien les cellules de recrutement ne savent pas poser les bonnes question

[I_believe_in_code]

j'ai jamais dis que le développeur dois "pisser" du code. Ce moment là est révolu. le développeur n'est plus celui qui reste devant son bureau à coder déconnecter du monde.

Personne ne "pisse" du code ; le code ne sort pas de la vessie du programmeur mais de son cerveau. (Evidemment, il faut avoir un cerveau, organe qui se perd)

Il faut bien qu'il reste une poignée de vrais passionnés d'informatique pour l'écrire, ce précieux code, en y passant leurs journées, coupés du monde s'il le faut, pour que les délais soient tenus, et que tout le monde soit content, à commencer par ceux qui ne s'abaisseront jamais à "pisser du code".

[deathness]

Sois rassuré car je pense qu'on est tous d'accord pour dire que outre les connaissances techniques, il faut au développeur une certaine faculté d'analyse fonctionnelle.

Ma question partie d'une remarque faite par un recruteur était est ce le niveau des développeurs qui a baissé ou bien les cellules de recrutement ne savent pas poser les bonnes question

C'est assez difficile de savoir ce que l'on veut, puis ce que l'on doit donc rechercher, et enfin comment tester pour être sur qu'on a bien le bon candidat. Surtout lorsque chacune de ces couches est fait par des personnes/services différents

[el_slapper]

(.../...)Ma question partie d'une remarque faite par un recruteur était est ce le niveau des développeurs qui a baissé ou bien les cellules de recrutement ne savent pas poser les bonnes question

En 1998/2001 on a recruté des hordes de gens qui n'avaient jamais programmé de leur vie et on a essayé d'en faire des programmeurs en quelques semaines. Pour certains(dont moi), ça a marché. Mais la majorité a fini par gicler pour incapacité à faire une boucle simple. Que le "niveau aie baissé", c'est pour moi de la foutaise. Ca ne peut pas être pire qu'à l'époque ou on recrutait effectivement n'importe qui les yeux fermés(et on l'avouait ouvertement au client). Il y a beaucoup d'écoles d'informatiques de nos jours, et si il est possible que la selection ne soit pas meilleure qu'à l'époque, au moins les gens ont un vernis.

De toutes façons, tout le monde n'est pas Don Knuth, et tout le monde veut des dizaines de Don Knuth. Donc les recruteurs ne seront jamais heureux. C'est pareil en football, tous les clubs du monde aimeraient avoir un Messi dans leur équipe..... Et parfois, même lui ne suffit pas à réussir le projet(comme gagner la LdC, ou la coupe du monde).

[omarcisses]

Personne ne "pisse" du code ; le code ne sort pas de la vessie du programmeur mais de son cerveau. (Evidemment, il faut avoir un cerveau, organe qui se perd)
.

"pisser du code" n'est qu'une expression pour désigner des gens qui codent tête baissée. C'est comme lorsqu'on dit qu'une personne code avec ses pieds.

Que le "niveau aie baissé", c'est pour moi de la foutaise. Ca ne peut pas être pire qu'à l'époque ou on recrutait effectivement n'importe qui les yeux fermés(et on l'avouait ouvertement au client). Il y a beaucoup d'écoles d'informatiques de nos jours, et si il est possible que la selection ne soit pas meilleure qu'à l'époque, au moins les gens ont un vernis.

De toutes façons, tout le monde n'est pas Don Knuth, et tout le monde veut des dizaines de Don Knuth. Donc les recruteurs ne seront jamais heureux. C'est pareil en football, tous les clubs du monde aimeraient avoir un Messi dans leur équipe..... Et parfois, même lui ne suffit pas à réussir le projet(comme gagner la LdC, ou la coupe du monde).

Enfin un qui répond à ma question, je partage complétement ton analyse merci

[gangsoleil]

Bonjour,

Il faut bien qu'il reste une poignée de vrais passionnés d'informatique pour l'écrire, ce précieux code, en y passant leurs journées, coupés du monde s'il le faut

Voila exactement l'exemple que j'attendais. Pour moi, ce que tu decris n'est pas un bon developpeur.

La plupart des vrais projets necessitent la participation de plusieurs personnes. Si au milieu de cela, l'un des developpeurs est un geek acharne qui n'en fait qu'a sa tete, meme s'il est techniquement super competent, le projet risque d'en patir.

C'est en ce sens que je disais que la valeur du developpeur depend de celui qui regarde : pour moi, un bon developpeur, c'est une personne techniquement competente qui sait travailler en groupe. Pour d'autres, un bon developpeur est un super crack, peu importe sa sociabilite.

[deathness]

Bonjour,



Voila exactement l'exemple que j'attendais. Pour moi, ce que tu decris n'est pas un bon developpeur.

La plupart des vrais projets necessitent la participation de plusieurs personnes. Si au milieu de cela, l'un des developpeurs est un geek acharne qui n'en fait qu'a sa tete, meme s'il est techniquement super competent, le projet risque d'en patir.

C'est en ce sens que je disais que la valeur du developpeur depend de celui qui regarde : pour moi, un bon developpeur, c'est une personne techniquement competente qui sait travailler en groupe. Pour d'autres, un bon developpeur est un super crack, peu importe sa sociabilite.

Assez d'accord. Pour moi la vrai valeur d'une appli c'est pas dans le code. C'est dans toute les réunions qui ont été faite pour écrire les spec et dossier de conception. La vrai valeur c'est l'ergonomie et les fonctionnalités qui ont été décidé à la base.
La manière dont on l'implémente derrière n'a vraiment pour moi comme qualité que le respect des specs. Même les perfs, dans la plupart des cas ne sont pas vraiment importante.

[Invité]

La manière dont on l'implémente derrière n'a vraiment pour moi comme qualité que le respect des specs. Même les perfs, dans la plupart des cas ne sont pas vraiment importante.

Excuses-moi mais c'est un peu du n'importe quoi que tu dis là.
La qualité logicielle est primordiale. C'est vrai qu'une première version peut répondre à tout ce que le client a demandé mais si la qualité logicielle n'est pas respectée alors bye bye la maintenance évolutive qui ne sera pas facile pour ceux qui viendront après la première équipe ayant développé l'application.

[gangsoleil]

La manière dont on l'implémente derrière n'a vraiment pour moi comme qualité que le respect des specs.

Je ne suis pas d'accord non plus : c'est aussi important d'avoir une bonne qualite de code que le reste, pour la lisibilite, la reprise du code, le bugfix et la maintenance evolutive.

[omarcisses]

La manière dont on l'implémente derrière n'a vraiment pour moi comme qualité que le respect des specs. Même les perfs, dans la plupart des cas ne sont pas vraiment importante.

si je comprends bien, la maintenabilité n'est pas importante car c'est la qualité du code qui l'assure. Va demander à un trader si les perfs ne sont pas importantes pour les applications d'achat et vente en bourse

[gangsoleil]

si je comprends bien, la maintenabilité n'est pas importante car c'est la qualité du code qui l'assure.

Nop.

Si tu ecris du code clair, mais que tu as une application dont le design n'a pas ete pense pour evoluer, ta maintenabilite est pourrie.

Va demander à un trader si les perfs ne sont pas importantes pour les applications d'achat et vente en bourse

Dans ce cas, les perfs font partie des specifications. Comme dans beaucoup d'autres domaines d'ailleurs.

[omarcisses]

Nop.

Si tu ecris du code clair, mais que tu as une application dont le design n'a pas ete pense pour evoluer, ta maintenabilite est pourrie.


Dans ce cas, les perfs font partie des specifications. Comme dans beaucoup d'autres domaines d'ailleurs.

Je pense que la tu confond mouton et bouton.
Le fait qu'un code soit clair fait il de lui un code de qualité. NONNNNNNN

je reprends cette phrase de deathness "la manière dont on l'implémente derrière n'a vraiment pour moi comme qualité que le respect des specs" la on me parle de maniere. la maniere c'est pas seulement la clarté du code. elle comprends aussi le design.

[gangsoleil]

Je pense que la tu confond mouton et bouton.
Le fait qu'un code soit clair fait il de lui un code de qualité. NON

je reprends cette phrase de deathness "la manière dont on l'implémente derrière n'a vraiment pour moi comme qualité que le respect des specs" la on me parle de maniere. la maniere c'est pas seulement la clarté du code. elle comprends aussi le design.

Je comprends de moins en moins ce que tu dis... Est-ce que tu peux essayer de reformuler ?

Pour moi, le respect des specs, ca concerne les fonctionnalites, et l'ergonomie. Sauf cas exceptionnel, je n'ai quasimment jamais vu de spec precisant des qualites de code, ni de la maintenabilite, ni quoi que ce soit du genre. Ne serait-ce que parce que c'est subjectif.

[omarcisses]

Pour moi, le respect des specs, ca concerne les fonctionnalites, et l'ergonomie. Sauf cas exceptionnel, je n'ai quasimment jamais vu de spec precisant des qualites de code, ni de la maintenabilite, ni quoi que ce soit du genre. Ne serait-ce que parce que c'est subjectif.

Voila ce que je voulais dire en d'autre termes on peut respecter les spec sans que notre code sois de qualité. et la clarté du code n'inclut pas qu'il soit un code de qualité. On peut aussi respecter notre spec sans que le l'appli sois maintenable. d'où je trouve bizarre qu'on me dise "la manière dont on l'implémente derrière n'a vraiment pour moi comme qualité que le respect des specs"