Si vous m'aviez dit il y a un an que je serais désinscrit de l'université, travaillant dans une startup de trois personnes dans le domaine des outils de développement front-end, j'aurais ri.

Les 3 derniers mois ont complètement transformé ma mentalité. J'ai commencé ce stage en hésitant vis-à-vis des startups, n'ayant connu qu'à quoi ressemble une carrière dans une grande entreprise. Je suis sorti avec un plan clair sur la façon dont je procéderais pour démarrer ma propre entreprise, de l'idéation et de la configuration de la base de code au déploiement et à la mise sur le marché.

L'équipe Vivid a rendu cela possible. Après réflexion, quelques distinctions clés entre les startups en démarrage et les Big Tech ont fait toute la différence.

• Attention. Chez Vivid, l'accent était mis sur mon apprentissage. J'ai été encouragé à choisir ce sur quoi je voulais travailler, à poser des questions et à parler de tout ce que je voulais apprendre. J'ai mentionné que j'étais intéressé par la façon dont Jorge a configuré le monorepo, et le lendemain, nous avons eu une discussion de deux heures sur les tenants et les aboutissants de Vite, Turborepo, pnpm, et plus encore. Même si cela témoigne de l'équipe Vivid, l'attention vient naturellement à une équipe plus petite. Mon travail était directement lié au succès de l'entreprise, il était donc dans l'intérêt de tous de m'aider à donner le meilleur de moi-même.
• Étendue de l'apprentissage. Dans une entreprise en démarrage, il n'y a pas de base de code établie sur laquelle s'appuyer. J'étais tellement habitué à prendre pour acquis des éléments tels que les scripts de déploiement et les chaînes de connexion à la base de données, mais tout à coup, je me suis retrouvé à devoir être le seul à configurer ces éléments. Je pense que dans les grandes entreprises, vous explorez un sujet très profondément, mais dans une startup, vous êtes obligé d'avoir un pied dans la porte pour chaque élément de votre produit.
• Qualité des codes. Bien que les startups aient généralement la réputation d'avoir un code de mauvaise qualité, ce n'était certainement pas le cas chez Vivid. J'ai tellement appris sur les meilleures pratiques en matière de code, que mes relations publiques ont été renvoyées trop souvent pour être corrigées. Même si c'était douloureux à l'époque, je suis certainement un meilleur ingénieur maintenant et je comprends l'importance d'une révision approfondie du code.
• Amusant! Dernier point mais non le moindre, le stage chez Vivid a été le plus amusant que j'aie jamais eu au travail. Aryaman, Jorge et Alberto ont créé un environnement si décontracté dès la première semaine, et maintenant j'ai l'impression de travailler sur un projet de hackathon avec mes très bons amis. Dans d'autres emplois, j'aurais hâte de quitter le travail à 17 heures, mais ici, je me trouve heureux de rester et de travailler jusqu'à n'importe quand.

Alors que j'écris cet article à quelques heures de notre deuxième soirée de lancement sur le même toit WeWork, j'ai rencontré Aryaman, Jorge et Alberto, j'aimerais presque avoir moi aussi une offre Big Tech pour renoncer et rejoindre Vivid. Au lieu de cela, je retourne en Colombie pour ma dernière année d'université, emmenant avec moi quatre nouveaux amis et l'envie de construire quelque chose avec ce que j'ai appris.

Entrez vif

J'ai rencontré Aryaman, Jorge et Alberto en personne pour la première fois lorsqu'ils ont renié leurs offres d'emploi Big Tech lors d'une soirée WeWork sur le toit. N'ayant eu qu'une brève conversation café avec Aryaman la semaine précédente, j'ai pensé que c'était tellement rafraîchissant de voir l'excitation qu'ils avaient tous les trois à propos de ce sur quoi ils travaillaient.

Je venais de terminer mon stage Microsoft et j'avais fait un stage chez Meta l'été précédent. J'avais l'impression d'avoir une bonne idée de ce à quoi ressemblerait la vie chez Big Tech, et même si je ne détestais pas ça, une grande partie de moi se demandait aussi à quoi cela ressemblerait de travailler dans une startup. Regarder l'équipe Vivid se réjouir alors qu'ils abandonnaient les offres de rêve de mon étudiant de première année était un signal d'alarme - je devais voir ce qui me manquait.

Ce n'était pas une surprise qu'un mois plus tard, je signais une lettre d'offre pour devenir le tout premier stagiaire de Vivid pour le printemps 2023.

Le Pivot

Je suis entré dans ma première journée de travail chez Vivid sans savoir à quoi m'attendre.

Le premier jour, j'ai été frappé par la plus grande surprise : Vivid ne construisait plus le Styler - leur produit phare qu'ils m'ont présenté sur ce toit il y a à peine quelques mois. J'ai réalisé que je rejoignais l'entreprise à un moment incroyablement unique - découvrir de première main ce que signifie créer une entreprise à partir de zéro.

J'ai été immédiatement plongé dans des séances de brainstorming alors que l'équipe réfléchissait à de nouvelles orientations pour l'entreprise. Je me suis rapidement familiarisé avec les idées lancées et j'ai absorbé les tenants et les aboutissants de ce qui rend une idée meilleure qu'une autre.

Quelques points clés à retenir de nos sessions de brainstorming :

