Qu'est ce que c'est un bon développeur

Bonjour,

Ce matin, j'ai parlé avec une personne responsable de la validation technique de notre boîte pour le cellule de recrutement. Il m'a fait savoir que de nos jours, il devient de plus en plus difficile de trouver un bon développeur. Et je me suis posé la question à savoir qu'est ce c'est un bon développeur? Car ayant passé des entretiens il m'arrive parfois qu'on me pose des questions qui ne révèle pas vraiment le niveau du développeur comme par exemple le nombre de design pattern qu'il existe et combien de famille peut-on les classer. Pour moi un bon développeur c'est quelqu'un qui même s'il ne connait pas un langage ou un framework est capable d'analyser pour sortir un algorithme (simple et efficace) capable de répondre au besoin. Quel est le plus important entre la capacité de résonner et de trouver un algo face à un problème ou de connaitre les mots clé d'un langage. Est il plus important de connaitre la liste des design patterns ou savoir les utiliser au moments requis. Bref Est ce le niveau des développeurs qui a baissé ou bien les cellules de recrutements ne savent plus poser les bonnes questions?

Je pense que j'avais vu la citation suivante dans la signature d'un membre du forum je crois :

Citation:

---

Un bon développeur lui il demande où se trouve la bonne information.
Un développeur confirmé lui il sait où se trouve la bonne information.
Un développeur expert lui il expose la bonne information.

---

ça ne répond pas exactement à ta question mais on sait tous qu'il n'existe pas un développeur qui n'ait jamais "googler" un problème à la recherche d'une solution à son problème.

Ya un peu des deux...
Il n'y a pas vraiment de réponse, ca dépend de la mission, du contexte entreprise, de l'equipe!
Un gars qui va venir tout chambouler dans une entreprise vieillote avec des gens qui bossent depuis 10 ans sur un produit, et qui ne soucis guère de comment vont pouvoir suivre les autres, c'est peut etre un très bon technicien mais beaucoup trop nez dans le guidon à mon sens!
Sinon il y a aussi l'informatique qui évolue très vite, et un recruteur d'aujourd'hui etait peut etre un très bon developpeur il y a 10 ans mais c'est pas forcément les même compétences aujourd'hui! (beaucoup plus de framework, utilisation massive d'internet, IDE)Donc il peut estimer qu'un gars qui connait pas le nom exact de la fonction toto de la classe Chose est un naze parceque lui il n'avait pas l'auto complétion et qu'il existait 10 fois moins de fonctions[...]

Après j'ai déjà vu des gars content parcequ'ils connaissent par coeur tout plein de pattern et autre bonne facon de faire, mais qui sont incapable de penser 30s au fait que le produit qu'il livre est une daube au niveau utilisation! Mais je te rassure il y a vraiment des gars compétent qui savent faire les deux:P.

Bref tout le monde s'estime plus ou moins bon (pas tous j'ai vu des gens assumés ne pas l'être) et c'est vrai en partie dans une tâche précise, beaucoups moins dans l'ensemble de ce qu'est le métier de developpeur;).

Citation:

---

Envoyé par micka132

(.../...)
Après j'ai déjà vu des gars content parcequ'ils connaissent par coeur tout plein de pattern et autre bonne facon de faire, mais qui sont incapable de penser 30s au fait que le produit qu'il livre est une daube au niveau utilisation! Mais je te rassure il y a vraiment des gars compétent qui savent faire les deux:P.
(.../...)

---

Le tout par coeur, cancer de l'enseignement supérieur(et pas qu'en France, hélas).

Citation:

---

Envoyé par omarcisses

qu'est ce c'est un bon développeur?

---

Beaucoup trop vague pour répondre dans l'absolu. Est-ce qu'on attend les mêmes qualités de quelqu'un qui va programmer un module d'assistance à la chirurgie en bloc opératoire, et d'un développeur web qui va bosser sur le dernier réseau social à la mode ? Probablement pas.

Sinon, avant que ce post dégénère en troll sur l'utilité des design patterns, je rappelle que ceux-ci ont aussi pour but à l'origine d'établir un vocabulaire commun de sorte que les développeurs puissent communiquer entre eux en étant sûrs qu'ils parlent de la même chose. Si mémoriser tous les design patterns de la terre et leur classification par coeur est évidemment stupide, connaître les principaux permet un gain de temps et d'efficacité énorme lorsqu'on travaille en équipe. Se reposer sur un socle de concepts solides que d'autres ont fondés avant nous reste la base de toute discipline (scientifique, d'ingénierie, d'artisanat, etc.)

