Discussion :

[Stéphane le calme]

Quels sont les critères qui vous permettraient d’estimer si untel est un bon ou un piètre développeur ?
Partagez vos avis

Si la notion de relativité s’étend sur plusieurs domaines comme l’art ou les préférences, d’autres donnent la place à des critères moins subjectifs pour déterminer le bon et le mauvais. En tant que professionnels de l’informatique et développeurs en particulier, quels sont les critères qui vous permettraient d’estimer si untel est un bon ou un piètre développeur ? Nick Kolakowski, rédacteur technique, propose les éléments qui lui semblent les plus adéquats pour pouvoir le déterminer.

• Une aptitude à apprendre : l’un des faits sur lesquels peu de place est laissé pour une antithèse est que la technologie est très évolutive. De nouveaux langages sortent pour répondre à des besoins bien spécifiques, d’autres enrichissent leurs bibliothèques. La technologie est en constante évolution et refuse de demeurer statique. La résultante est très simple : ce qui semble être à la pointe de la technologie aujourd’hui en matière de logiciel ou de matériel peut s’avérer obsolète dans les années voire les mois à venir. Bien sûr, il y a des langages de programmations qui résistent à l’influence du temps, mais ce sont là des exceptions, pas des règles.
  
  A ce rythme, les développeurs qui ne se contentent pas d’acquérir des bases dans les nouvelles technologies qui font leur apparition mais qui gardent dans leurs veilles technologiques des outils pour mettre à jour leurs connaissances sur des plateformes qu’ils maitrisent déjà possèdent un réel avantage. « Observez les développeurs que vous connaissez. Ceux qui trainent sur les forums, posent souvent des questions et s’essaient à de nouvelles plateformes sont ceux qui sont le plus susceptibles de réussir dans leurs carrières ».
  
• Une palette de connaissance étendue : pour Kolakowski, l’expertise dans un ensemble de domaines peu fourni, que ce soit du côté logiciel ou du côté matériel, ne suffit pas. « Un développeur ardu a au moins une certaine expertise dans les serveurs, les clients desktop ainsi que les appareils mobile » a-t-il soutenu. « Vous voulez développer pour le Web? Préparez-vous à connaître Javascript, HTML, CSS, SQL, Node.js, PHP ou ASP.NET, et bien plus encore. Le développement de jeux correspond plus à votre goût ? Non seulement vous aurez besoin d'une solide compréhension de C ++, mais en plus d’une connaissance de UX, de la modélisation, de l’Intelligence Artificielle, et ainsi de suite ».
  
  Selon lui, parce que le développement mobile est de plus en plus fragmentée, un développeur qui veut lancer son logiciel sur une variété de plateformes gagnerait à apprendre Objective-C et Swift (pour iOS), Java (pour Android) mais aussi le C et le C ++ « et ce, avant même de commencer à ingurgiter les subtilités de e-commerce et du marketing ».
  
• Les bugs et les essais : avoir les capacités de concevoir un nouveau logiciel est une chose, mais il faut également savoir comment le rendre aussi meilleur que possible. Même si cela ne nécessite pas de se spécialiser en assurance qualité, un développeur devrait néanmoins être en mesure de résoudre des problèmes rapidement, surtout lorsqu’il est dans une équipe. Si les testeurs assurance qualité sont généralement bien informés dans les langages de programmation les plus populaires, ils disposent en plus d’un éventail de compétences non techniques, parce que la résolution des problèmes de logiciels nécessite souvent l’interaction avec des personnes diverses.
  
• Avoir des compétences non techniques : les compétences non techniques incluent la communication, l'engagement, la flexibilité, l'efficacité et la capacité d'observer son environnement de façon à avoir des idées sur une manière de procéder. Alors que certains développeurs pourraient reléguer les compétences non techniques au second rang, il va de soi qu’ils devront interagir avec des êtres humains sur une base régulière. Dans ce cas, il est donc préférable d’apprendre quelques tours pour que lesdites interactions se passent sans accros.

