Wenn Sie mir vor einem Jahr gesagt hätten, dass ich von der Hochschule abgemeldet werde und bei einem Drei-Personen-Startup im Bereich Front-End-Entwicklertools arbeite, hätte ich gelacht.

Die letzten drei Monate haben meine Mentalität völlig verändert. Ich begann dieses Praktikum mit Bedenken gegenüber Start-ups, da ich nur wusste, wie eine Karriere in einem großen Unternehmen aussieht. Ich habe einen klaren Plan für die Gründung meines eigenen Unternehmens vorgelegt, von der Ideenfindung und Codebasis-Einrichtung bis hin zur Bereitstellung und Markteinführung.

Das Vivid-Team hat das möglich gemacht. Bei näherer Betrachtung machten einige wichtige Unterschiede zwischen Startups in der Frühphase und Big Tech den entscheidenden Unterschied.

• Aufmerksamkeit. Bei Vivid wurde großer Wert auf mein Lernen gelegt. Ich wurde ermutigt, auszuwählen, woran ich arbeiten wollte, Fragen zu stellen und über alles zu sprechen, was ich lernen wollte. Ich erwähnte, dass ich daran interessiert war, wie Jorge das Monorepo konfigurierte, und am nächsten Tag hatten wir eine zweistündige Diskussion über die Besonderheiten von Vite, Turborepo, pnpm und mehr. So sehr dies ein Beweis für das Vivid-Team ist, ist die Aufmerksamkeit bei einem kleineren Team ganz natürlich. Meine Arbeit war direkt mit dem Erfolg des Unternehmens verbunden, daher lag es im Interesse aller, mir zu helfen, mein Bestes zu geben.
• Breite des Lernens. In einem jungen Unternehmen gibt es noch keine etablierte Codebasis, auf der man aufbauen kann. Ich war es so gewohnt, Dinge wie Bereitstellungsskripte und Datenbankverbindungszeichenfolgen als selbstverständlich zu betrachten, aber plötzlich musste ich derjenige sein, der diese Dinge einrichtete. Ich denke, dass man sich bei größeren Unternehmen sehr intensiv mit einem Thema beschäftigt, bei einem Start-up hingegen ist man gezwungen, bei jedem Teil seines Produkts einen Fuß in der Tür zu haben.
• Codequalität. Obwohl Startups normalerweise für ihre schlechte Codequalität bekannt sind, war dies bei Vivid sicherlich nicht der Fall. Ich habe so viel über die besten Code-Praktiken gelernt, da meine PRs zu oft zur Korrektur zurückgeschickt wurden, um sie zählen zu können. Obwohl es damals schmerzhaft war, bin ich jetzt sicherlich ein besserer Ingenieur und weiß, wie wichtig eine gründliche Codeüberprüfung ist.
• Spaß! Zu guter Letzt war das Praktikum bei Vivid der größte Spaß, den ich je bei einem Job hatte. Aryaman, Jorge und Alberto haben von der ersten Woche an ein so entspanntes Umfeld geschaffen, und jetzt habe ich das Gefühl, dass ich gerade mit meinen wirklich tollen Freunden an einem Hackathon-Projekt arbeite. Bei anderen Jobs würde ich es kaum erwarten, um 17 Uhr Feierabend zu machen, aber hier bleibe ich gerne und arbeite bis wann auch immer.

Während ich diesen Beitrag nur wenige Stunden vor unserer zweiten Launch-Party auf demselben WeWork-Dach schreibe, auf der ich Aryaman, Jorge und Alberto getroffen habe, wünschte ich fast, dass auch ich ein Big-Tech-Angebot hätte, auf das ich verzichten und Vivid beitreten könnte. Stattdessen fahre ich für mein Abschlussjahr an der Uni zurück nach Columbia, mit vier neuen Freunden und dem Drang, mit dem, was ich gelernt habe, etwas aufzubauen.

Geben Sie Vivid ein

Ich traf Aryaman, Jorge und Alberto zum ersten Mal persönlich, als sie auf einer WeWork-Party auf dem Dach ihre Jobangebote im Big Tech-Bereich ablehnten. Nachdem ich in der Woche zuvor nur ein kurzes Kaffeegespräch mit Aryaman geführt hatte, fand ich es so erfrischend zu sehen, wie begeistert die drei von dem waren, woran sie arbeiteten.

