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


39

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.


18
Saya seorang pria, junior (di perusahaan ini), dan saya telah merasakan standar ganda yang serupa. Basis kode sering terlihat seperti omong kosong, namun saya diharapkan untuk mengikuti standar yang jauh lebih tinggi. Ya, ternyata omong kosong itu masuk ke sana karena "mars kematian" yang dibuat di masa lalu. Juga, ternyata saya terlihat 5 tahun lebih muda dari saya. Ketika kolega saya mengetahui usia saya yang sebenarnya, saya menjadi jauh lebih pintar dalam semalam. Manusia adalah monyet yang tidak sempurna. Ini membantu jika Anda berbagi makan siang dengan mereka dan menertawakan lelucon mereka, tetapi jangan berlebihan. Cowok mengartikan SEMUA sebagai rayuan.
Pekerjaan

4
@ Pekerjaan: Ya, jika basis kode adalah omong kosong itu harus lebih baik, maka komit Anda harus memiliki standar yang lebih tinggi. Kalau tidak, itu akan menjadi lebih buruk, kan? :)
Macke

@ Marscus, Anda benar, tetapi yang akan sangat membantu adalah jika aturannya dinyatakan dengan jelas, dan aturan yang sama berlaku untuk semua orang. Juga, ada sesuatu yang bisa dikatakan tentang pencampuran ke dalam standar kode yang sama, seperti yang disebutkan oleh penanya. Saya telah melihat seorang pria junior dilepaskan sebagai kambing hitam. Manajemen mengeluh bahwa para insinyur terlalu banyak membuat bug. Para insinyur tidak dapat melakukan pekerjaan yang layak karena manajemen memberi mereka tenggat waktu tetap. Jadi, ketika ada masalah, selalu ada pria yunior dengan kesalahan terbesar yang harus disalahkan dan dilepaskan. en.wikipedia.org/wiki/Dedovshchina
Job

3
Satu hal yang menonjol bagi saya adalah "Mereka terbiasa dengan pria sehingga mereka tidak menggunakan kesopanan." Saya katakan Anda perlu menyedotnya kecuali itu jelas masalah diskriminasi. Apakah Anda akan pergi ke lokasi konstruksi dan berharap diperlakukan berbeda dari yang lain? Tangguh. Jika Anda bekerja di lingkungan yang didominasi pria, Anda harus dapat mengatasi dan menyesuaikan diri dengan berbagai norma sosial seperti yang harus mereka lakukan. Jangan terlalu "sensitif".
Rig

1
Saya tahu ini terlambat beberapa tahun, tetapi saya pikir ini adalah topik penting bagi pembaca di masa depan. Jangan mengecualikan kemungkinan bahwa pimpinan tim Anda lebih tahu; dia mungkin lebih senior dan telah mengembangkan intuisi untuk masalah gaya bermasalah - saya menantang siapa pun dalam situasi ini untuk memperlakukan ini sebagai kesempatan untuk belajar dan tumbuh. Hormat meminta klarifikasi tentang masalah yang Anda tidak mengerti, dan berhati-hatilah untuk tidak salah menafsirkan kepribadian kering rekan kerja sebagai jahat.
weberc2

Jawaban:


41

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.


Respons Anna umumnya sangat masuk akal. +1. Saya pikir bekerja di tempat Anda bekerja akan membuat saya gila. Tidakkah manajemen Anda peduli dengan memenuhi tenggat waktu? Jika kodenya berhasil, kirimkan. Bersihkan nanti. Heck, Anda bahkan bisa membersihkannya pada hari Senin dan mendorongnya dalam rilis berikutnya. Perilaku ini oleh manajer Anda tidak akan pernah terbang di tempat kerja saya, dan saya senang saya dapat berkonsentrasi untuk memenuhi tenggat waktu alih-alih politik. Semoga situasi Anda menjadi lebih baik dan Anda menemukan solusinya. :)
jmort253

11
@ jmort253 Terima kasih. :) Yang mengatakan, "jika kode berfungsi, kirimkan" bisa menjadi sikap berbahaya untuk dimiliki. Kode kerja tidak selalu merupakan kode yang baik (meskipun tentu saja lebih baik daripada kode yang rusak) dan kualitas kode penting dalam jangka panjang. Membersihkannya nanti hampir tidak pernah terjadi, karena tenggat waktu lain muncul dan lebih banyak hal mendesak muncul. Ada istilah untuk ini - "utang teknis".
Adam Lear

@ Anna, setujui pentingnya kode konforman. Saya telah membaca bahwa kode yang tidak sesuai sudah cukup bagi Linus Thorvalds untuk menolak patch yang diajukan untuk Linux saat itu juga (tetapi saya tidak dapat menemukannya sekarang).

@ Anna / Thorbjorn - Kadang-kadang Anda hanya perlu melakukan apa yang diinginkan pelanggan meskipun jika ada tenggat waktu. Klien Anda tidak akan terlalu memahami jika ia kehilangan pendapatan bisnis senilai $ 15.000 karena Anda hanya ingin membersihkan kesalahan kapitalisasi. Sayangnya, mencoba menghilangkan 100% hutang teknis tidak selalu memungkinkan. Ini akan sama dengan menunggu 40 tahun untuk menabung cukup uang untuk membeli rumah impian Anda alih-alih mengambil hipotek. Tentu, Anda akan bebas dan jelas, tetapi Anda akan menghabiskan seluruh hidup Anda berurusan dengan tuan tanah yang teduh.
jmort253

