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

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.

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!

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

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.

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

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!

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.

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.

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.

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?

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.

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

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.

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.

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.

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

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.