Bagaimana cara menangani kode 'hampir bagus' dari pengembang junior? [Tutup]


95

Saya mendapat pertanyaan tentang pengelolaan tim. Saat ini saya sedang berurusan dengan pengembang junior yang bekerja jarak jauh dari pabrik pengkodean. Lelaki itu terbuka terhadap kritik dan mau belajar, tetapi saya ragu seberapa banyak saya harus mendorong beberapa hal.

Saat ini ketika sesuatu lurus dan jelas merupakan pelanggaran praktik yang baik: seperti pelanggaran SRP, objek Tuhan, nama yang tidak bermakna untuk metode atau variabel; Saya tunjukkan apa yang harus dia perbaiki dan mencoba menjelaskan mengapa itu salah.

Pertanyaan saya adalah: kapan saya berhenti? Saat ini jika ada beberapa pelanggaran kecil pada gaya pengkodean seperti nama variabel dalam bahasa yang salah (tim sebelumnya menggabungkan bahasa Spanyol dan Inggris dan saya mencoba untuk memperbaikinya), atau beberapa masalah struktural kecil saya melepaskan dan memperbaikinya jika Saya punya waktu luang atau kebetulan perlu memodifikasi kelas yang bermasalah. Saya merasa ini bagus untuk moral tim jadi saya tidak mendorong kembali kode tentang apa yang bagi pemula mungkin tampak seperti detail kecil, yang bisa sangat membuat frustasi, tapi saya juga khawatir kalau terlalu 'lunak' akan mencegah orang itu dari belajar bagaimana melakukan beberapa hal.

Bagaimana cara saya menyeimbangkan batas antara mengajar pria itu dan tidak membakarnya dengan kritik terus-menerus? Untuk seorang junior bisa membuat frustasi jika Anda memintanya untuk mengulang hal-hal yang menurutnya berfungsi.


7
Berapa banyak waktu yang Anda habiskan untuk memastikan dia tahu apa harapan Anda?
Blrfl


13
@gnat Saya pikir ini bukan kasus yang sama, masalah saya bukanlah kita melebihi perkiraan atau kode berlebihan. Sebenarnya kita lebih cepat dari jadwal. Pertanyaan saya adalah bagaimana menyeimbangkan garis antara mengajar lelaki itu dan tidak membakarnya dengan kritik terus-menerus, bagi seorang junior bisa membuat frustasi jika Anda menyuruhnya mengulangi hal-hal yang menurutnya berfungsi.
Zalomon

4
Saya mengedit ini untuk membuatnya lebih pada topik. Saya percaya ini berbeda dari pertanyaan duplikat yang ditautkan juga.
enderland

3
Beberapa hal yang saya coba bantu dengan ini: memasangkan pemrograman - mendapatkan wawasan tentang bagaimana ia bekerja dan berpikir dan mungkin mengekspos dia untuk proses pemikiran Anda saat Anda membaca kode Anda. Temukan tugas-tugas yang dia kuasai - kadang-kadang Anda akan mendapatkan hasil yang lebih baik melemparkan banyak bug kecil kepadanya vs pekerjaan fitur besar. Desain teknologi - beri dia celah pertama dalam mendesain perangkat lunak tanpa menyentuh kode. Ini membuatnya berpikir tentang struktur dan proses vs meletakkan kepalanya ke bawah dan mengeluarkan kode. Terakhir, semoga sukses. Kadang-kadang dibutuhkan lebih banyak ketekunan dari yang diharapkan tetapi layak jika ia menjadi produktif.
Sandy Chapman

Jawaban:


84

Jika menurut Anda kode tersebut harus diperbaiki sebelum bergabung, beri komentar. Lebih disukai dengan "kenapa" supaya dev bisa belajar.

Perlu diingat kode dibaca jauh lebih sering daripada yang tertulis. Jadi hal-hal yang tampak "minor" sebenarnya bisa sangat penting (nama variabel misalnya).

