Discussion :

[keskispas]

Un programmeur passe entre 10 et 20% de son temps à coder, et écrit en moyenne 10 à 12 lignes de code par jour qui seront incluses dans le produit final (peut importe leur niveau).

12 lignes/jour ??? J'avoue que c'est la phrase qui m'a le plus surpris. Peut-être ne travaillait-il que sur des réécritures ou il disposait d'une énorme bibliothèque. Mais il a bien fallu l'écrire ce code de base : c'est le boulot des mauvais programmeurs ?

Les bons programmeurs pensent à leur travail tous les jours, 24 heures sur 24.

Ben alors ça, même pas en rêve : une fois la journée terminée, je zappe ! Ou alors c'est que je travaille sur un projet personnel.

[Génoce]

J'ai remarqué qu'un bon programmeur fait des IHM très laides aussi

Me voila rassuré, je suis pas si mauvais alors !

[SekYo]

j'imagine s'il s'agissait de construction automobile , batiment , aéronautique , production d'énergie nucléaire , médecine ...
à part les prévisions météorologiques , existe-t-il un autre secteur où on puisse se permettre de tels chiffres ?

Le bâtiment est réputé (à tort peut-être) pour ses taux de satisfaction assez bas également. D'ailleurs c'est marrant qu'on emprunte beaucoup de vocabulaire à ce secteur

[kaymak]

+10.

Par ailleurs je me trouve tellement bête à laisser un commentaire si fluet que j'aurai préféré un sondage @Katleen !!!
Mais bon tant pis, il parait que c'est dans la nature des bons programmeurs que d'écrire peu ; )

[davcha]

12 lignes/jour ??? J'avoue que c'est la phrase qui m'a le plus surpris. Peut être ne travaillait-t'il que sur des réécritures ou il disposait d'une énorme bibliothèque. Mais il a bien fallu l'écrire ce code de base : c'est le boulot des mauvais programmeurs ?

C'est les joies de l'open-source :

Des gens peu scrupuleux débutent un projet open-source, font un gros buzz dessus, d'autres personnes naïves viennent leur prêter main forte et font tout le boulot.
Mais au final ils sont tellement nombreux que chacun d'entre-eux a peut-être écrit 60 lignes de code au total dans ce projet, étalé sur 5-6 jours, entre midi et deux ou le soir en compagnie de leur femme qui regarde secret story à la télé.

Plus tard, le projet est mature, les gens peu scrupuleux du début récupèrent tous les lauriers, grâce à leurs adeptes fanboys qui les ont aidés.

A ce moment là, les gens peu scrupuleux attrapent la grosse tête (si c'était pas déjà fait) et trollent sur des newsgroups dont tout le monde se fout à propos de leurs choix de design sans forcément savoir de quoi ils parlent (comme le choix de C parce que C++ "c'est de la merde pour mauvais programmeur").

S'en suit une guerre contre les modèles propriétaires qui pompent tout ce travail de chinois pour des clopinettes (c'est à dire rien, puisque c'est open-source, et que de toute façon, les licences GPL on s'en fout ).

[/humour] :p

[trenton]

C'est les joies de l'open-source :

Des gens peu scrupuleux débutent un projet open-source, font un gros buzz dessus, d'autres personnes naïves viennent leur prêter main forte et font tout le boulot.

Et c'est ainsi qu'ils deviennent l'homme le plus riche du monde.

Pour de vrai c'est pas complètement faux, mais ça concerne plutôt les projets sous licences de type BSD plutôt que GPL.

[chemanel]

- Un programmeur passe entre 10 et 20% de son temps à coder, et écrit en moyenne 10 à 12 lignes de code par jour qui seront incluses dans le produit final (peut importe leur niveau). Les bons programmeurs utilisent le temps qu'il leur reste à penser, rechercher et faire des tests pour parvenir au meilleur design possible. Les mauvais quant à eux passent ces 80 à 90% de temps à debugger leur code en faisant des essais au hasard puis en regardant si cela fonctionne.

Je pense que c'est tout à fait vrai... Au jour le jour, je passe plus de temps à concevoir/analyser qu'à proprement coder ...

