Comment je suis devenu développeur 100x - En tant que junior

L'idée qu'un développeur 10x, ou un développeur rockstar, soit meilleur que tous les autres développeurs en tout, est un mythe.

Au lieu de cela, vous devriez vous efforcer d'être un développeur 100x dans des situations très spécifiques, un développeur 10x dans certaines et un développeur 1x dans le plus grand nombre possible. Il est important d'être conscient des domaines dans lesquels vous excellez et des domaines sur lesquels vous devrez peut-être travailler.

À moins que vous ne travailliez pour une grande entreprise de technologie, il est probable que vous porterez plusieurs chapeaux. Au quotidien, vous devrez être capable de basculer entre le développement front-end, back-end et spécifique à un langage, tel que Java ou TypeScript. Cela est dû à la nature en constante évolution de notre industrie et au grand nombre de façons d'accomplir les mêmes tâches - comme imprimer "Hello World" dans plus de 400 langages de programmation différents.

Il est impossible d'être bon dans tout, mais il est possible d'être bon dans quelque chose.

Pour élaborer, j'aimerais partager une histoire d'il y a plus de dix ans qui a été un moment qui a changé ma vie et qui a eu un impact énorme sur ma carrière.

Comment je suis devenu développeur 100x - en tant que junior

J'ai travaillé avec une grande multinationale et faisais partie d'une équipe qui avait du mal à répondre à la demande.

Ils avaient créé une application Web Java personnalisée que des milliers d'employés utilisaient quotidiennement, mais à mesure que le nombre d'enregistrements entrant et sortant des serveurs SQL augmentait. Les choses ralentissaient. Ils avaient déjà mis à niveau le serveur SQL jusqu'à ses limites et avaient besoin de nouvelles solutions. Une évidence consistait à utiliser Memcache pour mettre en cache certains des résultats.

Malheureusement, Memcache avait été interdit en raison de certains incidents de sécurité dans le passé et du manque de HA. Les responsables avaient essayé d'obtenir l'approbation de Memcache pendant plus d'un an, mais avaient échoué. Pendant ce temps, les développeurs ont mené une bataille difficile car chaque amélioration de 10 % était annulée par le double de la croissance des utilisateurs.

C'est là que je suis entré et que j'ai rejoint.

Je n'avais aucune idée de leur dernière année de lutte et j'avais été recruté en tant que développeur junior pour aider à apporter quelques améliorations mineures à l'interface utilisateur, tandis que les seniors se concentraient sur les performances.

Cependant, j'étais très ennuyé par la lenteur des performances du serveur de développement. Et j'avais joué avec Hazelcast - une toute nouvelle bibliothèque de clustering et de mise en cache de serveurs basée sur Java.

Je l'ai utilisé comme alternative à Memcache. Et a pu le faire fonctionner sur l'application, qui n'avait aucune restriction particulière ni exigence d'approbation spéciale, ce qui a tué toutes les solutions précédentes.

Et avait un prototype fonctionnel avec une démo prête dans la même semaine. Pour une page de la plateforme, les appels API sont passés de plus de 10 secondes à moins d'une seconde. Cela a changé la donne.

Toute l'équipe a sauté à bord, et en un mois, nous avions une "solution de clustering qui n'est certainement pas Memcache" en production.

Alors que mon chef d'équipe et son patron offraient à tout le monde un banquet, mon manager m'a dit que lorsqu'il m'a amené à bord en tant qu'enfant intelligent, il ne s'était jamais attendu à ce que je sois un programmeur 10x ou 100x capable de résoudre ses problèmes du jour au lendemain.

Et cette déclaration m'a beaucoup frappé.

Parce que j'étais un imposteur – rien qu'un imposteur chanceux.

L'imposteur chanceux - Qui était un développeur 0.1x

Techniquement, je n'étais pas un développeur 1x ou même 10x. J'en savais moins que mes coéquipiers et j'apprenais sur le tas.

Mes pairs savaient mieux faire le front-end que moi et l'équipe savait comment optimiser SQL (et m'a appris, merci !). Mon plus grand crédit est que j'ai pu faire l'équivalent de "npm install miracle" et lire son manuel sur la façon de le configurer.

Avec le recul, il y avait beaucoup de problèmes que j'avais esquivés par chance.

