Kemarahan atas kode: programmer dan negativitas

Saya melihat sepotong kode. Mungkin ini adalah kode terburuk yang pernah saya temui. Untuk memperbarui hanya satu catatan dalam database, itu mengekstrak semua catatan dalam koleksi, dan kemudian mengirim permintaan untuk memperbarui setiap catatan dalam database, bahkan mereka yang tidak perlu diperbarui. Ada fungsi peta yang hanya mengembalikan nilai yang diteruskan ke sana. Ada pemeriksaan bersyarat variabel dengan nilai yang jelas sama, hanya dinamai dalam gaya yang berbeda ( firstName dan first_name ). Untuk setiap UPDATE, kode mengirimkan pesan ke antrian lain, yang diproses oleh fungsi serverless lain, tetapi yang melakukan semua pekerjaan untuk koleksi lain dalam database yang sama. Saya tidak menyebutkan bahwa fungsi tanpa server ini berasal dari "arsitektur berorientasi layanan" berbasis cloud yang berisi lebih dari 100 fungsi di lingkungan?

Bagaimana hal seperti itu bisa dilakukan? Saya menutupi wajah saya dan menangis tersedu-sedu. Rekan-rekan saya bertanya apa yang terjadi, dan saya menceritakan kembali tentang Hits Terburuk Dari BulkDataImporter.js 2018 . Semua orang mengangguk simpatik kepada saya dan setuju: bagaimana mereka bisa melakukan ini kepada kita?

Negatif: alat emosional dalam budaya programmer

Negativitas memainkan peran penting dalam pemrograman. Itu dibangun ke dalam budaya kita dan digunakan untuk membagikan apa yang diakui ("Anda tidak akan percaya seperti apa kode ini!"), Untuk mengekspresikan simpati melalui kesal ("Tuhan, mengapa melakukan ini?") dalam terang ("Saya tidak akan pernah melakukan itu"), untuk menyalahkan orang lain ("kami memamerkan karena kode-nya, yang tidak mungkin untuk menemani"), atau, seperti kebiasaan dalam organisasi yang paling "beracun", untuk mengelola orang lain melalui rasa malu ("Apa yang kamu pikirkan? Benar").



Negativitas sangat penting bagi programmer karena ini adalah cara yang sangat efektif untuk menyampaikan nilai. Saya dulu belajar di kamp programmer, dan praktik standar vaksinasi siswa dengan budaya serikat adalah dengan murah hati memasok meme, cerita, dan video, yang paling populer mengeksploitasi kekecewaan programmer ketika mereka bingung oleh orang-orang . Adalah baik ketika Anda dapat menggunakan alat emosional untuk menunjukkan yang Baik, Buruk, Mengerikan, Jangan Lakukan Ini, Tidak pernah sama sekali. Penting untuk mempersiapkan pemula untuk fakta bahwa kolega mereka, jauh dari IT, mungkin akan mengerti mereka secara keliru. Bahwa teman-teman mereka akan mulai mendorong mereka ide-ide aplikasi "dalam sejuta." Apa yang harus mereka keluarkan di labirin kode usang yang tidak ada habisnya dengan sekelompok minotaur di sudut.

Ketika kita mulai belajar pemrograman untuk pertama kalinya, pemahaman kita tentang kedalaman “pengalaman pemrograman” didasarkan pada pengamatan terhadap reaksi emosional orang lain. Ini terlihat jelas pada posting di subwoofer ProgrammerHumor , di mana banyak programmer baru nongkrong. Banyak tulisan lucu, sampai taraf tertentu, diwarnai dengan nuansa negatif yang berbeda: kekecewaan, pesimisme, kebencian, kesenangan, dan lain-lain. Dan jika ini tidak cukup bagi Anda, baca komentarnya.



Saya perhatikan bahwa, dengan akumulasi pengalaman, programmer menjadi semakin negatif. Para pemula, tidak menyadari kesulitan yang menunggu mereka, mulai dengan antusiasme dan kemauan untuk percaya bahwa alasan dari kesulitan-kesulitan ini hanyalah karena kurangnya pengalaman dan pengetahuan; dan pada akhirnya mereka akan menghadapi keadaan sebenarnya.

