Votre premier mois dans une startup laisse une empreinte. Il n'y a pas de montée en charge progressive, pas de semaine passée à regarder des vidéos d'intégration en attendant que l'informatique vous fournisse un ordinateur portable. Dès le premier jour, on s'attend à ce que vous construisiez, cassiez et répariez des choses que de vraies personnes utiliseront réellement. J'ai appris cela rapidement en rejoignant Treevah, une entreprise qui développe des outils pour aider les chercheurs d'emploi à organiser leurs candidatures. Trente jours dans un environnement en phase de démarrage m'en ont appris plus sur le développement logiciel que n'importe quel cours ou compétition.
Un rythme implacable
Chez Treevah, le travail n'attend pas que vous soyez installé. L'équipe s'efforce de faire passer le produit de l'alpha à la bêta, puis finalement en production, ce qui signifie que chaque tâche a son importance. Il n'y a pas de place pour le travail de remplissage ou les devoirs qui finissent classés dans la boîte de réception d'un professeur. Lorsque vous publiez une fonctionnalité, elle va directement aux utilisateurs qui tentent de suivre leurs échéances, leurs entretiens et leurs relances tout en cherchant leur prochain poste.
Le rythme est épuisant. Vous avancez vite chaque jour, et la charge de travail s'accumule plus vite que prévu. Les échéances ne sont pas abstraites ; elles sont liées à des jalons qui déterminent si l'entreprise peut servir davantage de chercheurs d'emploi ou corriger les lacunes de l'expérience actuelle. Cette lourdeur est pesante. Mais elle crée aussi une clarté difficile à trouver dans les grandes organisations. Quand je termine une tâche, je peux tracer une ligne directe entre ce que j'ai construit et une personne qui gère désormais plus facilement sa recherche d'emploi. Ce sentiment de responsabilité est rare, et il rend la fatigue supportable.
Les compétences progressent plus vite en production
Avant cet été, une grande partie de mon énergie était consacrée à la prise de parole en public et aux hackathons. Les deux m'ont appris à improviser et à présenter des idées sous pression. Les hackathons, en particulier, vous entraînent à bricoler des démos fonctionnelles en quelques heures. Mais il y a une différence entre un projet de week-end qui impressionne des juges et un code de production qui doit survivre au contact de centaines d'utilisateurs réels.
Passer un mois concentré sur le développement web chez Treevah a comblé ce fossé. À l'école, les projets sont encadrés. Le périmètre est fixe, les exigences sont mâchées, et si votre schéma de base de données s'effondre, vous pouvez l'expliquer sur une diapositive de présentation. Dans une startup, votre schéma doit tenir la route car de vrais chercheurs d'emploi y stockent de vraies données de candidature. La boucle de rétroaction est immédiate et impitoyable. Lorsqu'une page charge lentement ou qu'un formulaire ne parvient pas à s'enregistrer, personne ne se soucie de votre note ; ce qui compte, c'est de savoir s'ils viennent de perdre une opportunité.
Cette pression force la croissance. Vous apprenez à écrire un code plus propre, non pas parce qu'une grille d'évaluation l'exige, mais parce que c'est vous qui devrez le déboguer à minuit. Vous apprenez à poser des questions plus pertinentes lors des revues de code, car déployer une version défectueuse signifie que de vrais utilisateurs vont se heurter à un mur. Les opportunités ici frappent plus fort que les projets scolaires. Les erreurs coûtent plus cher, et ainsi, les leçons s'ancrent durablement.
La réalité humiliante des bugs
S'il y a un mythe que j'aimerais brûler, c'est l'idée que chaque bug logiciel est une défaillance logique dramatique. Certains le sont, bien sûr. Mais beaucoup de bugs rencontrés chez Treevah étaient d'une petitesse exaspérante. Ils se cachaient à la vue de tous et m'ont fait perdre des heures de ma vie.
Deux schémas revenaient sans cesse. Le premier était la duplication de règles CSS. Lorsque plusieurs développeurs touchent au même composant sur plusieurs sprints, les feuilles de style s'alourdissent. Une personne ajoute une classe utilitaire de marge tandis qu'une autre code une valeur en dur dans le fichier du composant. Ni l'un ni l'autre n'est faux isolément. Mais ensemble, ils créent des décalages de mise en page ou des guerres de spécificité qui font qu'un bouton semble correct sur Chrome mais cassé sur Safari. Pour identifier cela, il faut ouvrir les outils de développement du navigateur et parcourir les styles calculés ligne par ligne au lieu de lire une logique algorithmique élégante.
Le second consistait à définir des éléments en dehors de leurs div parentes. Un déclencheur de fenêtre modale ou un menu déroulant peut être ajouté au mauvais nœud du DOM. L'écran semble presque correct, on suppose donc que la structure est saine. Puis un conflit de z-index apparaît, ou un événement de clic remonte vers le mauvais gestionnaire, et soudain, un utilisateur ne peut plus fermer une fenêtre contextuelle qui recouvre son formulaire de candidature. Ce ne sont pas des énigmes d'informatique. Ce sont des erreurs spatiales et structurelles qui s'accumulent lorsque l'on avance rapidement.
Certains de ces bugs ont mis des semaines à être identifiés. Je fixais le code, me persuadais que la logique était solide, et m'égarais dans des impasses qui ne menaient nulle part. La frustration est réelle. On a l'impression de passer à côté de quelque chose d'évident, et c'est bien le cas. Mais la satisfaction de finir par repérer une règle en double ou une balise de fermeture mal placée est étonnamment