Apa yang Membuat Pengembang Menjadi Produktif

• Banyak faktor memengaruhi produktivitas pengembang
• Sebagiannya jelas dan mudah diukur, tetapi yang lain sulit diukur sehingga cenderung terlewat

Mengetahui apa yang harus dibangun (Knowing what to build)

• Membangun hal yang salah dengan cepat sama sekali tidak produktif
  • Harus tahu apa yang diinginkan pelanggan,
  • tahu apa yang dapat diterima oleh tim lain (berapa banyak indeks yang dimungkinkan pada tabel DB, apakah informasi yang secara hukum tidak boleh dibagikan bisa dibagikan?),
  • dan tahu apa yang pernah dicoba sebelumnya tetapi tidak berhasil

Melakukan lebih sedikit pekerjaan

• Menyelesaikan pekerjaan dengan cepat itu baik, tetapi lebih baik lagi jika sesuatu memang tidak perlu "dikerjakan" sama sekali
• Proses di perusahaan dapat menambahkan "pekerjaan sibuk" yang menurunkan produktivitas
  • Terkadang ada cara untuk dengan mudah menyesuaikan proses agar memberikan nilai yang sama dengan pekerjaan yang jauh lebih sedikit
• Sejumlah usaha mungkin diperlukan untuk "menjaga lampu tetap menyala (Keep the lights on, KTLO)"
• Ini adalah pekerjaan yang harus terus dilakukan (misalnya menjawab tiket dukungan), tetapi tidak mendorong proyek maju
• Pekerjaan seperti ini bisa terlihat produktif di berbagai metrik (jumlah tiket yang diselesaikan, jumlah commit yang di-merge), tetapi tidak membuat perusahaan menjadi lebih baik

Alat yang responsif

• Pengembang terus-menerus menggunakan alat: editor, git, sistem build
• Waktu tambahan yang ditimbulkan alat-alat ini bisa menjadi biaya yang cukup besar tergantung seberapa sering digunakan
• Bukan hanya biaya per jam, tetapi juga memecah fokus pengembang

Pengetahuan di kepala pengembang

• Sulit diukur
• Jika semua kondisi lain sama, pengembang dengan lebih banyak pengetahuan yang relevan akan lebih produktif
  • Karena mereka tahu bagaimana kode bekerja, mereka tidak perlu menelusuri kode terlalu dalam,
  • tahu cara menggunakan alat, dan tahu jebakan yang harus dihindari
  • mengajukan pertanyaan yang tepat
  • Pengembang 10x itu ada, dan mereka adalah "orang-orang yang sangat mengenal codebase"
• Ini berarti satu tim tidak seharusnya memiliki lebih banyak hal daripada yang bisa mereka simpan secara kolektif di kepala mereka. (Idealnya bus number lebih besar dari 1: teori Bus Factor)
  • Ini juga berarti menguntungkan untuk meminimalkan seberapa sering kepemilikan berubah
  • Tidak ada yang tahu lebih banyak tentang sesuatu daripada orang yang membuatnya
  • Idealnya, orang yang baru pertama kali menggunakan sebuah sistem bekerja dan belajar bersama orang yang sudah akrab dengan sistem tersebut
• Diperlukan batas yang jelas antar sistem
  • Antarmuka yang bersih dengan semantik sederhana berarti kita dapat memikirkan sifat-sifat antarmuka tanpa perlu mengetahui seluruh sistem di balik antarmuka tersebut
• Dokumentasi adalah cara yang baik untuk mentransfer pengetahuan
  • Terutama penting ketika pengembang harus melakukan tugas tertentu yang belum mereka kenal
  • Jika dokumentasi kurang, pengembang mungkin harus meneliti sendiri cara melakukan pekerjaan, membuat kesalahan lalu mengulang pekerjaan, atau menunggu tim lain menjawab pertanyaan, sehingga pekerjaan melambat
  • Ini bisa dengan cepat mengubah pekerjaan 1 jam menjadi pekerjaan 2 hari
  • Jika 100 pengembang harus melakukan pekerjaan ini, biaya dari hilangnya satu halaman dokumentasi bisa setara dengan gaji tahunan satu pengembang
• Ini juga berarti spesialisasi perlu ditingkatkan
  • Meminta semua pengembang melakukan pekerjaan yang sangat luas itu tidak produktif
  • Satu jam yang dihabiskan dalam proses untuk menulis beberapa sistem keamanan atau perencanaan kapasitas berbeda dengan satu jam yang dihabiskan untuk memahami domain demi menyelesaikan masalah

Infrastruktur yang berguna

• Infrastruktur seharusnya menjadi bantuan, bukan hambatan
• Harus cukup selaras secara masuk akal dengan semua pekerjaan yang perlu dilakukan
• Setiap bagian infrastruktur dirancang dengan use case tertentu dalam pikiran, tetapi dalam proyek kadang ada kasus yang keluar dari use case tersebut
  • Saat mendengar "Anda hanya boleh menggunakan infrastruktur kami" atau "Kami tidak bisa melakukan hal seperti itu di infrastruktur kami", rasanya sangat membuat frustrasi
  • Akibatnya, orang harus bekerja mengitari keterbatasan infrastruktur, atau membuang waktu masuk ke rapat untuk meyakinkan pemilik infrastruktur tentang kebutuhannya

Sedikit technical debt

