Empat kata yang sudah menyelamatkan ribuan developer dari serangan panik — sekaligus memulai ribuan sesi debugging yang panjang dan melelahkan. Kenapa ini terjadi, dan apa yang sebenarnya harus kita lakukan?


Siapa yang belum pernah ada di salah satu posisi ini? Di satu sisi ada pengguna yang frustrasi karena sistemnya tidak bekerja. Di sisi lain ada developer yang bingung karena di laptopnya semua berjalan sempurna. Tidak ada yang bohong. Tidak ada yang salah. Tapi sistem tetap error. Inilah salah satu misteri paling klasik di dunia rekayasa perangkat lunak.

Ungkapan "di saya normal, Pak" bukan pembelaan diri. Bagi developer yang jujur, itu adalah pernyataan fakta yang juga merupakan awal dari pertanyaan yang lebih besar: kenapa di sini normal, tapi di sana tidak? Dan pertanyaan itulah yang sebenarnya harus kita kejar.


------------------------------------// mengapa ini bisa terjadi? ---------------------------------

01

Tiga Alasan Paling Umum Kenapa "Di Saya Normal"


🖥️ Environment

Lingkungan yang Berbeda

Versi library, OS, konfigurasi server, variabel environment — semua ini bisa berbeda antara laptop developer dan server production.


🗄️ Data

Data yang Berbeda

Developer testing dengan data "bersih" buatan sendiri. User production punya data bertahun-tahun yang penuh edge case yang tidak pernah terbayang sebelumnya.


⏱️ Timing

Waktu dan Kondisi

Race condition, timeout, beban server tinggi, atau bug yang hanya muncul pada tanggal tertentu. Ini yang bikin developer mulai meragukan logika hidupnya.



-----------------------------------------// akar masalahnya--------------------------------------

02

Masalahnya Bukan Siapa yang Benar


Ini poin yang paling sering salah dimengerti — oleh kedua pihak. User mengira developer tidak serius atau melempar tanggung jawab. Developer merasa dituduh berbohong. Padahal keduanya benar secara teknis, tapi sama-sama melewatkan inti permasalahan.

Ketika satu fitur berjalan normal di environment A tapi error di environment B, itu bukan soal siapa yang salah. Itu sinyal bahwa sistem belum cukup robust untuk menghadapi variasi dunia nyata — dan itulah yang perlu diperbaiki.


💡 Perspektif yang Lebih Tepat

Bukan "kamu yang error" atau "di saya normal" — tapi "sistem kita belum siap menghadapi semua kondisi yang mungkin terjadi." Framing ini mengubah konflik personal menjadi masalah teknis yang bisa diselesaikan bersama.


Di instansi pemerintahan, tantangan ini berlipat ganda. Pengguna tersebar di berbagai wilayah dengan kondisi jaringan yang berbeda-beda. Ada yang pakai Windows 7, ada yang sudah Windows 11. Ada yang browsernya Chrome terbaru, ada yang masih IE karena "kebijakan kantor". Developer tidak bisa selalu testing di semua kondisi itu — tapi sistem harus tetap bisa menghadapinya.

---------------------------------------------// solusinya------------------------------------------

03

Empat Hal yang Sebenarnya Perlu Dilakukan

Daripada terus terjebak di perdebatan "di saya normal vs error terus", ini langkah konkret yang bisa membuat kita keluar dari lingkaran setan itu.


Logging

Logging yang Jelas dan Bermakna

Log bukan hanya untuk catatan — ia adalah mata kita di production. Log harus mencatat: apa yang terjadi, kapan tepatnya, siapa yang mengalami, dan dalam kondisi apa. Tanpa log yang baik, debugging production seperti mencari kucing hitam di ruangan gelap.

Environment

Reproducible Environment

Jika developer bisa meniru persis kondisi production — versi OS, versi database, data yang sama, konfigurasi yang sama — maka "di saya normal" tidak akan relevan lagi karena "saya" dan production sudah jadi satu lingkungan yang sama. Docker, environment variables, dan seed data yang konsisten adalah investasi yang sepadan.


Pendekatan Praktis

Di instansi pemerintah dengan server on-premise, minimal buat environment staging yang menggunakan konfigurasi identik dengan production. Testing di staging sebelum deploy = menghilangkan 80% dari "di saya normal, Pak".


Monitoring

Monitoring yang Proaktif

Jangan tunggu user telepon untuk tahu sistem error. Monitoring yang baik memberitahu kita sebelum user tahu ada masalah. Error rate naik? Alert masuk. Response time lambat? Sudah terdeteksi. Ini mengubah developer dari pemadam kebakaran menjadi penjaga yang siaga.


Komunikasi

Komunikasi yang Sabar dan Terstruktur

Ketika menerima laporan "error terus, Pak" — jangan langsung defensif. Tanyakan dengan tenang: di browser apa? Langkah apa saja yang dilakukan? Pesannya apa persis? Semakin spesifik informasinya, semakin cepat bug bisa ditemukan. Ini bukan interogasi — ini kolaborasi menuju solusi.


Template Komunikasi Bug yang Efektif

Minta user untuk melaporkan:

(1) langkah yang dilakukan,

(2) hasil yang diharapkan,

(3) hasil yang sebenarnya terjadi,

(4) screenshot atau pesan error.

Empat poin ini saja sudah memotong waktu debugging hingga separuhnya.