Je suis passé aux Microsoft TechDays. Un très bel événement pour la communauté Microsoft. Ambiance sympa, environ 15 000 personnes, c’est une autre échelle par rapport à Devoxx France. En tant que développeur Java, cela fait du bien de voir d’autres technologies et d’autres passionnés. Forcément ceux qui me connaissent et que j’ai croisé m’ont demandé : mais que fais-tu ici ? Et bien je vais te dire : ça fait du bien. En écoutant une conférence sur l’ergonomie Web ou une présentation sur ASP.NET MVC 3.0 j’ai appris de nouvelles choses. Comprendre et écouter l’approche dans le monde Microsoft permet de mieux se connaître, et de se rendre compte que finalement, nous sommes tous des développeurs.

L’abruti de base qui raille Microsoft, alors qu’il a un iphone (propriétaire) et que son boulot consiste à pisser du Java pour Weblogic (propriétaire) est bien mort. La communauté Java est parfois mal perçue, assez centrée sur son nombril, mais c’est de moins en moins vrai. Nous avons changé en 5 ans. Le rachat de SUN Microsystems par Oracle nous force à regarder vers l’extérieur, et à arrêter de penser que « l’autre, c’est le méchant« .

Le plus important finalement, c’est le métier de développeur. Que tu fasses du C# ou du Java, tu fais ce beau métier de développeur. Et pour cela, je te respecte.

Sur scène, mardi matin j’ai noté que les présentateurs portaient un teeshirt sympa, sur lequel on pouvait voir « Fier d’être développeur ». Intéressé par le sujet, j’ai découvert le site Fier d’être développeur.

Ce mouvement, matérialisé par une association et un site web, avec logo et slogan, aura pour objectif de
– Promouvoir le métier de développeur de logiciels,
– Expliquer la valeur de ce métier alliant rigueur scientifique et force de créativité,
– Communiquer la noblesse du choix de faire carrière en tant que développeur,
– Valoriser l’impact de l’expérience sur l’équation économique des développements logiciels,
– Encourager le respect mutuel entre les développeurs indépendamment des plates-formes et technologies utilisées.

Cette initiative a été lancée par Daniel Cohen-Zardi, PDG de SoftFluent en association avec Eric Vernie et Eric Mittelette de Microsoft France. Je ne connais pas la société ni les auteurs, mais je trouve l’idée sympa.

Je m’engage aussi dans cette volonté de défendre le métier de développeur et la place du développeur en France. C’est un combat que je défends depuis de nombreuses années sur le blog, à travers des articles comme « Développeur après 31 ans ? Ridé et chauve tu seras« .

Aujourd’hui j’ai 36 ans. J’ai été chef de projet, mais j’aime coder. J’aime développer des applications. Je gagne très bien ma vie, car je bosse en permanence pour ma passion. Si je m’étais orienté vers la direction « Chef de Projet », je pense que je me serai rapidement ennuyé.

J’encourage par contre chacun à prendre des responsabilités de manager. Gérer un projet c’est gérer des personnes. Or lorsqu’à 23 ans, en 5ème année d’école d’informatique, on souhaite vous fait croire que vous serez « Chef de projet » en sortant, je crois que l’on vous ment. Cela rassure votre maman et permet de prélever des frais de scolarité plus intéressant.

Si vous devenez chef de projet pour gérer un projet informatique, vous allez vous rendre compte que c’est assez compliqué. L’expérience dit que, pour gérer des informaticiens, il est plus facile d’avoir été développeur, ou d’être encore développeur. Je m’excuse auprès des bons managers qui lisent et qui n’ont jamais tapé une ligne de code. Cela existe. Mais c’est exceptionnel.

Gérer un projet, c’est en fait gérer l’équipe qui réalise ce projet. Cela demande de l’expérience pour comprendre et sentir les forces en présence entre le client et l’équipe. Il faut de l’empathie pour comprendre pourquoi parfois, il est possible de coder en 15 minutes quelque chose d’exceptionnel.

