Bulan pertama Anda di sebuah startup akan meninggalkan kesan mendalam. Tidak ada masa adaptasi yang lambat, tidak ada minggu yang dihabiskan hanya untuk menonton video orientasi sambil menunggu tim IT menyiapkan laptop. Pada hari pertama, Anda diharapkan untuk membangun, merusak, dan memperbaiki hal-hal yang benar-benar akan digunakan oleh orang sungguhan. Saya mempelajari hal ini dengan cepat setelah bergabung dengan Treevah, sebuah perusahaan yang membangun alat untuk membantu pencari kerja mengatur lamaran mereka. Tiga puluh hari di lingkungan tahap awal mengajarkan saya lebih banyak tentang pengembangan perangkat lunak daripada yang bisa diberikan oleh ruang kelas atau kompetisi mana pun.
Ritme yang Tak Kenal Ampun
Di Treevah, pekerjaan tidak menunggu Anda untuk merasa nyaman. Tim sedang berupaya keras untuk memindahkan produk dari tahap alpha ke beta dan akhirnya ke tahap produksi, yang berarti setiap tugas memiliki bobot yang besar. Tidak ada ruang untuk pekerjaan sekadar formalitas atau tugas yang hanya disimpan di kotak masuk profesor. Saat Anda merilis sebuah fitur, fitur tersebut langsung sampai ke tangan pengguna yang sedang mencoba melacak tenggat waktu, wawancara, dan tindak lanjut saat mencari peran berikutnya.
Temponya sangat melelahkan. Anda bergerak cepat setiap hari, dan beban kerja menumpuk lebih cepat dari yang Anda duga. Tenggat waktu bukanlah hal yang abstrak; mereka terikat pada pencapaian (milestone) yang menentukan apakah perusahaan dapat melayani lebih banyak pencari kerja atau memperbaiki celah dalam pengalaman pengguna saat ini. Beban tersebut terasa berat. Namun, hal itu juga menciptakan kejelasan yang sulit ditemukan di organisasi yang lebih besar. Ketika saya menyelesaikan sebuah tugas, saya dapat menarik garis lurus antara apa yang saya bangun dengan seseorang yang kini memiliki waktu lebih mudah untuk mengelola pencarian kerja mereka. Rasa kepemilikan seperti itu jarang ditemukan, dan hal itulah yang membuat rasa lelah terasa sepadan.
Keterampilan Berkembang Lebih Cepat di Tahap Produksi
Sebelum musim panas ini, sebagian besar energi saya habis untuk berbicara di depan umum dan mengikuti hackathon. Keduanya mengajarkan saya cara berpikir cepat dan mempresentasikan ide di bawah tekanan. Hackathon terutama melatih Anda untuk merakit demo yang berfungsi dalam hitungan jam. Namun, ada perbedaan antara proyek akhir pekan yang mengesankan juri dengan kode produksi yang harus bertahan saat berhadapan dengan ratusan pengguna nyata.
Menghabiskan satu bulan fokus pada pengembangan web di Treevah menutup celah tersebut. Di sekolah, proyek datang dengan batasan. Cakupannya tetap, persyaratannya disuapi, dan jika skema database Anda bermasalah, Anda bisa menjelaskannya melalui slide presentasi. Di dalam startup, skema Anda harus kuat karena pencari kerja yang sebenarnya menyimpan data lamaran yang nyata di dalamnya. Siklus umpan baliknya bersifat instan dan tidak kenal ampun. Ketika sebuah halaman dimuat dengan lambat atau sebuah formulir gagal disimpan, tidak ada yang peduli dengan nilai Anda; mereka peduli pada apakah mereka baru saja kehilangan kesempatan kerja.
Tekanan tersebut memaksa pertumbuhan. Anda belajar menulis kode yang lebih bersih bukan karena rubrik penilaian menuntutnya, tetapi karena Andalah yang akan melakukan debugging pada tengah malam. Anda belajar mengajukan pertanyaan yang lebih tajam selama code review karena merilis build yang rusak berarti pengguna nyata akan menemui kendala. Peluang di sini terasa jauh lebih berdampak daripada proyek sekolah. Kesalahannya berbiaya lebih mahal, sehingga pelajarannya lebih membekas.
Realitas Bug yang Menyadarkan
Jika ada satu mitos yang ingin saya patahkan, itu adalah gagasan bahwa setiap bug perangkat lunak adalah kegagalan logika yang dramatis. Beberapa memang seperti itu. Namun, banyak bug yang saya temui di Treevah adalah hal-hal kecil yang sangat menyebalkan. Mereka bersembunyi di tempat yang jelas dan membuang-buang waktu hidup saya.
Dua pola terus muncul. Yang pertama adalah aturan CSS duplikat. Ketika beberapa pengembang menyentuh komponen yang sama selama beberapa sprint, stylesheet akan membengkak. Satu orang menambahkan kelas utilitas margin, sementara yang lain menuliskan nilai secara langsung (hardcode) di file komponen. Keduanya tidak salah jika berdiri sendiri. Namun, jika digabungkan, mereka menciptakan pergeseran tata letak (layout shifts) atau perang spesifisitas yang membuat sebuah tombol terlihat bagus di Chrome tetapi rusak di Safari. Melacak hal tersebut berarti harus membuka browser dev tools dan menelusuri computed styles baris demi baris, alih-alih membaca logika algoritma yang elegan.
Yang kedua adalah mendefinisikan elemen di luar div induknya. Sebuah pemicu modal atau dropdown mungkin ditambahkan ke node yang salah di DOM. Layar terlihat hampir benar, sehingga Anda berasumsi strukturnya sudah mantap. Kemudian konflik z-index muncul, atau sebuah click event merambat (bubbles) ke handler yang salah, dan tiba-tiba pengguna tidak dapat menutup popup yang menutupi formulir lamaran mereka. Ini bukanlah teka-teki ilmu komputer. Ini adalah kesalahan spasial dan struktural yang menumpuk saat Anda bergerak terlalu cepat.
Beberapa bug ini butuh waktu berminggu-minggu untuk ditemukan. Saya akan menatap kode tersebut, meyakinkan diri sendiri bahwa logikanya sudah benar, dan menyusuri jalan buntu yang tidak membuahkan hasil. Rasa frustrasinya nyata. Anda merasa seolah melewatkan sesuatu yang sudah jelas, dan memang benar demikian. Namun kepuasan saat akhirnya menemukan aturan duplikat atau tag penutup yang salah tempat terasa secara mengejutkan