Waktu berlalu, mereka memperoleh pengalaman dan mendapatkan kemampuan untuk membedakan kode Baik dari Buruk. Dan ketika momen ini datang, programmer muda kesal karena bekerja dengan kode yang tampaknya buruk. Dan jika mereka bekerja dalam tim (jarak jauh atau secara langsung), mereka sering mengadopsi kebiasaan emosional rekan yang lebih berpengalaman. Seringkali ini mengarah pada peningkatan negatif, karena orang-orang muda sekarang dapat dengan serius berbicara tentang kode dan membaginya menjadi buruk dan baik, dengan demikian menunjukkan bahwa mereka "dalam subjek". Ini semakin memperkuat hal yang negatif: karena kekecewaan mudah untuk bertemu dengan kolega dan menjadi bagian dari kelompok, kritik terhadap Kode Buruk meningkatkan status dan profesionalisme Anda di mata orang lain: orang yang mengungkapkan pendapat negatif sering dianggap lebih cerdas dan kompeten .

Memperkuat yang negatif belum tentu merupakan hal yang buruk. Diskusi pemrograman, antara lain, sangat terfokus pada kualitas kode tertulis. Apa kode itu, sepenuhnya menentukan fungsi yang dimaksudkan (kita membuang peralatan, jaringan, dll.), Jadi penting untuk dapat mengekspresikan pendapat Anda tentang kode ini. Hampir semua diskusi bermuara pada apakah kode ini cukup baik dan mengutuk manifes itu sendiri dari kode buruk dalam ekspresi yang pewarnaan emosionalnya menjadi ciri kualitas kode:

• "Ada banyak inkonsistensi logis dalam modul ini, yang merupakan kandidat yang baik untuk optimalisasi kinerja yang signifikan."
• “Modul ini sangat buruk, kita harus merefosasinya.”
• "Modul ini tidak masuk akal, perlu ditulis ulang."
• "Modul ini payah, perlu ditambal."
• "Ini adalah ram, bukan modul, tidak perlu ditulis sama sekali, apa yang dipikirkan penulis."

Ngomong-ngomong, ini adalah "pelepasan emosional" yang memaksa pengembang untuk memanggil kode "seksi," yang jarang adil - kecuali Anda bekerja di PornHub.

Masalahnya adalah bahwa orang-orang aneh, bermasalah, dipenuhi dengan emosi penciptaan, dan persepsi dan ekspresi emosi mengubah kita: pada awalnya hampir tidak terlihat, tetapi seiring waktu - secara dramatis.

Jalur negatif negatif yang gelisah

Beberapa tahun yang lalu saya adalah pemimpin tim informal dan mewawancarai satu pengembang. Kami benar-benar menyukainya: ia cerdas, mengajukan pertanyaan bagus, secara teknis cerdas dan sangat cocok dengan budaya kami. Saya sangat terkesan dengan kepositifannya dan betapa nampak beraninya dia. Dan saya mempekerjakannya.

Pada waktu itu, saya bekerja di perusahaan selama beberapa tahun dan merasa bahwa budaya yang diadopsi di negara kami tidak terlalu efektif. Kami mencoba meluncurkan produk dua kali, tiga kali, dan beberapa kali sebelum saya tiba, yang menyebabkan biaya besar untuk pengerjaan ulang, di mana kami tidak dapat menunjukkan apa pun kecuali malam panjang, tenggat waktu pendek, dan produk pengerjaan ketik. Dan meskipun saya masih bekerja keras, saya ragu tentang tenggat waktu terakhir yang diberikan kepada kami oleh manajemen. Dan dia mengutuk dengan santai ketika berdiskusi dengan kolega saya beberapa aspek kode.

Jadi tidak ada yang mengejutkan dalam kenyataan - walaupun saya terkejut - bahwa beberapa minggu kemudian pengembang baru yang sama berbicara dengan cara yang sama negatif seperti yang saya lakukan (termasuk bersumpah). Saya menyadari bahwa dia akan bertindak berbeda di perusahaan yang berbeda dengan budaya yang berbeda. Dia hanya menyesuaikan dengan budaya yang saya buat. Rasa bersalah membuatku kewalahan. Karena pengalaman subjektif saya, saya menanamkan pesimisme ke novis, yang saya anggap sama sekali berbeda. Bahkan jika dia benar-benar tidak menyukainya dan hanya berusaha menunjukkan bahwa dia bisa bergabung dengan tim, saya memaksakan sikap menyebalkan saya kepadanya. Dan semua yang telah dikatakan, bahkan sebagai lelucon atau lewat, memiliki cara yang buruk untuk mengubah apa yang orang yakini.

Cara negativitas

