Fier d’être développeur

Un article pas technique pour deux sous, ce soir, à propos du site http://fierdetredeveloppeur.org/. Il s’agit d’un mouvement lancé par Daniel Cohen-Zardi, Eric Mittelette et Eric Vernié, et qui a connu une présentation remarquée aux Tech Days cette année, lors de la plénière du premier jour.

Les principes sont les suivants (copie du blog) :

1. Promouvoir le métier de développeur de logiciels,
2. Expliquer la valeur de ce métier alliant rigueur scientifique et force de créativité,
3. Communiquer la noblesse du choix de faire carrière en tant que développeur,
4. Valoriser l’impact de l’expérience sur l’équation économique des développements logiciels,
5. Encourager le respect mutuel entre les développeurs indépendamment des plates-formes et technologies utilisées.

“Fier”, vraiment ?

Bon, j’avoue avoir une réaction initiale un peu méfiante de tout ce qui commence par “fier de …”. De la même manière que je ne suis pas “fier d’être Picard d’origine”, je ne suis pas non plus “fier d’être Breton d’adoption”. Tiens, d’ailleurs, c’est la première proposition de Google quand on tape “fier de” :

Maintenant, quand j’y réfléchis, ce qui me gêne surtout dans cette expression est lorsqu’elle est utilisée dans un cas sur lequel un individu n’a pas prise. On n’a pas à être “fiers” d’être Breton / Picard / Corse / Français, pour la bonne et simple raison qu’on ne l’a pas choisi… C’est Brassens qui disait “Il n’y a que les cons qui sont fiers de venir de quelque part”. On peut bien sûr aimer sa région (bon, pour la Picardie, c’est un peu plus dur que pour la Bretagne ), être contents d’y vivre, mais fiers… je ne pense pas.

Du coup, fier d’être développeur, pourquoi pas ? Là, au moins, on a prise dessus : je connais peu de gens qui se trouvent être devenus développeurs par hasard. Des étudiants arrivés sans grande conviction en IUT Informatique, oui… Mais en général, ils se rendent vite compte si ce n’est pas pour eux.

Donc, va pour la fierté, mais il faut encore savoir de quoi on peut être fier. Il est vrai que le métier n’est pas très reconnu. En même temps, je pense n’avoir jamais assisté à une réelle stigmatisation du métier, mais c’est peut-être juste parce que les gens à qui je parlais de mon job avaient un ordinateur à dépanner et ne voulaient pas me fâcher .

Valeur de l’expérience

Comment peut-on penser une minute qu’un développeur de plus de 35 ans est grillé ou nul ? A l’inverse, c’est à peine à cet âge qu’on commence à devenir un vrai développeur, à savoir quelqu’un capable de penser à tous les aspects d’un code. Coder un algorithme dans tel ou tel langage, c’est bien, mais il faut une expérience énorme pour le faire de manière professionnelle. Pour vous donner une idée de la chose, voici ce que veut dire “coder” pour un non-développeur :

• Comprendre le problème
• Taper du code
• Compiler, tester
• Envoyer chez le client

Mais pour un “vrai” développeur, en plus de ces activités de base, chaque ligne de code embarque une série de réflexions sur :

• La robustesse du code : quels sont les cas dans lesquels il peut émettre une exception et comment ?
• La performance : le code nécessite-t-il aussi peu de ressources pour s’exécuter qu’il est raisonnable ?
• La sécurité : le code présente-t-il des failles connues (injections, attaques par canonicalisation, validation des entrants, etc.) ?
• Le code est-il suffisamment couvert par des tests unitaires ?
• Le code suit-il les bonnes pratiques SOLID ?

Nous pourrions en ajouter encore sans forcer. Or, tout ceci nécessite énormément de temps pour être acquis. Personnellement, j’ai commencé la programmation à l’âge de 12 ans, en créant un driver d’imprimante Citizen 120-D pour mon Amstrad CPC 6128. C’était une époque où utiliser un ordinateur signifiait naturellement programmer. Le lancement même d’un programme était un ordre BASIC (par contre, l’ordi bootait en zéro secondes ). Et après… hmmm… 25 ans donc, je considère que je suis seulement en train de devenir un développeur accompli depuis quelques années, encore que j’ai des manques criants dans de nombreux domaines. On va dire en tout cas qu’en C#, ça y est : je vois à peu près les tenants et les aboutissants de tout ce que je peux écrire. Mais ça m’a pris une dizaine d’années, et encore je ne compte pas les années sur les autres langages, qui étaient nécessaires. Au final, il m’a fallu vingt ans pour coder “propre”.

Bon, il me faut bien admettre que je suis plutôt du genre diesel, à la course comme en termes de programmation. A l’inverse, je passe une bonne partie de mes soirées à bloguer sur de la programmation, à tester des beta, écrire des petits bouts de code pour test, ou écrire des livres sur les technologies Microsoft. Au final, je dois donc être dans la moyenne quand je prétends qu’un développeur ne devient vraiment bon qu’au bout d’une dizaine d’années de pratique.

A nos managers

Une dernière chose sur la valorisation de l’expérience, et ce à l’attention des managers de développeurs (et c’est le point le plus important parmi ma logorrhée verbale de ce soir) :

