Iman pada Stack: Mengapa Developer Terjebak Dogma Teknologi

Adakah satu keputusan teknis yang pernah kamu ambil hanya karena "semua orang melakukannya"?

Pertanyaan itu terdengar sepele. Tapi kalau kita jujur, sebagian besar dari kita pernah memilih React karena pasar kerjanya luas, memakai microservices karena startup unicorn di Valley menggunakannya, atau menulis unit test dengan coverage 100% karena ada guru di YouTube yang mengatakan demikian. Kita menyebutnya best practice. Sebagian orang lain menyebutnya iman.

Ketika Best Practice Menjadi Dogma

Software engineering adalah disiplin yang aneh. Di sini, pengalaman seringkali dikalahkan oleh opini. Sebuah arsitektur yang bekerja di perusahaan dengan 10.000 engineer bisa dianggap sebagai standar emas untuk tim berlima. Panduan gaya kode yang ditulis untuk codebase jutaan baris bisa diterapkan pada proyek side project akhir pekan. Kita hidup dalam era di mana rekomendasi teknis mudah dipisahkan dari konteksnya.

Casey Muratori, dalam analisis performanya yang fenomenal, menunjukkan bahwa prinsip "clean code" seperti preferensi polymorphism dibandingkan switch statement bisa memperlambat kode hingga 15 kali lipat. Bukan 15 persen. Lima belas kali. Muratori tidak menyerang keterbacaan kode. Dia menyerang kekakuan dogma: aturan yang diterapkan tanpa mempertanyakan biaya runtime-nya. Baca analisis lengkapnya di Computer Enhance dan diskusi Hacker News terkait di sini.

Dogma seringkali dimulai dari tempat yang baik. Robert C. Martin menulis Clean Code untuk mengatasi kekacauan yang nyata. Manifesto Agile lahir sebagai reaksi terhadap proses berlebihan. Tapi setiap filosofi, begitu dikristalkan menjadi checklist, kehilangan daya kritisnya. Kita mulai melakukan TDD bukan karena membantu, tapi karena "itu yang dilakukan profesional". Kita memecah monolith menjadi 47 layanan mikro bukan karena ada kebutuhan bisnis, tapi karena "skalabilitas".

Psikologi di Balik Ketaatan Buta

Mengapa developer cerdas bisa jatuh ke dalam perangkap dogma? Ada beberapa faktor. Pertama, cognitive offload. Di dunia yang kompleks, aturan sederhana mengurangi beban mental. Lebih mudah mengikuti "function harus kecil" daripada menimbang trade-off antara keterbacaan dan efisiensi setiap kali menulis method.

Kedua, social proof. Industri teknologi berjalan pada momentum kolektif. Ketika setiap lowongan kerja mensyaratkan pengalaman dengan Kubernetes, sulit untuk mempertahankan argumen bahwa VPS tunggal mungkin sudah cukup. Kita berinvestasi dalam stack yang populer karena itu mengurangi risiko karir, bukan selalu karena itu solusi terbaik.

Ketiga, identitas. Banyak developer menempelkan diri pada komunitas tertentu: Rails way, JavaScript ecosystem, functional programming purists. Mempertanyakan dogma komunitas sama dengan mengkhianati identitas diri. Itu sebabnya diskusi soal tabs versus spaces bisa terasa seperti perang agama. Keempat, authority bias: kita cenderung percaya pada figur yang dianggap sukses. Jika tech lead di perusahaan unicorn mengatakan bahwa event sourcing adalah masa depan, kita cenderung menerima tanpa verifikasi.

Harga yang Dibayar

