Saya sedang melihat sepotong kode. Ini mungkin kode terburuk yang pernah saya lihat. Untuk memperbarui hanya satu catatan dalam database, ia mengambil semua catatan dalam koleksi dan kemudian mengirimkan permintaan pembaruan ke setiap catatan dalam database, bahkan catatan yang tidak perlu diperbarui. Ada fungsi peta yang hanya mengembalikan nilai yang diteruskan ke sana. Ada pengujian bersyarat untuk variabel dengan nilai yang tampaknya sama, hanya diberi nama dengan gaya berbeda (firstName и first_name). Untuk setiap UPDATE, kode mengirimkan pesan ke antrean berbeda, yang ditangani oleh fungsi tanpa server berbeda, namun melakukan semua pekerjaan untuk koleksi berbeda di database yang sama. Apakah saya menyebutkan bahwa fungsi tanpa server ini berasal dari “arsitektur berorientasi layanan” berbasis cloud yang berisi lebih dari 100 fungsi di lingkungan?
Bagaimana mungkin melakukan ini? Aku menutupi wajahku dan terlihat terisak-isak di sela-sela tawaku. Rekan-rekan saya bertanya apa yang terjadi, dan saya menceritakannya kembali dengan warna Hit Terburuk BulkDataImporter.js 2018. Semua orang mengangguk penuh simpati kepada saya dan setuju: bagaimana mereka bisa melakukan ini terhadap kami?
Negatif: alat emosional dalam budaya programmer
Negatif memainkan peran penting dalam pemrograman. Hal ini tertanam dalam budaya kita dan digunakan untuk membagikan apa yang telah kita pelajari (“Anda tidak melakukannya kamu akan mempercayainya, seperti apa kode itu!”), untuk mengungkapkan simpati melalui rasa frustasi (“Ya Tuhan, MENGAPA melakukan itu?”), untuk memamerkan diri (“Saya tidak akan pernah jadi tidak melakukannya”), menyalahkan orang lain (“kami gagal karena kode etiknya, yang tidak mungkin dipertahankan”), atau, seperti yang biasa dilakukan dalam organisasi yang paling “beracun”, mengendalikan orang lain melalui cara perasaan malu (“Apa yang sebenarnya kamu pikirkan?” ? Benar”).
Negativitas sangat penting bagi programmer karena ini adalah cara yang sangat efektif untuk menyampaikan nilai. Saya pernah menghadiri kamp pemrograman, dan praktik standar dalam menanamkan budaya industri pada siswa adalah dengan memberikan meme, cerita, dan video dengan murah hati, yang paling populer dieksploitasi. . Senang rasanya bisa menggunakan alat emosional untuk mengidentifikasi Yang Baik, Yang Buruk, Yang Jelek, Jangan Lakukan Itu, Jangan Sama Sekali. Pendatang baru perlu dipersiapkan menghadapi kenyataan bahwa mereka mungkin akan disalahpahami oleh rekan-rekan yang jauh dari IT. Bahwa teman-teman mereka akan mulai menjual ide aplikasi bernilai jutaan dolar kepada mereka. Bahwa mereka harus menjelajahi labirin kode usang yang tak ada habisnya dengan sekelompok minotaur di sudutnya.
Ketika kita pertama kali belajar memprogram, pemahaman kita tentang kedalaman “pengalaman pemrograman” didasarkan pada pengamatan reaksi emosional orang lain. Hal ini terlihat jelas dari postingan di , tempat berkumpulnya banyak programmer pemula. Banyak hal-hal lucu yang sampai taraf tertentu diwarnai dengan nuansa negatif yang berbeda-beda: kekecewaan, pesimisme, kemarahan, sikap merendahkan, dan lain-lain. Dan jika ini dirasa belum cukup bagi Anda, bacalah komentarnya.
Saya perhatikan bahwa seiring bertambahnya pengalaman programmer, mereka menjadi semakin negatif. Para pemula, yang tidak menyadari kesulitan yang menanti mereka, memulai dengan antusiasme dan kemauan untuk percaya bahwa penyebab kesulitan-kesulitan ini hanyalah kurangnya pengalaman dan pengetahuan; dan pada akhirnya mereka akan dihadapkan pada kenyataan.
Waktu berlalu, mereka memperoleh pengalaman dan mampu membedakan kode Baik dari Kode Buruk. Dan ketika momen itu tiba, programmer muda merasa frustrasi karena bekerja dengan kode yang jelas-jelas buruk. Dan jika mereka bekerja dalam tim (jarak jauh atau tatap muka), mereka sering kali mengadopsi kebiasaan emosional rekan kerja yang lebih berpengalaman. Hal ini sering kali mengarah pada peningkatan hal-hal negatif, karena generasi muda sekarang dapat berbicara dengan serius tentang kode dan membaginya menjadi buruk dan baik, sehingga menunjukkan bahwa mereka “mengetahuinya”. Hal ini semakin memperkuat hal negatifnya: karena kecewa, Anda mudah bergaul dengan rekan kerja dan menjadi bagian dari suatu kelompok; mengkritik Kode Buruk akan meningkatkan status dan profesionalisme Anda di mata orang lain: .
Meningkatnya sikap negatif tidak selalu berarti buruk. Pembahasan pemrograman, antara lain, sangat terfokus pada kualitas kode yang ditulis. Kode tersebut sepenuhnya mendefinisikan fungsi yang dimaksudkan (selain perangkat keras, jaringan, dll.), jadi penting untuk dapat mengungkapkan pendapat Anda tentang kode tersebut. Hampir semua diskusi mengarah pada apakah kode tersebut cukup baik, dan mengutuk manifestasi kode yang buruk dalam istilah yang konotasi emosionalnya mencirikan kualitas kode tersebut:
- "Ada banyak inkonsistensi logika dalam modul ini, modul ini merupakan kandidat yang baik untuk optimalisasi kinerja yang signifikan."
- “Modul ini sangat buruk, kita perlu melakukan refaktorisasi.”
- “Modul ini tidak masuk akal, perlu ditulis ulang.”
- “Modul ini jelek, perlu ditambal.”
- “Ini adalah bagian dari ram, bukan modul, tidak perlu ditulis sama sekali, apa yang dipikirkan pembuatnya.”
Ngomong-ngomong, "pelepasan emosional" inilah yang membuat pengembang menyebut kode itu "seksi", yang jarang sekali dianggap adil - kecuali Anda bekerja di PornHub.
Masalahnya adalah manusia adalah makhluk yang aneh, gelisah, emosional, dan persepsi serta ekspresi emosi apa pun mengubah kita: pada awalnya secara halus, tetapi seiring berjalannya waktu, secara dramatis.
Kemiringan negatif yang licin dan bermasalah
Beberapa tahun yang lalu, saya adalah pemimpin tim informal dan mewawancarai seorang pengembang. Kami sangat menyukainya: dia cerdas, mengajukan pertanyaan yang bagus, paham teknologi, dan cocok dengan budaya kami. Saya sangat terkesan dengan sikap positifnya dan betapa ia tampak giat. Dan saya mempekerjakannya.
Saat itu, saya telah bekerja di perusahaan tersebut selama beberapa tahun dan merasa bahwa budaya kami tidak terlalu efektif. Kami mencoba meluncurkan produk dua kali, tiga kali, dan beberapa kali lagi sebelum saya tiba, yang mengakibatkan biaya pengerjaan ulang yang besar, sehingga kami tidak dapat menunjukkan apa pun kecuali malam yang panjang, tenggat waktu yang ketat, dan produk yang berhasil. Dan meskipun saya masih bekerja keras, saya ragu dengan tenggat waktu terakhir yang diberikan manajemen kepada kami. Dan dia dengan santai mengumpat ketika mendiskusikan beberapa aspek kode dengan rekan-rekan saya.
Jadi tidak mengejutkan—walaupun saya terkejut—bahwa beberapa minggu kemudian, pengembang baru tersebut mengatakan hal negatif yang sama seperti yang saya katakan (termasuk makian). Saya menyadari bahwa dia akan berperilaku berbeda di perusahaan berbeda dengan budaya berbeda. Dia hanya beradaptasi dengan budaya yang saya buat. Saya diliputi perasaan bersalah. Karena pengalaman subjektif saya, saya menanamkan pesimisme pada pendatang baru yang saya anggap sangat berbeda. Meskipun dia sebenarnya tidak seperti itu dan hanya berpenampilan untuk menunjukkan bahwa dia bisa cocok, aku memaksakan sikap burukku padanya. Dan segala sesuatu yang diucapkan, meskipun hanya bercanda atau sepintas lalu, memiliki cara yang buruk untuk berubah menjadi apa yang diyakini.
Cara-cara negatif
Mari kita kembali ke programmer pemula sebelumnya, yang telah memperoleh sedikit kebijaksanaan dan pengalaman: mereka menjadi lebih akrab dengan industri pemrograman dan memahami bahwa kode buruk ada di mana-mana, dan tidak dapat dihindari. Hal ini terjadi bahkan di perusahaan paling maju yang berfokus pada kualitas (dan izinkan saya mencatat: tampaknya, modernitas tidak melindungi dari kode yang buruk).
Naskah yang bagus. Seiring waktu, pengembang mulai menerima bahwa kode buruk adalah realitas perangkat lunak dan tugas mereka adalah memperbaikinya. Dan jika kode yang buruk tidak dapat dihindari, maka tidak ada gunanya mempermasalahkannya. Mereka mengambil jalur Zen, fokus pada penyelesaian masalah atau tugas yang mereka hadapi. Mereka belajar cara mengukur dan mengomunikasikan kualitas perangkat lunak secara akurat kepada pemilik bisnis, menulis perkiraan yang masuk akal berdasarkan pengalaman mereka selama bertahun-tahun, dan pada akhirnya menerima imbalan besar atas nilai luar biasa dan berkelanjutan mereka bagi bisnis. Mereka melakukan pekerjaannya dengan sangat baik sehingga mereka mendapat bonus sebesar $10 juta dan pensiun untuk melakukan apa yang mereka inginkan selama sisa hidup mereka (mohon jangan anggap remeh).
Skenario lainnya adalah jalan kegelapan. Alih-alih menerima kode buruk sebagai suatu keniscayaan, pengembang mengambil tindakan sendiri untuk mengungkap segala sesuatu yang buruk di dunia pemrograman sehingga mereka dapat mengatasinya. Mereka menolak untuk memperbaiki kode buruk yang ada karena berbagai alasan: “orang harus tahu lebih banyak dan tidak terlalu bodoh”; "itu tidak menyenangkan"; “ini buruk bagi bisnis”; “ini membuktikan betapa pintarnya saya”; “Jika saya tidak memberi tahu Anda betapa buruknya kode ini, seluruh perusahaan akan jatuh ke laut,” dan seterusnya.
Tentunya tidak dapat menerapkan perubahan yang mereka inginkan karena sayangnya bisnis harus terus berkembang dan tidak dapat menghabiskan waktu untuk mengkhawatirkan kualitas kode, orang-orang ini mendapatkan reputasi sebagai pengeluh. Mereka dipertahankan karena kompetensinya yang tinggi, namun didorong ke pinggiran perusahaan, di mana mereka tidak akan mengganggu banyak orang, namun tetap akan mendukung pengoperasian sistem kritis. Tanpa akses terhadap peluang pengembangan baru, mereka kehilangan keterampilan dan tidak lagi mampu memenuhi tuntutan industri. Negativitas mereka berubah menjadi kepahitan yang pahit, dan akibatnya mereka memenuhi ego mereka dengan berdebat dengan siswa berusia dua puluh tahun tentang perjalanan yang telah ditempuh oleh teknologi lama favorit mereka dan mengapa teknologi itu masih begitu populer. Mereka akhirnya pensiun dan menjalani masa tua mereka dengan mengumpat pada burung.
Kenyataannya mungkin terletak di antara dua ekstrem ini.
Beberapa perusahaan telah sangat sukses dalam menciptakan budaya yang sangat negatif, picik, dan berkemauan keras (seperti Microsoft sebelumnya ) - seringkali ini adalah perusahaan dengan produk yang sangat sesuai dengan pasar dan kebutuhan untuk tumbuh secepat mungkin; atau perusahaan dengan hierarki komando dan kendali (Apple pada tahun-tahun terbaik Jobs), di mana setiap orang melakukan apa yang diperintahkan. Namun, penelitian bisnis modern (dan akal sehat) menunjukkan bahwa kecerdikan maksimal, yang mengarah pada inovasi dalam perusahaan, dan produktivitas tinggi pada individu, memerlukan tingkat stres yang rendah untuk mendukung pemikiran kreatif dan metodis yang berkelanjutan. Dan sangat sulit untuk melakukan pekerjaan kreatif berbasis diskusi jika Anda terus-menerus mengkhawatirkan 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 dibandingkan sebelumnya. Dalam organisasi teknik, aturan “". Semakin banyak anekdot dan cerita bermunculan di Twitter tentang orang-orang yang meninggalkan profesi ini karena mereka tidak dapat (tidak mau) terus menahan permusuhan dan niat buruk terhadap pihak luar. Bahkan Linus Torvalds permusuhan dan kritik selama bertahun-tahun terhadap pengembang Linux lainnya - hal ini menimbulkan perdebatan tentang efektivitas pendekatan ini.
Beberapa masih membela hak Linus untuk bersikap sangat kritis - mereka yang seharusnya tahu banyak tentang keuntungan dan kerugian dari "negatif beracun". Ya, kesopanan itu sangat penting (bahkan mendasar), namun jika kita menyimpulkan alasan mengapa banyak dari kita membiarkan ekspresi opini negatif berubah menjadi "toksisitas", alasan-alasan ini terkesan paternalistik atau remaja: "mereka pantas mendapatkannya karena mereka idiot ", "dia harus yakin bahwa mereka tidak akan melakukannya lagi", "jika mereka tidak melakukan itu, dia tidak perlu membentak mereka", dan seterusnya. Contoh dampak reaksi emosional seorang pemimpin terhadap komunitas pemrograman adalah akronim MINASWAN dari komunitas Ruby - "Matz itu bagus jadi kami baik."
Saya perhatikan bahwa banyak pendukung pendekatan "bunuh orang bodoh" sering kali sangat peduli dengan kualitas dan kebenaran kode, mengidentifikasi diri mereka dengan pekerjaan mereka. Sayangnya, mereka sering mengacaukan kekerasan dengan kekakuan. Kerugian dari posisi ini berasal dari keinginan manusiawi yang sederhana namun tidak produktif untuk merasa lebih unggul dari orang lain. Orang yang tenggelam dalam keinginan ini akan terjebak di jalan kegelapan.
Dunia pemrograman berkembang pesat dan mendorong batas-batas wadahnya – dunia non-pemrograman (ataukah dunia pemrograman merupakan wadah bagi dunia non-pemrograman? Pertanyaan bagus).
Ketika industri kita berkembang dengan kecepatan yang semakin meningkat dan pemrograman menjadi lebih mudah diakses, jarak antara “teknisi” dan “normal” semakin dekat. Dunia pemrograman semakin terpapar pada interaksi antarpribadi dari orang-orang yang tumbuh dalam budaya nerd yang terisolasi pada masa awal booming teknologi, dan merekalah yang akan membentuk dunia pemrograman baru. Dan terlepas dari argumen sosial atau generasi apa pun, efisiensi atas nama kapitalisme akan terlihat dalam budaya perusahaan dan praktik perekrutan: perusahaan terbaik tidak akan mempekerjakan siapa pun yang tidak dapat berinteraksi secara netral dengan orang lain, apalagi memiliki hubungan baik.
Apa yang saya pelajari tentang hal negatif
Jika Anda membiarkan terlalu banyak hal negatif mengendalikan pikiran dan interaksi Anda dengan orang lain, sehingga berubah menjadi racun, maka hal itu berbahaya bagi tim produk dan mahal bagi bisnis. Saya telah melihat (dan mendengar) banyak sekali proyek yang berantakan dan dibangun kembali sepenuhnya dengan biaya besar karena satu pengembang tepercaya memiliki dendam terhadap teknologinya, pengembang lain, atau bahkan satu file yang dipilih untuk mewakili kualitas keseluruhan basis kode.
Negatif juga melemahkan semangat dan menghancurkan hubungan. Saya tidak akan pernah lupa bagaimana seorang rekan memarahi saya karena memasukkan CSS ke file yang salah, hal itu membuat saya kesal dan tidak mengizinkan saya mengumpulkan pikiran selama beberapa hari. Dan di masa depan, saya tidak mungkin membiarkan orang seperti itu berada di dekat salah satu tim saya (tapi siapa tahu, orang-orang berubah).
Terakhir, yang negatif .
Saya rasa seperti inilah seharusnya kelas master tentang senyuman.
Tentu saja, ini bukan argumen yang mendukung berseri-seri dengan kebahagiaan, memasukkan sepuluh miliar emotikon ke dalam setiap permintaan penarikan, atau mengikuti kelas master tentang senyuman (tidak, jika itu yang Anda inginkan, maka tidak ada pertanyaan). Negatif adalah bagian yang sangat penting dari pemrograman (dan kehidupan manusia), menandakan kualitas, memungkinkan seseorang untuk mengekspresikan perasaan dan bersimpati dengan sesama manusia. Negatif menunjukkan wawasan dan kehati-hatian, kedalaman masalah. Saya sering memperhatikan bahwa seorang pengembang telah mencapai level baru ketika dia mulai mengungkapkan ketidakpercayaannya pada apa yang sebelumnya dia takuti dan tidak yakin. Orang-orang menunjukkan kewajaran dan kepercayaan diri dengan pendapat mereka. Anda tidak dapat mengabaikan ekspresi negatif, itu adalah Orwellian.
Namun, hal-hal negatif perlu diatasi dan diimbangi dengan kualitas penting manusia lainnya: empati, kesabaran, pengertian, dan humor. Anda selalu dapat memberi tahu seseorang bahwa dia mengacau tanpa berteriak atau mengumpat. Jangan meremehkan pendekatan ini: jika seseorang memberi tahu Anda tanpa emosi bahwa Anda telah melakukan kesalahan serius, itu sangat menakutkan.
Saat itu, beberapa tahun lalu, CEO berbicara kepada saya. Kami mendiskusikan status proyek saat ini, lalu dia bertanya bagaimana perasaan saya. Saya menjawab semuanya baik-baik saja, proyek berjalan, kami bekerja lambat, mungkin saya melewatkan sesuatu dan perlu dipertimbangkan kembali. Dia mengatakan bahwa dia telah mendengar saya berbagi pemikiran yang lebih pesimistis dengan rekan-rekan di kantor, dan orang lain juga memperhatikan hal ini. Dia menjelaskan bahwa jika saya memiliki keraguan, saya dapat mengungkapkannya sepenuhnya kepada manajemen, tetapi tidak “menghilangkannya”. Sebagai seorang lead engineer, saya harus memperhatikan bagaimana kata-kata saya mempengaruhi orang lain karena saya memiliki banyak pengaruh meskipun saya tidak menyadarinya. Dan dia menceritakan semua ini kepada saya dengan sangat baik, dan akhirnya mengatakan bahwa jika saya benar-benar merasa seperti itu, maka saya mungkin perlu memikirkan tentang apa yang saya inginkan untuk diri saya dan karier saya. Itu adalah percakapan yang sangat lembut dan santai. Saya berterima kasih padanya atas informasi tentang bagaimana perubahan sikap saya selama enam bulan berdampak pada orang lain tanpa saya sadari.
Ini adalah contoh manajemen yang luar biasa dan efektif serta kekuatan pendekatan yang lembut. Saya menyadari bahwa sepertinya saya hanya memiliki keyakinan penuh pada perusahaan dan kemampuannya untuk mencapai tujuannya, namun kenyataannya saya berbicara dan berkomunikasi dengan orang lain dengan cara yang sangat berbeda. Saya juga menyadari bahwa meskipun saya merasa skeptis terhadap proyek yang saya kerjakan, saya tidak boleh menunjukkan perasaan saya kepada rekan kerja dan menyebarkan pesimisme seperti penyakit menular, sehingga mengurangi peluang kami untuk sukses. Sebaliknya, saya bisa secara agresif menyampaikan situasi sebenarnya kepada manajemen saya. Dan jika saya merasa mereka tidak mendengarkan saya, saya dapat mengungkapkan ketidaksetujuan saya dengan keluar dari perusahaan.
Saya mendapat kesempatan baru ketika saya menjabat sebagai kepala penilaian personalia. Sebagai mantan chief engineer, saya sangat berhati-hati dalam mengungkapkan pendapat saya tentang kode lama kami (yang terus berkembang). Untuk menyetujui suatu perubahan, Anda perlu membayangkan situasi saat ini, tetapi Anda tidak akan mendapatkan apa-apa jika Anda terus-menerus mengeluh, menyerang, atau sejenisnya. Pada akhirnya, saya di sini untuk menyelesaikan tugas dan tidak boleh mengeluh tentang kode untuk memahaminya, mengevaluasinya, atau memperbaikinya.
Faktanya, semakin saya mengendalikan reaksi emosional saya terhadap kode tersebut, semakin saya memahami apa jadinya dan semakin sedikit kebingungan yang saya rasakan. Saat saya mengekspresikan diri dengan menahan diri (“harus ada ruang untuk perbaikan lebih lanjut”), saya membuat diri sendiri dan orang lain bahagia dan tidak menganggap situasi ini terlalu serius. Saya menyadari bahwa saya dapat menstimulasi dan mengurangi sikap negatif orang lain dengan bersikap masuk akal (yang menjengkelkan?) (“Anda benar, kode ini sangat buruk, tetapi kami akan memperbaikinya”). Saya senang melihat sejauh mana saya bisa menempuh jalur Zen.
Intinya, saya terus-menerus belajar dan mempelajari kembali sebuah pelajaran penting: hidup ini terlalu singkat untuk terus-menerus marah dan kesakitan.
Sumber: www.habr.com