Namun, jika Anda mendapati diri Anda membuat komentar yang terasa membosankan, mungkin pertimbangkan:

  • Haruskah proses CI Anda menangkap ini?
  • Apakah Anda memiliki "panduan pengembang" yang jelas untuk referensi (atau semuanya didokumentasikan di kepala Anda)?
  • Apakah komentar ini benar-benar berkontribusi pada kualitas kode?

Banyak orang mengorbankan produktivitas di altar proses atau kesempurnaan. Hati-hati kamu tidak melakukan ini.

Cobalah untuk mengunjungi kolega Anda secara langsung jika memungkinkan. Atau gunakan panggilan video. Membangun hubungan membuat kritik (bahkan review kode) lebih mudah dikelola.

Jika Anda menemukan bahwa sepotong kode memiliki terlalu banyak masalah, minta ulasan dengan potongan kode yang lebih kecil. Perubahan tambahan lebih cenderung untuk menghindari beberapa masalah desain yang lebih signifikan, karena mereka secara definisi lebih kecil.

Tetapi sama sekali tidak menggabungkan hal-hal dan kemudian kembali dan memperbaikinya. Ini agresif pasif dan jika pengembang menemukan Anda melakukan ini, Anda akan membunuh moral mereka.


65
@ 9000 sungguh menakjubkan betapa sering orang frustrasi tentang orang yang tidak berkontribusi sesuai dengan standar mereka, ketika standar itu bahkan tidak didokumentasikan di mana pun ...
enderland

32
Nama variabel sangat penting dalam menggambarkan maksud kode; nama metode / fungsi, terlebih lagi. Mendapatkan nama yang tepat bukanlah perfeksionisme yang tidak berguna, itu diperlukan untuk perawatan.
9000

9
@ALomon Pasti menyebutkannya kepadanya; lebih dari itu, ubah menjadi diskusi. Sebagai junior dev, saya bekerja dengan beberapa senior devs yang berbeda. Pengalaman terbaik saya adalah dengan seorang dev yang berbicara kepada saya melalui semua rekomendasinya - bahkan yang "kecil" seperti nama yang sedikit lebih baik untuk variabel. Saya tidak hanya belajar satu ton darinya, tetapi saya merasa sangat baik karena dia mendengarkan proses pemikiran saya dan termasuk saya dalam diskusi - itu membuat saya ingin dia meninjau kode saya lebih banyak sehingga saya bisa belajar lebih banyak. (lanjutan)
Dj18

6
@Zalomon (lanjutan) Di sisi lain, seorang dev senior yang membuat perubahan di belakang punggung saya (bahkan jika Anda mengatakan kepadanya setelah itu, itu masih di belakang punggungnya) benar-benar melemahkan semangat - itu membuat saya merasa seperti saya bekerja dengan seorang autokrat yang saya harus mencari cara untuk menyenangkan.
dj18

6
Pengalaman saya (kecil) tentang mentoring junior devs menunjukkan bahwa membuat seorang dev berpikir keras tentang nama yang tepat dan mengekspresikan tujuan data dalam nama variabel bernilai sementara. Ini membantu dev benar-benar memahami apa yang dilakukan kode mereka, dengan cara yang jauh lebih sedikit dari biasanya. Kadang-kadang membuat mereka menemukan kesalahan logis dalam kode yang terlibat, atau hanya cara yang lebih baik untuk mengekspresikan sesuatu. (Hal yang sama berlaku untuk saya; perbedaannya adalah saya memiliki disiplin yang diinternalisasi, terima kasih kepada pengulas kode ketat yang saya miliki di masa lalu.)
9000

19

Simpan kritik pada kode daripada penulis.

Pekerjaan apa pun yang dihasilkan disertai dengan ikatan emosional yang melekat. Pertimbangkan untuk mengurangi ini dengan melepaskan kode dari penulis sebanyak mungkin. Kualitas kode harus secara konsisten ditetapkan sebagai tujuan bersama yang Anda berdua hadapi, bersama, alih-alih menjadi titik gesekan di antara Anda.

