Tugas anda bukan sekadar menulis kod. Ia adalah membuat keputusan. Anda belajar daripadanya. Lama-kelamaan, anda melakukan lebih sedikit kesilapan. Akhirnya, anda membimbing orang lain melalui kabus yang sama. Lengkok itu—daripada menulis logik kepada memiliki hasil—adalah apa yang membezakan seseorang yang menaip sintaks daripada seseorang yang membina sistem.
Anda membuat pilihan setiap hari. Ada yang terasa remeh, seperti memilih warna butang. Yang lain mengubah suai keseluruhan produk. Triknya adalah menyedari lebih awal bahawa kedua-duanya saling berkaitan. Keputusan kecil yang dibuat secara cuai boleh menjadi kekangan besar kemudian hari, manakala pilihan sukar yang dibuat lebih awal sering kali kelihatan seperti genius apabila dilihat semula.
Radius Letupan Pilihan Awal
Apabila anda baru bermula, kesilapan anda bergema dalam ruang yang kecil. Satu commit yang buruk merosakkan binaan (build) tempatan. Satu fungsi yang cuai melambatkan satu skrin. Radius letupannya kekal kecil. Anda hanya memberi kesan kepada segelintir orang, dan kos pemulihan adalah rendah.
Tetapi apabila anda berkembang, sama ada sebagai jurutera individu atau sebagai sebuah syarikat, keputusan anda merentasi lebih banyak sistem. Pilihan yang sama jika dibuat pada skala besar boleh memakan masa berminggu-minggu. Inilah sebabnya anda mesti belajar untuk membuat pilihan yang terhitung sekarang, sebelum harganya menjadi mahal.
Fikirkan tentang tiga perangkap biasa:
Menggunakan platform yang tidak disokong oleh kebergantungan (dependencies) anda boleh membazirkan berpuluh-puluh atau beratus-ratus jam kejuruteraan. Jam-jam tersebut bukan sekadar untuk menaip. Ia adalah untuk menyahpepijat (debugging) isu keserasian yang pelik, menampal (patching) perpustakaan transitif, dan menjelaskan kepada pihak berkepentingan mengapa satu ciri ringkas mengambil masa sepanjang suku tahun.
Beralih daripada pengesahan berasaskan sesi kepada JWT pada peringkat awal hayat produk dapat mengelakkan penulisan semula yang mahal kemudian hari. Adalah jauh lebih mudah untuk melakukan penstrukturan semula (refactor) logik log masuk apabila anda mempunyai beribu-ribu pengguna berbanding apabila anda mempunyai berjuta-juta pengguna dan masa henti (downtime) menelan kos yang besar.
Menganggarkan masa sebagai dua kali ganda daripada jangkaan terbaik anda hanya berkesan jika anda menggunakan penimbal (buffer) tersebut untuk melindungi kualiti. Menambah masa dalam jadual supaya anda boleh melayari media sosial adalah pembaziran. Menambah masa supaya anda boleh menulis ujian, menyemak kes hujung (edge cases), dan mengesahkan kebolehperhatian (observability) adalah pelaburan.
Polanya mudah: hutang teknikal (technical debt) akan bertambah secara kompaun. Bayar ia selagi jumlah pokoknya masih kecil.
Tarikh Akhir dan Ilusi Kawalan
Tarikh akhir ada di mana-mana. Tarikh pelancaran, tarikh demo, pembekuan kod (code freeze). Dalam syarikat besar, ia sering berfungsi untuk tujuan psikologi berbanding tujuan teknikal. Ia mewujudkan perasaan kawalan terhadap kerumitan yang tidak difahami sepenuhnya oleh sesiapa pun.
Kesan sampingannya boleh diramal. Apabila tarikh akhir semakin hampir, kualiti merosot. Pasukan membuang ujian, menyahaktifkan pengendalian ralat (comment out error handling), dan menghantar kod yang tidak mahu diselenggara oleh sesiapa pun. Tarikh akhir dipenuhi. Kalendar kelihatan kemas. Produk menjadi lebih buruk.
Ini berlaku kerana jurutera menyukai kod yang sempurna dan seni bina yang elegan. Ia adalah sifat semula jadi kita. Tetapi jawapan yang sempurna tidak selalunya wujud. Pilihan yang betul adalah pilihan yang sesuai dengan keadaan semasa pasukan anda. Syarikat pemula (startup) dengan tiga orang tidak memerlukan protokol yang sama seperti platform penjagaan kesihatan yang dikawal selia. Anda membina untuk keadaan anda sekarang, bukan
That buffer is also where learning lives. If every hour is allocated to feature work, no one has space to improve the build pipeline, refactor the query layer, or document the API contract. The team stays stuck at its current velocity forever.
Replacing One Error for Another
We are currently rushing into a strange trade. We are replacing human errors with non-deterministic software errors. Large language models can generate boilerplate, suggest tests, and draft documentation faster than any junior engineer. But they do it with confidence, and they do it wrong in ways that are