Gérer un projet, c’est gérer un budget et du temps. Or le développeur en informatique n’a rien à voir avec l’ouvrier sur une chaine de montage. A quoi bon lui mettre sous le nez un plan en « jour/homme » calculé au doigt mouillé ? Nous devons donner des estimations de temps pour des choses que nous n’avons jamais fait, alors même que le client n’est pas certain de ce qu’il veut, et qu’en plus il n’arrive pas à se décider… Ajoutez à cela que nous utilisons des technologies jeunes, car ce qui est vieux n’est pas forcément moins cher ou plus utile. Oui, il faut prendre des risques dans ce métier. Il faut surtout apprendre à s’adapter.

Bref vous l’aurez compris, moi j’ai la vision d’un métier où certains développeurs (pas tous) peuvent continuer à coder. Ils seront capable de gérer d’autres développeurs, et seront payés à leur juste valeur. Pourquoi un informaticien compétent ne pourrait-il pas gagner 100 000 EUR par an ? Je rêve du jour où un patron du CAC40 comprendra que 3 développeurs peuvent lui construire un super logiciel, qui lui permettra de garder son poste de PDG, en gagnant des millions d’euros (et donc en créant des emplois).

Les derniers milliardaires aux USA comme le créateur de Facebook sont des informaticiens. Prend ça dans les dents : Steve Jobs était milliardaire avant 30 ans. Bill Gates aussi. Mark Zuckerberg aussi. Les 2 derniers sont des développeurs. Lorsque l’on parle d’eux, on n’ajoute pas « Nicolas, X-Mines » ou « Jacques, HEC-ESCP, Allemand première langue, a fait son CP à l’école des petits Chardons »

En informatique ce n’est pas le diplôme qui compte. C’est ce que tu fais, ce que tu crées. Et si tu n’es pas fier d’être développeur, alors passe la main. Car il y a des gens qui aiment ce métier.

Moi j’en fais partie, et je suis fier d’être développeur.


