50 qualités d'un Tech Sénior

Dans mes premières années de développement, j'avais une vision très naïve de la séniorité. J'ai longtemps pensé qu'un senior connaissait tout par coeur, avait réponse à tout, et avait déjà tout fait. Le cliché du geek super intelligent qui tape très vite sur son clavier et fait tout 10 fois plus vite qu'un autre. N'ayant jamais été ce type de personne, je me suis longtemps considéré comme junior, probablement à tort.

Je me suis alors mis en tête d'essayer de lister quelles pouvaient être ces qualités (y compris celles que je n'ai pas), et j'essaie de les partager ici, un peu en vrac. Bien entendu, cela reste une vision personnelle, forcément biaisée par ma propre expérience.

Décisions

1. Il prend généralement des bonnes décisions (en sachant qu'il est facile d'en prendre des mauvaises - orientées par la mode, par ses propres préférences, biais d'expérience) plutôt que par les besoins métiers. L'informatique, aussi passionnante soit-elle, reste une fonction support.
2. Mais il prend parfois une mauvaise décision, plutôt que de ne pas en prendre du tout.
3. Il choisit les bonnes technos pour résoudre les bons problèmes, quitte à mettre ses préférences de côté…
4. …mais est suffisamment lucide pour ne pas choisir le meilleur outil qu'en fonction de l'outil lui-même, mais aussi en fonction de l'équipe, ses compétences, et ses aspirations.
5. Il est suffisamment persévérant pour trouver la solution à un problème, mais sait quand arrêter pour ne pas perdre trop de temps, et choisir une solution de contournement.
6. Il est pragmatique plutôt qu'idéaliste. Il a compris que la techno parfaite n'existe pas, et accepte que le choix soit une question de compromis. Il comprend qu'une techno n'est jamais meilleure qu'une autre par définition, mais dans un contexte propre.
7. Il sait qu'une codebase n'est pas une oeuvre d'art et sert avant tout le business. En ce sens, il sait avoir le bon ratio entre développement de features et qualité de la codebase.

Conception et Architecture

8. Il montre une pensée "haut niveau". Tel un oiseau qui aurait une vue d'ensemble d'une situation.
9. Il sait qu'un système simple est plus fort par définition. Il évite à tout prix toute complexité inutile, dite "complexité accidentelle".
10. Il est capable de concevoir un système dans son ensemble sans rentrer dans le détail d'implémentation.
11. Il anticipe les besoins potentiels futurs, sans forcément passer du temps à les implémenter à ce moment.
12. Il anticipe les risques et prend le temps adéquat pour atténuer les plus probables et les plus impactants.
13. Dès qu'il a un besoin non trivial, il recherche une manière connue d'y répondre (ex : design pattern, package externe, etc).
14. Il sait évaluer la pertinence de construire soi-même from scratch ou d'utiliser un package externe à la place, en fonction de la situation.
15. Lorsqu'il évalue un outil payant, il fait la part des choses entre les annonces marketing et les bénéfices réels. Il ne choisit pas une techno juste parce qu'elle est nouvelle ou à la mode, mais bien parce qu'elle apporte de la valeur. Il accepte volontiers de garder des "vieilles" technos qui répondent parfois mieux au besoin de par leur stabilité.
16. Il sait que le code n'est pas la solution à tout et accepte volontiers que certains outils "no-code" soient plus adaptés, ou aucun outil du tout, quitte à ne pas être mis en valeur.

État d'esprit et personnalité

17. Il essaie de faire du mieux qu'il peut, mais pas sur n'importe quoi, car tout peut toujours être amélioré. Il sait gérer ses priorités et fait attention à ce que sa passion ne desserve pas son équipe.
18. Dans tout ce qu'il fait, il pense constamment aux autres, que ce soit les utilisateurs, ou ses propres collègues.
19. Il a des convictions, des opinions qu'il s'est forgées à travers le temps et l'expérience.
20. …tout en étant capable de remettre en cause ces  mêmes convictions au fil du temps.
21. Plus généralement, il sait mettre son égo de côté et avouer qu'il a pris une mauvaise décision, sait dire quand quelqu'un est meilleur que lui.
22. Tel un artisan qui voudrait les meilleurs outils, il passe du temps pour améliorer sa propre expérience de développement (ex : apprendre les raccourcis claviers, avoir des templates de projets pour démarrer plus vite, avoir des docs, avoir les bonnes extensions dans l'IDE, etc.)
23. Lors d'une situation d'urgence (ex : production tombée), il garde ses moyens et sa lucidité pour résoudre le problème. Il rassure au lieu de diffuser le stress.
24. Les réflexes qui proviennent de son expérience lui permettent d'éviter des pièges dans lesquels il est déjà tombé. Plus généralement, il fait des connexions entre des problèmes rencontrés, et des apprentissages passés.

Code, tests, debug

25. Il comprend les problématiques de complexité d'une codebase et de dette technique liée. Il sait que moins il y a de code, mieux c'est. Il est davantage satisfait de retirer du code qu'en ajouter.
26. Il sait qu'une fois que ça marche, la mission n'est pas terminée. Il vérifie que le code est suffisamment clair pour pouvoir le reprendre, l'opportunité de le nettoyer, ou éventuellement ajouter une couche d'abstraction à ce moment.
27. En plus du code lui-même, il met systématiquement en place tout ce qui est nécessaire autour : documentation, diagrammes, process, tests, etc.
28. Il comprend l'intérêt des différents types de tests (unitaires, intégration, E2E) et sait quand les implémenter ou ne pas les implémenter. Il évite de tester à la main quand un test écrit est aussi rapide et surtout, réutilisable.
29. Lorsqu'il a un problème, il procède par dichotomie pour rapidement en identifier la source.
30. Il sait à quel moment essayer lui-même de résoudre le problème, ou faire appel à une aide extérieure.
31. Il est capable de décrire son erreur avec précision et les détails nécessaires, pour pouvoir se faire aider au mieux.
32. Une fois résolues, il prend des notes des erreurs qu'il pourrait rencontrer de nouveau dans le futur, pour pouvoir les résoudre plus vite, car il sait que sa mémoire est limitée.

Connaissances et apprentissage

33. Il a un large spectre de compétences techniques : algorithmique, langages, frameworks, couches logicielles, infra, réseau, etc. Il est à la fois généraliste, mais aussi spécialiste dans un (T shaped) ou plusieurs (M shaped) sujets.
34. Il conçoit qu'il est impossible d'être expert partout, mais souhaite être capable de comprendre les domaines analogues au sien dans les grandes lignes. A chaque fois qu'il découvre une techno ou un outil, il essaie de comprendre l'intérêt et le périmètre de l'outil en question, sans rentrer dans le détail.
35. Il a compris que les connaissances s'imbriquent les unes aux autres et qu'une curiosité permanente va lui permettre de résoudre beaucoup plus de problèmes au fil du temps.
36. Il a des facilités à creuser et apprendre rapidement un sujet quand c'est nécessaire. Il sait qu'il ne sait pas, mais sait évaluer s'il peut apprendre rapidement ou pas.
37. Il s'ouvre volontiers à de la veille sur des technos qu'il n'utilise pas, pour garder une vision d'ensemble du marché.

Ouverture aux autres, travail en équipe, autres compétences

38. En plus des compétences techniques, il a une appétence à comprendre les autres métiers qui lui sont liés (produit, UI/UX, opérations) et comment la tech leur sert.
39. Il interagit avec les autres pour comprendre le contexte et le besoin. Il va chercher ces informations de manière proactive.
40. Il sait que démarrer du code sans connaître le besoin et avoir des spécifications claires, est le meilleur moyen de devoir recommencer, et qu'il a donc souvent besoin des autres.
41. Il a une tendance naturelle à transmettre son enthousiasme et ses connaissances autour de lui. Pas pour étaler sa science, mais pour faire progresser, en particulier les juniors.
42. Il a à la fois de la patience et de la tolérance envers un débutant. Il récompense les bons comportements (désir d'apprendre et de comprendre) tout en sachant être ferme lorsqu'il détecte un mauvais comportement (paresse, etc.). Il concède que l'état d'esprit est plus important que le niveau pur à un instant T.
43. Il implémente les bonnes pratiques et s'assure, s'il est en position de le faire, que l'ensemble des développeurs les comprennent et les appliquent aussi. Il s'assure de garder une codebase la plus unifiée possible…
44. …Tout en laissant un niveau de liberté nécessaire à un épanouissement, car il conçoit que le développement est un métier créatif, et que l'exécution pure est peu intéressante.
45. Il est capable d'intégrer un environnement qui n'est pas le sien relativement rapidement en cherchant activement les bonnes infos autour de lui pour monter en compétences.
46. En plus de ses compétences techniques, il sait communiquer avec clarté, que ce soit à l'oral ou à l'écrit, de manière synchrone ou asynchrone. Il vulgarise des concepts techniques complexes à des gens non techs en sachant cacher les détails, et en sachant se mettre à la place de celui à qui il explique la chose.
47. Il est proactif, ne se comporte jamais comme un exécutant, et remet en question lui-même et les autres quand c'est pertinent.
48. Il ne micro-manage pas, et essaie de faire briller les juniors.
49. Son charisme et son flegme sont rassurants pour les juniors. C'est un guide sur lequel on peut compter. Il transmet une culture et une passion.
50. Il connaît ses points faibles et est capable d'en parler sans peur autour de lui. Il crée ainsi une atmosphère de confiance et de collaboration, plutôt que de concurrence.

Conclusion

Je pense garder à jour cette liste, en la faisant évoluer au fil de mon expérience, la relire avant un entretien, et la partager à toute personne qui se poserait les mêmes questions que moi.