• Politique (qui a bloqué Memcache en premier lieu)
• Cas d'utilisation (nous n'avions aucune sécurité de contention en écriture, ce qui signifie que si 2 modifications se produisent dans la même ms, le cache sera mal mis à jour. Heureusement, cela se produit rarement)
• Stabilité (v1 de hazelcast plante comme un fou, heureusement que le serveur API a été conçu pour être déployé en mode HA, donc c'était au pire une gêne pour l'équipe infra)
• Sécurité (Avoir un port ouvert vers toutes les données sur le serveur API dans un cluster, était une mauvaise idée de ma part, et une erreur très mineure jusqu'à ce qu'un autre senior lise heureusement la documentation sur la façon de le sécuriser)
• Pile de langage (si le serveur était en Python, .NET, C# ou Ruby, je n'aurais aucune idée de comment même inclure un cache de cluster local)

J'ai eu la chance d'avoir une poignée de poneys à un tour, ce qui m'a fait 100x dans les bonnes situations. Ce qui n'a été possible que grâce au travail de fond mis en place par le reste de l'équipe.

J'ai également eu la chance que mes managers et mes patrons m'aient permis de choisir les problèmes que je voulais résoudre, car ils m'ont accéléré et m'ont envoyé dans plusieurs équipes pour "résoudre leurs problèmes". Tout en me permettant de maximiser mon rapport chance/impact et de répéter les « miracles ».

Avec l'expérience, j'ai aussi réalisé le contraire : je suis lent en développement front-end. C'était ce que j'étais censé faire à l'origine avant d'être accéléré en tant qu'ingénieur 10x et cela m'a beaucoup fait réfléchir au fil des ans. Comme cela aurait pu être le chemin sur lequel j'aurais été bloqué.

Cela m'a aussi frappé avec le recul, d'avoir "maîtrisé" le hazelcast, et diverses autres technologies. Combien cela aurait échoué pour d'autres équipes, même dans la même organisation, n'eut été de la situation unique, et des garde-fous, qui auraient dû être crédités au reste de l'équipe.

J'ai eu de la chance, en tant que junior, sinon quoi que ce soit d'autre.

C'est pourquoi les développeurs seniors ont tendance à être 10x développeurs juniors

Une fois que nous regardons au-delà des généralisations de l'ingénierie, il devient clair que chacun a ses compétences, qui peuvent aller de 100x à 0,1x.

Au fil des ans, alors que j'évoluais dans de nombreuses équipes et projets, je suis finalement devenu un développeur "senior". Pendant ce temps, j'ai réalisé que les personnes âgées ont généralement plus de compétences et savent ce qu'elles font de bien et de mal. Ils peuvent informer leurs responsables de manière proactive et hiérarchiser les tâches en conséquence. Cela ne signifie pas qu'ils savent tout faire, mais cela signifie qu'ils savent ce qu'il ne faut pas faire.

Les juniors, d'autre part, ont du mal avec cela car ils n'ont pas l'expérience nécessaire pour savoir en quoi ils sont bons ou mauvais. Il n'y a pas de moyen facile de le savoir autre que de simplement "essayer".

Une fois que cela est compris, il devient évident qu'il s'agit de maximiser le nombre de choses que vous savez pouvoir faire de manière fiable et efficace. Il s'agit également de maximiser votre facteur chance lorsqu'il s'agit d'assigner des tâches et de vous assurer que vous n'êtes pas coincé avec des choses pour lesquelles vous êtes mauvais.

D'une certaine manière pour les juniors, leurs progrès dépendront fortement de l'alignement de leur chance et de leurs compétences. Les personnes âgées avaient plus de contrôle (mais pas totalement) sur la façon d'orienter leurs progrès.

Dans ce cas : La chance n'est pas binaire. Vous pouvez augmenter le nombre de situations qui vous correspondent.

Comment maximiser votre chance de situation à 100x et 10x

Pour tout le monde, mais surtout pour les juniors et ceux qui débutent, la meilleure chose à faire est de continuer à essayer de nouvelles choses en matière de technologie et d'exploration. Cela vous aidera à déterminer ce dans quoi vous êtes bon et ce dans quoi vous êtes mauvais.

Pour ceux qui ont une meilleure idée de ce dans quoi ils sont bons, la prochaine étape consiste à augmenter le nombre de situations où ils peuvent faire de leur mieux. Cela implique un peu de pratique et de recherche sur les technologies adjacentes à celles qu'ils connaissent déjà. Une fois que vous devenez excellent dans quelque chose, assurez-vous de le posséder afin que vos managers et vos patrons sachent que c'est ce qu'ils devraient vous donner. Cela augmentera les chances de rencontrer ces situations 10x ou 100x plus fréquemment.

Trouvez au moins une chose dans laquelle vous êtes bon, même si c'est une chose très petite et étroite. Construisez à partir de là. (Certains exemples notables incluent regex et la configuration de webpack.)

Pour les seniors, si vous ne l'avez pas déjà fait, commencez à regarder au-delà des aspects techniques du développement. Cela ne signifie pas que vous devez passer à la gestion. Mais grâce à vos connaissances techniques uniques, vous pouvez jouer un rôle plus actif dans la compréhension de l'utilisateur ou du cas d'utilisation métier. Cela vous permettra d'optimiser avec vos managers pour assurer des taux de réussite 10x ou 100x pour vous et votre équipe.

Pour ceux qui recherchent un emploi, si vous savez que vous êtes doué pour quelque chose, même si c'est 10x, faites des recherches et approfondissez votre recherche d'emploi. Essayez de trouver une startup ou une multinationale bien financée qui rencontre des difficultés dans le domaine dans lequel vous excellez. Bien que cela puisse être difficile à réaliser et implique un certain réseautage, si vous vous placez au bon endroit et au bon moment, cela maximisera l'impact pour vous et l'entreprise concernée.

Ce sont toutes des choses que vous pouvez faire lentement au fil du temps, pour améliorer le facteur chance. Et offrez cette expérience 10 fois plus cohérente.

Merci de lire l'article swyx sur la façon de créer de la chance : swyx.io/create-luck

En tant que directeur technique et chef d'équipe aujourd'hui, cela tient toujours - 10x est un mythe - tout le monde est à la fois 100x et 0,1x

Certains peuvent penser que le CTO d'un outil de test d'interface utilisateur tel que Uilicious.com serait bon avec les technologies frontales. Cependant, c'est loin de la vérité. Notre nouvelle recrue moyenne ou junior dans l'entreprise est généralement plus rapide que moi le CTO lorsqu'il s'agit d'écrire des composants frontaux avec des frameworks frontaux modernes tels que Vue.js ou React.

Cela a changé ma perspective en tant que chef d'équipe/manager. Cela m'a montré à quel point le mythe de l'ingénieur 10x est toxique et mauvais. C'est une simplification excessive des étiquettes et une généralisation de situations très particulières. C'est une idée fausse toxique qui doit être corrigée.

Presque tous les mythes des ingénieurs de démarrage 10x, lorsqu'ils sont approfondis, s'avèrent avoir un individu avec des connaissances uniques au bon endroit et au bon moment. Et a pu éviter les tâches auxquelles ils étaient 0,1x.

Dans mon cas, il s'agissait de se concentrer sur l'infrastructure plutôt que sur le développement frontal. Où à la place, j'ai d'autres membres de l'équipe qui sont 1000 fois meilleurs pour le développement frontend.

C'est une prise de conscience importante en tant que manager car, pour chaque individu qui est 100x à une tâche, il y a une tâche qui les rend 0,1x alors qu'ils sont bloqués dans un puits de temps. Il s'agit de comprendre et de reconnaître ce à quoi chaque individu est 100x et ce à quoi il est 0,1x.

Bien que cela semble très simple, c'est beaucoup plus difficile dans la pratique.

Il y a beaucoup de choses qu'un chef d'équipe ou un développeur ne saura pas avant de l'avoir essayé auparavant. Ou ont le temps et l'opportunité de perfectionner et de maîtriser les compétences impliquées dans ces situations spécifiques. Il y a aussi beaucoup de choses, en particulier les nouvelles technologies, pour lesquelles personne n'est bon, et il s'agit de prendre des risques et des chances.

C'est le travail du chef d'équipe d'organiser les tâches en conséquence pour répondre au mieux aux besoins de chacun. Et si ce n'est pas possible, il s'agit aussi de comprendre que même si quelqu'un ne peut pas être 100x dans votre situation maintenant, il peut potentiellement être ailleurs dans d'autres équipes.

Et c'est à chaque développeur individuel de déterminer ce dans quoi il est bon et mauvais, et de le communiquer à son équipe en conséquence.

Alors à mort avec le mythe de l'ingénieur 10x, vive l'ingénieur 100x dans des situations spécifiques

PS : Si vous n'avez pas pris de résolutions pour la nouvelle année. Peut-être qu'augmenter votre surface de chance pourrait l'être !

~ 🖖 vivre longtemps et prospérer

Eugene Cheah : CTO de uilicious.com

Publié à l'origine sur : https://substack.tech-talk-cto.com/p/dev-to-cto-how-do-i-become-a-10x

Crédits image

• Austin Neill - image rockstar : unsplash.com/photos/sxxnM-tRlVg
• XKCD - bande dessinée sur les normes : xkcd.com/927
• CenturiiC - Bande dessinée sur des ingénieurs expérimentés : twitter.com/CenturiiC/status/15660603678258..
• Lucas Santos - Photo de dés : unsplash.com/photos/XIIsv6AshJY
• Vlad Hilitanu - Figues Lego : unsplash.com/photos/1FI2QAYPa-Y