Dari Junior ke Senior Engineer: Skill Non-Teknis yang Benar-benar Membedakan, Menurut Pengalaman Saya

Lima tahun lalu, saya dan seorang rekan kerja sama-sama mengerjakan migrasi database yang sama-sama sulit. Kode kami tidak jauh berbeda kualitasnya. Tapi enam bulan kemudian dia yang dipercaya lead proyek berikutnya, dan saya masih diberi tiket kecil. Waktu itu saya kesal — sekarang saya paham kenapa: dia lebih dulu paham bahwa pekerjaan engineer itu bukan sekadar menulis kode, tapi menyelesaikan masalah bisnis dan membuat orang lain paham keputusannya.

Ini bukan artikel motivasi. Ini daftar skill non-teknis yang benar-benar mengubah cara saya dinilai di tim, lengkap dengan kesalahan konkret yang saya buat di masing-masing area.

1. Menulis Secara Jernih Itu Setengah dari Pekerjaan Anda

Kesalahan terbesar saya sebagai junior: menganggap PR yang bagus cukup dengan kode yang bagus. Sekarang setiap PR yang saya buka, deskripsinya menjawab tiga hal — kenapa perubahan ini perlu, apa yang berubah, dan apa risikonya. Reviewer yang tidak perlu menduga niat saya akan menyetujui PR dua kali lebih cepat. Itu bukan perasaan; itu pola yang saya lihat konsisten selama bertahun-tahun.

Bukan cuma PR. Design doc yang bisa dibaca PM, postmortem yang tidak mencari kambing hitam, komentar commit yang menjelaskan alasan — semua itu meninggalkan jejak yang lebih awet daripada kode itu sendiri. Kode akan ditulis ulang; dokumen keputusan Anda akan dibaca orang lima tahun kemudian dan menentukan apakah mereka mengulangi kesalahan Anda.

# Contoh struktur deskripsi PR yang saya pakai sekarang