Mari kita kembali ke mantan pemrogram pemula kita yang memperoleh sedikit kebijaksanaan dan pengalaman: mereka mengenal industri pemrograman lebih dekat dan memahami bahwa kode buruk ada di mana-mana, itu tidak bisa dihindari. Hal ini ditemukan bahkan di perusahaan paling maju yang berfokus pada kualitas (dan biarkan saya perhatikan: tampaknya modernitas tidak menyelamatkan kita dari kode buruk sama sekali).

Naskah yang bagus Seiring waktu, pengembang mulai memasang fakta bahwa kode yang buruk adalah realitas dari perangkat lunak, dan bahwa pekerjaan mereka adalah untuk memperbaikinya. Dan bagaimana jika kode buruk tidak dapat dihindari, maka tidak ada gunanya membuat suara berisik karenanya. Mereka memulai jalan Zen, fokus pada pemecahan masalah atau tugas yang dihadapi mereka. Mereka belajar bagaimana mengukur secara akurat dan memberikan kualitas perangkat lunak kepada pemilik bisnis, berdasarkan pengalaman mereka selama bertahun-tahun, menulis perkiraan yang dibenarkan dengan sempurna, dan pada akhirnya menerima imbalan yang besar atas nilai luar biasa dan nilai yang tidak berubah untuk bisnis. Mereka melakukan pekerjaan mereka dengan sangat baik sehingga mereka dibayar bonus bonus sebesar $ 10 juta, dan mereka pensiun untuk melakukan apa yang mereka inginkan selama sisa hidup mereka (tolong jangan mengambilnya dengan keyakinan).



Skenario lain adalah jalan kegelapan. Alih-alih menerima kode buruk sebagai tak terhindarkan, pengembang mengambil tanggung jawab untuk mengumumkan semua yang buruk di dunia pemrograman sehingga mereka dapat mengalahkannya. Mereka menolak untuk memperbaiki kode buruk yang ada karena berbagai alasan: "orang harus tahu lebih banyak dan tidak sebodoh itu"; "Itu tidak menyenangkan"; "Ini buruk untuk bisnis"; “Ini membuktikan betapa pintar saya”; "Jika saya tidak memberi tahu Anda betapa buruknya kode ini, seluruh perusahaan akan terjun ke laut," dan seterusnya.

Tentunya tidak memiliki kesempatan untuk mengimplementasikan perubahan yang diinginkan, karena bisnis, sayangnya, harus terus berkembang dan tidak dapat menghabiskan waktu untuk memperhatikan kualitas kode, orang-orang tersebut mendapatkan reputasi sebagai pengadu. Mereka memiliki kompetensi yang tinggi, tetapi diusir ke halaman belakang perusahaan, di mana mereka tidak akan mengganggu banyak orang, tetapi pada saat yang sama mereka akan mendukung operasi sistem kritis. Setelah kehilangan akses ke peluang baru dalam pembangunan, mereka kehilangan keterampilan mereka dan berhenti memenuhi persyaratan industri. Negativitas mereka berubah menjadi kepahitan yang sengit, dan sebagai hasilnya, mereka menghibur ego mereka, berdebat dengan siswa berusia dua puluh tahun tentang jalan yang diikuti oleh teknologi lama yang mereka cintai dan mengapa itu masih segar. Pada akhirnya, mereka pensiun dan hidup dalam usia tua, memaki burung.

Mungkin, kenyataannya adalah suatu tempat di tengah-tengah antara dua ekstrem ini.

Beberapa perusahaan telah sangat sukses dalam menciptakan budaya yang sangat negatif, terisolasi, berkemauan keras (seperti Microsoft sebelum dekade yang hilang ) - sering kali ini adalah perusahaan dengan produk yang sangat cocok dengan pasar dan kebutuhan untuk tumbuh secepat mungkin; atau perusahaan dengan hierarki manajemen dan kontrol (Apple di tahun-tahun terbaik Jobs), di mana setiap orang melakukan apa yang mereka perintahkan. Namun, penelitian bisnis modern (dan akal sehat) menunjukkan bahwa untuk kecerdasan maksimal, yang mengarah pada inovasi perusahaan, dan produktivitas individu yang tinggi, tingkat stres yang rendah diperlukan untuk mempertahankan pemikiran kreatif dan metodis yang berkelanjutan. Dan sangat sulit untuk melakukan pekerjaan kreatif, yang didasarkan pada diskusi jika Anda terus-menerus khawatir tentang apa yang akan dikatakan rekan kerja Anda tentang setiap baris kode Anda.

