Apakah ada cara untuk lebih cepat dalam menyelesaikan bug? Saya baru saja mendapat peringatan dari bos saya [ditutup]


129

Saya baru saja diberitahu oleh bos saya bahwa saya akan menerima tinjauan kinerja negatif pada hari Senin. Dia ingin berbicara kepada saya tentang mengapa saya sangat lambat dan mengapa tingkat perbaikan bug saya sangat rendah.

Saya suka pemrograman dan menyelesaikan masalah tetapi saya benar-benar menemukan pekerjaan saya sangat sulit.

Saya sebenarnya sudah menjadi programmer selama sekitar 10 tahun. Tapi ini adalah pekerjaan linux embedded multithreading pertama saya - Saya sudah di sini 2 tahun dan jelas bagi semua orang bahwa saya masih berjuang. Dan saya pikir saya telah menjadi sangat terdemoralisasi dan merasa sangat terpinggirkan sehingga saya kehilangan banyak api yang saya miliki di awal pekerjaan.

Adakah yang pernah berada dalam situasi yang serupa dan bagaimana Anda meningkatkan tingkat perbaikan bug Anda?


Pembaruan: Saya mendapat ulasan. Saya telah mengikuti 'program pengembangan karyawan' 3 bulan (dari jenis yang disebutkan oleh Dunk). Tidak yakin apakah saya bisa membalikkan ini. Tetapi bahkan jika saya harus pindah, saya telah belajar banyak dari pengalaman ini.

Pembaruan lain

Sekarang sekitar 6 minggu sejak ulasan pertama. Saran saya kepada siapa pun yang menghadapi situasi yang sama adalah cukup rendah hati untuk menerima kritik dan belajar dari kesalahan Anda. Dan untuk tidak takut terlihat bodoh. Ajukan banyak dan banyak pertanyaan. Biarkan orang tahu Anda mencoba belajar dan terus bertanya sampai Anda mengerti. Tetapi bersiaplah untuk itu agar tidak berhasil. Saya sedang membangun portofolio kode ... serta memberikan yang terbaik.

Namun pembaruan lainnya

Saya ragu-ragu untuk meletakkan ini di sini, karena saya khawatir saya tidak akan dapat merujuk perusahaan yang akan datang ke profil stackoverflow saya ... Tetapi bagaimanapun, mungkin menarik bagi seseorang yang membaca pertanyaan ini, tetapi saya benar-benar kehilangan pekerjaan beberapa minggu yang lalu. Saya di tengah menyikat semua keterampilan yang saya butuhkan - saya telah mengambil banyak dari saran yang diberikan di sini.


170
Biarkan atasan Anda tahu bahwa sungguh baik baginya untuk menyimpan up untuk ulasan Anda alih-alih menyebutkannya ketika dia melihat itu masalah.
Blrfl

13
Pemrograman pemeliharaan membutuhkan jenis orang tertentu. Mungkin itu bukan urusanmu. Demikian juga, perkembangan baru membutuhkan jenis orang lain. Anda berbicara tentang menemukan alat / tips / trik. Berapa banyak alat yang telah Anda buat untuk digunakan sendiri? Jika jawabannya tidak ada, maka saya benar-benar berpikir Anda bukan tipe orang pemrograman pemeliharaan. Jika Anda telah terseret di antara beberapa proyek karena kurangnya kinerja maka anggap itu sebagai pesan yang jelas bahwa Anda tidak memenuhi syarat untuk posisi Anda berada. Cari sesuatu yang lebih cocok untuk Anda.
Dunk

40
Jika Anda harus menebak bahwa Anda sedang terseok-seok karena kinerja Anda, manajemen melakukan sesuatu yang salah. Demikian juga, jika Anda pertama kali mengetahui kinerja Anda di bawah 2 tahun, manajemen melakukan sesuatu yang salah.
Michael Shaw

32
@Bee: Biasanya, begitu seseorang mendapat ulasan buruk, sekarang saatnya untuk pergi. Mereka mungkin menempatkan Anda pada "program pengembangan karyawan" tetapi saya tidak berpikir saya pernah melihat seseorang pulih setelah mereka mencapai tahap itu. Waktu termudah untuk mencari pekerjaan adalah ketika Anda sudah memiliki pekerjaan. Jadi jika saya jadi Anda, saya akan memperbarui resume saya dan mulai mencari di tempat lain, segera. Anda juga harus sangat berhati-hati dengan jenis pekerjaan yang Anda ambil. Pengalaman 7 tahun masih menyisakan pilihan. Setelah Anda mencapai 10, perusahaan akan mengharapkan keahlian di bidang tertentu. Pilih area yang Anda suka dan pandai. Ups baru saja melihat Anda menekan 10 sudah.
Dunk

8
Tidak cukup untuk menjadi jawaban, tetapi mengenai "cara untuk mendapatkan lebih cepat": Anda menyatakan itu adalah domain tempat Anda baru. Mungkinkah Anda cara memperbaikinya terlalu banyak coba-coba, tidak benar-benar mengetahui apa yang terjadi "jauh di lubuk hati"? Dalam kasus seperti itu, mempelajari dasar-dasarnya secara menyeluruh akan membuat Anda lebih baik untuk melihat masalah potensial.
Matsemann

Jawaban:


80

Banyak jawaban yang mempertanyakan metode / taktik / metrik / bos Anda. Tapi itu intinya. Mungkin Anda lambat. Setiap kamar pengembang harus memiliki SATU yang lebih lambat dari yang lain, kan? (Itu hanya teori langsung.) Jadi mari kita asumsikan itu Anda. Jawabannya adalah, MENGAPA Anda lambat? (Jelas itu adalah pertanyaan yang harus Anda jawab sebelum Anda dapat memecahkan pertanyaan yang Anda nyatakan tentang bagaimana menjadi lebih cepat.)

