Un blogueur classe les développeurs en cinq catégories
êtes-vous d'accord avec son classement ? Et laquelle vous correspond le plus ?
Le 2010-11-22 12:11:06, par Idelways, Expert éminent sénior
Mise à jour du 23/11/2010
Nous avons passé en revue hier (lire ci-avant) un billet du blogueur Steven Benner. Son article a suscité sur Développez.com de nombreuses réactions et un débat intéressant.
Mais il a une suite.
Après s'être attaqué (d'une manière assez caricaturale) aux catégories des développeurs, l'auteur expose, dans un billet plus recherché, sa propre définition du « vrai développeur », comprendre les qualités qui doit réunir un bon développeur.
Selon lui, les vrais développeurs sont ceux qui peuvent apprendre vite, apprendre par la pratique, et ne jamais arrêter d'apprendre.
La définition de Benner ne serait donc pas incompatible avec les développeurs qui utilisent du code trouvé sur Google (ou Bing). Bien au contraire.
Ces développeurs, en arrivant à trouver et à adapter rapidement des solutions à leur travail font justement preuve de capacités d'apprentissage et d'adaptation.
Pour trouver les vrais développeurs, Benner donne quelques pistes. Parmi lesquelles, il recommande de mettre les candidats à l'épreuve mais sur des compétences de haut-niveau, non pas sur des patrons de conceptions ou d'obscures problèmes algorithmiques.
Des problèmes théoriques, utilisés par certains recruteurs pour départager les candidats, feraient passer à côté de certains "vrai développeurs". Car ces derniers peuvent de ne pas arriver à se rappeler de solutions à des problèmes qu'ils ne rencontrent que rarement, voire jamais.
En revanche, il déconseille de recruter les développeurs qui s'intéressent plus à l'informatique théorique qu'à l'expérience effective. Benner les considère même comme "une épine perpétuelle dans le pied de l'industrie du développement".
Source : le blog de Steven Benner
Et vous ?
Un blogueur classe les développeurs en cinq catégories
Êtes-vous d'accord avec son classement ? Et quelle catégorie vous correspond le plus ?
Steven Benner est un développeur Web californien qui blogue avec assiduité.
Parmi ses nombreux articles de fonds (et de qualité), il a récemment publié un article dans lequel il classe les développeurs (selon son expérience) en 5 catégories. Une classification forcément caricaturale mais néanmoins très intéressante.
La voici en réusmé.
En un : ceux qui sont efficaces, produisent des solutions rapides et robustes, mais pas vraiment élégantes.
En deux, les perfectionniste, qui ne se soucient aucunement des délais ni des budgets, seul le code parfait les intéresse et ils arrivent effectivement à faire des chef d'œuvres... mais souvent trop tard.
La troisième catégorie, selon Benner, est celle des anti-développeurs. Ceux qui refusent de coder sous prétexte que quelqu'un a forcément déjà fait le code voulu, qu'il suffit tout simplement reprendre.
La 4ème catégorie, opposée à la 2ème, est celle des développeurs qui respectent toujours les délais mais produisent du code "pourri". Les clients et les ressources humaines les adorent, les autres développeurs les haïssent.
Benner classe enfin en cinquième catégorie, les développeurs théoriciens qui passent le plus clair de leur temps (80% selon Benner) à étudier les options possibles, 15% du temps à pester contre les délais non raisonnable, 4% à raffiner les options et 1% du temps à coder réellement.
Et vous ?
Source : blog de Steven Benner
En collaboration avec Gordon Fowler
Nous avons passé en revue hier (lire ci-avant) un billet du blogueur Steven Benner. Son article a suscité sur Développez.com de nombreuses réactions et un débat intéressant.
Mais il a une suite.
Après s'être attaqué (d'une manière assez caricaturale) aux catégories des développeurs, l'auteur expose, dans un billet plus recherché, sa propre définition du « vrai développeur », comprendre les qualités qui doit réunir un bon développeur.
Selon lui, les vrais développeurs sont ceux qui peuvent apprendre vite, apprendre par la pratique, et ne jamais arrêter d'apprendre.
La définition de Benner ne serait donc pas incompatible avec les développeurs qui utilisent du code trouvé sur Google (ou Bing). Bien au contraire.
Ces développeurs, en arrivant à trouver et à adapter rapidement des solutions à leur travail font justement preuve de capacités d'apprentissage et d'adaptation.
Pour trouver les vrais développeurs, Benner donne quelques pistes. Parmi lesquelles, il recommande de mettre les candidats à l'épreuve mais sur des compétences de haut-niveau, non pas sur des patrons de conceptions ou d'obscures problèmes algorithmiques.
Des problèmes théoriques, utilisés par certains recruteurs pour départager les candidats, feraient passer à côté de certains "vrai développeurs". Car ces derniers peuvent de ne pas arriver à se rappeler de solutions à des problèmes qu'ils ne rencontrent que rarement, voire jamais.
En revanche, il déconseille de recruter les développeurs qui s'intéressent plus à l'informatique théorique qu'à l'expérience effective. Benner les considère même comme "une épine perpétuelle dans le pied de l'industrie du développement".
Source : le blog de Steven Benner
Et vous ?
Un blogueur classe les développeurs en cinq catégories
Êtes-vous d'accord avec son classement ? Et quelle catégorie vous correspond le plus ?
Steven Benner est un développeur Web californien qui blogue avec assiduité.
Parmi ses nombreux articles de fonds (et de qualité), il a récemment publié un article dans lequel il classe les développeurs (selon son expérience) en 5 catégories. Une classification forcément caricaturale mais néanmoins très intéressante.
La voici en réusmé.
En un : ceux qui sont efficaces, produisent des solutions rapides et robustes, mais pas vraiment élégantes.
En deux, les perfectionniste, qui ne se soucient aucunement des délais ni des budgets, seul le code parfait les intéresse et ils arrivent effectivement à faire des chef d'œuvres... mais souvent trop tard.
La troisième catégorie, selon Benner, est celle des anti-développeurs. Ceux qui refusent de coder sous prétexte que quelqu'un a forcément déjà fait le code voulu, qu'il suffit tout simplement reprendre.
La 4ème catégorie, opposée à la 2ème, est celle des développeurs qui respectent toujours les délais mais produisent du code "pourri". Les clients et les ressources humaines les adorent, les autres développeurs les haïssent.
Benner classe enfin en cinquième catégorie, les développeurs théoriciens qui passent le plus clair de leur temps (80% selon Benner) à étudier les options possibles, 15% du temps à pester contre les délais non raisonnable, 4% à raffiner les options et 1% du temps à coder réellement.
Et vous ?
Source : blog de Steven Benner
En collaboration avec Gordon Fowler
-
_skipExpert éminentNous aurions donc :
1) le fonceur précipité
2) l'artiste incompris
3) l'adepte de réutilisation massive
4) L'adepte du quick'n dirty
5) L'ingénieur râleur
Un peu caricatural tout ça, pour moi c'est un peu comme de dire qu'un théoricien est nul en pratique et vice versa, en à peine plus élaboré.
A mon avis, un développeur est un peu tous ces portraits à la fois mais dans des mesures qui peuvent varier suivant les individus et les projets, c'est juste l'excès dans une de ces catégories qui rend le bonhomme inefficace ou difficile à vivre.le 22/11/2010 à 12:56 -
pcabocheRédacteurJe suis d'accord... tant que tu travailles tout seul.
Le problème, c'est que ce cas est rare. Le plus souvent, tu travailles au sein d'une équipe et là, les choses se gâtent.
Tout d'abord, il y a la hiérarchie. Tu as un chef qui veut que les choses soient implémentées d'une certaine façon et si tu entrevois que ça va poser des problèmes à l'avenir (ex: problèmes de performance), il va falloir parlementer pendant des heures avec ledit chef. S'ensuivent des discussions souvent houleuses qui finissent presque invariablement par "c'est moi le chef, tu fais ce que je dis et tu discutes pas".
Variante: l'entreprise est organisée de telle façon que tu as les concepteurs d'un côté (qui sortent de beaux diagrammes UML, toussa) et les développeurs de l'autre (qui sont confrontés aux problèmes d'implémentation que les beaux diagrammes UML ne pouvaient prévoir).
Ensuite, tu as les autres collègues. La directive, c'est : "il faut écrire du code qui soit facilement compréhensible par tous, au cas où quelqu'un devrait reprendre ton code" (ce que j'appelle vulgairement : "apprendre à programmer pour les nuls".
Traduction d'un point de vue IT : "Fais une implémentation naïve, même si c'est pas performant, de manière que même un stagiaire pourrait comprendre"
Traduction d'un point de vue RH : "Si tu continues à remettre en question les choix de ton chef (alors que tes arguments sont parfaitement fondés), tu risques de prendre la porte, même si tu es considéré par tous comme le meilleur développeur de la boite... Donc ça serait sympa si quelqu'un pouvait maintenir ton appli après ton départ"
Du coup, sur ordre du patron, on part pour l'implémentation naïve, ultra compréhensible, mais qui est tellement peu performante qu'elle en est complètement inutilisable ("pourtant j'vous avais prévenus"). De là tu dois subir les foudres des utilisateurs mécontents et ton patron viens te demander "t'aurais une solution pour résoudre ce problème ?" (par "solution simple" il pense bien évidement : "un petit hack qui me permettrait de ne pas perdre complètement la face" et toi de lui répondre: "oui, j'ai une solution : TOUT CASSEEEEEEEER !"
Par chance, ce n'est pas une grosse appli (d'un point de vue taille du code. Par contre pour la boite, c'est crucial pour le business) et certaines parties de code peuvent être récupérés (les bouts de code adaptés des exemples fournis dans la doc officielle de la bibliothèque qu'on est en train d'utiliser). Tu refais l'appli et ô miracle, ça marche nickel ! (et ça prend vraiment peu de ressources)
En plus le code est beau et élégant... pour ensuite te rendre compte que tes charmants collègues pourtant "expérimentés" ne savent pas ce qu'est un Generic et n'ont jamais écrit d'application qui s'exécutait sur plus d'un thread à la fois.
Avis du patron: "de belles réalisations, mais souvent un peu complexes et une tendance à tout réécrire". Boulet, va !
Si, à la lecture de ce pamphlet, vous avez l'impression que ça sent le vécu, c'est parfaitement normal...le 23/11/2010 à 13:49 -
pcabocheRédacteurWow... non seulement le Père Noël existe, mais en plus il travaille dans une SSII.le 23/11/2010 à 12:00
-
el_slapperExpert éminent séniorautant son premimer post me parait caricatural au possible, autant j'apprécie le fond du deuxième : l'important, c'est de savoir s'adapter. Se couler dans les pratiques locales, ou du moment.
Pour les tests : j'ai été amené à en faire, et à réfléchir au sujet, face à une hiérarchie traumatisée(à juste titre) par quelques recrutements hautement malheureux. J'aurais aimé pouvoir testé l'adaptabilité des gens, mais j'avais pour contrainte "un QCM, pas plus de 15 minutes, on est pas là pour faire chier les gens pendant 2 heures". Je me suis donc limité à un petit test sur les bases techniques utilisées en local, juste pour vérifier que les gens qui annoncent "15 ans d'expertise dont 12 en COBOL" sont capables de comprendre un code basique dans ledit langage.
Eh bien ça a suffit à éliminer la moitié des candidats..... Pour l'autre moitié, ceux qui n'avaient pas bidonné leur CV(parceque mon test, il ne vole vraiment pas haut), ils ont gardé la méthode "standard" : le courant doit passer(en bref, à la tête du client). C'est évidemment suboptimal, mais il est difficille d'évaluer réellement quelqu'un en quelques minutes.
D'ou ma conclusion : un test pour éliminer les boulets, c'est pertinent. Un test pour trouver la perle rare, c'est de la clownerie.le 24/11/2010 à 10:47 -
pseudocodeRédacteurIl revient à ma mémoire une définition d'un de mes professeurs. C'était dans un autre contexte, mais c'est applicable à l'opinion de Steven Benner.
Face à un problème :
- Les mauvais développeurs croient connaitre la bonne méthode
- Les bons développeurs connaissent déjà la bonne méthode
- Les grands développeurs ne connaissent pas la bonne méthode, mais savent comment la trouverle 23/11/2010 à 19:46 -
sevyc64ModérateurJe me reconnais très bien dans ce que dit ce Steven Benner autant dans le premier que dans le second post.
Si j'en crois son classement, certes exagéré mais pas si loin de la réalité que ça, je suis à la fois dans la première et dans la cinquième catégorie, suivant les circonstances, avec une préférence pour la cinquième et une haine viscérale de la quatrième catégorie que l'expérience mais surtout l'age n'arrange pas.
Je suis donc un grand développeur, alors
JE hais les tests qu'il faut parfois passer en entretien, pondre un bon de code, comme ça sur le pouce sans pouvoir préparer, ni réfléchir, comme si on avait tout en mémoire, comme si développer c'était comme réciter les tables de multiplications à l'école primaire.
Et généralement j'échoue.le 23/11/2010 à 22:09 -
pcabocheRédacteurDans 8 ans, je pense que j'en aurai eu marre de l'info et que j'aurai ouvert un bar à putes en Thaïlande...
Du coup, quand on me pose la question "où vous voyez-vous dans 10 ans ?", je me sens obligé de mentir, de peur de ne pas être pris au sérieux...le 24/11/2010 à 22:34 -
sevyc64ModérateurEst si c'est un choix de carrière ?
Pourquoi un développeur doit obligatoirement évoluer dans sa carrière vers un poste de chef de projet ou d'architecte ? Qui impose cela ?
Je me demande d'ailleurs si les développeurs sont les plus compétants pour gérer des équipes et des projets ? Pour ceux que j'ai rencontré ce n'était pas le cas.
A chacun son boulot !!! Laissons les développeurs développer et laissons gérer les projets par des personnes capables de gérer des projet.le 02/12/2010 à 9:09 -
dissertMembre avertiJe suis entièrement d'accord avec skip, nous sommes tous un peu tout ça à la fois, selon les circonstances.
Et j'ajouterais que la manière dont nous serions classifiés dépendrait énormément de celui qui juge (moi, celui qui utilise mon API, celui qui la maintient ?)
Et d'ailleurs, il y a un an, cet article avait fait polémique :
http://www.joelonsoftware.com/items/...009/09/23.html
Il expliquait qu'un bon développeur codait correctement la plus part du temps (TDD, Sonar et tout), mais au moment de finaliser, il savait comment faire pour ne plus fignoler et releaser, au prix d'une augmentation de la dette technique.
C'est un peu suite à cet article que la notion de dette technique est apparu dans l'ecosystème Java.le 22/11/2010 à 13:12 -
GuilpMembre éprouvéMoi je suis souvent de ceux qui doivent reprendre le code de quelqu'un d'autre...
Donc forcément, je suis extrêmement anti hacks ou cheats, de code "bordel"!! J'insulte haineusement ces programmeurs environ 20 fois dans la journée pour me faire perdre (à moi, à mes collègues et à tout le monde) des centaines d'heures... Eux qui ont crû économiser quelques petites heures à engendrer un code bordélique et ultra crade plutôt qu'un code un minimum propre...
Je ne suis pas un perfectionniste pour autant, je fais en sorte de rendre mon travail à l'heure, je fais des compromis... Mais avec un code un tant soit peu propre et réutilisable avec si possible aucun hack ! (et si il y en a un, je le documente à mort).
Bref, je ne sais pas ce qu'est un "vrai" développeur, mais selon mon humble avis, un mauvais développeur est un développeur qui code sans réfléchir.
(Et on peut coder "directement" dans un projet sans pour autant que ça soit irréfléchi. Simple exemple : en s'inspirant d'une méthode agile. Mais des classes bordéliques et fourre-tout remplies de hack en tout genre... Le cauchemars!!)
ps: lors d'une mise à jour d'un article (comme c'est le cas ici), y a-t-il moyen de mettre un lien qui va directement au post de mise à jour sur son fil de discussion forum? S'il y en a un, je n'arrive jamais à le trouver (alors qu'avant, il était souvent dans le texte même de la mise à jour de l'article). merci ^^le 23/11/2010 à 20:50