Article original : How I Went from Sales to Front End Developer in 16 Months
Par Braedon Gough
Le 18 août 2015, j'étais dans un vol à sens unique à destination de Copenhague depuis l'aéroport Pearson de Toronto. Je commençais mon échange de deux semestres à la Copenhagen Business School.
Je me souviens facilement de la date car c'était l'anniversaire de mon frère. Il a été obligé de le passer à l'aéroport avec notre famille alors qu'ils me voyaient partir pour le Danemark, pour ce qu'ils pensaient être seulement 8 mois.
Ma seule familiarité avec Copenhague venait de regarder le CPH Open sur la chaîne YouTube de Thrasher Magazine. Heureusement pour moi, je suis tombé amoureux de la ville et, après mon premier semestre à l'étranger, j'ai fait de ma mission d'y rester encore plus longtemps. Je devais commencer un stage en retournant au Canada et je me suis lancé le défi d'en trouver un à Copenhague à la place.
Travailler à Copenhague
Je n'avais pas vraiment de plan, alors j'ai commencé à chercher des rôles de représentant au développement des ventes (SDR). Je venais d'apprendre ce rôle de niveau d'entrée dans l'un de mes cours. Comme toute mon expérience précédente était dans la vente et le service client, je pensais que ce serait un bon ajustement.
J'ai envoyé ma candidature à une jeune startup et en moins de 4 heures, j'étais au téléphone avec mon futur responsable des ventes. C'était ma première expérience de la rapidité avec laquelle les choses peuvent évoluer dans le monde des startups ! Environ un mois plus tard, j'avais mon premier jour. C'était aussi la première fois que je rencontrais des développeurs professionnels.
J'ai toujours eu un profond intérêt pour la technologie, bien que le plus proche que j'aie été du développement logiciel à ce moment-là était dans mon cours de Visual Basic au lycée !
Commencer mon nouvel emploi était la première fois que je pouvais travailler directement aux côtés de développeurs. C'était passionnant d'entendre parler de leur travail. Il y avait toujours tant de mots à la mode et de technologies dont ils parlaient – React, Ember, Scala, Python, TypeScript, code boilerplate, compilateurs, rendu. C'était intimidant de penser qu'il fallait en savoir autant pour développer des logiciels.
L'espace de vente où je travaillais
J'ai passé l'année et demie suivante à continuer de progresser dans ma carrière de vente, étant finalement promu responsable de compte. J'avais l'impression d'avoir grandement développé mes compétences en communication, en gestion du temps et en présentation.
Découvrir freeCodeCamp
Bien que j'étais performant dans mon rôle actuel de responsable de compte, je n'étais pas sûr qu'un avenir dans la vente soit exactement ce que je voulais. C'était aussi limitant pour mes perspectives d'emploi futures si je voulais continuer à rester au Danemark – ce n'est pas facile de trouver un bon emploi en vendant en anglais dans un pays où la première langue est le danois !
Je me suis mis à lire davantage, cherchant un nouveau passe-temps ou un défi. C'est alors que j'ai découvert le blog de freeCodeCamp (il était encore sur Medium à cette époque). Il m'a en fait fallu quelques jours avant de réaliser que freeCodeCamp n'était pas seulement un blog, mais une plateforme entière disponible pour apprendre à coder en ligne, gratuitement ! Comme si le nom ne parlait pas de lui-même...
Il n'a fallu que quelques défis HTML pour que je sois absolument accro. C'est alors que j'ai décidé de passer tout mon temps libre à travailler sur le programme de freeCodeCamp, avec l'objectif de peut-être devenir un jour développeur. J'adorais l'idée de pouvoir parler à mes collègues de React, même si cela semblait loin.
Lutter avec les bases
Je me sentais assez confiant dans la rapidité avec laquelle j'apprenais le HTML et le CSS jusqu'à ce que j'essaie réellement de compléter l'un des projets. Créer un simple portfolio ? Cela devrait être facile !
Mais c'était accablant de se sentir soudainement perdu dans un éditeur en dehors de freeCodeCamp. Essayer de commencer un projet à partir de zéro semblait impossible et c'était effrayant de voir à quelle vitesse j'avais l'impression d'avoir tout oublié. Devenir un vrai développeur semblait soudainement une impossibilité.
Demander de l'aide a finalement été la meilleure chose que j'ai faite pour moi-même. Après avoir ruminé ma frustration pendant bien trop longtemps, j'ai contacté un collègue qui m'a patiemment guidé à travers l'utilisation de VS Code, la structuration de mon document HTML et sa liaison à un fichier CSS. Après avoir finalement assemblé un portfolio, j'ai coché la case comme terminée, même si je pensais que mon travail était terrible comparé à celui des autres tentant le même défi.
J'ai finalement commencé le programme JavaScript, que j'attendais avec impatience après environ un mois et demi de lutte avec le HTML et le CSS.
Apprendre JavaScript
Cela a commencé assez facilement, bien que ce ne soit pas longtemps avant que je me sente à nouveau perdu et frustré. Après avoir terminé tous les modules JavaScript, j'ai senti qu'il me manquait la confiance et la ténacité pour tenter les projets JavaScript plus difficiles. Au lieu de cela, j'ai pris la voie facile et j'ai commencé le programme JavaScript de Codecademy.
Cela a certainement été utile pour consolider les bases pour moi – après tout, la répétition est la clé. Cependant, la plus grande erreur que j'ai faite dans mon parcours d'apprentissage a été de ne pas revenir pour tenter ces défis.
Après avoir travaillé sur tous les modules de Codecademy, j'ai commencé un autre cours de JavaScript, achetant cette fois "The JavaScript Bootcamp" sur Udemy. Comme c'était ma troisième fois de travailler sur les fondamentaux, j'ai terminé ce cours avec une base plus stable et plus de confiance dans ma capacité à travailler avec JavaScript.
Commencer chez Pleo
Pleo Team Camp, Déc 2019
De là, je me suis lancé directement dans un autre cours, cette fois sur Node, suivi d'un cours sur React.
Quelque part entre les cours sur Node et React, j'avais commencé un nouvel emploi en tant que gestionnaire de compte dans ce que je considère toujours comme la startup la plus cool du Danemark. C'était et c'est incroyablement excitant de faire partie d'une entreprise qui grandit si vite. C'était encore plus excitant de rencontrer tant de nouveaux développeurs talentueux auprès desquels apprendre.
Environ trois mois après le début de mon nouvel emploi, ma responsable et moi discutions de la façon dont mon rôle pourrait évoluer à l'avenir. J'ai été honnête avec elle et j'ai dit que je n'étais pas intéressé par davantage de responsabilités. Je voulais passer tout temps et toute capacité excédentaires à m'apprendre à coder, dans l'espoir de devenir un jour développeur.
Ce n'est pas quelque chose que vous voulez entendre de la part d'un représentant commercial relativement nouveau dans votre équipe. Mais à ma grande surprise, elle a été incroyablement soutenante et s'est engagée à m'aider de toutes les manières possibles, tant que j'atteignais mes objectifs.
Tentative du défi de codage
Après avoir parlé avec l'un de nos directeurs de l'ingénierie, il était clair que pour que nous puissions continuer une conversation sur ce à quoi ressemblerait une transition de la vente au produit, je devrais compléter notre défi de recrutement front-end, comme le ferait un candidat externe.
L'idée de tenter cela était à la fois incroyablement intimidante et motivante. C'est à ce moment-là que j'ai commencé à rester tard au bureau chaque soir. Je ne voulais pas perdre de temps à faire du vélo pour rentrer chez moi, donc dès que l'horloge affichait 17h00, je me dépêchais de trouver quelque chose à dîner, revenant à mon bureau dès que possible, pour commencer ma journée en prétendant être un développeur.
J'avais enfin terminé mon cours React juste avant les vacances de Noël et je travaillais sur quelques projets parallèles, bien que je n'aie jamais vraiment suivi aucun d'entre eux. Je savais que je devais commencer à appliquer mes connaissances mais j'ai trouvé difficile de compléter un projet sans un objectif final réel.
Avec un peu de temps libre pendant les vacances, j'ai commencé à regarder à nouveau le défi front-end. Je me sentais encore loin d'être capable de produire une soumission digne, cependant, j'ai senti que cela me donnait une sorte d'objectif final à atteindre afin que je puisse enfin terminer quelque chose.
Heureusement pour moi, notre défi front-end était très similaire au projet final du cours React, donc je pouvais réutiliser une grande partie du code boilerplate et des composants pour ma soumission. Je me sentais définitivement comme si je trichais.
Mais j'ai envoyé mon projet quand même et j'ai attendu avec impatience les commentaires. Avoir mon code examiné par deux de nos ingénieurs seniors était incroyablement effrayant et j'étais préparé à des commentaires sévères.
Après quelques semaines, ma note était là, et ma soumission n'était pas un échec total ! J'avais reçu des points de critique vraiment excellents et exploitables. L'un de mes collègues a même passé une heure avec moi après le travail, me guidant à travers chaque ligne de commentaires. Notre session de révision de code s'est si bien passée que nous avons décidé de nous retrouver à nouveau, semaine après semaine, jusqu'à bien après ma transition pour devenir développeur.
Mon premier PR
Mon responsable des ventes et le directeur de l'ingénierie ont continué à vérifier mes progrès au cours des mois suivants. En avril, l'opportunité s'est présentée que je pourrais éventuellement travailler à côté avec notre équipe d'outils internes. Il y avait de nombreux petits tickets non urgents qui nécessitaient de l'attention dans notre système back-office.
J'étais excité – ce serait une excellente façon pour moi d'acquérir une véritable expérience en travaillant avec l'équipe produit et il était très clair que cela ne devait pas interférer avec mon travail dans les ventes. Cette pensée de travailler avec du code réel, en production était INSANE !
Après un peu de coordination, une introduction à l'équipe et une invitation à notre organisation Github, j'ai reçu mon premier ticket à travailler.
Je devais ajouter une entrée pour rendre un champ modifiable pour notre équipe de conformité. Il était immédiatement clair que je n'avais aucune idée de comment faire cela. Bien sûr, j'avais déjà ajouté une entrée auparavant et je savais vaguement comment les formulaires fonctionnaient dans React, mais ce code semblait différent de tout ce que j'avais vu dans mes tutoriels.
J'ai soudainement été laissé avec un océan de questions. Comment fonctionne TypeScript ? Qu'est-ce qu'une branche ? Comment faire un PR ? À quoi servent toutes ces bibliothèques ? Comment mon code est-il construit et envoyé à nos utilisateurs ? Que se passe-t-il si je casse quelque chose d'important ?
Il m'a fallu quelques jours pour me repérer, mais après beaucoup de patience et d'aide de la part du responsable de l'ingénierie, j'ai réussi à obtenir deux approbations et à envoyer du code en production. C'était une étape majeure dans mon parcours.
Faire la transition
Au cours des cinq mois suivants, j'ai continué ma routine de rester tard au bureau, travaillant de 09h00 à 17h00 dans les ventes et de 17h00 jusqu'à tard en prétendant être un développeur travaillant avec ce que je considérais comme du vrai code.
Comme vous pouvez vous y attendre, mon désir de continuer dans les ventes diminuait chaque jour et j'ai commencé à insister pour voir si nous pouvions convenir d'une date pour que je fasse officiellement la transition.
Cela ne s'est certainement pas passé sans heurts. Personne n'avait d'expérience dans ce que cela signifie de déplacer quelqu'un des ventes à notre équipe produit. Tout d'abord, je devais être à la hauteur. Je pense que c'est vrai pour la plupart des organisations de vente – tout revient toujours à atteindre votre quota.
Après beaucoup de discussions, un accord a été conclu que je pourrais officiellement faire la transition le 1er août, à condition que je reste à la hauteur. C'était la lumière au bout du tunnel pour moi. C'était absolument déconcertant de penser que je serais bientôt présenté avec un contrat de travail pour mon nouveau rôle d'ingénieur logiciel. Les semaines précédant ont filé. À 17h00, mercredi 31 juillet, je n'étais plus gestionnaire de compte.
Il y a définitivement eu une période de transition pour s'habituer à mon nouveau rôle. Cela ressemblait à être un courtier en bourse travaillant sur le parquet de la bourse pour soudainement devenir bibliothécaire.
Mis à part le bruit, il n'y a pas eu un seul jour où je n'ai pas été excité à l'idée de venir travailler. J'ai continué à travailler dans notre équipe d'outils internes, construisant notre back-office de conformité et de support client.
Ce que j'ai appris
L'expérience que j'ai acquise dans les ventes est incroyablement avantageuse dans mon travail aujourd'hui. De solides compétences en communication, en gestion du temps et en présentation ont été inestimables en tant que développeur. Mais j'ai constaté que ces compétences manquent dans la plupart des communautés de développeurs que j'ai observées.
Je réalise que j'ai une chance incroyable d'avoir eu l'opportunité de travailler avec du code de production si tôt. C'était sans aucun doute un grand pas en avant dans mon apprentissage et cela a énormément aidé à accélérer ma compréhension des réalités du travail en tant que développeur, ce qui est impossible à acquérir à partir de tutoriels en ligne.
Avoir un mentor avec qui travailler a énormément accéléré mon apprentissage et a été extrêmement utile pour me tenir responsable d'avoir toujours un projet en cours, afin que nous ayons toujours quelque chose sur lequel travailler. Sans tout le soutien autour de moi, je pense que je passerais encore toutes mes nuits et week-ends à travailler sur des tutoriels ou à construire des générateurs de Pokémon aléatoires.
Je me suis engagé tôt à passer tout mon temps libre à continuer mon développement. Je pense qu'il est très facile de sous-estimer l'ampleur de l'engagement en temps que ce parcours nécessite. Avoir accès à un mentor est une grande aide, bien que même quelqu'un avec suffisamment de connaissances pour répondre occasionnellement aux questions peut vous faire économiser des heures de frustration. N'ayez pas peur de demander de l'aide.
En regardant rétrospectivement, j'aurais souhaité passer plus de temps à construire de petits projets et à appliquer les choses que j'ai apprises. J'ai fréquemment commencé des projets mais je n'ai jamais suivi jusqu'au bout parce que je sentais que je ne pouvais pas coder quelque chose de la bonne manière.
Passer du temps à lutter contre quelque chose a été bien plus utile pour mon apprentissage. Il y a certainement une sécurité à rester sur les rails d'un cours de codage interactif, mais cela peut mettre un plafond à votre capacité à appliquer vos connaissances dans le monde réel. Je suis définitivement tombé dans ce piège.
Il m'a fallu un certain temps avant de réaliser que personne ne sait quelle est la bonne manière, tout est inventé. En tant que développeur novice, il y a de la valeur dans une perspective fraîche.
Si j'avais un conseil que j'aurais souhaité avoir plus tôt, ce serait de faire un plus grand effort pour appliquer mes connaissances au fur et à mesure que j'apprenais. Il n'y a pas de vrai code ou de bonne manière de faire les choses, surtout quand on apprend. Chaque chance que vous avez d'appliquer vos apprentissages en cours de route est précieuse.
On ne devient pas développeur quand quelqu'un vous paie pour être développeur, on devient développeur dès la seconde où l'on commence à coder.
N'hésitez pas à écrire si vous avez des questions, envoyez-moi vos recommandations de livres préférés, connectez-vous avec moi sur LinkedIn ou suivez-moi sur Twitter !