Jika Anda memberi tahu saya setahun yang lalu bahwa saya akan dikeluarkan dari perguruan tinggi, bekerja di startup tiga orang di ruang alat pengembang front-end, saya akan tertawa.

3 bulan terakhir telah mengubah mentalitas saya sepenuhnya. Saya datang ke magang ini ragu-ragu tentang startup, karena hanya tahu seperti apa karir di perusahaan besar. Saya telah keluar dengan cetak biru yang jelas tentang bagaimana saya akan memulai perusahaan saya sendiri, mulai dari pembuatan ide dan penyiapan basis kode hingga penerapan dan masuk ke pasar.

Tim Vivid mewujudkannya. Setelah direnungkan, beberapa perbedaan utama antara startup tahap awal dan Teknologi Besar membuat perbedaan besar.

• Perhatian. Di Vivid, ada penekanan besar pada pembelajaran saya. Saya didorong untuk memilih apa yang ingin saya kerjakan, mengajukan pertanyaan, dan berbicara tentang apa pun yang ingin saya pelajari. Saya menyebutkan bahwa saya tertarik dengan cara Jorge mengonfigurasi monorepo, dan keesokan harinya kami berdiskusi selama dua jam tentang seluk beluk Vite, Turborepo, pnpm, dan lainnya. Sebanyak ini merupakan bukti tim Vivid, perhatian datang secara alami di tim yang lebih kecil. Pekerjaan saya terkait langsung dengan kesuksesan perusahaan, jadi membantu saya melakukan yang terbaik adalah kepentingan terbaik semua orang.
• Keluasan pembelajaran. Pada perusahaan tahap awal, tidak ada basis kode yang mapan untuk dibangun. Saya sudah terbiasa menerima hal-hal seperti skrip penerapan dan string koneksi basis data begitu saja, tetapi tiba-tiba saya mendapati diri saya harus menjadi orang yang mengatur hal-hal ini. Saya pikir di perusahaan yang lebih besar, Anda menjelajahi satu topik dengan sangat dalam, tetapi di awal, Anda dipaksa untuk menginjakkan kaki di pintu untuk setiap bagian dari produk Anda.
• Kualitas Kode. Meskipun startup biasanya memiliki reputasi kualitas kode yang buruk, hal ini tidak terjadi di Vivid. Saya belajar banyak tentang praktik kode terbaik, PR saya dikirim kembali untuk diperbaiki berkali-kali. Meskipun menyakitkan pada saat itu, saya jelas menjadi insinyur yang lebih baik sekarang dan saya memahami pentingnya tinjauan kode secara menyeluruh.
• Seru! Last but not least, magang di Vivid adalah hal paling menyenangkan yang pernah saya alami dalam pekerjaan. Aryaman, Jorge, dan Alberto membangun lingkungan yang santai sejak minggu pertama, dan sekarang saya merasa seperti sedang mengerjakan proyek hackathon dengan teman-teman hebat saya. Di pekerjaan lain, saya ingin sekali pulang kerja jam 5 sore, tetapi di sini saya menemukan diri saya senang tinggal dan bekerja sampai kapan pun.

Saat saya menulis posting ini hanya beberapa jam dari pesta peluncuran kedua kami di atap WeWork yang sama, saya bertemu Aryaman, Jorge, dan Alberto, saya hampir berharap bahwa saya juga mendapat tawaran Teknologi Besar untuk mengingkari dan bergabung dengan Vivid. Alih-alih, saya kembali ke Columbia untuk tahun terakhir kuliah saya, membawa serta empat teman baru dan keinginan untuk membangun sesuatu dengan apa yang telah saya pelajari.

Masukkan Jelas

Saya bertemu langsung dengan Aryaman, Jorge, dan Alberto untuk pertama kalinya ketika mereka mengingkari tawaran pekerjaan Big Tech mereka di pesta WeWork di puncak gedung. Setelah hanya mengobrol singkat dengan Aryaman seminggu sebelumnya, saya pikir sangat menyegarkan melihat kegembiraan mereka bertiga tentang apa yang sedang mereka kerjakan.

