Haruskah kita bertahan dengan karyawan yang masih menulis kode buruk setelah bertahun-tahun? [Tutup]


13

Saya mengajukan pertanyaan ini ke programmer C ++ karena: a) Hanya seorang programmer C ++ yang dapat menilai manfaat teknis dari contoh-contoh; b) Hanya seorang programmer yang akan merasakan temperamen programmer lain yang menulis kode seperti ini.

SDM dan direktur menyadari ada masalah hanya karena mereka melihat bukti di lapangan. Ini panggilan saya apakah kami memberi programmer pertanyaan lebih banyak waktu. Banyak kesalahan berada pada level yang sangat mendasar - pertanyaan saya (kepada programmer) adalah apakah seseorang yang mengaku sebagai pengembang senior C ++ harus diberi manfaat keraguan berdasarkan sampel kode mereka saat ini. Non-programmer - bahkan orang-orang di luar pemrograman C ++ - tidak dapat membuat penilaian atas hal ini.

Sebagai latar belakang, saya telah diberi tugas mengelola pengembang untuk perusahaan yang sudah mapan. Mereka memiliki pengembang tunggal yang berspesialisasi dalam semua pengkodean C ++ (sejak selamanya), tetapi kualitas pekerjaannya sangat buruk. Ulasan dan pengujian kode telah mengungkapkan banyak masalah, salah satu yang terburuk adalah kebocoran memori. Pengembang tidak pernah menguji kodenya untuk kebocoran, dan saya menemukan bahwa aplikasi dapat bocor banyak MB hanya dengan satu menit penggunaan. Pengguna melaporkan perlambatan besar, dan pendapatnya adalah, "itu tidak ada hubungannya dengan saya - jika mereka berhenti dan memulai kembali, semuanya baik-baik saja."

Saya telah memberinya alat untuk mendeteksi dan melacak kebocoran, dan duduk bersamanya selama berjam-jam untuk menunjukkan bagaimana alat tersebut digunakan, di mana masalah terjadi, dan apa yang harus dilakukan untuk memperbaikinya. Kami berada 6 bulan di jalur, dan saya menugaskan dia untuk menulis modul baru. Saya meninjaunya sebelum diintegrasikan ke dalam basis kode kami yang lebih besar, dan kecewa ketika menemukan kode buruk yang sama seperti sebelumnya. Bagian yang saya temukan tidak dapat dipahami adalah bahwa beberapa pengkodean lebih buruk daripada amatir. Misalnya, dia menginginkan kelas (Foo) yang dapat mengisi objek kelas lain (Bar). Dia memutuskan bahwa Foo akan memegang referensi ke Bar, misalnya:

class Foo {
public:
    Foo(Bar& bar) : m_bar(bar) {}
private:
    Bar& m_bar;
};

Tetapi (karena alasan lain) ia juga membutuhkan konstruktor default untuk Foo dan, alih-alih mempertanyakan desain awalnya, ia menulis permata ini:

Foo::Foo() : m_bar(*(new Bar)) {}

Jadi setiap kali konstruktor default dipanggil, sebuah Bar bocor. Lebih buruk lagi, Foo mengalokasikan memori dari heap untuk 2 objek lain, tetapi ia tidak menulis destruktor atau menyalin konstruktor. Jadi setiap alokasi Foo sebenarnya bocor 3 objek berbeda, dan Anda bisa membayangkan apa yang terjadi ketika Foo disalin. Dan - itu hanya menjadi lebih baik - dia mengulangi pola yang sama pada tiga kelas lainnya, jadi itu bukan slip satu kali. Seluruh konsep itu salah pada banyak tingkatan.

Saya akan merasa lebih mengerti jika ini berasal dari seorang novis total. Tetapi orang ini telah melakukan ini selama bertahun-tahun dan telah sangat memusatkan pelatihan dan saran selama beberapa bulan terakhir. Saya menyadari dia telah bekerja tanpa mentoring atau ulasan sejawat sebagian besar waktu itu, tapi saya mulai merasa dia tidak bisa berubah. Jadi pertanyaan saya adalah, apakah Anda akan bertahan dengan seseorang yang menulis kode yang jelas-jelas buruk?


