Kenapa Saya Menulis Blog Teknis

Setiap hari, kerja saya sebagai orang IT di dunia sistem klinik dan rumah sakit menghasilkan banyak sekali catatan kecil: kenapa sebuah query lambat, kenapa container tidak mau restart otomatis setelah reboot, kenapa integrasi dengan sistem eksternal tiba-tiba berhenti. Selama bertahun-tahun catatan itu cuma hidup di notes app, di catatan pribadi, atau di kepala saya sendiri. Baru belakangan saya sadar bahwa membiarkan catatan itu mati di tempat tersembunyi adalah kerugian, baik buat saya maupun buat orang lain yang mengalami masalah serupa. Dari situ lahir blog ini.

Saya menulis bukan karena merasa paling benar atau paling ahli. Saya menulis karena proses menulis itu sendiri memaksa saya berpikir lebih jernih, dan karena tulisan yang sudah jadi ternyata punya nilai pakai jangka panjang yang jauh lebih besar daripada catatan yang tersimpan rapi tapi tidak pernah dibaca ulang.

Untuk Diri Sendiri di Masa Depan

Alasan paling praktis: saya menulis untuk versi diri saya beberapa bulan atau beberapa tahun ke depan, yang hampir pasti akan lupa detail keputusan teknis yang saya ambil hari ini. Ini bukan hal baru, tapi sering diremehkan. Kita cenderung berpikir "ah, ini gampang, pasti saya ingat" — padahal begitu konteksnya hilang (nama variabel, alasan kenapa suatu library dipilih, trade-off yang dipertimbangkan), rekonstruksinya bisa memakan waktu lebih lama daripada menuliskannya dari awal.

Menulis dalam bentuk blog publik, bukan sekadar catatan pribadi, punya efek samping yang bagus: saya jadi terdorong menulis lebih rapi, lebih runtut, dan menjelaskan kenapa bukan cuma apa. Misalnya, kalau saya menulis tentang kenapa saya lebih suka menjalankan proses build di dalam container daripada langsung di host, saya jadi harus benar-benar menjabarkan alasannya — konsistensi environment, isolasi versi, kemudahan reproduksi bug — bukan sekadar mengandalkan kebiasaan. Tulisan yang sudah dijelaskan ke orang lain jauh lebih mudah dipahami ulang oleh diri sendiri dibanding catatan singkat yang penuh singkatan.

Untuk Orang Lain yang Menghadapi Masalah yang Sama

Alasan kedua sama pentingnya: hampir semua masalah teknis yang saya temui, dari konfigurasi reverse proxy sampai cara menata prompt untuk model bahasa di sistem internal, bukan masalah yang unik untuk saya sendiri. Ada developer lain di luar sana, mungkin baru pindah dari peran developer ke peran yang lebih ke arah infrastruktur atau leadership teknis seperti saya, yang sedang mencari jawaban untuk pertanyaan yang persis sama.

Dunia software di sektor klinik dan kesehatan itu relatif tertutup — banyak pengetahuan praktis yang tidak pernah dibagikan keluar karena alasan kerahasiaan data atau sekadar karena tidak ada waktu untuk menulis. Saya tidak bisa dan tidak akan membagikan detail data atau klien tertentu, tapi prinsip-prinsip teknis di baliknya — cara menata Docker stack yang stabil, cara berpikir soal reliability, cara mengintegrasikan LLM ke alur kerja yang sudah ada — itu semua bisa dibagikan tanpa melanggar apa pun, dan menurut saya justru sayang kalau tidak dibagikan.

Menulis sebagai Kebiasaan, Bukan Beban

Saya tidak menulis setiap hari dengan target angka tertentu. Yang saya coba bangun adalah kebiasaan: begitu saya menyelesaikan sesuatu yang cukup berarti untuk diingat, saya sisihkan waktu singkat untuk menuliskannya sebelum detailnya menguap. Ini jauh lebih ringan daripada menunggu sampai punya "topik besar" untuk ditulis, dan hasilnya jauh lebih konsisten.

Takeaway singkat: menulis blog teknis itu investasi murah dengan hasil ganda — dokumentasi yang menyelamatkan diri sendiri di masa depan, dan kontribusi kecil ke developer lain yang sedang mencari jawaban yang sama seperti yang pernah saya cari.