Saya baru saja menyelesaikan magang Microsoft dan telah magang dengan Meta pada musim panas sebelumnya. Saya merasa memiliki pemahaman yang baik tentang seperti apa kehidupan di Big Tech nantinya, dan meskipun saya tidak membencinya, sebagian besar dari diri saya juga bertanya-tanya seperti apa rasanya bekerja di perusahaan rintisan. Menyaksikan tim Vivid bersuka cita saat mereka melepaskan tawaran impian saya sebagai siswa baru adalah peringatan - saya harus melihat apa yang saya lewatkan.

Tidak mengherankan jika sebulan kemudian, saya menandatangani surat penawaran untuk bergabung sebagai magang pertama Vivid untuk musim semi 2023.

Pivot

Saya memasuki hari pertama kerja saya di Vivid tanpa mengetahui apa yang diharapkan.

Pada hari pertama, saya mendapat kejutan terbesar: Vivid tidak lagi membangun Styler — produk andalan mereka yang mereka demokan kepada saya di atap itu hanya beberapa bulan yang lalu. Saya menyadari bahwa saya bergabung dengan perusahaan pada waktu yang sangat unik — mengalami langsung apa artinya membangun perusahaan dari bawah ke atas.

Saya segera dilemparkan ke sesi brainstorming saat tim memikirkan arah baru untuk perusahaan. Saya dengan cepat mempercepat ide-ide yang dilemparkan dan menyerap seluk beluk dari apa yang membuat satu ide lebih baik dari yang lain.

Beberapa poin penting dari sesi brainstorming kami:

• Sangat penting untuk membangun produk yang benar-benar dibutuhkan orang . Tidak masalah jika alat Anda meningkatkan produktivitas setiap orang dalam tim sebesar 10% — tidak ada yang mau mengganggu alur kerja mereka saat ini untuk perbaikan kecil. Sebaliknya, jika ada dua atau tiga insinyur yang mengalami peningkatan produktivitas 200% , alat Anda akan jauh lebih lengket.
• Pesaing tidak mendiskualifikasi sebuah ide. Saya dulu berpikir bahwa jika ada perusahaan lain, sekecil apa pun, telah mulai mengerjakan ide yang mirip dengan saya, saya tidak boleh mengejarnya. Tapi sekarang, saya melihat perusahaan-perusahaan ini ada sebagai bukti bahwa ada masalah nyata yang perlu diselesaikan.
• Visi jangka panjang itu penting. Begitu juga melepaskan ide yang buruk. Saya terkejut ketika mendengar bahwa Vivid mengesampingkan Styler. Sebagai pengguna, saya pikir itu adalah produk yang dieksekusi dengan baik dengan kasus penggunaan yang solid. Sekarang saya mengerti bahwa tidak ada tujuan jangka panjang yang dapat diperkirakan dengan Styler dan berputar sangat penting untuk pertumbuhan perusahaan. Mampu menjauh dari ide tanpa jalan yang jelas ke depan, terlepas dari sunk cost fallacy, penting bagi startup untuk bergerak cepat.

Di bawah ini adalah gambar kontribusi kode pertama saya untuk tim Vivid!

Pada akhir dua minggu pertama di Vivid, saya beralih dari tidak tahu cara menulis satu baris React menjadi percaya diri bahwa saya dapat membuat halaman dari awal — lebih banyak pembelajaran daripada yang saya dapatkan dalam 12 minggu magang sebelumnya.

Sinkronisasi Jelas

Bagian kedua dari magang saya ditentukan oleh Vivid Sync. Kami sudah tahu ada gesekan substansial dalam penyerahan dari pengembang ke desainer. Namun selama panggilan telepon ke pelanggan, seorang pemimpin teknik berbagi wawasan utama — gesekan ini memiliki akar penyebab tunggal. Seiring waktu, perpustakaan Figma mulai menyimpang dari repositori kode, yang menyebabkan miskomunikasi yang konsisten antara desainer dan pengembang.

