Discussion :

[Invité]

Après avoir bien réfléchit, je pense qu'un bon programmeur est un programmeur qui se sent alaise dans ce qu'il fait.

Sa manière de nommer les variables et fonctions importe peu, logiquement il n-y a pas de bonne manière pour nommer les variables et fonctions puisque tout est relatif et dépend de la personne.

Ce qui est difficile pour les uns ne l'est pas forcement pour les autres.

Et de toute façon il n-y a pas de bon ou de mauvais programmeur, il y-a juste des programmeurs meilleurs que les autres.

[Saverok]

Un bon développeur sait travailler en équipe
La qualité d'une équipe se mesure à la satisfaction des utilisateurs du programme produit

[Invité]

????

[dream2l]

Un bon developpeur... ca veut dire quoi "Bon"?

Le Dev chez Google, le dev d'un OS, le Dev d'une ROM, le Dev sur ZX80, le Dev de la page web de la boulangerie du coin (script)...
Les 3 sont dit bons pour les users, et pourtant ils ne consomment pas la même quantité de doliprane.lol.
Certains filent leurs sources, d'autres les mettent au coffre...


un bon developpeur... ca veut dire quoi "Bon"?

J'ai tendance a croire qu'un "bon" developpeur se rapproche du CPU/GPU et non des users.

[pmithrandir]

C'est moi ou ce type d'article revient tous les mois pour dire exactement la même chose ? (Nommage, analyser le problème, apprentissage constant...)

Une chose appréciable serait que les blogueurs qui pondent se genre d'article chacun leur tour nous donnent quelques conseils pour les mettre en application.

Le nommage. Comment bien nommer une variable ? numeroDeTelephone, numTel, ndt, phoneNumber ?

Pour la personne qui dit qu'il faut avant tout être passionné,
Pourquoi est-ce qu'un développeur doit être passionné pour bien faire son travail?
Est-ce qu'on en ai encore à se dire que le meilleur c'est celui qui code toute la nuit et qui à 15 projets perso en cours?
Un déménageur peut parfaitement faire son boulot sans être passionné, pourquoi ça ne pourrait pas être le cas dans le développement informatique?

Je pense que la programmation demande une part importante de créativité.
On trouve peu de personne qui n'aiment pas leur métier et qui continu à faire preuve de créativité.

[Invité]

Un bon developpeur... ca veut dire quoi "Bon"?

Le Dev chez Google, le dev d'un OS, le Dev d'une ROM, le Dev sur ZX80, le Dev de la page web de la boulangerie du coin (script)...
Les 3 sont dit bons pour les users, et pourtant ils ne consomment pas la même quantité de doliprane.lol.
Certains filent leurs sources, d'autres les mettent au coffre...


un bon developpeur... ca veut dire quoi "Bon"?

J'ai tendance a croire qu'un "bon" developpeur se rapproche du CPU/GPU et non des users.

On parle du programmeur (en général) presque parfait.

[Canvas]

On pourrait ajouter qu'un bon programmeur doit savoir se mettre à la place de l'utilisateur lambda (voire beta)

----
Canvas

[iNaKoll]

Un bon développeur ? Un mec qui donne toujours l'impression de faire rapidement ce qu'on lui demande et qui arrive jusqu'à un certain point à décorréler la logique d'entreprise de la qualité du travail accompli.. Au final un bon développeur doit surtout savoir se vendre correctement. Les autres qualités viennent avec l'expérience. Qu'on le veuille ou non, un développeur est un coût... C'est peut-être légèrement différent dans les pays anglo-saxons.

[Zefling]

Quelqu'un a regardé Papy Grenier

Tu veux dire Les Inconnus ?

[fcx35]

100% d'accord avec Warne.

Ces 5 points sont des objectifs vers lesquels il faut tendre...

D'un point de vue 'technique', il faut, bien sûr, s'aider de tous les outils possibles (fonctions refactoring des ide, git, bien connaître les possibilités de son langage, ...).

D'un point de vue 'objectif', si professionnellement on a trop de contraintes de temps ou d'environnement rigides, il faut essayer de progresser sur les 5 points sur des devs perso.

Quand une partie de code, (une classe outils, ...), commence a être stable dans le temps, on peut considérer que c'est un bon développement !

[Pergos]

Pour moi, un bon développeur est aussi un "bon fainéant" qui sait où il passe son temps.