Mungkin ada berbagai macam alasan, tetapi berikut adalah beberapa penjelasan yang mungkin untuk dipertimbangkan:

  1. Anda kurang pintar dari mereka . Itu mungkin, bukan? (Penelitian telah menunjukkan bahwa kita semua adalah kurang populer , kurang-menarik , dan (akan mengikuti) kurang cerdas daripada teman-teman kita.) Jadi mungkin Anda hanya lambat berotak. Kemudian lagi, dalam kasus Anda saya pikir ini tidak mungkin. Sekilas profil StackOverflow Anda menunjukkan bahwa Anda memiliki riwayat mengajukan pertanyaan cerdas tentang berbagai topik. Jadi Anda jelas seorang pemikir dan mungkin yang bagus dalam hal itu.

  2. Anda menyebar terlalu tipis. Profil SO yang sama dari Anda menunjukkan bahwa pertanyaan Anda mencakup keseluruhan teknologi yang sangat luas selama 2 tahun terakhir (grafik, web, python, c ++, c, linux, tertanam, utas, utas, soket, dll.). Secara pribadi, saya tahu bahwa ketika saya berada dalam situasi memiliki (atau ingin) mempelajari banyak aliran yang berbeda, saya mendapati diri saya berenang dengan arus sangat cepat (atau, lebih tepatnya, sangat lambat ). Mungkin yang benar-benar Anda butuhkan di sini adalah FOCUS . Dan mungkin dosis prioritas yang sehat . Apakah di sana Anda bisa membuang pot yang kurang penting ke kompor belakang dan menyalakan panas pada hidangan utama?

  3. Anda tidak bersenang-senang. Ketika api padam, mesin uap ditakdirkan untuk melambat. Anda mengakui di pos Anda bahwa moral Anda telah terpukul belakangan ini. Sayangnya Anda telah tertelan ke pusaran mengisap harmonik negatif yang memperkuat diri sendiri - kekuatan yang dapat menghancurkan jembatan . Ini adalah spiral yang terlalu akrab: tugas yang sulit -> stres -> tenggat waktu yang terlewat -> lebih banyak stres -> mekanisme penanganan yang buruk -> lebih banyak stres -> penundaan -> tenggat waktu yang terlewat -> kritik / gosip (nyata atau yang dibayangkan) - > lebih banyak stres. Anda mendapatkan fotonya. Ini jarang mengarah ke tempat yang bermanfaat. Ambil pelajaran dari hari-hari saya di arung jeram: Ketika Anda tersedot di bawah air dengan arus yang mengalir di sisi belakang dari sebuah speed-4 kelas, jaket pelampung Anda TIDAK akanpelampung Anda kembali ke permukaan. Strategi terbaik (meskipun tidak intuitif) adalah menemukan dasar sungai, dan berjalan keluar dari tepi sungai. Jadi saran saya kepada Anda adalah: cari tempat , teman, (teman, gereja, kebiasaan baru yang sehat, dll.) Dan manfaatkan itu untuk membuat Anda keluar dari pusaran air.

  4. Anda tidak berada di zona Anda. Michael Jordan membuat pemain bisbol yang lemah. (OK, dia masih lebih baik dari saya, tapi jelas leaguer kecil.) Mungkin "multithreading embedded linux" tidak manggung. Tetapi Pengembangan Perangkat Lunak adalah bidang yang sangat luas (seperti yang Anda ketahui; cf # 2 di atas). Apakah perusahaan Anda cukup luas sehingga Anda dapat menemukan ceruk lain? Dalam pekerjaan terakhir saya, saya dipekerjakan sebagai SW dev yang tertanam. (Saya tidak memiliki pengalaman di bidang itu, tetapi saya memberi tahu mereka bahwa saya adalah "pembelajar cepat"). Saya dengan cepat tenggelam seperti batu. Tetapi saya terus bekerja keras dan terus mencari masalah yang saya lakukantahu bagaimana memecahkannya. Ternyata, saya secara bertahap dapat bermigrasi ke tanggung jawab baru di mana saya bisa bersinar, dan untuk yang akhirnya saya menerima banyak pujian. Jadi mungkin Anda perlu merek ulang sendiri.

Intinya adalah: jika Anda lambat, ada alasannya. Tapi, hei - Anda seorang insinyur perangkat lunak, bung! Debug dirimu sendiri!


2
jawaban yang brilian. saya pikir semua poin Anda berlaku untuk saya (dan mengenai # 1, juga mungkin saya saya kurang cerdas, saya mendengar bahwa ada berbagai jenis kecerdasan -. jadi mungkin yang berhubungan dengan # 4 mungkin aku numbskull tertanam linux dev tapi mungkin saya lebih baik dalam hal-hal web ... dan sekarang saya memikirkannya, ini sebenarnya mungkin realistis). Lagi pula - Anda sangat perseptif.
BeeBand

14
3 dan 4 lebih besar (untuk programmer) daripada yang bisa dibayangkan sebagian besar bos. Jika seorang programmer memiliki semangat kerja yang rendah, ia tidak dapat berkonsentrasi pada pekerjaan. Bagi seorang programmer, moral adalah momentum dan momentum adalah segalanya.
TimG

7
Jawaban yang sangat bagus. Debug sendiri adalah ungkapan yang bagus, btw. Saya berharap saya bisa membuat Anda senang untuk kedua kalinya hanya untuk itu.
Kyeotic

2
"Ini akan mengikuti" Anda tidak berfungsi pada poin 1 karena paradoks persahabatan memodelkan hubungan antara dua orang sebagai keunggulan dua arah sederhana antara dua simpul dalam grafik, sedangkan grafik siapa yang "lebih pintar" daripada siapa yang harus mempertimbangkan beragam faktor lain, belum lagi aturan transitivitas tidak berlaku. Saya setuju dengan poin 2,3 dan 4. Dalam kasus OP saya pikir bosnya adalah seorang douchebag yang menderita efek dunning-krueger.
funkymushroom

1
programmer, debug dirimu. menyukainya :) jawaban yang bagus juga. berguna bagi saya, bukan karena saya berada dalam situasi itu, tetapi karena saya dapat melihat sekarang bagaimana menghindarinya. +1
jammypeach

56

Bos Anda mungkin benar: Anda mungkin "berkinerja buruk" (lebih dari itu sebentar lagi). Tetapi mungkin bukan hanya tingkat kompetensi Anda yang harus disalahkan. Saya tidak berpikir itu akan menjadi jangkauan untuk menyarankan kekuatan di luar kendali Anda menyebabkan Anda stres, yang memiliki efek negatif pada kinerja Anda.

Mari kita lihat beberapa alasan atasan Anda sekarang mungkin mengemukakan ini:

Kebudayaan dan Politik

Mungkin ada kekuatan di luar kendali Anda yang mengharuskan bos Anda sekarang menyuarakan keprihatinannya. Penting untuk memahami sistem tempat Anda bekerja. Tugas Anda adalah membuat bos Anda terlihat baik. Satu-satunya cara untuk melakukan itu adalah memahami tekanan yang dia alami.

Kemampuan

Mungkin saja kemampuannya tidak seperti biasanya, seperti yang Anda katakan secara terbuka. Inilah yang akan saya lakukan dalam situasi ini:

Dapatkan umpan balik spesifik dari bos Anda tentang bagaimana dia mengukur kinerja. Apakah Anda tidak menutup bug sebanyak orang X? Apakah ada sejumlah bug yang harus Anda selesaikan? Jika Anda bekerja sendirian maka Anda perlu memastikan bahwa orang-orang yang mengukur kinerja Anda mengukurnya secara adil dan tidak didasarkan pada beberapa gagasan yang sudah terbentuk sebelumnya.

Jika kinerja Anda lambat dan berdasarkan kesenjangan nyata, identifikasi kesenjangan itu dan letakkan rencana terperinci bersama dengan bos Anda dengan tujuan untuk menutupnya.

Ulasan ini juga merupakan peluang bagus untuk mengemukakan fakta bahwa Anda tidak bahagia. Adalah baik bahwa Anda telah mengidentifikasi bahwa Anda tidak menyukai pekerjaan ini. Tapi cari tahu mengapa. Bagian mana dari pekerjaan Anda yang Anda sukai dan yang tidak Anda sukai? Mungkin saja pekerjaan ini bukan untuk Anda ...


2
itu jawaban yang bagus. Saya harus memikirkan mengapa saya tidak menikmati pekerjaan ini. Terutama file log yang mereka berikan kepada kami untuk menemani bug, saya datang untuk membenci mereka lebih dari orang lain - saya memulai selalu sepenuhnya dan benar-benar dalam kegelapan dengan bug apa pun yang mereka berikan kepada saya. Saya pikir ini perasaan 'dalam gelap' yang saya benci.
BeeBand

4
Kecuali ada yang mengalami masalah serupa pada proyek yang sama, kebanyakan orang memulai "dalam kegelapan" ketika mereka mendapatkan bug baru. Kemudian berdasarkan gejalanya, Anda mengetahui cara membuat ulang masalah tersebut, yang seharusnya memberikan gagasan tentang di mana harus mulai menebak penyebab masalahnya. Anda melanjutkan langkah demi langkah. Tidak ada yang ajaib, tidak ada yang perlu dibenci. Anda mengatakan Anda membenci file log. Apakah Anda membuat sendiri alat apa pun untuk secara otomatis menganalisis file-file log itu? Mengabaikan fakta bahwa file-file log seharusnya bermanfaat, jika tidak, maka tidak akan lama sebelum saya membuat alat untuk membantu menganalisisnya untuk saya.
Dunk

1
@Dunk ya saya memang membuat alat untuk mengurai file log dengan berbagai cara. Saya menemukan setelah itu bahwa seseorang telah membuat satu tahun yang lalu.
BeeBand

@Bee: Alat Anda membuat menunjukkan beberapa inisiatif yang diperlukan. Apakah tidak ada yang memberi Anda gambaran lingkungan pengembangan ketika Anda melakukan transisi antar proyek? Jika ada alat maka itu pasti akan tampak seperti pimpinan proyek harus memberi tahu Anda tentang mereka.
Dunk

@Dunk re overview - tidak. Pimpinan tim pertama saya menunjukkan kepada saya alat khusus - tetapi tidak menunjukkan bahwa itu berguna untuk memperbaiki bug dari jenis tertentu atau bahwa itu dapat diterjemahkan ke proyek lain. Ketika saya dipindahkan ke proyek pemeliharaan baru ini, tidak ada yang berbicara kepada saya melalui lingkungan pengembang - saya hanya perlu bertanya-tanya. Hanya setelah berjuang untuk membangun alat saya sendiri, saya bertanya pada seorang rekan dan dia menyebutkan bagaimana saya bisa menggunakan alat yang asli. (NB ini adalah alat yang berbeda dari komentar saya sebelumnya).
BeeBand

38

Beberapa lingkungan kerja tidak bisa bekerja. Saya telah melihat lingkungan di mana tidak ada yang bisa bertahan hidup (kecuali bagi mereka yang ada di awal) karena begitu banyak yang tidak terdokumentasi dan pertanyaan-pertanyaan sangat tidak disarankan.

Anda benar-benar harus jujur ​​dengan diri sendiri mengenai harapan dan sumber daya yang disediakan untuk membantu Anda mencapainya. Masalahnya mungkin bukan Anda.

Anda menyebutkan bahwa ada orang yang melakukan pekerjaan serupa dengan Anda yang, saya kira, tidak mengalami kesulitan, tetapi yang memiliki 5+ tahun pengalaman dengan 2. Anda. Bagaimana perasaan Anda dibandingkan dengan rekan-rekan Anda? Apakah mereka bintang rock yang sepenuhnya mengungguli Anda (dalam hal ini), atau apakah mereka sama seperti Anda? Mungkin mereka baru mengetahui sistemnya ketika itu lebih sederhana ... Anda menyebutkan memiliki pengalaman pemrograman 8 tahun sebelum pekerjaan ini. Bagaimana kabarmu di sana? Jika Anda hebat, maka itu akan memberi tahu Anda sesuatu.

Bagian yang mengejutkan saya adalah sedikit tentang Anda menggambarkan diri Anda dalam kegelapan sehubungan dengan semua bug yang datang kepada Anda. Bisa jadi basis kode begitu luas dan belum dipetakan sehingga harapan mungkin tidak masuk akal.

Bagi Anda untuk membuatnya sejauh yang Anda miliki berarti bahwa Anda telah melakukan sesuatu dengan benar dan sesuatu terjadi untuk Anda.

Intinya, saya pikir, adalah bahwa Anda perlu merasa baik tentang diri sendiri dan tentang apa yang Anda lakukan. Dan jika itu berarti melanjutkan, maka jadilah itu.

Lebih baik untuk pindah daripada memiliki pekerjaan yang merusak hidup Anda.


2
Saya telah melihat tim dalam karier profesional saya persis seperti yang telah Anda jelaskan. Kode yang mereka pelihara sangat luas dan samar, dan informasi tentang cara kerjanya dijaga dengan iri. Anggota tim baru sengaja dibiarkan sendiri, dan akhirnya mentransfer untuk menyelamatkan karier mereka.
Anthony Giorgio

31

Pertama, perhatikan: jawaban ini hanya berlaku untuk wilayah tertentu di mana dilarang untuk memecat seorang karyawan tanpa pesangon. Yang mengatakan ...

Ini bisa menjadi kasus pemecatan yang konstruktif dan mana yang ilegal.

Taktiknya adalah untuk menurunkan moral dan menurunkan harga diri seorang karyawan sampai mereka keluar dari pekerjaan. Ini adalah cara bagi perusahaan untuk menghemat uang dengan tidak harus membayar pesangon, atau menyelesaikan masalah karena harus menghadapi karyawan dan memecat mereka.

Dia ingin berbicara kepada saya tentang mengapa saya sangat lambat dan mengapa tingkat perbaikan bug saya sangat rendah.

Kesalahan ini sangat ambigu. Tidak mungkin bagi kedua belah pihak untuk mengklaim yang lain salah. Anda membutuhkan waktu sebulan untuk memperbaiki satu bug. Terus! Ini menempatkan Anda dalam posisi defensif, dengan harus menyajikan fakta untuk mendukung klaim Anda bahwa diperlukan satu bulan. Mengingat keterampilan, pengalaman, dan pengetahuan Anda saat ini sebagai faktor. Sebagai majikan, adalah tugas majikan untuk mengatur waktu dan upaya karyawannya. Majikan harus menjadi orang yang terlibat dalam risiko terkait dengan perbaikan bug. Bukan karyawan. Dia selalu punya pilihan untuk memberikan bug kepada orang lain.

Jika Anda seorang kontraktor, dan itu menyatakan dalam kontrak Anda yang akan bertanggung jawab untuk memperbaiki bug, maka itu adalah cerita yang sama sekali berbeda.

Apakah salah bagi majikan untuk mengeluh bahwa Anda terlalu lama? Sama sekali tidak, tetapi dia tidak bisa meminta pertanggungjawaban Anda, dan dia tidak bisa memecat Anda karenanya. Dia dapat mengatakan kepada Anda, "Kami tidak memiliki bug lagi yang memerlukan keahlian Anda, dan Anda cuti," tetapi mereka harus memberi tahu Anda saat ada masalah baru yang dapat Anda atasi. Kalau tidak, mereka harus mengakhiri dengan pesangon. Yang tidak bisa dia lakukan adalah memberi Anda pekerjaan yang tidak bisa Anda tangani dan kemudian mengeluh tentang hal itu. Saya pikir ini ilegal.

Saya suka pemrograman dan menyelesaikan masalah tetapi saya benar-benar menemukan pekerjaan saya sangat sulit.

Ada perbedaan besar antara mengambil pekerjaan yang menurut Anda sulit, dan majikan Anda memberi Anda pekerjaan yang terlalu sulit. Jika Anda merasa tugas yang diberikan kepada Anda selesai untuk mencegah Anda memiliki karier di perusahaan, ini bisa ilegal.

Saya sebenarnya sudah menjadi programmer selama sekitar 10 tahun. Tapi ini adalah pekerjaan linux embedded multithreading pertama saya - Saya sudah di sini 2 tahun dan jelas bagi semua orang bahwa saya masih berjuang.

Inilah mengapa saya pikir Anda menemukan diri Anda di tengah-tengah pemecatan yang konstruktif. Mereka tidak senang dengan Anda sehingga mereka menumpuk omong kosong pada Anda sampai Anda pergi.

Dan saya pikir saya telah menjadi sangat terdemoralisasi dan merasa sangat terpinggirkan sehingga saya kehilangan banyak api yang saya miliki di awal pekerjaan.

Majikan bertanggung jawab untuk menyediakan lingkungan kerja yang aman dan positif. Tanpa informasi lebih lanjut (kemungkinan besar pribadi) sulit bagi orang luar untuk mengatakan apa yang sebenarnya terjadi di sini. Tanyakan kepada pengacara ketenagakerjaan untuk konsultasi gratis. Mereka akan dapat memberi tahu Anda jika Anda sedang dimainkan.

Referensi

Saya bukan pengacara, tetapi apakah Google memiliki beberapa dokumen yang membahas topik pemecatan konstruktif yang layak dibaca sebelum Anda memasukkan ulasan Anda pada hari Senin. Poin utama di sini adalah memperhatikan pengurangan gaji, penghinaan, dan perubahan mendadak dalam karier Anda bersama perusahaan.

Fakta yang relevan harus diperhatikan:

  • Kegagalan untuk mendukung karyawan dengan baik selama kondisi kerja yang sulit
  • Mendisiplinkan karyawan secara berlebihan. Memberlakukan perubahan di tempat kerja karyawan dalam waktu singkat
  • Pengenaan pengurangan gaji atau upah

T&J Hukum: Pemecatan yang konstruktif

Alasan untuk mengklaim pemecatan yang konstruktif

Wikipedia

elemen pemecatan yang konstruktif


11
Ini tidak ilegal untuk memberikan ulasan kinerja negatif, tetapi mereka tidak harus obyektif dan setuju kriteria layak untuk bekerja dan mendukung Anda.
pjc50

9
Saya pikir, mungkin saya bereaksi berlebihan, ketika saya memposting jawaban itu, tetapi membaca posting Anda itu beresonansi dengan pengalaman saya sendiri. Memperbaiki bug bukanlah sesuatu yang dapat diukur dengan konteks kinerja. Saya telah menghabiskan 3 bulan sekali untuk memperbaiki satu bug. Biasanya, orang pintar adalah orang yang mendapatkan bug keras.
Reactgular

9
Saya tidak memilih karena saya tidak melihat bukti bahwa Anda seorang pengacara dan mengaku memberikan nasihat hukum. Juga, jika karyawan lain memperbaiki rata-rata X bug per bulan, tetapi OP memperbaiki X / 10, itu benar-benar objektif dan masuk akal.
Andy

7
@Andy terima kasih telah berbagi mengapa Anda diturunkan. Saya setuju bahwa rasio perbaikan bug adalah indikator, tetapi apa yang objektif tentang memberi tahu seseorang pada hari Jumat bahwa mereka memiliki ulasan negatif yang datang pada hari Senin berikutnya. Selain dengan bijaksana membuat mereka berkeringat di akhir pekan. Apakah tidak aman untuk mengasumsikan bahwa hasil yang diinginkan adalah bahwa karyawan tidak muncul pada hari Senin untuk diperiksa? Apakah itu tidak diklasifikasikan sebagai pemecatan yang konstruktif? Saya harap saya dapat mengubah perspektif Anda, karena pemecatan yang konstruktif merupakan masalah yang sedang berlangsung di industri kami.
Reactgular

7
Tidak mungkin seorang hakim akan memutuskan bahwa ini adalah pemecatan yang konstruktif. Anda dapat mengelak dan mengomel atas surat hukum, tetapi jenis hukum ini ada untuk kasus-kasus ketika seorang karyawan dilecehkan atau dilecehkan, situasi yang bermusuhan secara aktif. Berdasarkan apa yang dikatakan OP, mereka diberitahu bahwa mereka mendapatkan ulasan negatif karena dia tidak menumpuk terhadap rekan sebaya sejauh tingkat perbaikan bug; itu adalah situasi yang sulit untuk dihadapi, tetapi tidak sulit dan tentu saja tidak ilegal. Mungkin bos bisa lebih bijaksana, tetapi umpan balik tidak harus dibatasi pada ulasan kinerja resmi
pdubs

26

Mungkin Anda dibandingkan dengan salah satu programmer asli suatu proyek. Saya tahu bahwa sebagai pengembang asli dari salah satu proyek yang saya kerjakan, saya memiliki keuntungan luar biasa ketika memperbaiki bug di dalamnya. Saya tidak berpikir itu karena kurangnya dokumentasi, hanya saja saya secara intuitif dapat melompat ke masalah potensial karena otak saya tahu semua kode.

Jika Anda dibandingkan dengan itu, maka Anda tidak akan mengukurnya. Itu selalu akan membawa Anda lebih banyak waktu untuk mempercepat proyek dan Anda tidak akan tahu di mana semua titik interaksi potensial.

Saya membaca komentar Anda tentang tidak mencari tahu tentang alat dan trik yang digunakan programmer lain untuk menyelesaikan masalah. Mungkin untuk perbaikan bug Anda berikutnya, Anda perlu mencoba pemrograman berpasangan. Ini bisa sangat berguna. Bergantian mengemudi keyboard. Jangan banyak bicara.

Anda dapat menggunakan buku catatan atau papan tulis untuk memetakan jalur fungsi, utas dan mengunci masa hidup, dan tandai di mana Anda mengamati berbagai bit perilaku dan di mana Anda dapat memasukkan probe baru.

Memecahkan masalah-masalah threading tingkat rendah semacam ini bisa sangat sulit dan saya memiliki banyak simpati untuk Anda. Saya harus menganalisis beberapa gigabytes file log sebelum menemukan masalah dua baris. Dan tahukah Anda? Saya menatap itu selama berhari-hari sebelum saya meminta bantuan dari insinyur yunior yang pernah magang tahun sebelumnya, dan dia menemukan pendekatan baru dan menemukan masalah dalam satu jam. Jadi, setelah Anda menaruh waktu ke dalam bug, dapatkan beberapa mata baru di atasnya. Itu bisa banyak membantu!


3
Ini adalah tanggapan yang fantastis. Saya sangat terkesan.
Daniel Hollinrake

26

Salah satu disfungsi manajemen yang paling umum dalam industri ini adalah tidak memahami bahwa debugging secara intrinsik sulit . Saya memiliki pengalaman hampir 20 tahun dan saya masih harus menghabiskan satu minggu penuh untuk menemukan kesalahan satu baris yang membuat program macet sekali saja dari lima puluh. Dan kemudian, jika manajer saya tidak memahami hal-hal ini, mereka mengganggu saya untuk mengambil waktu seminggu untuk mengubah satu baris kode.

Apa yang bisa kamu lakukan?

  • Buat catatan saat Anda melakukan debug. Selalu buka jendela editor, dan tulis aliran kesadaran Anda. Tidak harus masuk akal bagi siapa pun kecuali Anda. Anda mungkin menemukan bahwa ini membantu Anda melakukan debug lebih cepat, tetapi itu juga berarti Anda memiliki sesuatu yang konkret untuk menunjukkan bahwa Anda tidak bermain Nethack sepanjang minggu.

  • Bandingkan catatan dengan semua rekan kerja Anda. Berapa lama biasanya mereka memperbaiki bug? Apakah bug mereka tetap diperbaiki? Seberapa sering mereka mengubah satu hal kecil dan menemukan diri mereka terkubur di bawah tumpukan konsekuensi yang mengalir? Jawaban atas pertanyaan-pertanyaan ini akan memberi Anda beberapa perasaan apakah Anda benar - benar berjuang relatif terhadap anggota departemen lainnya.

  • Berteman dengan orang-orang QA dan orang-orang dukungan pelanggan. Mereka adalah orang-orang dengan ide terbaik tentang seberapa penting bug itu. Seringkali ini memiliki sedikit atau tidak ada korelasi dengan betapa sulitnya bug, sehingga Anda dapat sedikit permainan sistem dan mencoba untuk mendapatkan semua bug penting, rendah kesulitan tinggi. (Ini tidak benar-benar curang. Tim yang terorganisir dengan baik selalu mengejar bug itu terlebih dahulu.)

  • Jika bos Anda belum memberi Anda umpan balik yang memadai tentang kinerja Anda selama dua tahun berturut-turut, itu adalah masalah untuk pertama kali muncul di ulasan kinerja ini, dan kemudian ketika Anda diberi solusi untuk itu, untuk meningkatkan dengan bos bos Anda. Bersikap sopan, dan terutama jangan biarkan mereka melihat betapa marahnya Anda, tetapi dapatkan kritik khusus secara tertulis.


4
"Debugging dua kali lebih sulit daripada menulis kode di tempat pertama." - Brian Kernigan (ayah dari C, UNIX)
TimG

4
@TimG: Dan seperti setiap programmer lain, Kernigan meremehkan kesulitannya.
mu terlalu pendek

Wow, saya ingin menunjukkan, bahwa ini adalah pertanyaan yang sangat sulit dan saya sangat terkejut melihat jawaban yang bagus dan berwawasan di sini. Terima kasih.
maksymko

12

Meskipun Anda mungkin suka pemrograman dan menyelesaikan masalah, mungkin ada pertanyaan tentang seberapa baik Anda menerapkan apa yang Anda pelajari ke bidang lain. Apakah ada di antara selusin bug terakhir yang telah Anda perbaiki yang cukup mirip sehingga yang membantu Anda memperbaikinya bermanfaat bagi yang lain? Ini adalah bagian dari melihat kembali apa yang Anda lakukan dan berapa lama untuk menyelesaikannya. Hanya sebuah ide untuk dipertimbangkan.

Kedua, saya akan melihat bagaimana Anda melakukan pekerjaan Anda. Apakah Anda terganggu secara berkala dan ketika Anda mencoba memperbaiki bug A, Anda diberi tahu bahwa bug B dan C adalah prioritas yang lebih tinggi? Pertimbangkan baik-baik jenis perubahan dalam bagaimana Anda melakukan pekerjaan Anda dapat membantu Anda di sini karena itu mungkin bagian dari apa yang ingin diketahui bos Anda.

Saya memiliki beberapa tempat kerja yang memberi tahu saya bahwa mereka tidak suka berapa lama waktu yang saya butuhkan untuk menyelesaikan beberapa pekerjaan saya. Tentu saja ini adalah tempat-tempat di mana jika saya menyelesaikan satu hal, 5 hal baru akan jatuh di pangkuan saya dan dengan demikian mudah kewalahan. Walaupun saya mungkin tidak lagi bekerja di sana, saya tidak memiliki solusi yang baik untuk mendapatkan perhatian saya pada beberapa hal sehingga saya tidak merasa seperti sedang mencoba menguasai 1.000 hal sekaligus. Jika saya dapat mengetahui beberapa hal penting yang harus dilakukan dan bagaimana pekerjaan saya akan dinilai, maka saya jauh lebih baik daripada jika saya memiliki daftar "yang harus dilakukan" yang panjangnya satu mil dan tidak ada yang peduli jika saya mendapatkan bagian dari itu dilakukan. Jadi, bisa jadi ada komponen budaya dalam organisasi ini meskipun saya akan berhati-hati untuk meminta hal-hal di sini berubah.


2
ended up getting micromanaged until I was terminated- Yah saya baru saja melihat profil SO Anda dan Anda jelas telah bangkit kembali dari itu, jadi saya menemukan respons Anda menggembirakan. Saya akan berbicara tentang poin pertama Anda pada hari Senin - Saya menerima bug dari daerah yang sangat berbeda.
BeeBand

10

Setelah dua tahun bekerja, jelas bagi semua orang (Anda, bos Anda, kolega Anda) tentang di mana Anda berdiri. Yaitu, Anda seharusnya tidak pernah tahu bahwa Anda telah melakukan yang buruk hanya setahun sekali; lingkungan kerja yang ideal akan memberikan umpan balik yang berkelanjutan.

Lagi pula, mengenai cara men-debug kode multithreaded: Anda belum menyebutkan apakah ini kode Anda atau orang lain. Ada beberapa debugger baru dan penganalisa statis yang dapat menangani konkurensi. Tapi sungguh, mengetahui polanya akan menjadi pilihan terbaik Anda karena Anda akan tahu apa yang harus dicari.

Jika Anda memahami bagaimana bagian kritis dan kondisi balapan serta kebuntuan bekerja, maka Anda akan berada dalam posisi yang lebih baik untuk menemukan hal-hal yang tidak terduga. Jika Anda melihat "komunikasi" antara dua utas tanpa variabel kondisi, atau jika sumber daya dimutekskan tanpa urutan tertentu, atau jika variabel lokal dinyatakan statictanpa alasan yang jelas, maka Anda memiliki bug potensial! Jadi pelajari praktik terbaik dari domain Anda dan Anda akan berada dalam posisi yang lebih baik untuk menilai ketika ada sesuatu yang tidak biasa.


2
ya ini bukan kode saya - ini adalah sistem tertanam luas yang luas, pertama kali dirancang 10 tahun lalu. Saya pikir Anda benar tentang polanya - saya harus kembali ke dasar.
BeeBand

1
@BeeBand akan lebih baik untuk mengetahui bagaimana keadaan Anda. Semoga semuanya berhasil.
Daniel Hollinrake

10

Jangan berjuang sendirian kecuali Anda harus. Rekrut rekan kerja. Dapatkan mereka untuk membantu perburuan bug. Tanyakan kepada mereka tentang proses dan alat berpikir mereka. Mungkin menyebutkan ini dalam ulasan Anda sebagai bagian dari rencana Anda untuk meningkatkan. Jika semua orang di sekitar Anda melakukan lebih baik pada sistem ini , mungkin mereka tahu sesuatu yang spesifik?


Akan menarik untuk mengetahui apakah BeeBand sudah melakukan ini. Membaca melalui komentar dan jawaban sepertinya itu adalah lingkungan yang tidak ramah.
Daniel Hollinrake

1
Yah, saya bisa bersimpati dengan itu. Saya tahu seperti apa rasanya berada di perusahaan tempat tim dev turun kerja. Untungnya, meskipun dalam kasus saya, saya bekerja dengan beberapa kolega hebat dan kami saling menjaga. Adakah orang yang bisa Anda jadikan pasangan? Waktu yang dihabiskan untuk melatih Anda dan membantu Anda menjadi lebih produktif akan memberikan hasil bagi semua orang. Dari suara hal-hal yang Anda lakukan peduli dan teliti sehingga perusahaan Anda akan mendapat manfaat dari menjaga Anda.
Daniel Hollinrake

8

Saya baru saja diberitahu oleh bos saya bahwa saya akan menerima tinjauan kinerja negatif pada hari Senin. Dia ingin berbicara kepada saya tentang mengapa saya sangat lambat dan mengapa tingkat perbaikan bug saya sangat rendah.

Ketahuilah bahwa di perusahaan nonfungsional apa pun tidak terjadi pada pesanan ini. Jika atasan Anda mengkhawatirkan kinerja Anda, ia harus menetapkan sasaran jangka pendek, dan membicarakan hasil Anda untuk mencari tahu di mana masalahnya.

Sebaliknya, ia memutuskan untuk memberi Anda ulasan negatif, lalu mencari tahu alasannya. Sepertinya dia tidak mau melibatkan diri dalam masalah, dan dia hanya ingin hasil di meja.

Jangan bertujuan untuk memecahkan bug lebih cepat. Bertujuan untuk mengevaluasi kemampuan Anda sendiri, periksa bagaimana rekan kerja Anda, bagaimana mereka tahu apa yang mereka ketahui, dan sadarilah bahwa ini bukan perusahaan yang ideal.

Adapun tips praktis, saya menggunakan potongan kode, dan mediawiki saya sendiri untuk membuat catatan. Saya selalu ingat buku apa yang harus dibaca selanjutnya, dan ke arah mana saya akan melanjutkan untuk melanjutkan belajar. Belajar adalah jalan menuju pekerjaan yang lebih baik dan kehidupan yang lebih bahagia.


7

Pertama, peningkatan kepercayaan diri:

Mengapa menderita? Anda dapat dengan mudah menemukan pekerjaan di mana mereka akan berpikir bahwa Anda "dewa" hanya karena Anda dapat melakukan apa pun yang tertanam di Linux, terlepas dari tingkat perbaikan bug Anda.

Bagaimanapun, tidak mungkin untuk menetapkan batas waktu berburu bug. Bug hunt adalah keterampilan, tidak diragukan lagi, dan efisiensi di dalamnya sangat berharga.

Anda mungkin kehilangan beberapa trik dasar yang diketahui orang lain, yang membuat Anda lebih lambat.

Misalnya, jika Anda dan saya sedang mengerjakan beberapa middleware Linux, dan saya menggunakan Valgrind untuk menemukan masalah kerusakan memori dan kondisi perlombaan data, sedangkan Anda hanya mengandalkan gdb dan printf, saya mungkin akan menendang pantat Anda, bahkan jika kamu lebih pintar dari saya.

Juga, bagaimana pemahaman Anda tentang konkurensi ? Jika Anda telah berkembang selama sepuluh tahun, tetapi sebagian besar pengalaman itu bukan dengan kode multithreaded, itu bisa menjadi masalah.

Anda harus mempelajari multithreading secara terperinci: lebih dari sekedar mengetahui cara menggunakan API, tetapi benar-benar "mendapatkannya" pada level yang dalam. Jika Anda melakukan pemrograman multithreaded, Anda harus menjadi pengembang yang dapat melihat basis kode dari satu mil jauhnya dan melihat skenario kondisi balapan, kebuntuan, inversi prioritas, kelaparan ...


1
Masalah terbesar dengan concurrency adalah jauh lebih mudah untuk menulis kode bebas bug daripada memperbaiki bug dalam kode buggy. Apalagi jika kodenya hampir benar. Dan bug biasanya tidak di satu tempat, tetapi didistribusikan di banyak tempat.
gnasher729

5

Baru-baru ini saya membaca buku Bekerja Efektif dengan Legacy Code dan memberi saya dorongan kepercayaan yang signifikan ketika menangani masalah dalam basis kode apa pun.

Jika kode yang Anda kerjakan kurang sempurna, saya pikir buku ini akan membantu. Saya telah menemukan bahwa banyak waktu untuk memperbaiki bug, saya harus memperbaiki kode di sekitarnya terlebih dahulu untuk memahaminya , dan kemudian setelah saya memahami kode, dan mudah-mudahan membuat kode dapat diuji, melacak dan memperbaiki masalah tidak terlalu sulit. (Kadang-kadang saya bahkan menulis ulang kode hanya untuk memahaminya, tetapi kemudian mengembalikan perubahan saya untuk mengurangi risiko memperkenalkan bug baru. Kemudian saya memasukkan perbaikan bug saya. Teknik itu didasarkan pada trik dari buku ini.)

Saya pikir saran saya hanya membahas sebagian dari masalah Anda, dan agak tidak langsung, tetapi buku ini layak dibaca tidak peduli apa pun, karena bekerja dengan kode lawas adalah keniscayaan bagi pengembang mana pun.


Saat ini saya membacanya berdasarkan rekomendasi Anda.
BeeBand

3

Tanyakan kepada atasan Anda berapa kecepatan Anda memperbaiki bug dan apa yang dimaksud dengan kecepatan rata-rata memperbaiki bug. Lebih penting lagi, tanyakan padanya bagaimana kecepatan memperbaiki bug diukur ...

Ini semacam metrik sebenarnya bukan metrik; jika ya, itu akan menjadi lebih tidak dapat diandalkan daripada LOC (walaupun mengukur hal-hal yang berbeda). Dan tanpa pengukuran yang tepat tidak ada alasan menuduh Anda tentang apa pun.


Agaknya, itu diukur sebagai masalah tertutup / satuan waktu . Mungkin masuk akal untuk mengatakan "baik, beberapa bug membutuhkan waktu lebih lama daripada yang lain", tetapi kecuali OP bekerja di bagian yang sulit dari kode dan semua orang melakukan hal-hal yang mudah, itu mungkin tidak akan menahan air.
Caleb

3

Ketahuilah bahwa Anda bekerja dengan majikan dan / atau pelanggan TIDAK untuk mereka. Jangan ragu untuk menyebutkan hal itu dalam wawancara, hanya untuk meluruskan dari awal.

Anda adalah seorang profesional dengan banyak berinvestasi dalam bisnis kecil Anda, yaitu diri Anda sendiri.

Anda bersedia bekerja sementara ada Union of Interests yang mendorong Anda keluar dari rak setiap hari.

Jika propulsi itu tidak ada di sana untuk waktu yang lama, maka lanjutkan.

Anda membuang-buang waktu dan energi Anda pada seorang gelandangan yang tidak membuat minat Anda terus bertambah / keterampilan diperbarui / tugas menjadi menantang dan / atau menarik bagi Anda untuk dikerjakan. Itu adalah tugas manajemen. Selain itu mereka murni overhead .....

Pertahankan gairah Anda, karena itulah kuncinya.


2

Saya pernah mengalami situasi yang sama karena saya takut meminta bantuan. Menilai dari apa yang Anda katakan dalam komentar ini ...

"Tapi yang membuat frustrasi adalah ada alat / tips / trik tertentu yang baru saya temukan setelah berada di sana selama satu setengah tahun. Saya telah bergeser dari satu tim ke tim lainnya (saya kira karena saya berkinerja buruk) dan saya menemukan alat 'tersembunyi' ini sangat sering. "

... Anda mungkin memiliki masalah yang sama saya lakukan. Debugging adalah keahlian sebanyak menulis kode yang tidak memerlukan banyak debug di tempat pertama. Menonton pengembang lain bekerja melalui masalah debug bisa sangat mendidik. Minta bantuan mereka ketika Anda kesulitan menyelesaikan sesuatu. Terutama jika Anda menutupi tanah yang belum Anda miliki sebelumnya. Dan lakukan itu idealnya sebelum waktunya panik karena Anda tidak menyelesaikan apa pun.

Yang mengatakan, saya setuju dengan komentar bahwa manajemen melakukan sesuatu yang salah. Jika seseorang berjuang dengan sesuatu, mereka harus mendapatkan bantuan sebelum ulasan negatif dimulai. Sial, jika ada orang di tim yang berjuang dan tidak pernah mendapat bantuan, saya katakan setiap anggota tim itu melakukan sesuatu yang salah (walaupun itu bisa jadi akibat langsung dari orang-orang yang memperhatikan tingkat perbaikan bug mereka terlalu dekat).


2

Apa yang hilang dari OP adalah penyebutan proses atau metode berulang yang diikuti untuk menyelesaikan bug.

Jadi, pertama-tama, dokumentasikan proses yang Anda ikuti. Pastikan untuk mendokumentasikan apa yang ingin dicapai setiap langkah dalam proses.

Anda dapat menguraikan proses sebagai memiliki tugas seperti ini:

  1. Pastikan Anda benar-benar memahami masalah apa yang sedang dilaporkan.
  2. Cobalah untuk mereproduksi masalah ini.
  3. Mulailah memecah masalah menjadi potongan-potongan kecil
  4. Pikirkan kemungkinan penyebab masalahnya.
  5. Uji hipotesis itu

Akan sangat membantu untuk mengetahui apakah bug sudah ada sejak lama, atau sedang diperkenalkan dengan perubahan terbaru. Jika bug telah diperkenalkan dengan perubahan baru-baru ini melakukan review kode dan / atau hanya membaca kode yang dibuat orang dapat membantu.

Saya pikir jika Anda dapat dengan jelas mendefinisikan masalahnya, misalnya, "Saya mengalami kesulitan memikirkan hipotesis untuk diuji ketika mencoba menyelesaikan bug" maka Anda bisa mendapatkan saran yang lebih fokus.

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.