• Il est important de créer un produit dont les gens ont vraiment besoin . Peu importe si votre outil augmente la productivité de chaque membre de l'équipe de 10 % - personne n'est prêt à perturber son flux de travail actuel pour une amélioration mineure. Au contraire, s'il y a deux ou trois ingénieurs qui connaissent une augmentation de productivité de 200 %, votre outil sera beaucoup plus collant.
• Les concurrents ne disqualifient pas une idée. J'avais l'habitude de penser que si une autre entreprise, aussi petite soit-elle, avait commencé à travailler sur une idée similaire à la mienne, je ne devrais pas la poursuivre. Mais maintenant, je vois que ces entreprises existent comme preuve qu'il y a un vrai problème qui doit être résolu.
• La vision à long terme est importante. Alors, lâcher prise sur une mauvaise idée. J'ai été surpris d'apprendre que Vivid abandonnait le Styler. En tant qu'utilisateur, je pensais que c'était un produit bien exécuté avec un cas d'utilisation solide. Maintenant, je comprends qu'il n'y avait pas d'objectif prévisible à long terme avec le Styler et que le pivotement était essentiel pour la croissance de l'entreprise. Être capable de s'éloigner d'une idée sans chemin clair, indépendamment de l'erreur de coût irrécupérable, est nécessaire pour que les startups avancent rapidement.

Ci-dessous, une image de ma toute première contribution de code à l'équipe Vivid !

À la fin des deux premières semaines chez Vivid, je suis passé de ne pas savoir comment écrire une seule ligne de React à être confiant que je pouvais créer une page à partir de zéro - plus d'apprentissage que j'en avais acquis au cours des 12 semaines de stages précédents.

Synchronisation vive

La deuxième partie de mon stage a été définie par Vivid Sync. Nous savions déjà qu'il y avait des frictions importantes dans le transfert des développeurs aux concepteurs. Mais lors d'un appel client, un responsable de l'ingénierie a partagé une idée clé : cette friction avait une cause fondamentale unique. Au fil du temps, les bibliothèques Figma commencent à diverger des référentiels de code, ce qui entraîne une mauvaise communication constante entre les concepteurs et les développeurs.

Dans la semaine qui a suivi l'idée, nous avions trouvé un partenaire de conception et commencé à développer le produit, qui était essentiellement un système de gestion des tâches reliant les composants Figma à une base de code via Github Issues.

J'ai été chargé de créer l'interface utilisateur Web, qui ressemblait à ceci :

Mais encore une fois, même si je pensais que l'idée et le produit étaient géniaux, une semaine seulement après avoir livré le produit à notre partenaire de conception, nous étions de retour dans la salle de réunion en recommençant à zéro.

Remue-méninges 2

Vivid Sync avait un défaut fatal - cela n'a pas résolu le problème du client. L'utilisateur final était motivé par la promesse de limiter le temps d'ingénierie perdu. Contrairement au Styler, Vivid Sync avait une vision claire à long terme, qui consistait à créer une synchronisation de bout en bout entre Figma et Code, mais le produit tel que livré n'a pas fait gagner de temps aux ingénieurs - il a en fait ajouté au montant total de travail en créant des tâches pour les travaux de maintenance.

L'équipe a été prise dans la construction de quelque chose aussi vite que possible pour notre partenaire de conception, mais rétrospectivement, il y avait des avertissements clairs dès le début que la valeur ajoutée immédiate de Sync pourrait ne pas être assez élevée.

Cette fois-ci, j'étais prêt pour ce qui allait arriver. Je me suis fixé comme objectif de participer activement aux discussions d'idéation. J'ai appris à rédiger des feuilles d'hypothèses, à mener des recherches compétitives et à gérer le flux et le reflux d'une pensée divergente réduite à une idée spécifique. Surtout, j'ai appris l'impact que mon opinion pouvait avoir dans une petite équipe.

Figma à coder

Mon historique de validation GitHub a clairement indiqué combien de temps nous avons passé à réfléchir - 3 semaines. Nous avons décidé de plonger directement dans la direction de la valeur la plus élevée pour les clients - en convertissant les conceptions Figma en code frontal utilisable. Il y avait une vision à long terme claire, nous nous adressions directement au problème de l'utilisateur final et nous avions tous des niveaux de conviction beaucoup plus élevés.

En ce qui concerne la construction, j'ai pris en charge l'intégration des nouveaux utilisateurs. L'objectif de l'intégration était de permettre à Vivid de générer du code à l'aide de composants déjà présents dans la base de code de l'utilisateur.

Le principal défi technique consistait à obtenir les composants de code de l'utilisateur et à les lier à leurs actifs Figma correspondants, de sorte que chaque fois que l'actif Figma était utilisé, nous pouvions appeler le bon composant dans le code. Les propriétés des composants devaient également correspondre afin que notre outil puisse appeler ces composants sans aucune erreur.

La fonctionnalité d'intégration comportait plusieurs éléments :

1. Application Github . L'application Github se connecte à un référentiel et renvoie tous les fichiers .tsx dans le référentiel connecté via une API REST
2. Microservice Python . Le microservice Python - construit avec Flask - utilise un algorithme de correspondance NLP pour faire correspondre sémantiquement les composants de code aux composants Figma.
3. Paquet de traversée de code . Le package de traversée de code m'a permis de relier l'application Github et le microservice Python. Il a obtenu les fichiers .tsx de l'application Github et a renvoyé les composants correspondants du microservice Python.
4. Plate-forme de match d'intégration. Enfin, l'interface utilisateur permettait d'établir des correspondances et de les soumettre à une base de données dans le backend.

Photos amusantes !