15
Jika Anda sudah melihat bahwa dia menulis kode yang buruk, mengapa Anda membiarkannya menulis omong kosongnya selama 6 bulan tanpa mengawasinya?
Billy McNuggets

4
IMO, ketika Anda melihat seseorang melakukan pekerjaan buruk untuk sementara waktu, Anda TIDAK BISA membiarkannya bekerja sendiri walaupun itu hanya debugging / perbaikan. Jika itu adalah keinginan Anda untuk membuatnya tetap di perusahaan Anda, Anda HARUS mengawasi dan SETELAH melihat apakah Anda masih mendapatkan hasil buruk dari dia. Membiarkannya bekerja sendiri selama 6 bulan tanpa menatapnya adalah IMO manajemen yang buruk.
Billy McNuggets

3
@ user94986 Lalu jika Anda menghabiskan waktu bersamanya, menjelaskan kepadanya bahwa kebiasaannya buruk, Anda harus mengawasinya, dan jika tidak ada yang berubah, jangan menunggu 6 bulan untuk berbicara dengannya.
Billy McNuggets

4
Jika dia tidak berpikir bahwa kebocoran memori adalah masalah, tidak ada gunanya mengajarinya cara menghindarinya dan memberikan alat bantu untuk mengatasi hal ini. Masalah utama mungkin adalah bahwa ia salah memahami tujuan dan persyaratan untuk produk tersebut.
maxim1000

2
Pertanyaan ini tampaknya di luar topik karena ini adalah tentang apa yang secara efektif nasihat hukum SDM yang bermasalah bagi kami untuk memberikan yang terbaik.
Insinyur Dunia

Jawaban:


22

Saran saya adalah untuk berhadapan dengannya tentang contoh khusus ini dan melihat apa yang dia katakan. Jika dia menyangkal ada yang buruk dengan kode, maka saya khawatir ada sedikit yang bisa Anda lakukan. Jika dia menerima bahwa dia melakukan kesalahan (bahkan jika dia defensif tentang hal itu), maka setidaknya ada ruang untuk perbaikan. Jika Anda menerima waktu dan upaya untuk meningkatkannya, maka Anda atau seorang programmer senior perlu mendudukkannya dan menyusun kode bersama sampai semua kecenderungan ini diratakan (bersiaplah untuk mendedikasikan orang ini untuk setidaknya 1 bulan waktu).

Seorang programmer yang buruk, saya biasanya dapat bekerja dengan, tetapi seorang programmer yang tidak dapat meningkatkan, saya tidak bisa.


12
+1 untuk "Seorang programmer yang buruk, saya biasanya dapat bekerja dengan, tetapi seorang programmer yang tidak dapat meningkatkan, saya tidak bisa."

Ya, juga, aku akan membiarkan pria itu tahu itu cukup serius. Sepertinya dia belum diberitahu atau belum mengakui bahwa ada masalah selama bertahun-tahun. Datanglah ke percakapan yang siap menunjukkan contoh hal-hal yang seharusnya tidak dilakukan dan bagaimana hal itu berdampak pada kualitas aplikasi. Jika dia masih tidak mau mempermasalahkan kodenya, saya mungkin akan membiarkannya pergi. Dan saya mungkin tidak akan memberinya banyak waktu untuk berakting bersama jika dia melakukannya. Anda pasti perlu menggarisbawahi bahwa masa depannya di perusahaan dipertaruhkan dan bahwa ia kurang dalam keterampilan yang cukup penting untuk seorang C + + dev.
Erik Reppen

@ErikReppen Saya setuju, tapi saya juga berpikir programmer bisa menjadi tipe orang yang paling keras kepala di dunia. Jika Anda mendorong terlalu keras, ia mungkin menyangkal masalah dengan kode-nya hanya karena defensif. Saya pikir ini penting untuk menekankan gentingnya situasi, tetapi saya masih akan mencoba untuk bersimpati dengan dia, "Saya kebetulan melihat kesalahan kecil ini. Apakah Anda kebetulan menangkapnya juga? Apakah Anda mengira Anda melakukan kesalahan yang sama di daerah programmu? "
Neil

