Ringkasan Utama
Membangun secara terbuka sebagai developer asal Indonesia berarti rutin membagikan build log, perbaikan bug yang benar-benar dikerjakan, dan tools open source, bukan sekadar pengumuman yang dipoles, dengan jadwal WIB yang menjangkau pembaca Eropa maupun Amerika. Selama dua tahun kebiasaan ini menarik perhatian recruiter, klien, dan sesama developer, membuktikan bahwa dokumentasi yang jujur dan konsisten lebih berpengaruh daripada lokasi atau jumlah followers.
Dua tahun lalu saya mulai memposting pembaruan singkat tentang apa yang benar-benar saya kerjakan di kantor maupun proyek sampingan: sebuah antrean percobaan ulang yang terus gagal secara diam-diam, paket approval workflow yang saya rilis sebagai open source, sebuah pipeline deployment yang saya bangun ulang dari nol setelah rollback yang buruk. Tanpa polesan, tanpa kalimat pemancing, hanya apa yang benar-benar rilis dan apa yang rusak. Saya tidak berharap banyak dari kebiasaan ini karena saya berbasis di Indonesia, beberapa jam terpisah dari percakapan teknologi paling ramai di internet, dan sebagian besar akun yang saya baca terasa sangat berorientasi Bay Area dan berbahasa Inggris.
Yang benar-benar terjadi mengejutkan saya. Recruiter menemukan tulisan saya sebelum menemukan resume saya. Calon klien mengirim pesan tentang paket yang persis sama dengan yang saya keluhkan saat merilisnya. Developer lain di Jakarta dan Surabaya mulai membalas dengan versi masalah mereka sendiri yang serupa. Building in public tidak membuat saya terkenal, dan tidak melewati bagian lambat mana pun dari sebuah karier, tetapi mengubah siapa yang bisa menemukan pekerjaan saya dan seberapa banyak konteks yang mereka miliki sebelum kami sempat berbicara. Tulisan ini adalah versi jujurnya: apa yang berhasil, apa yang terasa canggung, dan jadwal yang benar-benar bisa dipertahankan.
Apa sebenarnya arti building in public
Building in public adalah praktik membuat proses pembangunan sesuatu terlihat saat sedang berlangsung, bukan hanya hasil akhirnya. Praktik ini berakar dari budaya startup yang transparan dan gerakan indie hacker, di mana para founder memposting angka pendapatan, peluncuran yang gagal, dan fitur setengah jadi alih-alih hanya pengumuman yang sudah dipoles. Bagi seorang software engineer, satuan kontennya lebih kecil dan lebih sering: sebuah commit yang memperbaiki bug nyata, keputusan desain yang dibatalkan, benchmark yang mengejutkan. Tujuannya bukan viral. Tujuannya adalah meninggalkan jejak nyata dari pekerjaan engineering yang bisa ditemukan oleh seseorang yang mencari masalah serupa di kemudian hari.
- Pembaruan kecil dan sering lebih baik daripada pengumuman langka yang sudah dipoles, karena keduanya terakumulasi menjadi riwayat pekerjaan yang bisa dicari.
- Audiensnya bukan hanya pengikut Anda hari ini. Ini juga siapa pun yang mencari istilah error atau nama paket persis yang Anda tulis, berbulan-bulan kemudian.
- Anda tidak sedang memamerkan kepercayaan diri. Anda sedang mendokumentasikan proses nyata, termasuk bagian yang tidak berhasil pada percobaan pertama.
Tulis postingan tepat saat Anda memperbaiki bug, selagi kesalahannya masih segar. Entri build log yang ditulis seminggu kemudian berubah menjadi kompilasi sorotan, bukan catatan jujur, padahal catatan jujur itulah yang benar-benar mendapat kepercayaan.
Mengapa sudut pandang Indonesia lebih penting dari yang terlihat
Sebagian besar audiens saya tidak berada di Indonesia, dan sebagian besar konten yang saya baca ditulis dalam zona waktu AS atau Eropa. Kesenjangan itu bukan kerugian begitu Anda memanfaatkannya dengan sengaja. Memposting entri build log di akhir jam kerja WIB berarti tulisan itu muncul pagi hari bagi pembaca Eropa dan malam hari bagi pembaca AS keesokan harinya, memberikan dua gelombang perhatian terpisah alih-alih satu. Ini juga membuat kontennya terasa unik: seorang developer ERP yang menulis tentang alur kerja approval hierarkis dari Jakarta terasa berbeda dibandingkan tulisan serupa dari blog SaaS generik, karena ini menandakan sebuah ceruk yang spesifik dan kurang ramai. Terlihat jelas sebagai orang Indonesia bukanlah sesuatu yang perlu direndahkan dalam bio, itu adalah detail pembeda yang diingat oleh recruiter dan klien.
| Hari | Apa yang saya posting | Waktu WIB |
|---|---|---|
| Senin | Satu hal yang rilis atau diperbaiki minggu lalu, dengan penyebab sebenarnya | 20.00 |
| Rabu | Catatan teknis singkat tentang keputusan yang saya batalkan | 20.00 |
| Jumat | Membalas komentar, tanpa postingan baru | kapan saja |
| Minggu | Tulisan yang lebih panjang jika minggu itu ada hal yang layak diperluas | pagi |
Playbook realistis untuk memulai minggu ini
Anda tidak butuh kalender konten, newsletter, atau dokumen strategi personal branding untuk memulai. Anda butuh tempat menulis dan kebiasaan yang cukup kecil untuk bertahan di tengah sprint yang sibuk. Berikut versi yang benar-benar saya pertahankan selama dua tahun tanpa kelelahan.
- Pilih satu kanal saja. Saya menggunakan repository GitHub publik untuk build log dan satu postingan jejaring profesional untuk ringkasannya, tidak lebih. Dua kanal saja sudah terasa seperti pekerjaan kedua.
- Tulis pembaruan sebagai entri build log, bukan caption. Tanggal, apa yang berubah, alasannya, apa selanjutnya. Empat baris sudah cukup.
- Posting dua kali seminggu pada hari dan jam yang tetap, bukan kapan pun inspirasi muncul. Konsistensi yang membuat arsip bisa dicari dan dipercaya, bukan frekuensi.
- Setiap empat atau lima entri, ubah salah satunya menjadi artikel yang lebih panjang begitu detailnya cukup berguna bagi seseorang yang menghadapi masalah serupa.
// BUILD_LOG.md — one entry per shipped change
## 2026-07-03
- Added retry queue to the invoice sync job (WITA cron window)
- Root cause: webhook timeout under 3s, Resend retries needed backoff
- Next: write up the retry design as a short post this weekend
## 2026-06-26
- Migrated the approval workflow package to v2 API
- Broke one downstream consumer, fixed with a deprecation shim
- Opened the package as public on GitHub, linked from LinkedIn post
Jangan pernah memposting apa pun yang menyentuh kode milik perusahaan, data klien, atau keputusan bisnis yang belum dirilis. Building in public berarti membagikan penilaian engineering Anda sendiri dan pelajaran teknis umum, bukan pekerjaan rahasia orang lain. Jika ragu, generalisasi masalahnya sampai tidak lagi bisa mengidentifikasi klien tersebut.
Bagian canggung yang jarang diceritakan
Tidak semuanya positif, dan berpura-pura sebaliknya hanya membuat orang berhenti setelah dua minggu. Berikut yang benar-benar terasa tidak nyaman, terutama menulis dalam bahasa Inggris sebagai bahasa kedua dari Indonesia.
- Sepi selama berbulan-bulan. Sebagian besar entri build log hampir tidak mendapat interaksi. Nilainya muncul kemudian, saat seseorang mencari istilah persis yang Anda gunakan, bukan lewat like secara langsung.
- Menulis dalam bahasa Inggris lebih lambat dari yang Anda kira dalam bahasa Indonesia. Saya masih menyusun penjelasan teknis dalam bahasa Indonesia terlebih dahulu untuk logika ERP yang kompleks, baru kemudian menerjemahkannya, karena memaksa berpikir dalam bahasa Inggris sejak awal justru membuat penjelasannya lebih buruk.
- Membagikan kesalahan secara publik terasa lebih berisiko daripada kenyataannya. Selama dua tahun, tidak ada klien atau atasan yang pernah mempermasalahkan perbaikan bug yang didokumentasikan. Justru itu terbaca sebagai kompetensi, bukan kecerobohan.
Apa yang sebenarnya berubah
Hasil konkretnya lebih kecil dan lebih lambat dari janji versi growth-hacking dari saran semacam ini, tetapi nyata. Sebuah entri build log tentang antrean percobaan ulang menjadi alasan seorang klien menghubungi saya, karena mereka mengalami masalah timeout webhook yang persis sama dan tulisan saya menjelaskan perbaikannya lebih baik daripada dokumentasi vendor. Dua recruiter menyebut sudah membaca tulisan tertentu sebelum pernah mengirim pesan, yang berarti panggilan pertama langsung melewati fase menjelaskan pekerjaan saya seperti biasa. Dan developer lain di Indonesia mulai menghubungi dengan versi bug mereka sendiri yang serupa, yang berubah menjadi code review informal untuk kedua belah pihak.
Kebiasaan dengan leverage tertinggi adalah merilis sebagai open source alat internal kecil yang memang sudah saya buat. Repository publik dengan README nyata dan build log mengubah pekerjaan rutin menjadi bahan portofolio tanpa waktu menulis tambahan.
Rencana konkret 30 hari
Jika Anda ingin memulai minggu ini alih-alih membaca soal ini sebulan lagi, berikut urutan pasti yang akan saya ulangi jika memulai dari awal.
- Minggu 1: pilih satu repository publik atau blog yang sudah Anda miliki, dan tulis satu entri build log tentang sesuatu yang Anda rilis dalam tujuh hari terakhir.
- Minggu 1: posting ringkasannya hanya di satu tempat, pada hari tetap, pada jam WIB tetap.
- Minggu 2 dan 3: ulangi dua kali seminggu, tanpa pengecualian, bahkan jika pembaruannya terasa kecil.
- Minggu 4: ambil entri yang mendapat paling banyak pertanyaan atau balasan dan kembangkan menjadi artikel yang lebih panjang dengan detail teknis lengkap.
- Akhir bulan: tinjau apa yang benar-benar dibaca, bukan apa yang mendapat like, dan biarkan itu mengarahkan jenis masalah apa yang Anda dokumentasikan selanjutnya.
Semua ini tidak membutuhkan pengikut yang banyak, zona waktu AS, atau bahasa Inggris sebagai bahasa ibu. Yang dibutuhkan adalah kebiasaan yang cukup kecil untuk bertahan di minggu yang buruk dan cukup konsisten untuk bisa dicari. Setelah dua tahun, itu masih menjadi seluruh strategi: rilis sesuatu yang nyata, tuliskan dengan jujur, dan biarkan arsipnya bekerja sementara Anda terus membangun.