Salah satu cara untuk mencapai ini adalah dengan bijak memilih kata-kata Anda. Walaupun individu-individu STEM suka menganggap diri mereka sebagai orang yang sangat logis, emosi adalah bagian dari sifat manusia. Kata-kata yang digunakan bisa menjadi perbedaan antara perasaan terluka atau terhindar. Mengatakan "Nama fungsi ini akan lebih konsisten dengan konvensi jika itu dalam bahasa Inggris" lebih disukai daripada "Anda menulis nama fungsi ini salah dan harus dalam bahasa Inggris." Sementara yang terakhir masih jinak dan sendirian akan tampak baik-baik saja, dibandingkan dengan kesalahan sebelumnya menjadi jelas - ketika mempersiapkan apa yang harus dikatakan baik secara langsung atau email memeriksa apakah konteks Anda, kata-kata dan fokus adalah pada masalah daripada orangnya .

Bahasa tubuh

Sementara kata-kata itu penting, sebagian besar komunikasi bersifat non-verbal. Perhatikan bahasa tubuh, bahkan seluk-beluk yang tampaknya tidak signifikan seperti orientasi materi misalnya. Banyak interaksi senior-junior terjadi tatap muka, namun pendekatan berdampingan akan jauh lebih kondusif untuk hasil yang Anda inginkan.

Berikan umpan balik positif yang jujur

Banyak penelitian menunjukkan bahwa informasi dipelajari lebih cepat dan dipertahankan lebih baik ketika kita menghargai perilaku yang baik daripada menghukum yang buruk. Terkadang hanya dengan memperhatikan bahwa kinerjanya telah ditingkatkan dengan "pekerjaan bagus" yang sederhana atau yang lebih spesifik "Saya perhatikan belakangan ini bahwa gaya Anda telah mencocokkan standar kami dengan tee, pekerjaan yang hebat!" bahkan melengkapi pengakuan peningkatan ini dengan meminta mereka, pada gilirannya, memberi nasihat kepada orang lain tentang masalah yang telah mereka ubah dapat membuat semua perbedaan bagi dev junior Anda dan pekerjaannya.


2
Pada titik bertele-tele: ketika Anda harus menggunakan kata ganti orang, cukup memilih "kami" dan bukan "Anda" juga menghilangkan kritik, dalam pengalaman saya di kedua sisi tinjauan kode.
Josh Caswell

6

Lelaki itu terbuka terhadap kritik dan mau belajar, tetapi saya ragu seberapa banyak saya harus mendorong beberapa hal.

Dorong semua yang Anda bisa. Jika lelaki itu sedang belajar, dan tugas Anda untuk meninjau kodenya, Anda berdua akan mendapat banyak keuntungan jika dia melakukan pekerjaan dengan baik.

Itu berarti lebih sedikit kode bagi Anda untuk ditinjau di masa depan, dan mungkin memberikan target perekrutan tim Anda.

Juga, jika Anda menahan diri, Anda tidak membantu, tetapi merendahkan.

Hanya dengan fakta bahwa Anda memposting pertanyaan Anda di sini, menanyakan apakah Anda melakukan terlalu banyak, sudah menandatangani saya bahwa Anda tidak memerlukan saran khusus ini, tetapi untuk orang lain, ini dia: Ingatlah bahwa berusaha keras tidak berarti menjadi brengsek.

Menjadi seorang mentor bukanlah tugas yang mudah. Anda juga harus memberikan ruang baginya untuk membuat beberapa kesalahan dan memperbaikinya sendiri, pastikan bahwa dia akan melakukan itu di suatu tempat yang tidak melakukan kerusakan nyata.


5

Berdasarkan uraian Anda, saya akan membiarkannya di: "ini bagus. Ada beberapa hal yang akan saya lakukan berbeda tetapi mereka tidak terlalu penting."