Ich war frisch von meinem Microsoft-Praktikum und hatte im Sommer zuvor ein Praktikum bei Meta gemacht. Ich hatte das Gefühl, eine gute Vorstellung davon zu haben, wie das Leben bei Big Tech aussehen würde, und obwohl ich es nicht hasste, fragte sich ein großer Teil von mir auch, wie es wäre, bei einem Startup zu arbeiten. Zu sehen, wie das Vivid-Team sich freute, als es die Traumangebote meines Erstsemester-Ichs aufgab, war ein Weckruf – ich musste sehen, was ich verpasst hatte.

Es war keine Überraschung, dass ich einen Monat später ein Angebotsschreiben unterzeichnete, um im Frühjahr 2023 als erster Praktikant bei Vivid einzusteigen.

Der Dreh- und Angelpunkt

Ich begann meinen ersten Arbeitstag bei Vivid und wusste nicht, was mich erwarten würde.

Am ersten Tag erlebte ich die größte Überraschung: Vivid baute den Styler nicht mehr – ihr Flaggschiffprodukt, das sie mir erst vor ein paar Monaten auf dem Dach vorgeführt hatten. Mir wurde klar, dass ich zu einem unglaublich einzigartigen Zeitpunkt in das Unternehmen eintrat – ich konnte aus erster Hand erfahren, was es bedeutet, ein Unternehmen von Grund auf aufzubauen.

Ich wurde sofort in Brainstorming-Sitzungen eingebunden, während das Team über neue Wege für das Unternehmen nachdachte. Ich habe mich schnell mit den Ideen vertraut gemacht, die herumgeworfen wurden, und mir die Besonderheiten dessen angeschaut, was eine Idee besser macht als eine andere.

Ein paar wichtige Erkenntnisse aus unseren Brainstorming-Sitzungen:

• Es ist wichtig, ein Produkt zu entwickeln, das die Leute wirklich brauchen . Es spielt keine Rolle, ob Ihr Tool die Produktivität jeder Person im Team um 10 % steigert – niemand ist bereit, seinen aktuellen Arbeitsablauf für eine geringfügige Verbesserung zu unterbrechen. Wenn es vielmehr zwei oder drei Ingenieure gibt, die eine Produktivitätssteigerung von 200 % erleben, wird Ihr Werkzeug viel stabiler sein.
• Wettbewerber disqualifizieren eine Idee nicht. Früher dachte ich, wenn irgendein anderes Unternehmen, egal wie klein, mit der Arbeit an einer ähnlichen Idee wie meiner begonnen hätte, sollte ich diese nicht weiterverfolgen. Aber jetzt sehe ich die Existenz dieser Unternehmen als Beweis dafür, dass es ein echtes Problem gibt, das gelöst werden muss.
• Langfristige Vision ist wichtig. Das bedeutet auch, eine schlechte Idee loszulassen. Ich war überrascht, als ich hörte, dass Vivid den Styler aufgeben würde. Als Benutzer dachte ich, es sei ein gut umgesetztes Produkt mit einem soliden Anwendungsfall. Jetzt verstehe ich, dass es mit dem Styler kein vorhersehbares langfristiges Ziel gab und die Umstellung für das Wachstum des Unternehmens von entscheidender Bedeutung war. Damit Start-ups schnell vorankommen können, müssen sie in der Lage sein, von einer Idee Abstand zu nehmen, für die es keinen klaren Weg nach vorne gibt, und zwar ungeachtet des Irrtums über die versunkenen Kosten.

Unten ist ein Bild meines allerersten Code-Beitrags für das Vivid-Team!

Am Ende der ersten zwei Wochen bei Vivid wusste ich nicht mehr, wie man eine einzige React-Zeile schreibt, und war zuversichtlich, eine Seite von Grund auf neu erstellen zu können – mehr Wissen, als ich in den zwölf Wochen früherer Praktika gelernt hatte.

Vivid Sync

Der zweite Teil meines Praktikums wurde von Vivid Sync definiert. Wir wussten bereits, dass es bei der Übergabe von Entwicklern an Designer erhebliche Reibungsverluste gab. Doch während eines Kundengesprächs teilte ein technischer Leiter eine wichtige Erkenntnis mit: Diese Reibung hatte eine einzige Ursache. Mit der Zeit beginnen Figma-Bibliotheken von den Code-Repositorys abzuweichen, was zu anhaltenden Missverständnissen zwischen Designern und Entwicklern führt.

