Faisalaffan Blog
|
🇮🇩
Faisalaffan Blog
Karier7 menit baca

Apa yang Saya Lakukan sebagai Mid-Level Engineer — Shipping, Ownership & Luka Produksi

Saya mengirim fitur nyata ke pengguna nyata. Saya merusak produksi dan memperbaikinya sendiri jam 2 pagi. Saya membangun aplikasi mobile banking dengan 680 ribu unduhan, sistem armada tambang yang menghemat $200K/tahun, dan platform operasi lapangan untuk 4,1 juta pengguna. Inilah gambaran nyata engineering mid-level — proyek, metrik, dan insiden produksi yang menjadikan saya seorang engineer sejati.

Faisal Affan
Faisal Affan
Diterbitkan
Apa yang Saya Lakukan sebagai Mid-Level Engineer — Shipping, Ownership & Luka Produksi

Apa yang Saya Lakukan sebagai Mid-Level Engineer

"Mid-level adalah fase di mana kamu berhenti menulis kode yang berfungsi dan mulai menulis kode yang bertahan." — Saya, setelah rollback produksi ke-14

Tahun-tahun mid-level mengubahmu dari "seseorang yang bisa coding" menjadi "seseorang yang bisa mengirim produk." Perubahannya fundamental: kamu tidak lagi dinilai dari apakah kode kamu berjalan. Kamu dinilai dari apakah kode kamu bertahan di produksi — dalam skala besar, di bawah beban, saat semuanya kacau jam 3 pagi.


Premis Mid-Level

Apa yang Berubah

Sebelum (Junior): "Bisakah kamu menulis kode yang berfungsi?" Sekarang (Mid): "Bisakah kamu memiliki sebuah fitur dari ujung ke ujung — desain, bangun, tes, deploy, monitor, debug, dan iterasi — tanpa ditemani orang lain?"


Studi Kasus 1: SiTepat — Integrasi Mobile Banking

Peran: Backend Engineer Tunggal Stack: Go, Flutter, ISO 8583, PostgreSQL Skala: 680 Ribu+ unduhan Google Play, zero downtime selama lonjakan transaksi Lebaran

Ini adalah sistem produksi "sungguhan" pertama saya. Bukan situs WordPress. Bukan aplikasi CRUD. Sebuah aplikasi mobile banking yang harus terintegrasi langsung dengan sistem inti bank melalui protokol ISO 8583.

Yang Saya Bangun

  • Jembatan ISO 8583: Sebuah service Go yang menerjemahkan panggilan REST API menjadi pesan ISO 8583 untuk mainframe lama bank. Ini adalah jalur kritis — jika jembatan ini mati, 680 ribu pengguna tidak bisa cek saldo.
  • Dashboard Pembiayaan Real-Time: Agen lapangan bisa mensimulasikan perhitungan IIR (Internal Interest Rate) secara real-time, menggantikan proses Excel manual yang memakan 3-5 hari kerja.
  • Mesin Pengingat Pembayaran Cerdas: Pengingat otomatis melalui Firebase Cloud Messaging, mengurangi keterlambatan pembayaran sebesar 18%.

Yang Salah

Insiden Produksi #1: Timeout ISO 8583

Yang terjadi: Selama libur Idul Fitri (volume transaksi tertinggi tahun ini), jembatan ISO 8583 mulai timeout pada 30% permintaan. Mainframe bank merespons dengan benar — jembatan kamilah yang jadi hambatan.

Akar masalah: Kami membuka koneksi TCP baru untuk setiap pesan ISO. Pada 500+ permintaan konkuren, kumpulan koneksi habis. Perbaikannya adalah menerapkan koneksi persisten dengan health check.

Pelajaran: Integrasi tingkat protokol bukan "sekadar API lain." ISO 8583 memiliki keunikan dalam manajemen koneksi, urutan byte, dan encoding field yang akan menghancurkanmu jika kamu perlakukan seperti REST.

Insiden Produksi #2: Kedaluwarsa Token Firebase

Yang terjadi: Pengingat pembayaran berhenti terkirim. Tingkat pengiriman 0% selama 6 jam. Pengguna melewatkan tenggat pembayaran dan dikenakan denda keterlambatan.

Akar masalah: Token Firebase Cloud Messaging kedaluwarsa setiap 30 hari. Kami menyimpan token saat login pertama tetapi tidak pernah memperbaruinya. Perbaikannya sederhana — tetapi butuh 6 jam untuk diagnosis karena log error terkubur di dashboard Firebase, bukan di monitoring kami.

Pelajaran: Dependensi layanan eksternal perlu health check di monitoring KAMU, bukan di monitoring mereka. Jika kamu bergantung pada Firebase, monitor Firebase.

Dampak

