Apa yang Saya Lakukan sebagai Senior Engineer — Arsitektur, Trade-Off, dan Pertimbangan Teknis
Saya tidak lagi dinilai dari baris kode. Saya dinilai dari keputusan — arsitektur apa yang dipakai, trade-off apa yang diterima, dan bagaimana membimbing developer lain. Inilah kisah nyata merancang IoT telemetry untuk 50K events/detik, microservices untuk perusahaan asuransi terbesar di Australia, dan keputusan stack yang menjadi artikel paling banyak dibaca.
Faisal Affan
- Apa yang Saya Lakukan sebagai Senior Engineer
- Proposisi Senior
- Studi Kasus 1: Petrosea Minerva — IoT Fleet Telemetry
- Keputusan Arsitektur
- Dampak
- Studi Kasus 2: IAG Cybera360 — Arsitektur Platform Asuransi
- Trade-Off Kritis
- Dampak
- Studi Kasus 3: Mengapa Golang — Keputusan Stack
- Diagram Arsitektur yang Saya Rancang
- Kartu Skor Senior Saya
- Saran untuk Engineer yang Bertransisi ke Senior
- Dokumentasikan Setiap Keputusan Arsitektur — Bahkan yang Salah
- Mentoring Bukan Opsional
- Menulis Secara Publik — Portofolio Engineering-mu Berakumulasi
- Ukur Segalanya, Optimalkan yang Penting
- Yang Akan Saya Lakukan Secara Berbeda
Apa yang Saya Lakukan sebagai Senior Engineer
"Kamu tidak menjadi senior engineer dengan menulis lebih banyak kode. Kamu menjadi satu dengan membuat keputusan yang bertahan lebih lama dari dirimu." — Saya, setelah merusak production untuk ke-47 kalinya
Lompatan dari mid-level ke senior adalah transisi paling membingungkan dalam rekayasa perangkat lunak. Tahun-tahun mid-level-mu mengajarimu untuk mengirim fitur. Sekarang, tidak ada yang peduli seberapa cepat kamu secara pribadi mengirim. Mereka peduli apakah arsitektur yang kamu pilih bertahan selama tiga tahun pertumbuhan, apakah trade-off yang kamu dokumentasikan menghemat enam bulan penemuan ulang tim berikutnya, dan apakah engineer junior yang kamu bimbing bisa mengirim tanpa dirimu.
Proposisi Senior
Yang Berubah
Sebelum (Mid-Level): "Bisakah kamu memiliki sebuah fitur dari ujung ke ujung dan mengirimkannya dengan andal?" Sekarang (Senior): "Bisakah kamu membuat keputusan arsitektur yang akan diikuti oleh banyak tim — dan benar tentang trade-off-nya 80% dari waktu?"
Saya tidak lagi dinilai dari baris kode. Saya dinilai dari keputusan — arsitektur apa yang dipakai, trade-off apa yang diterima, dan bagaimana membimbing developer lain tanpa menulis kode mereka untuk mereka.
Inilah bagaimana tampilannya dalam praktik.
Studi Kasus 1: Petrosea Minerva — IoT Fleet Telemetry
Peran: Backend Engineer & System Architect Stack: Go, MQTT, Kafka, TimescaleDB, React Skala: 50K events telemetry/detik, 100+ unit alat berat di 3 lokasi tambang terpencil
Operasi pertambangan Petrosea memiliki masalah: 100+ dump truck, ekskavator, dan kendaraan pendukung yang beroperasi di lokasi terpencil di Kalimantan menghasilkan telemetry terus-menerus — posisi GPS, suhu mesin, konsumsi bahan bakar, berat muatan — setiap 2 detik. Data ini krusial untuk keputusan dispatch real-time, peringatan geofence, dan perawatan prediktif. Namun lokasi-lokasi tersebut memiliki konektivitas satelit intermiten yang membuat arsitektur berbasis HTTP tidak andal.
Keputusan Arsitektur
Saya merancang mesin geofencing real-time yang mampu memproses 50K events per detik dengan latensi peringatan di bawah 2 detik. Pilihan arsitektur inti adalah pipeline data:
Dampak
| Metrik | Sebelum | Sesudah |
|---|---|---|
| Pemrosesan telemetry | Manual/berbasis log | Real-time, 50K events/detik |
| Latensi peringatan geofence | 5-10 menit | < 2 detik |
| Deteksi pencurian BBM | Tidak diketahui (tidak terdeteksi) | Tertangkap di bulan pertama |
| Penghematan tahunan | — | Rp 3,2 M ($200K) |
| Visibilitas utilisasi armada | Laporan shift berbasis kertas | Dashboard langsung, 65% → 79% |
Studi Kasus 2: IAG Cybera360 — Arsitektur Platform Asuransi
Peran: Frontend & Backend Engineer Stack: Nuxt.js (SSR), Go microservices, PostgreSQL, D3.js Skala: 5+ integrasi mitra, digitalisasi seluruh siklus hidup asuransi untuk perusahaan asuransi terbesar di Australia
IAG (Insurance Australia Group) — perusahaan asuransi umum terbesar di Australia, kapitalisasi pasar ~AU$12 M — membutuhkan platform untuk melayani pasar asuransi cyber UKM yang kurang terlayani. Proses yang ada membutuhkan 3-4 hari untuk sebuah kutipan, melibatkan 100+ pertanyaan manual, dan memerlukan bolak-balik underwriter melalui email. Kami harus mendigitalkan seluruh siklus hidup: penilaian risiko → pembuatan kutipan → pengikatan → pemantauan → klaim.
Trade-Off Kritis
Dampak
| Metrik | Sebelum | Sesudah |
|---|---|---|
| Perputaran kutipan | 3-4 hari | < 15 menit |
| Siklus hidup asuransi | Manual/kertas | Sepenuhnya digital |
| Integrasi mitra | Tidak ada | 5+ (UpGuard, Acronis, RHCS, dll.) |
| Jangkauan platform | Australia saja | Asia Pasifik (Singapura, Malaysia, Hong Kong) |
Studi Kasus 3: Mengapa Golang — Keputusan Stack
Peran: Pengambil Keputusan Teknologi Stack: Go (dipilih), dievaluasi terhadap Node.js, Python, Rust
Setiap senior engineer pada akhirnya menghadapi pertanyaan: "Apa stack utama kamu dan mengapa?" Ini bukan pertanyaan trivia — ini adalah ujian kemampuanmu untuk mengevaluasi trade-off di berbagai dimensi: performa, produktivitas developer, kematangan ekosistem, pasar perekrutan, dan biaya perawatan jangka panjang.
Saya mengevaluasi empat opsi terhadap lima kriteria:
| Kriteria | Go | Node.js | Python | Rust |
|---|---|---|---|---|
| Model konkurensi | Goroutine (built-in) | Event loop (single-threaded) | Terbatas GIL | Async/await (kompleks) |
| Kecepatan kompilasi | < 2 detik | N/A (interpreted) | N/A (interpreted) | 30-120 detik |
| Deployment | Satu binary | Node + node_modules | Python runtime + pip | Satu binary |
| Kurva pembelajaran | Rendah (25 keywords) | Rendah | Rendah | Curam (ownership, lifetimes) |
| Perekrutan di Indonesia | Tumbuh pesat | Matang | Matang | Niche |
Keputusan: Go menang pada kesederhanaan, kecepatan kompilasi, dan ergonomi deployment — bukan performa mentah. Seorang pendukung Rust dapat dengan tepat menunjukkan bahwa Rust mengungguli Go dalam beban kerja CPU-bound sebesar 2-5x. Namun throughput CPU mentah jarang menjadi hambatan saya. I/O Jaringan, query database, dan throughput antrean pesan adalah hambatannya. Model konkurensi berbasis goroutine Go menangani itu dengan sempurna.
Pola yang Berulang
Setiap keputusan tingkat senior dalam karier saya mengikuti pola yang sama: identifikasi kendala nyata (bukan yang hipotetis), evaluasi trade-off secara eksplisit, dan pilih opsi yang mengoptimalkan hambatan — apakah itu produktivitas developer, kemudahan deployment, atau persyaratan SEO.
Diagram Arsitektur yang Saya Rancang
Di luar proyek individu, peran senior menuntut saya mendokumentasikan keputusan arsitektur sehingga dapat dipahami, ditantang, dan diperluas oleh engineer lain. Berikut adalah dua diagram kunci yang mewakili masalah arsitektur paling kompleks yang saya selesaikan.
Kartu Skor Senior Saya
| Item Portofolio | Apakah Saya Melakukannya? | Bukti |
|---|---|---|
| Diagram sistem arsitektur | ✅ Didokumentasikan di beberapa studi kasus dengan analisis trade-off | |
| Keputusan trade-off dengan alasan | ✅ Go vs Rust, MQTT vs HTTP, SSR vs SPA — masing-masing dengan matriks evaluasi eksplisit | |
| Dampak mentoring | ⚠️ Hanya mentoring informal — tidak pernah membuat program terstruktur | |
| Berbicara/menulis | ✅ 20+ artikel teknis yang diterbitkan termasuk analisis stack Go yang paling banyak dibaca | |
| Pengaruh arsitektur lintas tim | ✅ Merancang pola yang diadopsi oleh 3+ tim produk (form engine, pipeline telemetry) | |
| Kepemimpinan insiden produksi | ✅ Memimpin RCA untuk insiden IoT kritis, mendokumentasikan runbook untuk serah terima operasi | |
| ADR / dokumentasi teknis | ⚠️ Tidak konsisten — keputusan didokumentasikan dalam studi kasus tetapi tidak dalam ADR formal di setiap kasus |
Kolom mentoring informal adalah celah terbesar saya. Saya membimbing engineer junior dan mid-level pada code review dan keputusan arsitektur mereka, tetapi saya tidak pernah membuat kerangka mentoring terstruktur. Melihat ke belakang, itu adalah peluang yang terlewatkan — para engineer yang saya bimbing secara informal tumbuh lebih cepat, tetapi organisasi tidak dapat mereplikasi pola tersebut karena tidak didokumentasikan.
Saran untuk Engineer yang Bertransisi ke Senior
Dokumentasikan Setiap Keputusan Arsitektur — Bahkan yang Salah
Perbedaan antara senior dan mid-level bukanlah membuat keputusan sempurna — ini adalah mampu menjelaskan mengapa kamu membuat keputusan, alternatif apa yang dipertimbangkan, dan kapan kamu akan meninjaunya kembali. Mulailah menulis ADR (Architecture Decision Records) untuk setiap pilihan teknis yang tidak sepele. Analisis stack Go yang saya publikasikan menjadi artikel yang paling banyak dibaca bukan karena secara teknis mengesankan, tetapi karena menunjukkan matriks evaluasi — format yang persis sama dengan yang kamu butuhkan untuk portofolio senior-mu.
Mentoring Bukan Opsional
Kamu tidak menjadi senior dengan mengetahui lebih banyak. Kamu menjadi satu dengan membuat orang lain lebih efektif. Mulailah dengan satu engineer junior. Code review dengan penjelasan ("Saya akan melakukan X karena Y, tetapi pendekatanmu berfungsi jika Z"). Pair programming pada fitur yang kompleks. Tulislah dokumentasi internal yang membuka blokir tim. Bunga majemuk dari mentoring membuahkan hasil lebih cepat daripada fitur individu apa pun yang bisa kamu bangun.
Menulis Secara Publik — Portofolio Engineering-mu Berakumulasi
Setiap keputusan arsitektur, analisis trade-off, atau postmortem produksi yang kamu tulis adalah aset. Itu memvalidasi pemikiranmu untuk calon pemberi kerja masa depan, membantu engineer lain yang menghadapi masalah yang sama, dan membangun pengakuan yang membuat peran senior lebih mudah diamankan. Saya menulis 20+ artikel teknis selama tahun-tahun senior saya — dan setiap satu dari artikel tersebut berkontribusi lebih banyak pada lintasan karier saya daripada fitur tunggal mana pun yang saya kirim.
Ukur Segalanya, Optimalkan yang Penting
Engineer mid-level mengoptimalkan untuk "apakah ini berfungsi." Engineer senior mengoptimalkan untuk "apakah ini bertahan." Latensi, throughput, error budget, MTTR, frekuensi deployment — ini bukan metrik DevOps. Ini adalah metrik engineering senior. Mulailah mengukur sebelum kamu mengoptimalkan. "Penghematan tahunan $200K" dari Petrosea ada karena saya menginstrumentasi sistem dari hari pertama dan dapat menunjuk pada peningkatan spesifik dengan nilai dolar spesifik.
Yang Akan Saya Lakukan Secara Berbeda
- Mensahkan mentoring lebih awal. Engineer junior dan mid-level yang saya bimbing secara informal adalah yang paling saya banggakan. Tetapi saya seharusnya menciptakan pola yang dapat diulang — tech talk, jadwal pair programming, daftar periksa pertumbuhan — yang bertahan lebih lama dari kehadiran saya.
- Menulis ADR formal untuk setiap keputusan besar. Saya mendokumentasikan trade-off dalam studi kasus tetapi tidak dalam format ADR yang dapat dibaca mesin yang dibutuhkan organisasi untuk memori institusional.
- Berkata "tidak" dengan lebih jelas pada pekerjaan non-senior. Transisi tersulit adalah belajar bahwa tugas saya bukan menulis lebih banyak kode. Setiap jam yang saya habiskan untuk membangun fitur adalah jam yang tidak saya habiskan untuk meninjau arsitektur, membuka blokir rekan tim, atau mendokumentasikan keputusan. Para senior yang unggul sangat strategis tentang di mana mereka menginvestasikan waktu mereka.
Senior engineering bukanlah langit-langit. Ini adalah landasan peluncuran. Keputusan arsitektur yang kamu buat di tingkat ini bertahan lebih lama dari masa jabatanmu. Engineer yang kamu bimbing melampaui pengaruhmu. Trade-off yang kamu dokumentasikan menghemat waktu bertahun-tahun penemuan ulang tim masa depan. Kode-mu dikompilasi dan di-deploy. Namun keputusanmu berakumulasi — dan itulah yang membuat seorang senior engineer.