Citation:

---

Envoyé par Luckyluke34

Si mémoriser tous les design patterns de la terre et leur classification par coeur est évidemment stupide, connaître les principaux permet un gain de temps et d'efficacité énorme lorsqu'on travaille en équipe. Se reposer sur un socle de concepts solides que d'autres ont fondés avant nous reste la base de toute discipline (scientifique, d'ingénierie, d'artisanat, etc.)

---

Ce qui est marrant c'est avant cette entretien j'avais lu le livre "Design Patterns" que je trouve très bien et que je conseille à tout développeur. Ça ne m'aurais pas choqué si on m'avait demandé mes connaissances sur tel ou tel design pattern et son utilité. mais à mon arrivée on me donne une questionnaire en java ou les questions sont déjà faites. pas de question sur la manière de voir les choses, que faire faces à certaines situations, suis je capable de d'être autonome, sur mes capacités à trouver des solutions faces à des problèmes. je trouve que ça pousse les gens à faire du par cœur .

Bien sur que les designs patterns sont devenus important voir "incontournable" dans le monde de développement actuel. Mais faut il les retenir tous pour être un bon développeur je ne crois pas

Citation:

---

Envoyé par omarcisses

qu'est ce c'est un bon développeur?

---

Celui qui repond a tes criteres.

Citation:

---

Envoyé par omarcisses

Quel est le plus important entre :

• la capacité de résonner et de trouver un algo face à un problème
• connaitre les mots clé d'un langage

Est il plus important de connaitre la liste des design patterns ou savoir les utiliser au moments requis ?

---

Si tu as des reunions quotidiennes sur les DP, il est absolument necessaires de les connaitre parfaitement, et de ne pas se melanger.
Si tu fais des petits programmes de quelques milliers de lignes, tout seul dans ton coin, peu importe le DP tant que le programme fonctionne et n'est pas trop bugge.

Citation:

---

Envoyé par omarcisses

Est ce le niveau des développeurs qui a baissé ou bien les cellules de recrutements ne savent plus poser les bonnes questions?

---

Il faut distinguer deux types de recruteurs : les responsables techniques qui t'auront sous leurs ordres au quotidien, et les autres, qu'ils soient RH ou responsable commercial important peu.

Cas du responsable technique : si tu ne sais pas faire ce qu'il te demande, il va perdre du temps a te l'expliquer, a te montrer, ... Il joue donc gros lors d'un recrutement, et doit absolument trouver la personne correspondant au poste. Par contre, il n'a que rarement le pouvoir de decision.

Cas du RH / commercial / autre : il ne te verra pas au quotidien, et ne connait probablement pas la difference entre read et write. Par contre, il sait que dans ton CV il y a le bon mot-cle, qu'il doit te proposer un salaire le plus bas possible, ... Par contre, son pouvoir sur la decision finale est souvent assez grand.


Dans chacun des cas, le "bon developpeur" ne sera pas le meme.

Exemple :
Un type qui a fait de la prog objet pendant 10 ans, qui code en Java et en C++ en environnement Windows aura probablement peu de mal a se former en .Net, et sera donc un bon candidat pour le responsable technique.
Par contre, il n'a pas d'experience .Net dans son CV, donc ce mot-clef n'apparait nul part. Il ne sera meme pas visible pour les RH ou les commerciaux.

Est-ce que c'est un bon ? A toi de juger.

Citation:

---

la capacité de résonner

---

Pour la capacité de résonner, c'est pas nécesaire; d'ailleurs, je préfère une cloche ou un tuyau d'orgue pour cet usage.

Si il s'agit de la capacité de raisonner, oui, ça peut être utile pour un développeur.

:mouarf:

Citation:

---

Envoyé par Bluedeep

Pour la capacité de résonner, c'est pas nécesaire; d'ailleurs, je préfère une cloche ou un tuyau d'orgue pour cet usage.

Si il s'agit de la capacité de raisonner, oui, ça peut être utile pour un développeur.

:mouarf:

---

Désolé merci pour cette correction car j'avais pas relu

