Les articles que je vois passer sur les savoir-faire utiles quand on développe sont plutôt centrés sur les aspects techniques (“vous n’êtes pas un·e vrai·e développeur·euse si vous ne connaissez pas le langage XXX”) ou les aspects interpersonnels (“oubliez la technique, l’important pour faire du développement est de savoir communiquer”).
Ces deux aspects sont importants mais, quand je liste les compétences qui me sont utiles au jour le jour et que tout le monde ne maîtrise pas, ou du moins de maîtrise pas en débutant, je constate qu’il manque des choses.
Cette liste n’est pas exhaustive ou universelle mais contient des éléments que je trouve essentiels dans mon travail.
Tenir le rythme de ses mails
Dans une organisation au dessus d’une certaine taille, par exemple au dessus de 50 personnes, le nombre de mails “institutionnels” a tendance à augmenter. J’entends par là les mails envoyés à des groupes dont vous faites partie et qui ne vous concernent pas forcément directement.
Vous recevez ces mails pour de bonnes ou de mauvaises raisons, et il y a peu de chances que vous puissiez agir sur le fait qu’ils soient envoyés.
En revanche, je pense qu’il est important de faire en sorte de parvenir à vous tenir suffisamment au courant de ce qui se passe, c’est-à-dire de prendre connaissance du contenu des mails qui vous concernent, sans que cela ne vous prenne trop d’énergie ou de temps et sans que vous vous sentiez coupable de ne pas lire tous les mails dans le détail.
Il y a de nombreuses manières de faire et de nombreuses techniques pour les mettre en œuvre, par exemple le getting things done. Je n’ai pas de suggestion sur le comment, mais j’ai déjà vu trop de personnes stressées par l’idée d’ouvrir leur boîte mail pour considérer qu’il ne s’agit d’un problème important.
Relancer des personnes
Dans une organisation constituée de plusieurs équipes — que ça soit en interne, ou avec des équipes de prestataires — il arrive régulièrement que des personnes s’engagent à faire des choses dont vous avez besoin, et ne les fassent pas selon le calendrier prévu.
Sur le long terme, il peut être important de comprendre pourquoi et d’essayer de faire en sorte que ça n’arrive pas.
Mais vous n’avez pas forcément le temps ou l’autorité pour vous occuper de cet aspect.
Cela veut dire qu’il faut savoir relancer les personnes pour qu’elles tiennent leurs engagements. Cela n’est pas forcément agréable à faire, et peut même au début sembler insurmontable. Il faut donc essayer de trouver une manière de le faire qui ne vous affecte pas trop.
Par exemple en s’appuyant sur un modèle de mail qui vous semble acceptable, et en le réutilisant plutôt que de devoir à chaque fois écrire une relance à partir de rien.
Lire de la documentation
On s’attend d’une personne qui développe qu’elle sache lire une documentation d’une certaine longueur. En théorie, les personnes on les compétences pour le faire (elles savent lire et ont les compétences techniques pour comprendre le sujet).
En pratique, il s’agit d’une compétence qui s’apprend (et qu’on n’apprend pas forcément pendant ses formations), et qui rebute pas mal de monde. Ces personnes préfèreront par exemple essayer de faire fonctionner un outil en bidouillant du code plutôt que de lire sa documentation de manière détaillée.
Cela peut fonctionner, mais pas tout le temps, surtout si votre travail consiste à aider à résoudre les problèmes qui bloquent les autres.
(Il arrive aussi que de lire la documentation ne soit pas la bonne solution, mais cela ne veut pas dire que ça ne soit jamais le cas.)
Lire de la mauvaise documentation
Comme on l’a vu plus haut, il est parfois nécessaire de lire de la documentation, et donc de savoir lire de la documentation.
Et parfois cette documentation n’est pas terrible : pleine de jargon, mal structurée, n’est compréhensible que quand on connaît déjà le sujet qu’elle est censée expliquer…
Malheureusement, parvenir à extraire des informations à partir d’une mauvaise documentation fait souvent une différence. Dans le développement, il n’est pas rare de tomber sur de la mauvaise doc, par exemple celle de nombreux frameworks qu’on utilise faute de mieux.
Il vaut d’autant mieux maîtriser cette compétence qu’elle est souvent utile au mauvais moment, par exemple quand vous êtes bloqué·e depuis un certain temps sur un bug inexplicable et que vous parcourez la doc de long en large dans l’espoir de trouver l’élément qui vous permettrait de comprendre ce qui se passe.
Se retrouver dans du code inconnu
Savoir écrire du code correspondant à certains critères de “qualité” ou de “lisibilité”[1] c’est important.
Savoir refactorer du code également.
Mais parfois, il faut également arriver à se retrouver dans du code que vous ne connaissez pas, et qui utilise des frameworks et/ou des constructions dont vous n’avez pas l’habitude.
Certains langages qui permettent de nombreux styles sont propices à ce genre de choses, par exemple le C++.
Mais même dans des langages aux pratiques plus unifiées, comme Ruby, cela peut arriver : il suffit parfois d’une personne avec un style bien à elle pour que du code semble écrit dans une langue étrangère.
Et vous n’avez pas toujours l’opportunité de réécrire le code dans un style dont vous avez l’habitude ou de comprendre les choses en profondeur : parfois l’objectif est seulement de comprendre ce qui se passe, ou de modifier un comportement mineur. Il faut alors savoir trouver ses marques sans être envahi·e par le stress de ne pas tout comprendre.
Cela peut s’appuyer sur une forme d’intuition pour comprendre ce que les personnes qui ont développé le programme avaient en tête et les contraintes qui les ont amené à écrire ce code là.
Conclusion
Je pense que ces savoirs-faire sont importants pour qu’une personne puisse faire du développement dans une organisation de manière efficace.
On en parle peu car ils sont difficilement marketable à niveau individuel : ils ne permettent pas de se mettre en avant, au contraire des compétences qu’on associe à des profils de stars.
Comparez ce qu’il arrive à une personne qui lira une documentation pénible lui permettant d’utiliser un outil existant et ce qui arrive à la personne qui préférera se lancer dans l’écriture d’un nouvel outil.
Utiliser ces compétences n’est donc pas toujours le bon choix pour votre carrière, mais je suis persuadé que pouvoir compter sur elles quand c’est nécessaire est très utile, et que cela justifie d’investir le temps nécessaire pour les maîtriser.
Si vous êtes dans une position de manager, rappelez-vous que ces savoir-faire s’acquièrent, et que cet apprentissage peut prendre du temps et nécessiter de l’aide.