Punya beberapa pengalaman soal “kode buruk”. Saya sering bekerja sendirian, tetapi di tim saya juga pernah menulis kode yang sekadar berjalan namun tidak optimal. Saat mencoba merefaktor kode lama sambil mengerjakan tugas baru, saya sering ditolak, dan refaktor atau perbaikan yang diperlukan biasanya tetap jadi tiket lalu prioritasnya diturunkan atau diabaikan
Kalau sendirian, saya bisa menaruh pekerjaan yang perlu diutamakan ke prioritas teratas, tetapi di tim, keputusan kelas dua bisa bertahan selamanya atau dibiarkan sampai momen “sistem down”. Setelah itu, saat postmortem, kalau saya menunjuk tiket yang beberapa bulan sebelumnya meminta agar bom waktu itu diperbaiki, hal itu dianggap sebagai “menyalahkan” atau “bersikap agresif”, dan akhirnya solusinya jadi seolah-olah jangan pernah menulis kode kelas dua sama sekali, sehingga frustrasi dan kecemasan saat ngoding makin besar
Pada 2017 saya juga pernah dihubungi untuk memperbaiki kode yang saya tulis pada 2003/2004, dan kode itu ternyata masih dipakai di produksi. Melihat kembali kode yang rusak dan bagian-bagian yang dulu saya kompromikan, lalu sadar bahwa orang yang bertanggung jawab adalah saya sendiri, adalah pengalaman yang cukup merendahkan hati, dan sejak itu sudut pandang saya tentang kode yang mudah dipelihara dan dokumentasi berubah drastis
Tergantung tim dan perusahaannya. Saya sering mengalami tim tempat developer didorong untuk meluangkan waktu bagi maintenance kode dan refaktor, kadang bahkan diwajibkan hanya mengerjakan itu, pekerjaan yang berpusat pada engineering diprioritaskan di atas permintaan produk acak, dan jadwal juga disesuaikan agar pekerjaan bisa diselesaikan dengan benar
Pengalaman seperti ini umum saya temui, mulai dari perusahaan besar S&P 500, perusahaan bernilai 100 juta hingga 1 miliar dolar, sampai startup. Dalam kasus-kasus seperti ini, ada software engineer dan manajer berpengalaman yang mampu membuat kompromi yang masuk akal sambil tetap memenuhi kebutuhan bisnis, dan engineer juga sering berinteraksi langsung dengan pelanggan
Kuncinya adalah keseimbangan, dan keseimbangan itu biasanya tercipta lewat orang-orang yang mampu menilai dengan seimbang. Jika hanya mengejar “kesempurnaan”, hasilnya refaktor tanpa akhir dan produk tak pernah rilis, sedangkan jika utang teknis atau kualitas sampah diabaikan, bisnis bisa runtuh seiring waktu. Titik yang tepat berbeda-beda tergantung produk, industri, pelanggan, dan bisnisnya
Entah mati sebagai pahlawan, atau hidup cukup lama sampai melihat nama sendiri di git blame berusia 10 tahun
“Berjalan tapi tidak optimal” sering kali merupakan kompromi yang bisa diterima saat waktu sempit dan pekerjaan menumpuk. Slogan ala MBA seperti “perfect is the enemy of good” juga merupakan ungkapan yang bisa dipakai ketika ada sesuatu yang kurang
Dipanggil pada 2017 untuk memperbaiki kode yang ditulis pada 2003/2004 juga berarti kita semua adalah penjelajah waktu. Saya murah hati kepada diri saya di masa lalu, dan agak tidak sopan kepada diri saya di masa depan
Diri saya di masa lalu masih muda dan naif, tetapi produktif, dan sudah mendaki banyak gunung. Butuh dua hari untuk memahami kodenya, tetapi pada akhirnya ternyata cukup cerdas, dan bisa jadi diri saya yang sekarang lupa semuanya hanya karena ingatan yang buruk
Diri saya di masa depan akan memperbaiki semua yang salah. Ia lebih tua dan lebih bijak, akan mengganti XXX dan TBD dengan kode yang pintar, akan mewujudkan ide-ide bagus, dan percaya punya waktu tak terbatas untuk mengerjakan ulang ide-ide yang biasa saja. Kalau ada komentar yang lebih baik, mungkin ketiganya bisa menjadi satu
Saya rasa sikap merasa diri sebagai “satu orang pilihan” yang benar ini berbahaya. Sangat melegakan dan sehat ketika developer senior bisa menceritakan kesalahan yang mereka buat dan hal-hal yang gagal
Itu bukan cuma kesempatan belajar, tetapi juga menunjukkan budaya yang terbuka dan membantu melawan impostor syndrome. Sikap perfeksionis justru kebalikannya, karena seluruh pesannya hanya “berusahalah lebih keras agar tidak salah”, jadi tidak ada yang bisa dipelajari dan yang dituntut hanya lebih banyak usaha pribadi
Setidaknya dua kali, “satu orang pilihan” ini tidak mau mengakui kesalahan besar, menghindarinya bahkan dengan risiko kehilangan pelanggan yang baik, dan saya menduga mereka lalu menjelek-jelekkan orang lain di belakang
Pernah sekali saya menanggung kesalahan kecil seorang junior yang memasukkan versi software yang salah ke dalam laporan; padahal ke pelanggan tinggal bilang “ada kesalahan dan ini laporan yang sudah diperbaiki”, tetapi atasan saya hanya memikirkan “bisakah kita menyembunyikan ini dan menjaga citra bahwa kita sempurna?” Orang yang sama juga menjadikan kesalahan orang lain sebagai kesempatan untuk menuntut diskon, kompensasi, atau layanan gratis
Kebanyakan orang menurut saya hanya menjalani pekerjaannya sambil terus berkembang. Di manajemen konfigurasi kami ada cukup banyak hal buatan saya yang secara fungsional bekerja dengan baik, tetapi setelah 1–2 tahun memakai tool itu, saya jadi menyebut kualitasnya cukup buruk karena berbagai alasan
Dan itu tidak apa-apa. Kalau nanti ada alasan untuk mengubahnya, saya bisa merapikannya, dan sampai saat itu ia tetap menjadi contoh yang menunjukkan praktik buruk dan pendekatan yang lebih baik
Kalau Anda tidak bisa menemukan hal yang layak dikritik dari diri sendiri, artinya Anda tidak sedang berkembang. Jika kritik diri seperti itu dibagikan, orang lain juga bisa belajar dari kesalahan saya, dan tahu bahwa belajar dari kesalahan sendiri itu tidak masalah
Dalam code review saya sering mendengar kalimat seperti “kenapa tidak langsung saja menghindari kesalahan itu” atau “kenapa tidak langsung begini saja”
Sekarang saya biasanya menjawab, “mungkin karena IQ Anda lebih tinggi daripada saya. IQ saya rendah, jadi saya harus melakukan hal-hal yang lebih bodoh dan sederhana.” Kadang itu membuat lawan bicara sadar betapa tanpa refleksi mereka baru saja bersikap merendahkan seperti kutu buku kecil yang menyebalkan, lalu wajah mereka memerah
Saya agak alergi terhadap pertanyaan yang dimulai dengan “kenapa tidak langsung …?”. Hanya dengan mendengar tiga kata itu saja, biasanya saya sudah bisa menebak usulan yang akan datang berikutnya, bukan karena itu sangat rumit, tetapi karena biasanya itu adalah cara paling jelas yang pertama terlintas, dan kemungkinan besar sudah dipertimbangkan atau dicoba dengan hati-hati
Pertanyaannya sendiri bukan hal buruk, tetapi asumsi “ide saya ini terlalu mudah” dan “Anda tidak kepikiran hal yang jelas dan mudah ini” terasa menjengkelkan atau menghina. Sebaliknya, ketika saya bertanya ke orang lain, saya berusaha menghindari “kenapa tidak langsung”, dan lebih baik bertanya seperti “bolehkah saya memahami bahwa ada alasan tertentu mengapa X tidak dilakukan?” atau cukup bertanya alasannya dengan ramah
Jika pertanyaan itu muncul karena kurang konteks, sebelum menjelaskan apa yang saya lakukan, saya bisa lebih dulu menjelaskan kenapa pendekatan paling jelas tidak berhasil, atau apa saja requirement rumit dan input bermasalahnya, agar pertanyaan seperti itu bisa dicegah. Jika kodenya sudah terlanjur di-commit, tujuannya adalah mengurangi komentar susulan lewat catatan pada commit atau merge request. Kadang juga berguna untuk tidak membantah, lalu langsung menjelaskan bahwa saya sudah mencoba cara itu tetapi kenapa tidak berhasil, dan dengan tulus bertanya apakah mereka punya ide lain
Kalau ternyata itu benar-benar usulan yang belum saya pikirkan dan sepertinya bisa menyelesaikan masalah, saya bilang itu ide bagus dan meminta bantuan untuk mengimplementasikannya. Pada saat seperti itu memang ada godaan untuk melawan asumsi atau nada bicaranya, tetapi saya berusaha memilih untuk menerimanya saja dan merasa malu sebentar
Ini contoh penerapan grug brain yang sangat tepat https://grugbrain.dev/
“Jika harus memilih antara kompleksitas dan bertarung satu lawan satu dengan tyrannosaurus, grug akan memilih tyrannosaurus. Setidaknya grug bisa melihat tyrannosaurus”
Kalau bukan bercanda, pertanyaan pertama itu tidak membantu dan nyaris merupakan tindakan yang jahat. Semua orang sesekali membuat kesalahan
Pertanyaan kedua biasanya bisa menjadi umpan balik yang cukup bagus. Keterampilan dan pengetahuan orang tidak selalu tumpang tindih. Sesuatu yang sangat rumit bagi A belum tentu rumit bagi B, dan sebaliknya, dan itu juga tidak selalu berarti salah satunya lebih pintar. A mungkin tidak tahu SQL dan B mungkin tidak tahu pandas
Jika kita sudah mengasumsikan stack teknologinya memang mencakup SQL dan pandas, kadang masuk akal untuk memindahkan sebagian kode dari SQL ke pandas atau sebaliknya. Ada orang yang lebih mudah dengan gaya berorientasi objek, ada juga yang lebih mudah dengan gaya fungsional. Mana yang lebih masuk akal tidak selalu jelas, jadi pertanyaannya bisa jadi pertanyaan yang bagus. Jika usulannya buruk, jelaskan kenapa buruk; jika bagus, pertimbangkan apakah layak dikerjakan sekarang. Jika posisinya di tengah atau tidak ada waktu, akui saja lalu lanjut
Alternatif lain adalah sekadar setuju dengan jelas. Anda bisa menjawab, “Iya, itu memang bodoh ya?” atau “Iya, mungkin memang seharusnya tidak begitu”, atau “Akan saya pikirkan”
Dengan begitu lawan bicara lebih sulit membuat saya malu atau merasa bersalah hanya karena saya melakukan pilihan terbaik kedua. Saya melihat tujuan ucapan seperti ini sering kali adalah membangun posisi unggul lewat rasa malu. Memilih untuk tidak ikut permainan itu, dan biasanya justru itulah langkah yang menang
Jika itu diucapkan karena ketidaktahuan, tidak perlu menganggapnya sebagai serangan lalu membuat lawan malu agar mereka membayar harganya
Saya tidak bisa menemukan blog atau tulisan yang dulu pernah saya baca, tetapi pesannya adalah “kalau melihat sesuatu yang tidak optimal dalam kode, jangan langsung berasumsi tidak kompeten”. Orang yang menulis kode itu mungkin punya tenggat yang mepet, prioritas lain, atau faktor lain yang membuat mereka tidak bisa langsung melakukan “hal yang benar” saat itu
Bahkan jika kodenya sempurna saat ditulis, pertumbuhan codebase dan perubahan kebutuhan bisa membuatnya menjadi buruk
Misalnya, jika item yang akan disimpan hanya 10, file sederhana mungkin pilihan yang praktis, tetapi jika jumlahnya menjadi 10.000, mungkin dibutuhkan database. Namun kalau sejak awal memakai database untuk 10 item, orang juga akan mengeluh itu overengineering
Jika kelasnya hanya 2, if/else mungkin cukup, tetapi jika menjadi 20, mungkin dibutuhkan pola Factory, dan kalau itu dilakukan sejak awal, akan terlihat seperti arsitektur yang kelewat muluk. Kalau mencoba memprediksi pertumbuhan seperti ini lalu salah, hasilnya justru kode yang rumit. Proyek yang terus dikembangkan secara sistematis akan tumbuh melampaui dirinya sendiri
Ada juga Chesterton's Fence. Sesuatu yang tampak bodoh di dalam kode mungkin dulu benar-benar penting. Lebih buruk lagi, bisa jadi itu masih penting untuk kasus tepi yang jarang terjadi, hanya saja kita belum melihat alasannya
Saya pernah beberapa kali menerima komentar jahat tentang tulisan blog, baik di sini maupun di reddit. Saat itu, tanpa memberi penilaian, saya menambahkan tautan ke komentar jahat itu di tulisan sebagai cara menyorotinya. Biasanya tidak terjadi apa-apa, tetapi kadang itu mengarahkan diskusi kembali ke arah yang lebih sehat
Saya juga menerima cukup banyak. Sebagian mungkin memang pantas, tetapi kemungkinan besar kebanyakan tidak. Beberapa ada benarnya sampai taraf tertentu, tetapi tidak membantu atau malah merugikan komunitas secara langsung. Mengatakan hal yang benar dengan cara yang salah tetap saja berarti mengatakan hal yang salah
Memberi tautan ke komentar jahat tanpa menghakimi bukan ide yang buruk. Kalau komentarnya sudah ditandai mati, itu tidak selalu memungkinkan, tetapi saya tetap tidak membalas dengan cara yang sama. Saya juga bisa melakukannya, tetapi saya sudah belajar bahwa bensin bukan alat pemadam kebakaran yang efektif
Jika saya salah, saya berusaha mengakuinya secepat mungkin di tempat yang sama dengan tempat kesalahan itu terjadi. Saya sangat tidak suka permintaan maaf pribadi setelah serangan publik
Tetap ada batasnya. Saya merasa saya melakukan pekerjaan yang cukup baik, sudah melakukannya selama sekitar 40 tahun, dan banyak belajar selama waktu itu. Saya juga pernah bekerja di lingkungan yang menuntut dan tidak menerima pekerjaan bermutu rendah, jadi saya terbiasa menghasilkan pekerjaan yang cukup baik
Secara umum saya menghindari menghakimi orang lain di depan umum. Itu tidak membantu, dan saya juga tidak selalu benar. Namun jika saya harus bekerja bersama mereka atau menggunakan hasil kerja mereka, itu bisa berbeda. Saya pernah diserang dengan kasar hanya karena saya tidak menerima sampah, tetapi saya tidak bertingkah seperti Linus Torvalds. Jika memungkinkan, saya akan mengatakan dengan hormat bahwa pekerjaan itu tidak bisa saya terima
Meski begitu, kita selalu bisa membaik dan belajar hal baru, dan kadang kita belajar dari tempat yang sama sekali tidak terduga. Terbuka pada pembelajaran seperti itu pada dasarnya adalah kebijakan yang baik. Saya salah, lalu menjadi benar dengan belajar. “Penilaian yang baik datang dari pengalaman, dan pengalaman datang dari penilaian yang buruk”
Salah satu podcast favorit saya, well there's your problem di YouTube, hampir selalu menyematkan komentar yang mengeluhkan podcast itu. Biasanya keluhannya berada di level “saya tidak suka podcast ini, jadi podcast ini harus menjadi podcast lain”, dan komentar yang disematkan hampir selalu merupakan tafsiran paling bodoh yang mungkin untuk episode tersebut
Saya tidak tahu apakah itu efektif mengurangi komentar seperti itu, tetapi setidaknya itu memberi orang yang ikut serta dalam wacana dengan cara seperti itu topi bodoh secara metaforis
Saya setuju bahwa ada sikap buruk pada sebagian engineer. Siapa pun bisa menulis kode yang buruk, dan ada benarnya juga logika bahwa semua kode itu buruk dan merupakan utang
Tulisan ini menarik dibaca bersama “No more pink mustache”. Dalam tulisan itu, Lyft digambarkan “rusak pada skala yang sulit dipercaya”, dan penyebab kualitas sering kali bukan orang yang duduk di kursinya melainkan organisasinya :-)
[1] https://rachelbythebay.com/w/2020/02/29/poof/
Saya membaca tulisan ini pada 2018 dan senang melihatnya muncul lagi. Ini salah satu tulisan yang membuat saya banyak bertanya. Jika absolutisme atau sikap ekstrem tidak bisa dihilangkan, saya jadi berpikir filter seperti apa yang bisa dibuat saat menghadapi percakapan atau orang seperti ini. Saya punya model sendiri, tetapi saya penasaran strategi apa yang dipakai orang lain
Orang-orang seperti ini berusaha menguasai wilayah emosional yang bukan milik mereka. Biasanya mereka sudah menghitung sebelumnya bahwa mereka “boleh” melakukan itu, dan itu berarti mereka menganggap lawannya lemah
Ada tiga pilihan. Menyerah dan membiarkan wilayah itu diambil lalu lanjut menjalani hidup, karena makin sedikit tidur terganggu oleh ketidakadilan makin baik. Menghadapinya secara langsung; mereka siap berkelahi, tetapi posisi mereka sendiri pada dasarnya tidak rasional, jadi semakin sedikit kita terseret ke ruang pikir mereka, semakin besar kemungkinan untuk “menang”. Mengambil posisi dari atas; yaitu membawa bukti sosial bahwa mereka salah ke dalam ruang mereka. Dalam kasus tulisan asli, contohnya adalah programmer produktif yang saling menghormati pekerjaan satu sama lain dan tidak suka mencari-cari kesalahan
Saat seseorang memberi saran seperti “kalau dilakukan begini mungkin hasilnya lebih baik”, itu tidak selalu merupakan serangan terhadap saya atau penghinaan terhadap kemampuan saya
Orang yang memberi nasihat bisa saja orang bodoh yang canggung dalam hubungan sosial, atau sekadar benar-benar bodoh. Tidak apa-apa jika sebagian dunia tidak setuju dengan saya. Hanya karena orang menyampaikan pendapat yang berlawanan atau tidak setuju bukan berarti mereka mengancam saya
Tulisan yang aneh. Terdengar seperti tweet, isinya sedikit, dan judulnya tidak mencerminkan isi sehingga terlihat seperti clickbait
Saya tidak menentang inti pesannya, tetapi ada sisi lain juga. Kemampuan untuk menerima umpan balik juga diperlukan
Kebanyakan orang bisa menerima dan menerapkan umpan balik. Hanya saja, ada sebagian orang yang memberi umpan balik dengan sangat buruk lalu menganggap lawan bicaranya tidak bisa menerima umpan balik
Orang-orang seperti ini menganggap cara umpan balik yang mereka sukai adalah yang terbaik, semua orang harus merasakan hal yang sama, dan jika tidak, maka pihak lainlah yang harus berubah. Tentu saja itu salah. Tetapi jika hal ini diberitahukan kepada mereka, mereka sendiri menunjukkan mengapa saya mengatakan “kebanyakan” pada kalimat pertama
1 komentar
Komentar Hacker News
Kalau sendirian, saya bisa menaruh pekerjaan yang perlu diutamakan ke prioritas teratas, tetapi di tim, keputusan kelas dua bisa bertahan selamanya atau dibiarkan sampai momen “sistem down”. Setelah itu, saat postmortem, kalau saya menunjuk tiket yang beberapa bulan sebelumnya meminta agar bom waktu itu diperbaiki, hal itu dianggap sebagai “menyalahkan” atau “bersikap agresif”, dan akhirnya solusinya jadi seolah-olah jangan pernah menulis kode kelas dua sama sekali, sehingga frustrasi dan kecemasan saat ngoding makin besar
Pada 2017 saya juga pernah dihubungi untuk memperbaiki kode yang saya tulis pada 2003/2004, dan kode itu ternyata masih dipakai di produksi. Melihat kembali kode yang rusak dan bagian-bagian yang dulu saya kompromikan, lalu sadar bahwa orang yang bertanggung jawab adalah saya sendiri, adalah pengalaman yang cukup merendahkan hati, dan sejak itu sudut pandang saya tentang kode yang mudah dipelihara dan dokumentasi berubah drastis
Pengalaman seperti ini umum saya temui, mulai dari perusahaan besar S&P 500, perusahaan bernilai 100 juta hingga 1 miliar dolar, sampai startup. Dalam kasus-kasus seperti ini, ada software engineer dan manajer berpengalaman yang mampu membuat kompromi yang masuk akal sambil tetap memenuhi kebutuhan bisnis, dan engineer juga sering berinteraksi langsung dengan pelanggan
Kuncinya adalah keseimbangan, dan keseimbangan itu biasanya tercipta lewat orang-orang yang mampu menilai dengan seimbang. Jika hanya mengejar “kesempurnaan”, hasilnya refaktor tanpa akhir dan produk tak pernah rilis, sedangkan jika utang teknis atau kualitas sampah diabaikan, bisnis bisa runtuh seiring waktu. Titik yang tepat berbeda-beda tergantung produk, industri, pelanggan, dan bisnisnya
Diri saya di masa lalu masih muda dan naif, tetapi produktif, dan sudah mendaki banyak gunung. Butuh dua hari untuk memahami kodenya, tetapi pada akhirnya ternyata cukup cerdas, dan bisa jadi diri saya yang sekarang lupa semuanya hanya karena ingatan yang buruk
Diri saya di masa depan akan memperbaiki semua yang salah. Ia lebih tua dan lebih bijak, akan mengganti XXX dan TBD dengan kode yang pintar, akan mewujudkan ide-ide bagus, dan percaya punya waktu tak terbatas untuk mengerjakan ulang ide-ide yang biasa saja. Kalau ada komentar yang lebih baik, mungkin ketiganya bisa menjadi satu
Itu bukan cuma kesempatan belajar, tetapi juga menunjukkan budaya yang terbuka dan membantu melawan impostor syndrome. Sikap perfeksionis justru kebalikannya, karena seluruh pesannya hanya “berusahalah lebih keras agar tidak salah”, jadi tidak ada yang bisa dipelajari dan yang dituntut hanya lebih banyak usaha pribadi
Pernah sekali saya menanggung kesalahan kecil seorang junior yang memasukkan versi software yang salah ke dalam laporan; padahal ke pelanggan tinggal bilang “ada kesalahan dan ini laporan yang sudah diperbaiki”, tetapi atasan saya hanya memikirkan “bisakah kita menyembunyikan ini dan menjaga citra bahwa kita sempurna?” Orang yang sama juga menjadikan kesalahan orang lain sebagai kesempatan untuk menuntut diskon, kompensasi, atau layanan gratis
Dan itu tidak apa-apa. Kalau nanti ada alasan untuk mengubahnya, saya bisa merapikannya, dan sampai saat itu ia tetap menjadi contoh yang menunjukkan praktik buruk dan pendekatan yang lebih baik
Sekarang saya biasanya menjawab, “mungkin karena IQ Anda lebih tinggi daripada saya. IQ saya rendah, jadi saya harus melakukan hal-hal yang lebih bodoh dan sederhana.” Kadang itu membuat lawan bicara sadar betapa tanpa refleksi mereka baru saja bersikap merendahkan seperti kutu buku kecil yang menyebalkan, lalu wajah mereka memerah
Pertanyaannya sendiri bukan hal buruk, tetapi asumsi “ide saya ini terlalu mudah” dan “Anda tidak kepikiran hal yang jelas dan mudah ini” terasa menjengkelkan atau menghina. Sebaliknya, ketika saya bertanya ke orang lain, saya berusaha menghindari “kenapa tidak langsung”, dan lebih baik bertanya seperti “bolehkah saya memahami bahwa ada alasan tertentu mengapa X tidak dilakukan?” atau cukup bertanya alasannya dengan ramah
Jika pertanyaan itu muncul karena kurang konteks, sebelum menjelaskan apa yang saya lakukan, saya bisa lebih dulu menjelaskan kenapa pendekatan paling jelas tidak berhasil, atau apa saja requirement rumit dan input bermasalahnya, agar pertanyaan seperti itu bisa dicegah. Jika kodenya sudah terlanjur di-commit, tujuannya adalah mengurangi komentar susulan lewat catatan pada commit atau merge request. Kadang juga berguna untuk tidak membantah, lalu langsung menjelaskan bahwa saya sudah mencoba cara itu tetapi kenapa tidak berhasil, dan dengan tulus bertanya apakah mereka punya ide lain
Kalau ternyata itu benar-benar usulan yang belum saya pikirkan dan sepertinya bisa menyelesaikan masalah, saya bilang itu ide bagus dan meminta bantuan untuk mengimplementasikannya. Pada saat seperti itu memang ada godaan untuk melawan asumsi atau nada bicaranya, tetapi saya berusaha memilih untuk menerimanya saja dan merasa malu sebentar
“Jika harus memilih antara kompleksitas dan bertarung satu lawan satu dengan tyrannosaurus, grug akan memilih tyrannosaurus. Setidaknya grug bisa melihat tyrannosaurus”
Pertanyaan kedua biasanya bisa menjadi umpan balik yang cukup bagus. Keterampilan dan pengetahuan orang tidak selalu tumpang tindih. Sesuatu yang sangat rumit bagi A belum tentu rumit bagi B, dan sebaliknya, dan itu juga tidak selalu berarti salah satunya lebih pintar. A mungkin tidak tahu SQL dan B mungkin tidak tahu pandas
Jika kita sudah mengasumsikan stack teknologinya memang mencakup SQL dan pandas, kadang masuk akal untuk memindahkan sebagian kode dari SQL ke pandas atau sebaliknya. Ada orang yang lebih mudah dengan gaya berorientasi objek, ada juga yang lebih mudah dengan gaya fungsional. Mana yang lebih masuk akal tidak selalu jelas, jadi pertanyaannya bisa jadi pertanyaan yang bagus. Jika usulannya buruk, jelaskan kenapa buruk; jika bagus, pertimbangkan apakah layak dikerjakan sekarang. Jika posisinya di tengah atau tidak ada waktu, akui saja lalu lanjut
Dengan begitu lawan bicara lebih sulit membuat saya malu atau merasa bersalah hanya karena saya melakukan pilihan terbaik kedua. Saya melihat tujuan ucapan seperti ini sering kali adalah membangun posisi unggul lewat rasa malu. Memilih untuk tidak ikut permainan itu, dan biasanya justru itulah langkah yang menang
Misalnya, jika item yang akan disimpan hanya 10, file sederhana mungkin pilihan yang praktis, tetapi jika jumlahnya menjadi 10.000, mungkin dibutuhkan database. Namun kalau sejak awal memakai database untuk 10 item, orang juga akan mengeluh itu overengineering
Jika kelasnya hanya 2, if/else mungkin cukup, tetapi jika menjadi 20, mungkin dibutuhkan pola Factory, dan kalau itu dilakukan sejak awal, akan terlihat seperti arsitektur yang kelewat muluk. Kalau mencoba memprediksi pertumbuhan seperti ini lalu salah, hasilnya justru kode yang rumit. Proyek yang terus dikembangkan secara sistematis akan tumbuh melampaui dirinya sendiri
Memberi tautan ke komentar jahat tanpa menghakimi bukan ide yang buruk. Kalau komentarnya sudah ditandai mati, itu tidak selalu memungkinkan, tetapi saya tetap tidak membalas dengan cara yang sama. Saya juga bisa melakukannya, tetapi saya sudah belajar bahwa bensin bukan alat pemadam kebakaran yang efektif
Jika saya salah, saya berusaha mengakuinya secepat mungkin di tempat yang sama dengan tempat kesalahan itu terjadi. Saya sangat tidak suka permintaan maaf pribadi setelah serangan publik
Tetap ada batasnya. Saya merasa saya melakukan pekerjaan yang cukup baik, sudah melakukannya selama sekitar 40 tahun, dan banyak belajar selama waktu itu. Saya juga pernah bekerja di lingkungan yang menuntut dan tidak menerima pekerjaan bermutu rendah, jadi saya terbiasa menghasilkan pekerjaan yang cukup baik
Secara umum saya menghindari menghakimi orang lain di depan umum. Itu tidak membantu, dan saya juga tidak selalu benar. Namun jika saya harus bekerja bersama mereka atau menggunakan hasil kerja mereka, itu bisa berbeda. Saya pernah diserang dengan kasar hanya karena saya tidak menerima sampah, tetapi saya tidak bertingkah seperti Linus Torvalds. Jika memungkinkan, saya akan mengatakan dengan hormat bahwa pekerjaan itu tidak bisa saya terima
Meski begitu, kita selalu bisa membaik dan belajar hal baru, dan kadang kita belajar dari tempat yang sama sekali tidak terduga. Terbuka pada pembelajaran seperti itu pada dasarnya adalah kebijakan yang baik. Saya salah, lalu menjadi benar dengan belajar. “Penilaian yang baik datang dari pengalaman, dan pengalaman datang dari penilaian yang buruk”
Saya tidak tahu apakah itu efektif mengurangi komentar seperti itu, tetapi setidaknya itu memberi orang yang ikut serta dalam wacana dengan cara seperti itu topi bodoh secara metaforis
Tulisan ini menarik dibaca bersama “No more pink mustache”. Dalam tulisan itu, Lyft digambarkan “rusak pada skala yang sulit dipercaya”, dan penyebab kualitas sering kali bukan orang yang duduk di kursinya melainkan organisasinya :-)
[1] https://rachelbythebay.com/w/2020/02/29/poof/
Ada tiga pilihan. Menyerah dan membiarkan wilayah itu diambil lalu lanjut menjalani hidup, karena makin sedikit tidur terganggu oleh ketidakadilan makin baik. Menghadapinya secara langsung; mereka siap berkelahi, tetapi posisi mereka sendiri pada dasarnya tidak rasional, jadi semakin sedikit kita terseret ke ruang pikir mereka, semakin besar kemungkinan untuk “menang”. Mengambil posisi dari atas; yaitu membawa bukti sosial bahwa mereka salah ke dalam ruang mereka. Dalam kasus tulisan asli, contohnya adalah programmer produktif yang saling menghormati pekerjaan satu sama lain dan tidak suka mencari-cari kesalahan
Orang yang memberi nasihat bisa saja orang bodoh yang canggung dalam hubungan sosial, atau sekadar benar-benar bodoh. Tidak apa-apa jika sebagian dunia tidak setuju dengan saya. Hanya karena orang menyampaikan pendapat yang berlawanan atau tidak setuju bukan berarti mereka mengancam saya
Orang-orang seperti ini menganggap cara umpan balik yang mereka sukai adalah yang terbaik, semua orang harus merasakan hal yang sama, dan jika tidak, maka pihak lainlah yang harus berubah. Tentu saja itu salah. Tetapi jika hal ini diberitahukan kepada mereka, mereka sendiri menunjukkan mengapa saya mengatakan “kebanyakan” pada kalimat pertama