Pada titik apa kritik “konstruktif” terhadap kode Anda menjadi tidak membantu?

Saya baru-baru ini mulai sebagai pengembang junior. Selain sebagai salah satu orang yang paling tidak berpengalaman dalam tim, saya juga seorang wanita, yang datang dengan segala macam tantangannya sendiri bekerja di lingkungan yang didominasi pria. Saya mengalami masalah belakangan ini karena saya merasa saya mendapat terlalu banyak kritik pedantic yang tidak beralasan atas pekerjaan saya. Biarkan saya memberi Anda sebuah contoh tentang apa yang terjadi baru-baru ini.

Pemimpin tim terlalu sibuk untuk mendorong di beberapa cabang yang saya buat, jadi dia tidak sampai ke mereka sampai akhir pekan. Saya memeriksa email saya, tidak benar-benar bermaksud melakukan pekerjaan apa pun, dan menemukan bahwa dua cabang saya telah ditolak berdasarkan nama variabel, membuat pesan kesalahan lebih deskriptif, dan memindahkan beberapa nilai ke file konfigurasi.

Saya tidak merasa bahwa menolak cabang saya atas dasar ini berguna. Banyak orang bekerja selama akhir pekan, dan saya tidak pernah mengatakan bahwa saya akan bekerja. Secara efektif, beberapa orang mungkin diblokir karena saya tidak punya waktu untuk melakukan perubahan dan mengirimkan kembali. Kami sedang mengerjakan proyek yang sangat sensitif terhadap waktu, dan bagi saya sepertinya tidak membantu untuk langsung menolak kode berdasarkan hal-hal yang transparan bagi klien. Saya mungkin salah, tetapi sepertinya hal-hal seperti ini harus ditangani dengan tipe patch ketika saya punya waktu.

Sekarang, saya dapat melihat bahwa di beberapa lingkungan, ini akan menjadi norma. Namun, kritik itu tampaknya tidak terdistribusi secara merata, yang menyebabkan masalah saya selanjutnya. Dasar dari sebagian besar masalah ini adalah karena fakta bahwa saya berada dalam basis kode yang ditulis orang lain dan berusaha untuk sedikit invasif. Saya meniru nama variabel yang digunakan di tempat lain dalam file. Ketika saya menyatakan ini, saya terus terang diberi tahu, "Jangan meniru orang lain, lakukan saja yang benar." Ini mungkin hal yang paling tidak berguna yang bisa saya katakan. Jika kode yang sudah diperiksa tidak dapat diterima, bagaimana saya bisa tahu mana yang benar dan apa yang salah? Jika dasar kebingungan itu berasal dari kode yang mendasarinya, saya tidak berpikir itu '

Saya merasa sangat dipilih dan frustrasi dalam situasi ini. Saya sudah jauh lebih baik dalam mengikuti standar yang diharapkan, dan saya merasa frustrasi bahwa, misalnya, ketika saya refactor sepotong kode untuk ADD memeriksa kesalahan yang sebelumnya hilang, saya hanya diberitahu bahwa saya tidak buat kesalahan cukup dengan bertele-tele (dan cabang ditolak atas dasar ini). Bagaimana jika saya belum pernah menambahkannya? Bagaimana bisa masuk ke kode untuk memulai jika itu salah? Inilah sebabnya saya merasa sangat dipilih: Saya terus-menerus menemukan kode bermasalah yang ada, yang saya tiru atau refactor. Ketika saya menirunya, itu "salah", dan jika saya refactor, saya dicaci karena tidak cukup melakukan (dan jika saya terus berusaha, memperkenalkan bug, dll). Sekali lagi, jika ini adalah masalah seperti itu, saya tidak mengerti bagaimana kode masuk ke basis kode,

Lagi pula, bagaimana saya menangani ini? Harap ingat bahwa saya katakan di atas bahwa saya seorang wanita, dan saya yakin orang-orang ini biasanya tidak perlu khawatir tentang kesopanan ketika mereka meninjau kode orang lain, tetapi jujur ​​itu tidak bekerja untuk saya , dan itu menyebabkan saya menjadi kurang produktif. Saya khawatir jika saya berbicara dengan manajer saya tentang hal itu, dia akan berpikir saya tidak bisa menangani lingkungan, dll.

Ada kemungkinan Anda dipilih sebagai seorang wanita, tetapi mungkin juga Anda hanya seorang pengembang junior dan baru dalam pekerjaan itu.

