Building in Public sebagai Developer Indonesia

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.

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.

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.

1. 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.
2. Tulis pembaruan sebagai entri build log, bukan caption. Tanggal, apa yang berubah, alasannya, apa selanjutnya. Empat baris sudah cukup.
3. 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.
4. 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

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.

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.

1. 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.
2. Minggu 1: posting ringkasannya hanya di satu tempat, pada hari tetap, pada jam WIB tetap.
3. Minggu 2 dan 3: ulangi dua kali seminggu, tanpa pengecualian, bahkan jika pembaruannya terasa kecil.
4. Minggu 4: ambil entri yang mendapat paling banyak pertanyaan atau balasan dan kembangkan menjadi artikel yang lebih panjang dengan detail teknis lengkap.
5. 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.