Citation:

---

Envoyé par gangsoleil

Exemple :
Un type qui a fait de la prog objet pendant 10 ans, qui code en Java et en C++ en environnement Windows aura probablement peu de mal a se former en .Net, et sera donc un bon candidat pour le responsable technique.
Par contre, il n'a pas d'experience .Net dans son CV, donc ce mot-clef n'apparait nul part. Il ne sera meme pas visible pour les RH ou les commerciaux.

Est-ce que c'est un bon ? A toi de juger.

---

Je suis d'accord avec toi mais là tu parles des critères pour mieux placer un développeur chez un client et pas de son niveau technique. ce que j'ai du mal à entendre c'est le termes "bon développeur" en se basant seulement sur des critères autre que techniques. je te donne un exemple :

J'ai travaillé avec un développeur qui ne savait même pas faire les choses les plus simples en programmation (qui me met "if(x-0)==x"), a chaque fois qu'il faisait une chose on était obligé de repasser pour corriger mais qui avait un bon tchatte ,très gentil. Est ce un bon développeur alors qu'il possède tous les critères pour être placé ?? j'en doute

Citation:

---

Envoyé par omarcisses

tu parles des critères pour mieux placer un développeur chez un client et pas de son niveau technique.

---

Non, je montre juste que le niveau d'un developpeur depend de celui qui juge.

Tu es technique, tu cherches donc a quantifier le niveau technique d'un developpeur, c'est normal. Mais un RH aura d'autres criteres que toi.

Autre exemple, en base de donnee (ultra simple) :
Comment fait-on une jointure ?

• Reponse 1 : ah bah il faut deux tables, et puis il faut que l'une des colonnes de la premiere soit la meme chose que l'une des colonnes de la seconde
• Reponse 2 : Ah bah je sais pas, mais c'est le 4 eme bouton a gauche en haut dans Eclipse avec Hibernate.

Qui est le meilleur developpeur ? Celui qui connait les mecanismes internes mais va avoir besoin d'internet pour faire une jointure, ou bien celui qui ne sait pas ce qu'il fait, mais qui a deja finit et qui t'attend au cafe (d'ailleurs, qu'est-ce que tu fous, c'est pas vrai, il est lent ce mec) ?

Toi, tu vas preferer un certain type de developpeur. Le voisin, un autre.

Citation:

---

Envoyé par gangsoleil

Toi, tu vas preferer un certain type de developpeur. Le voisin, un autre.

---

Même si les gout et les couleurs ne se discutent pas je pense qu'on est dans un milieu qui demande un minimum de connaissances. Après je suis d'accord qu'un bon développeur pour un team leader n'est pas le même que celui d'un fonctionnelle. Mais je pense qu'importe le choix il y'a un niveau requis. C'est mon point de vue

Citation:

---

Envoyé par gangsoleil

Toi, tu vas preferer un certain type de developpeur. Le voisin, un autre.

---

Ouais, mais dans l'exemple que tu donnes, les deux paraissent en dessous du minimum. (si tu dois aller sur internet pour la syntaxe SQL d'une jointure, il y a clairement un problème - alors que pour la syntaxe SQL des fonctions de fenétrage par exemple, ça peut se comprendre).

http://www.drdobbs.com/architecture-...sign/240001941

Et

http://www.drdobbs.com/architecture-...sign/240001472

Gangsoleil a parfaitement répondu à la question en disant :

Citation:

---

Envoyé par gangsoleil

Celui qui repond a tes criteres.

---