@ Neil Satu-satunya jalan melalui dinding keras kepala adalah tendangan di pantat. Dan saya berbicara dari pengalaman sebagai sisi keras kepala dari persamaan itu. Yang mengatakan, jika ini adalah yang pertama dia dengar ada masalah dengan kodenya, ya, saya akan sedikit lebih lembut tetapi sepertinya mereka sudah mencoba mengomunikasikan masalah setidaknya sekali sebelumnya
Erik Reppen

@ErikReppen Mungkin, tetapi Anda berisiko dia bugar hanya untuk melepaskan Anda dari ekornya. Pada tingkat itu, Anda mungkin juga berkata "Bangun, atau Anda dipecat." Setidaknya pendekatan ini mencari tahu apakah dia sadar akan kesalahannya.
Neil

18

Jadi pertanyaan saya adalah, apakah Anda akan bertahan dengan seseorang yang menulis kode yang jelas-jelas buruk?

Tidak. Saya akan memecat pengembang C ++ profesional yang tidak memiliki pemahaman dasar tentang manajemen memori.

Jika seseorang datang dari Jawa atau C # atau sesuatu, saya akan memberi mereka sedikit lattitude, tapi ini murni ketidakmampuan.


9
Saya tidak mengerti bagaimana jawaban ini dapat di-upgrade. Memecat seseorang bukanlah masalah yang harus dianggap enteng.
Florian Margaine

3
@FlorianMargaine - Tentu, tapi sepertinya ini kasus yang jelas. Berapa jumlah karyawan ini yang menyebabkan perusahaan kehilangan penjualan karena kebocoran memori atau kerentanan keamanan? Berapa banyak waktu yang hilang untuk menguji / memperbaiki omong kosong ini? Berapa banyak dalam memiliki OP menjaga mereka? Berapa banyak yang membuat programmer lain menderita dari kehadirannya semata ? Kecuali jika karyawan memiliki jumlah pengetahuan domain (atau pemerasan) yang tidak masuk akal, tidak mungkin mengganti mereka lebih mahal.
Telastyn

1
@FlorianMargaine, Karyawan jenis ini adalah yang tidak cukup dipecat, itu melumpuhkan perusahaan dalam kesulitan untuk memperbaiki utang teknis. Dikatakan dalam lampu merah besar, "Mereka tidak peduli, jadi mengapa kita harus?". Tahu apa yang ingin dikatakan oleh karyawan yang Anda inginkan? "... tapi aku peduli, jadi aku harus pergi ke tempat yang tidak". Yang buruk sudah tidak peduli, jadi mereka tetap di kantor Anda. Anda HARUS menghapus orang yang merusak produktivitas, lebih dari yang mereka kontribusikan. Ini bukan pilihan yang dianggap enteng, namun itu benar-benar garis yang jelas, kegagalan bertindak adalah tindakan yang jelas.
JM Becker

13

Kami tidak dapat menjawab bagian yang lebih luas dari pertanyaan Anda. Yaitu, sebaiknya Anda mempertahankan atau memecat karyawan itu. Memecat karyawan itu sulit, tapi itu keputusan di luar lingkup komunitas seperti ini.

Anda memperbarui pertanyaan Anda untuk membatasi jawaban pada programmer C ++. Untuk latar belakang / kualifikasi saya: Saya memotong gigi saya di C, dan saya bisa kode dalam C ++, C #, dan Java. Dan saya suka mengejar kondisi balapan di antara utas karena saya pikir itu menyenangkan. Ya, saya "agak" bingung.

Jawaban dan keputusan Anda melingkupi hal ini: Apakah seseorang dapat berubah atau tidak tergantung pada individu dan apakah mereka ingin berubah.

Tapi mari kita mulai dengan beberapa pertanyaan Anda:

  1. Sudahkah Anda bertanya kepadanya tentang kode dan contoh yang Anda sebutkan? Apa kesannya tentang ulasan itu?
  2. Apakah Anda memberinya spesifik selama 6 bulan tentang memahami manipulasi memori dan memastikan kodenya tidak memiliki kebocoran memori?
  3. Apakah Anda memberikan umpan balik yang cukup sering selama 6 bulan tersebut untuk menunjukkan apakah dia membuat kemajuan atau tidak.
  4. Apakah Anda secara eksplisit menyebut bahwa cara pengkodeannya yang lama tidak lagi dapat diterima dalam kode baru?

