Senior Developer Bukan yang Paling Banyak Tahu, tapi yang Paling Sedikit Membuat Kekacauan

Gue pernah mengira developer senior adalah orang yang selalu punya jawaban tercepat. Setelah beberapa tahun, gue justru lebih percaya pada orang yang mau berhenti sebentar sebelum menjawab.

Senioritas bukan jumlah framework yang pernah disentuh. Senioritas terlihat dari kemampuan melihat efek samping: siapa yang akan merawat kode ini, apa yang terjadi saat traffic sepuluh kali lipat, dan apakah keputusan hari ini mengunci tim selama dua tahun.

Developer yang baik bisa membuat fitur. Developer yang lebih matang tahu kapan fitur itu belum perlu dibuat.

Mengurangi kekacauan

Orang senior menulis keputusan yang bisa dipahami enam bulan kemudian. Mereka memisahkan eksperimen dari production, memberi batas pada permission, dan tidak menyembunyikan trade-off di balik istilah “best practice”.

Mereka juga membuat review lebih aman. Kritik diarahkan ke kode dan risiko, bukan ego orang yang menulisnya. Ketika tidak tahu, mereka bilang tidak tahu lalu mencari bukti.

Yang paling penting, mereka tidak mengoptimalkan satu bagian sambil merusak sistem lain. Mereka bertanya apa yang harus tetap sederhana, apa yang boleh gagal, dan bagaimana tim memulihkan diri.

Kalau kehadiran seseorang membuat semua keputusan harus melewati dirinya, itu bukan senioritas. Itu bottleneck.

Menurut gue, ukuran senior yang paling jujur adalah ini: setelah ia bekerja, apakah tim menjadi lebih jelas, sistem lebih mudah dirawat, dan masalah lebih kecil saat gagal?

---

Senioritas terlihat ketika keadaan tidak ideal

Saat incident, orang yang paling berguna bukan selalu yang paling banyak bicara. Ia membantu tim membentuk situasi: apa yang diketahui, apa yang belum diketahui, dampaknya siapa, dan keputusan apa yang harus ditunda. Ia menjaga komunikasi tetap faktual sehingga orang lain bisa bekerja.

Senior juga tahu kapan harus menolak kompleksitas. Jika sebuah service hanya memiliki dua consumer, memecahnya menjadi lima deployment mungkin memperbesar permukaan kegagalan. Jika sebuah abstraksi membuat setiap perubahan harus melewati tiga layer, abstraksi itu sedang memindahkan biaya, bukan menghilangkannya.

Hal lain yang sering dilupakan adalah membangun pengganti. Dokumentasi, pairing, dan delegasi bukan pekerjaan tambahan yang mengganggu produktivitas. Itu cara memastikan sistem dan tim tidak bergantung pada satu kepala.

Saya lebih menghargai review yang menghasilkan pertanyaan bagus daripada review yang penuh koreksi gaya. Tujuan review bukan membuktikan siapa yang paling pintar; tujuannya mengurangi risiko sebelum kode bertemu pengguna.

Kalau pengalaman kita membuat tim lain lebih cepat mengambil keputusan tanpa kita, itu sinyal yang sehat. Senioritas yang tidak bisa ditransfer hanyalah ketergantungan yang diberi jabatan.

Sumber

• https://staffeng.com/guides/staff-archetypes/
• https://martinfowler.com/articles/technical-leadership.html
• https://sre.google/sre-book/part-I-foundations/