Negatif adalah rekayasa budaya pop

Saat ini, lebih banyak perhatian diberikan pada sikap para insinyur daripada sebelumnya. Dalam organisasi teknik, aturan " No Ovuk " menjadi semakin populer. Di Twitter, ada lebih banyak lelucon dan cerita tentang orang-orang yang meninggalkan profesi ini karena mereka tidak bisa (tidak mau) terus menerima permusuhan dan permusuhan terhadap orang luar. Bahkan Linus Torvalds baru-baru ini meminta maaf selama bertahun-tahun atas permusuhan dan kritiknya terhadap pengembang Linux lainnya - ini menyebabkan diskusi tentang efektivitas pendekatan ini.

Seseorang masih membela hak Linus untuk menjadi sangat kritis - mereka yang perlu tahu banyak tentang kelebihan dan kekurangan dari "racun negatif". Ya, kebenaran itu sangat penting (bahkan mendasar), tetapi jika kita meringkas alasan mengapa banyak dari kita membiarkan ekspresi opini negatif berubah menjadi “keracunan”, maka alasan ini terlihat paternalistik atau remaja: “mereka layak mendapatkannya karena mereka idiot”, “dia Saya harus yakin bahwa mereka tidak akan mengulanginya, "" jika mereka tidak melakukan itu, dia tidak perlu meneriaki mereka, "dan seterusnya. Contoh bagaimana reaksi emosional pemimpin mempengaruhi komunitas programmer adalah singkatan MINASWAN di komunitas Ruby - “Matz itu bagus jadi kami baik” (Matz [pencipta bahasa] itu baik, jadi kami baik).

Saya perhatikan bahwa banyak pendukung kuat dari pendekatan "bunuh orang bodoh" sering sangat memperhatikan kualitas dan kebenaran kode, mengidentifikasi diri mereka dengan pekerjaan mereka. Sayangnya, mereka sering mengacaukan kekerasan dengan kekakuan. Kerugian dari posisi ini berasal dari manusia yang sederhana, tetapi keinginan yang tidak produktif untuk merasa lebih unggul dari orang lain. Orang yang tenggelam dalam keinginan ini terjebak di jalan kegelapan.



Dunia pemrograman berkembang pesat dan berbatasan dengan batas-batas wadahnya - dunia non-pemrograman (atau ini dunia pemrograman wadah untuk dunia non-pemrograman? Pertanyaan bagus).

Ketika industri kami berkembang dengan kecepatan yang meningkat dan pemrograman menjadi lebih mudah diakses, jarak antara "teknisi" dan "normal" menurun dengan cepat. Dunia pemrograman semakin terekspos ke komunikasi antarpribadi antara orang-orang yang tumbuh dalam budaya "kutu buku" yang terisolasi dari awal boom teknologi, dan merekalah yang akan membentuk dunia pemrograman baru. Dan terlepas dari argumen apa pun mengenai lingkungan sosial atau generasi, efisiensi atas nama kapitalisme akan terwujud dalam budaya perusahaan dan pendekatan untuk merekrut: perusahaan terbaik tidak akan mempekerjakan orang-orang yang tidak dapat berinteraksi dengan orang lain secara netral, belum lagi hubungan yang baik.

Apa yang saya pelajari tentang yang negatif

Jika Anda membiarkan kelebihan negatif mengendalikan pikiran dan komunikasi Anda dengan orang lain, berubah menjadi "toksisitas", maka ini berbahaya bagi tim produk dan mahal untuk bisnis. Saya melihat banyak sekali proyek (dan mendengar tentang hal itu) yang berantakan dan sepenuhnya dikerjakan ulang dengan biaya tinggi, karena salah satu pengembang tepercaya mempertajam teknologi mereka, pengembang lain, atau bahkan satu-satunya file yang dipilih untuk mewakili kualitas seluruh basis kode .

Negatif juga menurunkan moral dan menghancurkan hubungan. Saya tidak akan pernah lupa bagaimana seorang rekan memarahi saya karena meletakkan CSS di file yang salah, ini membuat saya kesal dan mencegah saya mengumpulkan pikiran saya selama beberapa hari. Dan di masa depan saya tidak mungkin membiarkan orang seperti itu dekat dengan salah satu tim saya (namun, siapa tahu, orang berubah).

Akhirnya, kenegatifan secara harfiah membahayakan kesehatan Anda .


