Di hari Jumat, senior di komik tadi memegang selembar kertas. Junior berdiri di sebelah tumpukan kode yang lebih tinggi dari badannya. Keduanya menerima keluhan yang sama dan memakai AI yang sama. Akan tetapi, pekerjaan yang mereka selesaikan ternyata berbeda.
Junior memperbaiki database karena aplikasinya lambat. Senior membuka halaman yang dikeluhkan, lalu menemukan foto berukuran 40 MB. Dari sini kita bisa melihat bahwa perbedaannya sudah muncul sebelum mereka mulai menulis perubahan kode.
Menurut saya, bagian ini yang menarik untuk dibahas. AI bisa membantu kita menyelesaikan banyak pekerjaan, termasuk mencari penyebab masalah. Akan tetapi, hasilnya juga dipengaruhi informasi yang kita berikan, pertanyaan yang kita ajukan, dan cara kita mengecek jawabannya. Cerita ini memakai senior dan junior untuk memperlihatkan perbedaan tersebut. Kita tidak sedang membuat aturan bahwa semua senior pasti memilih langkah yang benar.
Aplikasinya lambat, kenapa langsung memperbaiki database?
Pada panel 1 sampai 3, pembaca sudah diperlihatkan foto yang membuat halaman lambat. Kedua engineer belum mengetahui hal itu. Mereka baru menerima tiket yang mengatakan aplikasinya lambat.
Kalau kita berada di posisi junior, database memang bisa menjadi salah satu dugaan. Halaman depan mungkin mengambil banyak data, menjalankan query yang terlalu berat, atau menunggu respons server terlalu lama. Dugaan itu cukup masuk akal untuk diperiksa.
Query adalah perintah untuk mengambil atau mengolah data di database. Sebagai contoh, mengambil daftar barang yang akan ditampilkan di halaman depan.*
Masalahnya, junior langsung memilih perbaikan dari dugaan tersebut. Permintaan kepada AI sudah mengarah ke optimasi database, padahal kita belum mempunyai pengukuran yang menunjukkan bahwa bagian itulah penyebab keluhan customer.
Senior di cerita ini mengambil langkah berbeda. Ia membuka halaman yang sama dengan customer dan memperhatikan proses loading-nya. Ia juga belum tahu jawabannya. Akan tetapi, langkah tersebut memberi informasi untuk menentukan bagian mana yang perlu diperiksa berikutnya.
Dengan konteks yang sama, junior juga bisa meminta AI membantu menyusun langkah pengecekan. Halaman mana yang perlu dibuka, data apa yang perlu dicatat, dan bagaimana membedakan waktu menunggu server dengan waktu download foto? Kita kemudian menjalankan pengecekan tersebut dan membandingkan hasilnya dengan dugaan awal.
Kenapa judulnya tiga derajat?
Pada panel 4, dua garis berangkat dari titik yang sama dengan selisih arah yang kecil. Di panel 8, sudutnya tetap sama, tetapi ujung kedua garis sudah berjauhan karena keduanya terus memanjang.
Anggap saja kita bergerak 100 meter dengan arah melenceng 3 derajat dari jalur yang dituju. Jarak ke sampingnya kurang lebih 5 meter. Kalau kita terus bergerak sampai 1.000 meter dengan arah yang sama, jarak ke sampingnya menjadi sekitar 52 meter. Sudutnya tidak perlu bertambah agar jaraknya makin besar.
Di pekerjaan engineering, tentu tidak ada ukuran derajat untuk sebuah keputusan. Gambar itu membantu menjelaskan bagaimana pekerjaan tambahan bisa terus mengikuti dugaan pertama yang belum diperiksa. Kita mulai dari perubahan query, lalu membuat test, menambah pengaturan, dan menyesuaikan kode lain agar cocok dengan perubahan tadi.
Kalau AI membantu kita menghasilkan perubahan lebih cepat, jumlah pekerjaan yang mengikuti dugaan tersebut juga bisa bertambah sebelum ada yang mengeceknya. Akan tetapi, AI juga bisa dipakai untuk membantu pengecekan lebih awal. Sehingga pengaruhnya bergantung pada bagian pekerjaan mana yang kita bantu dengan AI dan kapan hasilnya direview.
Angka sepuluh kali lebih banyak kode di komik juga bagian dari ilustrasi. Itu bukan ukuran peningkatan produktivitas yang saya anggap berlaku untuk semua tim. Tumpukan kertas dipakai untuk menunjukkan banyaknya pekerjaan yang sudah dibuat berdasarkan pilihan awal tadi.
Kalau test lolos, apa lagi yang perlu dicek?
Pada panel 6, junior sebenarnya mengajukan pertanyaan yang perlu: apakah database memang bagian yang lambat? Kalau pertanyaan ini ditindaklanjuti dengan pengukuran halaman customer, mereka mempunyai kesempatan untuk mengubah langkah sebelum menambah lebih banyak kode.
Jawaban robot di komik sengaja dibuat berlebihan. Robot memuji pertanyaannya, lalu memberikan versi kode yang lebih cepat. Pertanyaan tentang penyebab masalah belum dijawab, tetapi pekerjaannya sudah bergerak lagi.
Ini tidak berarti AI selalu setuju atau tidak bisa membantu analisa. Respons seperti itu bisa kita hentikan dan minta diperiksa kembali: data apa yang mendukung dugaan database lambat? Kalau belum ada datanya, apa yang perlu diukur? Penjelasan yang terdengar masuk akal tetap perlu dibandingkan dengan aplikasi yang sedang kita kerjakan.
Pada panel 7, test lolos dan benchmark membaik. Hasil tersebut dapat menunjukkan bahwa perubahan database bekerja sesuai hal yang diuji. Akan tetapi, kalau pengujiannya hanya mengukur query, kita belum mengetahui apakah waktu tunggu customer ikut berkurang.
Sehingga ada beberapa hal yang perlu kita bedakan saat review. Apakah perubahan kodenya bekerja? Apakah bagian yang diperbaiki memang menyebabkan masalah? Setelah perubahannya dipakai, apakah keluhan customer berkurang? Jawaban untuk pertanyaan pertama belum cukup untuk menjawab dua pertanyaan berikutnya.
Kenapa perubahan yang lebih kecil bisa lebih berguna?
Pada panel 9, senior menjelaskan bahwa foto di halaman depan berukuran 40 MB. Ia membuat ukurannya lebih kecil, dan dalam cerita tersebut halaman kemudian bisa dibuka di bawah satu detik. Junior baru menyadari bahwa ia sudah menulis ulang database untuk keluhan yang penyebabnya ada di bagian lain.
Angka waktu loading itu adalah hasil yang diberikan dalam cerita, bukan patokan untuk setiap foto 40 MB. Pada aplikasi sebenarnya, kita perlu mengukur lagi. Hasilnya bergantung pada ukuran file yang dikirim, koneksi, file lain di halaman tersebut, dan proses yang dijalankan browser.
Perbaikan foto juga tetap perlu diperiksa. Apakah gambarnya masih cukup jelas untuk kebutuhan customer? Apakah file asli tetap tersedia? Apakah browser mengambil versi baru, atau masih memakai file yang tersimpan sebelumnya? Pengujian sebelum dan setelah perubahan perlu memakai kondisi yang sebanding.
Selembar kertas yang dipegang senior tidak berarti perubahan kecil selalu lebih baik. Bisa saja database memang perlu diperbaiki. Kita perlu melihat hubungan perubahan itu dengan masalah yang ingin diselesaikan, termasuk risiko dan pekerjaan tambahan untuk merawatnya setelah dipakai.
Di panel 10, tumpukan kode junior masuk ke tempat sampah. Itu cara komik menggambarkan pekerjaan yang akhirnya tidak dipakai. Dalam pekerjaan sebenarnya, kita tidak perlu langsung menghapus semua perubahan. Kita bisa mereviewnya terpisah dan memeriksa apakah ada kegunaan lain yang cukup jelas. Akan tetapi, kode yang sudah terlanjur dibuat juga tidak harus dimasukkan ke aplikasi hanya karena kita sudah menghabiskan waktu untuk membuatnya.
Apa yang seharusnya dilakukan senior lebih awal?
Pada panel 11, senior baru membahas tujuan pekerjaan bersama junior. Menurut saya, percakapan ini seharusnya terjadi sebelum tumpukan kode tadi menjadi besar.
Kalau senior sudah lebih memahami aplikasi dan kemungkinan penyebabnya, pengalaman itu bisa dipakai untuk membantu junior menyusun pengecekan. Kita bisa mulai dari penjelasan pendek: customer mengalami masalah apa, dugaan penyebabnya apa, dan informasi apa yang sudah mendukung dugaan tersebut?
Misalnya, junior mengatakan bahwa ia ingin memperbaiki database karena halaman depan lambat. Senior bisa mengajaknya membuka halaman tersebut, mencatat bagian yang membutuhkan waktu paling lama, lalu membandingkannya dengan waktu query. Junior tetap mengerjakan analisa dan menjelaskan hasilnya. AI bisa membantu membaca kode, menyiapkan langkah pengujian, atau membandingkan catatan pengukuran.
Dari situ, review tidak perlu menunggu seluruh perubahan selesai. Setelah pengecekan awal, tim sudah bisa membahas apakah pekerjaan berikutnya masih sesuai dengan keluhan customer. Kalau dugaannya berubah, rencananya bisa diadjust saat jumlah perubahan masih sedikit.
Untuk tugas berikutnya, junior dapat menyimpan keluhan awal, kondisi pengujian, hasil pengukuran, dan alasan memilih perbaikannya bersama perubahan kode. Saat direview, senior bisa mengikuti cara berpikirnya dan tim bisa mengecek kembali halaman yang sama. Sehingga yang dipelajari junior juga mencakup cara memilih pekerjaan dan membuktikan hasilnya, selain cara menyelesaikan kode dengan bantuan AI.