Seperti yang tampaknya Anda pahami, kritik memiliki biaya dan jika Anda menghabiskan banyak waktu untuk detail yang picik, itu menjadi masalah moral. Idealnya semua standar pengkodean diperiksa secara otomatis dan Anda tidak dapat membangun kecuali Anda mengikuti mereka. Ini adalah penghemat waktu yang sangat besar dan memungkinkan Anda memulai bisnis. Jika Anda menyimpan kritik Anda untuk 'hal-hal yang penting', saran Anda akan memiliki dampak yang jauh lebih besar dan Anda akan dipandang sebagai mentor yang dihargai. Sangat penting untuk membedakan antara hal-hal yang tidak baik dan hal-hal yang tidak persis seperti yang Anda lakukan.

Saya percaya pada konsep momen yang bisa diajar . Jika pengembang memiliki kapasitas mental yang cukup, dia mungkin meminta perincian tentang apa yang akan Anda lakukan secara berbeda. (S) dia mungkin tidak dan tidak apa-apa. Orang-orang terbakar dan di awal karir membutuhkan banyak energi mental untuk mencapai hal-hal yang kelihatannya sederhana nanti.


Salah satu cara untuk menghindari siklus ulasan kode yang tak berkesudahan adalah dengan membuat perubahan kecil. Tidak ada permintaan tarik yang sangat kecil jika membuat perubahan yang menguntungkan (saya mendapat bagian dari PR 1-char). Semakin kecil semakin baik. Tanpa ampun memotong ruang lingkup tiket yang diserahkan kepada para biarawan yunior, dan membuat mereka menyelesaikan pekerjaan. Setelah mereka pandai dalam keseluruhan proses baca-mengerti-kode-uji-review-penyebaran, cakupannya bisa meningkat.
9000

1
Saya tidak berpikir itu ide yang baik untuk memberitahu dev "mereka tidak terlalu penting" jika mereka cukup penting bagi OP untuk kembali dan berubah nanti.
enderland

3
@enderland Dalam pengalaman saya, tidak ada yang namanya kode sempurna. Anda selalu dapat meningkatkannya nanti jadi itu tidak benar-benar relevan di sini. OP mengatakan ini adalah hal untuk "memperbaikinya jika saya punya waktu luang". Ada dua macam masalah. Hal-hal yang harus diperbaiki dan hal-hal yang tidak perlu diperbaiki. Yang terakhir mungkin diperbaiki atau tidak dan ini sepertinya masuk dalam kategori itu. Itu adalah panggilan penilaian pada tingkat tertentu, tetapi saya pikir jika, sebagai seorang dev yang berpengalaman, Anda tidak yakin itu layak disebut sebagai harus diubah, mungkin tidak.
JimmyJames

5

Saya akan mempertimbangkan menerima karyanya ketika itu dapat diterima, tidak sempurna. Dan kemudian tugas selanjutnya adalah setelah diskusi untuk merefleksikannya segera dengan membuat semua perubahan kecil tapi penting yang Anda inginkan.

Jadi ketika pekerjaan diterima pertama kali, pesan Anda adalah bahwa itu tidak buruk, dan beberapa tempat akan menerimanya sebagai cukup baik - tetapi bukan tempat di mana Anda ingin menjadi pengembang junior yang ingin mempelajari perdagangannya dengan baik.

Jadi Anda tidak mengatakan "Saya menolak pekerjaan Anda karena itu tidak cukup baik". Anda mengatakan (a) "Saya menerima pekerjaan Anda karena itu cukup baik", dan kemudian (b) "Tapi saya ingin itu lebih baik".


3
Atau "(b) Dan aku tahu kamu bisa melakukan yang lebih baik." Jika dia bertanya "ajari aku", kamu tahu dia di jalan yang benar. :)
Machado