Anda perlu memastikan Anda bisa mengatakan ya untuk semua pertanyaan itu. Jika tidak, masih ada beban pembuktian bagi Anda untuk berkomunikasi dengannya.

Tanggapannya terhadap ulasan terakhir Anda akan menjadi bagian yang paling jitu.

Jika dia sudah mencoba, dan menunjukkan beberapa tanda kemajuan maka mungkin Anda perlu meninjau proses bimbingan Anda. Jika ada, mungkin Anda perlu mempertimbangkan memasangkannya dengan programmer yang lebih berpengalaman sehingga dia bisa mendapatkan umpan balik langsung saat dia membuat keputusan desain. Saya bukan penggemar pemrograman pasangan, tetapi bisa sangat berguna dalam kasus seperti ini. Terus-menerus mengirimnya pergi untuk membuat lebih banyak revisi kode lama tidak selalu merupakan rute yang praktis untuk belajar.

Jika dia belum berusaha, maka Anda perlu memahami motivasinya lebih baik. Apakah dia tidak mengerti bahwa dia perlu berusaha lebih keras? Apakah dia tidak peduli? Apakah ada area lain di tim di mana keterampilannya akan lebih cocok dan dia lebih tertarik pada hal itu? Jika dia tidak peduli untuk mencoba, maka Anda perlu memahami alasannya.

Dari sana, Anda akan tahu apakah dia ingin berubah dan apakah dia bisa berubah. Tidak ada keinginan untuk berubah sama dengan tidak bisa berubah. Jika ada keinginan dan tingkat kemajuan, maka pertimbangkan untuk mengubah cara Anda merehabilitasi dia.


1
+1 untuk "Terus-menerus mengirimnya pergi untuk membuat semakin banyak revisi kode lama tidak selalu merupakan rute yang praktis untuk belajar"
Bill

+1 untuk paragraf terakhir. Kemajuan yang dicapai oleh seseorang versus usaha yang diinvestasikan dalam membimbing bahwa seseorang sama-sama perlu mempertimbangkan penilaian kinerja.
Marjan Venema

10

Saya khawatir kode buruknya bukan satu-satunya masalah di tim Anda.

  1. Siapa yang mengulas kodenya? Mengapa dia menyelinap pergi tanpa peringatan untuk menerima kode dengan kerentanan kebocoran memori?
  2. Mengapa tes stres tidak menemukan masalah ini? Apakah Anda menggunakannya? Jika ya, mengapa mereka tidak bekerja?
  3. Dia dibiarkan tanpa pengawasan untuk waktu yang lama. Mengapa?
  4. Dia tidak menggunakan alat yang kamu berikan padanya. Bagaimana Anda memotivasi dia untuk mulai menggunakan alat yang tepat?

Anda bilang dia sudah di perusahaan untuk waktu yang lama. Memecat orang seperti itu jarang merupakan ide yang baik (kecuali jika ia adalah tipe karyawan Wally). Pengetahuan mereka tentang kebutuhan klien, produk yang Anda miliki, dll. Seringkali jauh lebih berharga daripada kode yang mereka tulis.

Solusi:

  • pindahkan dia ke QA untuk membiarkan dia belajar apa yang harus dihindari
  • pasangkan pemrograman dengan seseorang yang bisa menunjukkan kesalahannya
  • memperpanjang upaya QA pada kodenya
  • buat dia menulis stress test, jika dia melihat mesin dev-nya hancur setelah membuat dan menghancurkan 10k objek mungkin dia akan belajar
  • beberapa / semuanya di atas :)

3

Membuat keputusan untuk memecat siapa pun adalah keputusan sulit bagi siapa pun untuk membuat. Situasi Anda diperparah oleh beberapa faktor:

  1. Tampaknya pengembang ini telah berada di perusahaan selama beberapa tahun
  2. Pengembang menulis semua kode perusahaan C ++
  3. Tampaknya sebelum Anda, tidak ada yang pernah membahas tingkat kode buruk dengan pengembang
  4. Sebagai manajer baru, Anda tidak tahu siapa / apa yang diketahui pengembang di dalam / tentang perusahaan dan apa konsekuensi politik dari memecat pengembang.