**Kenapa:** Tenant melaporkan data hilang setelah upgrade paket (tiket #482).

**Apa yang berubah:** Query migrasi paket sekarang dibungkus transaksi
dengan row-level lock, bukan dua UPDATE terpisah.

**Risiko:** Lock bisa menahan request lain maksimal ~200ms pada tabel
aktif. Sudah diukur di staging dengan 500 concurrent request.

Perhatikan bagian risiko. Junior menyembunyikan risiko karena takut ditolak. Senior menuliskannya di depan — itu sinyal bahwa mereka sudah memikirkannya.

2. Kepemilikan: Bukan Berarti Kerja Sampai Tengah Malam

Dulu saya salah paham istilah "ownership". Saya kira itu berarti mengerjakan semua sendiri. Hasilnya: bottleneck, saya jadi satu-satunya yang paham satu modul, dan liburan saya dihabiskan memandu orang lewat chat.

Kepemilikan yang sebenarnya, seperti yang saya pahami sekarang: Anda bertanggung jawab atas hasil, bukan atas jumlah baris yang Anda tulis. Kalau bug muncul di kode yang Anda tulis dua tahun lalu dan sekarang ditangani orang lain, Anda tetap ikut membantu konteksnya. Kalau ada keputusan arsitektur yang bakal menyesatkan tim, Anda angkat meski itu bukan "tugas Anda".

Bentuk paling praktis dari kepemilikan yang saya ajarkan ke engineer muda di tim saya:

• Jangan pernah bilang "itu bukan bagianku" sebelum mencoba membantu 15 menit.
• Kalau Anda menemukan masalah yang bukan ranah Anda, buat tiketnya lengkap dengan langkah reproduksi — jangan cuma kabari di chat lalu hilang.
• Kalau Anda membangun fitur, Anda yang menulis dokumentasi event audit yang relevan kalau fitur itu menyentuh data tenant.

Poin terakhir itu pengalaman nyata: fitur yang dulu saya rilis tanpa audit log yang memadai berujung komplain tenant yang tidak bisa kami selidiki. Sejak itu, "sudah tercatat dan bisa ditelusuri" jadi bagian dari definisi selesai.

3. Memperkirakan Waktu — dan Jujur Saat Meleset

Skill yang paling diremehkan junior: estimasi. Junior memberi angka optimis karena takut dianggap lambat. Senior memberi rentang dengan asumsi eksplisit, lalu update lebih awal begitu keadaan berubah.

Template yang saya pakai untuk tugas non-trivial:

Estimasi: 3-5 hari kerja
Asumsi: skema DB final, tidak ada perubahan requirement mid-way
Tidak termasuk: migrasi data lama (butuh investigasi terpisah, ~2 hari)
Titik checkpoint: hari ke-2, demo query utama

Kuncinya bukan akurasinya — tidak ada estimasi yang selalu akurat, diskusi asumsi keliru yang bertahan lama di Stack Overflow menunjukkan betapa mudah kita memegang keyakinan yang salah, termasuk soal perkiraan usaha sendiri. Kuncinya adalah komunikasi dini saat meleset. "Bakal telat 2 hari, sebabnya X, ini opsi untuk memangkas scope" itu kalimat senior. Diam sampai deadline baru bilang belum selesai, itu kalimat yang menghancurkan kepercayaan tim.

4. Membaca Kode Orang Lain Tanpa Menguji Ego

Junior melihat kode lama yang berantakan dan berpikir "siapa yang menulis sampah ini". Senior melihat kode lama dan bertanya "keputusan apa yang melatarbelakangi ini". Sering kali kode itu "jelek" karena constraint yang tidak lagi ada — deadline darurat, bug produksi yang harus di-patch jam 2 pagi, atau API pihak ketiga yang dulu berperilaku berbeda.

Ini skill yang bisa dilatih dan berdampak langsung: sebelum refactor apapun, saya habiskan 30-60 menit membaca git blame dan riwayat PR dari file yang bersangkutan. Sering saya menemukan komentar atau diskusi yang menjelaskan kenapa sesuatu ditulis dengan cara yang "aneh". Beberapa kali itu menyelamatkan saya dari menghapus guard yang ternyata menambal bug produksi berat.

5. Berkomunikasi dengan Non-Engineer Tanpa Membenci Meeting

PM tidak butuh tahu perbedaan soft delete dan hard delete secara internal; mereka butuh tahu konsekwensinya ke pengguna. Kalau PM bertanya "kapan selesai", mereka tidak sedang menguji Anda — mereka butuh info untuk keputusan bisnis mereka sendiri.

Latihan yang saya pakai: setiap kali menjelaskan hal teknis ke non-engineer, saya pakai struktur masalah → opsi → rekomendasi → kebutuhan keputusan. Tidak lebih dari lima menit. Contoh nyata — saat tim memutuskan strategi penghapusan data, saya tidak bahas implementasi; saya bahas risiko data hilang permanen versus tumpukan data sampah, lalu tunjuk arah. Pembahasan teknis lengkapnya seperti perbandingan soft delete vs hard delete yang saya tulis sebelumnya tetap saya simpan untuk sesama engineer.

6. Menanyakan "Kenapa" Sebelum Menyentuh Kode

Pertanyaan yang paling mengubah karier saya bukan pertanyaan teknis. Pertanyaannya: "masalah bisnis apa yang sebenarnya ingin kita selesaikan di sini?" Saya kehilangan minggu-minggu membangun solusi elegan untuk masalah yang bisa diselesaikan dengan query yang lebih baik dan perubahan proses kecil.

Junior menerima tiket, senior mempertanyakan tiketnya — dengan hormat, dengan konteks, dan sesudah mencoba paham dulu kenapa tiket itu dibuat. Ada buku yang kini membahas transisi junior ke senior secara sistematis, "Junior to Senior" di Holloway, dan diskusinya menarik justru karena banyak pembaca setuju bahwa jurang utamanya bukan soal menguasai framework baru.

Yang Bukan Berarti Anda Berhenti Belajar Teknis

Supaya jelas: ini bukan ajakan berhenti ngoding dan main politik kantor. Fondasi teknis tetap prasyarat — tanpa itu, semua skill komunikasi hanya kepiawaian berbicara tanpa substansi. Tetap pelajari hal-hal fundamental seperti prinsip 12-Factor App untuk aplikasi yang mudah di-deploy, tetap pahami database Anda, tetap mau debug sampai akar masalah.

Bedanya, di level senior semua itu jadi hygiene factor: keberadaannya dianggap wajar, ketiadaannya fatal. Yang membedakan Anda dari kandidat senior lain adalah hal-hal di atas.

Takeaway yang Bisa Anda Mulai Besok

Kalau mau mulai satu hal saja, mulai dari menulis. Tiga PR ke depan, pakai struktur kenapa-apa-risiko di deskripsinya. Lalu satu design doc kecil untuk keputusan teknis berikutnya, maksimal satu halaman. Setelah sebulan, bandingkan kecepatan review dan kualitas pertanyaan reviewer — menurut pengalaman saya, perubahannya terasa dan itu feedback loop tercepat untuk skill non-teknis nomor satu.

Setelah itu barulah latihan estimasi dengan asumsi eksplisit, dan kebiasaan membaca sejarah kode sebelum refactor. Tidak ada yang butuh izin atasan. Semua bisa dimulai tanpa ada yang menyuruh — dan justru itu inti dari jadi senior.

Sumber

• Show HN: My book for programmers called "Junior to Senior" — Holloway — referensi buku dan diskusi komunitas tentang transisi junior ke senior.
• Long-held, incorrect programming assumptions — Stack Overflow — contoh betapa mudahnya asumsi keliru bertahan lama, termasuk soal estimasi dan keyakinan diri.