1
Di posisi saya sebelumnya, kami menggunakan Stash / BitBucket sebagai alat peninjau kode kami. Itu memiliki opsi untuk memblokir permintaan tarikan dengan menetapkan tugas yang luar biasa atau langsung menolak permintaan tarikan. Saya hanya menggunakan ini untuk perubahan yang diperlukan. Jika ada perubahan kosmetik (mis. Keterbacaan kode minor, struktur data yang lebih baik, refactoring) Saya akan menunjukkannya dengan saran, tetapi tidak menambahkan tugas pemblokiran, lakukan jika Anda punya waktu. Ini juga mencegah tenggat waktu yang hilang karena keributan kecil.
Hand-E-Food

4

Pertanyaan terbuka cukup luas, tapi di sini ada beberapa ide.

  1. Ulasan rekan (oleh pengembang junior)

    Cara terbaik bagi seseorang untuk belajar cara "benar" adalah dengan melihat orang lain melakukannya. Apakah semua pengembang Anda melakukan tinjauan kode? Mungkin bukan ide yang buruk untuk membiarkan pengembang junior Anda melakukannya juga (walaupun Anda juga harus meminta setidaknya satu ulasan dari pengembang senior juga). Dengan begitu dia akan melihat coders yang baik beraksi, ditambah dia akan mengamati bahwa ada ulasan review diarahkan pada insinyur selain dirinya sendiri, yang berarti bahwa itu bukan masalah pribadi.

  2. Umpan balik awal / ulasan tugas

    Izinkan pengembang untuk berpartisipasi dalam pemecahan tugasnya sendiri. Mintalah dia merekam desain yang dimaksudkan dalam catatan tugas, dan kirimkan "tinjauan kode" tanpa perubahan dan hanya tugas. Dengan begitu Anda dapat meninjau rencananya sebelum ia menulis satu baris kode. Setelah tugasnya ditinjau, ia dapat memulai pengkodean (setelah itu ia akan mengirimkan ulasan kode lain). Ini menghindari situasi demoralisasi di mana pengembang telah menulis banyak hal dan Anda harus mengatakan kepadanya untuk menulis ulang.


3
Saya suka ide peer review, untuk saat ini hanya kami berdua di tim tapi saya bisa minta dia meninjau kode saya. Jika dia dapat memahami apa yang saya lakukan dan menemukan beberapa ketidaksesuaian, itu bisa membantu, baik untuk kualitas kode dan moralnya. Itu membantu saya ketika saya belajar bahwa saya bukan satu-satunya yang membuat kesalahan +1
Zalomon

2

Jika kode secara objektif melanggar standar tertulis, tidak ambigu, maka saya pikir Anda harus terus mendorong kembali sampai setiap masalah diperbaiki. Tentu, itu mungkin sedikit menjengkelkan bagi pengembang yang melakukan beberapa kali pertama, tetapi mereka mungkin juga mempelajari pedoman lebih cepat daripada yang lebih baru.

Juga, jika Anda mengizinkan beberapa pelanggaran standar di sana-sini maka mereka akan menetapkan preseden buruk - lihat teori broken windows . Juga, jauh lebih mudah untuk mengingat untuk mengikuti standar jika sudah diterapkan secara konsisten ke basis kode. Jadi sungguh, semua orang menang, termasuk pengembang junior yang dimaksud.

Saya tidak berpikir moral adalah masalah besar selama standar pengkodean ditulis. Hanya jika itu menjadi lebih subjektif "baik, saya akan melakukannya secara berbeda" -tulis, maka Anda harus khawatir, karena pendekatan pengembang mungkin sama validnya.


2

Pertimbangkan untuk mengadopsi alur kerja peninjauan kode, di mana pengembang memposting komit yang diajukan ke alat seperti Github Pull Requests atau Phabricator Diffusion dan mendapatkan sign-off rekan sebelum mendaratkan perubahan mereka ke cabang master bersama.

Dengan cara ini, alih-alih secara surut mengkritik atau meminta seseorang untuk mengulangi apa yang sudah dilakukan, pekerjaan belum selesai sampai melewati ulasan sejawat. Bolak-balik dengan teman sebaya adalah bagian dari proses rekayasa perangkat lunak seperti bolak-balik dengan kompiler.

