Comment apprendre à coder et obtenir un emploi de développeur [Livre complet]

Article original : How to Learn to Code and Get a Developer Job [Full Book]

Si vous voulez apprendre à coder et obtenir un emploi en tant que développeur, vous êtes au bon endroit. Ce livre vous montrera comment faire.

Et oui, c'est le livre complet – gratuitement – directement ici sur cette page de freeCodeCamp.

De plus, j'ai enregistré une version livre audio intégrale et GRATUITE de ce livre, que j'ai publiée en tant qu'épisode #100 du podcast freeCodeCamp. Vous pouvez le rechercher dans votre application de podcast préférée. N'oubliez pas de vous abonner. Je l'ai également intégré ci-dessous pour votre commodité.

Il y a quelques années, l'un des cinq plus grands éditeurs de livres de New York m'a contacté pour un contrat d'édition. Je les ai rencontrés, mais je n'avais pas le temps d'écrire un livre.

Eh bien, j'ai fini par trouver le temps. Et j'ai décidé de publier ce livre gratuitement, ici même sur freeCodeCamp.

L'information veut être libre, n'est-ce pas ? 🙂

Il vous faudra quelques heures pour lire tout cela. Mais c'est ici. Mes réflexions sur l'apprentissage du code et l'obtention d'un emploi de développeur.

J'ai appris tout cela en :

• apprenant à coder dans la trentaine
• travaillant ensuite comme ingénieur logiciel
• dirigeant freeCodeCamp.org au cours des 8 dernières années. Aujourd'hui, plus d'un million de personnes visitent ce site chaque jour pour apprendre les mathématiques, la programmation et l'informatique.

J'étais un professeur d'anglais qui n'avait jamais programmé auparavant. Et j'ai pu apprendre suffisamment le code pour obtenir mon premier emploi de développement logiciel en seulement un an.

Tout cela sans dépenser d'argent en livres ou en cours.

(J'ai dépensé de l'argent pour voyager dans les villes voisines et participer à des événements technologiques. Et comme vous le verrez plus loin dans le livre, c'était de l'argent bien investi.)

Après avoir travaillé comme ingénieur logiciel pendant quelques années, je me suis senti prêt. Je voulais enseigner à d'autres personnes comment effectuer cette transition de carrière également.

J'ai construit plusieurs outils d'éducation technologique que personne ne voulait utiliser. Mais un week-end, j'ai construit freeCodeCamp.org. Une communauté dynamique s'est rapidement formée autour.

En chemin, nous nous sommes tous entraidés. Et aujourd'hui, des gens du monde entier ont utilisé freeCodeCamp pour se préparer à leur premier emploi dans la tech.

Vous vous dites peut-être : je ne sais pas si j'ai le temps de lire ce livre en entier.

Pas de souci. Vous pouvez le mettre en favoris. Vous pouvez y revenir et le lire en autant de séances que nécessaire.

Et vous pouvez le partager sur les réseaux sociaux. Partager : "regardez ce livre que je lis" avec un lien est un moyen étonnamment efficace de se convaincre de finir la lecture d'un livre.

Je dis cela parce que je n'essaie pas de vous vendre ce livre. Vous l'avez déjà "acheté" en ouvrant cette page web. Maintenant, mon objectif est de vous rassurer sur le fait qu'investir votre temps pour finir de lire ce livre en vaudra la peine. 😉

Je promets de respecter votre temps. Il n'y a pas de battage publicitaire ou de remplissage ici – juste des conseils directs et exploitables.

Je vais condenser autant d'informations que possible dans chaque chapitre de ce livre.

Ce qui me rappelle : où est la table des matières ?

Ah. La voici :

Table des matières

1. Préface : À qui s'adresse ce livre ?
2. Résumé analytique en 500 mots
3. Chapitre 1 : Comment développer vos compétences
4. Chapitre 2 : Comment construire votre réseau
5. Chapitre 3 : Comment construire votre réputation
6. Chapitre 4 : Comment être payé pour coder – Clients freelance et recherche d'emploi
7. Chapitre 5 : Comment réussir votre premier emploi de développeur
8. Épilogue : Vous pouvez le faire

Préface : À qui s'adresse ce livre ?

Ce livre s'adresse à toute personne envisageant une carrière dans le développement logiciel.

Si vous recherchez une carrière flexible, bien rémunérée et impliquant beaucoup de résolution créative de problèmes, le développement logiciel est peut-être fait pour vous.

Bien sûr, chacun de nous aborde son propre parcours de codage avec certaines ressources : du temps, de l'argent et des opportunités.

Vous êtes peut-être plus âgé, et vous avez peut-être des enfants ou des parents âgés dont vous vous occupez. Vous avez donc peut-être moins de temps.

Ou vous êtes peut-être plus jeune, et vous avez eu moins de temps pour accumuler des économies ou acquérir des compétences qui augmentent vos revenus. Vous avez donc peut-être moins d'argent.

Et vous vivez peut-être loin des grandes villes technologiques comme San Francisco, Berlin, Tokyo ou Bengaluru.

Ou vous vivez peut-être avec des handicaps, physiques ou mentaux. L'âgisme, le racisme et le sexisme sont réels. Le statut d'immigration peut compliquer la recherche d'emploi. Un casier judiciaire aussi.

Vous avez donc peut-être moins d'opportunités.

Apprendre à coder et obtenir un emploi de développeur sera plus difficile pour certaines personnes que pour d'autres. Chacun aborde ce défi depuis son propre point de départ, avec les ressources dont il dispose.

Mais quel que soit votre point de départ – en termes de temps, d'argent et d'opportunités – je ferai de mon mieux pour vous donner des conseils concrets.

En d'autres termes : ne vous inquiétez pas – vous êtes au bon endroit.

Une note rapide sur la terminologie

Chaque fois que j'utiliserai de nouveaux termes, je ferai de mon mieux pour les définir.

Mais il y a quelques termes que j'utiliserai tout le temps.

J'utiliserai les mots "programmation" et "codage" de manière interchangeable.

J'utiliserai le mot "app" comme il a été conçu – comme abréviation pour tout type d'application, qu'elle fonctionne sur un téléphone, un ordinateur portable, une console de jeu ou un réfrigérateur. (Désolé, Steve Jobs. L'iPhone n'a pas le monopole du mot app.)

J'utiliserai également les termes "ingénieur logiciel" et "développeur logiciel" de manière interchangeable.

Vous rencontrerez peut-être des gens dans la tech qui s'en offusquent. Comme si le génie logiciel était un domaine prestigieux avec un héritage de plusieurs siècles, comme le génie mécanique ou le génie civil. Qui sait – ce sera peut-être vrai pour vos petits-enfants. Mais nous en sommes encore aux premiers jours du développement logiciel en tant que domaine.

Je vais juste laisser cette citation ici pour vous, au cas où vous vous sentiriez mal à l'aise de vous appeler ingénieur logiciel :

"Si les bâtisseurs construisaient des bâtiments de la même manière que les programmeurs écrivent des programmes, alors le premier pivert qui passerait par là détruirait la civilisation." – Gerald Weinberg, programmeur, auteur et professeur d'université

Tout le monde peut-il apprendre à coder ?

Oui. Je crois que toute personne suffisamment motivée peut apprendre à coder. En fin de compte, apprendre à coder est un défi de motivation – pas une question d'aptitude.

Dans les savanes d'Afrique – où les premiers humains ont vécu pendant des milliers d'années avant de se répandre en Europe, en Asie et dans les Amériques – y avait-il des ordinateurs ?

Les compétences en programmation n'ont jamais été quelque chose de sélectionné au fil des millénaires. Les ordinateurs tels que nous les connaissons (ordinateurs de bureau, portables, smartphones) sont apparus dans les années 80, 90 et 2000.

Oui – je crois que l'aptitude joue un rôle. Mais en fin de compte, quiconque veut devenir un développeur professionnel devra passer du temps au clavier.

Une grande majorité de personnes qui essaient d'apprendre à coder se découragent et abandonnent.

C'est ce que j'ai fait. Je me suis découragé et j'ai abandonné. Plusieurs fois.

Mais comme d'autres personnes qui ont fini par réussir, je revenais après quelques jours et j'essayais à nouveau.

Je dis tout cela parce que je veux reconnaître que : apprendre à coder et obtenir un emploi de développeur est difficile. Et c'est encore plus difficile pour certaines personnes que pour d'autres, en raison des circonstances.

Je ne vais pas prétendre avoir affronté une véritable adversité pour apprendre à coder. Oui, j'avais la trentaine, et je n'avais aucune formation formelle en programmation ou en informatique. Mais considérez ceci :

J'ai grandi dans la classe moyenne aux États-Unis – un Américain de 4ème génération issu d'un foyer anglophone. Je suis allé à l'université. Mon père est allé à l'université. Et son père est allé à l'université. (Ses parents avant lui étaient des fermiers suédois.)

J'ai bénéficié d'une sorte de privilège intergénérationnel. Un élan que certaines familles parviennent à acquérir au fil du temps lorsqu'elles ne sont pas déchirées par la guerre, la famine ou l'esclavage.

C'est donc ma mise en garde géante : je ne suis pas une figure de motivation pour vous gonfler à bloc afin de surmonter l'adversité.

Si vous avez besoin d'inspiration, il y a énormément de personnes dans la communauté des développeurs qui ont surmonté de réelles épreuves. Vous pouvez les rechercher.

Je n'essaie pas d'élever le domaine du développement logiciel. Je ne vais pas peindre des utopies de science-fiction qui pourraient voir le jour si tout le monde apprenait à coder.

Au lieu de cela, je vais juste vous donner des conseils pratiques sur la façon dont vous pouvez acquérir ces compétences. Et comment vous pouvez obtenir un bon emploi, afin de subvenir aux besoins de votre famille.

Il n'y a rien de mal à apprendre à coder parce que vous voulez un bon emploi stable.

Il n'y a rien de mal à apprendre à coder pour pouvoir créer une entreprise.

Vous rencontrerez peut-être des gens qui diront que vous devez être tellement passionné par le code que vous en rêvez. Que vous quittez votre emploi à plein temps pour passer tout votre week-end à contribuer à des projets open source.

Je connais des gens qui sont si passionnés par le code. Mais je connais aussi beaucoup de gens qui, après avoir terminé une dure semaine de travail, veulent juste passer du temps dans la nature ou jouer à des jeux de société avec des amis.

Les gens aiment généralement faire des choses pour lesquelles ils sont doués. Et vous pouvez développer un niveau raisonnable de passion pour le code simplement en devenant meilleur en codage.

En résumé : à qui s'adresse ce livre ? À tous ceux qui veulent s'améliorer en codage et obtenir un emploi de développeur. C'est tout.

Vous n'avez pas besoin d'être un "geek" autoproclamé, un introverti ou un activiste idéologique. Ou n'importe lequel de ces stéréotypes.

C'est très bien si vous l'êtes. Mais vous n'avez pas besoin de l'être.

Donc si c'est votre cas – si vous voulez sérieusement apprendre à coder suffisamment bien pour être payé pour le faire – ce livre est pour vous.

Et vous devriez commencer par lire ce résumé rapide du livre. Puis lire le reste.

Résumé analytique en 500 mots

Apprendre à coder est difficile. Obtenir un emploi de développeur logiciel est encore plus difficile. Mais pour beaucoup de gens, cela en vaut la peine.

Le codage est un domaine bien rémunéré, intellectuellement stimulant et créativement gratifiant. Une progression de carrière claire s'offre à vous : développeur senior, tech lead, engineering manager, CTO, et peut-être même CEO.

Vous pouvez trouver du travail dans presque tous les secteurs. Environ deux tiers des emplois de développeurs se trouvent en dehors de ce que nous appelons traditionnellement la "tech" – dans l'agriculture, l'industrie, le gouvernement et les services comme la banque et la santé.

Si vous craignez que votre emploi ne soit automatisé avant votre retraite, considérez ceci : coder est l'acte d'automatiser les choses. C'est donc par définition la dernière carrière qui sera complètement automatisée.

L'automatisation aura un impact sur le codage. C'est déjà le cas. Depuis des décennies.

Les outils d'IA générative comme GPT-4 et Copilot peuvent nous aider à passer de la programmation impérative – où vous dites aux ordinateurs exactement quoi faire – à la programmation déclarative – où vous donnez aux ordinateurs des objectifs de plus haut niveau. En d'autres termes : une programmation à la Star Trek.

Vous devriez toujours apprendre les mathématiques même si nous avons maintenant des calculatrices. Et vous devriez toujours apprendre la programmation même si nous avons maintenant des outils d'IA capables d'écrire du code.

Vous ai-je convaincu que le codage est une carrière pour vous ?

Bien. Voici comment percer dans le domaine.

Développez vos compétences.

Vous devez apprendre :

• Développement Front-End : HTML, CSS, JavaScript
• Développement Back-End : SQL, Git, Linux et serveurs Web
• Calcul scientifique : Python et ses nombreuses bibliothèques

Ce sont toutes des technologies matures, vieilles de plus de 20 ans. Quelle que soit l'entreprise pour laquelle vous travaillerez, vous utiliserez presque certainement la plupart de ces outils.

La meilleure façon d'apprendre ces outils est de construire des projets. Essayez de coder au moins un peu chaque jour. Si vous suivez le curriculum de freeCodeCamp de haut en bas, vous apprendrez tout cela et construirez des dizaines de projets.

Certaines des certifications du curriculum de base de freeCodeCamp.

Construisez votre réseau.

Une grande partie de l'obtention d'un emploi dépend de qui vous connaissez.

Il n'y a pas de mal à être introverti, mais vous devez repousser vos limites.

Créez des comptes GitHub, Twitter, LinkedIn et Discord.

