Saya pikir ketika saya dewasa, seluruh permainan saling menyalahkan akan selesai. Tapi, saya rasa tidak, karena itu adalah sesuatu yang terlalu sering saya dengar di tempat kerja. Kesalahan terjadi, dan perubahan terjadi pada kode yang kita tulis setiap hari, namun saya masih gagal melihat manfaatnya menemukan seseorang untuk dijadikan target.

Pada tingkat tinggi (setidaknya di mata saya), ini adalah mekanisme pertahanan. “Jika sesuatu yang buruk terjadi dan itu tidak ada kaitannya dengan saya maka itu berarti saya aman”. Tentu saja, saya kira itu benar sampai batas tertentu, tetapi hal itu juga menghilangkan inti dari sebuah tim. Kami menang sebagai sebuah tim, dan kami kalah sebagai sebuah tim. Ada beberapa alasan mengapa pengembangan perangkat lunak adalah olahraga tim, saya akan menyebutkan beberapa di antaranya:

  • Kita bisa berkolaborasi dalam desain kode, dua kepala lebih baik dari satu.
  • Jika ada orang yang mengalami kebuntuan, terkadang ada gunanya membicarakannya dengan orang lain.
  • Orang lain mungkin pernah mencoba hal serupa di masa lalu tetapi tidak berhasil, mereka dapat menjelaskan alasannya.

Berdasarkan sifat dari banyaknya organisasi yang menyiapkan repositori mereka, biasanya Anda memerlukan setidaknya 2 orang untuk meninjau kode Anda dan menyatakan bahwa kode tersebut bagus agar dapat digabungkan. Jika orang yang melakukan tinjauan tersebut melakukan tugasnya, lalu bagaimana mungkin kita memulai permainan saling menyalahkan dan menuding langsung orang yang melakukan perubahan? Kita biasanya mengabaikan fakta bahwa setidaknya ada tiga orang yang seharusnya terkena masalah ini, bukan hanya satu orang. Namun hal itu pun menghindari maksudnya.

Kebanyakan pengembang yang bangga dengan pekerjaan mereka tidak akan “mengabaikan” masalah yang mereka timbulkan. Di masa lalu, ketika saya melakukan kesalahan, saya adalah musuh terbesar bagi diri saya sendiri. Saya akan merenungkan dan menyalahkan diri sendiri atas kesalahan yang dibuat untuk menentukan bagaimana saya bisa menguji atau merencanakan dengan lebih baik sehingga saya tidak membuat kesalahan yang sama lagi. Saya tidak membutuhkan orang lain untuk ikut-ikutan menunjukkan bahwa saya melakukannya. Itu hanya membantu menggali Anda ke dalam lubang yang semakin dalam. Sebuah tim ada untuk saling mendukung saat kita terpuruk, bukan mengubur mereka lebih jauh lagi.

Saya masih ingat suatu hari di kantor ketika bug pemuatan data menyusup ke dalam sistem. Kami pada dasarnya mengalami dua perubahan yang terjadi di area yang sangat mirip (tidak membantu jika keduanya berada dalam paket SSIS yang tidak mungkin digabungkan). Setelah digabungkan ke dalam cabang utama, proses build/uji otomatis beban data mulai gagal. Jadi pertama-tama, ini bagus! Otomatisasi kami menemukan masalah sebelum mencapai produksi. Dan kemudian, permainan saling menyalahkan pun terjadi. Karena kedua orang tersebut berada di dua tim sprint yang berbeda, maka menjadi sedikit politis “siapa yang melakukannya maka Anda harus memperbaikinya”. Parahnya lagi, developer yang melakukan blaming merasa seperti kehabisan darah, target serangannya, rekan satu tim saya yang merupakan developer yang jauh lebih bersuara lembut sehingga tidak akan membela diri. Mereka dikalahkan dan dipukuli.

Saat itu saya hanya berkata, dan terus berkata “Saya tidak peduli siapa yang menulis kodenya, di sinilah kita berada sekarang, bagaimana cara memperbaikinya”. Akhirnya, setelah sekitar 10 menit bersikeras mencari kesalahan, kami beralih ke fase “bagaimana cara memperbaikinya”. Sampai hari ini, saya tidak melihat ada manfaatnya pembicaraan yang berlangsung terlalu lama untuk mencari kesalahan, hanya membuang-buang waktu saja.

Saya masih memiliki beberapa orang yang bertanya kepada saya, “siapa yang membuat perubahan”, ketika ada bug yang muncul. Jawaban saya selalu “tidak masalah”, atau “Saya tidak tahu”. Ya, kalau saya memang mau, saya bisa mengetahuinya, tapi untuk pengembangan aplikasi, sebenarnya tidak masalah. Semua itu akan menodai pandangan pengembang di mata mereka, padahal seluruh tim saya adalah orang-orang yang menerima perubahan tersebut.

Permainan menyalahkan hanya merugikan pengembang lain untuk membangun pengembang lain dan harus dihindari dengan cara apa pun. Ketika dalam situasi ditemukan masalah, jangan tanya “siapa penyebabnya”, tanyakan yang lebih konstruktif “apa yang bisa kita lakukan untuk memperbaikinya”. Ini akan membantu mengarah pada percakapan yang lebih sehat.

Awalnya diterbitkan di https://blog.judd.dev.