Anda dapat memposting kekhawatiran Anda sebagai komentar pada baris tertentu dan telah membuat diskusi tentang mereka. Dia dapat melakukan hal yang sama pada kode Anda. Diskusi tetap fokus pada perubahan kode yang diusulkan spesifik, dan bukan kinerja atau kompetensi seseorang secara umum.

Bahkan insinyur senior yang brilian di perusahaan saya berterima kasih ketika ulasan kode menangkap kesalahan ketik atau memaksa mereka untuk membuat semuanya lebih jelas. Sangat normal bagi karyawan baru untuk membutuhkan lebih banyak putaran iterasi. Seiring waktu, Anda mulai memperbaiki secara refleks jenis masalah yang Anda tahu akan menarik komentar sebelum memposting perbedaan. Memperoleh persentase yang lebih tinggi dari perbedaan yang Anda terima pada percobaan pertama adalah bagaimana Anda tahu Anda mengalami peningkatan.


1

Saya tidak mendorong kembali kode tentang apa yang bagi pemula mungkin tampak seperti detail kecil, yang bisa sangat membuat frustasi, tetapi saya juga khawatir bahwa menjadi terlalu 'lunak' dapat mencegah orang itu belajar cara melakukan beberapa hal.

Ini adalah kemungkinan nyata dan kekhawatiran yang valid. Tanyakan pengembang bagaimana perasaan mereka tentang hal itu.


Sebenarnya dia bilang dia merasa bodoh. Saya mencoba untuk tetap mengkritik di sisi positif dan saya mengatakan kepadanya bahwa saya senang dengan pekerjaannya, saya juga menjelaskan kepadanya bahwa saya memiliki keraguan semacam ini ketika saya mulai, tetapi saya harus berasumsi bahwa beberapa umpan balik tentang memberi dia untuk meningkatkan pekerjaannya itu salah.
Zalomon

2
Jelaskan bahwa Anda tidak akan membuang waktu Anda mengkritik kode-nya dengan hati-hati jika Anda tidak mengharapkannya menghasilkan menjadi programmer yang lebih baik. Dan berhati-hatilah dalam membedakan antara "Anda harus memperbaikinya agar kode ini dapat diterima" dan "inilah sesuatu yang dapat Anda lakukan lebih baik lagi lain kali". Memberikan sejumlah besar kritik mendalam dan akurat adalah hadiah terbesar yang dapat Anda berikan kepada seorang programmer junior. Kegagalan untuk melakukan itu membuat mereka menjadi programmer yang lebih buruk. Kritik harus mulai meruncing. Anda hanya perlu membuat setiap kesalahan satu kali, mungkin dua kali, dan hanya ada begitu banyak kesalahan.
David Schwartz

1

Dengan asumsi bahwa Anda memiliki beberapa permintaan alur kerja atau tinjauan kode tarik, dan tampaknya Anda lakukan, saya akan merekomendasikan mencatat hal-hal yang "tidak kritis" atau "disukai".

Jika Anda melihat PR dalam keadaan yang mirip dengan yang Anda gambarkan, dengan beberapa masalah gaya bahasa kecil atau membutuhkan refactoring yang tidak kritis, tinggalkan komentar, tetapi jangan ragu untuk menyetujuinya. Mengatakan sesuatu seperti, "Di masa depan, mungkin mencoba menghindari nama metode seperti ini demi sesuatu seperti deskriptifMethodName" mendokumentasikan pendapat Anda tanpa memaksa mereka untuk mengubahnya, atau memblokir perkembangan mereka.

Sekarang mereka tahu preferensi Anda, dan jika mereka berusaha meningkatkan, semoga akan melihat situasi seperti itu di masa depan. Itu juga membuat pintu terbuka bagi mereka untuk benar-benar mengubahnya pada saat itu, seandainya mereka setuju dengan Anda dan melihatnya sebagai cukup kritis.


0