Memeriksa kesalahan dan pesan ekspresif adalah penting. Jika Anda akan menambahkan sesuatu ke kode, pastikan itu benar dan sesuai dengan standar tim. Demikian pula, jika Anda memodifikasi kode orang lain, cobalah untuk memperbaikinya di mana mungkin - jangan pergi menulis ulang semuanya, tetapi cobalah untuk meninggalkannya sedikit lebih bersih daripada yang Anda temukan.

Apakah ada versi tertulis dari standar pengkodean yang diikuti oleh tim Anda? Jika tidak, mungkin ide yang baik untuk menuliskan semuanya. Anda dapat mempelopori upaya dengan menuliskan kesalahan yang Anda buat dan membentuknya menjadi daftar periksa yang dapat Anda rujuk sebelum mengirimkan perubahan Anda untuk ditinjau. Sebagai efek samping, Anda dapat menggunakan standar tertulis itu untuk mengajukan banding atas penolakan di masa depan jika mereka membantahnya.

Sepertinya ada beberapa kekurangan antara Anda dan pemimpin tim. Mungkin bermanfaat bagi Anda untuk meminta pertemuan pribadi dengannya dan membahas apa yang dapat Anda lakukan untuk meningkatkan. Anda dapat memimpin dengan sesuatu seperti "Saya merasa masih kehilangan banyak nuansa tentang apa yang harus saya lakukan. Sebagai pengembang junior saya ingin tumbuh dan berkembang. Dapatkah Anda membantu saya sampai di sana?" dan lihat apa yang terjadi.

Sepertinya Anda mungkin mengambil barang ini terlalu pribadi. Jangan; hal semacam ini terjadi setiap saat.

Alasan menolak check-in Anda (penamaan variabel, kualitas komentar, lokasi konfigurasi) tampaknya cukup standar bagi saya.

Saatnya adalah keputusan pemimpin tim Anda, dan saya tidak akan khawatir tentang itu jika saya adalah Anda. Jika seseorang diblokir selama akhir pekan, ketua tim dapat memilih untuk mengizinkan check-in dan meminta Anda untuk memperbaikinya setelahnya. Jika dia merasa pantas untuk menendang kembali meskipun itu mungkin memblokir beberapa devs lain, itu tanggung jawabnya.

Adapun pemimpin tim mengatakan kepada Anda untuk tidak meniru orang lain tetapi untuk melakukan apa yang benar, sepertinya dia mencoba memberi Anda beberapa inisiatif untuk membuat basis kode yang lebih baik. Itu pertanda baik. Dia memercayai Anda untuk menggunakan penilaian Anda , jadi teruskan saja dan lakukan apa yang Anda tahu benar. Itu tidak berarti bahwa Anda harus mengubah kode orang lain, tetapi itu berarti Anda harus bertanggung jawab atas kualitas kode yang Anda tulis.

Tambahan untuk jawaban lain:

Sebagai Pengembang Pimpinan, saya biasanya lebih pilih-pilih dengan para junior devs karena mereka jauh lebih lunak daripada orang yang telah bekerja selama beberapa tahun. (Keterampilan ppl saya belum begitu baik ...)

Sangat sulit untuk mengubah seseorang yang telah bekerja (dan mendapatkan gaji yang layak) untuk sementara waktu dan puas dengan tingkat kode (meskipun kualitasnya dapat ditingkatkan). Orang-orang itu tidak peduli jika Anda mencoba membimbing mereka untuk menjadi programmer yang lebih baik / hebat. Mereka senang bekerja di pabrik kode.

Cowok baru, seperti Anda, OTOH, biasanya merindukan bimbingan dan mengetahui apa yang benar dan tidak. Juga, mereka dapat menyerap feeback dan mengubah cara mereka menjadi lebih baik. Mereka tidak diatur dengan cara mereka.

Jika Anda memperhatikan saran ini dan menjadikannya bagian dari kehidupan sehari-hari Anda, Anda akan segera mengetahui bahwa Anda akan menulis kode yang lebih unggul daripada kebanyakan basis kode yang ada.

Jadi ...

.. bisa jadi Anda mendapatkan lebih banyak umpan balik hanya karena Anda memiliki potensi untuk membuatnya. :)

Sangat mungkin Anda dipilih karena ... Anda adalah pengembang junior.

Dari uraian Anda, sepertinya Anda tidak mengikuti standar seperti yang dipahami oleh ketua tim .

Solusinya sederhana:

• Jika itu standarnya, ikuti saja.
• Jika Anda tidak memahami standarnya, mintalah klarifikasi.
• Jika interpretasi Anda tentang standar atau instruksi berbeda dari pimpinan tim, mintalah klarifikasi

Jangan bertempur darinya; jika Anda mencoba membuat tim memimpin "salah" maka bahkan jika Anda menang, Anda kalah. Pelajari pelajaran yang sesuai dan terus berkembang.

Catatan Penulis

Beberapa tahun kemudian; Saya telah mengedit ini untuk lebih akurat mencerminkan perasaan saya tentang situasi tersebut. Saya memberikan nuansa yang lebih dalam jawaban saya karena saya belajar lebih banyak tentang nuansa dalam situasi ini. Sangat mudah untuk mengklaim jawaban 'hitam atau putih', tetapi kita semua tahu itu tidak sesederhana itu. Jawaban saya sekarang mencerminkan hal itu.

Dari apa yang telah Anda jelaskan; perilaku yang Anda alami tampaknya tidak ada hubungannya dengan jenis kelamin Anda. Itu bukan untuk mengatakan Anda tidak mengalami perlakuan terkait gender (saya harap Anda tidak), hanya saja apa yang Anda uraikan tampaknya tidak terkait gender.

Ketika saya adalah seorang pemimpin tim, saya memperlakukan semua orang sama. Tidak ada ruang dalam teknologi untuk memperlakukan seseorang dengan buruk karena jenis kelaminnya. Saya tidak tahu bagaimana menghadapinya jika itu terjadi pada Anda.

Penting bagi Anda untuk percaya bahwa pemimpin Tim Anda memperlakukan pria dan wanita secara setara. Jika ada bukti dia tidak, maka pepatah lama berlaku: Ubah lingkungan Anda atau ubah lingkungan Anda.

Maksud saya sama bahwa dia memperlakukan semua orang sama tanpa rasa hormat pada gender. Jika dia melakukan pekerjaannya dengan benar, Anda seharusnya tidak melihatnya mengkritik orang lain; dan mereka seharusnya tidak melihatnya mengkritik Anda. Di depan orang lain, sangat penting bagi pemimpin tim untuk menunjukkan kepercayaan diri, bahkan jika dia hanya menghabiskan lima menit terakhir sebelum memperbaiki perilaku secara pribadi.

Sekarang ke masalah yang Anda ajukan:

Anda memeriksa kode yang tidak memenuhi standar yang ditetapkannya, jadi dia menolak cabang Anda. Jika saya berada di posisinya, saya tidak akan melakukan hal yang sama dengan cara yang sama, tetapi saya akan memastikan bahwa bawahan saya (kata aneh; karena saya tidak menganggap pemimpin sebagai 'superior' dari orang-orang yang mereka kenal). memimpin, tetapi secara akurat (tidak memadai) menggambarkan situasi) tahu apa yang benar untuk dilakukan. Jika mereka tidak tahu standarnya, itu salah saya sebagai pemimpin. Terserah saya untuk memperbaikinya. Dalam hal ini, Anda mungkin telah melakukan kesalahan, tetapi fakta bahwa itu terjadi berarti Anda salah 1) tidak diberi tahu apa yang harus dilakukan atau 2) tidak dibimbing dengan tepat. Anda juga tidak salah.

Salah satu bagian terpenting dari menjadi seorang programmer adalah menyadari bahwa basis kode yang Anda kerjakan harus dipelihara oleh banyak orang yang berbeda. Setiap variabel yang berantakan atau hal-hal lain yang mengurangi kemampuan untuk membaca kode tidak transparan bagi pelanggan , karena butuh waktu lebih lama untuk memperbaiki masalah dalam kode yang lebih sulit untuk dibaca.

