Ce jeune homme était complètement mordu de programmation.
Quand je lui ai demandé ce qu'il voulait faire dans la vie, il m'a dit : "Je veux être chef de projet".
Ah?
Un peu surpris, je lui explique qu'en tant que chef de projet, il risque de ne pas programmer beaucoup. Réponse : "Je sais, mais j'ai peur de me lasser du code".
Ah?
Valeur sociale
Le monde français de l'éducation et de l'entreprise, dans le domaine des technologies de l'information comme dans beaucoup d'autres domaines, est gangréné par la prestigiosite. C'est un syndrôme psychologique qui affecte en général plutôt les hommes, âgés de 30 ans ou plus. L'individu affecté est alors sujet à des troubles sévères du jugement et du comportement.Par exemple, un individu atteint peut émettre des propos incohérents, du type : "Pisser du code, c'est bon pour les indiens. Mon fils, tu seras chef de projet dès ta sortie de l'école de commerce. Tu auras des responsabilités, c'est normal, tu es mon fils ; et tu auras un gros salaire. Mais moi vivant, tu ne seras jamais, tu m'entends ?, jamais technicien."
Chez ces individus-là, le monde est divisé entre ceux qui font et ceux qui décident. Il est bon et noble de décider, mais faire, c'est bien trop en-deçà de leur condition. Programmer, c'est faire ; beurk! Diriger des projets, c'est décider. Yabon!
Les individus qui ont contracté la prestigiosite développent en général d'autres symptômes, parmi lesquels on retrouve, en vrac : un goût marqué pour les réunions, une capacité de travail accrue (il n'est pas rare de les voir rester au bureau jusqu'à 21h), l'impression de tout savoir sur tout, la perte soudaine de tout esprit créatif au travail, une tendance à la déshumanisation (ils se mettent à parler de "ressource" pour dire "personne"), etc.
On comprend alors aisément qu'on retrouve souvent ces individus à des postes de cadres.
Recrutement
Et puis il y a aussi ces enterprises qui ne savent pas recruter. Dans celles-ci, dès qu'un de nos sujets d'étude a du développement à faire faire, il appelle la DRH (ou l'acheteur, si l'entreprise est une grosse consommatrice de prestation de service) en lui donnant la liste de mots-clefs qu'il ou elle doit utiliser pour trouver des candidats. Par exemple: "C#, XML, SOAP".Celle-ci tape alors ces mots-clefs dans Monster. Elle trouve quelques CV, et applique un algorithme relativement simple :
- Un "Epita, .Net, XML". Il n'y a pas marqué "C#". Eliminé.
- Un "C#, XML, SOAP, 10 ans d'expérience". Eliminé - pas assez flexible.
- Un "Supaéro, C, Automobile". "Supaéro" est un mot-clef spécial qui vaut trois autres mots-clefs dans un CV. Il manque "XML" et "SOAP", mais ils sont ainsi compensés par "Supaéro", avec même encore un peu de marge. Il y a marqué "C", qui ressemble très fort à "C#", et "Automobile" est certainement un plus. Entretien.
"Vous maîtrisez le XML?"
"Oui."
"Parfait. Votre profil nous intéresse. Quand pouvez-vous commencer?"
Subtil, n'est-ce pas? Le commun des mortels n'y voit en général que du feu, mais nos fameuses DRH, elles, savent immédiatement et avec un taux de certitude très élevé que le candidat possède la compétence "XML". Eh! N'est pas DRH qui veut, en France!
Le candidat n'a pas trop parlé de technique, ce qui est toujours bon signe (cela veut dire qu'il n'est pas un "geek", qu'il a des amis, qu'il sort le soir, etc). Et le processus d'embauche de se conclure positivement pour les deux parties sur la signature d'une convention de stage (le candidat n'a que 26 ans), sorte d'outil d'alchimiste qui transforme des "candidats" en "ressources".
Du code, c'est du code
Revenons à notre patient atteint de prestigiosite. Celui-ci trouve ainsi, quelques jours plus tard, la ressource livrée directement devant la porte de son bureau. Il la parque dans sa boquette et lui explique qu'elle trouvera toutes ses instructions dans le document "FRF BPP 3045984 A - Outil de gestion d'informations.doc" (description du projet, méthodes de travail norme ISO, référentiel documentaire, etc). Les toilettes sont au fond du couloir à droite.L'outil en question a été développé deux ans plus tôt en C#, avec une conception objet relativement soignée et quelques principes plutôt malins mettant en oeuvre la reflectivité du langage. Notre ressource, elle, qui connaît le C (elle a rigoureusement suivi les 18 heures de langage C en première année d'école), et qui devrait donc être parfaitement adaptée à ce projet, parce que la DRH sait exactement comment recruter ce type de profiles, n'a en réalité aucune idée de conception objet, n'utilise que des variables globales, et mettra un désordre sans nom dans le code qui deviendra peu à peu presque impossible à maintenir et qui sera dix ans plus tard remplacé par un outil du marché, très cher, mais qui fonctionne presque.
Evidemment, notre sujet, si par hasard devait lui venir l'idée que la qualité du code de cet outil pouvait avoir un impact quelconque sur sa fonctionnalité (la qualité du code mènerait à la qualité du logiciel), voir même, hérésie!, sur le fonctionnement de son équipe ou même de l'entreprise (la qualité du logiciel mènerait à la qualité du travail), verrait alors que la ressource en question n'était manifestement pas adaptée à ce projet.
Mais soyez rassurés : cette idée ne lui viendra pas. Tout simplement parce que du code, ce n'est "que du code".
Car pour notre sujet, la qualité d'un logiciel n'est liée qu'à la qualité du cahier des charges et du plan de recette. Il n'existe absolument aucune relation entre le code produit par la ressource et la qualité du logiciel. Aucune. C'est parfaitement indépendant. Et c'est bien pour ça qu'il aurait finalement bien mieux valu faire faire ce développement par Sasken en Inde. Ils écrivent des choses comme
for (i = 1; i <= 3; i++)
{
switch (i)
{
case 1: f1(); break;
case 2: f2(); break;
case 3: f3(); break;
}
}Le résultat net
Le résultat net de cette attitude, c'est que les jeunes qui arrivent sur le marché du travail en ayant envie de coder sont très fortement dévalorisés. Leurs compétences ne sont pas reconnues, ou le sont mal (note: "C" != "C#"). Ils sont employés à faire un travail considéré comme bas de gamme, et lorsqu'ils ont envie de proposer des solutions qui leur permettraient de faire les choses bien, on leur répond qu'on n'a ni le temps ni le budget et que de toute façon, on n'en a rien à faire si c'est amusant ou pas, l'important c'est que le cahier des charges et les délais soient respectés, et que c'est comme ça la vie, et que tu vois, je te l'avais bien dit que le code ça t'ennuierait, mais garde espoir petit homme, après 12 mois de stage puis 24 mois de CDD tu auras assez d'expérience pour devenir chef de projet junior et là tu pourras décider de ce que les moines copistes, pardon, les codeurs, feront ou ne feront pas, et tu gagneras plus de sous, et tu seras enfin un homme.Bisque, bisque rage.
Développeurs, choisissez mieux
Quand on est jeune, bien sûr, et en particulier quand on sort de l'école, le choix de l'entreprise dans laquelle on va travailler n'est pas si libre que ça. Il faut sans doute passer par quelques années d'expérience pas follichonnes pour pouvoir accéder ensuite aux bons jobs.Néanmoins, il est bon de connaître les signes qui permettent de faire la différence entre les entreprises où les développeurs sont respectés pour ce qu'ils sont, c'est-à-dire souvent les véritables artisans du succès commercial d'un produit, et pas vus comme des moines copistes mis à la disposition du manager polytechnicien qui, lui, sait tout.
Remarquez que quand je parle de Supaéro, de Polytechnique ou de l'Epita, je ne juge aucune de ces écoles. Je critique par contre l'importance que prend le nom de l'école sur le CV auprès des recruteurs. Personnellement, je n'ai jamais trouvé de relation directe entre le talent d'un développeur et l'école dont il sort. C'est parce que Les bons développeurs, je crois, ont appris chez eux dans leur chambre plutôt que sur les bancs de la fac.Or donc, si vous cherchez une entreprise où vous pourrez vraiment vous éclater, voici quelques signes intéressants :
- C'est un éditeur de logiciel. Eh! oui, ça paraît bête, mais c'est vraiment chez les éditeurs qu'on trouve le code le plus intéressant à écrire. En société de service, le développement peut être très intéressant, et vous aurez l'occasion de découvrir des tas de choses souvent un peu exclusives, mais vous n'aurez pas la notion de produit, de qualité parce qu'on aime la qualité, etc, et les choix de fonctionnaltiés seront très souvent faits par d'autres.
- Vous êtes recruté par des développeurs. Personne ne peut mieux juger des compétences d'un développeur qu'un autre développeur. Il est rare de ne voir aucune DRH durant le processus de recrutement, mais si c'est un développeur qui vous contacte et qui est présent lors de votre entretien, c'est déjà bon signe.
- Cherchez les tests pratiques! Pas les tests psychométriques, non. Je veux parler de code. Le seul moyen de s'assurer qu'un développeur sait programmer, c'est de le faire programmer. Sur papier ou sur ordinateur, ce n'est pas grave, l'important c'est d'écrire du code et d'en parler. Certaines entreprises envoient un exercice de programmation à faire chez soi, d'autres vous demanderont d'écrire du C sur un tableau blanc à l'entretien. Attention toutefois aux QCM: n'importe quel HEC peut imprimer un QCM et comparer vos réponses avec la liste préétablie des réponses attendues. Programmer devant le recruteur, en discuter ensuite avec lui, c'est en général très bon signe.
- Un développeur travaille avec son cerveau, tout comme les écrivains. Les écrivains qui peuvent écrire dans le bruit, de 9h à 18h, avec la même efficacité chaque jour ne sont pas nombreux. Les développeurs, pareil! Si l'endroit est calme et que les horaires sont flexibles, ce n'est pas forcément signe de gestion débonnaire et de farniente, c'est peut-être tout simplement le signe que l'entreprise à su mettre en place des conditions de travail favorables aux développeurs. A l'inverse, si on vous montre un océan de boquettes avec des téléphones qui sonnent toutes les dix secondes et une horloge pointeuse à côté de la porte d'entrée, ce n'est pas forcément signe que l'entreprise ne sait pas développer, mais ça peut indiquer qu'elle n'est pas tout à fait en phase avec les besoins de base des développeurs.
- Pas de recherche par mot-clef! Si l'entreprise développe en Java, et qu'elle ne veut entendre parler que de gens qui connaissent parfaitement le Java, méfiance. Un bon développeur peut apprendre un nouveau langage en quelques semaines, surtout s'il en connaît déjà plusieurs, ce qui est presque toujours le cas, et ses acquis dans d'autres langages sont souvent un avantage précieux. Discriminer sur les langages et technologies maîtrisés par le candidat n'est pas un bon signe.
- Des livres! Même si les développeurs trouvent aujourd'hui énormément d'information sur Internet, il y a un certain nombre de livres qui sont véritablement des mines d'or. Même si cela risque d'évoluer à l'avenir, un bon livre sur un sujet précis reste aujourd'hui la meilleure source d'informations techniques. Alors si on vous montre une belle bibliothèque fournie qui contient trois Stroustrup, le Brooks, les Knuth et quelques Tannenbaum, ou qu'on vous raconte qu'on achète volontiers des livres à la demande des développeurs, c'est très bon signe. Ca veut dire qu'ils ont au moins le soucis d'être bons. Et au passage, ça paraît bête à dire, mais assurez-vous que l'entreprise laisse l'accès à Internet à ses employés - croyez-moi, ce n'est pas le cas partout.
Jeu de briques
Snake
Pacman
Bubble