Metrik Sebelum Sesudah
Unduhan aplikasi 0 680 Ribu+
Waktu pemrosesan transaksi 3-5 hari kerja (manual) Real-time
Tingkat keterlambatan pembayaran 22% 18%
Uptime sistem N/A (sistem baru) 99,7%

Studi Kasus 2: HPU Digital Mining Platform

Peran: Full-Stack Engineer Stack: Microservices Go, React PWA, MQTT, PostgreSQL Skala: 3 provinsi, 100+ truk, 50 ribu event telemetri/detik

Ini adalah perkenalan saya dengan IoT — dan semua yang saya kira saya tahu tentang "sistem yang andal" diuji oleh kenyataan: lokasi tambang terpencil dengan konektivitas satelit intermiten, pelacak GPS yang melaporkan data sampah, dan pengguna yang belum pernah memakai smartphone sebelumnya.

Yang Saya Bangun

  • Manajemen Armada Real-Time: Pelacakan GPS langsung untuk 100+ truk jungkit, ekskavator, dan kendaraan pendukung
  • Manajemen BBM & Deteksi Anomali: Menangkap pencurian BBM dalam bulan pertama peluncuran
  • Manajemen Digital HSE: Mengganti pelaporan keselamatan berbasis kertas dengan PWA mobile
  • Dashboard Pusat Kendali Multi-Site: Visibilitas real-time dari lubang tambang ke kantor pusat dengan kemampuan drill-down ke telemetri truk individu

Yang Salah

Pelajaran IoT #1: Pelacak GPS Bohong

Kami membeli 50 pelacak GPS dari vendor terkemuka. 12 di antaranya melaporkan koordinat yang mustahil secara fisik — truk "teleportasi" 500 meter dalam 2 detik. Setelah 2 minggu debugging kode kami, kami menemukan: pelacak dikonfigurasi untuk melapor pada 1Hz (sekali per detik), tetapi ketika kehilangan kunci satelit, mereka menyangga pembacaan dan membuang semuanya sekaligus saat tersambung kembali. Sistem kami menginterpretasikan semburan data itu sebagai data real-time.

Perbaikan: Validasi kecepatan di sisi server. Jika perubahan koordinat menyiratkan >120 km/jam untuk truk tambang, tandai dan gunakan posisi terakhir yang diketahui baik. Menyelamatkan kami dari mengejar truk hantu selama sebulan.

Pelajaran IoT #2: Tepi Tak Punya Internet

Lokasi tambang di pedalaman Kalimantan memiliki konektivitas yang membuat 3G terlihat seperti fiber. Kami mendesain untuk "konektivitas eventual" — MQTT dengan QoS 1, buffer SQLite lokal di gateway tepi, unggahan batch ketika link satelit kembali. Arsitekturnya berhasil, tetapi kami meremehkan berapa lama "jendela offline" sebenarnya: kadang 6-8 jam.

Pelajaran: Desain untuk jendela offline terburuk, bukan rata-rata. Pengguna tidak akan peduli bahwa "rata-rata" konektivitas baik jika shift 8 jam mereka berakhir tanpa sinkronisasi data.

Dampak

Metrik Sebelum Sesudah
Utilisasi truk 65% 79%
Insiden pencurian BBM Tidak diketahui (tak terdeteksi) Terdeteksi bulan pertama
Penghematan tahunan — Rp 3,2 Miliar ($200K)
Waktu laporan HSE 5 hari (kertas) Real-time (digital)

Studi Kasus 3: Tepati — Platform Operasi Lapangan

Peran: Full-Stack Engineer Tunggal Stack: Monolit Go, Flutter mobile, SQLite, MQTT Skala: 4,1 juta pengguna akhir, dibangun sendiri dalam 30 hari

Ini adalah proyek yang mengajarkan saya perbedaan antara "membangun" dan "memiliki." Ketika kamu satu-satunya pengembang, tidak ada tim backend untuk disalahkan saat database lambat. Tidak ada tim frontend untuk memperbaiki UI. Tidak ada tim DevOps untuk menangani deployment.

Yang Saya Bangun

  • Mesin Sinkronisasi Offline-First: Agen lapangan di area tanpa konektivitas bisa mengisi formulir, mengambil foto, mengumpulkan tanda tangan — semuanya sinkron saat mereka kembali ke jangkauan jaringan
  • Mesin Formulir Dinamis: 50+ tipe field dengan logika kondisional, dapat dikonfigurasi tanpa perubahan kode
  • Pipeline Persetujuan Multi-Level: 4 tingkat hierarki dengan routing berbasis peran dan jejak audit lengkap
  • Mesin Simulasi IIR: Perhitungan pembiayaan real-time yang sebelumnya memakan 3-5 hari kerja

