Mau Ngusaiin Semua Bahasa & Tools Pemrogramming? Emang Lu Mau Jadi Avatar?

Tentang FOMO belajar tools baru, rasa insecure sebagai programmer, dan kenapa fondasi berpikir lebih penting daripada sekadar mengejar semua teknologi.

Akhir-akhir ini gue sering banget lihat konten-konten di Instagram Reels. Banyak konten kreator yang bahas rekomendasi tools AI, bahasa pemrograman, framework, roadmap jadi programmer, sampai cara cepat jadi programmer yang ga punya latar belakang IT. Awalnya gue enjoy-enjoy aja nontonnya. Banyak insight baru yang gue dapet dari sana. Tapi makin lama, karena terlalu sering lihat konten kayak gitu, gue malah mulai ngerasa insecure. Gue mulai takut tertinggal, takut kalah saing, takut ga bisa adaptasi, dan takut skill yang gue punya sekarang ternyata belum cukup.

Setiap ada teknologi baru yang rame, rasanya kayak ada tekanan buat langsung ikut belajar. Kalau belum nyobain tools baru itu, rasanya kayak gue lagi ketinggalan sesuatu yang penting. Dari situ, muncul pertanyaan di kepala gue :

Apa sih sebenarnya yang bikin seorang programmer bisa berkembang? Apakah harus bisa banyak bahasa pemrograman? Apakah harus bisa pakai banyak framework? Apakah harus selalu update dengan semua tools baru yang lagi rame?

Belajar teknologi baru memang penting, tapi kalau semua hal baru harus langsung dikejar, rasanya pasti bakal bikin capek banget. Dunia teknologi bergerak terlalu cepat. Hari ini orang bahas satu framework, besok muncul tools AI baru, minggu depan ada lagi pendekatan baru yang katanya lebih modern. Semakin lama gue belajar dan kerja di dunia programming, gue mulai sadar satu hal :

Programmer yang baik bukan berarti orang yang tahu semua teknologi.

Menurut gue, programmer yang baik adalah orang yang punya fondasi kuat buat memahami teknologi apa pun.

Gue sempat baca buku The Pragmatic Programmer, ada satu pesan yang menurut gue sederhana tapi jadi reminder buat gue :

Programmer harus peduli sama craft-nya.

Artinya, bukan cuma bikin fitur, bukan cuma asal task selesai, tapi juga mikir apakah solusi yang dibuat bisa dipahami, dirawat, dan dipertanggungjawabkan. Dari situ gue mulai sadar bahwa jadi programmer bukan cuma soal “bisa pakai tools apa”, tapi juga soal cara berpikir saat menyelesaikan masalah.

Masalahnya, di awal belajar programming dulu sewaktu kuliah, gue sering terlalu fokus ke tools. Belajar HTML, CSS, JavaScript, lalu lanjut ke frontend, backend, database, deployment, dan seterusnya. Semua itu penting. Tapi di dunia kerja, tantangannya ga selalu soal lu bisa pakai framework apa. Kadang lu harus masuk ke codebase yang sudah besar, fixing bug yang penyebabnya ga jelas, memahami alur sistem yang dibuat orang lain, dan menjelaskan ke tim kenapa sebuah solusi punya risiko tertentu. Di titik itu, yang paling diuji bukan cuma tools yang lu tahu, tapi cara lu berpikir.

Gue coba konsultasi ke orang yang berpengalaman dari gue, dan gue menyimpulkan bahwa ada 4 fondasi dasar yang penting banget buat jadi programmer.

Memahami cara sistem bekerja, membaca dan mengevaluasi kode, debugging, dan mengomunikasikan trade-off.

Fondasi pertama adalah memahami cara sistem bekerja. Maksudnya bukan lu harus hafal semua istilah teknis yang ribet, tapi minimal lu ngerti gambaran besarnya. Misalnya saat user klik tombol “Submit” di website, sebenarnya ada proses panjang di belakang itu. Frontend mengirim request, backend proses, database nyimpen dan ngambil data, terus hasilnya dikirim balik ke user. Kalau lu paham alur seperti ini, saat ada masalah lu ga asal tebak atau istilah dalam bahasa jawa “ngawang”. Lu bisa menelusuri apakah masalahnya ada di frontend, backend, data, koneksi, validasi, atau aturan akses user. Buat gue, memahami sistem itu seperti punya peta. Lu mungkin belum hafal semua jalan, tapi setidaknya lu tahu harus mulai mencari dari mana.

Fondasi kedua adalah kemampuan membaca dan mengevaluasi kode. Di dunia kerja, lu ga selalu bikin project dari nol. Sering banget lu masuk ke sistem yang udah jalan, dengan file yang isinya ribuan baris kode, aturan bisnis yang udah terbentuk, dan fitur yang saling berhubungan. Di situ, kemampuan menulis kode aja ga cukup. Lu perlu bisa paham file ini tugasnya apa, data ini datang dari mana, fitur ini dipakai untuk apa, dan kalau diubah impact-nya ke mana aja. Di buku Clean Code, ada gagasan yang menurut gue menarik.

“Kode lebih sering dibaca daripada ditulis.”

Artinya, kode yang bagus bukan cuma nulis kode yang asal jalan, tapi juga kode yang bisa dipahami oleh orang lain, termasuk diri kita sendiri maupun programmer yang bakal gantiin posisi gue di masa depan. Programmer yang baik bukan cuma mikir,