Un bon développeur n’est pas 2 (DEUX) fois, mais 10 (DIX) fois plus productif qu’un codeur lambda.

Je sais, c’est difficile d’être pleinement conscient de ceci, et quand on y pose les conséquences d’un point de vue pratique sur l’organisation d’un service informatique ou d’une SSII, on peut avoir de nombreux questionnements. Dites-vous juste que des managers de très haut niveau sont en train de prendre la mesure de cette réalité, et que plus vite vous le ferez également, plus votre avenir sera brillant. Ce n’est pas pour rien que Michael Bloomberg a déclaré que son but de l’année était de devenir développeur. Des articles comme http://www.forbes.com/sites/venkateshrao/2011/12/05/the-rise-of-developeronomics/ montrent également la valeur considérable d’un développeur.

Rassurez-vous, toutefois, chers managers : nous ne souhaitons ni votre place (nous n’y serions ni à l’aise ni épanouis), et nous sommes relativement peu exigeants en termes de salaire. Tout ce que nous souhaitons est de pouvoir continuer à apprendre tous les jours dans notre travail. Sachez d’ailleurs que si vous cherchez ce genre de développeur, il faudra les nourrir intellectuellement pour les garder…

Architecte logiciel

Dans une première partie de ma carrière, j’ai fait du développement à l’international, et l’évolution naturelle était de devenir responsable d’équipe. C’est ce que j’ai accepté de faire en devenir manager pour l’équipe France de mon employeur anglais. Le peu que je suis resté dans ce poste (j’ai très peu de temps après émigré en Bretagne pour y rejoindre ma femme – vous ai-je dit que je suis maintenant Breton?) m’a convaincu que c’était plutôt une perte de temps : je faisais moins de développement, et la résolution de conflits ou de problèmes de contrats n’avait que peu de saveur par rapport à la stimulation intellectuelle apportée par la résolution de problématiques techniques…

Je suis reparti de zéro chez mon second employeur, en redevenant simple analyste. Etant un passionné de .NET, j’ai naturellement pris progressivement une position de développeur référent, qui s’est officialisée à terme en “architecte logiciel”, et responsable du pôle Architecture / Formation / Innovation. Je lis ici, et j’ai déjà entendu dans d’autres cas, que ce terme peut être associé à de l’architecture lourde, avec une activité uniquement basée sur des diagrammes UML. Personnellement, je n’ai jamais cru à une trop grande symbolisation de l’architecture, l’activité de développement étant déjà à un haut niveau d’abstraction. Ma définition de ce poste et mon travail réel consistent plutôt à créer les conditions (API, docs, bonnes pratiques, formation, etc.) pour que les développeurs des équipes qui m’entourent puissent être le plus productifs possible. En plus de ceci, je me dois de refactoriser le code à un niveau global, en trouvant les veines dans lesquelles je peux enfoncer les coins qui sont pour moi l’inversion de dépendances, la modularité, l’injection ou encore les mocks / stubs. Bref, je reste proche du code, et il est hors de question pour moi de repartir sur un poste de management.

Je serai encore développeur quand je partirai à la retraite. D’ici là, je serai peut-être “architecte en chef”, ou “responsable R&D” . Je travaillerai peut-être encore plus avec l’université dans le cadre de thèses. Mais hors des titres et des coopérations, dans la réalité, je serai toujours un développeur.

Bien sûr, il faut préparer le futur. C’est principalement pour cela que je donne des cours, que j’écris des livres, et que je profite de mon statut de MVP pour rester au cœur du changement : le but est aussi de garder un profil exigeant. Mais honnêtement, tout ça est un tel temps investi que je ne le ferais pas par pur orientation de carrière !

Respect mutuel

Je termine avec le dernier principe énoncé par le mouvement “Fier d’être développeur”, à savoir le respect entre développeurs sur des plateformes différentes.

C’est également un facteur pour devenir un bon développeur : lire beaucoup de code d’autres personnes, et surtout regarder ce qui se fait dans les autres technologies. Pour bien comprendre pourquoi F# est arrivé dans .NET, il faut avoir jeté un œil du côté d’Haskell ou d’OCAML. Pour bien utiliser MEF, discuter avec un expert de Java / Spring fait gagner énormément de temps. Quand on ne comprend pas l’API de MSMQ, le mieux est encore de fureter sur les forums Apache ActiveMQ…

A ce propos, je recommande ce très bon article sur Le Touilleur Express. Je me sens totalement en phase avec ce développeur Java qui est venu aux Tech Days, ayant moi-même présenté une comparaison Java / .NET dans un évènement où l’énorme majorité des développeurs étaient des Javamen. Ca a évidemment chambré un peu des deux côtés, Nicolas De Loof pouvant difficilement laisser passer l’aspect propriétaire et les faiblesses d’injection de .NET, et moi-même ne pouvant pas m’empêcher de souligner le manque d’un équivalent à Linq, la surabondance de solutions équivalentes, le retard de Java 7, etc. Mais au final, j’ai beaucoup appris, rien qu’en préparant cette présentation, et encore plus en discutant avec les Javamen en question en fin de conférence et durant le reste de la journée du BreizhCamp (je vous avais dit que je suis désormais Breton ?)

Conclusion

Pas de conclusion. Si vous êtes arrivés au bout de ce post, vous avez déjà trop lu. Retournez coder !