Realitas Pengembang Tunggal

  • Kamu deploy kode sendiri. Jam 2 pagi. Di hari Sabtu.
  • Kamu debug insiden produksi sendiri. Tidak ada dukungan L2.
  • Kamu menulis dokumentasi sendiri. Jika tidak, tidak ada yang akan melakukannya — dan kamu akan menyesal dalam 6 bulan.
  • Kamu membuat keputusan arsitektur sendirian. Ini membebaskan sekaligus menakutkan — tidak ada yang memeriksa kewarasan keputusanmu.

Dampak

Metrik Sebelum Sesudah
Tingkat kehilangan data 23% 0%
Pengguna akhir yang dilayani 0 4,1 Juta
Waktu pembangunan N/A 30 hari (MVP)
Waktu keputusan pembiayaan 3-5 hari kerja Real-time

Kartu Skor Mid-Level Saya

Item Portofolio Apakah Saya Melakukannya? Catatan
2-3 studi kasus kerja ✅ SiTepat, HPU, Tepati — semuanya dengan dampak terukur
Metrik terukur ✅ 680 ribu unduhan, utilisasi 65→79%, kehilangan data 23% tereliminasi
Kontribusi open source ❌ Celah karir terbesar — mulai terlalu terlambat
Artikel teknis ⚠️ Menulis dokumentasi internal, tidak pernah dipublikasikan
Penanganan insiden produksi ✅ Bertahan dari 4 insiden besar, belajar lebih banyak dari itu daripada fitur mana pun

Saran untuk Mid-Level Engineer Saat Ini

  • Miliki siklus hidup penuh. Jangan hanya menulis fitur — deploy, monitor, debug, dan tingkatkan. Engineer yang menguasai full stack bernilai 3x lipat engineer yang hanya menulis kode.
  • Ukur sebelum dan sesudah. "Lebih cepat" adalah opini. "Latensi API turun dari 800ms menjadi 200ms" adalah item portofolio. Mulai ukur hari ini.
  • Tulis tentang insiden produksimu. Bug yang kamu perbaiki jam 2 pagi adalah postingan blog besok. Keputusan arsitektur yang kamu buat setelah insiden adalah bahan pembicaraan konferensi bulan depan.
  • Mulai open source sekarang. Bahkan satu PR ke proyek yang kamu gunakan. Skill yang kamu dapatkan — membaca codebase asing, mengikuti pedoman kontribusi, menerima review kode dari orang asing — persis yang diuji dalam wawancara senior+.

Mid-level adalah tahap karir yang paling diremehkan. Di sinilah kamu mengumpulkan luka produksi yang membuat portofolio senior-mu autentik. Setiap insiden, setiap rollback, setiap perbaikan jam 2 pagi — itu bukan trauma. Itu konten.

Artikel terkait

Karier
Karier
Yang Saya Lakukan di Level CTO — Strategi Bisnis Melalui Teknologi

Yang Saya Lakukan di Level CTO — Strategi Bisnis Melalui Teknologi

Di level ini, portofolio Anda bukan tentang teknologi — melainkan tentang bagaimana teknologi menciptakan nilai bisnis. Saya berhasil menekan biaya inferensi AI hingga 90%, membangun orkestrasi MCP yang melipatgandakan output developer 3x lipat, dan menetapkan strategi FOSS di mana setiap repositori menjadi aset portofolio 24/7. Inilah yang sebenarnya dihasilkan oleh kepemimpinan rekayasa.
Faisal Affan
Faisal Affan
Diterbitkan
Karier
Yang Saya Lakukan Sebagai Junior Developer — Fundamental yang Membentuk Segalanya

Yang Saya Lakukan Sebagai Junior Developer — Fundamental yang Membentuk Segalanya

Nol pengalaman production. GitHub penuh repo tutorial. Satu aset: kemampuan belajar cepat dan nol ketakutan merusak sesuatu. Ini yang benar-benar saya bangun sebagai junior engineer — situs WordPress, sistem universitas PHP, dan kesalahan hardcoded credentials yang mengajarkan saya keamanan selamanya.
Faisal Affan
Faisal Affan
Diterbitkan
Karier
Apa yang Saya Lakukan sebagai Senior Engineer — Arsitektur, Trade-Off, dan Pertimbangan Teknis

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
Faisal Affan
Diterbitkan
Karier
Apa yang Saya Lakukan sebagai Staff Engineer — Leverage, Standar, dan Dampak di Seluruh Organisasi

Apa yang Saya Lakukan sebagai Staff Engineer — Leverage, Standar, dan Dampak di Seluruh Organisasi

Seorang staff engineer tidak hanya memecahkan masalah sulit. Mereka memecahkan masalah yang menghalangi engineer lain untuk produktif. Saya membangun framework LMS multi-tenant yang melayani 100+ universitas, dynamic form engine yang diadopsi 3 tim, dan jembatan ISO 8583 yang menjadi standar organisasi. Seperti inilah wujud leverage di level staff sebenarnya.
Faisal Affan
Faisal Affan
Diterbitkan