Allez à des meetups et des conférences tech. Voyagez si nécessaire. (La majeure partie de votre budget "apprendre à coder" devrait aller aux voyages et aux billets d'événements – pas aux livres et aux cours.)

Saluez les gens qui sont seuls. Laissez les autres parler le plus possible et écoutez vraiment. Retenez les noms des gens.

Ajoutez des personnes sur LinkedIn, suivez-les sur Twitter et allez aux after-parties.

Construisez votre réputation.

Partagez de courtes démos vidéo de vos projets.

Continuez à postuler pour parler dans des conférences de plus en plus importantes.

Fréquentez les hackerspaces et aidez les personnes encore plus novices que vous.

Contribuez à l'open source. Le travail est similaire au développement logiciel professionnel.

Développez vos compétences, votre réseau et votre réputation en même temps. Ne vous laissez pas procrastiner sur les parties les plus effrayantes.

Au lieu de postuler à des emplois par la "porte d'entrée", utilisez votre réseau pour décrocher des entretiens par la "porte latérale". Les recruteurs peuvent aussi vous aider.

Continuez à passer des entretiens jusqu'à ce que vous commenciez à recevoir des offres d'emploi. Vous n'êtes pas obligé d'accepter la première offre que vous recevez. Soyez patient.

Votre premier emploi de développeur sera le plus difficile. Essayez d'y rester au moins 2 ans, et soyez essentiellement payé pour apprendre.

Le véritable apprentissage commence une fois que vous êtes en poste, travaillant au sein d'une équipe et sur de grandes bases de code legacy.

Plus important encore, dormez et faites de l'exercice.

Toute personne suffisamment motivée peut apprendre à coder assez bien pour obtenir un emploi de développeur.

C'est juste une question de savoir à quel point vous le voulez et à quel point vous pouvez être persévérant dans la recherche d'emploi.

Rappelez-vous : vous pouvez le faire.

Ce livre est dédié à la communauté mondiale de freeCodeCamp.

Merci à vous tous qui avez soutenu notre organisation caritative et notre mission au cours des 9 dernières années.

C'est grâce à votre bénévolat et à votre philanthropie que nous avons pu aider tant de personnes à apprendre à coder et à obtenir leur premier emploi de développeur.

La communauté a tellement grandi depuis l'humble projet open source que j'ai déployé pour la première fois en 2014. Je ne suis plus qu'une petite partie de cette communauté mondiale.

C'est un privilège d'être encore ici, travaillant à vos côtés. Ensemble, nous affrontons les problèmes fondamentaux de notre époque. L'accès à l'information. L'accès à l'éducation. Et l'accès aux outils qui façonnent l'avenir.

Ce ne sont encore que les débuts. Je ne me fais aucune illusion sur le fait que tout le monde saura coder de mon vivant. Mais tout comme la Bible de Gutenberg a accéléré l'alphabétisation en 1455, nous pouvons continuer à accélérer la littératie technologique grâce à des ressources d'apprentissage gratuites et ouvertes.

Encore une fois, merci à tous.

Et un merci spécial à Abbey Rennemeyer pour ses retours éditoriaux, et à Estefania Cassingena Navone pour la conception de la couverture du livre.

Et maintenant, le livre.

Chapitre 1 : Comment développer vos compétences

"Chaque artiste a d'abord été un amateur." ― Ralph Waldo Emerson

La route pour savoir coder est longue.

Pour moi, elle a été ambiguë.

Mais elle n'a pas à l'être pour vous.

Dans ce chapitre, je vais partager quelques stratégies pour apprendre à coder le plus sereinement possible.

D'abord, permettez-moi de vous raconter comment j'ai appris à coder en 2011.

Ensuite, je partagerai ce que j'ai appris de ce processus.

Je vous montrerai comment apprendre beaucoup plus efficacement que je ne l'ai fait.

L'heure de l'histoire : comment un enseignant dans la trentaine a-t-il appris seul à coder ?

J'étais un enseignant dirigeant une école d'anglais. Nous avions environ 100 étudiants adultes venus du monde entier en Californie. Ils apprenaient l'anglais avancé pour pouvoir entrer en master ou doctorat.

La plupart des enseignants de notre école adoraient enseigner. Ils aimaient passer du temps avec les étudiants en ville et les aider à améliorer leur anglais conversationnel.

Ce que ces enseignants n'aimaient pas, c'était la paperasse : rapports de présence, rapports de notes, documents d'immigration.

Je voulais que nos enseignants puissent passer plus de temps avec les étudiants, et moins de temps enchaînés à leurs bureaux à faire de la paperasse.

Mais qu'est-ce que je connaissais aux ordinateurs ?

La programmation ? Ne fallait-il pas être intelligent pour faire ça ? Je savais à peine configurer un routeur WiFi. Et j'étais nul en maths.

Eh bien, un jour, j'ai mis tout cela de côté et je me suis dit : "Tu sais quoi : je vais essayer. Qu'est-ce que j'ai à perdre ?"

J'ai commencé à chercher sur Google des questions comme "comment cliquer automatiquement sur des sites web" et "comment importer des données de sites web dans Excel".

Je ne m'en rendais pas compte à l'époque, mais j'apprenais à automatiser des flux de travail.

Et l'apprentissage a commencé. D'abord avec les macros Excel. Puis avec un outil appelé AutoHotKey où vous pouvez programmer votre souris pour qu'elle se déplace vers certaines coordonnées de l'écran, clique, copie du texte, puis se déplace vers d'autres coordonnées et le colle.

Après quelques semaines à tâtonner dans le noir, j'ai compris comment automatiser quelques tâches. Je pouvais ouvrir une feuille de calcul Excel et un site web, lancer mon script, puis revenir 10 minutes plus tard et la feuille de calcul était entièrement remplie.

C'était un travail d'amateur. Ce que les développeurs pourraient appeler un "dirty hack". Mais cela faisait le job.

J'ai utilisé mes nouvelles compétences en automatisation pour continuer à rationaliser l'école.

Bientôt, les enseignants n'avaient presque plus besoin de toucher à un ordinateur. Je faisais le travail de plusieurs enseignants, juste avec mes compétences rudimentaires.

Cela a eu un impact visible sur l'école. Une grande partie de notre temps avait été accaparée par un travail répétitif sur l'ordinateur. Et maintenant, nous étions libres.

Les enseignants étaient plus heureux. Ils passaient plus de temps avec les étudiants.

Les étudiants étaient plus heureux. Ils disaient à tous leurs amis dans leur pays d'origine : "vous devez aller voir cette école".

Bientôt, nous étions l'une des écoles les plus prospères de tout le système scolaire.

Cela m'a encore plus enhardi. Je me souviens m'être dit : "Peut-être que je peux apprendre à coder."

Je connaissais quelques ingénieurs logiciels grâce à mes soirées jeux de société. Ils avaient des parcours traditionnels, avec des diplômes de Cal Tech, Harvey Mudd et d'autres programmes célèbres en informatique.

À l'époque, il était beaucoup moins courant pour des personnes dans la trentaine d'apprendre à coder.

J'ai pris mon courage à deux mains pour partager mes rêves avec certains de ces amis.

Je voulais apprendre à programmer correctement. Je voulais pouvoir écrire du code pour gagner ma vie comme ils le faisaient. Et peut-être même écrire des logiciels capables de faire fonctionner des écoles.

Je partageais ces rêves avec mes amis développeurs. "Je veux faire ce que vous faites."

Mais ils haussaient les épaules. Puis ils disaient quelque chose comme :

"Je veux dire, tu pourrais essayer. Mais tu vas devoir boire un océan entier de connaissances."

Et : "C'est un domaine assez compétitif. Comment vas-tu rivaliser avec des gens qui ont grandi en codant depuis leur plus jeune âge ?"

Et : "Tu t'en sors déjà bien en tant qu'enseignant. Pourquoi ne pas t'en tenir à ce pour quoi tu es doué ?"

Et cela me faisait dévier de ma trajectoire pendant quelques semaines. Je faisais de longues promenades nocturnes introspectives. Je méditais sur mon avenir sous les étoiles. Ces gens avaient-ils raison ? Je veux dire – ils devaient savoir, non ?

Mais chaque matin, j'étais de retour à mon bureau. Regardant mes scripts s'exécuter. Regardant mes rapports se compiler à des vitesses surhumaines. Regardant mon ordinateur obéir à mes ordres.

Une pensée m'est venue : peut-être que ces amis essayaient juste de m'épargner des déceptions. Peut-être qu'ils ne connaissent personne qui a appris à coder dans la trentaine. Ils pensent donc que ce n'est pas possible.

C'est comme... pendant des années, les médecins pensaient qu'il serait impossible pour quelqu'un de courir un mile en 4 minutes. Ils pensaient que votre cœur exploserait en courant si vite.

Mais quelqu'un a fini par y arriver. Et son cœur n'a pas explosé.

Une fois que Roger Bannister – un étudiant d'Oxford de 25 ans – a brisé cette barrière psychologique – une foule d'autres personnes l'ont fait aussi. À ce jour, plus de 1 000 personnes ont couru un mile en moins de 4 minutes.

Roger Bannister courant comme un champion. (Image : Britannica)

Et ce n'est pas comme si je faisais quelque chose d'aussi audacieux et sans précédent que de courir un mile en 4 minutes. De nombreux développeurs célèbres ont réussi à apprendre le code par eux-mêmes au fil des ans.

Diable, Ada Lovelace a appris seule la programmation dans les années 1840. Et elle n'avait même pas d'ordinateur fonctionnel. Elle comprenait simplement comment l'ordinateur de son ami Charles Babbage fonctionnerait en théorie.

Elle a écrit plusieurs des premiers algorithmes informatiques. Et elle est largement considérée comme la première programmeuse informatique au monde. Personne ne lui a appris. Parce qu'il n'y avait personne pour lui apprendre. Quel que soit le doute qu'elle ait pu avoir, elle l'a clairement surmonté.

Maintenant, je n'étais pas Ada Lovelace. J'étais juste un enseignant qui avait déjà un ordinateur fonctionnel, une connexion internet décente et la capacité de chercher parmi des milliards de pages web avec Google.

Je me suis fait craquer les articulations et j'ai plissé les yeux. J'allais le faire.

Coincé dans l'enfer des tutoriels

"Si vous travaillez pendant 10 ans, obtenez-vous 10 ans d'expérience ou obtenez-vous 1 an d'expérience 10 fois ? Vous devez réfléchir à vos activités pour acquérir une véritable expérience. Si vous faites de l'apprentissage un engagement continu, vous acquerrez de l'expérience. Si vous ne le faites pas, vous n'en aurez pas, quel que soit le nombre d'années à votre actif." – Steve McConnell, ingénieur logiciel

J'ai passé les semaines suivantes à chercher sur Google et à faire des tutoriels au hasard que je trouvais en ligne.

Oh tiens, un tutoriel Ruby.

Oh-oh, ça commence à devenir difficile. J'ai des messages d'erreur non mentionnés dans le tutoriel. Hm... qu'est-ce qui se passe ici...

Oh tiens, un tutoriel Python.

La psychologie humaine est une chose curieuse. Dès que quelque chose commence à devenir difficile, nous nous demandons : est-ce que je fais ça correctement ?

Peut-être que ce tutoriel n'est plus à jour. Peut-être que son auteur ne savait pas de quoi il parlait. Est-ce que quelqu'un utilise encore ce langage de programmation ?

Lorsque vous faites face à des messages d'erreur ambigus après des heures de codage, l'herbe commence à paraître beaucoup plus verte ailleurs.

Il était facile de prétendre que j'avais progressé. C'est l'heure d'aller déjeuner.

Je voyais un ami au café. "Comment ça se passe ton apprentissage du code ?" demandait-il.

"Ça se passe super bien. J'ai déjà codé 4 heures aujourd'hui."

"Génial. J'aimerais voir ce que tu construis un de ces jours."

"Bien sûr," disais-je, sachant que je n'avais rien construit. "Bientôt."

Peut-être que j'irais à la bibliothèque et que j'emprunterais un nouveau livre sur JavaScript.

Il y a ce vieux dicton qui dit qu'acheter des livres vous donne le meilleur sentiment au monde. Parce que vous avez aussi l'impression d'acheter le temps de les lire.

Et c'est précisément là que je me suis retrouvé quelques semaines après avoir commencé à apprendre à coder.

J'avais lu les 100 premières pages de plusieurs livres de programmation, mais je n'en avais fini aucun.

J'avais écrit les 100 premières lignes de code de plusieurs tutoriels de programmation, mais je n'en avais fini aucun.

Je ne le savais pas, mais j'étais piégé dans ce que les développeurs appellent affectueusement "l'enfer des tutoriels" (tutorial hell).

L'enfer des tutoriels, c'est quand vous passez d'un tutoriel à l'autre, apprenant puis réapprenant les mêmes bases. Mais sans jamais vraiment aller au-delà des fondamentaux.

Parce qu'aller au-delà des fondamentaux ? Eh bien, cela demande un vrai travail.

Il faut tout un village pour élever un codeur

Apprendre à coder absorbait tout mon temps libre. Mais je ne faisais pas beaucoup de progrès. Je pouvais maintenant taper les caractères { et * sans regarder le clavier. Mais c'était à peu près tout.

Je savais que j'avais besoin d'aide. Peut-être un mentor à la Yoda, qui pourrait m'enseigner la voie. Oui – si une telle personne existait, cela ferait sûrement toute la différence.

J'ai entendu parler d'un endroit à proximité appelé un "hackerspace". La première fois que j'ai entendu le nom, j'étais un peu inquiet. Les hackers ne font-ils pas des choses illégales ? J'étais un professeur d'anglais qui aimait les jeux de société. Je ne cherchais pas les ennuis.

Eh bien, j'ai appelé le numéro indiqué et j'ai parlé avec un gars nommé Steve. J'ai demandé nerveusement : "Vous ne faites rien d'illégal, n'est-ce pas ?" Et Steve a ri.

Il s'avère que le mot "hack" est ce qu'il appelait un terme surchargé. Oui – "hacker" peut signifier s'introduire malicieusement dans un système logiciel. Mais "hacker" peut aussi signifier quelque chose de plus banal : écrire du code informatique.

Quelque chose peut être "hacky", ce qui signifie que ce n'est pas une solution élégante. Et pourtant, vous pouvez avoir "un hack astucieux" – un truc ingénieux pour faire fonctionner votre code plus efficacement.

En résumé : n'ayez pas peur du terme "hack".

Le campus de Facebook a le mot "hack" écrit en lettres géantes sur le béton. (Image : Bloomberg)

Pour ma part, j'utilise rarement le terme parce qu'il est très déroutant. Et je pense que récemment, beaucoup de hackerspaces ont pris conscience de cette ambiguïté. Beaucoup d'entre eux s'appellent désormais des "makerspaces" à la place.

Parce que c'est ça, un hackerspace : fabriquer des choses.

Steve m'a invité à visiter le hackerspace le samedi après-midi. Il a dit que plusieurs développeurs de la région seraient là.

La première fois que j'ai franchi les portes du Santa Barbara Hackerspace, j'ai été époustouflé.

L'endroit sentait le feu électrique. Ses tables de fortune étaient garnies de fers à souder, de bandes de lumières LED, de cartes de circuits Arduino pour amateurs et de piles de robots aspirateurs Roomba.

Le même Steve à qui j'avais parlé au téléphone était là, et il m'a accueilli. Il avait des lunettes, les cheveux gominés en arrière et un bouc. Il souriait toujours. Et quand on lui posait une question, au lieu de répondre rapidement, il hochait la tête et réfléchissait pendant quelques secondes d'abord.

Steve était un programmeur passionné qui avait étudié les mathématiques et la philosophie à l'Université de Californie – Santa Barbara. Il était toujours passionné par ces sujets. Mais sa véritable passion était Python.

Steve a allumé le projecteur et a donné un "lightning talk" informel. Il faisait la démonstration d'une application qu'il avait écrite et qui reconnaissait les codes QR dans une vidéo pour les remplacer par des images.

Quelqu'un dans l'assistance a affiché un code QR sur son ordinateur portable et l'a tenu devant la caméra. L'application de Steve a alors remplacé le code QR par une image de pizza.

Quelqu'un dans le public a crié : "Peux-tu faire tourner la pizza ?"

Steve a ouvert son code dans un éditeur de texte, appelé Emacs, et a commencé à y apporter des modifications en temps réel. Il passait sans effort de son éditeur de code à sa ligne de commande et au navigateur dans lequel l'application s'exécutait, effectuant des mises à jour du code en "hot loading".

Pour moi, c'était de la sorcellerie. Je ne pouvais pas croire que Steve avait pondu cette application en quelques heures. Et maintenant, il ajoutait de nouvelles fonctionnalités à la volée, à la demande du public.

Je me suis dit : "Ce gars est un génie."

Et ce soir-là, après la fin de l'événement, nous sommes restés et je le lui ai dit.

Nous avons mangé des sandwichs ensemble. Et je lui ai dit : "Je pourrais coder pendant toute ma carrière et ne pas être aussi bon que toi. Je serais ravi si après 10 ans je pouvais coder ne serait-ce qu'à moitié aussi bien que toi."

Mais Steve a protesté. Il a dit : "Je n'ai rien de spécial. Ne te limite pas. Si tu persévères dans le code, tu pourrais facilement me dépasser."

Maintenant, je ne croyais pas une seconde à ce qu'il me disait. Mais le simple fait qu'il le dise m'a donné des papillons dans le ventre.

Le voilà : un développeur qui croyait en moi. Il me voyait – un enseignant quelconque – la définition même d'un "script kiddie" – et pensait que je pouvais y arriver.

Steve et moi avons discuté tard dans la nuit. Il m'a montré son netbook à 200 $, qui, même selon les standards de 2011, était cruellement sous-dimensionné.

"Tu n'as pas besoin d'un ordinateur puissant pour construire des logiciels," m'a dit Steve. "Le matériel d'aujourd'hui est incroyablement puissant. Les ordinateurs ne sont lents que parce que les logiciels lourds qu'ils font tourner les ralentissent. Prends un ordinateur portable standard, efface le disque dur, installe Linux dessus et commence à coder."

J'ai noté le modèle d'ordinateur portable qu'il avait et j'ai commandé exactement le même en rentrant chez moi ce soir-là.

Après quelques jours à déboguer mon nouvel ordinateur avec Stack Overflow, j'ai réussi à installer Ubuntu. J'ai commencé à apprendre à utiliser l'éditeur de code Emacs. Le samedi suivant, je connaissais quelques commandes et j'étais impatient de les montrer.

Steve a hoché la tête en signe d'approbation. Il a dit : "Génial. Mais qu'est-ce que tu construis ?"

Je n'ai pas compris ce qu'il voulait dire. "J'apprends à utiliser Emacs. Regarde. J'ai mémorisé..."

Mais Steve semblait pensif. "C'est bien tout ça. Mais tu as besoin d'un projet. Aie toujours un projet. Ensuite, apprends ce que tu as besoin d'apprendre pour terminer ce projet."

À part quelques scripts que j'avais écrits pour aider les enseignants de mon école, je n'avais jamais rien terminé. Mais j'ai commencé à voir ce qu'il voulait dire.

Et j'ai commencé à comprendre. Tout ce temps, j'avais été piégé dans l'enfer des tutoriels, tournant en rond, ne finissant rien.

Steve a dit : "Je veux que tu construises un projet en utilisant HTML5. Et samedi prochain, je veux que tu le présentes au hackerspace."

J'étais terrifié par ses paroles. Mais je me suis redressé et j'ai dit : "Ça marche. Je m'en occupe."

Personne ne peut faire de vous un développeur à part vous-même

"J'essaie de libérer ton esprit, Neo. Mais je ne peux que te montrer la porte. C'est toi qui dois la franchir." – Morpheus dans le film Matrix (1999)

Le lendemain matin, je me suis réveillé très tôt avant le travail et j'ai cherché quelque chose comme "tutoriel HTML5". Je connaissais déjà une grande partie de tout cela grâce à mon passage dans l'enfer des tutoriels. Mais au lieu de sauter des étapes, j'ai juste ralenti et j'ai suivi exactement, en tapant chaque commande.

D'habitude, une fois que j'avais fini un tutoriel, j'allais juste en chercher un autre. Mais au lieu de cela, j'ai commencé à jouer avec le code du tutoriel. J'avais une idée simple pour un projet. J'allais faire une page de documentation HTML5. Et j'allais la coder purement en HTML5.

Laissez-moi vous expliquer rapidement le HTML5. C'est juste une version plus récente du HTML, qui existe depuis les premières pages web dans les années 1990.

Si un site web était un corps, le HTML serait les os. Tout le reste repose sur ces os. (Vous pouvez considérer le JavaScript comme les muscles et le CSS comme la peau. Mais revenons à l'histoire.)

Je savais qu'en HTML, on pouvait créer des liens vers différentes parties de la même page web en utilisant des propriétés ID. Alors j'ai pensé : et si je mettais une table des matières sur le côté gauche ? Ensuite, cliquer sur les différents éléments à gauche ferait défiler la page à droite pour afficher ces éléments.

En une demi-heure, j'avais codé un prototype rudimentaire.

Mais il était temps d'aller travailler à l'école. Toute la journée, je n'ai pensé qu'à mon projet et à la meilleure façon de le terminer.

Je suis rentré en courant, j'ai ouvert mon ordinateur et j'ai passé toute la soirée à coder.

J'ai copié la documentation HTML officielle (sous licence Creative Commons) directement dans ma page, en l'écrivant "en dur" dans le HTML.

Ensuite, j'ai passé environ une heure sur le CSS, pour que tout soit correct, et j'ai utilisé le positionnement absolu pour maintenir la barre latérale en place.

Je me suis fait un point d'honneur d'utiliser autant de nouvelles balises "sémantiques" du HTML5 que possible.

Et boum – projet terminé.

Une vague d'accomplissement m'a envahi. J'ai couru jusqu'à un terrain de football voisin et j'ai fait des tours de piste pour fêter ça. Je l'avais fait. J'avais terminé un projet.

Et j'ai décidé là, sur le champ : à partir de maintenant, tout ce que je ferai sera un projet. Je travaillerai toujours vers un produit fini.

Le lendemain soir, je suis monté sur le podium, j'ai branché mon ordinateur et j'ai présenté ma page web HTML5. J'ai répondu aux questions des développeurs présents sur le HTML5.

Parfois, je me trompais, et quelqu'un dans le public disait : "ça ne semble pas correct – laisse-moi vérifier la documentation."

Les gens n'avaient pas peur de me corriger. Mais ils étaient polis et encourageants. Je n'avais même pas l'impression qu'ils me corrigeaient – j'avais l'impression qu'ils corrigeaient le registre public – de peur que quelqu'un ne reparte avec des informations incorrectes.

Je n'ai ressenti aucune de l'anxiété que j'aurais pu ressentir en donnant une conférence lors d'une réunion d'enseignants.

Au contraire, j'avais presque l'impression de faire partie du public, apprenant à leurs côtés.

Après tout, ces outils étaient nouveaux et émergents. Nous essayions tous de comprendre comment les utiliser ensemble.

Après ma présentation, Steve est venu me voir et a dit : "Pas mal."

J'ai souri pendant un temps maladroitement long, sans rien dire, juste content de moi.

Puis Steve a plissé les yeux et a pincé les lèvres. Il a dit : "Commence ton prochain projet ce soir."

Leçons de mon parcours de codage

Nous prendrons des nouvelles du parcours de codage du jeune Quincy dans chacun des chapitres suivants. Mais maintenant, je veux analyser certaines des leçons ici. Et je veux répondre à certaines des questions que vous pourriez vous poser.

Pourquoi apprendre à coder est-il si difficile ?

Apprendre n'importe quelle nouvelle compétence est difficile. Qu'il s'agisse de dribbler avec un ballon de football, de changer l'huile d'une voiture ou de parler une nouvelle langue.

Apprendre à coder est difficile pour quelques raisons particulières. Et certaines d'entre elles sont uniques au codage.

La première est que la plupart des gens ne comprennent pas exactement ce qu'est le codage. Eh bien, je vais vous le dire.

Qu'est-ce que le codage ?

Coder, c'est dire à un ordinateur quoi faire, d'une manière que l'ordinateur puisse comprendre.

C'est tout. C'est tout ce qu'est réellement le codage.

Maintenant, ne vous y trompez pas. Communiquer avec les ordinateurs est difficile. Ils sont "bêtes" selon les standards humains. Ils feront exactement ce que vous leur dites de faire. Mais à moins d'être bon en codage, ils ne feront probablement pas ce que vous voulez qu'ils fassent.

Vous vous demandez peut-être : et les serveurs ? Et les bases de données ? Et les réseaux ?

En fin de compte, tout cela est contrôlé par des couches de logiciels. Du code. C'est du code jusqu'au bout. Finalement, vous atteignez le matériel physique, qui déplace des électrons sur des circuits imprimés.

Pendant les premières décennies de l'informatique, les développeurs écrivaient du code "proche du métal" – opérant souvent directement sur le matériel, faisant passer des bits de 0 à 1 et inversement.

Mais le développement logiciel contemporain implique tellement de "couches d'abstraction" – des programmes fonctionnant par-dessus d'autres programmes – que quelques lignes de code JavaScript peuvent faire des choses vraiment puissantes.

Dans les années 1960, un "bug" pouvait être un insecte rampant à l'intérieur d'un ordinateur de la taille d'une pièce, et finissant grillé dans l'un des circuits.

Le premier bug informatique, découvert en 1945, était un papillon de nuit qui s'était retrouvé coincé dans les panneaux d'un ordinateur de calcul de la taille d'une pièce à Harvard. (Image : Domaine Public)

Aujourd'hui, nous écrivons du code à de nombreuses couches d'abstraction au-dessus du matériel physique.

C'est ça, le codage. C'est infiniment plus facile que cela ne l'a jamais été par le passé. Et cela devient plus facile chaque année.

Je n'exagère pas quand je dis que dans quelques décennies, coder sera si facile et si courant que la plupart des jeunes sauront le faire.

Pourquoi apprendre à coder est-il encore si difficile après toutes ces années ?

Il y a trois grandes raisons pour lesquelles apprendre à coder est si difficile, même aujourd'hui :

1. Les outils sont encore primitifs.
2. La plupart des gens ne sont pas doués pour gérer l'ambiguïté, et apprendre à coder est ambigu. Les gens se perdent.
3. La plupart des gens ne sont pas doués pour gérer les retours négatifs constants. Et apprendre à coder est une succession brutale de messages d'erreur. Les gens se découragent.

Je vais maintenant discuter de chacune de ces difficultés plus en détail. Et je vous donnerai des stratégies pratiques pour surmonter chacune d'elles.

Les outils sont encore primitifs

Un Barclay possédé de Star Trek: The Next Generation, programmant sur le Holodeck.

"Ordinateur. Commencer nouveau programme. Créer comme suit. Chaise de poste de travail. Maintenant, créer une console alphanumérique standard positionnée à la main gauche. Maintenant, une console d'affichage iconique pour la main droite. Relier les deux consoles au cœur de l'ordinateur principal de l'Enterprise, en utilisant l'interface de scan neuronal." - Barclay dans Star Trek: The Next Generation, Saison 4 Épisode 19 : "The Nth Degree"

C'est ainsi que les gens pourraient programmer à l'avenir. C'est un exemple tiré de ma série de science-fiction préférée, Star Trek: The Next Generation.

Chaque personnage dans Star Trek sait coder. Les médecins, les officiers de sécurité, les pilotes. Même le petit Wesley Crusher (joué par l'enfant acteur Wil Wheaton) peut amener l'ordinateur du vaisseau à obéir à ses ordres.

Bien sûr – l'une des raisons pour lesquelles tout le monde sait coder est qu'ils vivent dans une société du 24ème siècle post-pénurie, avec accès à une éducation gratuite de haute qualité.

Une autre raison est que dans le futur, coder sera beaucoup, beaucoup plus facile. Il suffira de dire à un ordinateur précisément quoi faire, et – si vous êtes assez précis – l'ordinateur le fera.

Et si programmer était aussi facile que de donner des instructions à un ordinateur en langage clair ?

Eh bien, nous avons déjà fait des progrès significatifs vers cet objectif. Pensez à nos grands-mères, courant entre des ordinateurs centraux de la taille d'une pièce avec des piles de cartes perforées.

Travailler avec un ordinateur à cartes perforées dans les années 1950 (Image : NASA)

Il fut un temps où programmer même une application simple nécessitait des instructions méticuleuses.

Voici deux exemples d'un "Chiffre de César", le projet classique de devoir en informatique.

C'est aussi connu sous le nom de "ROT-13" parce que vous faites pivoter (ROTate) les lettres de 13 positions. Par exemple, A devient N (13 lettres après A), et B devient O (13 lettres après B).

Je vais vous montrer deux exemples de ce programme.

D'abord, voici le programme en assembleur x86 :

format     ELF     executable 3
entry     start

segment    readable writeable
buf    rb    1

segment    readable executable
start:    mov    eax, 3        ; syscall "read"
    mov    ebx, 0        ; stdin
    mov    ecx, buf    ; buffer for read byte
    mov    edx, 1        ; len (read one byte)
    int    80h

    cmp    eax, 0        ; EOF?
    jz    exit

    xor     eax, eax    ; load read char to eax
    mov    al, [buf]
    cmp    eax, "A"    ; see if it is in ascii a-z or A-Z
    jl    print
    cmp    eax, "z"
    jg    print
    cmp    eax, "Z"
    jle    rotup
    cmp    eax, "a"
    jge    rotlow
    jmp    print

rotup:    sub    eax, "A"-13    ; do rot 13 for A-Z
    cdq
    mov    ebx, 26
    div    ebx
    add    edx, "A"
    jmp    rotend

rotlow:    sub    eax, "a"-13    ; do rot 13 for a-z
    cdq
    mov    ebx, 26
    div    ebx
    add    edx, "a"

rotend:    mov    [buf], dl

print:     mov    eax, 4        ; syscall write
    mov    ebx, 1        ; stdout
    mov    ecx, buf    ; *char
    mov    edx, 1        ; string length
    int    80h

    jmp    start

exit:     mov     eax,1        ; syscall exit
    xor     ebx,ebx        ; exit code
    int     80h

Cet exemple en assembleur x86 provient du projet Rosetta Code sous licence Creative Commons.

Et voici le même programme, écrit en Python :

def rot13(text):
    result = []

    for char in text:
        ascii_value = ord(char)

        if 'A' <= char <= 'Z':
            result.append(chr((ascii_value - ord('A') + 13) % 26 + ord('A')))
        elif 'a' <= char <= 'z':
            result.append(chr((ascii_value - ord('a') + 13) % 26 + ord('a')))
        else:
            result.append(char)

    return ''.join(result)

if __name__ == "__main__":
    input_text = input("Enter text to be encoded/decoded with ROT-13: ")
    print("Encoded/Decoded text:", rot13(input_text))

C'est quand même un peu plus simple et plus facile à lire, non ?

Cet exemple en Python vient directement de GPT-4. Je l'ai sollicité de la même manière que le Capitaine Picard solliciterait l'ordinateur du vaisseau dans Star Trek.

Voici exactement ce que je lui ai dit : "Ordinateur. Nouveau programme. Prends chaque lettre du mot que je dis et remplace-la par la lettre qui apparaît 13 positions plus tard dans l'alphabet anglais. Puis lis-moi le résultat. Le mot est Banana."

GPT-4 a produit ce code Python, puis m'a lu le résultat : "Onanan."

Ce que nous faisons ici s'appelle de la programmation déclarative. Nous déclarons "ordinateur, tu devrais faire ceci". Et l'ordinateur est assez intelligent pour comprendre nos instructions et les exécuter.

Aujourd'hui, le style de codage que la plupart des développeurs utilisent est la programmation impérative. Nous disons à l'ordinateur exactement quoi faire, étape par étape. Parce qu'historiquement, les ordinateurs ont été assez bêtes. Nous avons donc dû les aider à mettre un pied devant l'autre.

Le domaine du développement logiciel n'est tout simplement pas encore mature.

Mais tout comme les premiers outils humains ont progressé – de la pierre au bronze puis au fer – il en va de même pour les outils logiciels. Et beaucoup plus vite.

Nous sommes probablement encore dans l'équivalent de l'âge du bronze de la programmation en ce moment. Mais nous pourrions atteindre l'âge du fer de notre vivant. Les outils d'IA générative comme GPT deviennent rapidement plus puissants et plus fiables.

La communauté des développeurs est encore divisée sur l'utilité d'outils comme GPT pour le développement logiciel.

D'un côté, vous avez les influenceurs entrepreneurs "devenez votre propre patron" qui disent des choses comme : "Vous n'avez plus besoin d'apprendre à coder. ChatGPT peut écrire tout votre code pour vous. Vous avez juste besoin d'une idée d'application."

Et à l'autre extrémité du spectre, vous avez les développeurs de la "vieille garde" avec des décennies d'expérience en programmation – dont beaucoup sont sceptiques quant au fait que des outils comme GPT soient réellement utiles pour produire du code de qualité industrielle.

Comme pour la plupart des choses, la réponse réelle se trouve probablement quelque part entre les deux.

On trouve facilement des vidéos YouTube de personnes qui partent d'une idée d'application, puis demandent à ChatGPT le code dont elles ont besoin. Certaines personnes arrivent même à prendre ce code et à l'assembler pour créer une application qui fonctionne.

Les grands modèles de langage comme GPT-4 sont impressionnants, et la vitesse à laquelle ils s'améliorent est encore plus impressionnante.

Pourtant, de nombreux développeurs sont sceptiques quant à l'utilité finale de ces outils. Ils se demandent si nous parviendrons à empêcher les IA d'"halluciner" de fausses informations.

C'est le problème fondamental de l'"interprétabilité". Il pourrait s'écouler des décennies avant que nous ne comprenions vraiment ce qui se passe à l'intérieur d'une boîte noire d'IA comme GPT-4. Et d'ici là, nous devrions tout vérifier deux fois, et supposer qu'il y aura beaucoup de bugs et de failles de sécurité dans le code qu'elle nous donne.

Il y a une grande différence entre être capable de faire faire quelque chose à un ordinateur pour vous, et comprendre réellement comment l'ordinateur le fait.

Beaucoup de gens savent conduire une voiture. Mais beaucoup moins savent la réparer – et encore moins concevoir une nouvelle voiture de A à Z.

Si vous voulez être capable de développer des systèmes logiciels puissants qui résolvent de nouveaux problèmes – et si vous voulez que ces systèmes soient rapides et sécurisés – vous allez toujours devoir apprendre à coder correctement.

Et cela signifie avancer à travers beaucoup d'ambiguïté.

Apprendre à coder est un processus ambigu

Quand on apprend à coder, on se demande constamment : "Est-ce que j'utilise mon temps à bon escient ? Est-ce que j'apprends les bons outils ? Est-ce que ces auteurs de livres / créateurs de cours savent même de quoi ils parlent ?"

L'ambiguïté embrume chaque séance d'étude. "Est-ce que mon test a échoué parce que le tutoriel n'est plus à jour et qu'il y a eu des changements majeurs dans le framework que j'utilise ? Ou est-ce que c'est moi qui m'y prends mal ?"

Comme je l'ai mentionné plus tôt avec l'enfer des tutoriels, vous devez également faire face à la maladie de "l'herbe est plus verte ailleurs".

Ceci est aggravé par le fait que certains développeurs pensent qu'il est malin de répondre aux questions par "RTFM", ce qui signifie "Read the Freaking Manual" (Lis le foutu manuel). Pas très utile. Quel manuel ? Quelle section ?

Un autre problème est que vous ne savez pas ce que vous ne savez pas. Souvent, vous ne pouvez même pas formuler la question que vous essayez de poser.

Et si vous ne pouvez même pas poser la bonne question, vous allez piétiner.

C'est particulièrement difficile avec le code car il est possible que personne n'ait tenté de construire exactement la même application que vous.

Et ainsi, certains des problèmes que vous rencontrez peuvent être sans précédent. Il se peut qu'il n'y ait personne vers qui se tourner.

15 % des requêtes que les gens tapent dans Google chaque jour n'ont jamais été recherchées auparavant. C'est une mauvaise nouvelle si vous êtes la personne qui tape l'une d'elles.

Ma théorie est que la plupart des développeurs résolvent un problème et passent simplement à autre chose, sans jamais le documenter nulle part. Vous êtes donc peut-être l'un des douzaines de développeurs qui ont dû inventer leur propre solution au même problème exact.

Et puis, bien sûr, il y a les vieux fils de discussion de forums et les pages StackOverflow.

Bande dessinée par XKCD

Comment ne pas se perdre en apprenant à coder

La bonne nouvelle est que la compétence et la confiance viennent avec la pratique.

Bientôt, vous saurez exactement quoi chercher sur Google. Vous développerez un sixième sens pour savoir comment la documentation est généralement structurée et où chercher quoi. Et vous saurez où poser quelles questions.

J'aimerais qu'il y ait une solution plus simple au problème de l'ambiguïté. Mais vous devez simplement l'accepter. Apprendre à coder est un processus ambigu. Et même les développeurs expérimentés sont aux prises avec l'ambiguïté.

Après tout, le codage est l'une des rares professions où l'on peut réutiliser indéfiniment des solutions à des problèmes déjà rencontrés.

Ainsi, en tant que développeur, vous faites toujours quelque chose que vous n'avez jamais fait auparavant.

Les gens pensent que le développement logiciel consiste à taper du code dans un ordinateur. Mais il s'agit en réalité d'apprendre.

Vous allez passer une part énorme de votre carrière à réfléchir intensément. Ou à taper aveuglément des commandes dans une invite pour essayer de comprendre comment un système fonctionne.

Et vous allez passer beaucoup de temps en réunion avec d'autres personnes : managers, clients, collègues développeurs. Apprendre le problème qui doit être résolu, afin de pouvoir construire une solution.

Soyez à l'aise avec l'ambiguïté et vous irez loin.

Apprendre à coder, c'est un message d'erreur après l'autre

Beaucoup de gens qui apprennent à coder ont l'impression de heurter un mur. Les progrès ne viennent pas aussi vite qu'ils l'espèrent.

Une raison majeure à cela : en programmation, la boucle de rétroaction est beaucoup plus serrée que dans d'autres domaines.

Dans la plupart des écoles, votre enseignant vous donne des devoirs, puis les note et vous les rend. Au cours d'un semestre, vous n'aurez peut-être qu'une douzaine d'occasions de recevoir un retour.

"Oh non, j'ai vraiment raté cet examen," pourriez-vous vous dire. "Je dois étudier plus dur pour le partiel."

Peut-être que votre enseignant laissera des notes à l'encre rouge sur votre copie pour vous aider à améliorer votre travail.

Recevoir une mauvaise note à un examen ou un devoir peut vraiment gâcher votre journée.

Et c'est ainsi que nous pensons généralement au feedback en tant qu'humains.

Si vous avez passé un peu de temps à coder, vous savez que les ordinateurs sont assez rapides. Ils peuvent exécuter votre code en quelques millisecondes.

La plupart du temps, votre code va planter.

Si vous avez de la chance, vous recevrez un message d'erreur.

Et si vous avez vraiment de la chance, vous obtiendrez une "trace de pile" (stack trace) – tout ce que l'ordinateur essayait de faire lorsqu'il a rencontré l'erreur – ainsi qu'un numéro de ligne pour le morceau de code qui a causé le plantage du programme.

C'est un retour négatif direct et brutal de la part d'un ordinateur. Tout le monde n'est pas capable de supporter de voir cela encore et encore toute la journée.

Imaginez si chaque fois que vous remettiez votre mémoire à votre professeur, il vous le rendait avec un grand "F" rouge écrit dessus. Et imaginez qu'il fasse cela avant même que vous ayez pu cligner des yeux. Encore et encore.

C'est ce que coder peut parfois donner comme impression. Vous avez envie de saisir l'ordinateur et de lui crier : "pourquoi ne comprends-tu pas ce que j'essaie de faire ?"

Comment ne pas se décourager

La clé, encore une fois, est la pratique.

Avec le temps, vous développerez une tolérance aux messages d'erreur vagues et aux traces de pile longues comme le bras.

Coder ne sera jamais plus difficile que lorsque vous débutez.

Non seulement vous ne savez pas ce que vous faites, mais vous n'êtes pas habitué à recevoir un feedback aussi impersonnel, rapide et négatif.

Voici donc quelques conseils :

Conseil n°1 : Sachez que vous n'êtes pas exceptionnellement mauvais à cela.

Tous ceux qui apprennent à coder luttent contre la frustration d'essayer de faire une fusion mentale vulcaine avec un ordinateur pour qu'il vous comprenne. (Encore une référence à Star Trek.)

Bien sûr, certaines personnes ont commencé la programmation quand elles étaient enfants. Elles peuvent agir comme si elles avaient toujours été douées pour ça. Mais elles ont très probablement galéré tout comme nous, adultes, et avec le temps ont simplement oublié les heures de frustration.

Considérez l'ordinateur comme votre ami, pas votre adversaire. Il vous demande simplement de clarifier vos instructions.

Conseil n°2 : Respirez.

La réaction naturelle de beaucoup de gens lorsqu'ils reçoivent un message d'erreur est de grincer des dents. Puis de retourner dans leur éditeur de code et de commencer à changer le code aveuglément, en espérant par chance passer outre.

Cela ne fonctionne pas. Et je vais vous dire pourquoi.

L'univers est complexe. Le logiciel est complexe. Il est peu probable que vous réussissiez quoi que ce soit de bon en mode "Forrest Gump".

Forrest Gump faisant ce qu'il fait et ayant une chance improbable en pêchant des crevettes.

Vous avez peut-être entendu parler du paradoxe du singe savant. C'est une expérience de pensée où l'on imagine des chimpanzés tapant sur des machines à écrire.

Si vous aviez une salle de rédaction pleine de chimpanzés faisant cela, combien de temps faudrait-il pour que l'un d'eux tape la phrase "être ou ne pas être" par pur hasard ?

Disons que chaque chimpanzé tape un caractère aléatoire par seconde. Il faudrait probablement 1 quintillion d'années pour que l'un d'eux tape "être ou ne pas être". C'est 10 à la puissance 18. Un milliard de milliards.

Même en supposant que les chimpanzés restent en bonne santé et que les machines à écrire soient régulièrement entretenues – la galaxie serait un vide froid et sombre au moment où l'un d'eux parviendrait à taper "être ou ne pas être".

Pourquoi je vous raconte tout cela ? Parce que vous ne voulez pas être l'un de ces chimpanzés.

Pendant ce temps, vous pourriez presque certainement trouver un moyen d'apprendre à ces chimpanzés à taper des mots français. Ils pourraient probablement réussir à taper tout Hamlet – pas seulement sa réplique la plus célèbre.

Même si vous avez de la chance et que vous dépassez le bug, qu'aurez-vous appris ?

Donc, au lieu de vous agiter, vous voulez prendre du temps. Comprendre le code. Comprendre ce qui se passe. Et ensuite corriger l'erreur.

Prenez toujours le temps de comprendre le code qui échoue. Ne soyez pas un chimpanzé quintillionnaire. (Je pense que cela signifie quelqu'un qui a 1 quintillion d'années, bien que selon Google, personne n'ait jamais tapé ce mot auparavant.)

Au lieu d'essayer des choses aveuglément en espérant passer le message d'erreur, ralentissez.

Prenez une profonde inspiration. Étirez-vous. Levez-vous pour aller chercher une boisson chaude.

Votre futur moi vous sera reconnaissant d'avoir fait de ce moment une occasion d'apprentissage.

Conseil n°3 : Utilisez la méthode du canard en plastique (Rubber Duck Debugging)

Prenez un petit canard en plastique et posez-le à côté de votre ordinateur. Chaque fois que vous rencontrez un message d'erreur, essayez d'expliquer ce que vous pensez qu'il se passe à votre canard.

Bien sûr, c'est ridicule. Comment cela pourrait-il être utile ?

Sauf que ça l'est.

Le débogage par le canard en plastique est un excellent outil pour ralentir et expliquer le problème en cours.

Vous n'êtes pas obligé d'utiliser un canard en plastique, bien sûr. Vous pourriez expliquer votre application Python à votre cactus de compagnie. Votre requête SQL au chat qui n'arrête pas de sauter sur votre clavier.

Le fait même d'expliquer votre raisonnement à voix haute semble vous aider à mieux traiter la situation.

Comment la plupart des gens apprennent-ils à coder ?

Parlons maintenant des parcours traditionnels vers un premier emploi de développeur.

Pourquoi devriez-vous vous soucier de ce que font les autres ? Alerte spoiler : vous n'en avez pas vraiment besoin.

Faites ce qui vous convient.

Cela dit, vous doutez peut-être de vous-même et des décisions que vous avez prises concernant votre apprentissage. Vous aspirez peut-être au chemin non emprunté.

Mon objectif avec cette section est de calmer vos angoisses.

L'importance des diplômes en informatique

Les diplômes universitaires restent la référence absolue pour se préparer à une carrière dans le développement logiciel. Surtout les licences en informatique (Computer Science).

Avant de commencer à dire "Mais je n'ai pas de diplôme en informatique" – pas de soucis. Vous n'avez pas besoin d'un diplôme en informatique pour devenir développeur.

Mais leur utilité est indéniable. Et je vais vous expliquer pourquoi.

D'abord, vous vous demandez peut-être : pourquoi les développeurs devraient-ils étudier l'informatique ? Après tout, l'un des développeurs les plus éminents de tous les temps a dit ceci à propos de ce domaine :

"L'enseignement de l'informatique ne peut faire de personne un programmeur expert, pas plus que l'étude des pinceaux et des pigments ne peut faire de quelqu'un un peintre expert." – Eric Raymond, développeur, informaticien et auteur

Les départements d'informatique faisaient traditionnellement partie du département de mathématiques. Les universités, dans les années 1960 et 1970, ne savaient pas trop où mettre tout ce truc informatique.

Dans d'autres universités, l'informatique était considérée comme une extension du génie électrique. Et jusqu'à récemment, même l'Université de Californie – Berkeley – l'une des plus grandes universités publiques au monde – ne proposait des diplômes en informatique que sous la forme d'une double spécialisation avec le génie électrique.

Mais la plupart des universités ont maintenant compris l'importance de l'informatique en tant que domaine d'étude.

À l'heure où j'écris ces lignes, l'informatique est le diplôme le plus rémunérateur que vous puissiez obtenir. Plus encore que les domaines axés sur l'argent, comme la finance et l'économie.

Selon Glassdoor, l'étudiant moyen en informatique aux États-Unis gagne plus d'argent lors de son premier emploi que n'importe quelle autre spécialité. 70 000 dollars US. C'est beaucoup d'argent pour quelqu'un qui vient de terminer ses études.

Plus que les diplômés en soins infirmiers (59 000 $), en finance (55 000 $) et en architecture (50 000 $).

D'accord – obtenir un diplôme en informatique peut vous aider à décrocher un emploi de débutant bien rémunéré. Ce n'est probablement une nouvelle pour personne. Mais pourquoi ?

Comment les employeurs perçoivent les diplômes de licence

Vous avez peut-être entendu de grands employeurs de la tech dire des choses comme : "nous n'exigeons plus que les candidats aient une licence."

Google l'a dit. Apple l'a dit.

Et je les crois. Qu'ils n'exigent plus de licence.

Nous avons eu beaucoup d'anciens de freeCodeCamp qui ont obtenu des emplois dans ces entreprises, dont certains n'avaient pas de licence.

Mais ces anciens de freeCodeCamp qui ont décroché ces emplois ont probablement dû être des candidats exceptionnels pour compenser le fait qu'ils n'avaient pas de licence.

Vous pouvez considérer ces offres d'emploi comme ayant divers critères sur lesquels les candidats sont jugés :

1. Expérience professionnelle
2. Éducation
3. Portfolio et projets
4. Ont-ils une recommandation de quelqu'un qui travaille déjà dans l'entreprise ? (Nous discuterons de la construction de votre réseau en profondeur au Chapitre 2)
5. Autres considérations de réputation (nous discuterons de la construction de votre réputation au Chapitre 3)

Pour ces employeurs qui n'exigent pas de licence, l'éducation n'est qu'une considération parmi d'autres. Si vous êtes plus fort dans d'autres domaines, ils peuvent choisir de vous interviewer – que vous ayez déjà mis les pieds dans une salle de classe universitaire ou non.

Notez simplement qu'avoir une licence facilitera l'obtention d'un entretien, même chez ces employeurs où le diplôme est facultatif.

Pourquoi tant d'emplois de développeurs exigent-ils spécifiquement un diplôme en informatique ?

Une licence reste une licence, dis-je souvent aux gens. Car dans la plupart des cas, c'est vrai.

Vous voulez entrer dans l'armée américaine en tant qu'officier plutôt qu'engagé ? Vous aurez besoin d'une licence, mais n'importe quelle spécialité fera l'affaire.

Vous voulez obtenir un visa de travail pour travailler à l'étranger ? Vous aurez probablement besoin d'une licence, mais n'importe quelle spécialité fera l'affaire.

Et pour tant d'offres d'emploi qui disent "licence exigée" – n'importe quelle spécialité fera l'affaire.

Pourquoi ? Le sujet que vous étudiez à l'université n'a-t-il aucune importance ?

Eh bien, voici ma théorie à ce sujet : ce que vous apprenez à l'université est moins important que le fait que vous ayez terminé l'université.

Les employeurs essaient de sélectionner des personnes capables de trouver un moyen de franchir ce rite de passage.

Il est tout à fait vrai que vous pouvez être en queue de classe, redoubler des cours que vous avez ratés et être en probation académique la moitié du temps. Mais un diplôme est un diplôme.

Savez-vous comment on appelle l'étudiant qui a terminé dernier de sa classe à l'école de médecine ? "Docteur".

Et pour la plupart des employeurs, il en va de même.

Dans de nombreux cas, les gens des RH ne font que cocher une case sur leur logiciel de filtrage des candidatures. Ils filtrent les candidats qui n'ont pas de diplôme. Dans ces cas-là, ils ne regarderont peut-être même jamais les candidatures de personnes sans diplôme.

Encore une fois, tous les employeurs ne sont pas comme ça. Mais beaucoup le sont. Ici aux États-Unis, et peut-être encore plus dans d'autres pays.

C'est nul, mais c'est ainsi que fonctionne le marché du travail actuellement. Cela changera peut-être au cours des prochaines décennies. Peut-être pas.

C'est pourquoi j'encourage toujours les personnes de 10 à 20 ans à envisager sérieusement d'obtenir une licence.

Pas pour l'une des raisons pour lesquelles les universités se vendent :

• L'éducation elle-même. (Vous pouvez suivre gratuitement des cours de certaines des meilleures universités en ligne, donc cela seul ne justifie pas le coût élevé des frais de scolarité.)
• L'"expérience universitaire" de vivre dans un dortoir, de se faire de nouveaux amis et de se découvrir. (La plupart des étudiants universitaires américains ne vivent jamais sur le campus, ils n'ont donc pas vraiment cela de toute façon.)
• Les cours d'enseignement général qui vous aident à devenir un "individu équilibré".

Encore une fois, la valeur réelle de l'obtention d'une licence – la vraie raison pour laquelle les Américains paient 100 000 $ ou plus pour 4 ans d'université – est que de nombreux employeurs exigent des diplômes.

Bien sûr, il y a d'autres avantages à avoir une licence, comme ceux que j'ai mentionnés : options de carrière militaire élargies et plus grande facilité à obtenir des visas de travail.

L'un d'eux est : si vous voulez devenir médecin, dentiste, avocat ou professeur, vous aurez d'abord besoin d'une licence. Vous pourrez ensuite l'utiliser pour entrer en master ou doctorat.

D'accord – c'est beaucoup d'informations de contexte. Permettez-moi donc de répondre franchement à vos questions.

Avez-vous besoin d'un diplôme universitaire pour travailler comme développeur logiciel ?

Non. Il y a beaucoup d'employeurs qui vous embaucheront sans licence.

Une licence facilitera grandement l'obtention d'un entretien chez de nombreux employeurs. Et cela peut également vous aider à obtenir un salaire plus élevé.

Qu'en est-il des diplômes de niveau Bac+2 (Associate's Degrees) ? Ont-ils de la valeur ?

En théorie, oui. Il y a certains domaines technologiques où un Bac+2 peut être requis. Et je pense que cela augmente toujours vos chances d'obtenir un entretien.

Cela dit, je ne recommanderais pas d'aller à l'université dans le but spécifique d'obtenir un Bac+2. Je vous encouragerais à 100 % à rester à l'école jusqu'à l'obtention d'une licence (Bac+3/Bac+4), qui est infiniment plus utile.

Selon le département de l'Éducation des États-Unis, au cours de votre carrière, le fait d'avoir une licence vous rapportera 31 % de plus que le simple fait d'avoir un Bac+2.

Et je suis convaincu que cet écart est beaucoup plus large avec une licence en informatique.

Vaut-il la peine d'aller à l'université pour obtenir une licence plus tard dans la vie, si vous n'en avez pas déjà une ?

Disons que vous avez la trentaine. Peut-être avez-vous suivi quelques cours à l'université. Peut-être avez-vous terminé les deux premières années et avez-vous pu obtenir un diplôme de niveau Bac+2.

Est-ce logique de "retourner à l'école" au sens formel ?

Oui, cela peut avoir du sens.

Mais je ne pense pas qu'il soit jamais judicieux de quitter son emploi pour retourner à l'école à plein temps.

Le mode de vie d'étudiant à plein temps est vraiment conçu pour les étudiants "traditionnels". C'est-à-dire les personnes âgées de 18 à 22 ans (ou un peu plus si elles ont servi dans l'armée), qui ne sont pas encore entrées sur le marché du travail au-delà des petits boulots de lycéens / d'été.

Les universités traditionnelles coûtent cher, et l'hypothèse est que les étudiants paieront grâce à une combinaison de bourses, de fonds familiaux et de prêts étudiants.

En tant qu'adulte qui travaille, vous aurez moins accès à ces sources de financement. Et tout aussi important, vous aurez moins de temps qu'un jeune diplômé du secondaire.

Mais cela ne signifie pas que vous devez abandonner le rêve d'obtenir une licence.

Au lieu de fréquenter une université traditionnelle, je recommande aux personnes de plus de 30 ans de s'inscrire dans l'une des universités en ligne à but non lucratif. Deux d'entre elles ont une bonne réputation et des frais très raisonnables : Western Governor's University et University of the People.

Vous pouvez également trouver un collège communautaire local ou un programme d'extension d'université d'État qui propose des diplômes. Beaucoup de ces programmes sont en ligne. Et certains sont même à votre propre rythme, afin que vous puissiez terminer les cours selon votre emploi du temps professionnel.

Faites vos recherches. Si une école semble prometteuse, je recommande de trouver l'un de ses anciens élèves sur LinkedIn et de le contacter. Posez-lui des questions sur son expérience et demandez-lui s'il pense que cela en valait la peine.

Je recommande de ne pas s'endetter pour financer votre diplôme. Il est bien préférable de fréquenter une école moins chère. Après tout, un diplôme est un diplôme. Tant qu'il provient d'une institution accréditée, cela devrait aller pour la plupart des usages.

Si vous avez déjà une licence, est-il logique de retourner à l'université pour obtenir une deuxième licence en informatique ?

Non. Les deuxièmes licences ne valent presque jamais le temps et l'argent investis.

Si vous avez une licence – même si c'est dans un domaine non scientifique – vous avez déjà tiré la majeure partie de la valeur que vous obtiendrez de l'université.

Qu'en est-il d'un Master en informatique ?

Ceux-ci peuvent être utiles pour l'avancement de carrière. Mais vous devriez les envisager plus tard, une fois que vous travaillez déjà comme développeur.

De nombreux employeurs paieront pour la formation continue de leurs employés.

Un programme que beaucoup de mes amis dans la tech ont suivi est le Master en informatique de Georgia Tech.

Le département d'informatique de Georgia Tech est parmi les meilleurs aux États-Unis. Et ce programme de master est non seulement entièrement en ligne, mais aussi très abordable.

Mais je ne recommanderais pas de le faire maintenant. Concentrez-vous d'abord sur l'obtention d'un emploi de développeur. (Nous couvrirons cela en profondeur plus loin dans ce livre).

Les diplômes continueront-ils à avoir de l'importance à l'avenir ?

Oui, je crois que les diplômes universitaires continueront à avoir de l'importance pendant des décennies – et peut-être des siècles – à venir.

Les diplômes universitaires existent depuis plus de 1 000 ans.

Beaucoup des meilleures universités des États-Unis sont plus vieilles que les États-Unis eux-mêmes. (Harvard a plus de 400 ans.)

La mort du diplôme universitaire est grandement exagérée.

Il est devenu populaire dans certains cercles de critiquer les universités et de dire que les diplômes ne comptent plus.

Mais si vous regardez les statistiques, ce n'est manifestement pas vrai. Ils ont un impact sur les revenus tout au long de la vie.

Et tout aussi important, ils peuvent ouvrir des carrières plus sûres, plus stables et finalement plus épanouissantes.

Bien sûr, vous pouvez gagner un excellent salaire en travaillant comme matelot en mer sur des plates-formes pétrolières.

Mais vous pouvez gagner un salaire tout aussi excellent en travaillant comme développeur dans un bureau climatisé, à entretenir des serveurs et à corriger des bases de code.

L'un de ces emplois est un travail dangereux et épuisant. L'autre est un emploi que vous pourriez confortablement exercer pendant 40 ans.

Beaucoup des "leaders d'opinion" qui critiquent les universités ont eux-mêmes bénéficié d'une éducation universitaire.

L'une des raisons pour lesquelles je pense que tant de gens pensent que les diplômes sont "inutiles" est qu'il est difficile de démêler l'apprentissage du boost de statut que l'on obtient.

L'université n'est-elle qu'une forme de signalement de classe – un moyen pour les riches de continuer à transmettre des avantages à leurs enfants ? Après tout, vous avez 3 fois plus de chances de trouver un enfant riche à Harvard qu'un enfant pauvre.

Le fait est que la vie est fondamentalement injuste. Mais cela ne change pas le fonctionnement du marché du travail.

Vous pouvez choisir le mode facile et obtenir un diplôme qui vous donnera plus d'options à l'avenir.

Ou vous pouvez choisir le mode difficile, potentiellement économiser du temps et de l'argent, et simplement être plus sélectif quant aux employeurs auxquels vous postulez.

J'ai beaucoup d'amis qui ont utilisé les deux approches avec grand succès.

Quelles alternatives existe-t-il au diplôme universitaire ?

Je travaille dans l'éducation des adultes depuis près de deux décennies, et je n'ai pas encore vu de substitut convaincant au diplôme universitaire.

Bien sûr – il existe des programmes de certification et des bootcamps.

Mais ceux-ci n'ont pas le même poids auprès des employeurs. Et ils sont rarement aussi rigoureux.

Note de côté : quand je dis "programmes de certification", je parle d'un programme où vous suivez un cours, puis obtenez une certification à la fin. Ceux-ci ont une valeur limitée. Mais les certifications basées sur des examens d'entreprises comme Amazon et Microsoft sont très précieuses. Nous en discuterons plus en détail plus tard.

Ce que je dis aux gens, c'est : obtenir un diplôme ou ne pas en obtenir – telle est la question.

Je rencontre beaucoup de gens qui sont mécaniciens automobiles, électriciens ou qui exercent un autre métier manuel, et qui n'ont pas de licence. Ils peuvent manifestement apprendre une compétence, l'appliquer et garder un emploi.

Je rencontre beaucoup de gens qui sont comptables, parajuristes et d'autres "travailleurs du savoir" qui n'ont pas de licence. Ils peuvent manifestement apprendre une compétence, l'appliquer et garder un emploi.

Dans de nombreux cas, ces personnes peuvent simplement apprendre à coder par elles-mêmes, en utilisant des ressources d'apprentissage gratuites et en fréquentant des personnes partageant les mêmes idées.

Certaines de ces personnes ont toujours eu pour objectif personnel de retourner à l'université et de terminer leur licence. C'est une bonne raison de le faire.

Mais ce n'est pas pour tout le monde.

Si vous voulez une éducation formelle, visez la licence. Si vous ne voulez pas d'éducation formelle, ne faites aucun programme. Apprenez simplement par vous-même.

La principale chose que les bootcamps et autres programmes de certification vont vous apporter, c'est une structure et un peu de pression des pairs. Ce n'est pas une mauvaise chose. Mais cela vaut-il la peine de payer des milliers de dollars pour cela ?

Comment apprendre seul à coder

La plupart des développeurs sont autodidactes. Même les développeurs qui ont obtenu une licence en informatique se déclarent souvent "autodidactes" dans les enquêtes de l'industrie comme l'enquête annuelle de Stack Overflow.

La plupart des développeurs en activité se considèrent comme "autodidactes" (Image : Enquête Stack Overflow 2016)

C'est parce que apprendre à coder est un processus qui dure toute la vie. Il y a constamment de nouveaux outils à apprendre, de nouvelles bases de code legacy à explorer et de nouveaux problèmes à résoudre.

Que vous poursuiviez des études formelles ou non, sachez ceci : vous devrez devenir bon en auto-apprentissage.

Que signifie être un développeur "autodidacte" ?

Sans vouloir être pédant, quand je parle d'auto-apprentissage, je veux dire un apprentissage dirigé par soi-même – un apprentissage en dehors de l'éducation formelle.

Très peu de gens sont véritablement "autodidactes" en quoi que ce soit. Par exemple, Isaac Newton a appris seul le calcul infinitésimal parce qu'il n'existait pas de livres sur le sujet. Il a dû le comprendre et l'inventer au fur et à mesure.

De même, Ada Lovelace a appris seule la programmation. Parce qu'avant elle, la programmation n'existait pas. Elle l'a inventée.

Quelqu'un pourrait vous dire : "Tu n'es pas vraiment autodidacte parce que tu as appris dans des livres ou des cours en ligne. Tu as donc eu des professeurs." Et il a raison, mais seulement au sens le plus étroit du terme.

Si quelqu'un s'offusque que vous vous appeliez autodidacte, dites simplement : "Selon vos critères, personne n'ayant pas été élevé par des loups ne peut prétendre être autodidacte en quoi que ce soit."

Montrez-leur cette section de ce livre et dites-leur : "Quincy a anticipé votre snobisme." Et puis passez à autre chose.

Parce que franchement, la vie est trop courte, n'est-ce pas ?

Vous êtes autodidacte.

Qu'est-ce que l'apprentissage dirigé par soi-même ?

En tant qu'apprenant autonome, vous allez organiser vos propres ressources d'apprentissage. Vous allez choisir quoi apprendre et où. C'est l'essence même de l'"apprentissage dirigé par soi-même".

Mais comment savoir si vous apprenez les bonnes compétences et si vous utilisez les bonnes ressources ?

Eh bien, c'est là que la communauté intervient.

Il existe de nombreuses communautés d'apprenants à travers le monde, qui s'entraident toutes pour développer leurs compétences.

Le mot communauté est difficile à définir. Est-ce que Tech Twitter est une communauté ? Qu'en est-il du forum freeCodeCamp ? Ou des nombreux groupes Discord et subreddits dédiés à des compétences de codage spécifiques ?

Je considère tout cela comme des communautés. S'il y a des gens qui s'y retrouvent régulièrement et s'entraident, je considère que c'est une communauté.

Qu'en est-il des événements en personne ? Le meetup mensuel des développeurs Ruby à Oakland ? Le meetup de la communauté startup de New York ? Le groupe d'utilisateurs Linux du centre du Texas ?

Ces communautés peuvent être en ligne, en personne, ou un mélange des deux.

Nous parlerons davantage des communautés dans le chapitre Construisez votre réseau. Mais le point essentiel est le suivant : les nouveaux amis que vous rencontrerez dans ces communautés peuvent vous aider à restreindre vos options sur ce qu'il faut apprendre et quelles ressources utiliser.

Quel langage de programmation devrais-je apprendre en premier ?

La réponse courte est : cela n'a pas vraiment d'importance. Une fois que vous avez bien appris un langage de programmation, il est beaucoup plus facile d'apprendre votre deuxième langage.

Il existe différents types de langages de programmation, mais aujourd'hui, la plupart des développements se font à l'aide de "langages de script de haut niveau" comme JavaScript et Python. Ces langages sacrifient l'efficacité brute que l'on obtient avec des "langages de programmation de bas niveau" comme le C. Ce qu'ils obtiennent en retour : l'avantage d'être beaucoup plus faciles à utiliser.

Les ordinateurs d'aujourd'hui sont des milliards de fois plus rapides qu'ils ne l'étaient dans les années 1970 et 1980, lorsque les gens écrivaient la plupart de leurs programmes dans des langages comme le C. Cette puissance compense largement l'inefficacité relative des langages de script.

Il est à noter que JavaScript et Python sont eux-mêmes écrits en C, et qu'ils deviennent tous deux plus rapides chaque année – grâce à leurs grandes communautés de contributeurs open source.

Python est un langage puissant pour le calcul scientifique (Data Science et Machine Learning).

Et JavaScript... eh bien, JavaScript peut tout faire. C'est le couteau suisse ultime des langages de programmation. JavaScript est le ruban adhésif qui maintient le World Wide Web ensemble.

"Toute application pouvant être écrite en JavaScript sera finalement écrite en JavaScript." – Loi d'Atwood (Jeff Atwood, fondateur de Stack Overflow et Discourse)

Vous pourriez faire toute votre carrière en JavaScript et n'auriez jamais besoin d'apprendre un second langage. (Cela dit, vous voudrez apprendre Python plus tard, et peut-être d'autres langages également.)

Je recommande donc de commencer par JavaScript. Non seulement il est beaucoup plus facile à utiliser que des langages comme Java et C++ – il est aussi plus facile à apprendre. Et il y a beaucoup, beaucoup plus d'offres d'emploi pour les personnes qui connaissent JavaScript.

Une capture d'écran du moteur de recherche d'emploi Indeed. Ma recherche pour "javascript" aux États-Unis a donné 68 838 offres d'emploi.

Les autres compétences sur lesquelles vous voudrez vous concentrer sont le HTML et le CSS. Si une page web était un corps, le HTML serait les os et le CSS serait la peau. (Le JavaScript serait les muscles, permettant au site web de bouger et d'être interactif.)

Vous pouvez apprendre un peu de HTML et de CSS en un seul après-midi. Comme la plupart des outils que je mentionne ici, ils sont faciles à apprendre, mais difficiles à maîtriser.

Vous voudrez également apprendre à utiliser Linux. Linux alimente une vaste majorité des serveurs mondiaux, et vous passerez une grande partie de votre carrière à exécuter des commandes dans la ligne de commande Linux.

Si vous avez un Mac, MacOS possède un terminal qui accepte presque toutes les mêmes commandes que Linux. (MacOS et Linux ont un ancêtre commun dans Unix.)

Mais si vous êtes sur un PC Windows, vous voudrez installer WSL, qui signifie Windows Subsystem for Linux. Vous pourrez alors exécuter des commandes Linux sur votre PC. Et si vous vous sentez aventureux, vous pouvez même faire un dual-boot avec les systèmes d'exploitation Windows et Linux sur le même ordinateur.

Si vous allez installer Linux sur un ordinateur, je recommande de commencer par Ubuntu. C'est la distribution Linux la plus utilisée (et la plus documentée). Elle devrait donc être la plus indulgente.

Ne vous y trompez pas – Linux est bien plus difficile à utiliser que Windows et MacOS. Mais ce que vous obtenez en retour de vos efforts est un système d'exploitation extrêmement rapide, sécurisé et hautement personnalisable.

De plus, vous n'aurez plus jamais à payer pour une licence de système d'exploitation. À moins que vous ne le vouliez. Red Hat est une entreprise pesant des milliards de dollars même si son logiciel est open source, car les entreprises paient pour leur aide à l'entretien et au support des serveurs Linux.

Vous voudrez également apprendre Git. Ce système de contrôle de version (Version Control System) est la manière dont les équipes de développeurs coordonnent leurs modifications d'une base de code.

Vous avez peut-être entendu parler de GitHub. C'est un site web qui facilite la collaboration des développeurs sur des projets open source. Et il étend encore certaines des fonctionnalités de Git. Vous en apprendrez plus sur GitHub dans le chapitre Comment construire votre réputation plus tard.

Vous voudrez apprendre le SQL et le fonctionnement des bases de données relationnelles. Ce sont les bêtes de somme de l'économie de l'information.

Vous entendrez également beaucoup parler des bases de données NoSQL (bases de données non relationnelles telles que les bases de données orientées graphes, orientées documents et les magasins clé-valeur). Vous pourrez en apprendre davantage à leur sujet plus tard. Mais concentrez-vous d'abord sur le SQL.

Enfin, vous voudrez apprendre comment fonctionnent les serveurs Web. Vous voudrez commencer par Node.js et Express.js.

Lorsque vous entendez le terme "développement full-stack", cela fait référence à l'assemblage du front-end (HTML, CSS, JavaScript) avec le back-end (Linux, bases de données SQL, et Node + Express).

Il existe de nombreux autres outils que vous voudrez apprendre, comme React, NGINX, Docker et des bibliothèques de tests. Vous pourrez les acquérir au fur et à mesure.

Mais les compétences clés sur lesquelles vous devriez passer 90 % de votre temps d'apprentissage avant l'emploi sont :

1. HTML
2. CSS
3. JavaScript
4. Linux
5. Git
6. SQL
7. Node.js
8. Express.js

Si vous apprenez ces outils, vous pouvez construire la plupart des grandes applications web et mobiles. Et vous serez qualifié pour la plupart des emplois de développeur débutant. (Bien sûr, de nombreuses descriptions de poste incluront d'autres outils, mais nous en discuterons plus tard dans le livre.)

Vous vous dites peut-être : génial. Comment j'apprends tout ça ?

Où apprendre à coder ?

C'est une excellente question. Il existe un curriculum complet conçu par des ingénieurs logiciels et des enseignants expérimentés. Il est conçu pour les adultes occupés. Et il est entièrement gratuit et à votre propre rythme.

C'est exact. Je parle du curriculum de base de freeCodeCamp. Il vous aidera à apprendre :

• Le développement Front-End
• Le développement Back-End
• Les mathématiques pour l'ingénierie
• et le calcul scientifique (avec Python pour la Data Science et le Machine Learning)

À ce jour, des milliers de personnes ont suivi ce curriculum de base et ont obtenu un emploi de développeur. Elles n'ont pas eu besoin de quitter leur emploi, de contracter des prêts ou de risquer quoi que ce soit d'autre qu'une partie de leurs soirées et de leurs week-ends.

En pratique, freeCodeCamp est devenu le parcours par défaut pour la plupart des gens qui apprennent à coder par eux-mêmes.

Si rien d'autre, le curriculum de base de freeCodeCamp peut être votre "base d'attache" pour l'apprentissage, et vous pouvez bifurquer à partir de là. Vous pouvez apprendre les compétences de base que la plupart des emplois exigent, et aussi toucher aux technologies qui vous intéressent.

Il existe des décennies de livres et de cours pour apprendre. Certains sont disponibles dans votre bibliothèque publique, ou via des services d'abonnement mensuel. (Et vous pourrez peut-être accéder à certains de ces services d'abonnement gratuitement via votre bibliothèque également.)

De plus, freeCodeCamp propose désormais près de 1 000 cours complets gratuits sur tout, de la préparation à la certification AWS au développement d'applications mobiles en passant par Kali Linux.

Il n'y a jamais eu de moment plus facile pour apprendre seul la programmation.

Développer vos compétences est une entreprise de toute une vie

Nous avons vu pourquoi l'auto-apprentissage est probablement la meilleure voie à suivre, et comment s'y prendre.

Nous avons parlé des alternatives à l'auto-apprentissage, comme l'obtention d'une licence en informatique ou d'un master.

Et nous avons vu quels outils spécifiques vous devriez vous concentrer à apprendre en premier.

Maintenant, changeons de vitesse et parlons de la façon de construire le deuxième pilier de votre réussite : votre réseau.

Chapitre 2 : Comment construire votre réseau

"Si tu veux aller vite, marche seul. Si tu veux aller loin, marchons ensemble." – Proverbe africain

"Réseautage." Vous pourriez grimacer au son de ce mot.

Le réseautage peut évoquer des salons de l'emploi maladroits dans des costumes étouffants, essayant désespérément de glisser votre CV dans les mains de quiconque l'acceptera.

Le réseautage peut évoquer des soirées arrosées devant un match – où vous faites semblant de vous intéresser à un sport que vous ne suivez même pas.

Le réseautage peut évoquer le fait de souhaiter un "joyeux anniversaire" à des gens que vous connaissez à peine sur LinkedIn, ou de "liker" leurs mises à jour de statut en espérant qu'ils vous remarquent.

Mais le réseautage n'a pas à être ainsi.

Dans ce chapitre, je vous dirai tout ce que j'ai appris sur la rencontre de nouvelles personnes. Je vous montrerai comment gagner leur confiance et être la première personne à laquelle ils pensent lorsqu'ils ont besoin d'aide.

Parce qu'en fin de compte, c'est de cela qu'il s'agit. Aider les gens à résoudre leurs problèmes. Être utile aux autres.

Je vous montrerai comment construire un réseau personnel robuste qui vous soutiendra pendant des décennies.

L'heure de l'histoire : comment un enseignant dans la trentaine a-t-il construit un réseau dans la tech ?

La dernière fois dans l'Heure de l'histoire : Quincy a appris un peu de code en lisant des livres, en suivant des cours en ligne gratuits et en fréquentant des développeurs au Hackerspace local. Il venait de terminer son premier projet et de donner sa première conférence technique...

D'accord – j'avais maintenant quelques compétences rudimentaires en codage. Je pouvais maintenant me débrouiller un minimum.

Quelle était la suite ? Après tout, j'étais un total étranger à la tech.

Eh bien, même si j'étais nouveau dans la tech, je n'étais pas nouveau dans le monde du travail. J'avais gagné ma vie pendant près d'une décennie en travaillant dans des écoles et en enseignant l'anglais.

En tant qu'enseignant, j'étais payé pour transmettre du savoir. En tant que développeur, je serais payé pour produire du code.

Je connaissais déjà une vérité très importante sur la nature du travail : c'est une question de réseau.

Je connaissais le pouvoir des réseaux. Je savais que le chemin vers l'opportunité passe directement par les gardiens du temple.

Tout ce qui me séparait d'un emploi de développeur lucratif était un responsable du recrutement capable de dire : "Oui. Ce gars Quincy semble être quelqu'un digne de rejoindre notre équipe."

Bien sûr, étant un étranger à la tech, je ne connaissais pas la culture.

La culture académique est beaucoup plus formelle.

On porte un costume.

On utilise une terminologie académique sophistiquée pour démontrer que l'on fait partie du "groupe".

On trouve des moyens d'insérer dans chaque conversation que l'on est allé à l'université X, ou que l'on a été assistant du Dr Y, ou que l'on a été publié dans la revue Z.

Les progressions de carrière sont différentes. Les conférences sont différentes. Les structures de pouvoir sont différentes.

Et je n'ai pas immédiatement apprécié ce fait.

Lors des premiers événements tech auxquels je suis allé, je portais un costume.

Je gardais des copies soigneusement pliées de mon CV dans ma poche à tout moment.

Je portais même des cartes de visite. J'avais commandé des feuilles d'aluminium anodisé et utilisé un découpeur laser pour y graver mon nom, mon adresse e-mail et même une citation du légendaire éducateur John Dewey :

"Quiconque a commencé à penser met une partie du monde en péril." – John Dewey

C'est toujours ma citation préférée à ce jour.

Mais quel manque de finesse.

"Salut, je suis Quincy. Voici ma carte de visite en aluminium rouge. Désolé d'avance – elle risque de déclencher le détecteur de métaux lors de votre vol de retour."

J'en faisais trop. Et c'était probablement douloureusement évident pour tous ceux à qui je parlais.

Je suis allé sur Meetup.com et j'ai répondu présent à chaque événement de développeurs que je pouvais trouver. Santa Barbara est une petite ville, mais elle est proche de Los Angeles. J'ai donc fait le trajet pour des événements là-bas aussi.

J'ai vite compris et j'ai troqué mon costume pour un jean et un sweat à capuche. Et j'ai remarqué que personne d'autre ne donnait de cartes de visite. J'ai donc arrêté d'en porter.

Je me suis inspiré des développeurs que j'ai rencontrés au hackerspace : soyez passionné, mais sobre. Gardez une partie de votre enthousiasme en réserve.

Et j'ai lu beaucoup de livres pour mieux comprendre la culture des développeurs.

The Coders at Work est un bon livre des années 1980.

Hackers: Heroes of the Revolution est un bon livre des années 1990.

Pour une ressource culturelle plus contemporaine, regardez la série télévisée Mr. Robot. Ses personnages sont un peu extrêmes, mais ils capturent bien l'état d'esprit et les manières de nombreux développeurs.

Bientôt, je parlais moins comme un enseignant et plus comme un développeur. Je ne détonnais plus de manière aussi maladroite.

Plusieurs fois par semaine, j'assistais à des événements locaux liés à la tech. Mon événement préféré n'était même pas un événement de développeurs. C'était la Santa Barbara Startup Night. Toutes les quelques semaines, ils organisaient un événement où les développeurs présentaient leurs prototypes. Certains des développeurs faisant la démonstration de leur code parvenaient même à obtenir des financements auprès de "business angels" – des gens riches qui investissent dans des entreprises en phase de démarrage.

Le gars qui dirigeait l'événement s'appelait Mike. Il devait connaître chaque développeur et entrepreneur de Santa Barbara.

Quand j'ai enfin eu le courage de me présenter à Mike, j'étais impressionné. C'était un ultra-marathonien avec un rythme cardiaque au repos dans les 40 battements par minute. Cheveux et barbe parfaitement taillés. Pour moi, c'était le gars le plus cool de la planète. Toujours impeccable. Toujours respectueux.

Mike était "non-technique". Il travaillait comme chef de produit (product manager). Et bien qu'il en sache beaucoup sur la technologie et la conception de l'expérience utilisateur, il ne savait pas coder.

Parfois, les développeurs écartaient les personnes non techniques. "C'est juste un gars du business," disaient-ils. Ou : "C'est un costume." Mais je n'ai jamais entendu personne dire cela de Mike. Il avait le respect de tout le monde.

Je me suis fait un point d'honneur d'observer la façon dont Mike interagissait avec les développeurs. Après tout, je n'étais pas si loin d'être "non-technique" moi-même. Je ne codais que depuis quelques mois.

Souvent, mes vieilles habitudes revenaient. Pendant les conversations, j'avais la tentation d'étaler ce que j'avais appris ou ce que j'avais construit.

Beaucoup de développeurs sont modestes quant à leurs compétences ou leurs réalisations. Ils pourraient dire : "Je touche un peu à Python." Et le petit moi peu sûr de lui ouvrait sa grande bouche pour dire quelque chose comme : "Oh ouais. J'ai codé tellement d'algorithmes en Python. J'écris du Python en dormant."

Et puis je rentrais chez moi et je cherchais le nom de ce développeur sur Google, pour réaliser qu'il était un contributeur majeur d'une bibliothèque Python importante. Et je m'en voulais.

J'ai vite appris à ne pas me vanter de mes réalisations ou de mes compétences. Il y a de fortes chances que la personne à qui vous parlez puisse vous donner des leçons de code. Mais la plupart d'entre eux ne s'en vanteraient jamais.

Il n'y a rien de pire que de sortir son ordinateur portable avec assurance, de montrer son code, puis de se voir poser une série de questions auxquelles on n'est absolument pas préparé à répondre.

Mes premiers mois de participation à des événements ont été une expérience d'humilité. Mais ces événements m'ont donné l'énergie nécessaire pour continuer à progresser dans mes compétences.

Bientôt, les gens du sud de la Californie commençaient à me reconnaître. Ils disaient : "Je te croise tout le temps à ces événements. C'est quoi ton nom déjà ?"

Un soir, un développeur a dit : "Suivons-nous sur Twitter." J'avais créé à contrecœur un compte Twitter quelques jours plus tôt, pensant que c'était un site gadget. Que pouvait-on vraiment transmettre avec seulement 140 caractères ? Je n'avais presque rien tweeté. Mais j'avais un compte Twitter prêt, et elle m'a suivi.

Cela m'a inspiré à passer plus de temps à peaufiner ma présence en ligne. J'ai rendu mon LinkedIn moins formel et plus convivial. J'ai regardé comment d'autres développeurs de la communauté se présentaient en ligne.

En quelques mois, je connaissais des gens de nombreux domaines :

• des développeurs expérimentés
• des personnes non techniques ou semi-techniques travaillant dans des entreprises tech
• des responsables du recrutement et des recruteurs
• et plus important encore, mes pairs qui étaient également en milieu de carrière et essayaient de percer dans la tech

Pourquoi les pairs étaient-ils les plus importants ? Sûrement qu'ils seraient les moins capables de m'aider à obtenir un emploi, non ?

Eh bien, laissez-moi vous confier un secret : disons qu'un responsable du recrutement embauche un nouveau développeur, le forme, et qu'il s'avère être vraiment bon dans son travail. Ce responsable va demander : où puis-je trouver d'autres personnes comme toi ?

Vos pairs sont l'un des éléments les plus importants de votre réseau. Beaucoup de mes opportunités de freelance et d'entretiens d'embauche sont venues de personnes qui ont commencé à apprendre à coder à peu près en même temps que moi.

Nous avons progressé ensemble. Nous étions des frères et sœurs d'armes. Ces liens sont les plus serrés.

Quoi qu'il en soit, tout ce réseautage au fil des mois allait finalement porter ses fruits un soir où je suis entré dans le bar d'un hôtel chic du centre-ville pour un événement de développeurs.

Mais nous en reparlerons dans le prochain chapitre. Parlons maintenant davantage de l'art et de la science de la construction de votre réseau.

Est-ce vraiment une question de réseau ?

Vous avez peut-être entendu l'expression selon laquelle le succès est "moins une question de ce que vous savez, et plus une question de qui vous connaissez."

En pratique, c'est une question des deux.

Oui – vos relations peuvent vous aider à décrocher l'emploi de vos rêves. Mais si vous n'êtes pas à la hauteur et que vous manquez de compétences pour réussir, vous ne ferez pas long feu dans ce rôle.

Mais supposons que vous développiez activement vos compétences. Vous avez suivi mes conseils du Chapitre 1. Quel est le bon moment pour commencer à construire votre réseau ?

Le meilleur moment pour commencer à construire votre réseau, c'était hier.

Mais vous n'avez pas besoin d'une machine à remonter le temps pour le faire. Parce que vous avez déjà un réseau. Il est probablement beaucoup plus petit que vous ne le souhaiteriez, mais vous connaissez des gens.

Ce peuvent être des amis de votre ville natale, ou les collègues de vos parents. Toute personne que vous connaissez de votre passé – même marginalement – peut être d'une aide précieuse.

L'étape n°1 consiste donc à faire l'inventaire complet des personnes que vous connaissez. Ne vous inquiétez pas – je ne vous demande pas encore de contacter qui que ce soit, ni de solliciter vos relations personnelles.

Réfléchissez avant d'agir. Formulez une stratégie.

Tout d'abord, faisons l'inventaire de toutes les personnes que vous connaissez.

Comment construire un tableau de réseau personnel

Vous voulez commencer par créer une liste des personnes que vous connaissez.

Vous pourriez le faire avec une feuille de calcul, ou un outil de gestion de la relation client (CRM) comme les commerciaux en utilisent. Mais c'est probablement excessif pour ce que nous faisons ici.

Je recommande d'utiliser un outil de tableau Kanban comme Trello, qui est gratuit.

Vous allez créer 5 colonnes : "à évaluer", "à contacter", "en attente de réponse", "en contact récemment" et "ne pas contacter pour l'instant".

Ensuite, vous voudrez créer des étiquettes, afin de pouvoir classer les gens selon la façon dont vous les connaissez. Voici quelques idées d'étiquettes : "Ami d'enfance", "Ami de la famille", "Ancien collègue", "Camarade de classe", "Amis d'événements tech".

Maintenant, vous pouvez commencer à créer des cartes. Chaque carte peut simplement porter leur nom, et si vous avez le temps, vous pouvez ajouter une photo à la carte.

Voici le tableau Trello que j'ai créé pour vous donner une idée de ce à quoi ce tableau de réseau personnel pourrait ressembler. J'ai utilisé des personnages de mon film d'enfance préféré, le classique de 1989, les Tortues Ninja.

Mon tableau de réseau personnel avec mes amis de mon travail secondaire de lutte contre le crime.

Vous pouvez parcourir vos comptes de réseaux sociaux – même vos vieux albums de fin d'année si vous les avez – et commencer à ajouter des gens.

Beaucoup de ces personnes ne seront d'aucune aide. Mais je recommande de les ajouter par souci d'exhaustivité. On ne sait jamais quand on se souviendra : "oh – untel a eu un emploi chez XYZ corp. Je devrais le contacter."

Ce processus peut prendre un jour ou deux. Mais sachez que c'est un investissement. Vous pourrez utiliser ce tableau pour le reste de votre carrière.

Vous vous dites peut-être "je n'ai pas besoin de faire ça – j'ai déjà un compte LinkedIn." Cela peut fonctionner, mais LinkedIn est un instrument brut. Vous voulez maximiser le signal et minimiser le bruit ici. C'est pourquoi je vous encourage à créer ce tableau de réseau personnel dédié.

Au fur et à mesure que vous ajoutez des personnes à votre tableau, vous pouvez les étiqueter. Prenez un moment pour faire des recherches sur chacune de ces personnes. Que font-elles ces jours-ci ? Ont-elles un emploi ? Dirigent-elles une entreprise ?

Vous pouvez ajouter des notes à chaque carte, au fur et à mesure que vous découvrez de nouveaux faits à leur sujet. Ont-elles récemment participé à une course de 5 km pour une œuvre de charité ? Leur grand-mère a-t-elle récemment fêté ses 90 ans ? Ces faits peuvent sembler superflus. Mais si la personne les partage sur les réseaux sociaux, cela signifie que ces faits sont importants pour elle.

Faites un effort pour vous intéresser aux gens. À leur vie quotidienne. À leurs aspirations. En comprenant leurs motivations et leurs objectifs, vous aurez une vision plus profonde de la façon dont vous pouvez les aider.

Et comme je l'ai dit plus tôt, la meilleure façon de forger des alliances est d'aider les gens. Nous en reparlerons longuement dans un instant.

Pour chacune des personnes que vous ajoutez à votre tableau de réseau personnel, demandez-vous si elle vaut la peine d'être contactée. Ensuite, placez-la soit dans la colonne "à contacter", soit dans la colonne "ne pas contacter pour l'instant".

Vous vous demandez peut-être : pourquoi la colonne s'appelle-t-elle "ne pas contacter pour l'instant" ? Parce qu'on ne sait jamais quand il peut être utile de connaître quelqu'un. Ne prenez jamais aucune amitié ou connaissance pour acquise.

Une fois que vous avez rempli votre tableau, étiqueté tout le monde et trié les gens dans les colonnes, vous êtes prêt à commencer à prendre contact.

Comment se préparer à la prise de contact réseau

La chose principale à garder à l'esprit lors de la prise de contact et de la tentative de faire une impression : restez simple.

Les gens sont occupés, et ils ne peuvent se souvenir que d'un nombre limité de faits vous concernant. Vous voulez condenser qui vous êtes à l'essentiel. Et la meilleure façon de le faire est d'écrire une biographie personnelle.

Comment écrire une biographie personnelle pour les réseaux sociaux

Vous voulez que votre présence soit cohérente sur tous vos comptes de réseaux sociaux.

Voici comment je me présente :

"Je suis Quincy. Je suis enseignant chez freeCodeCamp. J'habite à Dallas, au Texas. Je peux vous aider à apprendre à coder."

Allez-y, écrivez la vôtre. Essayez de la faire tenir en 100 caractères ou moins. Essayez d'éviter d'utiliser des mots compliqués ou du jargon.

Il peut être difficile de distiller votre identité en quelques mots. Mais c'est un processus important.

Rappelez-vous : les gens sont occupés. Ils n'ont pas besoin de connaître l'histoire de votre vie. Au fur et à mesure que vous apprendrez à mieux connaître ces personnes, vous pourrez progressivement remplir les détails de qui vous êtes en tant que personne. À mesure qu'ils posent des questions, ils pourront mieux vous connaître au fil du temps.

Et sur cette note, vous avez besoin d'une bonne photo de votre visage souriant.

Comment faire une photo de profil pour les réseaux sociaux

Si vous en avez les moyens, trouvez simplement un photographe local et payez-le pour prendre des portraits professionnels.

Vous avez peut-être même un ami passionné de photographie qui peut les prendre gratuitement.

J'ai pris ma photo moi-même, en utilisant Photobooth, qui est préinstallé sur MacOS. Mon ami a passé environ 10 minutes à corriger l'arrière-plan et l'ombrage dans Photoshop. Il a peut-être rendu mes dents légèrement plus blanches. Voici à quoi elle ressemble :

Ma photo de profil. J'utilise la même photo partout.

Assurez-vous de sourire avec les yeux, pour ne pas avoir l'air d'un robot. Ou mieux encore, pensez à quelque chose de vraiment drôle, comme je l'ai fait ici. Le sourire sera alors authentique.

Prenez beaucoup de clichés sous différents angles, et utilisez simplement celui qui vous met le plus en valeur.

Je recommande d'utiliser une photo qui ressemble à ce que vous êtes n'importe quel jour donné. Pas une photo lourdement retouchée qui essaie de maximiser votre attractivité. Vous voulez que les gens lors d'événements vous reconnaissent grâce à votre photo. Et vous ne voulez pas intimider les gens par votre beauté. Vous voulez les mettre à l'aise.

En parlant de mettre les gens à l'aise : ne portez pas de lunettes de soleil, et n'essayez pas trop d'avoir l'air cool. Vous voulez paraître amical et abordable. Un bon test pour cela est : regardez votre photo. Si vous étiez perdu et que vous voyiez cette personne dans la rue, auriez-vous le courage de lui demander votre chemin ?

Une fois que vous avez choisi votre photo de profil, utilisez la même partout. Mettez-la sur tous vos comptes de réseaux sociaux.

Utilisez-la sur votre site personnel. Ajoutez même la photo de profil à votre compte de messagerie.

Je recommande d'utiliser cette même photo pendant des années. Chaque fois que vous la changez, vous risquez que certaines personnes ne vous reconnaissent pas immédiatement. Même des changements subtils d'éclairage, d'angle ou d'arrière-plan peuvent perturber la familiarité des gens.

Assurez-vous de garder une version haute définition de la photo. De cette façon, les gens pourront l'utiliser pour promouvoir votre conférence ou votre apparition en tant qu'invité dans leur podcast. (Ne vous inquiétez pas – avec le temps, vous y arriverez.)

Comment contacter des personnes de votre passé

Maintenant que vous avez votre bio et vos photos, vous êtes prêt à commencer à parler aux gens.

Il y a 15 ans, je dirais que vous devriez appeler les gens au téléphone plutôt que de leur envoyer des messages. Mais la culture a beaucoup changé avec l'introduction des smartphones. La plupart des gens ne réagiront pas bien à un appel téléphonique.

De même, je ne recommande pas de proposer aux gens d'aller prendre un café ou de déjeuner avant d'avoir bien avancé dans la conversation. Les gens sont occupés et peuvent percevoir la demande comme maladroite.

Vous devez aller droit au but, et le faire rapidement.

Alors, quel est ce point sur lequel vous devez insister ?

Essentiellement :

1. Je vous connais
2. Je vous apprécie
3. et je respecte le travail que vous faites.

C'est tout.

Les gens aiment être connus. Ils aiment être appréciés. Ils aiment que le travail qu'ils font et la vie qu'ils mènent soient remarqués.

La plupart d'entre nous reçoivent de la reconnaissance le jour de notre anniversaire. Des gens de notre passé peuvent nous envoyer des SMS de "joyeux anniversaire", des messages sur les réseaux sociaux, ou même nous appeler.

Mais qu'en est-il des 364 autres jours de l'année ? Les gens aiment être reconnus ces jours-là aussi.

Eh bien, voici un moyen simple de reconnaître les gens.

Étape 1 : Faites des recherches sur la personne. Cherchez-la sur Google. Lisez ses publications les plus récentes sur les réseaux sociaux. Lisez son LinkedIn. S'il publie des photos de famille, prenez vraiment le temps de les regarder.

Étape 2 : Pensez à quelque chose que vous pourriez dire qui pourrait rendre sa journée un peu plus lumineuse.

Étape 3 : Choisissez une plateforme de médias sociaux sur laquelle il a été récemment actif. Envoyez-lui un message direct.

Je vais partager un modèle, mais n'utilisez jamais de modèles textuellement, car si le destinataire tape votre message dans Google, il découvrira que c'est un modèle, et toute votre bonne volonté sera gâchée.

Si j'envoyais un message à quelqu'un à qui je n'avais pas parlé depuis quelques mois ou années sans prévenir, je dirais quelque chose comme ceci :

"Salut [nom], j'espère que ton [nouvel an / printemps / semaine] commence bien. Félicitations pour [nouvel emploi / promotion / nouveau bébé / projet terminé]. C'est inspirant de te voir accomplir tout ça."

Quelque chose de court et direct comme ça. Salutation + félicitations + compliment. C'est la formule de base.

Ne vous contentez pas de le dire. Pensez-le.

Voulez-vous vraiment que cette personne se sente reconnue. Voulez-vous vraiment égayer sa journée. Voulez-vous vraiment l'encourager à continuer à progresser vers ses objectifs.

Les humains sont très doués pour détecter l'insincérité. N'essayez pas d'en faire trop. Ne leur donnez aucune raison de penser "cette personne veut quelque chose de moi."

C'est pourquoi la chose la plus importante à ce sujet est : soyez bref. Respectez le temps des gens. Personne ne veut d'une longue lettre à laquelle il se sentira obligé de répondre longuement.

Parce que – dites-le avec moi encore une fois – les gens sont occupés.

Comment construire des connexions encore plus profondes

Parce que les gens sont si occupés, ils sont souvent tentés de voir les étrangers davantage pour ce que ces étrangers peuvent faire pour eux :

• Cette personne conduit le bus qui m'emmène au travail.
• Cette personne prépare ma boisson exactement comme je l'aime.
• Cette personne aux RH répond à mes questions sur les congés.
• Cette personne a concocté une playlist acid jazz géniale que j'écoute pendant que je code.
• Cette personne m'envoie des e-mails utiles chaque semaine avec des ressources de codage gratuites.

Dans une certaine mesure, vous êtes ce que vous faites pour les gens.

Je sais, je sais. Cela peut sembler excessivement réducteur. Cynique même. Et ce n'est absolument pas vrai pour les amis proches et la famille dans votre vie.

Mais pour les gens qui vous connaissent à peine – qui vous croisent simplement au cours de leur journée – c'est probablement ainsi qu'ils vous voient.

Vous devez donner aux gens une raison de s'intéresser à vous. Vous devez leur donner envie d'en savoir plus sur vous.

Avant de pouvoir devenir l'ami proche de quelqu'un – quelqu'un dont il se soucie vraiment et à qui il pense quand vous n'êtes pas là – vous devez commencer par être quelqu'un qui lui est utile.

Et c'est ce que nous allons faire ici. Nous allons construire des relations encore plus profondes en proposant d'aider les gens.

Ce sera un long processus. Et vous devriez le commencer bien avant votre recherche d'emploi. La dernière chose que vous voulez, c'est que quelqu'un pense "Oh – tu me contactes juste parce que tu as besoin de quelque chose de moi."

Au contraire – vous le contactez parce que vous avez quelque chose à lui offrir.

Vous êtes, après tout, en possession de l'un des ensembles de compétences les plus puissants qu'une personne puisse acquérir. La capacité de plier les machines à votre volonté. Vous êtes un programmeur.

C'est ce que l'on ressent quand on est bon en codage.

Ou, du moins, vous êtes sur la voie de le devenir.

Vous avez donc déjà un bon prétexte pour contacter les gens.

Vous avez peut-être entendu le terme "appel à froid" (cold call). C'est quand vous appelez quelqu'un en ne sachant presque rien de lui, et en essayant de lui vendre quelque chose. Ce n'est pas facile, et une vaste majorité des appels à froid se terminent par un raccrochage de l'autre partie.

Mais plus vous en savez sur l'autre personne, plus l'appel devient "chaud", et plus vous avez de chances de réussir.

Maintenant, vous ne vendez rien ici. Et comme je l'ai mentionné plus tôt, vous ne les appelez pas non plus. Vous leur envoyez un message direct.

C'est peut-être via Twitter, LinkedIn, Discord, Reddit – peu importe. Mais vous les contactez avec un seul paragraphe de texte.

Comme je l'ai dit, l'approche la plus forte – celle qui a le plus de chances d'obtenir une réponse – est de proposer nonchalamment son aide.

Si je faisais cela, voici un modèle simple que j'utiliserais. N'oubliez pas de ne pas utiliser ce modèle textuellement. Réécrivez-le avec votre propre voix, comme vous le diriez à un ami :

"Salut [nom], félicitations pour [le nouvel emploi / la promotion / le nouveau bébé]. J'ai appris la programmation et je suis en train de construire mon portfolio. Tu m'es immédiatement venu à l'esprit comme quelqu'un qui accomplit beaucoup de choses. Y a-t-il un type d'outil ou d'application qui te faciliterait la vie ? Je pourrais peut-être le coder pour toi, pour m'entraîner."

C'est une approche forte, car elle est personnalisée et ne semble pas automatisée. Les gens reçoivent tellement de messages automatisés de nos jours qu'ils ignorent rapidement tout ce qui ressemble de près ou de loin à un message automatique.

C'est pourquoi j'envoie tous mes messages manuellement, et je ne compte pas sur l'automatisation. Il vaut mieux composer lentement les messages un par un que d'essayer de gagner du temps avec un script ou un publipostage.

Le moyen le plus rapide de se faire bloquer est d'envoyer un message à quelqu'un avec "Salut , comment ça va ?" où il manque manifestement un prénom – preuve que le message est un modèle.

Parfois, je reçois un message utilisant mon nom de famille au lieu de mon prénom. "Salut Larson." Quoi, je suis à l'école militaire maintenant ?

Et beaucoup de gens sur LinkedIn ont commencé à mettre un emoji au début de leur nom. Cela permet de détecter facilement les messages automatisés, car personne n'inclurait cet emoji dans son message direct.

Quand un message commence par : "Salut 🍜Sarah, cherchez-vous un nouvel emploi ?" Alors vous savez que c'est un message groupé.

Notez également que mon modèle ci-dessus ne dit pas "nous sommes allés à l'école ensemble" ou quelque chose comme ça. À moins que vous ne veniez de rencontrer quelqu'un il y a quelques jours, vous ne devriez pas préciser comment vous vous connaissez.

Pourquoi ? Parce que le fait même de rappeler aux gens comment vous vous connaissez incitera certaines personnes à prendre du recul et à se dire : "Tiens, je connais à peine cette personne."

Comment entretenir la conversation

Encore une fois, votre objectif est d'obtenir une réponse de leur part, afin de pouvoir entamer une conversation d'allers-retours.

Ces plateformes de messagerie ont un côté informel. Restez informel.

N'envoyez pas un seul message de plusieurs paragraphes. Faites des messages courts et percutants. Vous ne voulez pas que ce soit une corvée de vous répondre.

Une fois que vous avez obtenu une réponse, commencez à prendre des notes sur votre tableau de réseau personnel afin de vous souvenir de ces faits plus tard.

Peut-être qu'ils ont une idée d'application ou d'outil. Génial. Posez-leur des questions à ce sujet. Voyez si vous pouvez le construire pour eux.

Commencez par esquisser une maquette simple de l'interface utilisateur. Utilisez du papier millimétré si vous voulez avoir l'air particulièrement sophistiqué. Prenez-en une photo et envoyez-leur. "Quelque chose comme ça ?"

Cela prouvera que vous êtes sérieux dans votre volonté de les aider. Et je parierais que pour la plupart des gens, ce serait une expérience nouvelle.

"Tu m'aides ? Tu crées cette application pour moi ?" Ce sera flatteur, et ils s'en souviendront probablement. Même si l'application elle-même ne mène nulle part.

À partir de là, vous pouvez simplement suivre le fil de la conversation. Peut-être qu'elle s'essouffle. Pas de souci. Laissez faire. Vous pourrez trouver une raison de reprendre la conversation quelques semaines plus tard.

L'avantage de ces messages directs sur les réseaux sociaux est que tout l'historique des messages est là. La prochaine fois que vous leur enverrez un message, ils pourront simplement faire défiler vers le haut et voir "oh – c'est cette personne qui a proposé de construire cette application pour moi." Il n'y a plus de "c'est qui déjà ?" gênants comme on peut en avoir lors de conversations en personne.

Encore une fois, gardez tout informel et positif. Si vous avez l'impression que la conversation avance lentement, ce n'est pas un problème. Parce que vous allez avoir des dizaines d'autres conversations en cours. D'autres fers au feu. Vous allez être une abeille occupée à construire votre réseau.

Comment rencontrer de nouvelles personnes et élargir votre réseau personnel

Nous avons parlé de la façon de contacter des personnes que vous connaissez déjà. Ces connexions sont toujours là, même si elles se sont un peu atrophiées au fil des ans.

Mais comment établir de toutes nouvelles connexions ?

Ce n'est pas une tâche facile. Mais j'ai quelques conseils qui rendront ce processus un peu moins intimidant.

Tout d'abord, rencontrer des gens pour la première fois en personne est tellement plus puissant que de les rencontrer en ligne.

Lorsque vous rencontrez quelqu'un en personne, votre mémoire a tellement plus d'informations auxquelles se raccrocher :

• L'apparence de la personne, sa posture et sa façon de se déplacer dans l'espace
• Le son de sa voix et sa façon de parler
• Les lumières, les sons, les arômes, la température et l'ambiance générale du lieu
• Et tant d'autres petits détails qui s'ancrent dans votre mémoire

Passer 10 minutes à discuter avec quelqu'un en personne peut créer un lien plus profond que des dizaines de messages échangés sur des semaines de correspondance.

C'est pourquoi je recommande vivement : sortez et rencontrez des gens lors d'événements locaux.

Comment rencontrer des gens lors d'événements locaux en ville

Quels événements ? Si vous vivez dans une ville densément peuplée, vous avez peut-être une tonne d'options à votre disposition. Vous pourrez peut-être aller à des événements tech plusieurs soirs par semaine, avec un minimum de trajet.

Si vous vivez dans une petite ville, vous devrez peut-être vous contenter de rencontrer des gens lors de rassemblements locaux. Salons du livre, fêtes de quartier, événements sportifs.

Si vous allez à l'église, à la mosquée ou au temple, apprenez aussi à connaître les gens là-bas.

Et oui, je sais que cela peut paraître ridicule. "Cette personne debout à côté de moi dans les gradins au match de foot ? Elle va m'aider d'une manière ou d'une autre à obtenir un emploi de développeur ?"

Peut-être. Peut-être pas. Mais ne sous-estimez personne.

Cette personne dirige peut-être une petite entreprise.

Elle est peut-être allée à l'école avec un ami qui est vice-président de l'ingénierie dans une entreprise du Fortune 500.

Et peut-être – juste peut-être – qu'elle est aussi ingénieur logiciel. Après tout, nous sommes des millions d'ingénieurs logiciels dans le monde. Et nous ne vivons pas tous dans la Silicon Valley. 😉

Lorsque vous rencontrez une nouvelle personne, vous ne voulez pas sortir immédiatement votre téléphone et dire "Puis-je vous ajouter à mon réseau professionnel LinkedIn ?"

Au lieu de cela, jouez-la cool. Présentez-vous.

Retenez leur nom. Les noms sont essentiels pour construire une relation. Si vous avez du mal avec les noms, entraînez-vous à les retenir. Vous pouvez vous exercer en essayant de retenir le nom de chaque personnage – même mineur – lorsque vous regardez des séries télévisées ou des films.

Si vous oubliez le nom de quelqu'un, ne devinez pas. Dites simplement "quel est ton nom déjà" et assurez-vous de le retenir la deuxième fois.

Serrez-leur la main ou faites un "fist bump". Parlez avec eux de ce qui vous semble naturel. Si la conversation s'essouffle, pas de souci. Laissez-la s'arrêter.

On construit des relations au fil du temps. Ce n'est pas une question de temps total passé avec quelqu'un – c'est une question du nombre de fois où vous rencontrez cette personne sur une longue période.

Il y a de fortes chances que vous revoyiez la personne à l'avenir. Peut-être au même endroit quelques semaines plus tard. Et c'est là que vous passez à l'action :

"Salut [nom], comment se passe [la chose dont vous avez parlé la fois précédente] ?"

Reprenez la conversation là où elle s'était arrêtée. S'ils semblent être quelqu'un qui serait un ajout utile à votre tableau de réseau personnel, demandez-leur "hé, qu'est-ce que tu fais [jour de la semaine] prochain ? Tu veux venir avec moi à [autre événement local à venir] ?"

Ayez toujours en tête votre semaine d'événements à venir, afin de pouvoir inviter les gens à vous rejoindre.

C'est un excellent moyen d'amener les gens à passer du temps avec vous dans un espace public et sûr. Et vous apportez quelque chose de valeur – en les informant d'un événement à venir.

S'ils semblent intéressés, vous pouvez dire "Génial. Quel est le meilleur moyen pour moi de te contacter et de te donner les détails de l'événement ?"

Boum – vous avez maintenant leur e-mail, leur réseau social ou leur numéro de téléphone, et votre relation peut se développer à partir de là.

Cela peut sembler être une approche lente. Pourquoi être si prudent ?

Encore une fois, les gens sont occupés. Les gens intelligents protègent leur temps et leurs informations personnelles.

Il y a trop de vampires qui veulent profiter des gens – en essayant de leur vendre quelque chose, de les arnaquer, de les faire entrer dans leur système de vente pyramidale, ou de faire du prosélytisme d'une manière ou d'une autre.

Le meilleur moyen d'aider les autres à surmonter cette méfiance réflexe est d'être déjà sur leur radar lors de rencontres précédentes comme une personne raisonnable.

Comment exploiter votre réseau

Nous parlerons davantage de la façon d'exploiter votre réseau au Chapitre 4. Pour l'instant, considérez votre réseau purement comme un investissement de temps et d'énergie.

J'aime penser à mon réseau comme à un verger. Je plante des relations. Je m'en occupe et je m'assure qu'elles sont en bonne santé.

Qui sait quand ces relations deviendront des arbres et porteront des fruits. L'objectif est de continuer à planter des arbres, et à un moment donné dans le futur, ces arbres vous aideront à subvenir à vos besoins.

Continuez à envoyer de l'énergie positive. Continuez à proposer d'aider les gens en utilisant vos compétences, et même votre propre réseau. (Il est rarement mauvais de faire une présentation polie entre deux personnes que vous connaissez.)

Soyez une personne gentille, attentionnée et serviable.

Ne vous sentez jamais impatient face à la lenteur d'une recherche d'emploi.

Ne vous sentez jamais offensé ou snobé.

Ne vous sentez jamais jaloux du succès de quelqu'un d'autre.

On récolte ce que l'on sème. Vous récolterez un jour ce que vous avez semé. Et si vous semez de l'énergie positive, vous vous préparez à une récolte abondante.

Chapitre 3 : Comment construire votre réputation

"La façon de gagner une bonne réputation est de s'efforcer d'être ce que l'on désire paraître." – Socrate

Maintenant que vous avez commencé à développer vos compétences et votre réseau, vous êtes prêt à commencer à construire votre réputation.

Vous partez peut-être de zéro – un total nouveau venu dans la tech. Ou vous avez peut-être déjà une certaine crédibilité que vous pouvez apporter de votre autre emploi.

Dans ce chapitre, je partagerai des conseils pratiques sur la façon dont vous pouvez vous forger une réputation d'excellence parmi vos pairs. Ce sera la clé pour obtenir des clients freelance, un premier emploi et progresser dans votre carrière.

Mais d'abord, voici comment j'ai construit ma réputation.

L'heure de l'histoire : comment un enseignant dans la trentaine s'est-il forgé une réputation de développeur ?

La dernière fois dans l'Heure de l'histoire : Quincy a commencé à construire son réseau de développeurs, d'entrepreneurs et de responsables du recrutement dans la tech. Il fréquentait les hackerspaces et les événements tech de la ville. Mais il n'était pas encore monté dans l'arène pour tester sa force...

J'étais déjà à plusieurs mois de mon parcours de codage quand j'ai enfin trouvé le courage d'aller à mon premier hackathon.

Un jour, j'ai rencontré un bug particulièrement coriace, et je ne savais pas comment le corriger. J'ai donc fait ce que beaucoup de gens feraient dans cette situation : j'ai procrastiné en naviguant sur le web. Et c'est là que je l'ai vu. Startup Weekend EDU.

Un Startup Weekend est une compétition de 54 heures qui consiste à construire une application, puis à la présenter à un panel de juges. Ces événements récompensent vos connaissances en codage, en design et en entrepreneuriat également.

Cet événement particulier – organisé au cœur de la Silicon Valley – avait un panel d'éducateurs et d'entrepreneurs de l'éducation comme juges. Avec mon expérience dans l'éducation des adultes, cela semblait être un premier hackathon idéal pour moi.

J'en ai parlé à Steve. Et puis j'ai dit les mots magiques : "C'est moi qui conduis." Ce qui était une bonne chose, car Steve n'avait pas de permis de conduire.

Avec Steve à bord, nous avons complété notre équipe avec quelques développeurs du Santa Barbara Hackerspace.

J'ai passé des semaines à préparer l'événement en faisant des recherches sur les juges et les entreprises pour lesquelles ils travaillaient. J'ai fait des recherches sur les sponsors. Et bien sûr, j'ai pratiqué le code comme un moine Shaolin.

Enfin, après un mois de préparation, c'était le grand week-end. Nous nous sommes entassés dans ma Toyota Corolla 2003 au vernis écaillé, avons mis de la musique énergique et avons commencé notre trajet de 5 heures.

En montant, nous avons discuté de ce que nous devrions construire. Ce serait axé sur l'éducation, bien sûr. De préférence pour les lycéens, car c'étaient les niveaux scolaires sur lesquels se concentraient les entreprises des juges.

Mais que devait faire l'application ? Comment allait-elle faciliter la vie des gens ?

J'ai repensé à ma propre époque au lycée. Je n'avais pas grand-chose sur quoi m'appuyer, car j'avais abandonné après seulement un an. (J'ai réussi à étudier et à obtenir le GED – le diplôme d'équivalence – tout en travaillant chez Taco Bell, avant d'aller finalement à l'université. Mais c'est une autre histoire.)

Mais un point de douleur dont je me souvenais du lycée, et qui résonnait encore après toutes ces années : les dissertations d'anglais.

J'adorais écrire. Mais je n'aimais pas écrire au format MLA, avec ses règles de citation rigides. Je redoutais de préparer une page de bibliographie (Works Cited). Mon professeur me retirait toujours des points parce que je ne formatais pas mes citations correctement.

Après avoir écouté beaucoup d'idées moyennes des autres passagers de la voiture, j'ai pris la parole. J'ai dit : "J'ai une idée. On devrait coder une application qui crée les citations pour vous."

Et quelqu'un a ri et a dit : "C'est génial." (Out of sight).

Et Steve a dit : "Hé, c'est un bon nom. On pourrait l'appeler Out of Cite avec un 'C'."

Nous avons tous ri et nous nous sommes sentis malins. Puis nous avons commencé à discuter des détails de mise en œuvre.

Quand nous sommes arrivés sur les lieux, il y avait environ 100 autres développeurs. C'était un espace de bureaux en open-space, avec des box bas flanqués de tableaux blancs.

J'ai entendu des murmures à propos de l'un de ces développeurs. "Hé, c'est le gars qui a gagné l'événement l'année dernière," j'entendais les gens dire. Ils faisaient un geste vers un développeur à l'air arrogant entouré de fans. "Peut-être qu'il me laissera faire partie de son équipe."

L'événement a commencé par des pitchs. N'importe qui pouvait aller à l'avant de la salle, prendre le micro et faire un pitch de 60 secondes pour l'application qu'il voulait construire.

J'étais tellement nerveux que j'avais l'impression qu'un alien allait sortir de ma poitrine. Alors naturellement, j'étais le premier dans la file. On arrache le pansement d'un coup, n'est-ce pas ?

Je transpirais et je gesticulais follement pendant que je débitais mon pitch. J'ai dit quelque chose comme ça : "Les citations, c'est nul. Enfin, ce n'est pas nul. C'est nécessaire. Et vous devez les ajouter à vos devoirs. Mais préparer les citations, c'est nul. Construisons une application qui remplira votre page de bibliographie pour vous. Qui est avec moi ?"

La salle était silencieuse. Puis les gens ont réalisé que j'avais fini de parler, et ils m'ont applaudi poliment. Le MC m'a pris le micro des mains et l'a donné à la personne suivante, et je suis retourné à ma place en sautillant.

Après les pitchs, il était temps de former des équipes. Notre contingent de Santa Barbara s'est regardé et a dit : "Je suppose qu'on est une équipe."

Nous avons trouvé le mot de passe wifi et avons pris le meilleur des espaces de travail : un bureau d'angle qui avait une porte qu'on pouvait vraiment fermer.

J'ai commencé à gribouiller des maquettes d'interface utilisateur sur le tableau blanc. J'ai dit : "Nous voulons quelque chose qui soit toujours à portée de clic. Directement dans la barre de menu du navigateur."

"Comme une extension de navigateur," a dit Steve.

"Ouais. Construisons une extension de navigateur."

Je leur ai montré des exemples des trois formats que les dissertations pouvaient exiger : MLA, APA et Chicago.

"Est-ce qu'on pourrait générer les trois à la fois, pour qu'ils n'aient qu'à faire un copier-coller ?" ai-je demandé.

"On peut faire mieux que ça," a dit Steve. "On peut avoir un bouton pour chacun d'eux qui met la citation directement dans leur presse-papiers."

Nous avons travaillé vite, créant un simple MVP (Minimum Viable Product) dès le vendredi soir. Tout ce qu'il faisait, c'était récupérer les métadonnées du site web actuel et les structurer comme une citation. Mais ça marchait.

Comme c'était mon premier hackathon, je ne voulais pas avoir le stress de loger dans une auberge de jeunesse. J'avais donc fait des folies pour prendre une chambre d'hôtel. Nous avions deux lits jumeaux, donc chaque soir nous faisions un roulement pour savoir lequel d'entre nous devait dormir par terre.

Samedi matin, nos ambitions ont grandi. Je suis allé au tableau blanc et j'ai dit à l'équipe : "Citer des sites web, c'est bien beau. Mais beaucoup de choses que les étudiants citent se trouvent dans des livres ou des articles académiques. Nous devons pouvoir générer des citations pour ceux-là aussi."

Nous avons trouvé une API que nous pouvions utiliser pour obtenir des informations de citation basées sur l'ISBN (un numéro de série utilisé pour les livres). Et nous avons bricolé un script capable de rechercher des articles académiques basés sur leur DOI (un numéro de série utilisé pour les articles académiques), puis de scraper les données de la page de résultat.

Samedi soir, le code de notre extension de navigateur commençait vraiment à prendre forme. Je me suis donc assis et j'ai commencé à préparer les diapositives de la présentation. J'ai laissé une grande partie du codage final à mes coéquipiers pendant que je répétais mon pitch encore et encore pendant des heures.

Même si c'était mon tour de dormir dans un lit, je n'ai presque pas pu fermer l'œil à cause de la nervosité. J'étais là, en plein cœur de l'écosystème tech. La Silicon Valley.

En tant qu'enseignant, je donnais régulièrement des conférences devant mes pairs – parfois des dizaines. Mais là, c'était différent.

Dans quelques heures, je présenterais devant une salle remplie de développeurs ambitieux. Et des juges. Des gens avec des doctorats, dont certains avaient fondé leurs propres entreprises tech. Ils allaient évaluer notre travail. J'étais terrifié à l'idée de tout gâcher.

Incapable de dormir, j'ai ouvert mes e-mails. L'équipe du Startup Weekend avait envoyé un e-mail, qui comprenait un PDF d'un livre. C'était un mash-up non officiel des classiques des startups tech 4 Steps to the Epiphany et The Lean Startup.

Maintenant, j'avais déjà lu ces livres, car ils étaient une lecture obligatoire pour quiconque voulait construire des produits logiciels au début des années 2010. Mais j'avais aussi lu des dizaines d'autres livres sur les startups. Et beaucoup de leurs idées se mélangeaient dans un brouillard de conseils.

Il était 4 heures du matin, et je ne pouvais pas dormir. Alors j'ai commencé à lire. Une chose que ces livres soulignent vraiment, c'est de construire quelque chose pour lequel les gens paieront. La forme ultime de validation client.

C'est là que j'ai réalisé : vous savez ce qui pousserait vraiment ma présentation vers la ligne d'arrivée ? Une preuve de "product-market fit". La preuve que l'application que nous construisions résolvait un vrai problème que les gens avaient. À tel point qu'ils sortiraient leur portefeuille.

Cela m'a donné une idée. Je devrais aller sur le terrain avec notre application et la vendre à des gens.

Mais c'était dimanche matin. Où allais-je trouver des clients potentiels ? Eh bien, notre hôtel se trouvait justement près du campus principal de l'Université de Stanford.

J'ai conduit mon équipe sur le lieu de l'événement, je leur ai fait un signe d'adieu et j'ai dit : "Je reviendrai quand j'aurai de l'argent liquide sonnant et trébuchant de la part des clients."

Mes coéquipiers ont ri. Je ne suis pas sûr qu'ils pensaient que j'étais sérieux. Ils ont dit : "Ne sois pas en retard pour le pitch."

Mais j'étais sérieux. J'avais un prototype de l'application qui tournait sur mon ordinateur portable. J'ai tapé Stanford dans mon GPS et je me suis lancé dans ma mission.

Maintenant, j'ai étudié dans une université d'État vraiment bon marché en Oklahoma. Je me sentais donc vraiment hors de mon élément quand je suis arrivé dans l'une des meilleures universités du monde.

Stanford coûte 50 000 $ par an. Et je me suis garé sur leur parking au volant d'une voiture qui valait un dixième de cela.

Le campus était une ville fantôme à ce moment-là de la semaine. Mais une ville fantôme palatiale, néanmoins. Des statues de bronze. Des arches emblématiques partout.

Je me suis demandé : où sont les étudiants les plus performants, les plus acharnés, à cette heure de la journée ? Ceux qui n'ont pas de temps à perdre à créer manuellement leurs pages de bibliographie ?

Je suis entré dans la bibliothèque principale, juste devant le bureau de sécurité et un panneau qui disait "pas de démarchage".

J'ai déambulé dans les rayons, trouvant une petite poignée de personnes en train d'étudier. Ce gamin prenait studieusement des notes en lisant un épais manuel. Bingo.

Je me suis glissé sur le siège à côté de lui. "Psst. Hé. Tu aimes les citations ?"

"Quoi ?"

"Les citations. Tu sais, genre, les pages de bibliographie."

"Euh..."

"Tu sais, la dernière page de ton devoir, où tu dois lister tous les..."

"Je sais ce qu'est une page de bibliographie."

"D'accord. Eh bien, regarde ça." J'ai tiré ma veste sur le côté comme un dealer, et j'ai sorti mon netbook à 200 $. Il m'a écouté un moment pendant que je débitais mon pitch de vente maladroit.

J'ai dit : "Tiens. J'ai cette extension de navigateur. Je vais sur n'importe quel site web, je clique sur le bouton, et voilà. Ça crée une citation pour moi."

Le gamin a haussé les sourcils. "Est-ce que ça peut faire du MLA ?"

J'ai contenu mon excitation et j'ai dit : "MLA, APA et même Chicago. Regarde." J'ai cliqué sur le bouton et trois citations sont apparues – chacune avec son propre bouton de copie dans le presse-papiers.

Le gamin a hoché la tête, semblant assez impressionné. J'ai donc tenté de conclure la vente.

"Et si je te disais que je m'apprête à lancer cette application avec un abonnement annuel. Mais si tu t'inscris maintenant, je te donnerai un accès illimité non pas pour un an, mais à vie."

Le gamin a réfléchi un instant.

J'avais entendu dire que le silence était le meilleur ami du vendeur. Je suis donc resté assis là pendant un temps inconfortablement long dans un silence total, en le fixant.

Finalement, il a dit : "Cool, j'en suis."

"Génial. Ça fera vingt dollars."

Le gamin a reculé. "Quoi ? C'est cher."

C'était bien sûr l'époque des startups subventionnées par le capital-risque, où Uber et Lyft perdaient de l'argent sur chaque course dans une course à la part de marché. La réaction du gamin n'était donc pas totalement surprenante.

Mais j'ai réfléchi vite. "Eh bien, combien d'argent liquide as-tu sur toi ?"

Il a fouillé dans son portefeuille, puis a dit : "cinq dollars."

J'ai regardé le billet froissé et j'ai haussé les épaules. "Vendu."

Il a souri, et je lui ai envoyé un e-mail avec les instructions pour l'installer. Puis j'ai dit : "Encore une chose. Prenons une photo ensemble."

J'ai mis mon téléphone en mode selfie. Il a commencé à sourire, et j'ai dit : "Tiens. Tiens le billet de cinq dollars."

J'ai passé une autre heure à pitcher des gens dans la bibliothèque, et j'ai réussi à obtenir un autre client payant. Puis je suis retourné en courant sur le lieu de l'événement pour finaliser notre prototype avec l'équipe.

Cet après-midi-là, j'ai fait ce que je pense être encore la meilleure présentation de ma vie. Nous avons fait une démo en direct de l'application – qui a parfaitement fonctionné.

Nous avons terminé la présentation avec les photos que j'avais prises, posant avec des étudiants de Stanford qui étaient maintenant nos clients payants. Quand j'ai brandi l'argent que nous avions gagné, le public a éclaté en applaudissements.

Dans l'ensemble, ce fut l'une des expériences les plus exaltantes de ma vie. Nous sommes arrivés en deuxième position et avons gagné des crédits d'API de l'une des entreprises qui parrainaient l'événement.

À l'after-party, j'ai mangé de la pizza en vitesse pour avoir plus de temps pour réseauter avec tout le monde. Je me suis connecté sur LinkedIn. J'ai suivi sur Twitter. J'ai pris des selfies avec les gens et j'ai utilisé au maximum le hashtag de l'événement.

Ce fut un moment charnière dans mon parcours de codage. J'avais prouvé aux personnes présentes dans cette salle que je pouvais aider à concevoir, coder et même vendre une application. Et plus important encore, je me l'étais prouvé à moi-même.

Sur le circuit des hackathons

À partir de ce moment-là, je suis devenu accro aux hackathons. Cette année-là, j'ai participé à des dizaines d'entre eux. Je suis devenu un guerrier de la route, sillonnant la côte, participant à chaque compétition possible.

Ce serait beaucoup plus difficile à partir de là. Je n'avais plus d'équipe. J'étais seul.

J'arrivais, je rencontrais autant de gens que possible, puis je montais sur scène pour pitcher une idée qui, selon moi, pourrait séduire les juges.

Parfois, des gens rejoignaient mon équipe. Parfois, je rejoignais les équipes d'autres personnes.

Je ne voulais pas seulement concevoir des applications – je voulais aussi les coder. Et mes ambitions dépassaient souvent mes capacités.

Il y a eu de nombreux hackathons où j'essayais encore de corriger des bugs dans les dernières minutes avant de monter sur scène. Parfois, mes applications plantaient pendant les démos en direct.

Lors d'un hackathon à Las Vegas, j'ai réussi à bousiller la base de code si gravement que nous avons dû utiliser un diaporama. J'étais assis dans le public, la tête entre les mains, regardant impuissant mon coéquipier démontrer comment notre application fonctionnerait hypothétiquement – si j'avais pu la faire fonctionner. Nous n'avons pas eu beaucoup de succès auprès des juges.

Mais j'ai continué à m'acharner. J'arrivais dans de nouvelles villes, je m'enregistrais à l'auberge de jeunesse, j'allais sur les lieux et je mangeais autant de pizza gratuite que possible.

Mes équipes étaient arrivées en deuxième ou troisième position tant de fois que je pouvais à peine les compter. Mais nous n'avions jamais réussi à gagner carrément un hackathon.

La percée

C'était jusqu'à un événement à San Diego. Je n'oublierai jamais le sentiment d'avoir construit quelque chose qui a tellement conquis le public et les juges que notre victoire semblait être une conclusion inévitable.

Après l'annonce de notre victoire, je me souviens m'être éclipsé par la porte de derrière vers un parking et avoir appelé mes grands-parents. Je leur ai dit que j'avais enfin réussi. J'avais aidé à construire une application et à élaborer un pitch qui avait gagné un hackathon.

Je ne sais pas ce que mes grands-parents comprenaient du développement logiciel ou des hackathons. Mais ils m'ont dit qu'ils étaient fiers de moi.

Maintenant qu'ils sont partis, je repense souvent à cette conversation. Je chéris leurs encouragements. Leur foi dans le fait qu'un petit-fils enseignant de 30 ans puisse essayer comme un fou et devenir développeur.

J'ai continué à faire des hackathons après cela. J'ai continué à former de nouvelles équipes et à apprendre de nouveaux outils en cours de route. On n'oublie jamais la première fois qu'on fait fonctionner une API. Ou quand on comprend enfin comment fonctionne une commande Git. Et on n'oublie jamais les gens qui se démènent à vos côtés, essayant de faire en sorte que l'application tienne bon pendant la démo.

Le hackathon TechCrunch Disrupt. Le hackathon DeveloperWeek. Le hackathon ProgrammableWeb. Le hackathon Salesforce avec un prix d'un million de dollars. Tant de grands hackathons et tant d'apprentissage. Ce fut le creuset où mes compétences de développeur ont été forgées.

Non seulement j'ai réussi à développer mes compétences et mon réseau en cours de route – mais j'avais maintenant une réputation de quelqu'un capable de gagner un hackathon.

Je pouvais "shipper" (livrer).

Cela faisait de moi une valeur connue.

Et cette réputation a été cruciale pour obtenir mes premiers clients freelance, mon premier emploi de développeur, et surtout – pour faire confiance à mes propres instincts de développeur.

Pourquoi votre réputation est-elle si importante ?

Le rôle de la réputation dans la société remonte très loin dans la préhistoire humaine. Dans la plupart des tribus et des colonies, il y avait un système pour garder trace de qui devait quoi à qui.

Avant l'argent, il y avait le crédit.

Il pouvait s'agir d'un registre écrit. Ou d'un ancien qui gardait simplement tous ces enregistrements dans sa tête.

Au-delà de la comptabilité brute, il y avait aussi une "vibe" moins tangible, mais tout aussi importante, que les gens portaient avec eux.

"Jean sait vraiment comment ferrer un cheval."

Ou "Jeanne est la meilleure conteuse du pays."

Ou "Le courage de Jay au combat nous a sauvés contre les envahisseurs il y a trois hivers."

Vous noterez que ces exemples impliquent tous que quelqu'un soit bon dans quelque chose. Pas seulement qu'il soit une personne gentille et sympathique.

Il est certainement utile d'être une personne détendue et terre-à-terre. Mais nous ne sommes pas dans The Big Lebowski, et nous ne survivrons pas uniquement grâce à notre charme.

The Big Lebowski (à gauche). Il n'avait pas d'emploi, il n'avait pas de compétences, il n'avait pas d'énergie. Mais il était d'un calme olympien.

Il est facile pour un développeur de dire : "Oh ouais. Je connais JavaScript comme ma poche. Je peux vous construire n'importe quel type d'application JavaScript dont vous avez besoin, tournant sur n'importe quel appareil auquel vous pouvez penser."

Ou de dire : "Je livre du code en respectant le budget et en avance sur le calendrier – tout le temps."

Mais comment savoir s'ils n'exagèrent pas leurs affirmations ?

Après tout, un homme sournois a dit un jour :

"Si vous ne pouvez être bon qu'en une seule chose, soyez bon en mensonge.

Alors vous serez bon en tout."

(La véritable origine de cette citation est inconnue. Mais j'aime imaginer qu'elle a été dite par un escroc des années 1920 portant un haut-de-forme et un monocle.)

N'importe qui peut mentir. Et certaines personnes le font.

Plus tôt dans ma carrière, j'ai eu la tâche désagréable de licencier un enseignant qui avait menti sur l'obtention d'un master. Les années ont passé et personne ne s'en est aperçu.

Chaque année, il mentait sur ses documents annuels, afin d'obtenir une augmentation de salaire plus élevée que les autres enseignants. Et chaque année, il s'en sortait.

Mais un jour, une petite anomalie m'a mis la puce à l'oreille. J'ai examiné son dossier, appelé les services d'archives universitaires et découvert qu'il n'avait jamais pris la peine de terminer son diplôme.

Quand je l'ai attrapé, c'était un vrai moment à la Scooby-Doo. "Et j'aurais réussi mon coup, s'il n'y avait pas eu ces maudits gamins."

C'était dur de savoir que cette personne avait enseigné à l'école pendant des années et avait été payée plus que beaucoup d'autres enseignants – juste parce qu'elle était prête à mentir.

Les fruits du mensonge sont toujours là, étincelants. Certaines personnes sont prêtes à céder à cette tentation.

Les employeurs le savent. Ils savent qu'on ne peut pas faire confiance à n'importe quelle personne qui prétend connaître le développement JavaScript full-stack. Il faut être prudent quant à savoir qui reçoit un badge d'entreprise, une adresse e-mail d'entreprise et les clés de vos bases de données de production.

C'est pourquoi les employeurs utilisent des questions d'entretien comportementales – pour essayer de débusquer les personnes plus enclines à la malhonnêteté.

Appelez-moi naïf, mais je crois que la plupart des gens sont intrinsèquement bons. Que la plupart des gens sont prêts à jouer selon les règles tant que ces règles sont raisonnablement équitables.

Mais si même une personne sur dix s'avère être une embauche désastreuse, cela signifie que nous sommes tous soumis à un examen plus approfondi.

Le pire scénario n'est pas seulement quelqu'un qui ment pour gagner plus d'argent. C'est quelqu'un qui vend des secrets d'entreprise, détruit les relations avec les clients ou enfreint les lois au nom du gonflement de ses chiffres.

L'histoire regorge d'employés qui ont causé des dommages catastrophiques à leurs employeurs, tout cela pour leur propre profit personnel.

Ainsi, le processus d'embauche des développeurs dans la plupart des grandes entreprises est paranoïaque au possible. Peut-être devrait-il l'être. Mais malheureusement, cela rend plus difficile pour tout le monde d'obtenir un emploi de développeur – même pour les candidats les plus honnêtes.

En tant que développeurs, nous avons besoin de preuves que nos compétences sont aussi solides que nous le disons. Nous avons besoin de preuves que notre éthique de travail est aussi inébranlable que nos employeurs en ont besoin.

C'est là que la réputation intervient. Elle réduit l'ambiguïté. Elle réduit le risque de contrepartie. Elle rend plus sûr pour les employeurs de faire une offre d'emploi et de signer un contrat de travail avec vous.

Cela signifie que – si vous avez une réputation assez solide – vous pourrez peut-être entrer dans l'entreprise par une porte latérale – plutôt que par la porte d'entrée où les autres candidats font la queue.

Certaines entreprises ont même des recruteurs internes qui peuvent accélérer votre processus d'entretien. Une solide réputation peut également vous aider à avoir plus de pouvoir de négociation lors des discussions salariales.

Parlons donc de la façon dont vous pouvez vous forger une solide réputation et devenir recherché par les managers.

Comment construire votre réputation de développeur

Il existe au moins six façons éprouvées de construire votre réputation de développeur. Ce sont :

1. Les hackathons
2. Contribuer à l'open source
3. Créer du contenu axé sur les développeurs
4. Gravir les échelons en travaillant dans des entreprises qui ont un "nom connu"
5. Se constituer un portfolio de clients freelance
6. Lancer votre propre projet open source, entreprise ou association caritative

Comment trouver des hackathons et d'autres compétitions de développeurs

Les hackathons représentent le moyen le plus immédiat de construire votre réputation, votre réseau et vos compétences en codage en même temps.

La plupart des hackathons sont gratuits et ouverts au public. Vous avez juste besoin d'avoir le temps et le budget pour voyager.

Si vous vivez dans une ville avec beaucoup de hackathons – comme San Francisco, New York, Bengaluru ou Pékin – vous pourrez peut-être vous rendre à l'événement, puis rentrer dormir dans votre propre lit.

Même si je vivais à Santa Barbara, qui n'avait des hackathons que tous les quelques mois, j'avais un ancien camarade de classe à San Francisco qui me laissait dormir sur son canapé. Cela m'a donné accès à beaucoup plus d'événements.

Les hackathons étaient autrefois des événements très rudes. Les gens s'enfilaient des boissons énergisantes et dormaient par terre, tout cela pour finir leur projet avant l'heure du pitch.

Mais les organisateurs de hackathons deviennent progressivement plus attentifs à la santé et à la durabilité de ces événements. Après tout, beaucoup de participants ont des enfants, ou des emplois à plein temps exigeants, et ne peuvent pas coder à fond pendant tout un week-end.

La meilleure façon de trouver les événements à venir est de simplement chercher sur Google "hackathon [nom de votre ville]" et de parcourir les différents calendriers d'événements qui apparaissent dans les résultats de recherche. Beaucoup d'entre eux seront organisés par des universités, des employeurs locaux ou même des associations caritatives axées sur l'éducation.

Si vous jouez pour gagner, je vous recommande de faire vos recherches à l'avance.

Qui sont les sponsors de l'événement ? Il s'agira généralement d'entreprises de type "Business-to-Developer", avec des API, des outils de base de données ou diverses offres de logiciels en tant que service (SaaS).

Ces sponsors auront probablement un stand lors de l'événement où vous pourrez discuter avec leurs évangélistes technologiques (developer advocates). Ce sont des personnes payées pour apprendre aux gens à utiliser les outils de l'entreprise. Parfois, vous rencontrerez même des employés clés ou des fondateurs à ces stands, ce qui peut être une excellente opportunité de réseautage également.

Souvent, le hackathon proposera des prix spécifiques aux sponsors. "Meilleure utilisation de l'API de [sponsor]". Il peut être plus facile de concentrer votre temps sur l'intégration d'outils de sponsors spécifiques dans votre projet, plutôt que d'essayer de gagner le grand prix. Vous pouvez toujours noter ces victoires sur votre LinkedIn ou votre CV. Une victoire est une victoire.

Parfois, le hackathon est si prestigieux – ou le prix est si important – qu'il est logique d'essayer de gagner la compétition purement et simplement.

Pendant que je faisais des hackathons, j'ai pu gagner plusieurs mois de loyer en prix en espèces, plusieurs années d'espace de coworking gratuit, et même une visite privée du bâtiment des Nations Unies à New York.

Sur le circuit des hackathons, j'ai rencontré des gens dont la principale source de revenus était les prix en espèces gagnés lors de hackathons. Un développeur que je connaissais a réussi à gagner neuf prix de sponsors lors du même hackathon. Il a réussi à intégrer tous ces outils de sponsors dans son projet – et a également remporté la deuxième place au classement général.

Ne soyez pas surpris si certaines des personnes que vous croisez fréquemment lors de hackathons finissent par fonder des entreprises financées par le capital-risque, ou lancent des projets open source de premier plan.

Le niveau d'ambition que vous verrez chez les habitués des hackathons est bien plus élevé que celui du développeur moyen. Ce sont, après tout, des gens qui finissent une semaine de travail, puis enchaînent directement sur un week-end de travail. Ces gens n'ont pas peur de sauter de la poêle dans le feu.

Comment contribuer à l'open source

Contribuer à l'open source est l'un des moyens les plus immédiats de construire votre réputation. La plupart des employeurs vont regarder votre profil GitHub, qui affichera bien en vue votre historique de commits Git.

Le profil GitHub de Mrugesh Mohapatra, qui fait énormément de développement de plateforme et de DevOps pour freeCodeCamp.org. Notez à quel point sa barre d'activité est verte. 2 208 contributions au cours de l'année écoulée seulement.

Beaucoup de mainteneurs de projets open source, tels que la Linux Foundation, Mozilla (Firefox), et bien sûr nous-mêmes chez freeCodeCamp, ont des normes élevées en matière de qualité de code.

Vous pouvez parcourir les "issues" GitHub ouvertes pour trouver des bugs connus ou des demandes de fonctionnalités. Ensuite, vous pouvez apporter les modifications au code et ouvrir une "pull request". Si les mainteneurs acceptent votre pull request, ce sera un atout majeur pour vous.

L'un des meilleurs moyens d'obtenir un emploi dans une entreprise tech est de devenir un contributeur open source prolifique à leurs dépôts (repositories).

La contribution open source est un excellent moyen de construire votre réputation car tout ce que vous faites est public. Et vous bénéficiez de la preuve sociale d'avoir d'autres développeurs qui examinent et acceptent votre travail.

Si vous souhaitez construire votre réputation grâce à l'open source, voici comment commencer.

Lisez le guide complet de Hillary Nyakundi sur comment débuter avec l'open source.

Comment créer du contenu axé sur les développeurs

Les développeurs sont des gens. Et comme les autres, ils veulent avoir quelque chose à faire de leur temps lorsqu'ils ne travaillent pas, ne dorment pas ou ne passent pas du temps avec leurs amis et leur famille.

Pour beaucoup de gens – moi y compris – cela signifie passer du temps dans les pensées des autres. Des livres. Des essais vidéo. Des expériences interactives comme les visual novels.

On peut globalement appeler cela du "contenu". Je ne suis pas un grand fan du mot, car il donne l'impression que ces œuvres sont jetables. Mais c'est ainsi que les gens l'appellent.

Le développement logiciel est un domaine incroyablement vaste, avec tant de sujets différents que vous pourriez aborder. Il y a des vlogs sur le style de vie des développeurs, des tutoriels de préparation aux entretiens de codage, des streams de codage en direct sur Twitch, et des podcasts d'interviews de développeurs comme le podcast de freeCodeCamp.

Il y aura probablement des catégories entières de contenu pour développeurs auxquelles nous n'avons même pas encore pensé, qui apparaîtront au cours de la prochaine décennie.

Si vous vous intéressez au cinéma, au journalisme ou à l'écriture créative, le contenu pour développeurs peut être un bon moyen de construire votre réputation.

Vous pouvez choisir un sujet spécifique et devenir progressivement l'expert reconnu.

Il y a des développeurs qui se spécialisent dans les tutoriels pour des piles technologiques (stacks) spécifiques, par exemple.

Mon ami Andrew Brown est un ancien CTO de Toronto qui a réussi tous les principaux examens DevOps. Il crée des cours gratuits pour vous préparer à toutes les certifications AWS, Azure et Google Cloud, et gère également un service de préparation aux examens.

Il y a plus de 30 millions de développeurs de logiciels dans le monde. C'est beaucoup de gens qui consommeront potentiellement votre contenu, et qui finiront par savoir qui vous êtes.

Comment gravir les échelons en travaillant dans de grandes entreprises

Vous avez peut-être vu un développeur présenté comme un "Ex-Googler" ou un "Ex-ingénieur Netflix".

Certaines entreprises tech ont des processus d'embauche si rigoureux – et des normes si élevées – que le simple fait d'obtenir un emploi dans l'entreprise est une grande réussite.

Il y a des raisons pratiques pour lesquelles les employeurs regardent où les candidats ont travaillé précédemment. Cela réduit le risque d'une mauvaise embauche.

Vous pouvez construire votre réputation en gravissant la hiérarchie du prestige. Vous pouvez passer d'un employeur local à une entreprise du Fortune 500, et finalement à l'un des géants de la tech.

Bien sûr, travailler dans une multinationale géante n'est pas fait pour tout le monde. J'en parlerai davantage au Chapitre 4. Mais sachez que c'est une option pour construire votre réputation.

Comment construire votre réputation en vous constituant un portfolio de clients freelance

Vous pouvez construire votre réputation en travaillant avec des entreprises en tant que freelance.

Les développeurs freelance travaillent généralement sur de plus petits projets en solo. Cela peut donc être une meilleure stratégie pour construire votre réputation localement.

Par exemple, si vous avez fait du bon travail pour une banque locale, cela peut suffire à convaincre un cabinet d'avocats local de vous engager également.

Il y a quelque chose à dire sur le fait d'être un "héros local". Je connais de nombreux développeurs qui peuvent rivaliser efficacement avec la concurrence en ligne simplement en étant physiquement présents aux réunions et en connaissant les gens localement.

Comment construire un portfolio de développeur de votre travail

Une fois que vous avez construit quelques projets, vous voudrez les montrer. Et la meilleure façon de le faire est d'utiliser de courtes vidéos.

Les gens sont occupés. Ils n'ont pas le temps de télécharger votre code et de le faire tourner sur leur propre ordinateur.

Et si vous envoyez les gens sur un site web, ils ne comprendront peut-être pas pleinement ce qu'ils regardent, ni pourquoi c'est si spécial.

C'est pourquoi je vous recommande d'utiliser un outil de capture d'écran pour enregistrer des démos vidéo de 2 minutes.

Deux minutes devraient suffire pour montrer comment le projet fonctionne. Une fois que vous avez fait cela, vous pouvez expliquer certains détails de mise en œuvre et les décisions de conception que vous avez prises.

Mais commencez toujours, toujours par la démo. Les gens veulent voir quelque chose fonctionner. Ils veulent voir quelque chose de visuel.

Une fois que vous avez attiré les gens avec votre démo convaincante de votre application en cours d'exécution, vous pouvez expliquer tous les détails que vous voulez. Votre public aura maintenant plus de contexte et sera plus intéressé.

Deux minutes est aussi une durée magique, car vous pouvez télécharger cette vidéo dans un tweet, et elle se lancera automatiquement sur Twitter au fur et à mesure que les gens défilent. Les vidéos en lecture automatique ont beaucoup, beaucoup plus de chances d'être regardées sur Twitter. Elles suppriment la friction de devoir cliquer sur un bouton de lecture ou de naviguer vers un autre site web.

Vous pouvez mettre ces vidéos de démo de projet sur des sites comme YouTube, Twitter, votre profil GitHub, et bien sûr votre propre site portfolio.

Pour capturer cette vidéo, je recommande d'utiliser QuickTime, qui est intégré à MacOS. Et si vous êtes sur Windows, vous pouvez utiliser Game Recorder, qui est gratuit dans Windows 10.

Et si vous voulez un outil plus puissant, OBS est gratuit et open source. Il est plus difficile à apprendre, mais infiniment personnalisable.

En ce qui concerne les conseils d'enregistrement : gardez votre taille de police aussi grande que possible, et utilisez un micro externe. N'importe quel micro que vous pouvez trouver – même celui d'écouteurs bon marché – sera meilleur que de parler dans le micro intégré de votre ordinateur portable.

Investissez autant de temps que nécessaire pour enregistrer et réenregistrer les prises jusqu'à ce que vous réussissiez.

Être capable de faire la démo de vos projets et de présenter votre code est une compétence précieuse que vous utiliserez tout au long de votre carrière. Le temps passé à s'entraîner au pitch n'est jamais perdu.

Comment lancer votre propre projet open source, entreprise ou association caritative

Être fondateur est le moyen le plus rapide – mais aussi le plus risqué – de se forger une réputation de développeur.

C'est le plus risqué car vous pariez votre temps, votre argent et peut-être même vos relations personnelles – tout cela pour un résultat inconnu.

Si vous contribuez à l'open source pendant assez longtemps, vous allez vous forger une réputation de développeur.

Si vous arpentez le circuit des hackathons pendant assez longtemps, vous allez vous forger une réputation de développeur.

Mais vous pourriez essayer de lancer des projets entrepreneuriaux pendant des décennies sans obtenir de traction. Et gaspiller votre temps, votre argent et vos relations en cours de route.

L'entrepreneuriat dépasse le cadre de ce livre. Mais si cela vous intéresse, je vous donnerai ce conseil rapide :

La plupart des entrepreneurs échouent. Certains échouent à cause de circonstances indépendantes de leur volonté. Mais beaucoup échouent faute de comprendre la nature des risques qu'ils prennent.

Ne vous précipitez pas pour fonder un projet, une entreprise ou une association caritative. Essayez de travailler pour d'autres organisations qui font déjà du travail dans votre domaine d'intérêt.

En travaillant pour quelqu'un d'autre, vous êtes payé pour apprendre. Vous êtes exposé au travail et aux risques qui l'entourent. Et vous pouvez accumuler des économies pour une éventuelle aventure entrepreneuriale.

Comment ne pas détruire votre réputation

"Il faut toute une vie pour se bâtir une bonne réputation, mais on peut la perdre en une minute." – Will Rogers, acteur, cowboy et l'un de mes héros d'enfance en Oklahoma

Bâtir sa réputation est un marathon, pas un sprint.

Il peut falloir des années pour se bâtir une réputation assez solide pour ouvrir les bonnes portes.

Mais comme dans un marathon de compétition, un faux pas peut vous coûter un temps précieux. Un faux pas qui entraîne une blessure peut vous mettre complètement hors course.

Ne dites pas de bêtises sur Internet

Les gens disaient des bêtises tout le temps autrefois. Les mots restaient peut-être en suspens pendant quelques minutes pendant que tout le monde grimaçait. Mais les mots finissaient par se dissiper.

Maintenant, quand les gens disent des bêtises, ils le font souvent en ligne. Et à l'encre indélébile.

Partez toujours du principe qu'au moment où vous tapez quelque chose sur un site web et que vous appuyez sur Entrée, cela va être sauvegardé dans une base de données. Cette base de données va être sauvegardée dans plusieurs centres de données à travers le monde.

On peut prouver l'existence de données, mais il n'y a aucun moyen de prouver l'absence de données.

Vous devriez supposer, à toutes fins utiles, que le chat est sorti du sac. Il n'y a pas moyen de remettre le chat dans le sac. Quoi que vous veniez de dire : c'est sur votre dossier permanent.

Vous pouvez supprimer la remarque. Vous pouvez supprimer votre compte. Vous pouvez même essayer de l'effacer des résultats de recherche Google. Mais quelqu'un l'a probablement déjà sauvegardé sur la Wayback Machine. Et quand l'une de ces bases de données se fera inévitablement pirater dans quelques années, ces données seront probablement encore là quelque part, prêtes à être ressorties par quelqu'un.

C'est une époque effrayante pour les grandes gueules. Alors n'en soyez pas une. Réfléchissez avant de parler.

Mon conseil, qui peut sembler lâche : perdez l'habitude de vous disputer avec les gens en ligne.

Certaines personnes respectent la règle de la cour de récréation : "si tu n'as rien de gentil à dire, ne dis rien du tout."

Je préfère le "féliciter en public, critiquer en privé."

Je reconnaîtrai publiquement le bon travail que quelqu'un fait dans la communauté des développeurs. Si je vois un projet qui m'impressionne, je le dirai.

Mais je m'abstiens généralement de démolir les gens. Même ceux qui le méritent.

Dans une bagarre, tout le monde finit par avoir l'air sale.

Vous ne voulez pas avoir l'air colérique, en train de mettre en pièces l'argument de quelqu'un, ou de vous acharner sur quelqu'un qui vient de dire une bêtise.

Bien sûr – l'esprit caustique peut vous faire gagner des points sur internet à court terme. Mais cela peut aussi faire en sorte que les gens vous aiment un peu moins et vous craignent un peu plus.

J'essaie aussi de m'abstenir de me plaindre. Oui, je pourrais probablement obtenir un meilleur service client si je menaçais de tweeter à propos d'un vol annulé.

Mais les gens sont occupés. La plupart d'entre eux ne veulent pas utiliser leur temps si rare à faire défiler les réseaux sociaux, pour me voir gémir sur ce qui est, dans l'absolu, un inconvénient mineur.

C'est donc mon conseil sur l'utilisation des réseaux sociaux. Essayez de rester positif.

S'il s'agit d'une question qui vous tient à cœur, je ne vous empêcherai pas de dire ce que vous pensez. Réfléchissez simplement avant de taper, et réfléchissez avant d'appuyer sur envoyer.

Ne promettez pas trop pour ensuite livrer trop peu

L'une des façons les plus courantes que je vois chez les développeurs de saboter leur propre réputation est de promettre trop et de livrer trop peu (over-promise and under-deliver). Ce n'est pas nécessairement une erreur fatale. Mais c'est mauvais.

Vous vous souvenez quand j'ai parlé du hackathon de Las Vegas où j'ai totalement échoué à terminer le projet à temps pour le pitch, et où nous avons dû utiliser des diapositives au lieu d'une application fonctionnelle ?

Oui, c'était l'un des points les plus bas de mon parcours d'apprentissage du code. Mes coéquipiers étaient polis, mais je suis sûr qu'ils étaient déçus par moi. Après tout, j'avais été trop confiant. J'avais promis trop par rapport à ce que je serais capable de réaliser dans ce laps de temps, et j'avais livré trop peu.

Il est bien préférable d'être modeste dans vos estimations de vos capacités.

Rappelez-vous la parabole d'Icare qui, sur des ailes de cire, vola trop près du soleil. Si seulement il avait adopté une approche plus mesurée. S'il était monté un peu plus lentement. Alors ses ailes n'auraient pas fondu, et il n'aurait pas plongé dans la mer, laissant un père rongé par la culpabilité.

La Chute d'Icare de Pieter Bruegel l'Ancien, vers 1560. Icare aurait pu être un champion. Il aurait pu être quelqu'un. Mais au lieu de cela, il n'est que des jambes disparaissant dans la mer. Et les fermiers et les bergers ne peuvent pas se donner la peine de lever les yeux de leur travail pour prendre la mesure de son insignifiance.

Maîtrisez vos addictions avant qu'elles ne nuisent à votre réputation

Si vous souffrez d'une addiction non traitée aux drogues, à l'alcool ou au jeu, demandez d'abord de l'aide. La recherche d'un emploi de développeur peut être un processus long et épuisant. Vous voulez vous y lancer avec toute votre attention.

Même quelque chose d'apparemment inoffensif comme l'addiction aux jeux vidéo peut vous distraire et absorber trop de votre temps. Il vaut la peine de la maîtriser d'abord.

Je ne suis pas médecin. Et je ne vais pas vous faire un discours sur "la drogue c'est mal". Mais je dirai ceci : vous entendrez peut-être parler de modes de la Silicon Valley, où des développeurs abusent de drogues en pensant pouvoir ainsi améliorer leurs capacités de codage ou de résolution de problèmes.

Pendant un temps, il y a eu la mode du "micro-dosage de LSD". Il y a eu la mode des amphétamines pharmaceutiques.

Ma réaction instinctive à cela est la suivante : tout avantage que ces substances pourraient vous donner est probablement non durable, et un bilan négatif net sur une période plus longue.

Ne cédez pas à la pression des pairs pour prendre des drogues psychoactives. Ne cédez pas à la pression des pairs pour boire lors des happy hours. (Je n'ai pas bu ne serait-ce qu'une bière depuis la naissance de ma fille il y a 8 ans, et je n'ai pas l'impression d'avoir manqué quoi que ce soit.)

Si vous êtes en convalescence après une addiction, soyez conscient que l'apprentissage du code et l'obtention d'un emploi de développeur seront un processus stressant. Allez-y à votre rythme, afin de ne pas risquer une rechute.

Vous ne voulez pas arriver au bout du processus de transition de carrière – et accomplir tant de choses – pour voir vos vieilles habitudes refaire surface et anéantir votre dur labeur.

Essayez de séparer votre vie professionnelle de votre vie personnelle

Vous avez peut-être entendu l'expression "ne pas mélanger les affaires et le plaisir".

En tant que développeur, vous allez devenir une personne influente. Vous allez commander un certain respect de la part des gens de votre ville.

Peut-être pas autant qu'un médecin ou un astronaute. Mais quand même. Les gens vont vous admirer.

Vous allez parler avec des gens qui aimeraient être à votre place.

N'étalez pas votre richesse.

N'agissez pas comme si vous étiez plus intelligent que tout le monde.

N'abusez pas du rapport de force pour obtenir ce que vous voulez dans vos relations.

Cela vous rendra antipathique aux yeux des gens qui vous entourent. Et si c'est capturé et publié en ligne d'une manière ou d'une autre, cela pourrait vous hanter pour le reste de votre carrière.

Ne perdez jamais de vue tout ce que vous avez. Et tout ce que vous avez à perdre.

Utilisez l'astuce du narrateur

Je terminerai ce chapitre avec une petite astuce que j'utilise pour me motiver.

Tout d'abord, rappelez-vous que vous êtes le héros de votre propre parcours de codage. Dans le théâtre de votre esprit, vous êtes la personne que tout le monde regarde – celle qu'ils encouragent.

L'astuce du narrateur consiste à narrer vos actions dans votre tête au fur et à mesure que vous les faites.

Quincy traverse le hackerspace à grands pas, son ordinateur portable sous le bras. Il place sa tasse sous le distributeur d'eau chaude et y dépose un sachet de thé frais. Il tire le levier. Et tandis que l'eau fumante remplit sa tasse, il dit à haute voix avec son meilleur accent britannique : "Thé. Earl Grey. Chaud."

Sa boisson énergisante à la main, il se glisse dans un box, pose son ordinateur bien à plat sur la surface, et croise le regard d'un collègue développeur. Leurs regards se croisent une seconde. Quincy incline très légèrement la tête, reconnaissant la présence du développeur. Le développeur incline la tête en retour, partageant presque par télépathie ce sentiment : "Je te vois, l'ami. Je te vois présent. Je te vois accomplir des choses."

Cela peut paraître ridicule. Eh bien oui, c'est ridicule. Mais je le fais tout le temps. Et ça marche.

Narrer même les moments les plus banals de votre vie dans votre tête peut vous aider à vous dynamiser. Cristalliser le moment présent devant vous, et vous donner une clarté d'intention.

Et cela fonctionne encore mieux quand on pense à sa vie en termes d'époques ("les années Taco Bell"). Ou de points d'inflexion ("réussir l'examen du GED").

Quel est le rapport avec la construction de votre réputation ? Votre réputation est essentiellement le résumé de qui vous êtes. Ce que vous signifiez pour les gens qui vous entourent.

En vous prenant plus au sérieux, en pensant à votre vie comme à un film, vous travaillez progressivement sur qui vous êtes. Et sur qui vous voulez devenir un jour.

En narrant vos actions, vous projetez une lumière plus vive sur elles dans votre propre esprit. Pourquoi ai-je fait cela ? À quoi je pensais ? Y avait-il un meilleur coup à jouer ?

Tant de gens sabotent leur réputation sans même s'en rendre compte, simplement parce qu'ils se sont installés dans de mauvaises habitudes.

Pendant des années, j'ai cru que je devais être "drôle" tout le temps. Je cherchais n'importe quelle occasion d'injecter un peu d'humour d'autodérision. Beaucoup de gens comprenaient ce que je faisais et trouvaient cela amusant. Mais beaucoup ne comprenaient pas, et avaient simplement l'impression que j'étais un crétin.

Pourquoi ai-je fait cela ? Je pense que cela remontait à l'école primaire, quand j'essayais toujours d'être le clown de la classe et de faire rire les gens.

Mais des décennies plus tard, ce réflexe de combler le silence par le rire ne me servait pas bien.

"Quand on répète une erreur, ce n'est plus une erreur. C'est une décision." – Paulo Coelho

J'aurais pu continuer ainsi bien plus longtemps sans remarquer cette mauvaise habitude. Mais avec l'astuce du narrateur, la maladresse de mon comportement a été mise à nu.

Je suis sûr que j'ai beaucoup d'autres façons de penser et de faire les choses qui sont sous-optimales. Et avec l'aide de l'astuce du narrateur, j'espère les identifier à l'avenir et les affiner, avant qu'elles ne donnent aux gens une mauvaise impression.

Votre réputation deviendra votre héritage.

Pensez à qui vous voulez être à la fin de votre histoire. À la façon dont vous voulez que les gens se souviennent de votre passage sur Terre. Ensuite, travaillez à rebours à partir de là.

La personne que vous voulez être à la fin du film. Ce héros que vous voulez que les gens admirent. Pourquoi ne pas commencer à vous comporter ainsi dès maintenant ?

Pouvez-vous imaginer ce que ce serait d'être un développeur à succès ? D'avoir construit des systèmes logiciels sur lesquels les gens comptent ?

Ce futur vous – comment penserait-il ? Comment aborderait-il les situations et résoudrait-il les problèmes ? Comment parlerait-il de ses accomplissements ? De ses revers ?

Le simple fait de penser à votre futur moi peut vous aider à clarifier votre pensée. Vos priorités.

Je pense souvent au "Vieux Quincy", avec son mal de dos. Il doit s'excuser pour courir aux toilettes toutes les 30 minutes.

Mais le Vieux Quincy fait toujours de son mieux avec ce qu'il a. Il bouge malgré ses articulations douloureuses. Il réfléchit malgré un esprit parfois embrumé.

Le Vieux Quincy veut toujours accomplir des choses. Il est fier de ce qu'il a accompli, mais il ne passe pas beaucoup de temps à regarder en arrière. Il regarde vers l'avant, ce qu'il va faire aujourd'hui, et quels objectifs il va atteindre.

Je pense souvent au Vieux Quincy, et je remonte le temps jusqu'à là où je suis aujourd'hui.

Quelles décisions puis-je prendre aujourd'hui qui me prépareront à être quelqu'un digne d'admiration demain ? Dois-je attendre des décennies pour gagner cette réputation ? Ou puis-je emprunter un peu de ce respect au futur ?

En pensant comme mon futur moi pourrait penser, puis-je faire des choix qui me valent une réputation positive dans le présent ?

Je crois que vous pouvez exploiter votre future réputation – votre héritage – dès maintenant. Pensez simplement en termes de votre futur moi et de ce que vous accomplirez. Et utilisez cela comme un point de repère pour vous guider.

J'espère que ces outils – l'astuce du narrateur et l'astuce de visualisation de votre futur moi – vous aideront non seulement à réfléchir à la nature de la réputation. J'espère qu'ils vous aideront également à prendre des mesures concrètes pour améliorer votre réputation.

Parce que se bâtir une réputation – se faire un nom – est le chemin le plus sûr vers un succès durable en tant que développeur.

Le succès peut signifier beaucoup de choses pour beaucoup de gens. Mais la plupart des gens – de la plupart des cultures – seraient d'accord : un aspect majeur du succès est de mettre de la nourriture sur la table pour soi et sa famille.

Et c'est ce dont nous allons parler ensuite.

Chapitre 4 : Comment être payé pour coder – Clients freelance et recherche d'emploi

Si vous avez développé vos compétences, votre réseau et votre réputation, alors obtenir un emploi de développeur n'est pas si compliqué.

Notez que j'ai dit que ce n'est pas compliqué – c'est quand même beaucoup de travail. Et cela peut être éprouvant.

D'abord, laissez-moi vous raconter comment j'ai obtenu mon premier emploi.

L'heure de l'histoire : comment un enseignant dans la trentaine a-t-il obtenu son premier emploi de développeur ?

La dernière fois dans l'Heure de l'histoire : Quincy a arpenté le circuit des hackathons, en gagnant même quelques-uns. Il se forgeait une réputation de développeur "dangereux" avec JavaScript. Pas super compétent. Juste dangereux...

Je venais de terminer une longue journée d'apprentissage à la bibliothèque du centre-ville de Santa Barbara, à siroter du thé et à construire des projets.

La meilleure chose quand on vit en Californie, c'est le temps. On plaisantait en disant que quand on louait un appartement d'une chambre à un prix exorbitant en banlieue, on ne payait pas pour l'intérieur – on payait pour l'extérieur.

Mon objectif était de passer le moins de temps possible dans ce piège à rats exigu vieux de 100 ans, et de passer le reste du temps à marcher en ville.

C'était un magnifique mercredi soir. J'avais encore deux jours pour préparer le hackathon du week-end. Et mon cerveau était complètement grillé par la journée de codage. Ma femme travaillait tard, alors j'ai regardé mon calendrier pour trouver quelque chose à faire.

Le premier lundi de chaque mois, je répertoriais tous les événements technologiques à venir dans le sud de la Californie pour le mois, afin de toujours avoir un événement tech auquel assister si j'en avais l'énergie.

Ah – ce soir, c'est le meetup Ruby on Rails de Santa Barbara, et j'avais déjà confirmé ma présence.

Je ne connaissais pas grand-chose à Ruby on Rails, mais j'avais réalisé quelques petits projets avec. J'étais bien plus un développeur JavaScript et Python.

Mais je me suis dit, qu'importe. Je dois maintenir mon élan dans la construction de mon réseau. Et le lieu n'était qu'à quelques pâtés de maisons.

Je suis entré et il n'y avait que quelques développeurs assis autour d'une table en train de discuter. Il est vite devenu clair qu'ils travaillaient tous ensemble dans une startup locale, maintenant une large base de code Ruby on Rails. La plupart d'entre eux y travaillaient depuis plusieurs années.

À ce stade, j'avais passé l'année écoulée à développer mes compétences, mon réseau et ma réputation. J'étais donc capable de tenir mon rang pendant la conversation.

Mais j'avais aussi le sens des limites de mes capacités. Je suis donc resté modeste. Sobre. De la façon dont j'avais vu tant d'autres développeurs à succès mener une conversation lors d'événements technologiques.

Il est devenu clair que l'un des développeurs à table était le directeur de l'ingénierie. Il rapportait directement au CTO.

Et puis il est devenu clair qu'ils cherchaient à embaucher des développeurs Ruby on Rails.

J'ai été franc sur mon parcours et mes capacités. "Mon parcours est dans l'éducation des adultes. Enseigner l'anglais et diriger des écoles. J'ai commencé à apprendre à coder il y a environ un an."

Mais l'homme était étonnamment imperturbable. "Eh bien, si vous voulez venir pour un entretien, nous pourrons voir si vous seriez un bon élément pour l'équipe."

Ce soir-là, je suis rentré chez moi en ressentant une électricité. C'était bien plus de l'effroi que de l'excitation.

Je ne me sentais pas du tout prêt. Et je ne cherchais même pas de travail. Je vivais sur mes économies, apprenant à coder à plein temps, avec une assurance maladie via l'emploi de ma femme.

J'étais un épargnant compulsif. Les gens se moquaient de moi à ce sujet. Je changeais ma propre huile, je me coupais les cheveux moi-même, et je cuisinais même mon propre riz à la maison quand nous commandions des plats à emporter – juste pour économiser quelques dollars.

Au cours de la décennie où j'avais travaillé comme enseignant, j'avais réussi à épargner près d'un quart de mes revenus après impôts. Et j'achetais de vieux jeux vidéo sur Craigslist, puis je les revendais sur eBay. Cela peut paraître idiot, mais c'était une source de revenus substantielle pour moi.

Pourquoi épargnions-nous tout cela ? Nous n'en étions pas sûrs. Peut-être pour acheter une maison en Californie à un moment donné dans le futur ? Mais cela signifiait que je n'avais pas besoin de me précipiter pour obtenir un emploi. Je savais que j'étais dans une position privilégiée, et j'essayais d'en tirer le meilleur parti en apprenant davantage chaque jour.

Bref, je ne pensais pas être prêt pour mon premier emploi de développeur. Et je craignais que s'ils m'embauchaient, ce soit une grosse erreur. Ils réaliseraient à quel point j'étais inexpérimenté, me licencieraient, et je devrais ensuite expliquer cet échec lors de futurs entretiens d'embauche.

Bien sûr, je sais maintenant que je voyais cette opportunité de la mauvaise façon. Mais laissez-moi finir l'histoire.

Quand j'ai programmé mon entretien d'embauche, ils m'ont demandé un CV. Je ne savais pas trop quoi faire, alors j'ai laissé toute mon expérience professionnelle. Toutes les écoles pour lesquelles j'avais travaillé au fil des ans. (J'ai omis mon passage au drive-thru de Taco Bell.)

Bien sûr, aucune de mes expériences professionnelles n'avait quoi que ce soit à voir avec le codage. Mais qu'étais-je censé faire, leur remettre une feuille de papier vierge ?

Eh bien, j'avais un portfolio en ligne de projets que j'avais construits. Et surtout, j'avais une liste de tous les hackathons que j'avais gagnés ou où j'avais été classé. Je les ai donc inclus.

J'ai passé les dernières heures avant l'entretien à revoir tous les tutoriels Ruby on Rails que j'avais utilisés au cours de l'année écoulée, pour me rafraîchir la mémoire. Puis j'ai mis mon sweat à capuche, mon jean et mon sac à dos, et je me suis rendu à leur bureau.

La responsable de bureau était une dame sympathique qui m'a emmené dans l'espace des développeurs et m'a présenté à leur petite équipe. Ils étaient peut-être une douzaine, la plupart habillés en jeans et sweats à capuche, âgés de 20 à 45 ans environ. Il y avait deux femmes.

J'ai navigué à tour de rôle dans l'enchevêtrement de bureaux et de câbles, serrant la main de chacun d'eux et me présentant. C'est là que toute mon expérience de professeur de classe mémorisant les noms des élèves m'a été utile. J'ai pu me souvenir de tous leurs noms, de sorte que plus tard dans la journée, en partant, j'ai pu assurer le suivi avec chacun d'eux : "Ravi de vous avoir rencontré [nom]. Je serais ravi de travailler à vos côtés."

J'ai d'abord rencontré le directeur de l'ingénierie. Nous sommes allés dans un petit bureau et avons fermé la porte.

Un tableau blanc au mur était couvert de croquis de diagrammes UML (Unified Modeling Language). Un arc-en-ciel de feutres effaçables à sec traçait les relations entre divers serveurs et services.

Je ne cessais de jeter des coups d'œil à ce tableau blanc, craignant qu'il ne m'y envoie pour résoudre des problèmes de codage et démontrer mes compétences. Peut-être le fameux problème "fizzbuzz" ? Peut-être voudrait-il que j'inverse un arbre binaire ?

Mais il n'a jamais mentionné le tableau blanc. Il est juste resté assis là à me regarder intensément tout le temps.

C'était une entreprise d'environ 50 employés, avec beaucoup de financements en capital-risque, et des milliers de clients payants – principalement des petites entreprises. Ils se targuaient d'être pragmatiques. À aucun moment ils ne m'ont interrogé sur ce que j'avais étudié à l'école, ou sur le genre de travail que j'avais fait par le passé. Tout ce qui les importait, c'était...

"Écoutez. Je sais que vous savez coder," a-t-il dit. "Vous avez codé tout ce temps, gagné des hackathons. J'ai regardé certains de vos projets de portfolio. La qualité du code était correcte pour quelqu'un qui débute. Donc pour moi, la vraie question est – pouvez-vous apprendre comment nous faisons les choses ici ? Pouvez-vous travailler avec les autres développeurs de l'équipe ? Et plus crucialement : pouvez-vous accomplir des tâches ?"

J'ai dégluti, je me suis penché en avant et j'ai rassemblé toute la confiance possible. "Oui," ai-je dit. "Je crois que je le peux."

Et il a dit : "Bien. Bien. D'accord. Allez attendre dans le restaurant de Pho en bas. [Le CTO] devrait descendre dans une minute."

J'ai donc discuté avec le CTO autour de nouilles. J'ai surtout écouté. J'avais appris que les gens projettent de l'intelligence sur les personnes calmes. Écouter attentivement ne vous aide pas seulement à devenir plus intelligent – cela vous donne même l'air plus intelligent.

Et l'approche a fonctionné. La réunion a duré environ une heure. Les nouilles étaient savoureuses. J'ai appris beaucoup sur l'histoire de l'entreprise et ses objectifs à court terme. Le CTO a dit : "D'accord, remontez parler avec [le directeur de l'ingénierie]."

Et c'est ce que j'ai fait. Et il m'a proposé un emploi.

Maintenant, je tiens à le souligner. Ce n'est pas ainsi que la plupart des gens obtiennent leur premier emploi de développeur.

Vous vous dites probablement : "Tiens, voilà Quincy qui fait son Forrest Gump pour atterrir dans un job de développeur qu'il ne cherchait même pas. Si seulement nous pouvions tous avoir cette chance."

Et c'est certainement ce que j'ai ressenti à l'époque. Mais dans la section suivante, je vais explorer la relation entre les employeurs et les développeurs. Et comment le fait que j'aie décroché cet emploi était moins dû à mes compétences en entretien qu'à l'année de codage, de réseautage et de construction de réputation qui l'avait précédée.

Ce n'était pas un emploi douillet dans une grande entreprise tech, avec toute la rémunération, les avantages et les bowlings d'entreprise. C'était un rôle de contractuel qui payait à peu près la même chose que ce que je gagnais en tant qu'enseignant.

Mais c'était un emploi de développeur. Une entreprise me payait pour écrire du code.

J'étais désormais un développeur professionnel.

Ce que veulent les employeurs

Faisons un bond de dix ans en avant. J'ai maintenant été des deux côtés de la table. J'ai été interviewé par des responsables du recrutement en tant que développeur. J'ai interviewé des développeurs en tant que responsable du recrutement.

J'ai passé de nombreuses heures au téléphone avec des développeurs qui sont en pleine recherche d'emploi. Certains d'entre eux ont postulé à des centaines d'emplois et n'ont reçu que quelques "rappels" pour des entretiens.

J'ai aussi passé de nombreuses heures au téléphone avec des managers et des recruteurs, essayant de mieux comprendre comment ils embauchent et ce qu'ils recherchent.

Je pense qu'une grande partie de la frustration que les développeurs ressentent face au processus d'embauche vient d'un malentendu.

Les employeurs valorisent une chose par-dessus tout : la prévisibilité.

Lequel de ces candidats pensez-vous qu'un employeur préférerait ?

X est un codeur "rockstar" 10x qui a souvent des éclairs de génie. X a aussi des pics de productivité incroyables. Mais X est souvent grincheux avec ses collègues, et manque souvent des échéances ou des réunions.

Y est un codeur correct, et a une production plus lente mais plus constante. Y s'entend bien avec ses collègues, et manque rarement des réunions ou des échéances.

Z est similaire à Y en termes de production, et capable de bien s'entendre avec ses collègues et de respecter les échéances. Mais Z a changé d'emploi 3 fois au cours des 3 dernières années.

D'accord, vous pouvez probablement deviner d'après tout ce que j'ai dit jusqu'ici : Y est le candidat préféré. Et c'est parce que les employeurs valorisent la prévisibilité par-dessus tout.

X est un candidat piège que certains managers débutants pourraient faire l'erreur d'embaucher. Si vous êtes curieux de savoir pourquoi embaucher X serait une si mauvaise idée, lisez Nous avons licencié notre meilleur talent. La meilleure décision que nous ayons jamais prise.

J'ai seulement ajouté Z à cette liste pour souligner un point : essayez de ne pas changer d'emploi trop souvent.

Vous pouvez augmenter vos revenus assez rapidement en passant d'un employeur à l'autre. Vous pouvez commencer à postuler pour de nouveaux emplois dès que vous acceptez une lettre d'offre. Mais cela repoussera de nombreux responsables du recrutement.

Après tout, pierre qui roule n'amasse pas mousse. Vous entrerez et sortirez des bases de code avant d'avoir eu le temps de comprendre comment elles fonctionnent.

Considérez ceci : il peut falloir 6 mois ou plus à un manager pour mettre un nouveau développeur à niveau, au point qu'il puisse être un bénéfice net pour l'équipe.

Jusqu'à ce point, la nouvelle recrue est essentiellement une charge pour les ressources de l'entreprise, absorbant le temps et l'énergie de ses pairs qui doivent l'intégrer, l'aider à s'orienter dans une base de code et corriger ses bugs.

La plupart des employeurs ont une aversion pour le risque

Disons qu'un manager embauche le mauvais développeur. Prenez un moment pour réfléchir à quel point cela peut être préjudiciable pour l'équipe.

En moyenne, il faut environ 3 mois pour pourvoir un poste de développeur dans une entreprise. Les employeurs doivent d'abord :

• faire approuver le budget pour l'embauche d'un développeur par leurs supérieurs
• créer la description de poste
• publier l'offre sur des sites d'emploi et communiquer avec des recruteurs
• passer au crible les CV – dont beaucoup seront de piètre qualité, provenant de candidats qui postulent aveuglément à autant d'emplois que possible
• commencer le processus d'entretien, qui peut impliquer de faire venir les candidats par avion dans la ville et de les loger à l'hôtel
• des cycles d'entretiens impliquant de nombreux membres de l'équipe. Pour certains employeurs, c'est une affaire de plusieurs jours
• sélectionner un candidat final, et négocier une offre...
• que de nombreux candidats n'accepteront pas de toute façon
• signer les contrats et intégrer l'employé
• lui donner accès à des systèmes internes sensibles
• le présenter à ses coéquipiers, et s'assurer que tout le monde s'entend bien
• puis des mois de formation informelle, pendant lesquels l'employé doit comprendre un service ou une partie d'une base de code legacy
• et enfin, l'imprégner de la façon de faire de l'équipe

Bref – beaucoup de travail.

Maintenant, imaginez qu'après avoir fait tout cela, le nouvel employé dise : "Hé, je viens de recevoir une offre plus élevée de cette autre entreprise. Salut tout le monde, je m'en vais."

Ou imaginez que l'employé ne soit pas fiable, et arrive souvent des heures après le début de la journée de travail.

Ou imaginez que l'employé lutte contre une addiction non traitée à la drogue, à l'alcool ou au jeu, qu'il ait des problèmes de colère – ou qu'il s'avère simplement être une personne passive-agressive qui mine l'équipe.

Vous devez maintenant recommencer tout ce processus et chercher un nouveau candidat pour le poste.

Embaucher est difficile.

Vous comprenez donc pourquoi les employeurs ont une aversion pour le risque. Beaucoup d'entre eux laisseront passer des candidats apparemment qualifiés jusqu'à ce qu'ils trouvent quelqu'un dont ils se sentent sûrs à 99 %.

Parce que les employeurs ont une telle aversion pour le risque, les demandeurs d'emploi en souffrent

Maintenant, si vous pensez que l'embauche est difficile, attendez d'entendre parler du processus de candidature. Vous l'êtes peut-être déjà trop familier. Mais voici comment ça se passe...

• Vous devez préparer votre CV. En chemin, vous prendrez des décisions que vous remettrez constamment en question tout au long de votre recherche d'emploi.
• Vous devez chercher des offres d'emploi en ligne, faire des recherches sur les employeurs et évaluer s'ils sont susceptibles de vous convenir.
• La plupart des offres d'emploi mèneront à des formulaires web où vous devrez retaper votre CV encore et encore, en espérant que le formulaire ne plante pas à cause d'erreurs de serveur ou d'erreurs de validation JavaScript.
• Une fois que vous avez soumis ces candidatures, vous devez attendre que l'employeur les traite. Certains employeurs reçoivent tellement de candidatures qu'ils ne peuvent pas toutes les examiner manuellement. (Google reçoit à lui seul 9 000 candidatures par jour.) Les employeurs utiliseront des logiciels pour filtrer les candidatures. Les recruteurs internes passent en moyenne 6 secondes à regarder chaque CV. Souvent, votre candidature ne sera jamais examinée par un humain.
• Vous n'aurez probablement jamais de nouvelles de l'entreprise. Ils n'ont guère intérêt à vous dire pourquoi ils vous ont rejeté (ils ne veulent pas que vous intentiez un procès pour discrimination). Si vous avez de la chance, vous recevrez l'un de ces e-mails "Nous avons choisi de poursuivre avec d'autres candidats".
• Et tout le temps que vous passez à postuler à ces emplois – potentiellement des heures par semaine – est mentalement épuisant et, bien sûr, non rémunéré.

Wow. Vous voyez donc quel cauchemar le processus d'embauche représente pour les employeurs, et surtout pour les candidats.

Mais si vous persévérez, vous finirez par décrocher des offres. Et quand il pleut, il pleut à verse.

Voici les données de la recherche d'emploi d'un contributeur de freeCodeCamp sur une période de 12 semaines :

Sur 291 candidatures, il a finalement reçu 8 offres.

Et au fur et à mesure que les offres arrivaient, le salaire de départ devenait de plus en plus élevé. Notez, bien sûr, qu'il s'agit d'un emploi à San Francisco, l'une des villes les plus chères du monde.

À la semaine 12, ses offres de salaire de départ étaient presque le double de ce qu'elles étaient à la semaine 2.

Le taux d'obtention d'entretiens de ce développeur est très solide. Et sa capacité de négociation était également forte. Vous pouvez en savoir plus sur son processus si vous êtes curieux.

Mais comme je l'ai déjà dit, il est beaucoup plus facile d'entrer dans une entreprise par la porte latérale.

Et c'est l'une des raisons pour lesquelles j'ai écrit ce livre. Je ne veux pas que vous continuiez à faire la queue devant la porte d'entrée de ces employeurs.

Si vous développez vos compétences, votre réseau et votre réputation, vous pouvez contourner une grande partie du processus de candidature.

Tout au long de ce livre, je vous ai enseigné des techniques pour augmenter votre probabilité de "tomber" sur une offre d'emploi.

"La chance, c'est quand la préparation rencontre l'opportunité. Si vous n'aviez pas été préparé quand l'opportunité s'est présentée, vous n'auriez pas eu de 'chance'." – Oprah Winfrey

C'est pourquoi, tout au long de ce livre, je vous ai encouragé à développer ces trois domaines à la fois, et à commencer à y penser dès le premier jour – bien avant votre recherche d'emploi.

Mon histoire de ne même pas chercher de travail et de décrocher un emploi peut sembler idiote. Mais cela arrive plus souvent que vous ne le pensez.

La réalité est la suivante : apprendre à coder est difficile.

Mais savoir coder est important.

Dans chaque industrie – dans pratiquement chaque entreprise au monde – les managers essaient de trouver des moyens de pousser leurs processus vers la couche logicielle.

Cela signifie des développeurs.

Vous entendez parler de grands licenciements dans la tech de temps en temps. Beaucoup de ces licenciements affectent des employés qui ne sont pas des développeurs. Mais souvent, beaucoup de développeurs perdent aussi leur emploi.

Pourquoi les entreprises licencieraient-elles des développeurs, après avoir passé tant de temps et d'argent à les recruter et à les former ? À part une situation de faillite, je ne connais pas la réponse à cette question. Je ne suis pas sûr que quiconque la connaisse.

Il y a de plus en plus de preuves que les licenciements détruisent la valeur à long terme au sein d'une entreprise. Mais en pratique, de nombreux CEO se sentent poussés par leurs investisseurs à procéder à des licenciements. Et quand plusieurs entreprises procèdent à des licenciements à peu près au même moment, d'autres CEO peuvent suivre le mouvement.

Pourtant, même avec les licenciements, la plupart des économistes s'attendent à ce que le nombre d'emplois de développeurs et d'autres emplois liés au logiciel continue de croître. Par exemple, le Bureau américain des statistiques du travail prévoit une augmentation de 15 % du nombre de développeurs au cours de la prochaine décennie.

Le marché du travail est peut-être tendu en ce moment, mais peu de gens s'attendent à ce que ce ralentissement dure.

Mon espoir est qu'avec des compétences solides, un réseau solide et une réputation solide, vous pourrez décrocher un bon emploi malgré un marché du travail difficile.

Espérons qu'un jour, il sera plus facile pour les employeurs et les employés qualifiés de se trouver – sans le long et brutal processus de candidature et d'entretien.

À quoi s'attendre lors du processus d'entretien d'embauche pour développeurs

Une fois que vous commencerez à décrocher des entretiens d'embauche, vous aurez un aperçu du redoutable processus d'entretien pour développeurs et du célèbre entretien de codage.

Un flux d'entretien typique pourrait impliquer :

1. Passer une évaluation de codage en ligne de vos compétences ou un "Phone Screen" (entretien téléphonique de présélection).
2. Et ensuite, si vous réussissez cela, un deuxième entretien technique par téléphone ou vidéo.
3. Et ensuite, si vous réussissez cela, un entretien "sur site" où vous vous rendez dans un bureau de l'entreprise. Ceux-ci impliquent généralement plusieurs entretiens avec les RH, les responsables du recrutement et les développeurs de base avec lesquels vous pourriez travailler.

En chemin, vous ferez face à des questions qui testent vos connaissances en résolution de problèmes, en algorithmes et structures de données, en débogage et autres compétences.

Vos intervieweurs peuvent vous laisser résoudre ces problèmes de codage sur un ordinateur dans un éditeur de code. Mais souvent, vous devrez les résoudre à la main tout en étant debout devant un tableau blanc.

La chose clé à retenir est que la personne qui vous interviewe ne cherche pas seulement une réponse correcte de votre part. Elle essaie aussi de comprendre comment vous réfléchissez.

Ils veulent savoir : comprenez-vous les fondamentaux de la programmation et de l'informatique ? Ou vous contentez-vous de régurgiter une série de solutions que vous avez mémorisées ?

Maintenant, pratiquer les algorithmes et les structures de données vous aidera beaucoup. Mais vous devez aussi être capable de réfléchir à voix haute, et d'expliquer votre processus de pensée pendant que vous écrivez vos solutions.

La meilleure façon de s'entraîner à cela est de se parler à voix haute pendant que l'on code. Ou – si vous vous sentez aventureux – de vous diffuser en direct en train de coder.

Il y a beaucoup de flux de "live coding" sur Twitch où les gens "apprennent en public" en construisant des projets devant un public. En prime, si vous êtes prêt à vous exposer ainsi, cela vous aidera aussi à construire votre réputation de développeur.

Une autre chose à retenir lors des entretiens au tableau blanc : votre intervieweur. Il n'est pas juste assis là à attendre que vous finissiez. Il est avec vous tout le temps, vous observant et vous évaluant consciemment et inconsciemment.

Essayez de rendre le processus d'entretien aussi interactif que possible pour votre intervieweur. Souriez et établissez un contact visuel occasionnel. Essayez de juger son langage corporel. Est-il détendu ? Hoche-t-il la tête pendant que vous expliquez des points ?

Votre intervieweur sait probablement ce qu'il cherche dans votre code. Voyez donc si vous pouvez lui soutirer quelques indices. En faisant des observations ou en posant des questions ouvertes à voix haute, vous pourrez peut-être amener votre intervieweur à intervenir et à se sentir impliqué dans le processus.

Vous voulez que votre intervieweur vous apprécie. Vous voulez qu'il vous encourage, afin qu'il puisse passer outre certains des défauts de vos compétences en programmation, ou ignorer certaines des erreurs que vous pourriez faire dans votre code.

Vous vous vendez en tant que candidat à un emploi. Assurez-vous que votre intervieweur a l'impression de faire une bonne affaire.

Et il en va de même pour tous les entretiens comportementaux que vous pourriez avoir à passer. Ces entretiens portent moins sur votre capacité de codage que sur votre "culture fit" (adéquation culturelle). (J'aimerais pouvoir vous dire ce que cela signifie, mais chaque manager le définira d'une manière légèrement différente.)

Dans ces entretiens comportementaux, vous devrez convaincre votre intervieweur que vous avez de solides compétences en communication.

Il est certain qu'il est utile de parler couramment la langue dans laquelle vous passez l'entretien, et de connaître le bon jargon. Vous pouvez en acquérir une grande partie en écoutant régulièrement des podcasts tech, comme le podcast de freeCodeCamp.

Une chose importante que vos intervieweurs essaient d'établir : êtes-vous une personne calme qui jouera bien avec les autres ? La meilleure façon de le montrer est d'être poli, et de s'abstenir d'utiliser des grossièretés ou de trop s'éloigner du sujet en cours.

Vous ne voulez pas entrer dans un débat sur quelque chose sans rapport, comme une rivalité sportive. Je recommande aussi de ne pas essayer de corriger vos intervieweurs, même s'ils disent des choses que vous jugez idiotes ou fausses.

Si vous avez de mauvaises ondes de la part de l'entreprise, vous n'êtes pas obligé d'accepter leur offre d'emploi. Les employeurs rejettent des candidats tout le temps. Et vous, en tant que candidat, avez aussi le droit de rejeter un employeur. L'entretien lui-même n'est probablement pas le meilleur moment pour un conflit.

Devrais-je négocier mon salaire lors de mon premier emploi de développeur ?

Essayer de négocier votre salaire à la hausse ne fait généralement pas de mal, tant que vous le faites poliment.

J'ai écrit longuement sur comment négocier le salaire de votre offre d'emploi de développeur.

Essentiellement, négocier un salaire de départ plus élevé dépend de l'influence dont vous disposez.

Votre employeur a du travail à faire. À quel point votre employeur a-t-il besoin que vous travailliez pour lui ? Quelles autres options a-t-il ?

Et vous avez besoin de revenus pour survivre. Quelles autres options avez-vous ? Quel est votre plan de secours ?

Si vous avez une offre d'emploi d'un autre employeur proposant de vous payer un certain montant, vous pouvez l'utiliser comme levier dans votre négation salariale.

Si votre meilleur plan de secours est de retourner à l'école et d'obtenir un diplôme de master ou doctorat... ce n'est pas un levier particulièrement fort, mais c'est mieux que rien. Et vous pourriez le mentionner pendant le processus de négociation salariale.

Pensez au long processus d'embauche que j'ai décrit plus tôt. Les employeurs doivent passer par au moins une douzaine d'étapes avant de pouvoir atteindre l'étape de l'offre d'emploi avec les candidats. Ils prévoient probablement déjà que vous négocierez, et ne seront pas surpris par cela.

Maintenant, si vous êtes dans une situation comme la mienne où une entreprise vous propose simplement un emploi à l'improviste, vous pouvez vous sentir mal à l'aise d'essayer de négocier.

Smithers des Simpson

Je l'admets – dans mon histoire ci-dessus, quand mon manager m'a proposé le job, je n'ai pas négocié.

Rétrospectivement, aurais-je dû négocier ma rémunération ? Probablement.

Avais-je un levier ? Probablement pas beaucoup. Mon plan de secours était de continuer à participer à des hackathons et de continuer à siroter du thé et à coder à la bibliothèque publique.

J'aurais peut-être pu négocier et obtenir quelques dollars de plus de l'heure. Mais au moment où ils m'ont proposé le job, la rémunération était la dernière chose à laquelle je pensais. J'étais juste extatique à l'idée de devenir un développeur professionnel.

D'ailleurs, une fois que vous aurez travaillé comme développeur dans une entreprise pendant un an environ, vous voudrez peut-être demander une augmentation. J'ai écrit longuement sur comment demander une augmentation en tant que développeur. Mais cela revient à la même chose : le levier.

Devriez-vous utiliser un recruteur pour votre recherche d'emploi de développeur ?

Oui. Si vous pouvez trouver un recruteur qui vous aidera à décrocher votre premier emploi de développeur, je pense que vous devriez le faire.

J'ai écrit longuement sur pourquoi les recruteurs sont un outil sous-estimé dans votre boîte à outils.

De nombreux employeurs paieront aux recruteurs une commission pour leur avoir envoyé des candidats de haute qualité.

Les incitations des recruteurs sont bien alignées avec vos propres objectifs en tant que demandeur d'emploi :

1. Puisqu'ils sont payés en fonction de votre salaire de départ, ils sont enclins à vous aider à négocier un salaire de départ aussi élevé que possible.
2. Plus ils placent de candidats — et plus ils les placent vite — plus les recruteurs gagnent d'argent. Ils voudront donc vous aider à obtenir un emploi le plus rapidement possible afin de pouvoir passer à d'autres demandeurs d'emploi.
3. Puisqu'ils ne sont payés que si vous réussissez en tant qu'employé (et restez au moins 90 jours), ils essaieront de s'assurer que vous êtes compétent et que vous correspondez bien à la culture de l'entreprise.

Cela dit, si un recruteur vous demande de lui payer de l'argent pour quoi que ce soit, c'est un signal d'alarme.

Et tous les recruteurs ne se valent pas. Faites vos recherches avant de travailler avec un recruteur. Même s'ils sont finalement payés par l'employeur, vous investissez toujours votre temps pour les aider à vous placer. Et le temps est précieux.

En parlant de temps, une façon de commencer à être payé pour coder plus tôt – même pendant que vous vous préparez à la recherche d'emploi – est d'obtenir des clients freelance.

Comment obtenir des clients freelance

J'encourage les nouveaux développeurs à essayer d'obtenir quelques clients freelance avant de commencer leur recherche d'emploi. Il y a trois bonnes raisons à cela :

1. Il est beaucoup plus facile d'obtenir un client freelance que d'obtenir un emploi à plein temps.
2. Le travail en freelance est moins risqué puisque vous pouvez le faire sans quitter votre emploi actuel.
3. Vous pouvez commencer à être payé pour coder plus tôt, et commencer à construire votre portfolio de travail professionnel plus tôt.

Obtenir des clients freelance peut être beaucoup plus facile que d'obtenir un emploi de développeur. Pourquoi ?

Pensez aux petites entreprises locales. Ce peut être juste une famille qui gère un restaurant. Ou une boutique. Ou une entreprise de plomberie. Ou un cabinet d'avocats.

Combien de ces entreprises pourraient bénéficier d'un site web interactif, de systèmes de gestion d'arrière-guichet (back-office) et d'outils pour automatiser leurs flux de travail courants ? La plupart d'entre elles.

Maintenant, combien de ces entreprises peuvent se permettre d'avoir un développeur de logiciels à plein temps pour construire et maintenir ces systèmes ? Pas autant.

C'est là que les freelances interviennent. Ils peuvent faire du travail sur une base plus économique, au cas par cas. Une petite entreprise peut faire appel à un freelance pour un seul projet, ou pour une période plus courte.

Si vous construisez activement votre réseau, certaines des personnes que vous rencontrez peuvent devenir vos clients.

Par exemple, vous pouvez rencontrer un comptable local qui souhaite mettre à jour son site web. Et peut-être ajouter la possibilité de programmer une consultation, ou d'accepter un paiement par carte de crédit pour une facture. Ce sont des fonctionnalités courantes que les petites entreprises peuvent demander, et vous pouvez devenir assez bon pour les mettre en œuvre.

Vous pouvez aussi rencontrer des gérants de petites entreprises qui ont besoin d'un système ERP, ou d'un système CRM, ou d'un système d'inventaire, ou de l'un des innombrables autres outils.

Dans de nombreux cas, il existe un outil open source que vous pouvez déployer et configurer pour eux. Ensuite, vous pouvez simplement leur apprendre à utiliser ce système. Et vous pouvez leur facturer des frais de service mensuels pour être "de garde" et prêt à corriger les problèmes qui pourraient survenir.

Devrais-je utiliser un contrat pour le travail en freelance ?

Vous voudrez trouver un modèle de contrat standard, le personnaliser et le faire approuver par un avocat.

Il peut sembler gênant de faire signer un contrat à la boulangerie locale juste pour aider à mettre à jour leur site web ou leur présence sur les réseaux sociaux. Mais le faire rendra toute la transaction plus professionnelle qu'un simple accord verbal.

Il est peu probable qu'une petite entreprise vous traîne en justice pour quelques milliers de dollars. Mais au cas où cela arriverait, vous serez content d'avoir signé un contrat.

Combien devrais-je facturer pour le travail en freelance ?

Je prendrais ce que vous gagnez à votre emploi actuel, je calculerais votre taux horaire et je le doublerais. Cela peut paraître beaucoup d'argent, mais le travail en freelance est bien plus difficile que le travail régulier. Vous devez apprendre beaucoup.

Alternativement, vous pourriez simplement facturer au projet. "Je vais déployer et configurer ce système pour vous pour 1 000 $."

Assurez-vous simplement de spécifier une période pendant laquelle vous êtes prêt à maintenir le projet. Vous ne voulez pas que les gens vous appellent 3 ans plus tard en s'attendant à ce que vous reveniez réparer un système que personne n'a entretenu.

Comment m'assurer que les clients freelance me paient ?

Beaucoup d'autres freelances – moi y compris – utilisent cette approche simple : demandez la moitié de votre rémunération d'avance, avant de commencer le travail. Et quand vous pouvez démontrer que vous avez fait la moitié du chemin, demandez l'autre moitié.

Essayez toujours d'obtenir tout l'argent avant de terminer réellement le projet. De cette façon, le client ne pourra pas faire miroiter l'argent sous votre nez pour essayer d'obtenir du travail supplémentaire de votre part.

Si vous êtes déjà payé en totalité, le travail que vous ferez pour aider votre client après coup transmettra : "Je me dépasse pour vous."

Ce qui est une ambiance totalement différente de : "Oh oh – allez-vous seulement me payer pour tout ce travail que je fais ?"

Devrais-je utiliser un site de freelance comme Upwork ou Fiverr ?

Si vous êtes dans une partie rurale du monde et que vous ne trouvez aucun client localement, vous pourriez essayer certains de ces sites de freelance. Mais sinon, je ne me concentrerais pas sur eux. Voici pourquoi :

Quand vous essayez de décrocher des contrats sur un site de freelance, vous êtes en compétition avec tous les freelances du monde entier. Beaucoup d'entre eux vivront dans des villes qui ont un coût de la vie bien inférieur au vôtre. Certains d'entre eux ne se soucieront même pas vraiment de leur réputation comme vous, et pourraient être prêts à livrer un travail de piètre qualité.

Dans une certaine mesure, ces sites favorisent un phénomène de "course vers le bas" où la personne qui propose de faire le travail au prix le plus bas obtient généralement le job.

Si vous vous concentrez plutôt sur la recherche de clients via votre propre réseau local, vous n'aurez pas à rivaliser avec ces freelances à l'étranger.

Et il en va de même pour les personnes qui cherchent de l'aide auprès de développeurs freelance. Si jamais vous voulez embaucher un freelance, je vous recommande vivement de travailler avec quelqu'un que vous pouvez rencontrer en personne, qui a des liens avec votre communauté.

Quelqu'un qui vit dans votre ville depuis plusieurs années, et qui assiste à beaucoup des mêmes rassemblements sociaux que vous – il sera beaucoup moins enclin à essayer de profiter de vous. Si vous et votre contrepartie vous souciez tous deux de votre réputation, vous êtes tous deux investis dans un partenariat qui fonctionne.

Vous pouvez chacun être une histoire de succès dans les portfolios de l'autre.

Le freelance, c'est comme diriger une entreprise d'une seule personne. Et cela signifie beaucoup de travail caché.

Ne sous-estimez pas la quantité de "travail caché" impliquée dans la gestion de votre activité de développement en freelance.

D'une part, vous voudrez peut-être créer votre propre entité juridique.

Aux États-Unis, l'approche la plus courante consiste à créer une Limited Liability Company (LLC) et à mener des affaires en tant que cette société – même si vous êtes la seule personne à y travailler.

Cela peut simplifier vos impôts. Et si jamais vous faites une erreur et êtes poursuivi par un client, votre entité juridique peut vous aider à vous isoler de la responsabilité personnelle, de sorte que ce soit votre LLC qui fasse faillite – pas vous personnellement.

Vous pouvez aussi envisager de prendre une assurance responsabilité civile pour vous protéger davantage contre cela.

Rappelez-vous que lorsque vous travaillez en freelance, vous devez généralement payer des impôts à la fin de l'année, alors assurez-vous d'épargner pour cela.

Pour créer votre LLC, vous pouvez bien sûr simplement trouver des documents types en ligne et les déposer vous-même. Mais si vous êtes sérieux au sujet du freelance, je vous recommande de parler avec un avocat et/ou un comptable spécialisé dans les petites entreprises pour vous assurer que vous avez tout configuré correctement.

Quand devrais-je arrêter le freelance et commencer à chercher un emploi ?

Si vous êtes capable de payer vos factures en freelance, vous voudrez peut-être simplement continuer. Avec le temps, vous pourriez même être en mesure de créer votre propre agence de développement de logiciels, et d'embaucher d'autres développeurs pour vous aider.

Cela dit, si vous aspirez à la stabilité d'un emploi de développeur, vous avez peut-être de la chance. Les clients freelance peuvent se transformer en emplois à plein temps si vous restez avec eux assez longtemps. À un certain point, il peut être économiquement logique pour un client de vous proposer simplement un emploi à plein temps à un taux horaire inférieur. Vous obtenez la stabilité d'une semaine de travail de 40 heures, et ils obtiennent vos compétences à plein temps.

Vous pourriez aussi être en mesure de garder quelques clients freelance quand vous obtenez un emploi. Cela peut être un complément appréciable à vos revenus. Mais gardez à l'esprit que, comme nous l'apprendrons dans le prochain chapitre, votre premier emploi de développeur peut être une responsabilité dévorante. Du moins au début.

À quel point cette première année de travail en tant que développeur professionnel va-t-elle être mouvementée ? Eh bien, parlons-en.

Chapitre 5 : Comment réussir votre premier emploi de développeur

"Un navire dans un port est en sécurité. Mais ce n'est pas pour cela que les navires sont construits." – Grace Hopper, mathématicienne, contre-amiral de l'US Navy et pionnière de l'informatique

Une fois que vous obtenez votre premier emploi de développeur, c'est là que le véritable apprentissage commence.

Vous apprendrez à travailler de manière productive aux côtés d'autres développeurs.

Vous apprendrez à naviguer dans de grandes bases de code legacy.

Vous apprendrez les systèmes de contrôle de version, les outils d'intégration continue et de déploiement continu (CI/CD), les outils de gestion de projet, et plus encore.

Vous apprendrez à travailler sous la direction d'un engineering manager. Comment livrer avant une échéance. Et comment gérer une grande part d'ambiguïté au travail.

Plus important encore, vous apprendrez à vous gérer vous-même.

Vous apprendrez à briser les barrières psychologiques qui nous affectent tous, comme le syndrome de l'imposteur. Vous apprendrez vos limites, et comment les repousser très légèrement.

L'heure de l'histoire : comment un enseignant dans la trentaine a-t-il réussi son premier emploi de développeur ?

La dernière fois dans l'Heure de l'histoire : Quincy a décroché son premier emploi de développeur dans une startup tech locale. Il allait travailler comme l'un des douze développeurs maintenant une base de code large et sophistiquée. Et il n'avait aucune idée de ce qu'il faisait...

Je me suis réveillé à 4 heures du matin et je n'ai pas pu me rendormir. J'ai essayé. Mais j'avais cette brûlure dans la poitrine. Cette anxiété. Cette panique.

J'avais travaillé pendant une décennie dans l'éducation. D'abord comme tuteur. Puis comme enseignant. Et enfin comme directeur d'école.

Dans quelques heures, j'allais tout recommencer tout en bas de l'échelle, en travaillant comme développeur.

Est-ce que mes apprentissages passés – mes succès passés – auraient seulement de l'importance dans cette nouvelle carrière ?

J'ai fait ce que je fais toujours quand je ressens de l'anxiété – je suis allé courir. Je dévalais les collines, ma lampe frontale oscillant dans l'obscurité. Quand j'ai atteint la plage, j'ai couru le long de l'océan alors que le soleil pointait le bout de son nez au-dessus de la cime des arbres.

Au moment où je suis rentré, ma femme partait déjà au travail. Elle m'a dit de ne pas m'inquiéter. Elle a dit : "Je t'aimerai toujours même si tu te fais virer pour incompétence."

Quand je suis arrivé à mon nouveau bureau, il n'y avait personne. En tant qu'enseignant, j'avais l'habitude d'arriver à l'école à 7h30 pile. Mais j'ai vite réalisé que la plupart des développeurs de logiciels ne commencent pas le travail si tôt.

Je me suis donc assis en tailleur dans le couloir d'entrée, codant en suivant des tutoriels sur mon netbook.

Une employée s'est approchée de moi avec un air inquiet. Elle pensait probablement que j'étais un squatteur. Mais je l'ai rassurée sur le fait que je travaillais effectivement maintenant pour son entreprise, et je l'ai convaincue de me laisser entrer.

C'était surréaliste de traverser le bureau vide en open-space vers l'espace des développeurs, avec seulement la lumière de l'enseigne de sortie pour me guider.

J'ai installé mon netbook sur un bureau debout vide et j'ai terminé mon tutoriel de codage.

Un peu plus tard, les lumières se sont allumées autour de moi. Mon patron était arrivé. Au début, il n'a pas reconnu ma présence. Il s'est juste assis à son bureau et a commencé à envoyer des rafales de frappes sur son clavier mécanique.

"Larson," finit-il par dire. "Prêt pour votre grand premier jour ?"

Je ne l'étais pas. Mais je voulais signaler de la confiance. J'ai donc dit les mots prononcés pour la première fois dans Big Trouble in Little China (Les Aventures de Jack Burton dans les griffes du Mandarin), l'un de mes films préférés des années 80 : "Je suis né prêt."

Vous avez probablement entendu "Je suis né prêt" un million de fois. Mais cela a été prononcé pour la première fois en 1986 par Jack Burton à son ami Wang Chi, alors qu'ils s'apprêtaient à affronter un sorcier millénaire dans son entrepôt de la mort. Je n'arrive pas à croire que mes parents m'aient laissé regarder ça à l'époque, mais je suis content qu'ils l'aient fait.

"Génial," dit mon patron. "Allons vous chercher une machine."

"Oh, j'en ai déjà une," dis-je, tapotant mon netbook à 200 $. "Ce bébé tourne sous Linux Mint, et j'ai déjà personnalisé mon fichier .emacs pour pouvoir..."

"On est sur Mac ici," dit-il en se dirigeant vers un placard de rangement. Il fouilla un instant et ressortit. "Tenez. C'est un modèle d'il y a 3 ans, mais ça devrait faire l'affaire. On l'a remis à zéro."

J'ai commencé à dire que j'étais déjà familier avec ma configuration, et que je pouvais travailler beaucoup plus vite avec, mais il n'a rien voulu entendre.

"On utilise tous les mêmes outils. Ça facilite beaucoup la collaboration. La convention plutôt que la configuration, vous savez."

C'était la première fois que j'entendais l'expression "convention over configuration" mais elle reviendrait souvent au cours des jours suivants.

J'ai passé les heures suivantes à configurer mon nouvel ordinateur de travail alors que les autres développeurs arrivaient progressivement.

Il était presque 10 heures quand nous avons commencé notre réunion d'équipe "standup". Nous nous tenions tous en cercle près du tableau blanc. Nous faisions chacun notre tour un rapport sur ce sur quoi nous travaillions ce jour-là.

Tout le monde donnait des mises à jour de statut rapides et précises.

Quand ce fut mon tour, j'ai commencé à me présenter. J'étais déjà assez anxieux, quand est entré nul autre que Mike, ce gars ultra-marathonien qui dirigeait les événements Startup de Santa Barbara. Il croquait des mini-carottes, ayant déjà couru environ 50 kilomètres ce matin-là.

Après que j'ai eu fini, Mike prit la parole, m'accueillant et disant qu'il m'avait vu à certains de ses événements. Il donna ensuite une mise à jour de statut de 15 secondes sur une fonctionnalité sur laquelle il travaillait.

Toute la réunion ne prit qu'environ 10 minutes, et tout le monde se dispersa vers son bureau.

J'ai fini par réussir à faire tourner la base de code de l'entreprise sur mon nouvel ordinateur portable. C'était une application Ruby on Rails qui avait grandi pendant 5 ans. J'ai lancé la commande rake stats et j'ai vu qu'il y avait des millions de lignes de code. J'ai frissonné. Comment pourrais-je jamais comprendre tout cela ?

Mon voisin, un développeur barbu et bourru, dit : "Eh, la plupart de tout ça, ce sont juste des packages. La base de code réelle sur laquelle tu travailleras ne fait peut-être que 100 000 lignes. Ne t'inquiète pas. Tu vas prendre le coup de main."

J'ai dégluti, mais je me suis dit : "C'est moins que des millions de lignes. C'est donc une bonne chose."

"Je m'appelle Nick au fait," dit-il en se présentant. "Si tu as besoin d'aide, fais-le moi savoir. Ça fait pas mal d'années que je patauge dans cette base de code, donc je devrais pouvoir t'aider."

Au cours des jours suivants, j'ai criblé Nick de questions sur chaque système interne que je rencontrais.

Finalement, Nick a commencé à mettre son statut de messagerie sur "mode code" et à mettre son casque à réduction de bruit. Il me tournait un peu le dos, avec un langage corporel signifiant : "laisse-moi tranquille pour que je puisse aussi avancer sur mon propre travail."

Ce fut l'une de mes premières leçons sur la dynamique d'équipe. On ne veut pas abuser de son hospitalité avec trop de questions. On doit devenir meilleur pour apprendre les choses par soi-même.

Mais c'était une base de code massive, et elle était largement non documentée, à part des commentaires en ligne et un wiki d'équipe assez pauvre.

Comme c'était une base de code propriétaire sur laquelle seuls les développeurs autour de moi travaillaient, je ne pouvais pas utiliser Stack Overflow pour comprendre où se trouvait telle ou telle logique. Je devais juste tâtonner dans le noir.

J'ai commencé à faire un roulement sur le voisin que je dérangerais pour une question particulière. Mais j'avais l'impression d'épuiser rapidement tout l'enthousiasme qu'ils pouvaient encore avoir pour moi en tant que coéquipier.

J'ai sur-corrigé. Je suis devenu timide à l'idée de poser même des questions simples. Je me suis fixé comme règle d'essayer pendant 2 heures de me débloquer avant de demander de l'aide.

À un moment donné, après avoir piétiné pendant plusieurs heures, j'ai fini par demander de l'aide. Quand mon manager a découvert que j'avais été bloqué toute la matinée, il a demandé : "Pourquoi n'as-tu pas demandé de l'aide plus tôt ?"

Une autre difficulté était de comprendre la base de code elle-même – le "monolithe" et ses nombreux microservices.

La base de code avait des milliers de tests unitaires et de tests d'intégration. Chaque fois que vous écriviez une nouvelle contribution au code, vous étiez également censé écrire des tests. Ces tests permettaient de s'assurer que votre code faisait ce qu'il était censé faire – et ne cassait aucune fonctionnalité existante.

Je "cassais souvent le build" en soumettant du code que je pensais suffisamment testé – pour finir par voir mon code casser une autre partie de l'application à laquelle je n'avais pas pensé. Cela frustrait toute l'équipe, qui était incapable de fusionner son propre code tant que le problème racine n'avait pas été corrigé.

Le build cassait plusieurs fois par semaine. Et je n'étais pas la seule personne à faire ce genre d'erreurs. Mais j'avais l'impression d'être le seul.

Il y avait des jours où j'avais l'impression de ne pas être fait pour être développeur. Je me disais : "À qui je veux faire croire ça ? Je me réveille un jour et je décide que je vais être développeur ?"

Je n'arrêtais pas d'entendre les échos de toutes ces choses que mes amis développeurs m'avaient dites un an plus tôt, quand je commençais tout juste mon parcours de codage.

"Comment vas-tu rivaliser avec des gens qui ont grandi en codant depuis leur plus jeune âge ?"

"Tu vas devoir boire un océan entier de connaissances."

"Pourquoi ne pas t'en tenir à ce pour quoi tu es doué ?"

Je prenais des pauses de plus en plus longues pour m'éloigner de mon ordinateur. Le bureau avait une cuisine remplie de snacks. Je trouvais plus d'excuses pour me lever et aller chercher un snack. N'importe quoi pour retarder le sentiment écrasant que je n'avais aucune idée de ce que je faisais.

Les premiers mois furent rudes. Pendant les réunions standup du matin, j'avais l'impression que tout le monde avançait vite. Fermant des bugs ouverts et livrant des fonctionnalités. J'avais l'impression de n'avoir rien à dire. Je travaillais toujours sur la même fonctionnalité que la veille.

Chaque jour, quand je me réveillais et me préparais pour le travail, je ressentais de l'effroi. "Ça va être le jour où ils vont me licencier."

Mais ensuite j'allais au travail et tout le monde était plutôt gentil, plutôt patient. Je demandais de l'aide si j'étais vraiment bloqué. Je faisais quelques progrès, et je corrigeais peut-être un bug ou deux.

Je devenais plus rapide pour naviguer dans la base de code. Je devenais plus rapide pour lire les traces de pile quand mon code faisait une erreur. Je livrais des fonctionnalités à un rythme plus soutenu qu'auparavant.

Chaque fois que mon patron m'appelait dans son bureau, je me disais : "Oh non, j'avais raison. Je vais me faire licencier aujourd'hui." Mais il me confiait juste d'autres bugs à corriger, ou des fonctionnalités à développer. Ouf.

C'était la chose la plus surréelle – moi terrifié à l'idée d'être sur le point de me faire virer, et lui n'ayant aucune idée que quelque chose n'allait pas.

Bien sûr, j'avais déjà entendu le terme "syndrome de l'imposteur". Mais je ne réalisais pas que c'était ce que je vivais. Je pensais sûrement souffrir du syndrome "je suis nul en code", n'est-ce pas ?

Un jour, j'étais assis à côté de Nick, et il avait l'air assez épuisé. J'ai proposé de lui aller chercher un soda à la cuisine.

Quand je suis revenu, il a ouvert la canette, a pris une gorgée et s'est adossé à sa chaise, fixant son moniteur rempli de code. "Ce bug, mec. Trois semaines à essayer de corriger ce seul bug. À ce stade, j'en rêve la nuit."

"Trois semaines à essayer de corriger le même bug ?" demandai-je. Je n'avais jamais entendu parler d'une telle chose.

"Certains bugs sont plus coriaces à craquer que d'autres. Celui-là est vraiment vicieux."

J'ai eu l'impression que quelqu'un venait de me gifler avec un saumon. J'avais vu mon travail comme des blocs de tâches. Comme s'il devait falloir une demi-journée pour corriger un bug, et que si cela prenait plus de temps, je faisais quelque chose de mal.

Mais Nick était là – avec son diplôme d'informatique de l'Université de Californie et ses années d'expérience sur cette même base de code – et il était bloqué pendant trois semaines sur un seul bug.

Peut-être avais-je été trop dur avec moi-même. Peut-être que certains de ces bugs que j'avais corrigés n'étaient pas nécessairement des "bugs d'une demi-journée", mais des "bugs de deux ou trois jours". Oui, j'étais inexpérimenté et lent. Mais même ainsi, peut-être que je m'imposais des standards irréalistes.

Après tout, quand nous budgétisions du temps pour les fonctionnalités, nous avions parfois des "fonctionnalités de 5 jours" ou même des "fonctionnalités de 2 semaines". Nous ne faisions pas cela pour les bugs, mais ils variaient probablement de la même manière.

Je suis rentré chez moi et j'ai lu davantage sur le syndrome de l'imposteur. Et ce que j'ai lu expliquait une grande partie de mon anxiété.

Au cours des mois suivants, j'ai continué à construire des fonctionnalités pour la base de code. J'ai continué à collaborer avec mon équipe. C'était toujours un travail difficile, qui faisait chauffer le cerveau. Mais cela commençait à devenir un peu plus facile.

J'ai tissé des liens avec mes coéquipiers chaque jour au déjeuner autour de jeux de société. Une semaine, nous avons eu un tournoi d'échecs à l'échelle de l'entreprise.

Au bout de quelques tours, j'ai joué contre le CEO.

Le CEO a un style de jeu d'échecs peu orthodoxe. Il a utilisé une ouverture farfelue que peu de joueurs d'échecs sérieux choisiraient. Et j'ai pu prendre une avance précoce dans la partie.

Mais au cours des coups suivants, il a pu reprendre lentement le contrôle de la partie. Il a fini par prendre le dessus et m'a battu.

Quand je lui ai demandé comment il trouvait le temps de garder ses compétences aux échecs affûtées tout en dirigeant une entreprise, il a dit : "Oh, je ne le fais pas. Je ne joue qu'une ou deux fois par an."

Puis il s'est arrêté un instant, la main figée devant lui, comme s'il s'apprêtait à se lancer dans un cours. Il a dit : "Mon oncle était un joueur d'échecs de compétition. Et il m'a juste donné un seul conseil à suivre : chaque fois que ton adversaire bouge, ralentis et essaie de comprendre le jeu de son point de vue – pourquoi a-t-il fait ce coup ?"

Il s'est incliné puis s'est excusé pour courir à une réunion.

J'ai beaucoup repensé à ce qu'il a dit au fil des ans. Et j'ai réalisé que ce conseil ne s'applique pas seulement aux échecs. On peut l'appliquer à n'importe quelle situation conflictuelle.

Si vous devez répéter une tâche, vous devriez l'automatiser

Une autre leçon que j'ai apprise sur le développement de logiciels : comme j'étais la personne la plus junior de l'équipe, on m'assignait souvent le "sale boulot" que personne d'autre ne voulait faire. L'une de ces tâches était d'être la "nounou du build".

Chaque fois que quelqu'un cassait le build, je récupérais la dernière version de notre branche principale et j'utilisais git bisect pour essayer d'identifier le commit qui l'avait cassé.

J'ouvrais ce commit, je lançais les tests et je comprenais ce qui n'allait pas. Ensuite, j'envoyais un message à la personne qui avait cassé le build, lui disant ce qu'elle devait corriger.

Je suis devenu très rapide à faire ça. Dans une journée remplie de rapports de bugs déroutants et de demandes de fonctionnalités ambiguës, j'avais hâte que le build casse. Cela me donnait une chance de me sentir utile rapidement.

Il ne fallut pas longtemps avant que quelqu'un dans l'équipe dise : "Vu la fréquence à laquelle le build casse, on devrait juste automatiser ça."

Je n'ai rien dit, mais je me suis senti sur la défensive. C'était une mauvaise idée. Comment un script pourrait-il faire un aussi bon travail pour trouver le commit coupable que moi – un développeur en chair et en os ?

Cela a pris quelques jours. Mais bien sûr, l'un de mes coéquipiers a pondu un script. Et je n'ai plus eu besoin d'être la nounou du build.

C'était étrange de voir un message indiquant que le build avait échoué, puis un instant plus tard de voir un message disant quel commit avait cassé le build et qui devait aller le corriger.

Je me sentais indigné. Je n'ai rien dit, mais dans ma tête je pensais : "C'est censé être mon travail. Ce script a pris mon boulot."

Mais bien sûr, je repense maintenant à ma réaction et je ris. Je m'imagine, maintenant dans la quarantaine, en train de tout laisser tomber plusieurs fois par semaine pour être la nounou du build.

Parce qu'en pratique, si une tâche peut être automatisée – si vous pouvez la décomposer en étapes distinctes qu'un ordinateur peut faire de manière fiable pour vous – alors vous devriez probablement l'automatiser.

Il y a plein de travaux plus intéressants que vous pouvez faire de votre temps.

Ce graphique de XKCD peut vous aider à déterminer si une tâche vaut l'investissement en temps pour être automatisée.

Leçons des anciens du village

J'ai beaucoup appris des autres membres de l'équipe. J'ai appris des concepts de conception de produits de Mike. Il m'a emmené courir sur la plage, et m'a appris à courir sur l'avant-pied, là où la plante de vos pieds touche le sol avant vos talons. C'est un peu plus doux pour vos articulations.

Et j'ai appris les concepts d'ingénierie logicielle agile de Nick. Il m'a aidé à choisir de bons livres de développement logiciel dans la bibliothèque de l'entreprise. Et il m'a même invité à une pendaison de crémaillère, et j'ai pu rencontrer ses enfants.

Après environ un an de travail pour l'entreprise, j'ai senti qu'il était temps d'essayer de voler de mes propres ailes, et de construire des projets autour de l'apprentissage en ligne. Je me suis assis avec le CTO pour lui annoncer la nouvelle de mon départ.

J'ai dit : "Je suis reconnaissant que vous m'ayez tous embauché, même si j'étais clairement le développeur le plus faible de l'entreprise."

Il a juste laissé échapper un rire et a dit : "Bien sûr, quand tu as commencé, tu étais le pire développeur de l'équipe. Je dirais que tu es toujours le pire développeur de l'équipe."

Je suis resté assis là à lui sourire maladroitement, clignant des yeux, ne sachant pas s'il était juste en colère que je parte.

Et puis il a dit : "Mais c'est malin. Tu es malin. Parce que tu veux toujours être le pire musicien du groupe. Tu veux toujours être entouré de gens qui sont meilleurs que toi. C'est comme ça que tu grandis."

Deux semaines plus tard, j'ai validé mes modifications de code pour la journée et j'ai transmis mes tickets ouverts. J'ai remis mon Mac aux réglages d'usine et je l'ai remis à mon manager.

J'ai serré la main de mes coéquipiers et je suis sorti dans l'air du soir californien.

J'ai démarré sur les chapeaux de roue, alignant des contrats de freelance pour payer les factures. Et j'ai repéré un appartement dans la Bay Area, juste de l'autre côté du pont du cœur battant de la tech dans le quartier South of Market de San Francisco.

J'étais désormais un développeur professionnel avec un an d'expérience déjà derrière moi.

J'étais prêt à rêver de nouveaux rêves et à faire de nouveaux choix.

Je partais pour le pays des startups.

Leçons de ma première année en tant que développeur

J'ai fait beaucoup de choses correctement pendant ma première année en tant que développeur professionnel. Je me donne un B-.

Mais si j'avais la chance de tout recommencer, il y a des choses que je ferais différemment.

Voici quelques conseils. Puissent-ils maximiser votre apprentissage et minimiser vos peines de cœur.

Laissez votre ego à la porte

Beaucoup de personnes entrant dans le domaine du développement de logiciels commenceront tout en bas. Un titre que vous pourriez avoir est "Junior Developer".

Il peut être un peu gênant d'avoir un certain âge et d'avoir le mot "junior" dans son titre. Mais avec de la patience et du travail acharné, vous pouvez passer outre.

Un problème auquel je faisais face chaque jour était – j'avais 10 ans d'expérience professionnelle. Je n'étais pas un employé débutant. Oui, j'étais nouveau dans le développement, mais j'étais assez expérimenté dans l'enseignement et même la gestion de personnes. (J'avais géré 30 employés à mon dernier poste d'enseignant.)

Et pourtant – malgré toute mon expérience professionnelle passée – j'étais toujours un développeur débutant. J'étais toujours un novice. Un néophyte. Un bleu.

Même si j'avais envie de crier "J'étais le patron avant – je n'ai pas besoin que vous me fassiez du baby-sitting" – la vérité était que j'avais besoin de baby-sitters.

Et si je cassais accidentellement la production ? Et si j'introduisais une vulnérabilité de sécurité dans l'application ? Et si j'effaçais toute la base de données ? Ou si je cryptais quelque chose d'important et perdais la clé ?

Ces genres de désastres arrivent tout le temps.

La réalité est qu'en tant que nouveau développeur, vous êtes comme un éléphant dans un magasin de porcelaine, essayant de marcher prudemment, mais brisant tout sur votre passage.

Ne vous laissez pas impatienter par vos coéquipiers. Résistez à la tentation de parler de vos diplômes avancés, des prix que votre travail a gagnés, ou de cette fois où le maire vous a remis les clés de la ville. (D'accord, cette dernière chose ne m'est jamais arrivée.)

Pas seulement parce que cela vous rendra difficile à vivre professionnellement. Parce que cela vous distraira de la tâche à accomplir.

Pendant les premiers mois de ma carrière de développeur, j'ai utilisé mes réalisations passées comme une sorte de sucette. "Ouais, je suis nul en code, mais je suis phénoménal pour enseigner la grammaire anglaise. Ai-je mentionné que je dirigeais une école ?"

Quand vos doigts sont sur le clavier, et que vos yeux sont sur l'éditeur de code, vous devez laisser partir ce moi passé. Vous pourrez vous délecter de l'accomplissement d'hier ce soir, une fois le travail d'aujourd'hui terminé.

Mais pour l'instant, vous devez accepter toutes les émotions qui viennent avec le fait d'être à nouveau un débutant. Vous devez vous concentrer sur la tâche à accomplir et faire le job.

C'est probablement juste le syndrome de l'imposteur qui parle

Presque tout le monde que je connais a vécu le syndrome de l'imposteur. Ce sentiment que vous n'êtes pas à votre place. Ce sentiment qu'à tout moment vos coéquipiers vont voir à quel point votre code est terrible et vous exposer comme n'étant pas un "vrai développeur".

Dans une certaine mesure, le sentiment ne disparaît pas. Il est toujours là dans un coin de votre tête, prêt à pointer le bout de son nez quand vous essayez de faire quelque chose de nouveau.

"Pourrais-tu m'aider à passer ce message d'erreur ?" "Euh... je ne suis pas sûr d'être la meilleure personne à qui demander."

"Pourrais-tu faire du pair programming avec moi sur l'implémentation de cette fonctionnalité ?" "Euh... je suppose si tu ne trouves personne de plus qualifié."

"Pourrais-tu donner une conférence à notre prochaine conférence ?" "Euh... moi ?"

J'ai rencontré des ingénieurs seniors qui souffrent encore occasionnellement du syndrome de l'imposteur, plus d'une décennie après le début de leur carrière.

Quand vous vous sentez inadéquat ou non préparé, c'est peut-être juste le syndrome de l'imposteur.

Bien sûr – si vous me donniez un scalpel et disiez "aide-moi à faire une chirurgie cardiaque", je me sentirais comme un imposteur. Dans une certaine mesure, se sentir dépassé est tout à fait raisonnable si vous êtes effectivement dépassé.

Le problème est que si vous avez pratiqué le développement de logiciels, vous pouvez être capable de faire quelque chose mais toujours souffrir inexplicablement d'anxiété.

Je ne suis pas médecin. Mais mon instinct est que – pour la plupart des gens – le syndrome de l'imposteur diminuera progressivement avec le temps, à mesure que vous pratiquerez davantage et gagnerez en confiance.

Mais il peut surgir au hasard. Je n'ai pas peur d'admettre que je ressens parfois des pointes de syndrome de l'imposteur en faisant une nouvelle tâche, ou une que je n'ai pas faite depuis un moment.

La clé est de simplement l'accepter : "C'est probablement juste le syndrome de l'imposteur qui parle."

Et de continuer.

Trouvez votre tribu. Mais ne tombez pas dans le tribalisme

Quand vous obtiendrez votre premier emploi de développeur, vous travaillerez aux côtés d'autres développeurs. Youpi – vous avez trouvé votre tribu.

Vous passerez beaucoup de temps avec eux, et vous pourriez tous commencer à vous sentir comme une unité soudée.

Mais n'ignorez pas les personnes non-développeurs autour de vous.

Dans mon histoire ci-dessus, j'ai parlé de Mike, le Product Manager qui dirigeait aussi des événements de startup. Il était "non-technique". Sa connaissance du codage était limitée au mieux. Mais j'oserais dire que j'ai appris autant de lui que de n'importe qui d'autre dans l'entreprise.

Vous travaillerez peut-être avec d'autres personnes d'autres départements – designers, product managers, project managers, informaticiens, testeurs QA, marketeurs, même des gens de la finance et de la comptabilité. Vous pouvez aussi apprendre beaucoup de ces personnes.

Oui, vous devriez vous concentrer sur la construction d'un tissu conjonctif solide entre vous et les autres développeurs de l'équipe. Mais restez curieux. Fréquentez d'autres personnes à la cantine ou lors d'événements d'entreprise. On ne sait jamais qui sera la prochaine personne à vous aider à développer vos compétences, votre réseau ou votre réputation.

Ne vous installez pas trop confortablement et ne vous spécialisez pas trop tôt

Je donne souvent ce conseil aux personnes qui commencent leur parcours de codage : "apprenez des compétences de codage générales (JavaScript, SQL, Linux, etc.) puis spécialisez-vous sur le tas."

L'idée est qu'une fois que vous comprenez comment fonctionnent les outils les plus courants, vous pouvez ensuite aller apprendre les équivalents moins courants de ces outils.

Par exemple, une fois que vous avez appris PostgreSQL, vous pouvez facilement apprendre MySQL. Une fois que vous avez appris Node.js, vous pouvez facilement apprendre Ruby on Rails ou Java Spring Boot.

Mais certaines personnes se spécialisent trop tôt au travail. Leur patron pourrait leur demander de "posséder" une certaine API ou fonctionnalité. Et s'ils font du bon travail avec ça, leur patron pourrait continuer à leur donner des projets similaires.

Vous ne gérez que vous-même, mais votre patron gère beaucoup de gens. Il est peut-être trop occupé pour développer une compréhension nuancée de vos capacités et intérêts. Il pourrait en venir à vous voir comme "la personne XYZ" et vous donner seulement des tâches liées à cela.

Mais vous savez ce pour quoi vous êtes bon, et ce qui vous intéresse. Vous pouvez essayer de vous porter volontaire pour des projets en dehors de votre zone de confort. Si vous pouvez amener votre patron à vous les assigner, vous pourrez continuer à élargir vos compétences, et potentiellement travailler avec de nouvelles équipes.

Rappelez-vous : votre patron est peut-être responsable de votre performance à votre poste, mais vous êtes responsable de votre performance tout au long de votre carrière.

Prenez des projets qui remplissent à la fois votre obligation envers votre employeur, et vous positionnent bien pour vos objectifs de carrière à long terme.

Épilogue : Vous pouvez le faire

S'il y a un message que je veux vous laisser ici, c'est celui-ci : vous pouvez le faire.

Vous pouvez apprendre ces concepts.

Vous pouvez apprendre ces outils.

Vous pouvez devenir un développeur.

Ensuite, dès que quelqu'un vous remettra de l'argent pour que vous l'aidiez à coder quelque chose, vous passerez au rang de développeur professionnel.

Apprendre à coder et obtenir un premier emploi de développeur est un processus intimidant. Mais ne soyez pas intimidé.

Si vous persévérez, vous finirez par réussir. C'est juste une question de pratique.

Construisez vos projets. Montrez-les à vos amis. Construisez des projets pour vos amis.

Construisez votre réseau. Aidez les gens que vous rencontrez en chemin. On récolte ce qu'on sème. Vous obtiendrez ce qui vous revient.

Il n'est pas trop tard. La vie est longue.

Vous repenserez à ce moment dans quelques années et vous serez content d'avoir fait un choix.

Prévoyez que cela prendra du temps. Prévoyez l'incertitude.

Mais par-dessus tout, revenez toujours au clavier. Continuez à vous rendre aux événements. Continuez à partager vos victoires avec vos amis.

Comme Lao Tseu, le Vieux Maître, l'a dit un jour :

"Un voyage de mille lieues commence par un seul pas."

En finissant ce livre, vous avez déjà fait un pas. Diable, vous avez peut-être déjà fait de nombreux pas vers vos objectifs.

L'élan est tout. Alors gardez cet élan vers l'avant que vous avez déjà construit au cours de ces dernières heures avec ce livre.

Commencez à coder votre prochain projet aujourd'hui.

Et rappelez-vous toujours :

Vous pouvez le faire.