Le poste idéal

Actuellement en recherche de poste, il est plusieurs points qui me font considérer son attrait. Voici une liste sans ordre particulier des choses que je regarde quand on me propose une mission :

• Communication avec les équipes métier : s’il y a plusieurs niveaux d’interlocuteurs voire impossibilité de contacter les expert·e·s métier en direct, alors c’est un problème.
• Communication avec les équipes ops (experts Azure, responsables système, DBA…) : de même, il faut pouvoir travailler dans un cadre sain avec les personnes maîtrisant l’infrastructure sur laquelle tournent nos applications.
• Bienveillance et non-toxicité de l’équipe et du management. Je ne crois pas dans la notion bizarrement répandue de “dictateur bienveillant” qu’on fait parfois porter aux tech leads. C’est à mon avis une approche qui se révèle rapidement toxique et contre-productive ; je lui préfère celle du référent, à la fois plus humble, plus ouverte et nettement plus en adéquation avec ma personnalité.
• Diversité et inclusivité de l’environnement. Une équipe avec des profils divers amènera plus de richesse et de succès qu’une équipe composée des mêmes profils. La tech est un milieu très masculin, peu inclusif et trop rebutant pour de nombreuses personnes ne correspondant pas au stéréotype “homme blanc hétéro cisgenre”. Je souhaite contribuer à changer cela.
• Réactions en cas de crise : l’absence de micro-management est nécessaire, ainsi qu’une bonne communication sur un canal dédié ; la mise en place d’actions après crise (discussions et réflexion long terme) est un atout important.
• Agilité : y a-t-il du travail en flux ou est-ce un cycle en V (même camouflé en sprints) ? Les dates et les deadlines sont-elles des notions importantes ? Par exemple, CI et CD ne sont pas des mots vides de sens, ils impliquent des pratiques importantes comme une synchronisation et une livraison régulières et fréquentes dans la branche principale, idéalement en utilisant le (trunk-based development. Derrière, une batterie de tests automatiques vérifient la non-régression en quelques minutes et une livraison en production est possible plusieurs fois par jour sans stress. Ça n’est pas “on utilise git-flow, on livre dans la branche principale 1 fois par mois, les TNR sont manuels et une livraison en prod prend plusieurs jours”.
• Télétravail : depuis 2020, j’ai pu constater la nette augmentation de ma productivité et celle de l’équipe en général grâce au télétravail. Il me semble primordial que cela soit en place au moins 3 jours par semaine et le présentiel doit avoir du sens, il ne doit pas exister simplement pour rentabiliser les locaux de l’entreprise.
• Temps partiel : de même, travaillant à 80% depuis 2020, j’ai pu voir les bénéfices du travail à temps partiel sur ma productivité et ma communication.
• Amélioration continue : il me semble important que chaque membre dans l’équipe soit à la fois conscient de ses limites et actif voire moteur dans l’action de les repousser.
• Accueillir le changement avec un esprit ouvert : au niveau organisationnel, il y a parfois des barrières à lever ou des choses à améliorer. Les propositions constructives doivent être accueillies à bras ouverts et non réprimées ou traitées avec condescendance. Si un développeur avec plus de 20 ans d’expérience fait des remarques et des propositions d’amélioration des pratiques en place, c’est peut-être un signe qu’il faut en discuter et remettre des choses en question au lieu de rester immuable.
• Approche “test first” : indispensable pour se poser les bonnes questions dès le début du développement et passer le temps qu’il faut dans l’espace du problème au lieu de sauter directement dans l’espace de la solution.
• Dans un contexte legacy : appui voire impulsion du management pour en sortir. Malgré ses défauts, le code legacy remplit un besoin métier ; il est donc précieux pour le métier mais il faut s’y attaquer via des actions de fond comsommatrices de temps et de budget. Je peux être moteur sur ce genre de sujet mais je ne souhaite pas être seul dans ce combat.

Bien sûr on peut discuter et débattre de chacun des points mais ma vision du poste idéal les contient tous.

Les points bloquants

De même, il est plusieurs points que j’estime bloquants, soit parce qu’ils ne correspondent pas à ma vision d’un environnement professionnel, soit parce que j’ai dépassé certains problèmes que je ne souhaite plus rencontrer :

• Toxicité, culture sexiste : en plus de 20 ans, j’ai bien compris que le secteur de la tech avait un problème sur ce sujet. Je ne souhaite pas travailler dans ce type d’environnement qui me paraît totalement obsolète aujourd’hui.
• Process lourds et encombrants : les livraisons en production tous les 2 ou 3 mois et qui durent 1 ou 2 jours complets ne correspondent pas du tout à ma façon de travailler.
• Télétravail moins de 3 jours par semaine : si je reconnais une valeur indéniable au présentiel, elle ne me paraît pas telle qu’il faille passer plus de 2 jours par semaine sur site dans le cadre d’un poste de développeur ou tech lead.
• Estimations à tout va : les estimations sont par essence fausses ; dans le développement logiciel on fait toujours un développement pour la première fois. Passer beaucoup de temps à estimer chaque tâche est à mon sens contre-productif et donne une fausse impression de contrôle tout en accentuant la pression sur les équipes.
• Les propositions et prises d’initiative sont empêchées voire mal vues : dans ce cas ce n’est pas mon profil qui est requis mais celui d’un simple exécutant (qui sera en outre bien moins cher).