Saya berurusan dengan pengembang junior yang bekerja jarak jauh dari pabrik pengkodean.

Sayangnya, itu bukan situasi yang ideal: satu programmer canggih yang bertanggung jawab atas satu programmer pemula, dengan pemisahan geografis. Tidak mengherankan bahwa ada beberapa ketegangan, tetapi perbedaan tersebut dapat dikurangi.

Saya ingin tahu, apa maksud Anda dengan "pabrik pengkodean"? Terminologi itu, bagi saya, menunjukkan sikap meresahkan yang mungkin memperburuk beberapa masalah manajemen yang telah Anda sebutkan.

... pelanggaran SRP, objek Dewa, nama yang tidak bermakna untuk metode atau variabel; Saya tunjukkan apa yang harus dia perbaiki dan mencoba menjelaskan mengapa itu salah.

Masalahnya, saya pikir, adalah bahwa pengembang junior Anda memuntahkan kode tanpa melalui proses desain yang tepat. Ini adalah kegagalan Anda, sebagai manajer dan pengembang senior, untuk memberikan panduan dan mengajarkan kebiasaan pengembangan perangkat lunak yang baik. Anda dapat mencegah penulisan kode buruk jika Anda pertama kali bekerja sama untuk membuat sketsa kerangka. Itu akan lebih baik daripada mengkritik dan menulis ulang kode setelah kode itu diproduksi, baik dari segi efisiensi maupun moral.

Anda mungkin harus menyesuaikan kembali alur kerja Anda. Sepertinya Anda saat ini mengharapkan dia untuk mengirimkan produk kepada Anda. Yang Anda butuhkan adalah kolaborasi yang lebih dekat, sehingga Anda dapat memberikan panduan di setiap langkah pengembangan. Bicara tentang desain dan antarmuka sebelum pengkodean dimulai. Ketika pengkodean sedang terjadi, lakukan pemeriksaan lebih sering, untuk menangkap masalah lebih awal. Jika memungkinkan, coba pasangkan pemrograman, melalui berbagi layar dengan saluran audio.

Semua ini akan membutuhkan lebih banyak upaya di pihak Anda, tetapi mungkin akan bermanfaat, mengingat hubungan bermasalah yang saat ini Anda miliki.


-1

Jika ini merupakan pelanggaran terhadap standar pengkodean, tunjukkan kepadanya di mana ia berada sehingga ia tahu. Jika Anda harus terus menunjukkan kesalahan yang sama padanya, maka Anda mungkin memiliki masalah dengan seseorang yang tidak dapat mematuhi aturan atau menolaknya. Jangan gunakan waktu luang Anda untuk memperbaiki kesalahan. Orang ini harus memperbaiki kesalahan mereka sendiri sehingga mereka tidak membuatnya lagi.

Selalu beri tahu mereka apa yang mereka lakukan dengan benar dan bagaimana mereka dapat meningkatkan waktu berikutnya. Kami selalu dapat menjadi lebih baik di beberapa area. Umpan balik sangat penting untuk menjadi lebih baik dalam hal apa pun.


-1

Gagasan lain untuk berurusan dengan "terlalu banyak kritik" adalah melakukan tugas sendiri dari waktu ke waktu, dan biarkan pengembang junior melakukan review kode untuk Anda. Ini setidaknya memiliki dua keuntungan:

  • mereka dapat belajar bagaimana hal-hal harus dilakukan.
  • dalam kasus ketika ada beberapa solusi bagus atau nama variabel saya menerima saran dari pendekatan yang berbeda tetapi (hampir?) sama bagusnya. Ketika saya memperbaiki kode saya karena komentar seseorang, saya menunjukkan kepada orang-orang bahwa mereka dihormati dan kritik selalu hanya menyangkut kode - terlepas dari siapa penulisnya.

Saya akan senang mengetahui apa yang salah dengan posting saya. Downvote adalah tanda pertentangan yang bisa dimengerti, tapi hapus suara ?!
BartoszKP
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.