“Gimana caranya fitur ini jalan?” Tapi juga, “Gimana caranya fitur ini bisa di maintenance dan di kembangkan?”

Fondasi ketiga adalah debugging. Salah satu fondasi yang selalu IT Lead tekankan ke gue adalah debugging. Awalnya gue mikir debugging cuma soal nyari error terus fixing. Tapi semakin lama, gue semakin sadar bahwa debugging itu lebih mirip kerja jadi dokter di rumah sakit. Ketika pasien datang dengan gejala tertentu, dokter ga langsung asal ngasih obat. Dokter perlu tanya dulu keluhannya apa, sejak kapan muncul, bagian mana yang sakit, apakah ada riwayat tertentu, lalu baru cari kemungkinan penyebabnya. Debugging juga kurang lebih seperti itu. Pas ada bug, tugas programmer bukan cuma ngilangi bug yang terlihat di permukaan. Kita perlu lihat gejalanya, baca petunjuknya, cek alurnya, lalu uji kemungkinan penyebabnya satu per satu sampai ketemu akar masalahnya. Karena kadang data ga muncul di layar bukan berarti masalahnya selalu ada di tampilan. Bisa jadi datanya memang belum ada, belum dikirim dari backend, user ga punya izin, atau memang ada aturan bisnis yang membuat data tersebut di-hide.

Fondasi keempat adalah mengomunikasikan trade-off. Trade-off itu sederhananya pilihan yang punya konsekuensi. Ada solusi yang cepat tapi kurang rapi, ada solusi yang rapi tapi butuh waktu lebih lama, dan ada solusi yang aman untuk sekarang tapi perlu diperbaiki lagi nanti. Di kerjaan, ini sering kejadian waktu user minta fitur baru atau complaint karena fiturnya nggak works atau nggak sesuai ekspektasi. Contohnya user request pengen nambah fitur, nambah filter, atau nambah kolom. Kelihatannya simple kan? Tapi dari sisi sistem, bisa jadi perlu cek dulu backend, frontend, data, aturan akses, dan dampaknya ke fitur lain. Ini ngingetin gue sama salah satu insight dari buku Peopleware :

“The major problems of our work are not so much technological as sociological.”

Hal yang gue tangkap adalah, banyak masalah di dunia software development yang kelihatannya teknis, padahal ujung-ujungnya juga soal manusia. Ekspektasi user, komunikasi tim, prioritas, deadline, dan cara kita menjelaskan risiko. Di sinilah programmer perlu menjelaskan masalahnya ada di mana, opsi solusinya apa, risikonya apa, dan kenapa solusi tertentu dipilih. Jangan langsung cuma bilang, “Iya, bisa kok,” tanpa memahami impact-nya. Dan jujur aja, gue juga masih sering kayak gitu wkwkwk.

Tapi pelan-pelan gue belajar bahwa programmer yang matang bukan cuma bisa bikin fitur, tapi juga bisa bantu orang lain memahami konsekuensi dari sebuah pilihan teknis.

Dari empat fondasi itu, gue perlahan sadar bahwa, jadi programmer bukan sekadar pinter pakai tools aja. Programmer juga bukan cuma duduk, buka laptop, buka VS Code, buka ChatGPT, nulis prompt, lalu implement. Tools memang bisa bantu mempercepat kerja. AI juga bisa bantu proses belajar dan development. Tapi tetap aja, yang paling penting adalah cara berpikir di baliknya. Lu perlu paham masalahnya apa, sistemnya berjalan seperti apa, kode yang lu ubah berdampak ke mana, bug-nya berasal dari mana, dan kenapa sebuah solusi layak dipilih.

Jujur, gue masih jauh dari kata “perfect”. Masih banyak hal yang belum gue tahu, masih sering ketemu bug yang bikin gue emosi dan pengen mukulin orang (Ga deng, canda ✌️). Masih perlu banyak belajar, dan masih sering butuh arahan dari orang yang lebih berpengalaman. Tapi dari perjalanan gue sejauh ini, gue mulai sadar bahwa empat fondasi ini kepake banget di pekerjaan sehari-hari. Gue belajar memahami alur sistem sebelum asal ubah kode, baca legacy code, debugging ketika ada masalah, dan menjelaskan pilihan solusi dengan bahasa yang lebih mudah dipahami sama tim atau user.

Buat lu yang baru mulai belajar programming, atau sedang merintis karier di dunia ini kayak gue, ga apa-apa kalau lu belum tahu semua tools. Ga apa-apa kalau lu belum bisa semua framework. Ga masalah kalau lu masih bingung pas baca legacy code atau ketemu bug anomali. Yang penting, jangan cuma belajar cara pakai tools. Latih juga cara memahami masalah.

Karena teknologi akan terus berubah. Framework akan terus berganti. Tools baru akan terus muncul. Tapi fondasi seperti memahami sistem, membaca kode, debugging, dan mengomunikasikan trade-off akan tetap kepakai di mana pun lu bekerja.

Bagi gue pribadi, programmer yang baik bukan programmer yang tahu semuanya. Programmer yang baik adalah programmer yang mau terus belajar, bisa menelusuri masalah, memahami sistem, dan menjelaskan solusi dengan cara yang mudah dipahami oleh orang awam.

Cheersss…