En définitive donc, pour lui, être un bon développeur ne saurait se résumer à avoir une bonne connaissance d’une palette de technologies et de plateformes, mais également un fort sentiment de curiosité et une volonté d’apprendre et la capacité à développer des aptitudes non techniques.

Source : Insights

Et vous ?

Quels sont les critères qui vous permettraient d’estimer si untel est un bon ou un piètre développeur ? Pourquoi vous paraissent-ils pertinents ?

[RyzenOC]

Quels sont les critères qui vous permettraient d’estimer si untel est un bon ou un piètre développeur ?

Je ne sais pas, par contre les news du style: "Les entretiens d’embauche permettent-ils de trouver le bon développeur ?", "Codeur, programmeur, développeur : y a-t-il une différence ?", "Programmation : qu’est-ce qui est recherché chez un candidat dans un entretien technique ? " ou encore "Qu’est ce qui fait la beauté d’un logiciel ? ",

je vois pas l'interet de ce genre de news, surtout si il y'en 2 par semmaine qui au final veulent dire la meme chose

Enfin je dis sa, mais c'est peut être mieux qu'avant, ou on avait des études bidons toute les 2semmaines style : "
L’erreur humaine est le principal facteur de violation de la sécurité de l’entreprise" ou encore mon préféré "Des chercheurs estiment que les personnes qui se rongent les ongles ou qui s'arrachent les cheveux, peuvent être des perfectionnistes "

[tomlev]

Je pense qu'il faut prendre en compte une large palette de critères pour juger du niveau d'un développeur... Tous les bons développeurs ne sont pas bons dans les même domaines. Il y en a qui sont excellents en algorithmes, mais pas très bons en architecture. D'autres qui écrivent du code pas très propre, mais ont une grande capacité à comprendre (et faire évoluer) des systèmes complexes.

Parmi les principales qualités nécessaires à un développeur, je mettrais (liste pas exhaustive du tout) :
- savoir se remettre en question
- toujours chercher à s'améliorer (ça passe entre autres par la veille technologique : lire des articles, essayer de nouvelles technos, etc)
- s'attacher à suivre les bonnes pratiques dans la mesure du possible... et savoir quand s'en écarter

[Gulien]

D'accord avec sazearte, on tourne en rond sur ces sujet.
Je pense que la plupart des devs aujourd'hui ont acquis les grands axes qui font qu'un logiciel est de qualité (acquérir ne veut pas dire pratiquer : Faute de temps, de moyens, de patience, flemme ...)

Pour moi un bon dev, c'est celui qui termine un projet qui fonctionne (c'est déjà un bon point) et qui est arrivé à faire quelque-chose de transmissible, maintenable, répétable, modulable (ce dernier point est je pense le plus difficile, étant donné qu'il demande une vue assez haute sur les environnements qu'on utilise, et que lorsqu'on débute un projet, ça se passe souvent sur un nouvel outil que l'on découvre).

[MichaelREMY]

Quels sont les critères qui vous permettraient d’estimer si untel est un bon ou un piètre développeur ? Pourquoi vous paraissent-ils pertinents ?

un bon développeur :
- doit penser toujours à celui qui viendra relire/refaire/corriger/terminer son propre code pour lui faciliter le travail
- être rigoureux / méthodique
- être très curieux, même avec excès


un mauvais développeur :
- a beaucoup de préjugés techniques et s'y tient
- n'aime pas les docs (longue ou courte) et veut qu'un travail soit faisable ou domptable tout de suite
- n'a vu et pratiqué longuement qu'un seul langage dans sa vie

En tant que professionnels de l’informatique et développeurs en particulier,

un peu bizarre de juger un confrère.
Je pense que les critères d'un bon dvp/ou mauvais varient forcément suivant que l'on soit cdp, développeur en équipe développeur solo, pdg d'une startup, commercial ou ingénieur d'affaire.
Pour une , un bon développeur peur être une personne qui travaille très mal mais qui rend quand-même un travail accompli qui fera gagner de l'argent
Pour une autre, un bon développeur sera juste une personne qui travaille bien et honnêtement même si elle a du mal à terminer dans les temps et à apporter une valeur ajoutée à l'entreprise (ce qui n'est pas le point de vue d'un cdp ou commercial)

