Belajar Platform Engineer - Developer Experience (DevEx)

#Pendahuluan

Di episode 23 kita menilai maturity platform secara kuantitatif. Tapi ada kualitas yang lebih sulit diukur dan lebih menentukan adopsi: bagaimana rasanya bekerja dengan platform kalian setiap hari? Episode ini membahas developer experience (DevEx) — feedback loops yang cepat, dokumentasi sebagai produk, dan pengurangan toil. DevEx adalah alasan utama developer memilih golden path atau meninggalkannya.

Mengapa ini penting? Platform yang andal dan aman (episode 16-20) bisa tetap gagal total jika terasa lambat dan membingungkan. Developer punya pilihan: golden path yang 80% mulus atau jalan lama yang 100% mereka kenal. DevEx yang buruk membuat platform jadi "sesuatu yang wajib dilalui", bukan "cara yang lebih baik" — dan yang wajib dilalui selalu dicari celahnya.

#Apa Itu DevEx dan Bagaimana Mengukurnya

DevEx melampaui "tools yang bagus". Kerangka SPACE memetakan produktivitas developer:

Dimensi SPACE	Pertanyaan
Satisfaction	Seberapa puas developer dengan platform?
Performance	Seberapa cepat kerja selesai (deploy, provisioning)?
Activity	Berapa banyak yang dikerjakan (PR, rilis)?
Communication & collaboration	Seberapa mudah kolaborasi?
Efficiency & flow	Berapa banyak waktu kerja yang terganggu (menunggu, toil)?

Dari DX (Developer Experience) group, Core 4 adalah indikator inti:

Metrik	Definisi
Perception	Survei: "platform ini membuat kerjaku lebih mudah"
Adoption	% service memakai platform (ep. 23)
Productivity	Time-to-first-success, deploy time, waktu setup lokal
Impact	DORA metrics: lead time, failure rate (ep. 22)

Kuncinya: DevEx diukur dari persepsi DAN data objektif, bukan salah satunya. Persepsi tinggi tapi DORA jelek, atau sebaliknya, sama-sama sinyal yang perlu digali.

#Feedback Loops: Inner dan Outer

Cara terbaik memperbaiki DevEx adalah mempercepat feedback loop:

Inner loop (lokal) — dari edit kode ke melihat hasilnya. Target: skrip dev yang mudah (make dev), build cepat, preview otomatis. Semakin cepat feedback, semakin produktif developer.
Outer loop (CI/CD) — dari push ke production (episode 7). Target: feedback yang jelas per tahap — status deploy, log yang berguna, link dashboard observability.
Platform feedback loop — umpan balik tentang platform itu sendiri: fitur request, laporan "platform membuatku lambat", dan NPS berkala (episode 22).

Setiap menunggu yang lama (build 10 menit, pipeline 40 menit) adalah drain produktivitas yang kumulatif. Prioritaskan pengurangan waktu ini — itulah perbaikan DevEx dengan ROI terbesar.

#Mengukur Feedback Loop

Feedback loop yang lambat perlu diukur agar bisa dibenahi. Tiga angka yang paling menggambarkan:

Metrik	Definisi	Target awal
Local dev time	Edit kode → melihat hasil lokal	< 1 menit
Build & test time	Push → status CI selesai	< 10 menit
Deploy to prod	Commit → production (ep. 7)	< 30 menit

Ukur dulu baseline-nya, lalu jadikan pengurangan angka ini sebagai prioritas platform. Perbaikan kecil pada loop terpanjang sering memberi kemenangan DevEx terbesar.

#Dokumentasi sebagai Produk

Dokumentasi yang baik adalah pengganda DevEx. Perlakukan ia seperti produk: punya struktur, pemilik, dan metrik.

TechDocs (Backstage, episode 6) — dokumentasi dikelola di repo, di-render di portal, versi sesuai kode.
Struktur yang jelas — quickstart 5 menit, reference, dan runbook (troubleshooting) dipisah.
Freshness — dokumentasi basi adalah pembunuh kepercayaan; jadwalkan review dan tandai dokumen yang sudah lama tak di-update.
Searchability — developer mencari jawaban, bukan membaca manual; pastikan search di portal berfungsi baik.

Scaffold TechDocs

# Template Backstage: dokumen ter-generate bersama service
npx @techdocs/cli generate --source-dir . --output-dir site

Pola penting: jadikan dokumentasi bagian dari definisi-done service. Service tanpa TechDocs tidak "selesai" — di-enforce oleh scorecard (episode 23).

#Mengurangi Toil Developer

Toil developer adalah pekerjaan manual yang berulang dan bisa diotomasi — musuh DevEx. Sumber toil paling umum di platform:

Sumber toil	Perbaikan platform
Menunggu environment	Self-service provisioning (ep. 12, 14)
Request akses berkali-kali	Approval via git + group SSO (ep. 12)
Debugging tanpa visibilitas	Observability bawaan (ep. 9)
Migrasi manual	Migration service (ep. 14)
Setup lokal yang rapuh	Skrip dev + kontainerisasi standar

Ukur toil: per minggu, berapa jam developer habiskan untuk hal yang bisa diotomasi? Tiap 10 jam toil yang dihapus per developer per minggu adalah kemenangan besar — dan angka itulah yang dipakai membela investasi platform.

#Common Pitfalls

Hanya survei, tanpa data — persepsi tanpa angka bisa menyesatkan; gabungkan dengan metrik objektif.
Mengabaikan inner loop — fokus ke CI tapi setup lokal tetap buruk; developer kehilangan waktu setiap hari.
Dokumentasi tanpa pemilik — basi dalam 3 bulan dan ditinggalkan.
Mengotomasi hal yang salah — otomasi yang tidak dipakai lebih buruk daripada tidak ada; otomasi dari pain point nyata yang diukur.
DevEx sebagai proyek sekali jalan — DevEx adalah budaya berkelanjutan; miliki ritme survei, metrik, dan perbaikan tiap kuartal.

Important

DevEx adalah hasil pengukuran, bukan perasaan. Terapkan dua langkah kecil sekarang: ukur waktu setup lokal dan deploy-to-production (data), lalu tanyakan 5 developer pain point terbesar mereka (persepsi). Dua data ini sudah cukup untuk memulai perbaikan DevEx yang nyata.

#Penutup

Inti yang harus dibawa pulang:

DevEx diukur lewat SPACE dan Core 4: persepsi + data objektif.
Percepat feedback loops — inner loop (lokal) dan outer loop (CI/CD) adalah pengganda produktivitas.
Dokumentasi adalah produk: TechDocs, struktur jelas, freshness, dan searchability.
Kurangi toil yang terukur — tiap jam manual yang diotomasi adalah kemenangan DevEx.
DevEx adalah ritme berkelanjutan, bukan proyek sekali jalan.

Di episode 25 selanjutnya kita menyiapkan platform untuk pola beban berikutnya: edge & serverless platform — serverless di Kubernetes, edge compute untuk latensi rendah, dan desain platform hybrid yang memadukan semuanya!