Jika tim Anda memiliki pedoman penulisan kode, ikuti mereka. Jika tidak, maka harus ada semacam konvensi komunitas untuk bahasa Anda (Untuk .NET dan C #, Microsoft memiliki standar yang diikuti banyak perusahaan).

Tanyakan pada Tim Lead Anda di mana pedoman pengkodean berada sehingga Anda dapat memastikan bahwa Anda mengikuti mereka. Bawa dua checkin ke rapat Anda di mana dua pengembang lain tidak secara konsisten mengikuti pedoman, sehingga ketika dia mengatakan tidak ada, Anda dapat menunjukkan bahwa orang lain tampaknya memiliki masalah dengan itu, dan semua orang akan mendapat manfaat dari memiliki pedoman tersebut.

Jika dia memperlakukan Anda dengan adil, maka dia akan melihat ini dan ini harus berada di atas daftar hal yang harus dilakukan. Jika dia tidak memperlakukan Anda dengan adil, maka Anda memiliki amunisi jika itu terus terjadi.

Mengatakan "Aku akan menyelesaikannya nanti" itu buruk. Nanti tidak pernah terjadi. Luangkan waktu untuk melakukannya dengan benar. Tidak ada yang lebih baru dalam pemrograman.

Sulit ketika Anda seorang pengembang junior. Anda merasa tertekan untuk tampil dan ada banyak orang yang memandang Anda, dan setiap kesalahan yang Anda buat terkait dengan nama Anda dalam kendali sumber selamanya.

Tidak ada tempat di posting Anda yang Anda sebutkan bagaimana orang lain di sekitar diperlakukan. Anda terus mengulangi bahwa Anda "merasa" Anda "dipilih" karena Anda "seorang wanita".

Saya pikir Anda diperlakukan seperti seorang programmer junior terlepas dari jenis kelamin Anda dan Anda harus berterima kasih untuk itu, karena itulah arti kesetaraan. Saya juga merasa Anda membuat keributan besar terhadap perubahan estetika kode kecil, 5 menit yang Anda diminta untuk lakukan sekarang alih-alih memasukkannya ke daftar tugas dan tidak pernah menyiasati mereka.

Tidak ada tempat di pos Anda yang menyebutkan bahwa Anda diperintahkan untuk melakukan hal-hal ini pada akhir pekan. Mungkin baik-baik saja untuk memeriksa perbaikan pada Senin pagi.

Pimpinan tim Anda mungkin sedikit jengkel untuk selera saya, tetapi dari jabatan Anda, saya tidak melihat ada yang salah dengan permintaannya.

Tolong berhenti bermain kartu gender untuk apa-apa . Saya merasa ini tidak bermartabat dan merusak konsep kesetaraan gender.

Saya tidak merasa bahwa menolak cabang saya atas dasar ini berguna. Banyak orang bekerja selama akhir pekan, dan saya tidak pernah mengatakan bahwa saya akan bekerja. Secara efektif, beberapa orang mungkin diblokir karena saya tidak punya waktu untuk melakukan perubahan dan mengirimkan kembali. Kami sedang mengerjakan proyek yang sangat sensitif terhadap waktu, dan bagi saya sepertinya tidak membantu untuk langsung menolak kode berdasarkan hal-hal yang transparan bagi klien. Saya mungkin salah, tetapi sepertinya hal-hal seperti ini harus ditangani dengan tipe patch ketika saya punya waktu.

Sulit mengatakan sesuatu yang berguna sebagai seseorang yang tidak melihat kode Anda atau mengetahui sesuatu tentang jadwal proyek Anda. Tetapi, jika pemimpin Anda bertindak secara bertanggung jawab dan melakukan pekerjaan dengan baik, dia tahu, bahwa orang lain tidak benar-benar diblokir dan sprint tidak akan terlambat. Jadi, jangan khawatir tentang itu. Mungkin Anda melebih-lebihkan dampak pada komitmen Anda. Kalau tidak: jika proyek Anda kritis waktu dan melewati semua tes, itu akan terlalu pemilih untuk menolak kode, yang dapat diperbaiki setelah rilis dalam sekejap mata.

Buatlah Berhasil Lakukan dengan Benar Buatlah Cepat

Jadi, jika pemimpin Anda membuat keputusan untuk menolak komitmen Anda, sebagai seorang profesional ia harus tahu, apa yang ia lakukan.

Sekarang, saya dapat melihat bahwa di beberapa lingkungan, ini akan menjadi norma. Namun, kritik itu tampaknya tidak terdistribusi secara merata, yang menyebabkan masalah saya selanjutnya. Dasar dari sebagian besar masalah ini adalah karena fakta bahwa saya berada dalam basis kode yang ditulis orang lain dan berusaha untuk sedikit invasif. Saya meniru nama variabel yang digunakan di tempat lain dalam file. Ketika saya menyatakan ini, saya terus terang diberitahu, "Jangan meniru orang lain, lakukan saja yang benar."

Sebagai Junior sulit untuk menemukan jalan yang menjadi basis kode perusahaan.

Terbaik: ada standar pengkodean yang terdokumentasi - dan Anda diharapkan akan belajar untuk menguasai mereka.

Biasanya: ada didokumentasikan coding standar - dan Anda harus belajar melalui trial dan error atau harus saya katakan berkomitmen dan _reject? Ini seringkali menyakitkan (seperti dalam kasus Anda). Ini kadang - kadang berbahaya dalam hal kualitas kode dan dapat menyebabkan program pemujaan kargo , di mana orang tidak hanya meniru penamaan variabel, tetapi juga menyalin dan menempel struktur dan pola dari basis kode dengan itikad baik, itu harus dilakukan seperti itu. Jangan lakukan itu! Bahkan tidak meniru penamaan variabel yang ada.

Tetap pada Kode Bersih . Ini adalah praktik yang baik dan memberi Anda posisi mempertahankan yang mudah. Jika kode itu dapat dibaca, diuji, dan dipelihara, Anda sebagian besar telah memenangkan diskusi apa pun.

Dan ini mengarah pada saran (terakhir) yang lain: Ikuti aturan pramuka !

Selalu tinggalkan basis kode dalam keadaan yang lebih baik, daripada sebelumnya. Bahkan jika kode di sekeliling Anda bekerja dengan jahat, bersihkan kode Anda - dan jika Anda punya waktu memperbaiki lingkungan.

Luangkan sedikit waktu untuk mempelajari berbagai nuansa kepribadian rekan kerja Anda. Dalam pengalaman saya, Anda dapat menghindari kritik yang tidak masuk akal, tidak perlu, tidak konsisten, atau sekadar tidak berharga jika Anda mengatasi masalah rekan kerja Anda.

Misalnya beberapa rekan kerja mungkin akan mabuk pada hari Senin. Mereka mungkin sangat mudah tersinggung dan sangat ingin menolak cabang kode tertentu atau melakukan. Jika Anda harus bekerja dengan orang seperti ini, cobalah untuk menghindari melakukan kode pada hari Senin.

Di sisi lain, rekan kerja yang mabuk mungkin terlalu bosan untuk tidak peduli dengan kesalahan pesan ... jadi Senin pagi mungkin waktu yang tepat untuk melakukan kode Anda :-p

Keunikan kepribadian di kantor atau tempat kerja benar-benar tidak ada habisnya. Semoga Anda bisa belajar siapa yang harus dihindari dan kapan harus menghindarinya. Juga jangan terlalu keras pada diri sendiri :-) Anda selalu dapat berhenti dan mencari pekerjaan lain!