Tout dépend de la personne en face de toi et qui te pose les questions.
Mais c'est en mettant les mains dans le cambouis qu'on reconnaisse les bons et les mauvais mais il faut noter que cela dépend du projet et de la capacité du développeur à appréhender la problématique et à apporter des solutions et surtout en prenant du recul (on n'est pas là pour utiliser toutes les dernières technos si elles ne sont pas efficaces par exemple)

Après tout on est peut-être meilleur que quelqu'un mais il faut aussi savoir comme on est tous le con de quelqu'un on est aussi le mauvais développeur de quelqu'un :ccool:

Je confirme qu'être "bon développeur" n'est valable que pour un contexte, une situation et un instant donné.
En vrac on pourrait avoir les critères suivants :

• Rapidité d'exécution
• Elegance d'execution
• Expertise dans un domaine
• Connaissance étendue
• Communication équipe
• Communication externe
• Capacité d'abstraction
• Capacité de synthèse
• etc.

Bref tu peux encore en trouver des milliers.
A chaque contexte, la priorité sur ces critères sera différente. Et donc un bon développeur dans un contexte pourra être considéré comme médiocre dans un autre contexte.
D'ailleurs c'est souvent le but des entretiens (RH ou plus technique) savoir évaluer si tu correspond à l'entreprise, à l'équipe, au client, etc.

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.

Le reste après dépend surtout du contexte.

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

Citation:

---

Envoyé par omarcisses

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

---

Si on te dit que le fait qu'un développeur est bon techniquement selon le contexte ce n'est pour rien.

Je prends exemple sur toi. Tu es développeur Java qui maîtrise les frameworks X et Y (et que tu es même certifié sur ceux-ci) mais tu as quand même mis le framework Z dans ton CV alors que tu n'as pas que des notions sur celui-ci.
La RH remarque ton CV en se basant sur les mots clefs. Vu que le framework Z fait partie de ton CV et tes certifications enfonçant bien le clou, la RH te considère comme un très bon développeur surtout que la majeur partie des développeurs déjà embauchés ne les a. Alors tu obtiens un entretien qui ne sera pas du tout technique. Tu fais bonne impression niveau communication et tu montres que tu t'intéresses au projet. Cool ensuite viens l'entretien avec le chef de projet (espérons qu'il soit technique) qui te pose des questions basique sur le langage Java et aussi sur tous les designs patterns. Là tu t'en sors tant bien que mal et tu obtiens au final le job parce que le chef de projet a considéré que même avec les notions tu pourras vite t'en sortir en t'auto-formant.

Tu intègres une équipe. Disons que tu es la 4ème personne embauchée. Au bout de quelques jours tu te rends compte que tes 3 collègues sont hyper calés sur le framework Z, connaissent toutes les best practices et qu'ils sont obligés de repasser sur tout ce que tu as fait ou touché pour que ça colle bien à la bonne pratique et qu'il n'y ait pas de mauvaises surprises lors du prochain sprint. Après ta ou tes boulettes qui ont empêché la livraison de l'application à la date prévue, tes collègues te regarderont d'une certaine façon et se permettront même de parler de tes compétences de façon globale alors qu'il peut exister de forte chance que s'il s'agissait du framework X ou Y tu seras leur maître :mrgreen:

Citation:

---

Envoyé par h2s84

Si on te dit que le fait qu'un développeur est bon techniquement selon le contexte ce n'est pour rien.

Je prends exemple sur toi. Tu es développeur Java qui maîtrise les frameworks X et Y (et que tu es même certifié sur ceux-ci) mais tu as quand même mis le framework Z dans ton CV alors que tu n'as pas que des notions sur celui-ci.
La RH remarque ton CV en se basant sur les mots clefs. Vu que le framework Z fait partie de ton CV et tes certifications enfonçant bien le clou, la RH te considère comme un très bon développeur surtout que la majeur partie des développeurs déjà embauchés ne les a. Alors tu obtiens un entretien qui ne sera pas du tout technique. Tu fais bonne impression niveau communication et tu montres que tu t'intéresses au projet. Cool ensuite viens l'entretien avec le chef de projet (espérons qu'il soit technique) qui te pose des questions basique sur le langage Java et aussi sur tous les designs patterns. Là tu t'en sors tant bien que mal et tu obtiens au final le job parce que le chef de projet a considéré que même avec les notions tu pourras vite t'en sortir en t'auto-formant.

Tu intègres une équipe. Disons que tu es la 4ème personne embauchée. Au bout de quelques jours tu te rends compte que tes 3 collègues sont hyper calés sur le framework Z, connaissent toutes les best practices et qu'ils sont obligés de repasser sur tout ce que tu as fait ou touché pour que ça colle bien à la bonne pratique et qu'il n'y ait pas de mauvaises surprises lors du prochain sprint. Après ta ou tes boulettes qui ont empêché la livraison de l'application à la date prévue, tes collègues te regarderont d'une certaine façon et se permettront même de parler de tes compétences de façon globale alors qu'il peut exister de forte chance que s'il s'agissait du framework X ou Y tu seras leur maître :mrgreen:

---

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