Proyek sumber terbuka berbeda dengan proyek laba. Banyak proyek open source mampu memiliki standar yang lebih ketat karena tidak selalu ada untung / rugi. Proyek kepemilikan memiliki tujuan yang berbeda, dan terkadang tujuan bisnis tersebut diutamakan. Saya tidak mengatakan kode tidak boleh sesuai, hanya saja kadang-kadang Anda hanya perlu melakukan apa yang harus Anda lakukan dan memiliki disiplin untuk kembali dan memperbaiki masalah setelah penyebaran.
jmort253

25

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.


2
+1 Anda berfokus pada hubungan dan emosi. Pemrogram yang bekerja dengan Anda terdengar sangat kering tetapi mereka hanya berfokus pada masalah kode. Ini cukup umum di lingkungan pemrograman tempat saya bekerja. Saya pernah melihat ini terlepas dari jenis kelaminnya.
Michael Durrant

14

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. :)


Ini menimbulkan banyak poin bagus.
sevenseacat

13

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.


1
Mencoba mengikuti beberapa "standar" ke "T" ketika seseorang berurusan dengan dorks seperti yang dia jelaskan tidak akan banyak gunanya. Ini akan menjadi argumen tanpa akhir tentang definisi dan semantik.
MrDatabase

4
@MatDatabase Mereka tidak terdengar seperti dorks bagi saya. Sedikit pilih-pilih, mungkin, tetapi iblis sering dalam detail dan setelah Anda mulai menyelinap standar Anda, seluruh aplikasi Anda bisa menurun dengan cepat.
Adam Lear

3
Memang benar bahwa standar harus dihormati. Namun ia jelas menunjukkan bahwa itu bukan standar (pengembang sebelumnya tidak mematuhinya). Oleh karena itu rekan kerjanya memaksakan "standar" padanya (tanpa mengatakan sesuatu seperti "hei lihat ... kita tahu itu tampaknya tidak konsisten tetapi kami benar-benar berusaha untuk meningkatkan basis kode kami") adalah munafik dan tidak membantu. Ketika rekan kerja bertindak seperti ini, Anda perlu mengambil pendekatan yang berbeda dan lebih cerdas.
MrDatabase

@ user15859: jika Anda merujuk pada jawaban saya, itu sama sekali bukan maksud saya. Saya yakin saya mengatakan hal yang persis sama dengan yang dikatakan Anna dalam jawabannya. Tidak ada pelanggaran yang dimaksudkan. Pelanggaran standar yang Anda sebutkan penting untuk pemeliharaan jangka panjang, dan ambiguitas apa pun dalam lingkup penerapan standar harus diselesaikan dengan pimpinan tim Anda. Jika Anda malas Anda tidak akan memposting di sini. Jika Anda tidak kompeten Anda tidak akan terlalu peduli. Saya tidak percaya Anda adalah salah satu dari mereka.
Steven A. Lowe

1
Saya pikir dia merujuk pada apa yang dikatakan Woot4Moot ketika dia menggunakan "kemalasan dan ketidakcakapan" sebagai ungkapan dalam komentarnya. Saya pikir jawaban Anda baik-baik saja karena memberi OP beberapa jalan dan ruang untuk mengambil tindakan berdasarkan interpretasinya tentang apa yang sebenarnya terjadi.
jmort253

10

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.


1
Saya akan komentar kedua tentang "Aku akan sampai nanti". Jika saya memiliki nikel untuk setiap kali saya mendengarnya, yah, saya tidak akan berada di sini mengetikkan komentar ini. :-)
Eric King

Untuk. Net ada gaya polisi. Nyalakan, sehingga kode tidak akan membangun sampai StyleCop bahagia. Ini menghilangkan subjektivitas manusia adalah intimidasi tenaga kerja. Anda lihat, teknologi dapat membantu Anda memutuskan apakah Michael Phelps adalah # 1 atau # 2. Namun, dalam figure skating, figurekating.about.com/od/famousskaters/tp/scandals.htm Menjadi seorang pemimpin tim seharusnya bukan tentang power-tripping. Seharusnya tidak ada favorit [dis-] dalam tim. Orang harus berhati-hati untuk memastikan bahwa kesan seperti itu tidak terbentuk. Salah satu cara yang baik untuk melakukannya adalah dengan mengaktifkan aturan yang akan memeriksa kode dan memberi Anda jawaban yang tidak bias.
Pekerjaan

3

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.


1

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.


0

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!


1
Temukan pekerjaan itu sebelum Anda berhenti, banyak manajer perekrutan bahkan tidak akan mewawancarai jika Anda tidak bekerja.
Woot4Moo

-2

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.


2
Ini sepertinya tidak "kejam"; konsistensi adalah komponen penting dalam pemeliharaan, pemeliharaan adalah komponen penting dalam kualitas, dan perangkat lunak berkualitas memiliki peluang pengiriman yang lebih tepat waktu dan biaya lebih murah daripada 'kode kompromi'. Mungkin menggembirakan bahwa sekitar 80% perusahaan perangkat lunak ingin sekali mengkompromikan kualitas dan menanggung akibatnya, sehingga sepertinya tidak ada kekurangan kesempatan kerja "non-kejam". :)
weberc2

1
Saya tidak ingin bekerja di lingkungan di mana konvensi dasar tidak ditegakkan. Jika sebuah proyek menyerah pada membela pedoman pengkodeannya, itu akan menjadi tak terpelihara dalam jangka panjang. Terutama penamaan variabel bukan hal kecil: Tidak peduli berapa banyak kode yang ada disebut matriks tertentu A, saya tidak akan pernah menerima komit yang memanggil matriks lain Buntuk konsistensi. Tentu saja, saya tidak tahu apa yang dimaksud OP dengan "meniru [...] nama-nama yang digunakan di tempat lain" tepatnya, namun, mengingat kualitas beberapa kode yang saya lihat, mungkin di sepanjang garis ini.
cmaster
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.