Konsekuensi dari dogma bukan hanya kode yang lambat. Lebih berbahaya lagi adalah atrofi kemampuan berpikir kritis. Ketika kita selalu mencari jawaban dari dokumentasi framework atau thread Stack Overflow, kita mengorbankan kemampuan untuk mengevaluasi trade-off secara mandiri. Sean Goedecke, dalam tulisannya soal LLM dan keahlian, mencatat bahwa model bahasa justru memberikan hasil terbaik pada ahli domain. Ironisnya, orang yang paling bergantung pada AI adalah mereka yang paling sedikit memahami domainnya. Dogma bekerja dengan cara yang sama: semakin tidak mengerti, semakin kaku menurut aturan. Artikelnya bisa dibaca di seangoedecke.com.

Di tingkat organisasi, dogma menghasilkan overengineering yang mahal. Sistem didesain untuk skala yang mungkin tidak pernah tercapai. Tim menghabiskan sprint untuk refactoring yang tidak dibutuhkan pengguna. Waktu dan energi kognitif tersedot oleh upaya mematuhi aturan abstrak, bukan menyelesaikan masalah nyata. Lebih parah lagi, inovasi terhambat. Ketika semua orang menggunakan stack dan pola yang sama, ruang untuk eksperimen mengecil. Kita menjadi copy-paste culture yang berkedok engineering excellence.

Menjadi Skeptik yang Konstruktif

Apakah ini berarti kita harus menolak semua best practice? Tentu tidak. Aturan exist karena alasan yang valid. Tapi aturan harus menjadi titik awal, bukan destinasi akhir.

Skeptisisme sehat dimulai dari pertanyaan sederhana: "Di konteks apa aturan ini diciptakan?" Clean Code ditulis untuk tim besar yang bekerja pada codebase lama. Jika kamu solo developer membangun MVP dalam dua minggu, mungkin pragmatisme lebih penting daripada purity. Microservices masuk akal ketika tim dan codebase sudah mencapai skala tertentu. Untuk startup dengan tiga engineer, itu bisa jadi bom kompleksitas.

Kedua, ukur dampaknya, bukan kepatuhannya. Jangan bangga dengan coverage 100% jika tesmu rapuh dan lambat. Jangan bangga dengan arsitektur "clean" jika performanya mengecewakan pengguna. Metric yang benar adalah value yang diciptakan, bukan seberapa religius kita mengikuti doktrin.

Ketiga, pelajari sejarah. Banyak dogma modern adalah reaksi berlebihan terhadap dogma lama. Monolith buruk, maka semua orang ke microservices. Microservices merepotkan, maka muncul modulith. Setiap siklus mengulang pola yang sama: dari satu ekstrem ke ekstrem lainnya, tanpa pernah berhenti di tengah.

Mencari Keseimbangan

Pragmatisme bukanlah anti-intelektualisme. Pragmatisme adalah kemampuan membedakan antara prinsip dan preferensi. Ia mengakui bahwa software tidak dibangun dalam vacuum. Ada deadline, budget, keterbatasan tim, dan kebutuhan pengguna yang harus dipenuhi hari ini, bukan tahun depan.

Salah satu tanda developer matang adalah kemampuan untuk mengatakan "cukup". Cukup testing, cukup abstraksi, cukup optimasi. Bukan karena malas, tapi karena mereka memahami diminishing return. Mereka tahu kapan waktunya berhenti mengikuti blueprint dan mulai membaca peta lapangan sendiri.

Catatan Penutup

Software engineering pada intinya adalah tentang membuat keputusan di bawah ketidakpastian. Tidak ada formula ajaib. Stack yang tepat adalah stack yang menyelesaikan masalahmu dengan biaya yang bisa kamu toleransi, bukan stack yang paling banyak di-star di GitHub.

Industri ini akan terus menghasilkan framework baru, metodologi baru, dan buzzword baru. Beberapa di antaranya akan sangat berharga. Tapi yang paling berharga adalah kemampuanmu untuk menimbang, memilih, dan sesekali menolak. Itulah yang membedakan engineer dari pengikut.

Jadi, keputusan teknis terakhir kapan kamu benar-benar mempertanyakan "mengapa" sebelum "bagaimana"?