Catatan

Ada satu fase yang hampir pasti dialami developer yang usianya sudah melewati 40 tahun atau bahkan sudah 50 tahun. Fase ketika kita mulai sadar bahwa masalah utama kita bukan lagi kurang belajar, tapi terlalu banyak belajar tanpa arah.

Di usia ini, teknologi tidak melambat. Justru sebaliknya. Ia makin bising.

JavaScript terus melahirkan framework baru. Frontend sekarang seperti laboratorium eksperimen tanpa jam istirahat. Ada Next.js, Remix, SvelteKit, Astro, Hono, Bun, Deno, edge runtime, server action, island architecture. Semua terlihat canggih. Semua terlihat menjanjikan. Dan jujur saja, semuanya terasa melelahkan.

Di backend, kita melihat pemandangan serupa.

PHP masih di sana. Masih dipakai. Masih menghasilkan uang. Tapi Laravel makin hari makin kompleks. Indah, rapi, penuh keajaiban—dan penuh jebakan bagi yang tidak benar-benar paham. Di saat yang sama, Go dan Rust naik daun. Go terlihat sederhana dan cepat. Rust terlihat serius dan aman. Banyak developer 40+ yang diam-diam bertanya: “Apa saya harus pindah?”

Pertanyaan itu wajar.

Tapi di usia ini, mungkin pertanyaan yang lebih jujur adalah: “Untuk apa?”

Karena di titik ini, kita sudah tidak lagi belajar demi rasa penasaran semata. Kita belajar sambil membawa beban: tanggung jawab keluarga, proyek yang harus selesai, sistem yang harus stabil, dan energi yang tidak lagi tak terbatas.

Masalahnya, banyak dari kita masih bersikap seperti developer usia 20-an. Mengejar semua tren. Takut ketinggalan. Takut dianggap usang. Padahal realitasnya berbeda.

Di usia 40+, kedalaman jauh lebih berharga daripada kecepatan.

Kita tidak butuh sepuluh framework di kepala. Kita butuh satu atau dua yang benar-benar kita pahami sampai ke akar. Bukan sekadar bisa pakai, tapi tahu risikonya. Tahu batasnya. Tahu kapan harus berkata: “Ini cukup.”

Frontend modern, misalnya. Kita tidak harus menguasai semuanya. Tapi kita perlu memahami problem intinya: state, async, rendering, performance, dan maintainability. Framework boleh berganti, tapi masalah dasarnya itu-itu saja.

Backend pun sama.

Laravel, Go, Rust—semuanya alat. Yang menentukan kualitas sistem bukan bahasanya, tapi keputusan teknis di baliknya. Salah desain tetap salah, walau ditulis dengan bahasa yang sedang naik daun.

Maka, bagaimana seharusnya bersikap sebagai developer 40+?

Pertama, berdamai dengan kenyataan bahwa kita tidak perlu tahu semuanya.

Ini bukan menyerah. Ini memilih. Kita memilih fokus. Kita memilih energi kita dipakai untuk hal yang berdampak nyata.

Kedua, jadikan teknologi baru sebagai cermin, bukan tujuan.

Belajar Go untuk memahami kesederhanaan concurrency. Belajar Rust untuk memahami pentingnya safety. Belajar framework frontend baru untuk melihat pendekatan berbeda. Tapi tidak harus pindah stack setiap kali ada yang viral.

Ketiga, ukur keberhasilan dari keberlanjutan, bukan kekinian.

Sistem yang bisa dirawat lima tahun ke depan lebih berharga daripada sistem yang terlihat futuristik hari ini tapi menyiksa besok.

Keempat, manfaatkan satu keunggulan yang tidak dimiliki developer muda: pengalaman.

Kita pernah melihat teknologi datang dan pergi. Kita tahu bahwa hype selalu berulang dengan nama baru. Pengalaman ini bukan beban—ini kompas.

Dan terakhir, izinkan diri kita untuk berkata jujur:

“Saya tidak ingin menjadi developer yang tahu semuanya. Saya ingin menjadi developer yang bisa diandalkan.”

Di usia 40+, mungkin tujuan kita bukan lagi menjadi yang paling update, tapi yang paling stabil.

Dan justru di situlah nilai kita sebenarnya.

