Les 3 forces de motivation du développeur Les développeurs réfléchissent beaucoup sur eux-mêmes. Chaque jour, La programmation compte de nouveaux sujets sur Qu’est ce qui fait un bon développeur ou le profil type d’un développeur. Donc je sais que le sujet a été maintes fois abordé... mais je m’en fiche. Comme un rite de passage virtuel d’un développeur-bloggeur, Je me dois de vous soumettre ma propre classification des développeurs. La voici... Après 15 ans dans le métier, J’en suis devenu à réaliser que la plus fondamentale qualité d’un développeur est sa source de motivation. Elle sous-tend toutes ses décisions et interactions. Elle prédit quel type de code il va écrire, quelle technologie il va préférer, et même comment il va réussir sur une mission donnée. Et c’est souvent assez facile de se faire un avis sur un développeur après juste quelques jours de travail avec lui. Il y a 3 et seulement 3 sources de motivation (Pour moi !), et elles peuvent être schématisées de la manière suivant: Sur chaque sommet se trouve la force de motivation, et au centre se trouve l’absence complète de motivation. (I.e. dont give a crap). Vous savez de quoi je veux parler. Peu importe, chaque développeur à sa propre et unique « forme », où plus grande est l’aire dans ce triangle, plus grande est la motivation. Par exemple, voici comment je me représente, plus ou moins : Bien qu’un développeur puisse comporter plusieurs motivations, Il y a toujours une force qui domine. Je vais expliquer chacune d’entre-elle: Business Motivated(Motivation d’entreprise – « fonceur ») : Conduit par le désir de finir le travail pour le client, ces développeurs sont souvent les « favoris » des décideurs parce qu’il délivre des fonctionnalités rapidement et sans poser beaucoup de questions. Besoin d’une nouvelle fonctionnalité à la dernière minute? Pas de problème. Ces personnes font preuve d’un volontarisme (même si un peu de réflexion pourrait bénéficier à l’intégrité de l’architecture du système). En termes de code, ils pensent plus concrètement, et ne sont souvent pas les meilleurs pour créer des structures abstraites réutilisables où d’autres objectifs non fonctionnels. Ils veulent juste finit le projet. Sur chaque projet, quelques ’un de ces développeurs sont crucial. Ils font avancer les choses et ne font pas de vagues. Technology Motivated(Motivation technologique – « Technologique »): Ces développeurs sont curieux par nature. Ils sont toujours avides d’apprendre à utiliser les nouveaux Framework, langages ou méthodologies et prendront chaque opportunité de l’essayer dans leur projet actuel. La bibliothèque vient juste de sortir ce week-end et a été écrite par un gars durant un week-end? Essayons là! Ces personnes connaissent toutes les technologies à la mode, et les ont probablement testées durant des nuits ou le week-end. Ils aiment essayer des choses nouvelles, et comprendre quels outils fonctionnent le mieux. Sur un projet vierge, ils s’épanouissent, mais quand les nouveautés s’essoufflent et que le code devient commun, ils se tournent vers de plus vert pâturage, ou quelque fois pire, cherche un moyen d’utiliser une technologie même si cela se fait au détriment du système. Problem Motivated(Motivation par un problème – « Solutionneur »): Les projets difficiles excitent ces développeurs, indépendamment de la technologie employée, même si celle-ci ajoute de la valeur au projet. Tout est comme un puzzle. Présenter une solution élégante ou astucieuse est le but final. Si cela aide le projet dans son fonctionnement, très bien (et souvent c’est le cas). Ces développeurs sont intéressés par les nouvelles technologies dans la mesure où elle présente un meilleur moyen de résoudre les problèmes. Mais pas intéressé au point de tester juste pour voir comment cela fonctionne. Quand leurs solutions est solide Quelque fois les détails importent peu. Maintenant effectivement, ceci n’est pas la « vrai » classification du système, mais j’ai trouvé que cela était intéressant de réfléchir sur mes collègues, comment les classés dans une de ces 3 catégories (actuellement 4). – Le fonceur, Le technologique, Le solutionneur, et le « dont-give-a-craps » (littéralement : ne me donner pas de la merde). Une connaissance de chacune de nos différences est utile. Je sais que chacun aura des forces et des faiblesses, et contribuera au projet de manière différente, et dans différentes partie du cycle de vie. Par exemple, au démarrage d’un nouveau projet, nous faisons appelle aux « technologiques » pour nous informer sur quels Framework ou bibliothèques à l’horizon pourrais être les plus utiles. Ou quand l’équipe a terminé la plupart de l’analyse, nous passons le relais au « fonceur» pour commencer à produire du code. Et quand un problème est particulièrement épineux et nécessite d’être réfléchis, nous faisons appelle aux « solutionneurs » pour prendre du recul et trouver un moyen de sortir de l’impasse. En d’autre mot, chacun contribue à sa manière. Comprendre les sources de motivations sous-jacentes des gens peut nous aider à avoir le meilleur d’une équipe. Cela peut aussi vous faire prendre conscience du besoin de garder une équipe équilibrée – Trop de développeurs d’un certain type n’est jamais bon, et dans les fait peut conduire au désastre pour votre projet. Tandis qu’une équipe composé exclusivement de « technologiques » ou de « solutionneur » peut être obséder par l’infrastructure du projet et ne jamais délivrer quoique ce soit au final, Une équipe de fonceur aura tendance à rapidement créer une grosse boule de pue.
Posted on: Fri, 15 Nov 2013 14:19:56 +0000
Trending Topics
Recently Viewed Topics
© 2015