Je réfléchis à cet article depuis quelque temps. En fait, depuis un échange de commentaires dans l’un de mes précédents articles.
La question concernait le fait d’embaucher (ou non) des développeurs qui codent pendant leur temps libre. Est-ce une bonne chose ?
Naturellement, j’aurais tendance à préférer un gars (ou une fille, mais ne m’en voulez pas si je parle au masculin) qui développe le soir et le week-end. C’était un feeling plus qu’un raisonnement réfléchi, alors je me suis creusé un peu la tête sur le sujet.
Pourquoi préférer un geek ?
Si on essaye d’être rationnel, il y a plusieurs aspects positifs dans le fait d’embaucher quelqu’un qui passe une partie de ses soirées et de ses week-ends sur son ordinateur :
- C’est un passionné : Quand on se cogne 8 à 12 heures de développement par jour au boulot et qu’on vous demande de l’implication et de l’imagination, on peut vite être «usé» par le temps. Ce qui fait souvent la différence, c’est la passion qu’on éprouve pour l’informatique en général et le développement en particulier. Ce n’est pas pour rien que la passion est un critère fréquemment cité par tous les recruteurs.
- Il fait une veille techno active : J’ai déjà parlé de l’importance de la veille technologique. Un développeur passionné, c’est bien ; un développeur qui explore de nouveaux horizons, c’est mieux. En prenant du temps personnel pour faire du développement, il essaiera des techniques différentes de celles dont il a l’habitude, et cela pourra n’être que profitable pour l’entreprise sur le long terme.
- Il accorde peu d’importance à la politique : Ce n’est pas évident pour tout le monde, mais le monde de l’entreprise est un terreau fertile pour l’apparition de comportements «politiques». Et il n’y a rien de plus désagréable et improductif que d’avoir des guéguerres de pouvoir. Un vrai geek, passionné par l’informatique au point de développer sur son temps personnel, s’attachera le plus souvent à bien faire son travail sans s’occuper des manigances des uns et des autres. Dans une entreprise bancale, ça pourrait jouer en sa défaveur, mais dans une entreprise “normale”, ce sont les politiciens qui sont mis à l’écart.
Pourquoi faudrait-il éviter un geek ?
D’un autre côté, il existe aussi des raisons pour ne pas souhaiter embaucher un codeur fou :
- Il n’est intéressé que par le défi technique : Nous avons tous connu des informaticiens qui changent régulièrement d’entreprise parce qu’ils s’ennuient rapidement. Dès qu’ils ont l’impression d’avoir fait le tour de ce qu’ils pouvaient apprendre et de ce qu’ils pouvaient apporter, ils ressentent le besoin irrépressible de partir ailleurs. Et même si pendant l’entretien d’embauche ils vous disent «Votre annonce correspond précisément à ce que j’ai toujours recherché !», vous ne savez absolument pas quels seront leurs moteurs internes dans 6 mois.
- Il peut s’essouffler rapidement : Si l’usure du temps le rattrape plus vite que ne le fait avancer sa passion, il risque d’en avoir plus rapidement assez du développement que vous n’auriez pensé. Et le jour où votre développeur de génie vous dire «J’en ai marre du développement, je veux devenir chef de projets / faire du décisionnel / faire du référencement / devenir commercial», vous allez faire une drôle de tête.
- Il peut avoir un déséquilibre social : Même si tous les geeks ne répondent pas aux clichés que l’on s’en fait, certains restent toutefois des asociaux ou des autistes latents. Le fait de développer le soir et le week-end n’est alors qu’un indicateur de leur incapacité à avoir une vie sociale équilibrée. Et cela voudra dire que les mêmes difficultés de communications les gêneront dans l’accomplissement de leur travail (à moins de les faire bosser tous seuls au fond d’une grotte, sans interaction avec qui que ce soit, mais c’est assez rare).
- Il peut privilégier ses projets personnels : C’est le revers de la médaille qui est habituellement passé sous silence. Les gens ont des passions, c’est normal et souhaitable pour maintenir un équilibre personnel. Mais à l’inverse de la plupart des passions qui ne peuvent pas se pratiquer au travail (sport, musique, tricot, élevage d’alligators nains), le développement informatique est une activité à laquelle les développeurs peuvent s’adonner même quand ils sont au boulot. On ouvre juste un fichier supplémentaire, on se connecte par SSH à un autre serveur… et on passe 4 heures à développer un petit-truc-qui-prendra-5-minutes.
Conclusion
Comme souvent, on se retrouve là sans avoir une grande vérité unique et absolue. Chaque situation est différente, chaque personne est spéciale.
Il y a des avantages et des inconvénients. Mais en fait il s’agit de risques plutôt que d’inconvénients réels. En tout cas, rien qui ne soit détectable et rectifiable avec un management efficace.
Pour ma part, je valorise le codage personnel chez les jeunes informaticiens, pour deux raisons :
- Ils n’ont pas encore l’expérience et les habitudes nécessaires à la mise en place d’une veille technologique correcte. Leurs projets personnels peuvent en tenir lieu pendant un certain temps, et les aidera à trouver leur propre méthode de veille.
- L’expérience est une chose très importante. On l’oublie parfois, mais il y a une vraie différence de qualité et de rapidité entre un développeur junior et un informaticien qui a plusieurs années de travail derrière lui. Les projets personnels sont un moyen efficace pour engranger rapidement de l’expérience supplémentaire. On réussit mieux ses études d’informatique quand on développe des projets personnels en plus de ceux imposés par le cursus. Il en est de même avec l’expérience professionnelle.
Par contre, chez des informaticiens expérimentés, je privilégie ceux qui savent faire une vraie veille techno et qui ont une vie personnelle équilibrée. Ce sont ceux qui ont la meilleure expérience professionnelle et qui savent le mieux en faire profiter l’entreprise.
je crois qu’on a la même analyse sur les profils de développeurs.
J’ai même un exemple intéressant : j’ai travaillé pour Yahoo! un temps, et il y a quelques années ils ont voulu se doter de vrais développeurs Web à Londres. La méthode de recrutement a consisté à aller chercher tous les blogueurs et même certains qui écrivaient des bouquins, et à écumer les conférences sur les technos du Web.
En quelques mois, ils se sont donc retrouvé avec une équipe de gens vraiment très bons : le niveau technique était franchement très élevé, moi qui regardait tout ça depuis Paris, j’ai énormément appris pendant le temps que ça a duré.
Et puis il a fallu que tous ces champions se mettent à délivrer, et passé le premier projet de chacun, ça n’a pas été une mince affaire que de canaliser toute cette créativité et cette excitation : ce qui sortait était d’une bonne qualité technique, mais les tests n’étaient pas plus poussés qu’ailleurs, les deadlines n’étaient pas vraiment respectées, et le debugging était vécu comme une punition et par conséquent très mal traité.
Au bout de 2 ans, la moitié de l’équipe a démissionné un par un
Bref d’après cette expérience et d’autres, je pense qu’il faut essayer de varier les profils dans une équipe : un bon uber-geek pour de la veille techno et aller au fond de certains concepts, 1 developpeur chevronné et cher payé, généralement lead technique, pour essayer de faire (faire) du code qui tiendra longtemps la route, et un mix de juniors passionnés ou très raisonnables pour faire avancer le travail.
J’ai une question qui pourrait peut être faire l’objet d’un post entier pour toi : nous sommes habitués à avoir le Net toute la journée sur nos postes. et sur le Net, il y a énormément de mix perso-pro : facebook, twitter, le mail, les messengers … nous sommes une génération de zappeur, et les juniors trouvent ça complètement normal.
A ton avis, va t on finir par réguler dans les équipes de dev ces comportements de zappeur ? en n’autorisant le perso qu’entre midi et 2 par exemple, et la veille techno 1h par jour le matin.
La dernière fois que j’ai soufflé l’idée, on m’a traité de nazi communiste 🙂
Commentaire très intéressant. Surtout, la réflexion sur le « panachage » des compétences dans une équipe me donne matière à réflexion.
Pour la question soulevée à la fin du commentaire, on pourrait effectivement en parler longuement. Je pense que la réponse tient en 2 points :
– Il faut éduquer et responsabiliser les gens.
– Tous les usages nouveaux génèrent des abus. Quand le téléphone coûtait cher, les gens passaient 3 heures par jour pendus au bout du fil, au boulot. Quand Internet n’était pas encore démocratisé, les gens passaient 2 heures par jour à envoyer et recevoir des emails, au boulot. Puis les gens ont commencé à surfer pendant 15 minutes par heure, en estimant qu’il s’agit d’une activité normale. Puis sont arrivés les messageries instantanées, puis maintenant Facebook et Twitter…
Il n’y a pas de solution miracle. Les américains ont leur méthode : Tu te débrouilles comme tu veux pour faire ton boulot ; si tu veux bosser 4 heures aujourd’hui et 12 heures demain, pas de soucis ; si tu veux surfer 3 heures d’affilée, no problem ; par contre, si ton boulot n’est pas fini dans les temps, tu vas te faire taper sur les doigts très fort. Et là-bas, tu ne te fais pas taper sur les doigts deux fois de suite ; la deuxième fois, tu es viré du jour au lendemain. Résultat, les gens font ce qu’il faut pour faire leur boulot.
Est-ce vraiment mieux en terme de confort de travail ? Je ne le pense pas. Je remarque juste que, en France, ceux qui trouvent normal de glandouiller au travail (électroniquement ou non, la pause-café reste chronophage) n’ont même pas présent à l’esprit qu’ils risquent leur emploi à cause de cela.
La grande différence entre les USA et la France en matière de taf, c’est surtout que « là-bas » il existe une vraie culture du résultat, mais surtout une vraie culture du « fixage d’objectif » avec les évaluations qui vont avec. En France, on a trop souvent des managers qui ne connaissent ni vraiment leur boulot ni même le management, alors leur demander d’évaluer ce qui a été fait ou non relève encore de la science fiction 😉
… et potentiellement des gratifications qui vont avec les résultats.
🙂 C’est assez vrai.
Il y a une vraie différence culturelle. Mais bref, ce n’était pas le sujet de l’article, gardons ces digressions pour plus tard.
Que faites-vous si vous devez gérer un geek qui bâcle son boulot, pour passer du temps sur un projet perso ? Ça m’est déjà arrivé et je serais curieux de savoir comment d’autres personnes ont affronté cela.
Ca dépend du style de chacun :
Si le travail est baclé ou pas rendu dans les temps qu’eux même m’ont donné (on estime le temps de dev en même temps que le périmètre et la solution technique) on parle de pourquoi le résultat n’est pas obtenu.
A ce moment là en discussion tête à tête j’essaye de voir si il sait lui même pourquoi il en est là, et je lui rappelle les règles de base (on ne mélange pas pro et perso, on évite de se foutre de moi …)
Je n’y suis pas encore arrivé, mais au bout de plusieurs discussions comme ça, si la situation n’a pas changé, c’est sûrement qu’il n’y plus rien à faire : ça n’est plus un passage à vide, ça devient une rebellion ouverte. A partir de là, il vaut mieux ne plus travailler ensembles
Pas d’expérience dans ce domaine, mais j’imagine qu’il faut trouver un compromis, genre : réduire le reste à faire, mais de resserrer les échéances ?
Hmmm, ce n’est pas parce qu’on n’est pas un geek, qu’on travaille mieux, au sens respect des deadlines, debugging, etc. J’ai des collègues informaticiens pas du tout passionnés par l’info, qui n’en font pas en dehors de leur job, qui manquent cruellement de curiosité… et ce n’est pas pour autant qu’ils bossent mieux en terme de qualité de production. Je ne pense pas que ce soit corrélé.
Autre remarque : quelqu’un qui dirait « «J’en ai marre du développement, je veux devenir chef de projets / faire du décisionnel / faire du référencement / devenir commercial», euhhh c’est pas un passionné d’info, ça ! C’est juste un touche-à-tout qui ne doit pas creuser grand chose. Le geek au sens « suivre la mode », qui peut faire un peu de veille superficielle au mieux.
Le côté « j’embauche un passionné pour qu’il bosse aussi sur son temps perso, mais je veux pas qu’il bosse perso sur son temps pro » est assez savoureux. Merci pour la franchise !
@Oelita : Pour le premier point, on est d’accord.
Pour le second point, je parlais des geeks qui s’essoufflent. De manière générale, c’est vrai pour n’importe quel travail, tout le monde peut arriver à saturation de n’importe quelle situation extrême.
Pour le troisième point, on s’est mal compris. Quand je dis que je cherche des gars qui codent le soir et le week-end, je ne parle pas de code professionnel, mais bien de projets personnels. Parce qu’en travaillant sur des projets perso, ils augmentent leur expérience, ils s’intéressent à des choses différentes, ils testent des choses qui pourraient un jour être utiles au travail.
8 à 12h de développement pro quotidien, plus des développements perso et vous voulez des gens équilibrés ?
Quelle contradiction !
Une vie équilibrée c’est 8h de travail, 8h de repos, 8h de sommeil. On peut faire légèrement varier en fonction des personnes mais ça devrait être de cet ordre.
Faire bosser (ou laisser bosser) un développeur jusqu’à 12h par jour, outre l’illégalité totale de la situation, pour qu’en plus il se farcisse quelques heures de dev perso supplémentaire c’est vouloir des gens complètement désaxés.
Je suis tombé sur ce blog récemment, c’est bourré d’articles pertinents mais j’avoue être pas passé loin de tomber de ma chaise en lisant celui-ci.
J’ai également un gros problème avec ces employeurs qui voudraient que leurs employés se forment à leur propre frais. Je trouve ça complètement hallucinant. Je ne nie pas que les meilleurs profils sont ceux qui effectuent cette veille si critique en informatique mais quand même …
@Marc : Non, tu interprètes mal ce que j’ai écris. Je ne dis pas que je fais bosser mes développeurs 12 heures par jour ! (cette simple idée les ferait mourir de rire, je t’invite à passer dans nos locaux le matin et le soir, tu verras)
Disons que 8 heures par jour est effectivement la durée normale de travail quotidien. Puisque les développeurs sont habituellement des cadres, on est en droit d’attendre d’eux de répondre présent lorsqu’il y a une urgence ponctuelle (dans ma boîte, on est resté 2 fois au bureau jusqu’à 22h à cause d’une mise en production délicate : décembre 2010 et septembre 2012). Dans ce cas-là, on peut imaginer aller jusqu’à 12 heures de travail ; au-delà c’est vraiment inutile, on va faire plus d’erreurs qu’autre chose.
Enfin, sur la question de la veille techno, je persiste à dire qu’elle est importante, et qu’elle peut faire la différence entre deux informaticiens. Mais on est d’accord, cela ne remplace pas la R&D organisée au sein de l’entreprise. Ce sont juste deux choses différentes, et je ne vois pas en quoi mon article dirait le contraire.