Bulan pertama anda di sebuah syarikat pemula (startup) akan meninggalkan kesan mendalam. Tiada tempoh penyesuaian yang perlahan, tiada minggu yang dihabiskan dengan menonton video orientasi sementara menunggu bahagian IT menyediakan komputer riba. Pada hari pertama, anda diharapkan untuk membina, merosakkan, dan membaiki perkara yang akan digunakan oleh manusia sebenar. Saya mempelajari perkara ini dengan cepat selepas menyertai Treevah, sebuah syarikat yang membina alatan untuk membantu pencari kerja menyusun permohonan mereka. Tiga puluh hari dalam persekitaran peringkat awal telah mengajar saya lebih banyak tentang pembangunan perisian berbanding apa jua bilik darjah atau pertandingan yang pernah saya sertai.
Rentak yang Tidak Berhenti
Di Treevah, kerja tidak menunggu anda untuk menyesuaikan diri. Pasukan sedang berusaha keras untuk menggerakkan produk daripada alpha ke beta dan akhirnya ke produksi, yang bermaksud setiap tugasan membawa beban yang besar. Tiada ruang untuk kerja sekadar mengisi ruang atau tugasan yang hanya disimpan di dalam peti masuk profesor. Apabila anda melancarkan sesuatu ciri, ia terus sampai kepada pengguna yang sedang cuba menjejaki tarikh akhir, temu duga, dan susulan semasa mencari kerjaya seterusnya.
Kepantasannya amat memenatkan. Anda bergerak pantas setiap hari, dan beban kerja bertimbun lebih cepat daripada yang anda jangkakan. Tarikh akhir bukanlah sesuatu yang abstrak; ia terikat dengan pencapaian penting yang menentukan sama ada syarikat boleh melayani lebih ramai pencari kerja atau membaiki jurang dalam pengalaman sedia ada. Beban itu memenatkan anda. Namun, ia juga mewujudkan kejelasan yang sukar ditemui dalam organisasi yang lebih besar. Apabila saya menyelesaikan sesuatu tugasan, saya dapat melihat kaitan langsung antara apa yang saya bina dengan seseorang yang kini mempunyai masa yang lebih mudah untuk menguruskan pencarian kerja mereka. Rasa tanggungjawab sebegitu adalah sesuatu yang jarang ditemui, dan ia membuatkan keletihan itu terasa berbaloi.
Kemahiran Berkembang Lebih Pantas dalam Produksi
Sebelum musim panas ini, sebahagian besar tenaga saya digunakan untuk pengucapan awam dan hackathon. Kedua-duanya mengajar saya cara berfikir dengan pantas dan membentangkan idea di bawah tekanan. Hackathon terutamanya melatih anda untuk membina demo yang berfungsi dalam masa beberapa jam sahaja. Namun, terdapat perbezaan antara projek hujung minggu yang mengagumkan juri dengan kod produksi yang perlu bertahan apabila berhadapan dengan ratusan pengguna sebenar.
Menghabiskan masa sebulan memfokuskan kepada pembangunan web di Treevah telah merapatkan jurang tersebut. Di sekolah, projek datang dengan panduan yang ketat. Skopnya tetap, keperluan disuap secara terperinci, dan jika skema pangkalan data anda gagal, anda boleh menjelaskannya dalam slaid pembentangan. Di dalam sebuah startup, skema anda mesti kukuh kerana pencari kerja yang sebenar menyimpan data permohonan yang sebenar di dalamnya. Gelung maklum balas adalah serta-merta dan tidak bertolak ansur. Apabila sesuatu halaman dimuatkan dengan lambat atau borang gagal disimpan, tiada siapa peduli tentang gred anda; mereka hanya peduli sama ada mereka baru sahaja terlepas peluang pekerjaan.
Tekanan itu memaksa pertumbuhan. Anda belajar untuk menulis kod yang lebih bersih bukan kerana rubrik menuntutnya, tetapi kerana anda sendiri yang akan menyahpepijat (debug) kod tersebut pada tengah malam. Anda belajar untuk mengajukan soalan yang lebih tajam semasa semakan kod kerana melancarkan binaan yang rosak bermakna pengguna sebenar akan menghadapi masalah. Peluang di sini memberikan impak yang lebih besar berbanding projek sekolah. Kesilapan yang dilakukan lebih berisiko, dan itulah yang membuatkan pengajarannya lebih melekat.
Realiti Bug yang Mengajar Kita Rendah Diri
Jika ada satu mitos yang ingin saya hapuskan, ia adalah idea bahawa setiap pepijat (bug) perisian adalah kegagalan logik yang dramatik. Sesetengahnya memang begitu. Namun, banyak pepijat yang saya temui di Treevah adalah sangat kecil sehingga menyakitkan hati. Ia tersembunyi di depan mata dan membazirkan berjam-jam masa saya.
Dua corak sering muncul. Pertama ialah peraturan CSS pendua. Apabila ramai pembangun menyentuh komponen yang sama dalam beberapa sprint, helaian gaya (stylesheets) menjadi terlalu besar. Seorang menambah kelas utiliti margin manakala seorang lagi memasukkan nilai secara tetap (hardcode) dalam fail komponen. Kedua-duanya tidak salah secara berasingan. Tetapi apabila digabungkan, ia mewujudkan anjakan susun atur atau peperangan spesifisiti yang menyebabkan butang kelihatan baik di Chrome tetapi rosak di Safari. Menjejaki perkara tersebut bermakna anda perlu membuka alatan pembangun pelayar dan meneliti gaya terhitung (computed styles) baris demi baris, bukannya membaca logik algoritma yang elegan.
Kedua ialah mendefinisikan elemen di luar div induk mereka. Pencetus modal atau menu lungsur (dropdown) mungkin ditambah ke nod yang salah dalam DOM. Skrin kelihatan hampir betul, jadi anda menganggap strukturnya kukuh. Kemudian konflik z-index muncul, atau acara klik merebak ke pengendali yang salah, dan tiba-tiba pengguna tidak dapat menutup tetingkap popup yang menutup borang permohonan mereka. Ini bukanlah teka-teki sains komputer. Ia adalah kesilapan ruang dan struktur yang bertimbun apabila anda bergerak terlalu pantas.
Sebahagian daripada pepijat ini mengambil masa berminggu-minggu untuk dikesan. Saya akan merenung kod tersebut, meyakinkan diri sendiri bahawa logiknya sudah mantap, dan meneroka jalan buntu yang tidak membawa ke mana-mana. Kekecewaannya benar-benar nyata. Anda rasa seolah-olah anda terlepas pandang sesuatu yang jelas, dan memang benar pun. Namun, kepuasan apabila akhirnya dapat mengesan peraturan pendua atau tag penutup yang salah letak adalah secara mengejutkan...