Avec des outils comme LinQ ou (n)Hibernate il ne faut plus coder la couche de donnée... (Ni la db d'ailleurs) Elle est générée automatiquement sur base des objets qu'on a créés dans le business... Objets qu'on ne code plus a la main car il y a de très bon outils qui permettent de "dessiner" tout nos diagrammes de classes nécessaire... De même les IHM peuvent être générées automatiquement (que ça soit des formulaires, listing etc...) grâce au DataBinding... Du coup, 80% de nos applications d'aujourd'hui sont "codées" grâce à des outils graphiques... Sans presque toucher au code, ça se limite plus à de la configuration... Après il nous reste plus qu'a coder les "cas spéciaux" (algorithmes propre à l'application). Pour l'architecture générale de l'application, il y a de nombreux pattern disponible un peu partout qui permette d'avoir une architecture éprouvée par la communauté...

C'est vrai qu'au final... il ne reste plus grand chose à coder !

[Auteur]

- Programmer, c'est du boulot. C'est une activité mentale intense. Les bons programmeurs pensent à leur travail tous les jours, 24 heures sur 24. Ils écrivent leurs codes les plus importants sous la douche ou dans leurs rêves.

je suis rassuré, je suis donc pas le seul dans ce cas

[el_slapper]

12 lignes/jour ??? J'avoue que c'est la phrase qui m'a le plus surpris. Peut être ne travaillait-il que sur des réécritures ou il disposait d'une énorme bibliothèque. Mais il a bien fallu l'écrire ce code de base : c'est le boulot des mauvais programmeurs ?
(.../...)

Le standard IBM, dans les années 80, c'était 7. Mais sur des ensembles déjà matures. Il m'est arrivé de cracher 1000 lignes en une journée sur un truc nouveau, mais ensuite, j'ai passé 2 semaines à affiner l'ensemble(avec les concepteurs, qui avaient du cracher une spec en 24 heures pour 18 flux à transférer. bizarrement, leurs specs n'étaient pas impeccables du premier coup...).

Le truc standard, c'est 2 semaines de bagarre pour arracher une spec précise, 15 minutes à écrire 43 lignes de code, et 1 semaines pour intégrer tout ça(et corriger la parenthèse qui manquait, j'ai trouvé le moyen de me planter quand même). Evidemment, je bosse sur de vieilles applis. Si on passe 6 mois à créer le truc, et 9 ans et demi à le maintenir, ça lisse complètement le nombre de lignes réellement écrit. Là, je maintiens du code de 1996. avant, c'était du 1972.

Pour ce qui est de retrouver l'existant, j'ai de moi-même l'image d'un archéologue logiciel.

[cyrianox]

Je me suis reconnu dans cette description comme "mauvais" et "bon" programmeur.... hé ouais, on évolue avec le temps. (~2/3 ans de pratique pour gagner un level)

[Hinault Romaric]

Ah oui programmer maintenant c'est tout un art il ne suffit plus d'écrire des tas de lignes de code. Mais être capable en quelque lignes de code de tirer le meilleur de plusieurs outils déjà mis à notre disposition pour atteindre les objectifs attendus. Et cela est une grosse activité mentale.

Je me vois bien dans cette description j'irais même jusqu'à dire qu'une bonne partie des problèmes de programmation qui me tracassent je les résous dans le taxi, dans mes songes ...

[free07]

Je suis entièrement d'accord sur le fait qu'un bon programmeur passe + de temps à la réflexion, à la recherche, aux essais qu'à l'écriture du code proprement dites mais pour moi, il a oublié une chose capitale :

Le bon programmeur recherche toujours la solution la + simple, contrairement au mauvais programmeur.

Passer du temps à simplifier est très important pour la réussite d'un projet, c'est du moins l'expérience que j'en ai.

[martopioche]

Ce qui est amusant à la lecture de cet article (qui n'est pas une étude !!! ), c'est que j'ai l'impression de revoir mes cours de Génie Logiciel...

Ce qu'il faut par contre, c'est suivre le lien vers le post original pour aller voir les liens car ses références complètent bien ce post finalement assez caricatural.

J'aurai tout de même une nuance à faire : l'excellence ne fait pas parti des projets industriels. Le bon développeur trouvera le compromis entre l'excellence du design, les délais, les besoins réels...

Après pour le coté bon/mauvais programmeur, il faut être conscient que beaucoup de programmeurs le sont par besoin alimentaire (cas des "Drone programmers" dans le lien) mais l'industrie est tel faite que pas mal de personnes sans expérience réelle sont parachutés architectes ou experts et on se retrouve alors avec des conceptions bancales ou sur-architecturées.

Quant au choix des technos, je me suis vu répondre un jour sur un projet au forfait que j'ai rejoin en cours de route que "on a vendu ces technos donc on utilise ces technos"... Sic...

[martopioche]

12 lignes/jour ??? J'avoue que c'est la phrase qui m'a le plus surpris. Peut être ne travaillait-il que sur des réécritures ou il disposait d'une énorme bibliothèque. Mais il a bien fallu l'écrire ce code de base : c'est le boulot des mauvais programmeurs ?

En fait tu as raté une partie de la phrase : il te manque "lignes de code par jour qui seront incluses dans le produit final". Si tu écris un test de 50 lignes pour tester 2 lignes, tu as écrit 52 lignes, mais tu n'as que 2 lignes dans le produit final. On ajoute des choses comme le refactoring, et tu vas voir que tu as effectivement peu de lignes dans le produit final.

[grunk]

Franchement c'est bien joli de passer 88 à 90 % de son temps au design mais parfois c'est pas vraiment ce qui va faire avancer le schmilblick.

C'est de toute manière pas possible à part dans le monde magique des développeurs sans boss , sans deadline et sans contrainte.

Quand un client te commande un soft , si à la première réunion tu viens avec des diagrammes UML, des diagrammes de class à la place d'une jolie interface pour qu'il puisse faire clic clic tu te fais déchirer (enfin c'est comme ça que ça marche chez moi) alors que pourtant tu auras fait nettement plus de taf en faisant de la conception que de l'IHM.

Chez nous c'est en partie pour ça que la conception , la documentation et tout ses truc invisibles mais pourtant indispensable sont trop souvent remis à plus tard voire à jamais

[chemanel]

Quand un client te commande un soft , si à la première réunion tu viens avec des diagrammes UML, des diagrammes de class à la place d'une jolie interface pour qu'il puisse faire clic clic tu te fais déchirer (enfin c'est comme ca que ca marche chez moi) alors que pourtant tu auras fait nettement plus de taf en faisant de la conception que de l'IHM.

Normal, le client, lui, il s'en bat les steak avec une pelle à tarte de savoir qu'un objet dérive d'un autre basé celui ci sur une interface dérivée d'une factory... (Quoi que j'ai pu remarqué que la mentalité a changée, et que les "chef de projet client" essaye de s'investir de plus en plus dans le développement)

En .NET (Silverlight / WPF) tu as un outil terrible qui s'appelle SketchFlow qui te permet de construire des IHM interactive très très vite. Tout en étant non jetable car ça travaille sur des projets C# ou VB que tu peux switcher sous visual studio a tout moment en ayant ton code XAML et tes fichiers déjà créés.

[maske]

C'est un petit peu n'importe quoi ce post - selon moi déconnecté de la réalité et très caricatural.

C'est qui ce type qui sort la vérité moulée dans un blog avec autant de confiance en soi ?

Il ne me paraît pas important d'argumenter, tant chaque élément, caricature et amalgame à la fois des "bons" et "mauvais" programmeurs, parle de lui même.

Sans déconner, c'est ce que vous voyez dans votre vie professionnelle de tous les jours ?

Je répondrais simplement sur une chose : 12 lignes de code effectives incluses dans le projet final par jour ?

Mais euh sur des projets de plusieurs milliers de lignes, qui c'est qui programme alors ? Le mauvais programmeur, parce que le bon est occupé à réfléchir sur ses 12 lignes ?

Si on compte rapidement, 12 000 lignes de code (un petit projet donc), à 12 lignes par jour, ça fait 1000 jours pour avoir le projet complet ?

Est-ce que ça serait pas un peu débile ?

Pour ceux qui diraient qu'on utilise des librairies externes open-source-machin-truc-etc., on ne les comptes pas dans le nombre de lignes produites dans un projet (sinon je vois pas comment on évalue ce qui a été produit en terme de volume de code).

[phryos]

les 12 lignes par jour ne me choque pas du tout. On parle bien de lignes effective donc il faut enlever les commentaires, les tests unitaires. Après il l'aspect documentation à savoir les docs de conceptions, fiche de tests et j'en passe... Tout ceci a un coût rapporté en ligne de codes, ça baisse énormément.

Un responsable informatique m'a raconté que c'était à peu près une constance quelques soient les langages utilisés (nombre de lignes de code/dev). L'idée était donc de développer un langage le plus efficace possible requérant le moins de ligne de code. Ainsi on gagne en rapidité de développement de produit. A priori c'était un des buts du développement du java par rapport à du C++ (à prendre au conditionnel ce dernier point, je ne fais que rapporter)

[davcha]

Si on compte rapidement, 12 000 lignes de code (un petit projet donc), à 12 lignes par jour, ça fait 1000 jours pour avoir le projet complet ?

Est-ce que ça serait pas un peu débile ?

Non, parce quand t'es un excellent programmeur, tu te débrouilles pour refiler le boulot à quelqu'un d'autre. Que ça soit un générateur de code auquel tu comprends rien, ou un mec lambda qui veut absolument participer à ce mouvement humanitaire qu'est l'open-source

[atb]

Pour moi, toute la subtilité de la chose, la difficulté d’être un bon développeur est de trouver
un équilibre entre la conception et le codage.

Perso, un mauvais codeur est celui qui :
Avant même d’avoir fini de lire et COMPRENDRE les spécs et le besoin fonctionnel, saute sur clavier et commence à coder ….
Celui qui code comme un porc, code illisible, sans commentaire, librairies externes pas bien testées…Et trouve toujours un moyen de se justifier.
Celui qui ne teste pas (entièrement son code/programme). Au lieu de le faire de long en large, peaufine son interface chouchou, ou ces messages,…

Et OUI passer une demi-journée avec une feuille et crayon à réfléchir, c’est toujours mieux que de coder 12000 lignes sans atteindre tous les objectifs.

Un exemple : On donne le même besoin, un programme à réaliser, avec plein de tests if else + des règles de gestion.

Le mauvais développeur va le faire en une journée, oubliant de nombreux cas, indéchiffrable pour le reste de l’équipe et donc impossible de débuguer ou maintenir.

Un bon développeur, va consommer une journée à dessiner des tableaux logiques, pour lister tous les cas possibles, éliminer ceux qui ne servent à rien. Et ensuite le faire en une heure.

Pour finir je dirais que la différence réside dans la méthodologie du travail, qui sera acquis avec l’expérience (pour certain seulement).