Moi, développeur

Tout d'abord, qui parmi nous ne s'est jamais senti un jour incompris en tant que développeur

• "Mais bon sang, pourquoi ne m'écoute-t-on jamais"
• "Si seulement j'avais le pouvoir de décider, tout serait tellement mieux"

Nous avons une tendance naturelle à considérer notre métier comme avant-gardiste, essentiel à la société. Qu'est-ce qui fait avancer le monde, si ce n'est la technologie, et ceux qui la développent, la font progresser. Nous nous sentons aussi incompris, par nos familles (que celui qui arrive à expliquer à ses grand-parents en quoi consiste son travail de tous les jours fasse un pas en avant), amis d'autres professions, sans oublier les gens du marketing bien évidemment, eux c'est le pire !

Nous nous regroupons donc entre nous, dans des User Group, des conférences... des cercles fermés. Mais là encore le fossé s'élargit, connaissez-vous la "Conférence annuelle des plombiers" ? Nous aimons aussi nous évaluer, nous catégoriser. Pour reprendre une tirade bien connu "Y'a le bon développeur, et y'a le mauvais développeur". Il y aussi les RockStar, les Dieux du Dev, les Ninjas. Vous connaissez le plombier Ninja ? la Rock Star du fer à souder ?

Mais tout ceci est une bonne chose. Cela prouve que nous aimons notre métier, nous sommes des passionnés. Car après tout quelle est la plus simple définition d'une passion ? Un enthousiasme et un intérêt très fort pour une activité. Une activité à laquelle nous nous adonnons sur notre temps libre. Et c'est bien cette notion de temps libre qui est importante. Nous avons la chance d'avoir un métier qui nous passionne, pour lequel nous pouvons facilement sacrifier une soirée si cela nous permet de tester une nouvelle technologie, un nouvel outil, ou de développer un morceau de code qui nous a trotté dans la tête pendant des heures.

Nous sommes passionnés.

Individual and Interaction over Process and Tools

En tant que développeurs passionnés, nous voulons améliorer les choses, c'est pourquoi comme certains chez Ford ou Toyota à leur époque, nous avons trouvé des moyens pour révolutionner notre industrie. Des gens d'expérience et de grande valeur ont énoncé des principes fondamentaux pour le développement logiciel, qu'ils ont regroupés dans le Manifeste Agile. Intéressons nous juste à l'un des principes.

"Individual and Interaction over Process and Tools"

Ou en bon français "Les individus et intéractions plutôt que les processus et les outils". Nous sommes tous d'accord sur ce principe. Les processus infinissables, les outils pour gérer nos moindres faits et gestes, savoir à quel heure Roger va faire pipi, combien de secondes il a passé sur telle ou telle tâche. Les processus et les outils tuent notre industrie à petit feu, nous en sommes conscient. L'essentiel est ailleurs, nous développons un produit, pour répondre à un besoin ou solutionner un problème. L'agilité est là pour nous aider à trouver comment passer le plus possible de notre temps à faire cela, et rien que cela, développer un produit.

Nous choississons de mettre en place Scrum. Nous fixons une limite dans le temps, les sprints. Chaque sprint commence par un planning, nous définissons de manière collégiale l'ensemble des tâches qui devront être intégrées dans ce sprint et nous leur affectons une complexité. Nous répartissons les rôles, "Tu seras ScrumMaster mon fils". Ensuite on se lance dans le développement. Enfin si je puis dire, on va le faire ce pu***n de produit. S'en suit chaque matin une réunion (Que ceux qui ne sont pas d'accord sur le terme me jettent la pierre en premier, mais regrouper 10 personnes ensemble à une heure déterminé à l'avance pour discuter de leur travail pendant un temps plus ou moins long, que ce soit assis autour d'une table, debout ou allongé par terre, j'appelle ça une réunion). Ce "Scrum daily Meeting" a donc pour vocation d'être court, pour ne pas déconcentrer les développeurs de leur tâche principale, développer. Malgré tout, on sait que la dérive est facile et relativement fréquente. S'en suivent les 2/3/4 semaines de sprint, pour conclure par une rétrospective. Qu'ai-je bien fait, qu'est-ce qui n'a pas marché, qu'est-ce que je peux améliorer ? Et on repart sur une nouvelle itération.

Pour faciliter tout ça, nous avons mis en place certaines choses, un tableau blanc séparé en plusieurs colonnes, des post-it que l'on déplace quand on a avancé sur une tâche (certains logiciels ont été développés pour répondre plus facilement à ces besoins). Des jeux de cartes permettent de mieux définir la complexité des tâches. Certaines équipes utilisent la technique pomodoro : La journée de développement est découpée en sections de 30 minutes. Au début de chaque session, j'enclenche un timer pour 25 minutes, durée durant laquelle je m'interdis toute interaction avec le monde extérieur. S'en suivent 5 minutes de pause.

Voilà en quelques mots (plus ou moins bien formulés) ce qu'est Scrum.

Nous avons donc remplacé des processus et des outils par.....
... (temps de réflexion) ...
...

Vous voyez où je veux en venir ?

