Muhammad Royhan

Senior Fullstack Engineer · Team Lead

Tujuh tahun membangun sistem yang tidak boleh salah.

Backend dan frontend. Tujuh tahun, tiga promosi, satu perusahaan. Cara kerja saya bertumpu pada systems thinkingMemahami sistem dari cara bagian-bagiannya saling memengaruhi dari waktu ke waktu, bukan dari satu bagian yang dilihat terpisah. dan fokus ke hal yang bisa dikendalikanDikotomi kendali dari Stoikisme: keluarkan tenaga hanya untuk hal yang benar-benar bisa kita pengaruhi, lalu rancang sistem untuk mengantisipasi sisanya., supaya sistemnya tetap bisa dirawat setelah saya serahkan.

Tujuh tahun di satu perusahaan. Ini yang berubah tiap tahunnya
I2019

Junior Software Engineer

Mulai dari kode warisan orang lain

Saya tidak merencanakan masuk ke bidang ini. Moving Bytes Digital menerima saya tahun 2019. Pekerjaan pertama saya: membangun ERP, sekaligus melanjutkan marketplace sewa yang sudah dikerjakan orang lain.

Sampai 2021 saya merawat marketplace itu dan membangun aplikasi mobile-nya bersama tim. Dari situ muncul pertanyaan yang saya bawa sampai sekarang. Bagaimana caranya mengambil keputusan yang benar kalau variabelnya bukan milik kita?

II2022

Senior Software Engineer

Sistem bank, dari nol sampai serah terima

Tahun 2022 saya pegang sistem kredit karyawan untuk Bank Perkreditan Rakyat. Dari commit pertama sampai serah terima. Proyek pertama yang saya kerjakan sendiri dari awal, di bidang yang tidak menoleransi kesalahan sekecil apa pun.

Di sistem perbankan tidak ada bug yang sifatnya cuma tampilan. Angka yang salah itu utang seseorang. Tapi yang paling banyak mengajari saya justru serah terimanya: kode yang dilepas ke tim lain harus bisa menjelaskan dirinya sendiri, tanpa saya di ruangan.

III2023

Team Lead — Maintenance Sistem Legacy

Dipromosikan untuk merawat sistem orang lain

Promosi Team Lead datang tahun 2023. Bukan yang membangun sistem baru, bukan juga yang memimpin proyek unggulan. Yang menjaga semua sistem yang sudah rilis tetap jalan.

Hampir sepanjang tahun itu saya bekerja di dalam keputusan yang bukan saya buat, di kode yang tidak boleh saya tulis ulang, dengan tenggat yang bukan saya tentukan. Pelajarannya satu. Apa yang kita warisi hampir tidak pernah bisa kita kendalikan. Yang bisa kita kendalikan cuma satu: apakah orang berikutnya menerimanya dalam kondisi lebih jelas.

Setelah tujuh tahun, kira-kira begini saya memilahnya. Coba dulu beberapa sebelum lihat jawaban saya.

  • Codebase yang kita warisi

    Jawaban saya: Tidak bisaKeputusan yang sudah terlanjur dibuat bukan pilihan kita. Yang jadi pilihan kita cuma satu: apakah orang berikutnya menerimanya lebih jelas.

  • Tenggat dari klien

    Jawaban saya: Tidak bisaJarang kita yang menentukan. Yang milik kita adalah sejujur apa kita menyusun scope terhadap tenggat itu.

  • Struktur codebase

    Jawaban saya: Bisa dikendalikanIni benar-benar milik kita. Sebagian besar pekerjaan ada di sini.

  • Cara rekan tim melakukan debugging

    Jawaban saya: Tidak bisaKita bisa kasih konteks dan dokumentasi. Kita tidak bisa memaksa orang berpikir dengan cara kita.

  • Apakah API pihak ketiga tetap hidup

    Jawaban saya: Tidak bisaYang bisa kita atur cuma perilaku sistem kita saat API itu mati.

  • Test coverage di kode yang kita rilis

    Jawaban saya: Bisa dikendalikanTidak ada orang lain yang menentukan ini. Kalau tipis, itu keputusan kita sendiri.

IV2024

Team Lead

Payroll untuk 800+ karyawan

Dua tahun, dua sistem, satu engineer di masing-masing. Scroll untuk lihat bagaimana skalanya berubah, dan apa akibatnya ke arsitektur.

PAYROLL RUNSETIAP ANGKA BISA DILACAK

Satu perusahaan

  1. 2024. Sistem payroll untuk perusahaan sendiri. Internal, skala kecil, risikonya masih terkendali. Kalau ada yang rusak, saya dengar langsung dari meja sebelah.

  2. Jalan benar selama setahun. Sistem itu lalu jadi fondasi untuk versi klien. Bukan bikin ulang, tapi melanjutkan.

  3. 2025. Masalah yang sama, tapi untuk klien dengan lebih dari 800 karyawan. Di titik ini angka yang salah bukan lagi laporan bug. Itu gaji yang tidak sampai.

  4. Jadi saya dahulukan keterlacakan di atas kecepatan. Setiap angka bisa dilacak sampai ke sumbernya, setiap payroll run bisa dihitung ulang dari nol.

  5. Rilis Juni 2026. Jalan terus sejak itu, dan sampai sekarang masih saya yang rawat.

Ringkasan prinsip

Premis I
Salah hitung payroll bukan laporan bug. Itu gaji yang tidak sampai.
Premis II
Angka yang tidak bisa dihitung ulang dari sumbernya cuma bisa dipercaya, bukan diverifikasi.
Kesimpulan
Bangun supaya setiap angka bisa dihitung ulang. Kepercayaan bukan pengendalian.
VSekarang

Team Lead

Posisi saya sekarang

Balik ke pertanyaan di awal. Bagaimana caranya mengambil keputusan yang benar kalau variabelnya bukan milik kita?

Sampai sekarang saya belum punya jawaban yang rapi, dan sudah berhenti menunggu. Yang saya punya cara kerja: pisahkan yang bisa dirancang (batas modul, kepemilikan, keterlacakan) dari yang cuma bisa dihadapi.

Saya masuk bidang ini bukan karena passion. Saya bertahan karena ada orang yang bergantung pada hasil kerja saya. Ternyata itu alasan yang jauh lebih awet.

Di luar payroll, ada proyek sampingan Maret–Juni 2025 yang membawa cara kerja yang sama ke tim lintas negara.

Bukti

Tech Stack

Alat yang saya pakai. Dipilih karena tidak bikin kejutan waktu sistem lagi ramai.

Frontend

  • React.js
  • Next.js
  • Flutter
  • TypeScript

Backend

  • Node.js
  • Express.js
  • NestJS
  • REST API
  • Sequelize.js
  • JavaScript

Infra & Tools

  • MySQL
  • Docker
  • GitHub
  • Postman

Sedang mencari Senior Fullstack Engineer atau Team Lead?

Saya terbuka untuk peran itu, baik remote, hybrid, maupun on-site. Silakan hubungi langsung, tidak perlu isi form.