Félicitations. Convaincre un grand chef de donner des sous est généralement une compétences dont nous, simples mortels, sommes dépourvus. Il nous arrive d'en ressentir une certaine frustration.
La mentalité peut varier du tout au tout. Je suis passé par des grandes banques Françaises, par des boites de courses de chevaux, par un éditeur de logiciels Français, et je suis désormais chez un éditeur de logiciels américain. Eh, euh, comment dire, il y a beaucoup de differences. Avec quelques points communs tout simples quand même, dont je parlerais plus bas. Mais si tu cherches un mode d'emploi qui te permette de comprendre tous les développeurs, tu est mal barrés, nous sommes un groupe extrêmement hétérogène.
Premier point : il n'existe pas de développeur type. Tout ce qui me fait bander fera fuir 80% des autres développeurs(ah, un bon petit programme cobol de 36 ans d'âge à refondre, sans specs, sans commentaire, et avec des noms de variables en deux lettres - j'ai kiffé ma race. La plupart des développeurs qui me lisent vont me prendre pour un fou - et pourtant, ce ne sont pas, pour la plupart, des rigolos).
Deuxième point : il ne s'agit pas d'un monde, mais de tout un tas de mondes juxtaposés.
Ce vieil article de Joel Spolsky en détaille 5, mais il y en a bien plus de nos jours(et nombre de ses constatations sont un peu démodées).
Conclusion de ces deux points : il faut avoir l'esprit ouvert, et accpter d'être surpris. D'autant plus que le programmeur est souvent(mais pas toujours) un individualiste qui aime marquer son territoire, et qui exigera qu'on respecte ses bizarreries à lui. La programmation est un effort intellectuel intense, très solitaire, et qui convient plus à des personnalités fortes.
la première question tombe dans le mauvais sens, à mon humble avis. Chaque développeur a ses propres marottes(les miennes sont très
old tech, je les garde pour moi). L'idée, au contraire, c'est de choisir une techno(éventuellement avec l'aide d'un architecte, ou du lead technique qui sera la base de l'équipe, pour ensuite prendre des gens qui aiment ça).
La question des challenges est bien plus intéressante. Elle est très dépendante de la personnalité, mais le principe de base(qui s'applique aussi dans d'autres domaines), qui est de sortir gentiment de sa zone de confort, me parait parfaitement applicable. Après, quand on ne connait pas le domaine, ça peut être plus difficile à identifier. Et motiver les gens sur une gestion de cimenterie peut être moins facile que sur le calcul de l'influence de Jupiter sur la trajectoire des satellites. Sur ce point là, je ne sais pas si tu auras beaucoup de marge de manoeuvre.
L'environnement de ses rêves n'est pas dans tes moyens. l'open-space est l'horreur pour un développeur qui a besoin de silence pour se concentrer, et on ne trouve plus que ça sur le marché. Même la personne qui t'a débloqué un budget n'a sans doute pas les moyens de te fournir
un espace de travail convenable. Je suis passé récemment d'un
open space à 12 à un
open space à 2(le reste n'est pas encore occupé), et j'ai facile gagné une heure de productivité par jour. Mais je ne me fais aucune illusion : dès qu'il y aura de nouveaux recrutements, mon petit paradis sera envahi. Et ma productivité va retomber. Et ce sera facile à mesurer.
Pour le team management, il faut absioluemnt comprendre sur quel rythme fonctionnent les développeur. Pour résumer
cet article de Paul Graham, là ou un manager peut faire des tâches de une demi-heure et rester productif, il est très difficile de faire des sessions de travail de moins de une demi-journée. Mettons un dev qui arrive à 9h30, tu lui mets une réunion à 10h30, à 10h30 il va manger, à 14h30 nouvelle réunion - sa journée est foutue. Il ne va pas avoir le temps de commencer de grandes choses. Il va au mieux arriver à faire un petit truc entre 15h30 et 18h30. Parceque cognitivement, faire un développement, ça demande de monter en mémoire(celle du cerveau, pas celle de la machine) un très grand nombre d'informations. Puis de travailler avec. Et
chaque interruption est mortelle pour ce processus.
Ca fait toujours plaisir de voir passer des gens différents - et civilisés. Tu constatera aussi aux réponses de mes prédécesseurs(j'ai failli faire la même remarque sur le digital, mais ils m'ont grillé) que étant confrontés à des machines qui font autre chose que ce qu'on veut à la moindre imprécision mineure(une collègue a un jour fait perdre 5M€ à son employeur pour un point mal placé dans un code de milliers de lignes), nous avons l'habitude aussi d'être très exigeants sur des points qui paraissent être du détail. Ce n'est pas pour le plaisir d'être canulants, c'est notre activité quotidienne qui nous forge de la sorte.
