Programmer Terburuk yang Pernah Saya Kenal
(dannorth.net)- Sebuah tim konsultasi di Big Bank mencoba mengukur produktivitas individu dengan story/story point yang diselesaikan, dan Tim Mackinnon berulang kali mendapat skor 0 pada metrik itu
- Alasan skornya 0 bukan karena ia tidak bekerja, melainkan karena ia tidak mengambil story atas namanya sendiri dan menghabiskan sebagian besar harinya untuk pair programming
- Kepada pengembang yang kurang berpengalaman, alih-alih memberi jawaban langsung, ia menciptakan pembelajaran lewat pertanyaan Socratic; dengan senior, ia mencari solusi yang lebih baik bersama melalui sudut pandang yang berbeda
- Tim bekerja dengan lebih efektif, lebih produktif, dan lebih selaras ketika bersama Tim, dan manajer pada akhirnya diam-diam membuang metrik produktivitas individu sambil tetap mempertahankan Tim
- Karena cara mengukur kontribusi individu secara terpisah bisa membuat kontribusi seperti milik Tim terlihat 0, produktivitas harus dilihat dari dampak bisnis dan aliran kerja tingkat tim
“Programmer Skor 0” yang Diciptakan Metrik Individu
- Sebuah tim di Big Bank memperkenalkan metrik kinerja per individu untuk evaluasi performa pribadi dan tujuan pengembangan
- Manajer menghindari metrik seperti jumlah baris kode atau jumlah bug yang mudah dimanipulasi, lalu memilih story atau story point yang selesai sebagai objek pengukuran karena dianggap mewakili nilai bisnis
- Karena setiap orang mencantumkan namanya pada story di alat yang mirip Jira, membuat metrik produktivitas per individu menjadi mudah
- Skor Tim Mackinnon bukan sekadar rendah, tetapi benar-benar 0 setiap minggu dan di setiap iterasi
- Manajer menilai Tim harus dikeluarkan dari tim dan diganti dengan orang yang benar-benar “mengirimkan” story, tetapi lead tim menolak hal itu
Apa yang Sebenarnya Dihasilkan Tim
- Tim tidak mengambil story atas namanya sendiri, melainkan bekerja sambil berpasangan dengan anggota tim yang berbeda setiap hari
- Saat bekerja dengan pengembang yang kurang berpengalaman, ia membiarkan mereka yang mengemudi langsung dan dengan lembut membimbing mereka menuju solusi
- Tidak memaksakan jawaban atau mendorong secara keras
- Menciptakan momen belajar dengan pertanyaan seperti “what if”, “how else”, dan Socratic questions
- Dengan pengembang senior, ia bekerja dengan cara yang lebih mirip penciptaan bersama atau sparring, menerapkan pandangan dunia yang berbeda pada masalah dan menghasilkan sesuatu yang sulit dipikirkan sendirian
- Alih-alih langsung mengirimkan software, Tim membangun tim yang mengirimkan software
- Seluruh tim bergerak dengan lebih efektif dan produktif
- Bekerja dengan cara yang lebih selaras dan lebih toleran
- Pengalaman bekerja bersama juga menjadi lebih menyenangkan
- Saat manajer datang untuk mengamati tim, Tim selalu sedang bersama orang lain mengerjakan “pekerjaan orang itu”, dan hasilnya memiliki kualitas lebih baik serta waktu penyampaian nilai yang lebih singkat
- Pada akhirnya tim mempertahankan Tim, dan memilih akuntabilitas tim alih-alih metrik produktivitas individu
- Mereka melacak dan merayakan dampak bisnis yang dikirimkan ke organisasi sebagai unit berkinerja tinggi
Ke Mana Seharusnya Produktivitas Dilihat
- Mengukur produktivitas sendiri memang perlu, dan untuk memiliki dampak bisnis yang terukur adalah hal yang ideal demi akuntabilitas
- Jumlah uang yang dihemat
- Jumlah uang yang dihasilkan
- Jumlah uang yang dilindungi
- Jika pengukuran dampak bisnis langsung sulit, metrik bisnis pengganti juga bisa digunakan
- Dalam sistem adaptif yang kompleks, asumsi bahwa kontribusi satu individu bisa dipisahkan dan diukur secara tersendiri sejak awal sudah goyah
- Metrik DORA tidak mengukur kontribusi piston individu, melainkan cara kerja sistem kerja
- Bisa dilihat sebagai metrik budaya Westrum
- Bisa juga dilihat sebagai metrik yang mengamati bagaimana perubahan teknis mengalir ke production
- Metrik individu bisa membuat kontribusi nyata orang seperti Tim terlihat 0, dan pendekatan yang melihat kinerja tingkat tim serta aliran di level sistem jauh lebih tepat
1 komentar
Komentar Hacker News
Sekitar 20 tahun lalu saya bekerja di sebuah perusahaan perangkat lunak menengah yang menjual aplikasi desktop untuk Mac dan Windows. Timnya sebagian besar hanya berpengalaman dengan Mac dan baru mulai belajar Windows, jadi versi Windows punya banyak masalah
Saat itu saya dikenal sebagai pakar Windows, jadi saya direkrut untuk memperbaiki versi tersebut dan membantu tim terbiasa dengan pemrograman Windows
Bagian awal hari biasanya saya habiskan seperti “kunjungan dokter”, berkeliling ke ruang developer lain untuk pair programming, menyelidiki bug, dan membahas praktik terbaik Windows API. Belakangan seorang rekan bertanya, “Bagaimana kamu bisa punya waktu selonggar itu?”
Beberapa bulan kemudian, dalam evaluasi, saya mendapat penilaian bahwa “produktivitasnya tidak setinggi yang diharapkan, terutama mengingat produktivitas anggota tim lain belakangan meningkat,” padahal menurut saya justru itulah alasan mereka merekrut saya
Berbagi pengetahuan adalah manfaat terbesar yang bisa diberikan kepada developer lain, tetapi orang-orang yang memilih jalan itu mendapat imbalan yang terlalu kecil
Tanpa developer seperti ini, dunia perangkat lunak saat ini bahkan tidak akan mendekati keadaan sekarang, dan meski mereka tidak mendapat ucapan terima kasih langsung, mereka jelas bernilai
Semua pekerjaan perbaikan punya prioritas yang sama, tetapi tingkat kesulitannya berbeda. Setelah belajar selama sebulan, dan karena tidak ada yang mau mengerjakannya, saya mengambil perbaikan base station. Pekerjaan itu memakan waktu lebih lama, tetapi jauh lebih penting bagi operasional
Di rapat akhir bulan, muncul pie chart tingkat utilisasi, dan saya terlihat jauh lebih buruk dibanding para senior yang berpengalaman
Saat itu saya belajar mengapa para senior memilih pekerjaan yang cepat dan mudah saja, juga tentang adanya politik kantor. Mengalami atasan yang buruk di awal karier justru merupakan keberuntungan
Dalam evaluasi pertama, manajer baru saya awalnya sudah menyiapkan rencana peningkatan kinerja, tetapi setelah kami pindah ke open office, ia melihat orang-orang mengantre untuk meminta bantuan saya dan saya tidak pernah menolak siapa pun, lalu mengakui bahwa ia membuang rencana itu
Kehilangan cubicle memang agak menyebalkan, tetapi berkat kejadian itu saya jadi memandang open office secara positif
Tentu saja sekarang saya tidak bekerja di kantor mana pun, dan tidak berniat menerima pekerjaan lagi kalau bukan work from home
Baru setelah reputasi terbentuk, kita bisa mengubah sesuatu; sebelumnya itu sulit
Terlalu banyak orang mengoptimalkan diri demi “tim” lalu dipecat atau tersisih dari promosi karena persepsi negatif dari atasan. Sebaliknya, orang yang memperoleh reputasi baik berdasarkan standar yang saat ini dipentingkan perusahaan sering kali cukup lama ditoleransi meski melakukan perilaku buruk
Apakah ia langsung pergi ke tempat yang lebih baik, mulai lebih sedikit membagi waktunya agar sesuai dengan metrik kinerja perusahaan, atau berhasil meyakinkan seseorang yang cukup tinggi di bagan organisasi bahwa ia memang direkrut untuk peran seperti itu?
Saya teringat anekdot Bell Labs
Seseorang menghitung karyawan paling produktif berdasarkan metrik seperti jumlah paten, lalu menemukan bahwa banyak dari mereka makan siang dengan orang yang sama
Orang itu sendiri tidak punya produktivitas individual yang tinggi, tetapi ia selalu mengajukan pertanyaan yang mendalam dan persuasif sehingga membuat rekan-rekannya menjadi lebih produktif secara terukur
Para pengacara di departemen paten Bell Labs mencoba mencari prinsip organisasi yang menjelaskan mengapa sebagian orang lebih produktif. Satu-satunya kesamaan adalah para karyawan dengan banyak paten sering makan siang atau sarapan bersama insinyur listrik Harry Nyquist
Nyquist tidak memberikan ide spesifik; ia membuat orang-orang terbuka dan berpikir, dan yang terpenting, mengajukan pertanyaan bagus
Kelompok manusia adalah struktur yang halus, sehingga suasana tim yang baik dan pertanyaan yang baik dapat memperbaiki keadaan tanpa terlihat
Kalau tidak, sulit bagi mereka untuk mendapat upah yang adil
Menurut saya tidak
Di perusahaan tempat saya bekerja selama beberapa tahun, kalau tidak menghasilkan 10 poin per minggu, seseorang akan masuk target perbaikan kinerja, tak peduli junior atau senior
Saya pernah melewati beberapa tim, dan cara sebuah tim mengukur poin bisa langsung terlihat hanya dari tingkat stres para developer
Tim yang berusaha mengukur poin dengan niat baik menjadi stres, kebanyakan menunjukkan tanda-tanda burnout, dan bekerja 60 jam seminggu
Sebaliknya, tim yang memperlakukan sistem itu seperti game dan memahami bahwa itu tugas yang mustahil memberi poin setinggi mungkin pada tiket, atau memecahnya menjadi tiket-tiket kecil lalu terus menumpuk skor; mereka bahagia tanpa stres
Dalam lingkungan seperti itu, mengikuti aturan adalah strategi orang polos yang mudah dimanfaatkan, dan ketika saya akhirnya berhenti, 7 senior engineer perusahaan itu semuanya ikut keluar dalam waktu 4 bulan
Tujuannya adalah membagi pekerjaan menjadi cerita-cerita yang bisa dicapai secara konsisten tanpa stres, alih-alih cerita dengan ketidakpastian dan risiko besar
Bukan berarti tempat kerja itu terlihat bagus, tetapi para developer yang menganggap mereka “mempermainkan sistem” pada umumnya tampak bergerak sesuai cara yang memang ingin didorong Scrum
Namun memaksa poin minimum per minggu hingga mendorong penggelembungan poin adalah manajemen yang buruk sekali
Karena mereka berhasil memeras lebih banyak pekerjaan dari orang-orang yang sama dibanding jika tidak memberi tekanan
Mantan atasan saya pernah terang-terangan berkata bahwa untuk menyelesaikan proyek ia akan “merekrut orang lalu membakarnya habis”, dan rencananya cukup kalau mereka bisa bekerja berguna selama 6 bulan
Kalau mereka bertahan menanggung stres dan kompensasi rendah, itu dianggap bonus bagi perusahaan, dan saya sendiri tidak bertahan lama
Kalau minggu itu belum bisa selesai, tiketnya ditandai selesai, lalu pekerjaan sisanya dibuka lagi sebagai bug
“Begitu sebuah ukuran menjadi target, ukuran itu berhenti menjadi ukuran yang baik”
Di beberapa tempat, mengetahui apa yang bisa diharapkan manajer lebih penting daripada produktivitas murni menuju sasaran
Orang-orang yang memperkirakan dengan niat baik mungkin mengira manajemen juga bertindak dengan niat baik, tetapi banyak proyek dibuat berdasarkan harapan semata, atau diberi tenggat yang dibuat-buat sangat pendek untuk “memotivasi” orang
Stres itu mungkin tidak menciptakan banyak nilai selain kepuasan emosional bagi manajer
Jika kinerja software engineer dinilai oleh orang nonteknis, hasilnya bisa dramatis
Teman saya “Tommy” adalah staf IT dengan kemampuan jaringan yang hebat, dan beberapa minggu setelah pindah ke perusahaan energi milik pemerintah, ia harus membangun ulang total jaringan dengan perangkat modern, termasuk sampai semua gedung kantor pusat
Perusahaan berniat menyerahkannya ke vendor luar, tetapi setelah melihat biaya yang disusun bagian keuangan, Tommy terkejut, lalu mengatakan ia bisa melakukannya sendiri asalkan ada perangkat fisik seperti router, switch, dan kabel, serta 2 orang untuk pemasangan kabel
Dalam beberapa minggu ia menyelesaikan pekerjaan itu dengan biaya kurang dari sepersepuluh anggaran awal, tetapi yang ia terima hanya ucapan lisan dari atasannya: “terima kasih, kerja bagus”
Sungguh getir menjadi teknisi IT di era ketika atasan-atasan yang kolot tidak memahami nilai sebenarnya
Nantinya Tommy bisa masuk sebagai kontraktor dan mendapat bayaran tambahan
Developer yang benar-benar hebat yang pernah bekerja bersama saya bisa menulis kode yang bagus, dan juga kode buruk yang harus segera dibuang; keduanya justru membuatnya menyenangkan diajak bekerja
Nilai dari kode yang baik tidak perlu dijelaskan, dan mungkin saja kami masih memakai kodenya sampai sekarang
Namun ia juga luar biasa dalam situasi darurat
Ketika pelanggan benar-benar berhenti beroperasi dan mungkin itu kesalahan kami, ia langsung muncul, cepat memahami masalah, lalu dengan cepat menulis dan memasang kode spaghetti yang berantakan agar pelanggan bisa kembali berjalan
Kode itu menyakitkan mata, tidak bisa di-check-in maupun di-refactor, tetapi krisis langsung terhindarkan sementara seseorang nantinya memperbaikinya dengan benar
Saya justru lebih kagum pada kemampuan yang terakhir ini, karena di atas segalanya itu keterampilan yang langka, dan ia memang orang baik sehingga semua orang menyukainya
Meski begitu saya menyelesaikan pekerjaan dengan cepat, dan kode aneh saya berkali-kali menyelamatkan hari dengan mengatasi situasi darurat atau memenangkan tender
Sulit berkomunikasi dengan developer yang “perfeksionis”; bagi mereka, jika kode tidak dirancang dengan cukup matang, kebutuhan akan kecepatan pun seolah tidak bernilai
Tentu saja mereka juga mungkin berpikir sebaliknya tentang saya
Sekarang kami membuat rapat mingguan untuk meredakan masalah, dan itu cukup berhasil
Yang paling sulit adalah menentukan pendekatan mana yang tepat ketika situasinya bukan darurat, tetapi jadwal ketat dan spesifikasi tidak jelas; setidaknya sekarang keputusan dibuat bersama
Bukan berarti tidak bisa dipelajari sendiri, tetapi bagi saya, menghafal masalah umum dan solusinya sampai bisa mengetiknya secara mekanis adalah hal yang benar-benar menyiksa
Selama Anda tidak memiliki perusahaan sendiri, Anda selalu dinilai berdasarkan nilai yang tampak dari luar
Jika pemberi kerja tidak bisa melihat nilai Anda secara visual, kecil kemungkinan Anda bertahan di sana
Sistem kinerja meritokratis yang sempurna memang ideal, tetapi jika perekrutan atau evaluasi berada di tangan orang lain, keberhasilan 100% bergantung pada bagaimana orang itu memandang Anda
Persepsi itu muncul dari apa yang tampak di luar, terlepas dari apakah hal itu benar-benar bernilai bagi perusahaan atau tidak
Yang dibicarakan di sini bukan kemampuan programming atau nilai nyata, melainkan perekrutan dan evaluasi; dan banyak juga orang yang produktif sekaligus pandai mengelola reputasi
Secara pribadi, saya ingin para senior di tim benar-benar mengerjakan hal-hal yang sulit
Membantu junior agar bisa bekerja memang bagus, tetapi untuk pekerjaan yang sulit dan kompleks yang tidak bisa dilakukan junior karena kurang pengetahuan, pengalaman, dan keterampilan interpersonal, orang yang berpengalaman tetap dibutuhkan
Pair programming seperti apa pun tidak bisa sepenuhnya menggantikan itu
Kita harus menghindari situasi ketika fitur bernilai rendah diimplementasikan dengan sangat baik, tetapi pekerjaan berdampak tinggi dan berprioritas tinggi tidak selesai karena orang-orang paling berpengalaman sibuk membantu yang kurang berpengalaman dengan hal-hal seperti cara menulis unit test
Fakta bahwa sebuah tugas diberikan kepada junior bukan berarti secara default itu masalah mudah; kalau tidak begitu, bagaimana kita bisa menumbuhkan kemampuan engineer?
Tidak semua senior boleh menghabiskan waktunya untuk mentoring junior dan kolaborasi, tetapi jika ada beberapa orang seperti ini di tim, mereka berperan sebagai pengganda kekuatan dan menguntungkan seluruh tim
Walaupun perusahaan tidak mengetahuinya saat merekrut, jika ia sudah menemukan ceruk peran yang berguna, perusahaan seharusnya mengubahnya menjadi peran resmi
Ia adalah coach, dan itu tidak masalah jika memang direkrut untuk peran seperti itu, tetapi kalau perusahaan menginginkan coach, kemungkinan mereka akan merekrutnya secara terpisah
Ada kalanya fitur sulit tidak bisa diselesaikan junior meski diberi waktu tak terbatas, karena mereka belum memiliki skill-nya dan skill itu butuh bertahun-tahun untuk terbentuk
Bantuan senior sesekali memang diperlukan, tetapi jika karena itu senior tidak menghasilkan apa pun, nilainya bagi perusahaan menjadi lemah
Fitur sulit sebaiknya diberikan kepada orang yang cukup senior; jika ingin mengembangkan junior, bagikan bagian yang lebih mudah dari pekerjaan itu dan minta senior menjelaskan apa yang sedang ia lakukan
Sikap Tim yang membantu semua orang memang hebat, tetapi juga aneh jika programmer lain membutuhkan bantuan sebanyak itu sampai Tim sama sekali tidak punya waktu menghasilkan output sendiri
Masalahnya bukan pada Tim, melainkan pada manajemen yang menganggap wajar kondisi ketika para profesional selalu membutuhkan bantuan dan struktur ketika Tim seperti relawan selalu siap membantu kapan saja
Sejak awal, jika salah satu senior membuatnya dengan benar, junior seharusnya juga bisa memperbaikinya
Jika senior itu yang membuatnya tetapi strukturnya tetap membuatnya sulit dan kompleks, patut dipertanyakan mengapa ia disebut senior
Meski begitu, pekerjaan semua senior tidak bisa hanya membantu junior
Menjadi orang seperti itu sekarang sulit
Karena semuanya berpusat pada capaian yang terlihat di permukaan, orang seperti itu mudah menjadi target perampingan, dan saya pernah mengalaminya langsung
Team player, mentor, dan arsitek perangkat lunak makin tersisih, sementara coder yang menumpahkan banyak kode mengambil tempat
Meski kemampuan mengirim fitur dan memelihara sistem menurun dari waktu ke waktu karena technical debt, manajer menyukai developer yang secara konsisten menulis lebih dari 5.000 baris per minggu, terlepas dari jumlah fitur yang benar-benar dirilis atau bug
Sebagai team lead sekaligus engineer yang pernah mengelola proyek kompleks, orang yang menulis lebih dari 2.000 baris kode per minggu terasa menakutkan
Itu berarti lebih dari 100.000 baris kode dalam setahun, dan kita harus memikirkan kompleksitas yang tidak perlu
Kemungkinan besar fitur yang sama bisa diimplementasikan dalam 10.000 baris, dengan bug lebih sedikit dan dalam separuh waktu, tetapi itu hanya 380 baris per minggu sehingga manajer tidak akan menyukainya
Saya cenderung melihat developer yang menghasilkan ribuan baris tidak memikirkan arah jangka panjang proyek dengan cukup mendalam, dan sebagian besar kode itu terasa mendekati kode yang akan dibuang
Google sampai batas tertentu melembagakan ini sebagai peran Tech Lead, dan engineer ini diharapkan bertindak sebagai mentor dan orang yang menggandakan kekuatan, bukan sekadar individual contributor
Tidak selalu berjalan sesuai desain, mungkin malah jarang, dan TL bisa terjebak dalam koordinasi orang, perencanaan, serta perdebatan kecil sampai tidak bisa bekerja sebagai engineer
Meski begitu, maksud dari peran itu cukup baik
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
Gagasan untuk mengukur segala sesuatu dan bertindak berdasarkan angka yang bisa diperoleh sudah ada sejak abad ke-19
Para manajer mengulangi praktik yang sama sejak saat itu, dan hasilnya pun cukup stabil dengan cara yang sama
Pemilik sebuah perusahaan tempat saya sempat bekerja ingin menulis ulang layanan web dari nol setiap 6 bulan demi mengikuti framework web terbaru dan tren
Pahlawan 5.000 baris per minggu pasti akan langsung ia rekrut di tempat
Dalam proyek maintenance, ada kalanya saya melewati satu minggu tanpa menulis satu baris pun sendiri, dan malah menghabiskan seminggu penuh untuk mengurangi jumlah baris kode
Luar biasa
Dalam olahraga dayung ada latihan yang disebut seat racing, yaitu memasukkan dan mengeluarkan orang dari berbagai kombinasi delapan kursi untuk mencari kombinasi tercepat
Kekuatan individu juga menjadi metrik, tetapi siapa yang naik ke perahu lomba ditentukan oleh kecepatan tim
Pada akhirnya, kombinasi tercepat jarang sekali berisi delapan orang terkuat begitu saja, dan sering kali ada satu atau dua orang “ajaib” yang membuat perahu mana pun menjadi lebih cepat meski di atas kertas mereka tidak tampak lebih unggul
Mereka secara halus meningkatkan keseimbangan, ritme, dan tenaga orang lain
Sebagian pelatih tidak mau menerimanya dan menolak, sehingga akhirnya jumlah kemenangan berkurang
Ini sangat mirip dengan tim software, dan pada akhirnya yang penting adalah kombinasi dan hasil
Saat diminta melatih “kepemimpinan teknis”, saya selalu mengatakan agar memperhatikan dengan saksama karyawan tipe fasilitator
Bantuan mereka membuat karyawan lain lebih produktif dan efektif, dan sebagian orang mendapatkan kepuasan kerja yang lebih besar dari membantu orang lain bekerja dengan hebat daripada melakukan hal luar biasa sendiri lalu mengambil semua kredit
Orang-orang seperti ini sering mendapat skor rendah, tetapi jika mereka hilang, produktivitas tim turun secara bersih
Jadi saya mencoba memberi alat untuk membedakan antara orang yang memang tidak produktif dan orang yang produktivitasnya tampak melalui keberhasilan orang lain
Mengukur hanya satu metrik lalu mengelola berdasarkan itu sama sekali bukan ide bagus
Karena orang yang mempermainkan metrik akan “menang”, dan perilaku seperti itu berujung pada promosi
Saya juga menyampaikan hal ini kepada pimpinan Google, tetapi Laszlo berkata, “Inilah sistem yang kami punya, dan memang tidak sempurna, tetapi kami akan jalan dengan ini. Mau bekerja di dalamnya atau tidak, itu pilihan Anda”
Dari rapat itu saja sudah cukup jelas apakah pimpinan senior berniat menciptakan lingkungan engineering yang lebih baik atau tidak
Banyak manajer baru, terutama mereka yang sebelumnya adalah engineer kontributor individual, berpikir bahwa jika mempertahankan anggota “terbaik” dan mengeluarkan anggota “buruk”, moral tim dan output akan sama-sama membaik
Namun “terbaik” menurut pemahaman mereka didasarkan pada standar keberhasilan dalam pekerjaan lama mereka sendiri, bukan pada standar mengelola orang
Karena itu mereka cenderung menyukai orang dengan keterampilan dan kebiasaan yang mirip dengan diri mereka, dan memandang rendah orang dengan keterampilan dan kebiasaan yang berbeda
Momen ketika mereka menyadari hal ini dan mata mereka membelalak selalu menarik
Kebijakan suku bunga nol telah memperbanyak peran seperti direktur senior yang mengelola papan Jira dan daftar tugas, sementara orang yang mampu melakukan pekerjaan nyata justru kurang
Saya tidak menentang gagasan bahwa mungkin ada orang yang memfasilitasi produktivitas orang lain, tetapi pada akhirnya agar sesuatu selesai, “orang lain” itu tetap dibutuhkan
Jika tidak, organisasi akan mengalami nekrosis