Saya tidak pernah bekerja di lingkungan di mana kode ditolak atas dasar konvensi tertentu yang tidak diikuti. Jika saya berada di posisi Anda, saya akan tergoda untuk mencari pekerjaan di tempat di mana saya lebih diberdayakan untuk membuat keputusan yang tepat dan di mana pelanggan adalah fokus utama, bukan kode.

Saya tidak mengatakan kode dan standar yang bersih tidak penting, tetapi pelanggan dan timeline produk tidak boleh menderita karena kesalahan ejaan dalam sesuatu yang tidak akan dilihat oleh orang, pelanggan, atau eksekutif non-teknis.

Dengan itu, sepertinya Anda mungkin bekerja di lingkungan di mana harapan tidak jelas, atau Anda tidak sepenuhnya memahami persyaratan, untuk alasan apa pun.

Apa pun situasinya, terserah Anda untuk mengambil kendali dan mengajukan pertanyaan klarifikasi. Jadilah proaktif, jika Anda belum melakukannya. Anggota tim dan ketua tim Anda kemungkinan akan lebih menghormati Anda karena mengajukan pertanyaan untuk memperjelas aturan untuk check-in. Anda juga dapat meminta "tinjauan setelah tindakan" di mana Anda dan pemimpin tim Anda membahas apa yang seharusnya Anda lakukan dan bagaimana Anda dapat mengetahui perbedaan sejauh kapan harus mengambil tindakan tertentu dan kapan tidak.

Saya sarankan berikan waktu, karena Anda masih baru, untuk melihat apakah Anda dapat melewati segala rintangan dan menyelesaikan masalah ini dengan pengalaman, komunikasi, dan mempelajari standar. Namun, jika setelah beberapa bulan situasinya tidak berubah dan lingkungan masih terganggu oleh ambiguitas, mungkin sudah waktunya untuk mencari pekerjaan di perusahaan lain.

Tidak setiap organisasi kejam ini, dan Anda mungkin menemukan lingkungan kerja lain yang lebih cocok dengan kepribadian, gaya, dan persyaratan komunikasi Anda.