Innerhalb einer Woche nach der ersten Idee hatten wir einen Designpartner gefunden und mit der Entwicklung des Produkts begonnen, bei dem es sich im Wesentlichen um ein Aufgabenverwaltungssystem handelte, das Figma-Komponenten über Github Issues mit einer Codebasis verknüpfte.

Ich wurde damit beauftragt, die Web-Benutzeroberfläche zu erstellen, die so aussah:

Aber so sehr ich die Idee und das Produkt auch großartig fand, waren wir nur eine Woche, nachdem wir das Produkt an unseren Designpartner geliefert hatten, wieder bei Null im Besprechungsraum.

Brainstorming Pt. 2

Vivid Sync hatte einen schwerwiegenden Fehler – es löste das Problem des Kunden nicht. Der Endbenutzer wurde durch das Versprechen motiviert, die verschwendete Engineering-Zeit zu begrenzen. Im Gegensatz zum Styler hatte Vivid Sync eine klare langfristige Vision, die darin bestand, eine End-to-End-Synchronisierung zwischen Figma und Code zu schaffen, aber das gelieferte Produkt sparte den Ingenieuren keine Zeit – es trug tatsächlich zum Gesamtaufwand bei Arbeit, indem Sie Aufgaben für Wartungsarbeiten erstellen.

Das Team war damit beschäftigt, so schnell wie möglich etwas für unseren Designpartner zu entwickeln, aber im Nachhinein gab es von Anfang an klare Warnungen, dass der unmittelbare Mehrwert von Sync möglicherweise nicht hoch genug sein könnte.

Dieses Mal war ich auf das vorbereitet, was kommen würde. Ich habe es mir zum Ziel gesetzt, mich aktiv an Ideendiskussionen zu beteiligen. Ich habe gelernt, Hypothesenbögen zu schreiben, Wettbewerbsforschung durchzuführen und mit dem Auf und Ab unterschiedlicher Denkweisen umzugehen, die sich auf eine bestimmte Idee beschränken. Vor allem habe ich gelernt, wie viel Einfluss meine Meinung in einem kleinen Team haben kann.

Figma zu Code

Aus meinem GitHub-Commit-Verlauf ging genau hervor, wie lange wir mit der Ideenfindung verbracht haben – drei Wochen. Wir haben uns entschieden, direkt in die Richtung einzutauchen, die den Kunden den größten Nutzen bringt – die Konvertierung von Figma-Designs in nutzbaren Frontend-Code. Es gab eine klare langfristige Vision, wir gingen direkt auf die Schwachstellen des Endbenutzers ein und wir waren alle viel überzeugter davon.

Als es um den Aufbau ging, übernahm ich die Verantwortung für das Onboarding neuer Benutzer. Das Ziel des Onboardings bestand darin, Vivid die Generierung von Code unter Verwendung von Komponenten zu ermöglichen, die sich bereits in der Codebasis des Benutzers befinden.

Die größte technische Herausforderung bestand darin, die Codekomponenten des Benutzers abzurufen und diese mit den entsprechenden Figma-Assets zu verknüpfen, sodass wir jedes Mal, wenn das Figma-Asset verwendet wurde, die richtige Komponente im Code aufrufen konnten. Auch die Komponenteneigenschaften mussten angepasst werden, damit unser Tool diese Komponenten fehlerfrei aufrufen konnte.

Die Onboarding-Funktion bestand aus mehreren Teilen:

1. Github-App . Die Github-App stellt eine Verbindung zu einem Repository her und gibt alle .tsx-Dateien innerhalb des verbundenen Repositorys über eine REST-API zurück
2. Python-Microservice . Der mit Flask erstellte Python-Microservice verwendet einen NLP-Matching-Algorithmus, um Codekomponenten semantisch mit Figma-Komponenten abzugleichen.
3. Code-Traversal-Paket . Mit dem Code-Traversal-Paket konnte ich die Github-App und den Python-Microservice miteinander verbinden. Es hat .tsx-Dateien von der Github-App abgerufen und die passenden Komponenten vom Python-Microservice zurückgegeben.
4. Onboarding-Match-Plattform. Schließlich ermöglichte die Benutzeroberfläche die Durchführung und Übermittlung von Übereinstimmungen an eine Datenbank im Backend.

Lustige Fotos!