Par exemple, sur de vieilles applications, casser un bout du code, ça a un cout non négligeable en temps de tests, mais un code devenu illisible ou instable, ça a aussi un coût : un bon développeur, en "bon fainéant" qu'il est, est capable de savoir quand le fait de casser ce bout de code va lui "éviter de perdre trop de temps" sur la maintenance.
Idem pour les noms de variables ou noms de fonctions : se rappeler de tout, ça squatte la mémoire, ça fait passer du temps dans d'autres portions de code pour être sûr qu'on a bien compris à quoi servait la variable/fonction,... Donc renommer intelligemment des variables/fonctions, c'est avoir "moins besoin de monopoliser son cerveau", et passer moins de temps à relire le code.

Bref, un bon développeur est un "fainéant intelligent" !

[jabbounet]

Ce genre de discussion me fait toujours penser a la chasse à la galinette cendrée dans le bouchonois et la différence entre le bon et le mauvais chasseur.

cf:

EDIT: En relisant en détail les messages je vois que je ne suis pas le seul....

[ptah35]

Bref, un bon développeur est un "fainéant intelligent" !

Cela me rappelle un mot de John Backus : "Much of my work has come from being lazy"

[macslan]

Tu veux dire Les Inconnus ?

Il me semblait bien qu'ils avaient repris ce truc de quelque part

[Zefling]

Il me semblait bien qu'ils avaient repris ce truc de quelque part

En même temps, c'est assez souvent repris. Il faut dire, quand on dit « qu'est-ce qu'un bon [placez-ici l'activité] ? ». C'est souvent ça qui vient à l'esprit.

[macslan]

En même temps, c'est assez souvent repris. Il faut dire, quand on dit « qu'est-ce qu'un bon [placez-ici l'activité] ? ». C'est souvent ça qui vient à l'esprit.

Je parle du JdG

[gaby277]

Bonjour,
Ce que dit "Henrik Warne' transcrit par "Hinault Romaric" (en très raccourci décomposer un problème complexe en plusieurs problèmes simples) ça a été dit déjà il y a bien longtemps par René Descartes dans le discours de la méthode !
Par ailleurs cela est n'est pas spécifique à l'informatique et s'applique à bien d'autres techniques.
Donc rien de bien nouveau et de fulgurant mais bon comme on dit ça ne mange pas de pain.

[Bestel74]

C'est moi ou ce type d'article revient tous les mois pour dire exactement la même chose ? (Nommage, analyser le problème, apprentissage constant...)

Une chose appréciable serait que les blogueurs qui pondent se genre d'article chacun leur tour nous donnent quelques conseils pour les mettre en application.

Le nommage. Comment bien nommer une variable ? numeroDeTelephone, numTel, ndt, phoneNumber ?

Pour la personne qui dit qu'il faut avant tout être passionné,
Pourquoi est-ce qu'un développeur doit être passionné pour bien faire son travail?
Est-ce qu'on en ai encore à se dire que le meilleur c'est celui qui code toute la nuit et qui à 15 projets perso en cours?
Un déménageur peut parfaitement faire son boulot sans être passionné, pourquoi ça ne pourrait pas être le cas dans le développement informatique?

Tu ne peux pas comparer 2 métiers aussi différents l'un de l'autre :
Un bon soldat est prêt à mourir pour sa patrie, est-ce que du coup un bon développeur doit-être prêt à mourir pour sa patrie aussi ?

Ce n'est pas parce que la caissière fait du bon travail sans être passionné, que c'est aussi vrai pour un développeur !

Je pense qu'il faut au être un minimum passionné, pourquoi ? Car ça permet de continuer son auto-formation, et de toujours vouloir faire mieux !

EDIT: Du coup sans passion pour moi, le développeur aura beaucoup plus tendance à rester du ses acquis... Si ils sont excellents il pourra faire du très bon travail, mais pour combien de temps ?

[redbullch]

Je pense qu'il est important de nuancer. Dire dans l'absolu que les développeurs passionnés sont plus compétents n'est pas vraiment exact.

Par contre, on peut prendre le risque d'assumer : P(bon développeur|passionné) > P(bon développeur|pas passionné).

[Cyrilange]

Comment ne pas être d'accord avec Henrik Warne. Les 2 premières étapes étant, à mon avis, les plus importantes et trop souvent négligées.