• Kode yang sudah ada tidak akan pernah sepenuhnya cocok dengan pekerjaan yang ingin Anda lakukan
  • Penulis kode aslinya tidak punya "bola kristal" untuk melihat perubahan apa yang nanti akan Anda buat
  • Tetapi beberapa kode jauh lebih mudah diubah daripada kode lainnya
• Jawaban untuk "bagaimana kita bisa melakukan X?" seharusnya bukan "kita harus mendesain ulang semua ini"
• Jika technical debt banyak, bahkan perubahan kecil pada fitur akan memaksa perubahan sistem yang lebih besar
• Mengurangi technical debt dapat meminimalkan area paparan yang harus (a) dipahami dan (b) diubah
• Proyek untuk melunasi technical debt harus diselesaikan
  • Jika dihentikan di tengah jalan atau diturunkan prioritasnya, sistem bisa menjadi lebih buruk daripada sebelumnya

Tingkat kegagalan yang rendah

• Jika terjadi kegagalan saat menjalankan alat, kegagalan build, kegagalan deploy, atau regresi akibat error di production, itu adalah waktu yang terbuang
• Menurunkan kemungkinan kegagalan seperti ini akan meningkatkan produktivitas
• Selain insinyur yang mengalami kegagalan, hal ini juga cenderung membuang waktu tim yang memiliki sistem yang gagal (karena mereka harus bersama-sama menganalisis dan memperbaiki kegagalan itu)

Praktik produktif bersifat praktis (Productive practices are practical)

• Cara terbaik untuk belajar menyelesaikan masalah tertentu adalah dengan membuat prototipe
• Jika lingkungan menghambat pembuatan prototipe, pendekatan yang paling produktif pun bisa ikut terhambat
• Jika sulit menggunakan alat monitoring, pengembang akan membuat lebih sedikit dashboard, mengukur lebih sedikit hal, dan keputusan akan menjadi kurang berbasis data
• Sebaliknya, jika perubahan besar dipecah menjadi code review kecil-kecil, kode menjadi lebih mudah ditinjau dan di-deploy

Seberapa baik engineer bisa fokus

• Engineer bekerja mengikuti jadwal pembuatan, dan mereka perlu bisa fokus
• Fokus itu bisa dicuri oleh rapat dan interupsi
• Interupsi juga mencakup perintah CLI yang lambat, test yang lambat, dan pekerjaan yang harus diselidiki karena tidak tahu cara melakukannya
• Memikirkan terlalu banyak hal dalam satu minggu juga merusak kemampuan untuk fokus
• Deadline yang mendekat, atau pertanyaan yang belum dijawab manajer, tetap memakan RAM mental bahkan ketika mencoba fokus pada hal lain

Menyelesaikan pekerjaan

• Membangun 50% bukan berarti 50% produktivitas, melainkan 0% produktivitas
• Tidak ada yang lebih tidak produktif daripada pekerjaan yang akhirnya dibuang
• Kadang meninggalkan proyek di tengah jalan memang merupakan keputusan yang benar
  • Melawan kekeliruan sunk cost terkadang adalah hal yang tepat
  • Tetapi tidak boleh ada pola yang konsisten berupa perubahan prioritas sebelum proyek selesai
  • Dalam kasus seperti itu, produktivitas tim bisa turun menjadi 0

Penutup

• Kita tidak selalu bisa membangun dashboard untuk mengukur semua faktor yang beragam ini, tetapi kita tetap bisa mengetahui bagaimana hal-hal di atas memengaruhi produktivitas
• Menyelesaikan masalah-masalah ini dapat secara signifikan meningkatkan jumlah pekerjaan yang bisa dilakukan
• Beberapa masalah ternyata sangat mudah diperbaiki
  • Jika menghabiskan beberapa jam untuk menulis dokumentasi, perusahaan bisa menghemat ribuan jam
• Jika harus menebang pohon dengan cepat, mulailah dengan mengasah mata gergaji

[kofmania]

Wow, ini tulisan yang banyak bagian penutupnya ya

[laeyoung]

"Jika dokumentasi kurang memadai, kecepatan kerja pengembang bisa melambat karena mereka harus mencari sendiri cara mengerjakan tugas, membuat kesalahan lalu mengulang pekerjaan, atau menunggu tim lain menjawab pertanyaan."

Memang bukan dokumentasi pengembangan, tetapi saat saya meminta orang yang baru onboarding untuk memperbarui dokumen onboarding perusahaan seminggu setelah onboarding, dokumentasinya jadi membaik. Soalnya, ketika baru masuk dan belum punya informasi apa pun, merekalah yang paling tahu apa yang dibutuhkan pada saat itu.

Saya juga merasa banyak Readme.md pada proyek open source di GitHub ditulis dengan cukup baik mungkin karena banyak pengguna pertama yang datang lalu memberi umpan balik.

[devsepnine]

Akhir-akhir ini terlalu banyak pekerjaan yang datang sampai rasanya kewalahan T_T

[ahwjdekf]

Infrastruktur seharusnya menjadi bantuan, bukan hambatan --> saat ini perusahaan-perusahaan di Korea sama sekali tidak seperti itu dengan menjadikan keamanan sebagai alasan.

[hero512]

Saya memahami perasaannya, tetapi artikel ini ditulis dalam bahasa Inggris. Perusahaan-perusahaan di negara berbahasa Inggris juga tampaknya menghadapi situasi yang serupa.

[kuroneko]

Rasanya ini bukan sekadar ringkasan, melainkan sudah setingkat terjemahan... Terima kasih atas rangkuman yang detail.