Pertanyaan tentang arsitektur WordPress hampir selalu muncul dari developer yang sudah cukup lama berkutat di dunia web. Biasanya, pertanyaan ini lahir setelah berinteraksi dengan framework yang lebih “tertib”: Laravel dengan MVC-nya, CodeIgniter yang relatif rapi, atau bahkan pendekatan clean architecture yang tegas memisahkan tanggung jawab.

Lalu saat kembali membuka WordPress—melihat fungsi global, hook berseliweran, logic bercampur di theme—muncullah satu kesimpulan spontan: ini kok berantakan sekali?

Secara jujur, kesimpulan itu tidak sepenuhnya salah.

WordPress memang bukan contoh arsitektur modern yang lahir dari buku teks rekayasa perangkat lunak. Ia lahir pada masa PHP masih sangat prosedural, ketika standar belum mapan, dan ketika tujuan utamanya bukan membangun sistem yang “indah”, melainkan membuat orang bisa menulis di internet dengan mudah. Warisan masa itu masih sangat terasa sampai hari ini. Variabel global, fungsi tanpa namespace, dan alur eksekusi yang sulit ditelusuri bukanlah kecelakaan, melainkan jejak sejarah.

Masalahnya, kita sering menilai WordPress dengan kacamata yang keliru. Kita memperlakukannya seolah-olah ia adalah framework, padahal WordPress sejak awal adalah sebuah produk. Ia bukan alat untuk membangun CMS lain, tapi CMS itu sendiri. Maka ia tidak pernah memaksa penggunanya untuk patuh pada pola tertentu. Tidak ada larangan keras mencampur logika dengan tampilan. Tidak ada polisi arsitektur yang akan menghentikan kita menulis query langsung di template. Yang penting: halaman tampil, konten terbit, dan pengguna bisa bekerja.

Di sinilah konflik batin developer biasanya muncul. Di satu sisi, naluri teknis kita memberontak melihat kekacauan struktur. Di sisi lain, kita tidak bisa menyangkal satu fakta penting: WordPress bekerja. Ia dipakai jutaan orang, menopang bisnis nyata, dan bertahan lebih dari dua dekade tanpa memutus kompatibilitas masa lalu.

Sistem hook WordPress adalah contoh paling jelas dari paradoks ini. Ia sangat fleksibel, sangat kuat, dan sekaligus sangat membingungkan. Dengan hook, siapa pun bisa mengubah perilaku sistem tanpa menyentuh core. Tapi ketika proyek membesar, melacak siapa memodifikasi apa sering kali menjadi pekerjaan melelahkan. Bagi pemula, ini terasa seperti sihir. Bagi developer berpengalaman, ini sering terasa seperti hutan tanpa peta.

Namun justru di situlah letak keberhasilan WordPress. Ia tidak dibangun untuk menyenangkan arsitek software, melainkan untuk melayani pengguna sebanyak mungkin. Backward compatibility dijaga mati-matian. Plugin lama tetap hidup. Tema usang tidak tiba-tiba rusak. Stabilitas ekosistem lebih penting daripada keindahan struktur internal.

Apakah ini berarti WordPress tidak bisa dibuat lebih rapi? Tentu bisa. Dengan disiplin, WordPress dapat diperlakukan sebagai “mesin”, sementara arsitektur kita bangun sendiri di dalam plugin. Logika dipisahkan, OOP diterapkan, theme difokuskan pada tampilan. Tapi semua itu adalah pilihan sadar developer, bukan kewajiban yang dipaksakan oleh sistem.

Maka, ketika ditanya apakah arsitektur WordPress itu berantakan, jawabannya tergantung dari sudut pandang. Jika diukur dengan standar arsitektur modern, jawabannya cenderung iya. Tapi jika diukur dari kemampuannya bertahan, beradaptasi, dan digunakan oleh orang dengan latar belakang yang sangat beragam, WordPress justru menunjukkan kecerdasan desain yang berbeda.

WordPress bukan sistem yang rapi secara akademis.
Ia adalah sistem yang sangat pragmatis.

Dan dalam dunia nyata, sering kali yang bertahan bukanlah yang paling indah strukturnya, melainkan yang paling bisa dipakai oleh banyak orang.