[ustensile]

Pour résumer un peu tout et donner mon avis un peu, citons ici un gars qui fait un site sympa sur Python, un bon dev doit :

-faire du code qui marche
-faire du code qui continue à marcher
-faire du code dont on sait pourquoi il marche
-donner envie de bosser avec

[el_slapper]

Et puis tout ça dépend hautement des circonstances. Il y a des endroits ou ils ont été heureux de me voir partir, d'autres ou ils flippaient leur race quand je suis arrivé à la limite des trois ans. Donc, suivant l'endroit et les circonstances, je suis un bon développeur...ou pas(de toutes façons, je suis testeur, maintenant).

[MichaelREMY]

j'ajoute ma complétion en gras à ton avis

Pour résumer un peu tout et donner mon avis un peu, citons ici un gars qui fait un site sympa sur Python, un bon dev doit :

-faire du code qui marche dans le temps imparti par le cdp pour que le projet soit rentable.
-faire du code qui continue à marcher et qui soit facilement corrigeable , à maintenir par autrui
-faire du code dont on sait pourquoi il marche c-a-d correctement commenté et structuré
-donner envie de bosser avec

par contre je ne suis pas d'accord avec votre dernière proposition.
Qu'une personen donne envie de bosser avec elle ou pas est trop subjectif. ça dépendrait de vous alors ? que vous consédérez que tout le monde doit être en accord avec votre personnalité..? un peu trop nombriliste je trouve.
Une personne peut être chiante au quotidien, ou qui a un parfum qui te déplaît à toi, ou qui s'habille avec des goûts qui te gêne, qui a une religion qui te déplait n'est pas un critère de bon développeur ni un critère de mauvais développeur.

Think entreprise en premier, et non pas collègue ou buddy d'apéro!

[Sodium]

C'est très simple. Un bon développeur c'est un développeur qui fait ce que je lui dit, rapidement, de la manière dont je l'aurais fait et en adoptant à la lettre mes conventions de nommage.

[elpaulo]

J'aurais tendance à être de l'avis d'ustensile sur ce point.

C'est pour moi important de bosser avec des gens qui y mettent de la bonne volonté, ne sont pas défaitistes, sont globalement positifs. Bosser avec une grande gueule qui voit tout en noir, pour qui un projet est perdu d'avance, et qui fout une sale ambiance, c'est mauvais parce que ça se répand comme la peste, et tu finis avec tout l'open space influencé par ce genre de personnes.

Donc oui, hors de l'affectif subjectif, il y a des comportement à adopter en entreprise pour que tout ce passe bien, et ce n'est clairement pas à sous-estimer.

[FaridM]

J'ai l'impression de voir ce sujet toutes les semaines... On à toujours pas trouvé la recette miracle pour recruter que des bons développeurs??

[hotcryx]

En aidant un collègue à corriger un bug dans son code c# (développé par un autre),

je lui dis: "ici, en pointant un "if" du doigt, tu mets 'égal null' "

lui: "quoi, = null ?"

moi: "non, == null"

(grilled forever)

[hotcryx]

C'est très simple. Un bon développeur c'est un développeur qui fait ce que je lui dit, rapidement, de la manière dont je l'aurais fait et en adoptant à la lettre mes conventions de nommage.

Je suis d'accord avec toi mais ça risque de vite tourner à la dictature informatique

Comme on dit chez nous: "on n'est jamais mieux servi que par soi-même"

[lankoande]

Décidément ce sujet reste sans solution !
De mon point de vu, un bon programmeur c'est un programmeur qui s'est faire un bon programme/logiciel.
Un bon programme/logiciel c'est un programme qui répond aux mieux aux attentes des clients.
Le bon programmeur est également une personne qui reconnaît ses limites et qui vise toujours toujours la perfection. !