Yang mengatakan Anda telah menghabiskan 6 bulan terakhir menunjukkan kepada pengembang kesalahan dalam caranya dan kode barunya belum membaik.

Pada tahap ini Anda benar-benar perlu memulai beberapa manajemen proaktif sehingga dalam waktu 3 bulan sudah

  • Seorang programmer C ++ yang layak yang tahu apa yang dia lakukan

atau

  • Dihentikan pengembang.

Untuk melakukan ini meskipun Anda harus duduk dengan pengembang, jelaskan apa yang salah dalam penulisan / email, jelaskan bagaimana pengembang dapat meningkatkan dan dengan sangat jelas menyatakan bahwa jika ada peningkatan yang diharapkan tidak terjadi maka ia akan diakhiri dalam 3 bulan.

Anda juga harus sangat jelas bahwa perbaikan diharapkan sejak saat ini untuk sisa pekerjaannya dengan perusahaan dan bukan hanya untuk 3 bulan ngengat!

Anda juga harus memberi tahu manajer Anda sendiri dan Departemen SDM (jika ada).

Selama proses ini, Anda harus secara aktif mengelola pengembang dan meninjau tugas / kode setiap 1-2 hari dan memastikan mereka siap, merinci yang tidak dan menjelaskan apa yang dapat dilakukan untuk memperbaikinya.


1

Entah Anda belum jelas tentang seberapa serius Anda mengambil pengerjaan yang buruk (yaitu mungkin dia melihat waktu apa yang telah Anda habiskan bersamanya sebagai pilihan jika dia ingin meningkatkan daripada kebutuhan mutlak), atau dia memiliki yang sangat buruk sikap yang tidak berkelanjutan. Jika belum jelas bagi pengembang ini bahwa Anda mempertimbangkan posisinya atas masalah ini, maka itu perlu dijabarkan (dengan asumsi kepemimpinan Anda tidak masalah dengan wewenang Anda untuk mengakhiri). Semoga kejutan itu akan membawa perubahan.

Keputusan kepegawaian memiliki implikasi yang jauh lebih luas daripada hanya orang ini, Anda perlu mempertimbangkan dampaknya terhadap tim. Jika sikapnya dibiarkan makmur, itu bisa memberikan kebencian dari orang lain atau membuat orang lain merasa bahwa hal semacam ini juga oke. Dari sudut pandang tim, harus benar-benar jelas bahwa jika dia pergi, itu karena alasan yang tepat dan dia memiliki banyak peluang untuk meningkat.

Satu permata yang saya ambil pada kursus tahun yang lalu adalah fakta bahwa orang-orang dengan pengetahuan teknis yang tidak dimiliki orang lain dapat memimpin manajemen untuk memberi mereka kelonggaran. Itu buruk untuk tim. Anda mungkin takut kehilangan satu-satunya pengembang c ++, tetapi mereka dapat diganti. Jelas ada risiko yang melekat jika dia tahu produk yang dirilis dengan baik, tetapi sering saya melihat orang dengan produk / pengetahuan teknis yang tampaknya tak tergantikan diganti lebih mudah daripada yang diantisipasi. Tim dan organisasi seringkali mengisi kekosongan yang awalnya tampak sulit untuk diisi. Tentu saja jika dia tidak memiliki keterampilan c ++ atau pengetahuan khusus organisasi yang Anda pikir akan sulit untuk diganti, ada jauh lebih sedikit masalah!


1
Saya menduga orang ini akan benar-benar terperangah untuk mengetahui bahwa manajernya berpikir untuk memecatnya. Beberapa orang yang Anda hanya perlu memukul kepala dengan papan dan flat memberitahu mereka bahwa mereka harus meningkatkan atau mereka akan dipecat.
HLGEM

0

Tentu saja tidak. Ingat, ini bukan amal, Anda menukar uang untuk bekerja. Jika dia tidak memegang sisi kesepakatannya maka seperti transaksi apa pun saya akan berhenti membayar.


-1

Jika Anda ingin memberinya kesempatan, kembangkan tes standar yang mengumpulkan metrik pada kebocoran memori. Pantau kemajuannya setiap minggu, berkeras melihat kode yang dia ubah, dan mencari peningkatan. Jika dia tidak bisa mengelola pada saat itu, memecat makian yang tidak berguna.

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.