Tampak bagi saya bahwa kelas master senyum harus terlihat seperti ini.

Tentu saja, ini bukan argumen yang mendukung kebahagiaan, memasukkan sepuluh miliar smiley ke dalam setiap permintaan tarik atau pergi ke kelas master dengan senyum (tidak, well, jika itu yang Anda inginkan, maka tidak ada pertanyaan). Negativitas adalah bagian yang sangat penting dari pemrograman (dan kehidupan manusia), menandakan kualitas, memungkinkan Anda untuk mengekspresikan perasaan dan belasungkawa kepada orang-saudara. Bukti negatif dari wawasan dan kewajaran, kedalaman masalah. Saya sering melihat bahwa seorang pengembang telah mencapai tingkat yang baru ketika ia mulai menyatakan ketidakpercayaan pada apa yang ia takut dan tidak yakin. Dengan pendapat mereka, orang menunjukkan kehati-hatian dan kepercayaan diri. Seseorang tidak dapat menolak ekspresi negativitas, itu akan dalam gaya Orwellian.

Namun, yang negatif harus ditutup dan diseimbangkan dengan kualitas manusia penting lainnya: empati, kesabaran, pengertian dan humor. Anda selalu dapat memberi tahu seseorang bahwa dia mengacau tanpa berteriak dan memaki. Jangan meremehkan pendekatan ini: jika Anda benar-benar tanpa emosi mereka mengatakan bahwa Anda benar-benar kacau, itu benar-benar menakutkan.

Pada waktu itu, beberapa tahun yang lalu, CEO berbicara kepada saya. Kami membahas situasi proyek saat ini, kemudian dia bertanya bagaimana perasaan saya. Saya menjawab bahwa semuanya baik-baik saja, proyek berjalan, kami perlahan-lahan bekerja, mungkin saya telah melewatkan sesuatu dan perlu ditinjau. Dia mengatakan bahwa dia mendengar saya berbagi pertimbangan yang lebih pesimistis dengan rekan kerja di kantor, dan orang lain juga memperhatikan hal ini. Dia menjelaskan bahwa jika saya ragu, saya dapat sepenuhnya mengekspresikannya kepada kepemimpinan, tetapi tidak untuk "menurunkannya." Sebagai seorang insinyur kepala, saya harus ingat bagaimana kata-kata saya memengaruhi orang lain, karena saya memiliki pengaruh besar, bahkan jika saya tidak menyadarinya. Dan semua ini dia katakan dengan sangat ramah kepada saya, dan pada akhirnya mengatakan bahwa jika saya benar-benar merasakan perasaan seperti itu, maka saya mungkin perlu memikirkan apa yang saya inginkan untuk diri saya sendiri dan karier saya. Itu adalah percakapan yang sangat lembut dalam gaya "tenangkan dirimu atau keluar." Saya berterima kasih kepadanya atas informasi tentang bagaimana sikap saya, yang telah berubah selama enam bulan terakhir, secara tidak kasat mata memengaruhi orang lain bagi saya.

Ini adalah contoh manajemen yang luar biasa, efektif, dan kekuatan pendekatan yang lunak. Saya menyadari bahwa sepertinya saya benar-benar percaya pada perusahaan dan kemampuannya untuk mencapai tujuan, tetapi pada kenyataannya saya berbicara dan berkomunikasi dengan orang lain dengan cara yang sama sekali berbeda. Saya juga menyadari bahwa walaupun merasa skeptis tentang proyek yang sedang saya kerjakan, saya seharusnya tidak menunjukkan sikap saya kepada rekan-rekan saya dan menyebarkan pesimisme seperti infeksi, mengurangi peluang keberhasilan kami. Alih-alih, saya dapat dengan agresif menyiarkan situasi yang sebenarnya kepada kepemimpinan saya. Dan jika saya merasa bahwa mereka tidak mendengarkan saya, saya dapat menyatakan ketidaksetujuan saya dengan meninggalkan perusahaan.

Saya mendapat peluang baru ketika saya mengambil posisi sebagai kepala staf penilaian. Sebagai mantan chief engineer, saya dengan hati-hati memantau pendapat saya tentang kode warisan kami (yang terus meningkat). Untuk menyetujui perubahan, Anda perlu membayangkan situasi saat ini, tetapi Anda tidak akan melakukan apa pun jika Anda terhenti dalam mengeluh, menyerang, atau sesuatu seperti itu. , , , , , .

, , , , . (« »), . , , (?) (« , , »). , .

, : , .