[MichaelREMY]

Décidément ce sujet reste sans solution !(...)!

comme je l'ai dit plus haut, personne n'a défini ce que c'est un bon développeur.
le définition varie suivant que ce soit vue par un un développeur lui-même, par un cdp, par un dsi, par pdg, par un recruteur ou RH.
et ça dépend aussi de la taille de l'entreprise.

[Sodium]

Je suis d'accord avec toi mais ça risque de vite tourner à la dictature informatique

Comme on dit chez nous: "on n'est jamais mieux servi que par soi-même"

Vu les trois votedown du post j'en déduis que certaines personnes sont de piètres déceleurs de second degré

[manu007]

Lorsque je dois embaucher un programmeur, deux critères m'indiquent qu'il est la personne correcte:

1) Sa possibilité a se mettre en cause
2) Son habilité a faire le moins possible

1) M'indique qu'il pourra s'habituer a n'importe quelle nouvelle téchnologie ou défi,
2) Bien contrôlé, il écrira un code court et très vite. Un code est court est facilement maintenu.

J'ai jamais étè déçu.

[MichaelREMY]

Lorsque je dois embaucher un programmeur, deux critères m'indiquent qu'il est la personne correcte:

1) Sa possibilité a se mettre en cause
2) Son habilité a faire le moins possible

1) M'indique qu'il pourra s'habituer a n'importe quelle nouvelle téchnologie ou défi,
2) Bien contrôlé, il écrira un code court et très vite. Un code est court est facilement maintenu.

J'ai jamais étè déçu.

ton (1) n'indique pas ce que tu penses.
Savoir se remettre en cause, signifie pouvoir douter de son propre travail et le revérifier même si il est sûr de lui.

Ce que tu penses (s'habituer à n'importe quelle nouvelle techno) est la qualité de fléxibilité et de curiosité associées

[petitours]

un élément de réponse complémentaire

le bon développeur envoi en production un code qui marche, sans bugs (au moins les premières minutes d'utilisation) et avec une ergonomie ou documentation pour l'utilisateur largement travaillée pour que son travail soit reçu de manière positive.
Bref le bon developpeur est pragmatique, le résultat est fondamental pour lui, en plus des qualités technoco/techniques de son métier de codeur évoquées plus haut.

[Dendrite]

Ce n'est pas parce qu'un sujet est bateau qu'il est inintéressant !
Sinon, plus personne ne parlerait de la pluie et du beau temps, et ce jour n'est pas près d'arriver !
Bref, on s'est tous demandés un jour "Suis-je un bon développeur ?".
Et l'on en trouve des meilleurs, et des pires... et l'on n'est guère avancé.

Ce qui me fait du bien, c'est le ZEN de Python, bien que je ne développe pas en Python, j'essaie de l'appliquer car ce sont de bons conseils.
Et pour la beauté, je vous le mets en anglais, parce qu'en plus, en anglais, ce sont de beaux conseils, ça ressemble presque à une prière.

Préfèrer le beau au laid,
l’explicite à l’implicite,
le simple au complexe,
le complexe au compliqué,
le déroulé à l’imbriqué,
l’aéré au compact.
La lisibilité compte.
Les cas particuliers ne le sont jamais assez pour violer les règles,
même s’il faut privilégier l’aspect pratique à la pureté.
Ne jamais passer les erreurs sous silence,
ou les faire taire explicitement.
Face à l’ambiguïté, ne pas se laisser tenter à deviner.
Il doit y avoir une – et si possible une seule – façon évidente de procéder,
même si cette façon n’est pas évidente à première vue, à moins d’être Hollandais.
Mieux vaut maintenant que jamais,
même si jamais est souvent mieux qu’immédiatement.
Si l’implémentation s’explique difficilement, c’est une mauvaise idée.
Si l’implémentation s’explique facilement, c’est peut-être une bonne idée.
Les espaces de nommage sont une sacrée bonne idée, utilisons-les plus souvent !

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one– and preferably only one –obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea – let’s do more of those!