Récemment, on a beaucoup parlé sur twitter de l’ingénieur 10x qui a lancé un grand débat sur ce qui fait un bon ingénieur. Certaines choses vraiment stupides ont été mentionnées telles que « les ingénieurs 10x détestent les réunions » et « les ingénieurs 10x arrivent en retard au bureau » et « le fond de l’ordinateur portable des ingénieurs 10x est généralement noir ». En général, il semble que certaines personnes pensent que si vous êtes assez intelligent, il est normal d’être un connard.
Dans Wix, nous essayons de laisser les connards derrière la porte. Nous croyons que les ingénieurs 10x ne sont pas seulement des gens qui peuvent produire 10x plus vite que la plupart des gens, même plus, ce sont des gens qui peuvent rendre toute une équipe 10x meilleure en ayant une influence positive sur toute personne avec qui ils travaillent.
Beaucoup de gens passent une grande partie de leur carrière à devenir ce que nous pensons être un ingénieur décent. Cela signifie que vous êtes un bon codeur, qui peut résoudre des problèmes et qui maîtrise l’utilisation des outils qui sont à votre disposition tels que l’IDE, le débogueur, les services et les frameworks. Cet article tente de décrire ce que nous, à Wix Engineering, pensons faire d’un ingénieur décent un ingénieur 10x.
L’une des capacités les plus importantes d’un ingénieur est d’être capable de travailler de manière indépendante. En un mot, cela signifie de toujours savoir ce que vous devez faire et d’être rarement dans une situation où vous attendez que quelqu’un vous dise quoi faire. Cela ne signifie pas que vous êtes capable de tout faire par vous-même, mais que vous savez vous débloquer et débloquer les autres membres de votre équipe d’une manière propre qui crée une dette technique minimale. Par exemple, si vous êtes bloqué par un problème, vous trouverez une solution, que ce soit en demandant l’aide de vos pairs ou en le résolvant par vous-même. Les ingénieurs indépendants ont la capacité de mener un projet de l’idée à la production en passant par toutes ses phases. Ils sont capables de définir quelles sont les choses dont ils ont besoin pour pouvoir accomplir une tâche et ils savent quand lever le drapeau s’ils ont besoin d’aide.
Planification
La chose la plus difficile avec laquelle on voit les ingénieurs moins expérimentés se débattre est d’être capable de prendre une grande tâche et de la décomposer en petites étapes. Ceci est important non seulement pour pouvoir estimer combien de temps quelque chose prend, mais c’est aussi une partie critique de la construction de logiciels de haute qualité. Une planification correcte permet au développeur de diffuser la version initiale du produit le plus tôt possible et de commencer à recevoir des commentaires plus rapidement. Une planification correcte signifie que vous avez une conception du système dès le début et que vous avez une bonne idée de ce que vous allez faire avant de vous jeter à l’eau. Une planification correcte signifie qu’il n’y a pas de grosses surprises qui brisent votre conception pendant le développement. Un bon ingénieur devrait être capable de décomposer une tâche, de définir la conception et les phases de sortie, et de fournir des documents de conception et des estimations pour montrer son plan.
Humilité
C’est un difficile. Même les ingénieurs les plus forts ont souvent des progrès à faire en matière d’humilité. Cela signifie ne pas être amoureux de ses propres solutions. Être capable d’écouter et d’accepter les solutions des autres. Supposer le meilleur de vos pairs et, lorsque vous voyez quelque chose qui semble être une erreur, essayer d’en comprendre le raisonnement. Ouvrez les choses à la discussion. Laissez les gens proposer leurs propres solutions. Partagez vos idées et ne vous souciez pas d’en obtenir le crédit. Il est plus important que chacun se sente à l’aise avec une idée et sente que c’est un travail d’équipe que de savoir que c’est votre idée. Soyez honnête. Accordez du crédit aux autres. N’ayez jamais peur de dire que vous aviez tort ou de reconnaître que quelqu’un d’autre a raison. Les gens respectent ceux qui peuvent changer d’opinion.
Réutiliser
Cela peut paraître trivial, mais la plupart des gens ne comprennent pas que la meilleure façon de progresser est de s’appuyer sur un travail antérieur. Les ingénieurs moins expérimentés ont toujours la mauvaise habitude de penser que la meilleure façon pour eux d’avancer rapidement est d’ignorer tout ce qui existe déjà et de recommencer. Les bons ingénieurs vont toujours rechercher, apprendre, poser des questions et comprendre toutes les solutions existantes déjà disponibles. Même si la solution existante présente des lacunes, ils essaieront de voir comment l’améliorer avant de décider de la remplacer. Ils ne rejetteront jamais une solution existante sans l’examiner en profondeur et sans parler avec le propriétaire de la solution existante.
Etat d’esprit de l’infrastructure
Comme décrit ci-dessus, la réutilisation d’un travail antérieur peut avoir un impact énorme sur les gens. Cela signifie que les ingénieurs doivent toujours être à l’affût pour voir s’ils ont l’occasion de créer quelque chose de réutilisable. La chose la plus facile à faire lorsque vous avez une telle opportunité est de l’ignorer. Rendre les choses réutilisables coûte toujours plus cher au « créateur » que de ne pas les rendre réutilisables, c’est pourquoi de nombreuses personnes à courte vue ignorent les avantages qu’elles et les autres équipes en retireront par la suite. Un bon développeur identifiera les opportunités de créer des choses réutilisables, saura comment les rendre réutilisables de la meilleure façon, et investira l’effort nécessaire pour le faire.
Maîtrisez votre domaine
La seule façon de trouver de bonnes solutions est de comprendre en profondeur le produit sur lequel vous travaillez. Les bons ingénieurs n’ont pas seulement une compréhension profonde du produit qu’ils développent. Ils comprennent également tous les cas d’utilisation, comprennent la motivation du produit et peuvent facilement avoir une conversation significative avec le chef de produit, contester les décisions et proposer des alternatives. Ils savent quelles sont les fonctionnalités importantes et quelles sont celles qui le sont moins, ils savent comment établir des priorités en fonction de cela et proposer des solutions de contournement si nécessaire. Ceci est important non seulement pour le produit sur lequel vous travaillez, mais aussi pour tout produit avec lequel vous vous intégrez.
Curiosité
Les bons développeurs doivent avoir une saine curiosité qui s’étend bien au-delà des frontières de leur domaine. Cela est particulièrement vrai pour apprendre comment les technologies sous-jacentes fonctionnent réellement, mais il est tout aussi important de comprendre les produits sur lesquels les autres équipes travaillent, leur architecture et la façon dont ils se connectent en tant que système complet. Avoir ce contexte plus large peut être inestimable lors de la résolution de problèmes complexes et une source d’inspiration.
No boundaries
Nous voyons souvent que la source de mauvaises solutions et de mauvaises architectures est ancrée dans le fait que les gens ont peur de changer les choses qui sont en dehors des limites de leur boîte. Le développeur client aura tendance à résoudre les choses sur le client, même s’il est préférable de le faire sur le serveur. Le développeur d’applications aura tendance à résoudre le problème localement, même si la solution se trouve dans la plate-forme ou dans l’infrastructure. La raison en est simple. Il est plus facile de ne pas créer de discussion avec une équipe différente, il est plus facile de traiter le monde hors de votre portée comme une boîte noire, il est plus facile de traiter avec le diable que vous connaissez. Mais les bons ingénieurs doivent savoir qu’ils font partie d’un grand système et qu’aucune partie du système n’est vraiment hors de leur portée. Discuter d’un changement d’architecture avec une autre équipe est sain et utile et peut ajouter à votre perspective. Proposer de contribuer au changement dont vous avez besoin est excellent pour établir la confiance entre les équipes. Toucher un nouveau domaine est une expérience dont vous ne pouvez que bénéficier. Plus important encore, lorsque vos limites deviennent plus souples, cela signifie que votre impact augmente. Chaque fois que vous évitez de sortir de vos limites, réalisez que ce que vous faites en fait, c’est vous empêcher d’avoir un plus grand impact.
Responsabilité / propriété
Bien que cela ne soit pas immédiatement apparent, très souvent, si vous creusez la cause profonde de la raison pour laquelle un certain projet a été retardé ou a échoué, vous trouverez que cela se résume à la propriété et à la responsabilité. Les gens auront toujours tendance à blâmer leur entourage : « J’ai dû attendre qu’une autre équipe termine quelque chose », « J’ai eu un problème de système et personne n’a eu le temps de m’aider », « J’ai reçu les définitions trop tard ». Un bon ingénieur sait que ces choses sont presque toujours des excuses. Lorsque vous êtes le propriétaire de la tâche et que la responsabilité de sa réalisation vous incombe, votre état d’esprit doit être que chaque problème que vous rencontrez est quelque chose que vous devez résoudre. Si vous êtes bloqué par une autre équipe, allez leur parler. Proposez de travailler en binôme sur le problème et ne « jetez » pas la responsabilité sur quelqu’un d’autre. Si vous n’avez pas encore obtenu de définitions, faites quelques hypothèses sur ce que seront les définitions. Il est préférable de faire des progrès et de procéder à des ajustements par la suite, plutôt que de rester assis et d’attendre. Si quelque chose d’important vous retarde, sachez quand lever le drapeau et savoir comment contourner le problème afin de pouvoir au moins progresser sur un autre front. Ne soyez jamais dans une situation où quelqu’un d’autre est responsable de résoudre votre problème, c’est l’inverse – vous êtes responsable d’arriver à la ligne d’arrivée et vous devez gérer les obstacles sur le chemin.
Communication
C’est un véritable changeur de jeu et souvent la chose la plus critique à avoir pour qu’un ingénieur puisse avoir un impact énorme sur toute l’équipe. Être capable de communiquer est la plus grande chose qui a permis à l’humanité de devenir ce qu’elle est, évidemment la même chose est tout aussi critique pour tout aspect de la vie, y compris l’ingénierie logicielle. Les bons ingénieurs doivent être capables d’expliquer avec éloquence leurs idées et leurs opinions. Ils doivent être capables de débattre intelligemment et respectueusement avec leurs pairs. La communication ne consiste pas seulement à parler, il est encore plus important de savoir écouter. Tous les membres de l’équipe ne sont pas en mesure d’exprimer leurs idées de la même manière et un bon ingénieur doit être patient et poser les bonnes questions pour comprendre ce que pensent les autres et les aider à se faire entendre. Tout cela est aussi important pour la communication orale que pour la communication écrite, et surtout, il ne s’agit pas seulement de converser – la vie des développeurs est remplie de tonnes de formes de communication : documents, présentations, documentation, commentaires de code, messages de validation. Même écrire du code lisible et choisir de bons noms de variables est une forme de communication.
Travail d’équipe
C’est l’un des endroits où même les ingénieurs expérimentés échouent très souvent et ne savent même pas que cela se produit. Pensez à toutes les fois où vous avez dit « c’est trop compliqué, laissez-moi faire ». Pensez à toutes les fois où vous avez dit « cette tâche est le travail d’une seule personne, ajouter d’autres personnes ne la rendra pas plus facile ». Pensez à toutes les fois où vous n’avez pas eu le temps d’aider quelqu’un d’autre et n’avez jamais donné suite, où vous avez corrigé/réfacturé le code de quelqu’un sans lui demander son avis, ou où vous avez effectué un changement important sans consulter votre équipe. Il y a des tonnes d’exemples. Et le fait est que même pour les ingénieurs expérimentés, cela semble être la bonne chose à faire sur le moment. Mais il s’agit d’un raisonnement tactique qui ne porte ses fruits qu’à court terme. Si nous voulons réaliser de grandes choses, nous devons nous assurer que nous pouvons collaborer en équipe. Ce n’est pas un hasard si le travail d’équipe vient juste après la communication. Ce sont les éléments qui nous rendent les plus efficaces, c’est de la biologie de base. Les grands ingénieurs ne se contentent pas de collaborer avec leurs pairs, de les consulter, d’apprendre d’eux, de les aider, de les jumeler et de les respecter, ils jouent également le rôle de mentor, signalent les problèmes, s’intéressent et apprennent de tout ce qui se passe dans l’équipe et essaient de manière proactive d’être utiles, même pour des choses qui ne les concernent pas directement. Les ingénieurs étonnants savent quand et comment proposer des conceptions qui faciliteront la collaboration de nombreuses personnes sur des choses où beaucoup de travail est attendu.
Gardez-le simple
La complexité d’une solution peut être l’un des tueurs silencieux de la capacité de l’équipe à avancer et à s’adapter. C’est comme l’hypertension artérielle. Pour l’œil non averti, il semble que tout va bien et que tout fonctionne comme prévu, mais en fait, au fond de vous, quelque chose qui n’affecte directement aucune fonctionnalité principale vous tue lentement. Les bons ingénieurs créent des solutions pragmatiques et un code lisible, même si vous écrivez plus de lignes de code. Ne montrez pas à quel point vous êtes « intelligent » en utilisant toutes les capacités du langage, en créant des niveaux d’abstraction redondants ou en écrivant une fonction en une seule ligne que personne d’autre ne peut comprendre ou déboguer. Ne soyez pas un puriste, ne sur-ingénieriez pas les solutions lorsque ce n’est pas absolument nécessaire et n’ayez jamais peur de prendre quelque chose qui est déjà complexe et d’essayer de le simplifier.
Prioriser
Nous ne pouvons pas tout faire. Nous ne pouvons pas résoudre tous les problèmes. Nous ne pouvons pas gagner tous les débats. Nous ne pouvons pas tout rendre parfait. Nous avons un temps et des ressources limités et nous devons les utiliser à bon escient. Cela signifie que nous devons être capables de distinguer ce que nous devons insister à faire, ce que nous pouvons reporter et ce que nous devons ignorer. Les développeurs prennent ces décisions des dizaines de fois par jour. Lorsque nous nous demandons s’il faut enquêter sur un bogue, lorsque nous envisageons de procéder à une refonte, lorsque nous envisageons de traiter un cas d’utilisation ou un cas limite, lorsque nous envisageons de faire un détour par rapport à la tâche prévue et même lorsque nous investissons du temps pour convaincre quelqu’un de notre opinion. Les bons ingénieurs savent qu’ils doivent s’acharner à réparer, enquêter, rechercher ou insister pour faire valoir leur point de vue sur les choses qui sont vraiment importantes. Ils savent qu’il est possible de prendre une note et de revenir plus tard sur une question si elle est importante mais pas urgente. Et ils savent laisser quelque chose de côté ou accepter l’opinion de quelqu’un d’autre même s’ils en sont mécontents lorsque ce n’est pas vraiment si important.
Gestion du temps
Comme mentionné plus haut, la triste vérité de notre existence est que nous sommes liés par le temps. Les produits que nous développons doivent éventuellement être mis en ligne, nous avons des délais, des estimations et des objectifs à atteindre. Les bons développeurs doivent non seulement développer une intuition pour estimer le temps que prennent leurs tâches, mais ils doivent également être astucieux dans la façon dont ils décomposent et ordonnent leurs tâches en parties encore plus petites. Ils doivent gérer judicieusement leurs interruptions et leurs changements de contexte. Cette intuition de l’estimation du temps est une partie indissociable de la capacité à établir des priorités comme décrit ci-dessus. Par exemple, si une tâche est suffisamment courte, elle peut valoir la peine d’être effectuée même si elle n’est pas super importante. Et si c’est trop long, il serait peut-être préférable de reporter un peu ou de consulter vos pairs ou votre manager.
Conclusion
Comme mentionné précédemment, nous pensons que les ingénieurs experts dans tous les domaines ci-dessus peuvent rendre l’équipe 10x meilleure en influençant et en inspirant leurs pairs. Les grands ingénieurs doivent toujours se rappeler que cela fait partie de leur travail quotidien : influencer et inspirer. Cela signifie que vous devez trouver le temps non seulement de faire votre travail, mais aussi d’aider les autres à faire le leur. Cela peut prendre de nombreuses formes : encadrer les membres de votre équipe, créer des ressources pour éduquer les gens, s’assurer que tout est bien documenté, être toujours prêt à expliquer et à travailler en binôme avec les autres, et bien plus encore. Être un bon mentor et un bon éducateur signifie que vous n’aidez pas seulement les membres de votre équipe à grandir, cela approfondit également votre compréhension de tout ce que vous faites et cela vous donne une nouvelle perspective sur la clarté des choses, la complexité du système et les endroits où les choses peuvent s’améliorer.
Ce sont les éléments constitutifs des ingénieurs 10x, non seulement dans leur impact individuel, mais aussi dans leur impact sur tout le monde. Demandez-vous toujours ce que vous pouvez faire pour rendre votre impact plus grand, il y a toujours plus de place pour croître.