19 réflexions sur « Fier d’être développeur »

  1. Très bon article de référence sur le sujet.

    « Aujourd’hui j’ai 36 ans. J’ai été chef de projet, mais j’aime coder. »
    => Ayant été des 2 côtés de l’Atlantique (France, USA), cette phrase sonne étrangement. Parlant assez souvent avec des dev américains/canadiens, prendre du plaisir à coder est presque un truc normal.

    On saura que la situation a changé en France quand il n’y aura plus besoin d’écrire cette phrase.

    Tu as tout mon soutien.

  2. Je suis globalement d’accord avec la conclusion, moins avec le raisonnement.

    En fait, ça part bien jusqu’à cette phrase: « J’encourage par contre chacun à prendre des responsabilités de manager. »

    Personnellement, on a bien essayé de me faire croire que je serais chef de projet au bout de 2 ans, mais 1. ce n’est pas le métier que je voulais faire (toujours pas d’ailleurs) et 2. faut pas prendre des ingénieurs pour des abrutis non plus (même si dans le lot y en a pas mal quand même).

    Le management c’est un métier à part, il est peut être possible de l’apprendre dans les écoles de management mais c’est avant tout une question d’affinités et de compétences. Dans les filières techniques comme celle que j’ai suivie, on forme des techniciens – à la rigueur des chercheurs – et pas des managers. S’il y en a qui se découvrent des dons, pourquoi pas et grand bien leur fasse. Mais je ne vois pas grand chose de commun entre un développeur accompli, concepteur de systèmes logiques plus ou moins complexes, et un chef de projet, gestionnaire de personnes entre autres ressources (je force volontairement le trait ici).

    Je suis donc d’accord avec la conclusion de l’article et je suis moi-même fier de mon métier, comme la plupart des collègues de mon équipe actuelle (et pas comme la plupart des gens de ma boite). Mais j’aimerais bien qu’on arrête de restreindre les débouchés à la seule gestion d’équipe et qu’on parle un peu plus des autres profils: consultant, formateur, expert technique, architecte, urbaniste – et développeur senior.

  3. C’est vrai que dans le monde Microsoft ils ont une vision un peu différente et assez intéressante, leur langage évolue d’ailleurs plus vite (pour le pire et le meilleur) !

    Ça serait sympa de faire du buzz la dessus avec une bannière \ »Fier d’être développeur\ » que chacun pourrait afficher sur son blog ou espace perso…

    Car pour casser le mythe du chef de projet tout puissant aboutissement ultime de la carrière, il va falloir en brasser de l’air avant que cela n’arrive aux oreilles de nos décideurs.

    Les Chefs de projet, certes il en faut mais ce n’est pas eux qui font un produit de qualité [j’exclue le côté fonctionnel].
    Il n’y a qu’à comparer le travail réalisé par 2 équipes :
    _ l’une avec un responsable de projet très bon et des développeur inexpérimentés
    _ l’autre avec un chef de projet déconnecté du monde avec de bons développeurs

    Les entreprises qui ont fait fortune dans l’Informatique ont toutes été bâties autour d’un développeur (ou par un)

    Mais c’est plus rassurant d’avoir des petits chefs [tyrannique et incompétents] que pleins de développeurs [doués et aimant leur job]
    On sait jamais les ouvriers (3*) pourraient réclamer quelques choses aux grands chefs.

    Après on risque de tomber dans le défaut inverse où on voit un PDG qui est fier d’avoir recruté un gars qui lit 3 bouquins par semaine et qui apprend 1 langage par an [Vu sur Capital M6], la quantité n’a jamais fait la qualité… chez nous on appelle ça pipoter son boss 😀 [même si la performance reste possible je trouve dommage de la louer de la sorte, en plus trouver 12 livres intéressants et utiles par mois me semble un défi bien difficile ! ]

  4. Entretien d’embauche chez X… avec Guillaume Bodet :
    – Alors présentes toi
    – Je suis développeur…

    Par la suite, X… m’a fait une offre.
    il m’a raconté après qu’avec cette phrase j’avais réussi mon entretien d’embauche 🙂

  5. Chanceux
    Un petit chef (d’agence) un jour m’a dit :
    « Ton CV fait trop développeur ! » (d’ailleurs c’était pas mon CV mais leur dossier technique dans lequel il a fallu que je recopie mon CV [do my job])
    Ben je me suis levé et je suis parti …. [quelques minutes plus tard ;)]

    Développer c’est comme chanter, tout le monde peut le faire mais ça donne pas le même résultat !

  6. Autre société de développeurs non mentionnée ici : Google.

    La valeur technique de ses produits l’emporte sur les plans marketing plutôt réduits de Google.

    Par ailleurs, le soin de leur processus de recrutement (incluant plusieurs entretiens techniques intensifs) montre que, pour Google, les développeurs ne sont pas des ressources interchangeables. Car comme je l’ai écrit pour un autre commentaire http://www.touilleur-express.fr/2011/09/01/quel-type-de-developpeur-etes-vous/ « Mon idée, c’est que Google a compris qu’un très bon développeur coutait 2 à 3 plus cher que le prix de base, mais qu’il était 5 fois plus productif : la différence entre les 2 ratios est tout benef pour Google. En fait, la différence entre ces 2 ratios (et donc, l’avantage pour Google) est encore supérieur : on est ici dans une évaluation linéaire, mais en matière de travail en équipe, le cout des échanges se fait en n^2 et donc, l’avantage compétitif que tire Google de son processus d’embauche est aussi en n^2 ». Et un autre avantage d’avoir des développeurs de bon, voire de haut-niveau, pour Google est d’avoir une hiérarchie sans doute plus faible, car ce type de développeurs sont de ceux qui s’auto-organisent plus facilement.

    Bref, c’est une de ces sociétés qui reconnait la haute importance de la production de ses développeurs, production technique stratégique pour la vie de cette entreprise, et qui, le reconnaissant, chouchoute ses développeurs.

    Je ne crois pas que Google aurait pu arriver au même résultat avec des développeurs moyens, recrutés plus pour leur taux moyen journalier que pour leur compétence technique. A réalisation exceptionnelle, développeurs exceptionnels.

  7. @Dominique De Vito
    Tu as réussi en quelques lignes et raccourcis à illustrer une vérité que je partage mais qui pour autant est bien rare.
    J’ajouterai que cette analyse ne vaut trop souvent, malheureusement, que pour les éditeurs.
    Ayant travaillé pour différentes sociétés de services, ou en interne chez un grand compte et enfin chez un éditeur je résumerai mon expérience à:
    – SSII: mode trop concurrentiel pour éviter les problèmes de coûts et donc de bonne gestion de compétences. Il y a assez de billets ici qui narrent la vie de beaucoup de nos amis prestataires à qui l’on demande de produire sans qualité, à qui on ne propose pas de mise a jour des compétences,…
    – en interne chez un grand compte: on ne vous fait pas confiance, l’informatique n’est pas le métier premier de la boite, on délègue aux SSII
    – chez un éditeur: respect total des compétences techniques. L’engineering est l’entité où tous souhaitent travailler, où tous sont respectés. Pour info, je bosse chez RedHat pour le *domaine* JBoss, et pas en engineering (donc je ne me lance pas de fleurs).

    Ceci n’est que mon expérience personnelle mais pour avoir énormément d’amis dans les 2 autres catégories, les choses se répètent assez souvent.

  8. je tiens aussi à ajouter qu’il y a de tres bonnes SSII, d’excellents indépendants, des collègues qui se démènent techniquement malgré le manque de moyens, de délais, qui se forment seuls…
    je tenais juste a mettre en relief la reconnaissance des compétences techniques dans divers types de sociétés.

  9. bonjour,
    j’adore lire vos posts, je m’inspire, j’essaie de murier en les lisant .
    cependant , « En informatique ce n’est pas le diplôme qui compte. C’est ce que tu fais » n’est ce pas l’ecole qui donnent des connaissances et savoir faire primordiales pour etre bon developpeur,
    je suis bac+3 et je sens que je suis pas bon developpeur (innovateur) parce que j’ai pas la chance de continuer mes etudes et apprendre plus .

  10. Manager des projets, dans le domaine informatique ou pas, c’est gérer de l’ambiguïté, des personnes, des ambitions, des frustrations, des attentes et aussi une partie technique (budget, etc.).

    Cela nécessite de comprendre que la qualité intrinsèque ou l’avancement technique d’un logiciel ne contribuera finalement pas tant que ça à son succès (e.g. BETAMAX vs VHS, Minitel vs Internet?, vous pensez vraiment que Facebook est une grande avancée technologique?).

    De comprendre qu’il vaut parfois savoir jouer entre les notes quitte à reprendre la partition plus tard plutôt que d’arrêter de jouer. Ces notions sont difficiles à accepter pour beaucoup d’informaticiens, moi le premier.

    Tout le monde n’a pas envie de ça. Que chacun soit le meilleur possible dans son domaine devrait être la seule chose qui compte. Cette excellence vient souvent avec l’amour de ce que l’on fait.

  11. Je suis d’accord. Je suis tellement d’accord. D’ailleurs je suis développeur depuis mes débuts à 24 ans. J’aimerai continuer, que la prestation informatique me permette de le faire. Mais force est de constater que l’âge venant on a plus sa place (rapport qualité/prix). Il faut garder cela en tête et provoquer le changement avant qu’il ne s’impose de lui-même.

  12. @islam
    Tu te trompes islam, les longs cursus ne t’apprendront pas autant que le terrain. Certes, ils te permettront probablement un meilleur salaire à la première embauche mais ça s’arrête la.
    Une société qui n’a comme repère que les diplômes obtenus sans relativiser et pondérer l’expérience réelle est une société qui passera à côté d’excellents profils de passionnés et tant pis pour elle. Ma société embauche en majorité les contributeurs sur les projets open source et peu importe s’ils ne sont que BAC+0.

    @Fred
    Expérience redondante: au bout de 2 ou 3 ans à peine, beaucoup de développeurs pensent que la voie royale est de devenir chef de projet. Pourquoi? Parce que les compétences purement techniques ne sont pas reconnues, comme si c’etait *simple* comparé à tenir Gant et assister à des réunions interminables pour se refiler les responsabilités.

    Certes un bon chef de projet est un bon communiquant (parce que les techniciens ne savent pas aligner 3 mots c’est bien connu, après tout il faut bien mettre les gens dans des cases), ne doit pas être totalement nul en technique mais en quoi serait-ce plus important/difficile que d’acquérir et mettre en pratique une bonne assise technique?
    Je vais être très provocateur, mon but n’est pas de sous estimer l’importance d’un chef de projet.
    Disons sur un projet de 300 jours hommes, installe une équipe de 4 développeurs confirmés. Je suis persuadé qu’ils te feront un meilleur boulot, en temps et en qualité qu’une équipe de 8 constituée de 4 débutants, 2 confirmés, 2 stagiaires, 1 chef de projet, le tout sous stress car le directeur commercial aura accepté de baisser de 300 a 250 jours pour parer la concurrence (au final le projet prendra quand même 400 jours).

    Ca m’agace que de bons profils techniques se démotivent car le contexte les force à produire moins qualitatif qu’ils ne savent le faire, car la hiérarchie sublime la gestion de projet (certainement pour parer aux fautes et lacunes de cette même hiérarchie). Développer c’est créer, et c’est passionnant lorsque l’on t’en donne les moyens!

  13. Juste un mot pour dire que nombre d’idées développées dans ce billet ou dans les commentaires (le fait que développeur est un métier à part entière, l’importance d’avoir des développeurs talentueux, la mauvaise idée de faire un projet avec des hordes de développeurs débutants, etc.) sont présentes, entre autres choses, dans un livre qui a plus de 10 ans mais qui n’a pas pris une ride – et que tout développeur, je crois, devrait lire : « Software Craftsmanship – The New Imperative » http://www.mcbreen.ab.ca/SoftwareCraftsmanship/

    Un petit bémol sur la conclusion que je trouve un poil populiste. Le diplome ne fait pas tout mais les autodidactes qui créent un soft fabuleux à 20 ans restent quand même une exception… Faire quelques études théoriques sur la « science informatique » et apprendre à développer au contact de bons développeurs est, à mon avis, le moyen le plus sûr pour poursuivre dans cette voie.

  14. Venu ici après le Paris Jug du 14/02.

    Très bon article et en tant que développeur/architecte pour une SSII en ce moment j’apprécie très particulièrement :
     » A quoi bon lui mettre sous le nez un plan en « jour/homme » calculé au doigt mouillé ? Nous devons donner des estimations de temps pour des choses que nous n’avons jamais fait, alors même que le client n’est pas certain de ce qu’il veut, et qu’en plus il n’arrive pas à se décider… »

    Et là je me rappelle mon CP pour un client industriel « Le client veut X, ça va mettre combien de temps ? » … Peut être 10 min peut être 2 jours, il faudrait déjà qu’on sache de quoi ça parle non ???

    Heureusement récemment je me suis mis à Grails et Groovy, ma réponse est donc toujours la même « 5 min » 😉

  15. Bonjour,
    Bienvenu dans l’association ! 🙂 C’est exactement l’idée qui nous anime, hors apparatenance a telle ou telle société ou sur tel ou tel outil/framework. Etre développeurs doit retrouver ses lettres de noblesse, et pour cela que nous que nous crééons cette association.

  16. J’approuve le projet mais je trouve dommage que cela fasse doublon avec le MUNCI (association dont je suis adhérent depuis longtemps) qui a grosse modo les mêmes objectifs

Les commentaires sont fermés.