L’histoire de Pedro, reconverti de chauffeur routier à développeur Ruby on Rails à 38 ans
(writesoftwarewell.com)- Pedro David Garcia Lopez, originaire d’Espagne, a émigré au Royaume-Uni en 2015 pour travailler comme chauffeur routier, avant de changer de carrière à 38 ans pour devenir développeur Ruby on Rails
- À l’époque où il était chauffeur, il ne passait généralement que 4 à 6 jours par mois à la maison, ce qui rendait difficile de dégager un temps d’apprentissage régulier entre son rôle familial et ses longues heures de travail
- À partir de septembre 2019, il s’est fixé pour objectif de devenir développeur en moins d’un an et a appris Ruby, Sinatra, Rails, React après être passé par Python, des cours Udemy puis le bootcamp Flatiron School
- En 2020, en pleine période COVID, il a dû chercher son premier poste de développeur et, après plusieurs mois sans nouvelles pour des entretiens, a accepté une première opportunité à Manchester malgré un salaire bas et de longs trajets domicile-travail
- Aujourd’hui, il apprécie fortement la productivité et le plaisir qu’apportent Ruby et Rails, et conseille aux nouveaux programmeurs de se concentrer sur la manière d’apprendre, les questions et la recherche de mentors plutôt que de vouloir tout poursuivre à la fois
Le parcours d’un chauffeur routier devenu développeur
- Pedro David Garcia Lopez est un Espagnol de 42 ans qui a émigré au Royaume-Uni en 2015 et prévoit de revenir en Espagne pour se rapprocher de sa famille
- Il est arrivé au Royaume-Uni en 2015 comme chauffeur routier, avec aussi l’envie d’offrir de nouvelles opportunités à sa fille et d’apprendre correctement l’anglais
- Lorsqu’il travaillait comme chauffeur, il circulait entre le Royaume-Uni et différents pays d’Europe, et ne restait généralement chez lui que 4 à 6 jours par mois
- En tant que conducteur professionnel, il a conduit presque tous les types de véhicules sur la route, s’est rendu au moins une fois dans les pays du continent européen de l’UE, et a parcouru avec son camion une distance suffisante pour faire plusieurs fois le tour de la Terre
L’intérêt pour l’informatique et les premiers échecs d’apprentissage
- Il a découvert l’informatique vers l’âge de 12 ans, lors d’un cours d’été de dactylographie, et s’est passionné pour les ordinateurs en utilisant MS-DOS et Windows 3.1
- Après le décès de son père à 14 ans, il a dû concilier ses études et le soutien de sa famille, ce qui rendait presque impossible l’achat d’un ordinateur à la maison
- À 18 ans, il a travaillé à temps plein, économisé pendant trois mois et acheté son premier ordinateur, un Pentium II, ce qui lui a donné envie d’apprendre la programmation
- Il a commencé avec un livre sur le C++, mais l’approche lui a semblé trop technique et difficile, sans lui permettre de créer quelque chose d’intéressant, puis la vie a pris le dessus et il n’a pas pu approfondir la programmation
La décision de devenir développeur en un an
- À mesure que son anglais s’améliorait et que l’accès aux informations en ligne devenait plus simple, il s’est rappelé son rêve d’enfance de devenir développeur
- Il a suivi sur YouTube des cours de HTML, CSS et JavaScript, et a aussi essayé des formations du type « devenir programmeur en 7 jours »
- freeCodeCamp lui paraissait plus structuré et plus sérieux, mais les longues journées de conduite et son rôle de père et de mari rendaient difficile un rythme d’apprentissage suffisant
- Après de longues années sur la route et consacrées à sa famille, il a décidé de quitter un emploi stable avec un plan clair : devenir développeur en moins d’un an ou abandonner
- Il a commencé sérieusement en septembre 2019, et a appris les bases via Python et des cours Udemy, mais sans acquérir la conviction de pouvoir construire quelque chose par lui-même, même s’il arrivait à reproduire ce qu’il voyait
Flatiron School et le premier emploi
- Après avoir examiné plusieurs options, il a rejoint la Flatiron School
- Il estimait que le risque était limité, puisque s’il ne trouvait pas d’emploi après la formation, il n’aurait pas à payer les frais
- Au bootcamp, il a appris de manière structurée, des bases de Ruby jusqu’à Sinatra, Ruby on Rails et React
- Grâce aux enseignants, aux camarades, aux devoirs et à la pratique, il a dépassé le simple stade de la reproduction pour devenir capable de créer des choses nouvelles
- Il a terminé la formation fin mai 2020 et en a retiré le sentiment de savoir identifier et résoudre des problèmes par lui-même, ainsi que d’apprendre de nouvelles choses
- Son diplôme est arrivé en pleine période COVID, et les confinements limitaient les occasions de passer des entretiens ou d’entrer en contact avec des gens
- En tant que diplômé de bootcamp de 38 ans sans expérience, il est resté plusieurs mois sans recevoir d’invitations en entretien, au point de craindre que son CV ne soit tout simplement écarté
- Sa première opportunité est arrivée à Manchester, à deux heures de train de chez lui, sans politique de télétravail
- Le salaire représentait un tiers de ce qu’il gagnait comme chauffeur routier, et une part importante partait dans les frais de train
- La stack technique reposait sur PHP et jQuery, mais il a accepté l’offre parce qu’il devait faire ses débuts comme développeur
Son regard sur Ruby et Rails
- Il a découvert Ruby et Rails au bootcamp, puis a acquis davantage d’expérience en travaillant chez Superbyte
- Chez Superbyte, il utilisait une stack non standard comprenant Mongoid et un peu de React, mais il y a beaucoup appris auprès de l’équipe
- Après avoir accumulé une expérience professionnelle avec Ruby on Rails, il s’y est encore plus attaché et considère qu’une fois familiarisé avec les conventions de Rails, beaucoup de choses deviennent plus simples
- Parmi les attraits de Ruby et Rails, il cite la communauté et un écosystème qui continue d’évoluer
- Il se dit enthousiaste à l’idée d’adopter l’écosystème Hotwire au lieu de rester sur React, et apprécie le fait que de nombreux besoins puissent être couverts à la manière Rails
Livres, modèles et manière d’apprendre
- Il a commencé à lire des livres techniques plus tard dans sa carrière, en prenant conscience de plusieurs lacunes, et estime qu’il lui en reste encore beaucoup à lire
- Les livres qui l’ont marqué sont les suivants
- Layered Design for Ruby on Rails Applications, Vladimir Dementyev
- Rebuilding Rails, Noah Gibbs
- Ruby Under a Microscope, Pat Shaughnessy
- Practical Object-Oriented Design in Ruby, Sandi Metz
- Il admire les personnes compétentes en programmation et passionnées, ainsi que celles qui partagent leurs connaissances
- Il cite parmi les personnes et initiatives auxquelles il est reconnaissant Quincy Larson, freeCodeCamp et les créateurs de contenu
- Avi Flombaum, qui fut son enseignant à la Flatiron School, est aussi une personne qui l’a marqué, et il estime que les collègues avec lesquels il a travaillé l’ont aidé à grandir comme développeur et comme personne
Sa manière actuelle de travailler et ses outils
- Au cours de sa courte carrière, il a connu le télétravail complet, l’hybride et le travail au bureau cinq jours par semaine
- Avec son projet de retour en Espagne, il prévoit de rejoindre à partir de la mi-avril un poste entièrement à distance chez gocertify
- Chez Superbyte, il est passé d’un poste de Junior Developer à un rôle plus proche d’un semi-senior, en participant à l’écriture de code, à la conception de concepts et à une partie de la R&D
- Il passe la majeure partie de son temps à écrire du code, mais apprécie aussi le pair programming et les revues de PR
- Il considère qu’enseigner est l’une des meilleures façons d’apprendre des concepts, et aime proposer des approches à ses collègues ou apprendre d’eux
- Voici les outils qu’il utilise fréquemment
- Éditeur de code : VS Code
- Interface graphique de base de données : MongoDB Compass
- Terminal : iTerm with oh my zsh
- Navigateur : Chrome
- Notes et gestion de projet : Apple Notes, VS Code Markdown, GitHub projects/issues
- Communication : Microsoft Teams
Les conseils qu’il donne aux nouveaux programmeurs
- Son conseil le plus important est le suivant : apprenez à apprendre
- Chacun apprend et mémorise différemment, il faut donc trouver la méthode d’apprentissage qui vous convient
- Pedro apprend en construisant lui-même, ou en regardant un tutoriel puis en le reproduisant, avant d’aller plus loin vers un domaine qui l’intéresse
- Il lit d’abord les livres sans coder, puis les relit en les utilisant comme guides plutôt que comme supports à reproduire pas à pas
- Il n’est pas nécessaire d’avoir l’impression de devoir tout apprendre : se concentrer sur une chose que l’on aime peut mener plus loin que d’effleurer trop de sujets à la fois
- Il conseille aux nouveaux programmeurs de travailler dur et de poser des questions sans hésiter
- Selon lui, la question la plus stupide est celle qu’on n’a pas posée
- Il dit aussi qu’il ne faut pas se sentir insuffisant ni croire qu’on en sait trop peu
- Il recommande Ruby et Rails, qui peuvent devenir simples et agréables une fois le cap initial passé
- Trouver un mentor ou quelqu’un pour accompagner sa progression peut aussi être une bonne idée, et il recommande First Ruby Friend comme ressource pour les apprenants Ruby
- Pour le contacter, il utilise LinkedIn et Twitter/X, et il prévoit de reconstruire www.lorrydriveloper.com en Ruby on Rails après la fermeture de son ancien site personnel sous Django
1 commentaires
Commentaires Hacker News
Au Royaume-Uni, j’ai fait le chemin inverse : de développeur (principalement C#) à chauffeur poids lourd.
Aujourd’hui, je conduis aussi bien des camions rigides de 12 tonnes que de gros semi-remorques de 44 tonnes, et pendant mon temps libre, je prends plus de plaisir à développer en RoR et Golang que lorsque j’étais payé pour coder.
Mon temps de travail hebdomadaire est passé de 38-40 heures à 50-52 heures en moyenne, mais la conduite de HGV est bien mieux rémunérée que mon ancien poste de développeur. Cela dit, ça reflète peut-être davantage mon niveau ou mes compétences en tant que développeur.
Il existe des exceptions, mais il faut passer des entretiens exigeants, et ici il n’y a pas de choses comme des stagiaires à 200 000 dollars de rémunération totale.
C’est pour cela qu’apprendre un métier technique, devenir scrum master ou travailler dans les transports peut être une alternative réaliste. Les développeurs sont coincés dans la stagflation et, par exemple, acheter une maison à moins de 90 minutes de trajet de la métropole de Sydney reste difficile même pour la plupart des développeurs. En 15 ans, les prix de l’immobilier ont triplé, mais les salaires des développeurs et les tarifs des contrats n’ont pas augmenté dans les mêmes proportions.
Certaines personnes restent dans ce qu’elles connaissent et craignent les grands changements, mais un inconfort temporaire peut mener à une satisfaction bien plus grande sur le long terme. Qu’on se dirige vers la conduite de poids lourds, qu’on en parte, ou qu’il s’agisse de n’importe quel autre métier, continuer à raconter ce genre de parcours peut inspirer quelqu’un qui traverse burn-out et désillusion.
Quand métier et hobby sont les mêmes, la grande différence est qu’on n’a pas de chef à part soi-même.
J’y ai déjà pensé, mais je m’inquiétais des situations où il faut manœuvrer dans le centre de petits villages ruraux. Dans le village où j’habitais, des maisons se faisaient régulièrement percuter. Je me demande si ce genre d’incident est fréquent, s’il y a beaucoup de pression liée à des délais de livraison très serrés, et combien de temps il faut pour obtenir le permis HGV.
C’est bien de voir des gens changer de carrière plus tard dans la vie, mais l’expression « des personnes qui ont surmonté des difficultés pour se retrouver sur le même terrain que les autres » donne un peu le même sentiment que les articles du genre des camarades de classe ont levé des fonds pour acheter un fauteuil roulant.
C’est réconfortant de voir qu’il existe des gens bien, mais cela ignore complètement la réalité d’un système qui maintient délibérément certaines personnes en bas.
Des histoires du type : « Les enfants de la classe se sont mobilisés pour faire un don afin de sauver un orphelin de la machine à broyer les orphelins ! » Reste alors la question : pourquoi cette machine existe-t-elle au départ ?
Si quelqu’un censé rester en bas réussit, ou, Dieu nous en préserve, excelle, il se heurtera à de la résistance ou à des sanctions extrêmes. Parfois de manière discrète, mais très souvent de façon ouverte, derrière des portes closes, par un petit nombre de personnes.
C’est plutôt un échec à bien définir les priorités et à équilibrer l’usage des impôts pour améliorer la vie et les perspectives des citoyens ordinaires.
Il aurait mieux valu que ces personnes soient rémunérées à la hauteur de leur valeur dès le départ, plutôt que de devoir fournir tant d’efforts pour se déplacer latéralement sur le marché du travail.
J’aimerais bien essayer la programmation un jour, mais quand on vient de la finance, le calcul du salaire n’est pas aussi simple que pour un chauffeur poids lourd.
Il faudrait entrer directement sur un poste assez senior, ce qui paraît peu réaliste.
Je me demande parfois à quoi ressemblerait le monde si des écoles comme Flatiron School, ou divers bootcamps, avaient enseigné Elixir au lieu de Ruby.
Et « lorry » est vraiment un excellent mot, c’est dommage qu’on n’ait pas d’occasion de l’utiliser aux États-Unis.
Tant que ces diplômés ne sont pas assez nombreux pour influencer le choix de stack des nouveaux projets, ils ne pèsent pas vraiment sur le marché, et cela ne serait probablement jamais arrivé. Pour un développeur junior sans diplôme de CS, ne connaître que Ruby est déjà une option assez étroite, mais Ruby était populaire avant les bootcamps, c’est pour cela qu’il était enseigné. J’aime Elixir, mais si les écoles avaient fait ça, la plupart auraient sans doute fermé en quelques mois et les diplômés n’y auraient pas gagné grand-chose.
J’étais autrefois développeur KDE.
Il y avait des parcours intéressants de membres de la communauté qui arrivaient dans l’IT : une soprano devenue community manager, ou une grand-mère devenue développeuse parce qu’elle voulait améliorer des jeux pour ses petits-enfants. C’était une belle époque.
Étant presque âgé de 38 ans, je n’ai pas l’impression que ce soit si vieux.
Curieusement, des gens dans la vingtaine avec deux ans d’expérience pensent qu’une personne proche de la quarantaine ne peut pas acquérir les mêmes connaissances qu’eux en deux ans. Au contraire, les quadragénaires et quinquagénaires ont probablement, grâce à leur expérience de vie, davantage de pragmatisme et de discipline, plus d’attention aux détails et plus de patience.
Avant d’atteindre les 80 ans, âge où le risque de déclin cognitif ou de fragilité augmente, il est difficile de dire qu’on est vraiment vieux. Quand j’étais enfant, je pensais que la quarantaine, c’était vieux, mais à y réfléchir, il reste encore environ 40 ans avant d’être réellement vieux. C’est bien plus long que la durée de la plupart des entreprises, mariages ou carrières.
Les postes Ruby on Rails sont-ils encore assez populaires ?
Un bon développeur peut se mettre à niveau sur un nouveau langage en quelques semaines. Je l’ai fait moi-même, et j’ai aussi vu une équipe construire une plateforme entière avec une stack qui lui était totalement inconnue. Programmer, c’est surtout décomposer des problèmes, concevoir des solutions et les implémenter. Le code n’en est que le résultat.
D’après mon ressenti dans ma région, si l’on vient d’un parcours non traditionnel et qu’on n’a pas de diplôme en informatique, il peut être préférable d’étudier un langage un peu moins typique comme Ruby ou Python. Si vous postulez dans des entreprises qui utilisent des langages plus populaires, vous devez rivaliser avec une mer de candidats ayant un diplôme et de l’expérience dans ce langage.
Les entreprises Ruby ou Python me semblent un peu plus ouvertes à l’idée d’embaucher quelqu’un qui n’a pas le diplôme attendu, et, à bien des égards, probablement un peu plus détendues. J’ai presque uniquement travaillé dans des entreprises Java, mais j’ai une fois travaillé dans une entreprise Python, et cette équipe détestait Java/C++/C# de façon presque politique, tout en défendant Python avec une ardeur militante. Si un candidat partageait ce sentiment, elle aurait sans doute ressenti une forte affinité avec lui.
Là où je travaille actuellement, il existait depuis longtemps un produit atypique construit avec Ruby on Rails, et cette équipe était elle aussi passionnée et étrangement politique, convaincue que Ruby était supérieur à tout le reste, et elle embauchait davantage de personnes issues de parcours non traditionnels. Même plusieurs années après avoir quitté le poste Python, des recruteurs ont continué à me contacter uniquement pour des postes de développeur Python, comme si c’était plus important que le produit, la composition de l’équipe ou la culture de l’entreprise. Quand ils me présentent des postes dans des équipes Java ou C#, ils mettent généralement l’accent sur l’entreprise, les investisseurs ou le produit, plutôt que sur le langage.
Il y a moins d’offres que pour JS, Java ou C#, mais il y a aussi moins de développeurs Ruby. Cela a toujours été le cas.
Il y a énormément de gens qui n’ont pas réellement l’expérience qu’ils prétendent avoir, et quand on pose des questions de programmation de base auxquelles un développeur senior devrait pouvoir répondre, environ 80 % des candidats vont directement sur ChatGPT et font passer la réponse pour la leur. Ce ne sont même pas des exercices façon LeetCode, mais des questions du niveau de « qu’est-ce que le polymorphisme » ou « qu’est-ce que le refactoring ».
C’est peut-être toute l’industrie qui est devenue comme ça, mais avec un vivier de talents plus restreint, cela se voit beaucoup plus. Si cela ne tenait qu’à moi, nous utiliserions autre chose au travail, et pas seulement à cause de la taille réduite du vivier. Beaucoup de fonctionnalités de Rails censées être « agréables » et faire gagner du temps ont peu d’impact dans des applications complexes, ou se transforment en angles morts qui nous ralentissent.
Node, dotnet, Go et Java semblent tous plus populaires.
Le passage « J’ai décidé d’entrer à Flatiron School. Si je n’obtenais pas de travail après avoir terminé le cursus, je n’avais pas à payer » est essentiel.
J’ai moi aussi suivi un bootcamp, dans l’un de ceux qui exigeaient un entretien d’admission, et c’était un vrai entretien, assez difficile pour un débutant. Le modèle des bootcamps peut être vraiment excellent lorsqu’il est bien mis en œuvre. Bien sûr, il y a aussi de la corruption et des arnaques, et malheureusement beaucoup de personnes innocentes ont perdu de l’argent.
Donc, si vous envisagez un bootcamp, mieux vaut en choisir un où il est difficile d’entrer et qui propose un accord de partage des revenus. Cela dit, les accords de partage des revenus peuvent eux aussi être douteux. Il arrive qu’ils exigent un remboursement même si vous obtenez un emploi sans rapport avec la tech, par exemple dans le commerce de détail.
https://news.ycombinator.com/item?id=40067939
D’après mon expérience avec ce type de dispositifs, ils sont généralement très exploitants et ciblent souvent des personnes vulnérables. Le plus gros indice, c’est que la plupart de ces organismes ne rendent pas les conditions du contrat publiques. En général, il faut passer plusieurs heures dans le processus avant d’en connaître les détails, parce qu’ils ne veulent pas que l’information circule, précisément pour les raisons que je viens d’évoquer.
À l’inverse, on peut s’en servir comme filtre rapide. Si vous demandez « Pouvez-vous m’envoyer les détails maintenant ? » et qu’on vous répond « Pas avant d’être venu à un séminaire en présentiel de quatre heures », passez votre chemin.
« Chauffeur routier à 40 ans ? »
Cela révèle l’âgisme de notre secteur. Commencer ce métier à 38 ans est traité comme si l’on était une relique, presque comme une curiosité de foire.