Dalam waktu seminggu sejak ide pertama kali muncul, kami telah mendapatkan mitra desain dan mulai membangun produk, yang pada dasarnya adalah sistem manajemen tugas yang menghubungkan komponen Figma ke basis kode melalui Github Issues.

Saya ditugaskan untuk membangun UI web, yang terlihat seperti ini:

Tapi sekali lagi, meskipun menurut saya ide dan produknya bagus, hanya seminggu setelah kami mengirimkan produk ke mitra desain kami, kami kembali ke ruang rapat mulai dari awal lagi.

Brainstorming Pt. 2

Vivid Sync memiliki kesalahan fatal — tidak menyelesaikan masalah pelanggan. Pengguna akhir dimotivasi oleh janji untuk membatasi waktu rekayasa yang terbuang percuma. Tidak seperti Styler, Vivid Sync memiliki visi jangka panjang yang jelas, yaitu menciptakan sinkronisasi end-to-end antara Figma dan Code, tetapi produk yang dikirimkan tidak menghemat waktu teknisi — justru menambah jumlah total bekerja dengan membuat tugas untuk pekerjaan pemeliharaan.

Tim terjebak dalam membangun sesuatu secepat mungkin untuk mitra desain kami, tetapi jika dipikir-pikir, ada peringatan yang jelas dari awal bahwa nilai tambah langsung dari Sync mungkin tidak cukup tinggi.

Kali ini, saya siap untuk apa yang akan datang. Saya membuat tujuan saya untuk berpartisipasi aktif dalam diskusi ide. Saya belajar bagaimana menulis lembar hipotesis, melakukan penelitian kompetitif, dan mengelola pasang surut pemikiran yang berbeda yang dipersempit menjadi ide tertentu. Yang terpenting, saya belajar seberapa besar pengaruh pendapat saya dalam tim kecil.

Figma ke Kode

Riwayat komit GitHub saya menjelaskan dengan tepat berapa lama kami menghabiskan ide — 3 minggu. Kami memutuskan untuk terjun langsung ke arah nilai tertinggi bagi pelanggan — mengonversi desain Figma menjadi kode frontend yang dapat digunakan. Ada visi jangka panjang yang jelas, kami secara langsung menangani masalah pengguna akhir, dan kami semua memiliki tingkat keyakinan yang jauh lebih tinggi.

Ketika turun ke gedung, saya mengambil alih kepemilikan pengguna baru. Tujuan orientasi adalah untuk memungkinkan Vivid menghasilkan kode menggunakan komponen yang sudah ada di basis kode pengguna.

Tantangan teknis utama adalah mendapatkan komponen kode pengguna dan menautkannya ke aset Figma yang sesuai, jadi kapan pun aset Figma digunakan, kita dapat memanggil komponen yang benar dalam kode. Properti komponen juga perlu dicocokkan agar alat kami dapat memanggil komponen ini tanpa kesalahan.

Fitur onboarding memiliki beberapa bagian yang berbeda:

1. Aplikasi Github . Aplikasi Github terhubung ke repositori dan mengembalikan semua file .tsx di dalam repositori yang terhubung melalui REST API
2. Layanan Mikro Python . Layanan mikro Python — dibuat dengan Flask — menggunakan algoritme pencocokan NLP untuk mencocokkan komponen kode secara semantik dengan komponen Figma.
3. Paket Penjelajahan Kode . Paket traversal kode memungkinkan saya menggabungkan Aplikasi Github dan Python Microservice. Itu mendapat file .tsx dari Aplikasi Github dan mengembalikan komponen yang cocok dari layanan mikro Python.
4. Platform Pertandingan Orientasi. Terakhir, UI mengizinkan kecocokan dibuat dan dikirim ke database di backend.

Foto Menyenangkan!