Nous perdons de vue l'essentiel.

La communication et les clients

Notre métier nous amène à nous regrouper, à échanger avec d'autres personnes qui font le même métier que nous, avec qui nous arrivons à nous faire comprendre. Nous nous comprenons tellement bien que nous rentrons de plus en plus dans les détails, nous parlons d'implémentations de frameworks, d'optimisations de langages, des meilleurs façon de développer tel ou tel solution. Nous aimons parler, nous aimons communiquer, nous le faisons tous les jours, on blogue, on twitte, on commente... HackerNews, Reddit... Nous sommes certainement la profession qui communique le plus.

Mais nous ne communiquons qu'avec d'autres développeurs. Nos collègues sont des développeurs, nos amis (pas tous heureusement) sont des développeurs, alors pourquoi devrions nous nous forcer à communiquer différement ?

Parce que nous sommes mauvais en communication.

Qui n'a jamais entendu ou dit lui-même "Le client est nul, il ne comprend rien à rien", "Les gars du marketing sont nuls, il faut leur expliquer 20 fois la même chose", "Les utilisateurs sont des abrutis, ils ne comprennent pas cette nouvelle feature" Si cela se reproduit fréquemment, quelle est la probabilité que le problème ne vienne pas du client, du marketing ou des utilisateurs mais plutôt de nous.

Dans Rework, Jason Fried et David Heinemeier Hansson donne le conseil suivant "If you are trying to decide among a few people to fill a position, hire the best writer. It doesn’t matter if that person is a marketer, salesperson, designer, programmer, or whatever; their writing skills will pay off." (Si vous hésitez entre plusieurs candidats pour un poste, embauchez celui qui écrit le mieux. Peu importe que celui-ci soit du marketing, des achats, un développeur ou autre; leurs compétences en rédaction seront payants)

Cette phrase m'a fait réfléchir quand je l'ai lue. Il faut bien un critère pour différencier deux profils similaires, mais pourquoi celui-là ? Un bon rédacteur a par définition une bonne capacité pour synthétiser ses idées, les exprimer de manière simple et compréhensible par tous. En résumé, il sait communiquer.

Embaucher un bon communicant n'a pas pour but de faire de lui le prochain porte-parole de votre société, les gens du marketing en sont tout aussi bien capables. La communication est toujours dans les deux sens, je parle et j'écoute. Si je sais bien m'exprimer, avec tout type de personnes, développeurs, utilisateurs... alors je saurais également bien écouter, mieux comprendre ce qu'ils veulent me dire, mieux évaluer leur besoin et ainsi développer un meilleur produit.

Alors si vous voulez embaucher quelqu'un, embauchez le meilleur communicant... mais pas pour s'exprimer, pour écouter.

KDD ou l'art du Knowledge Driven Design

Nous lisons presque tous les jours des articles comparant les performances des différents frameworks web, serveurs d'applications, langages de programmations ou diverses librairies. Nous passons parfois un temps infini à réaliser des POCs avec différentes technologies pour savoir laquelle s'adapterait mieux dans notre cas d'utilisation. Nous décidons (quand nous ne sommes pas forcés) de refaire toute une application car le précédent framework n'est plus assez à la mode/performant/cool. Nous souhaitons utiliser ce nouvel outil car c'est hype et que ça serait bien sur mon CV. Nous sommes des développeurs, nous voulons expérimenter, toucher à tout, tout connaître.

Mais nous perdons de vue l'essentiel.

Pourquoi, à la base, sommes-nous développeurs ?

• Pour tester de nouveaux frameworks ?
• Pour développer des applications répondant aux specs ?
• Pour le bien-être de nos utilisateurs ?
• Pour changer le monde ?

Pas vraiment.

Nous développons des produits pour générer des revenus.

La notion de revenue passe souvent inaperçue aux yeux du développeur.

Dans une SSII (oops, appelez moi ESN désormais), si l'utilisateur final n'est pas content, est-ce que mon salaire va être réduit de moitié le mois suivant ? Chez un gros éditeur logiciel, est-ce que si le produit ne se vend pas, je vais devoir partager mon salaire entre mes collègues de bureau ?

Les seuls, selon moi, à posséder cette notion, sont les petits éditeurs de logiciels, les startups, ceux pour qui les revenus dépendent du produit et vice-versa. Prendre conscience qu'un mauvais produit impactera nos revenus force à s'améliorer (avec plus ou moins de succès), mais quand on est en là, plus question de décider de changer de technologie car celle qu'on utilise n'est "plus à la mode". Quand bien même, quel utilisateur va s'en rendre compte ? Aucun. En revanche, un utilisateur qui n'est pas satisfait du produit, même si celui-ci est rapide/beau/sexy/cool, va cesser de l'utiliser, ce qui va impliquer... une baisse de revenu. Pour l'exemple, on entend souvent dire que Ruby est lent, mais malgré ça, combien de sites sur le web tournent avec Ruby actuellement, un sacré paquet, et des sites dont les utilisateurs en sont contents. La technologie et le produit sont deux choses très différentes.

Conclusion

Ne perdons pas de vue l'essentiel.