Bagaimana Anda menjelaskan sumber masalah yang teridentifikasi tanpa menjadikannya "alasan"? [Tutup]


14

Saat berlatih (setidaknya sebanyak yang saya bisa) "pemrograman tanpa ego", saya fokus pada pemecahan masalah siapa pun yang menulis kode terkait (jika orang itu tidak membuat kode berbahaya) dan saya ingin memahami masalahnya sepenuhnya untuk memastikan untuk mengatasi sumber masalah ini.

Namun, ketika seseorang menunjukkan kode saya untuk menunjukkan kesalahan, saya sering mencoba mengingat apa yang menjadi pola pikir saya saat menulis kode cacat dan saya mencoba menjelaskannya kepada orang yang menunjuk kesalahan untuk memperjelas apa yang menjadi sumber kesalahan (misalnya ketika beberapa nama dipilih dengan buruk, Anda mungkin menggunakannya dengan cara yang tidak dimaksudkan dan dengan keberhasilan yang jelas ...).

Sekarang, saya melakukan ini dengan refleks dan sebagian besar rekan kerja saya memahami refleks ini. Tetapi saya juga bekerja di perusahaan di mana rekan kerja berada dalam mentalitas menyalahkan orang yang membuat masalah yang diidentifikasi, dengan atau tanpa humor (bagi saya itu tetap memiliki efek tidak waras yang sama).

Dalam lingkungan semacam ini, menjelaskan mengapa Anda harus menulis kode yang salah membuat orang lain berpikir bahwa Anda sedang mencoba membuat alasan. Saya berkomentar bahwa kebanyakan orang non-teknis (atau bukan ahli domain, tidak yakin, ini hanya pengalaman pribadi) juga bereaksi persis seperti itu ketika Anda mencoba menjelaskan mengapa Anda melakukan sesuatu yang salah.

Jadi, ketika berhadapan dengan orang / lingkungan semacam ini, bagaimana Anda bisa menjelaskan sumber kesalahan yang sebenarnya tanpa terlihat seperti "membuat alasan"? (dan apakah itu layak untuk dijelaskan?)


Apakah ini terjadi pada saya (pada hal-hal non-teknis) selama wawancara HR ... tidak menyenangkan: /
Matthieu M.

Jawaban:


10

Saya pikir itu hanya masalah membuat kata-kata Anda cocok dengan apa yang Anda rasakan di dalam, dan menempatkan hal yang Anda rasakan paling kuat (pemecahan masalah tanpa ego) sebagai prioritas pertama dalam respons Anda. Ketika seorang rekan kerja menunjukkan nama variabel yang buruk, Anda bisa mengatakan "Saya benar-benar lelah hari itu," atau Anda bisa mengatakan "Anda benar, itu nama yang mengerikan; Saya benar-benar lelah hari itu." atau "Saya yang melakukan itu; saya benar-benar lelah hari itu." atau "Terima kasih telah menemukan itu untuk saya; saya benar-benar lelah hari itu." Dll. Jika Anda memimpin dengan alasan, itu terdengar seperti alasan. Jika Anda memimpin dengan memiliki kesalahan, berterima kasih kepada seseorang karena menemukannya, atau hanya setuju dengan mereka, alasannya tidak terlalu banyak alasan.

Sebagai bonus, ketika Anda mempraktekkan ini, Anda hampir pasti akan menemukan lebih sedikit kebutuhan untuk menawarkan penjelasan bagi mereka "Saya lelah, saya tidak berpikir ada orang yang akan menggunakannya untuk itu, saya sedang terburu-buru" situasi. Anda masih dapat menggunakannya untuk "baik penjualan tidak pernah menyebutkan bahwa mereka memberi tahu pengguna bahwa fitur akan ditambahkan, Bob tidak menjelaskan kepada saya dengan benar, jika Joe memilih nama variabel yang lebih baik, saya akan melakukannya dengan benar, itu berfungsi sampai Anda mengubah situasi spec, ketika akar penyebab dan analisis perubahan yang mendasarinya mungkin diperlukan.


Saya kira itu solusi terbaik. Pada akhirnya saya akan mendapatkan lebih banyak waktu dan lebih banyak energi yang berfokus pada menyetujui dan memperbaiki masalah dan hanya menjelaskan sumber masalah yang saya pikirkan jika ditanya tentang hal itu. Lagipula, secara default, hanya aku yang peduli. Jika mereka peduli mereka akan bertanya, kurasa.
Klaim

12

Kesalahpahaman semacam ini biasa terjadi antara kaum pragmatis dan idealis. Kaum pragmatis hanya berpikir, “ada yang salah ... siapa yang bisa kita salahkan?” Kaum idealis sudah mencoba mencari cara untuk mencegah hal itu dari kesalahan lagi.

Ashton masuk ke San Francisco pada sore hari. Dia mengambil SuperShuttle ke Fisherman's Wharf dan, kelaparan, pergi ke restoran dan memesan setumpuk besar panekuk.

Saat itulah implikasi dari meninggalkan kehidupan sebelumnya di Michigan benar-benar mulai meresap. Dia tidak punya pekerjaan, tidak punya tempat tidur, mobilnya hilang, dia berhutang $ 40.000 dalam pinjaman mahasiswa, dan memiliki $ 173 di dompetnya.

Tapi deh, mereka benar-benar memiliki pelayan yang cantik di San Francisco, pikirnya, mengagumi ikal stroberi dari Molly Ringwald yang mirip berdiri di dekat mesin kasir depan. Mungkin sedikit lebih dari lima kaki. Bintik-bintik gila.

Sementara Ashton menatapnya dari seberang restoran yang sunyi, beberapa anak laki-laki berpakaian bagus datang dan mulai berbicara dengannya. Wisatawan, mungkin, atau pelajar? Apakah ada sekolah di sekitar sini? Pasti ada sekolah di San Francisco. Dia tidak bisa mendengar apa yang mereka katakan, tetapi tampaknya sedikit lebih rumit daripada "bisakah kita memiliki meja dan membeli pancake."

"Molly" mengeluarkan dompetnya dan mencari-cari. Dia memberi anak-anak sejumlah uang. Percakapan berlanjut. Dia mencoba menelepon; tidak ada yang menjawab. Akhirnya dia membuka mesin kasir dan menghitung banyak uang, yang dia berikan kepada mereka.

"Aneh," pikir Ashton, tetapi dia membayar cek, dan pergi ke seberang jalan ke sebuah kafe Internet untuk mencari apartemen di Craigslist.

Hal pertama yang mengejutkannya adalah bahwa harga apartemen itu gila. Kembali di Michigan, ia membayar $ 475 untuk satu kamar tidur yang benar-benar bagus, tetapi di San Francisco, segalanya tampaknya tiga kali lipat dari itu. Tanpa pekerjaan, dia bahkan tidak yakin apakah ada yang mau menyewanya. Sementara dia merenungkan masalah ini, dia melihat pelayan dari tempat pancake keluar, jelas bingung. Dia duduk di halte bus dan mulai menangis.

Sekarang, Ashton tua tidak akan pernah, tidak pernah hanya pergi ke seorang gadis acak di jalan, apalagi yang menangis, tetapi mantra ajaib San Francisco entah bagaimana membuatnya kehilangan penghambatan, jadi dia membeli dua cangkir teh peppermint , pergi ke halte bus, duduk di sebelahnya, dan berkata, “Saya sepertinya punya secangkir teh peppermint tambahan. Apakah kamu menyukainya? "

Gadis itu menatapnya, bingung, dan kemudian tertawa sedikit.

"Maaf," kata Ashton. “Aku biasanya tidak melakukan ini. Saya melihat Anda bekerja di IHOP, dan kemudian ketika saya melihat Anda di sini .... Oh. Ngomong-ngomong, aku Ashton. Dengan huruf N. ”

"Aku Becca," katanya. "Dengan M."

Ashton berkata, “M itu diam, saya kira?” Mereka tertawa sedikit. Becca mengendus-endus. Ashton menemukan saputangan di saku mantelnya, sisa hidup dalam iklim yang sangat dingin.

Mereka mulai berbicara. Ternyata Becca baru saja dipecat.

“Orang tua bodoh itu. Dia tidak mau mendengarkan saya! Saya mengambil sejumlah uang dari kasir untuk menebus putranya sendiri, tetapi dia tidak mau mendengarnya. Dia hanya berasumsi aku mencurinya. ”

"Apa?"

"Yah, anak-anak ini datang ke restoran, mereka adalah teman sekolah Daryl, putra Pak Dimitrious."

"Itu pemiliknya?"

"Baik. Pokoknya anak-anak ini tampak baik, mereka mengatakan bahwa beberapa pengedar narkoba marah pada Daryl karena alasan tertentu dan mereka membutuhkan $ 200 untuk menyelamatkannya. ”

“Selamatkan dia dari apa? Saya tidak mengerti. Bagaimana cara kerjanya? "Tanya Ashton. Itu tidak terdengar seperti kisah nyata. Tapi mungkin begini caranya di California.

“Saya memberi mereka $ 40 dari saya sendiri, tetapi mereka sangat bersikeras bahwa jika mereka tidak menghasilkan $ 200, Daryl akan terluka. Saya tidak dapat menghubungi Mr. Dimitrious melalui telepon, dan saya takut, jadi saya mengambil $ 160 dari register dan memberikannya kepada mereka. Tetapi ketika saya mencoba menjelaskan itu kepadanya, dia hanya membalik dan tidak mau mendengarkan saya. Aku berusaha memberitahunya bahwa Daryl dalam kesulitan, dan yang ingin dia bicarakan hanyalah bahwa aku mencuri darinya. Bagaimana dia bisa memecat saya karena berusaha membantu putranya sendiri? Apa yang salah dengan pria itu? "

Ashton cukup yakin Becca baru saja mendapatkan scammed, tetapi dia tidak bisa memaksakan diri untuk memecahkannya. Dan meskipun dia tampak kesal, dia benar-benar menikmati berbicara dengannya, jadi dia melanjutkan pembicaraan. Dia mulai mengoceh tentang bagaimana, ketika dia bekerja di perusahaan furnitur di Michigan, semua orang harus mengambil kursus yang disebut "Lima Mengapa." Idenya adalah bahwa setiap kali ada yang salah, Anda harus bertanya mengapa harus segera mendapatkan penyebabnya. Lalu Anda bertanya mengapa lagi, untuk mencari tahu apa penyebabnya, dan Anda terus melakukannya, sekitar lima kali, sampai Anda menemukan akar masalahnya.

"Jadi, misalnya, kamu dipecat. Mengapa? Karena uang hilang dari mesin kasir. Mengapa? Karena Anda memberikannya kepada beberapa anak. Mengapa? Karena mereka bilang Daryl dalam masalah. Mengapa?"

"Tunggu, mengapa apa?" Tanya Becca.

"Mengapa mereka memberitahumu Daryl dalam kesulitan?"

Becca berpikir sebentar.

"Aku ditipu, bukan aku."

"Kupikir mungkin kau melakukannya."

Becca terdiam untuk waktu yang sangat, sangat lama. Kemudian dia mulai tertawa, dan itu menulari Ashton, dan mereka berdua tertawa seperti orang gila, dan rasanya luar biasa, setelah hari yang menegangkan.

"Kau benar-benar kutu buku," katanya. "Lima mengapa." Dia harus setuju.

Mereka bersenang-senang. Mereka berjalan di ujung utara, dan mereka berbicara selama berjam-jam. Dia memberitahunya tentang menjadi programmer, dan perusahaan furnitur, dan bagaimana, dalam dua tahun, tidak ada satu hal pun yang dia lakukan di tempat kerja, dan dia muak dengan hal itu, dan memulai kehidupan baru, dan di sinilah dia, tanpa tempat tinggal, pada malam musim dingin di San Francisco.

“Ya ampun,” kata Becca, “Aku tahu tempatnya. Saya tinggal di rumah bersama yang besar di Bukit Rusia. Ada ruangan kosong sekarang. ”

"Di mana Bukit Rusia?" Tanya Ashton.

"Tidak jauh. Aku akan membawamu. Tapi tunggu ... maukah kamu menunggu supaya aku bisa mencoba sekali lagi untuk mendapatkan pekerjaanku kembali? ”

Ashton lebih bahagia dari hari sebelumnya. Hal-hal benar-benar memiliki cara untuk bekerja.

"Tentu!" Katanya, hampir pusing. "Tunggu sebentar." Dan dia mengeluarkan $ 160 dari dompetnya, menyisakan tiga dolar, dan dia memberikannya kepada Becca, dan berkata, "Ambil ini, ini mungkin bisa membantu kamu mendapatkan pekerjaanmu kembali."

"Oh, aku tidak bisa!" Katanya, tetapi Ashton bersikeras, dan mereka sepakat untuk bertemu dalam setengah jam di Steps of Rome di Columbus Ave., di mana Ashton pergi untuk duduk dan merawat secangkir espresso sementara Becca berjalan kembali menuju restoran.

Dan agak terlambat.

Dan satu jam berlalu, lalu satu lagi, dan pelayan Italia itu jelas menyukai Ashton, jadi dia tidak mengganggunya hanya memesan satu kopi dan duduk di meja selama berjam-jam, dan ini tengah malam, lalu jam satu pagi, lalu pagi jam dua pagi, dan pelayan akhirnya berkata, "Dengar, maaf, teman, kami akan tutup, Anda harus pergi."


6
Hei, Joel, ada beberapa ide hebat di sini ... mungkin Anda harus mempertimbangkan sebuah blog?
Macneil

2
-1 untuk jawaban lain. Ini bukan jawaban yang bijaksana untuk pertanyaan yang kompleks, tetapi lebih merupakan kecelakaan yang sedang terjadi.
Josh K

2
@ Macneil: Ini? Ini mengoceh dan berantakan. Lelucon jawaban. Saya menghormati Joel, dan berpikir ia telah menulis beberapa hal yang layak. Ini? Ini sebuah lelucon.
Josh K

2
@ Bob: Pikiran yang bertanya harus mencari jawaban dari tempat lain.
Josh K

1
@sharptooth: OP mengoceh pikiran batinnya tentang bug kepada orang-orang yang tidak peduli dengan apa yang dia pikirkan dan hanya ingin bug mereka diperbaiki. Ini adalah pemborosan waktu yang tidak relevan, seperti kisah anjing Joel yang tak berguna dan tak berguna. Joel mengambil apa yang OP lakukan dan menerjemahkannya ke dalam konteks SE, dan menunjukkan bahwa itu benar-benar menjengkelkan bagi semua orang kecuali orang yang mengoceh. Tidak ada moral dalam cerita ini; ceritanya adalah moral.
Bob Murphy

6

Saya merasa pilihan terbaik adalah dengan mengakui masalahnya dan berjanji untuk memperbaikinya dengan cepat. Orang-orang pada umumnya tidak tertarik mengapa dan bagaimana Anda melakukan kesalahan, satu-satunya pengecualian adalah manajer Anda karena ia perlu terus menilai Anda sesuai dengan profesional.

Adapun menyalahkan orang yang melakukan kesalahan, itu sifat manusia dan Anda tidak bisa menahannya. Saran terbaik adalah membangun penghalang mental dan berusaha untuk tidak menganggapnya terlalu pribadi, jangan biarkan kritik mereka menyentuh Anda. Itu sulit.


6

Jawaban singkat: Anda tidak

Kemungkinannya adalah siapa pun yang menunjukkan kesalahan tidak tertarik mengapa itu salah, mereka hanya ingin memperbaikinya. Fakta bahwa Anda ingin mengetahui mengapa kesalahan itu dibuat dan apa yang dapat Anda pelajari darinya dan dengan demikian meningkatkannya patut dipuji, tetapi sekali lagi siapa pun yang menunjukkan kesalahan itu mungkin tidak tertarik mendengar monolog internal Anda.

tetap melakukan apa yang Anda lakukan, ini membantu Anda meningkatkan. Tapi jangan lakukan itu dengan keras di depan pengguna.


Benar-benar tepat. Jika seorang pelayan di sebuah restoran membawakan saya makanan orang lain, saya hanya ingin dia mengambilnya dan membawakan saya makanan secepat mungkin. Saya tidak ingin mendengar mengapa dia melakukannya.
Bob Murphy

@Klaim: Katakan saja, "Maaf untuk masalahnya. Saya akan memperbaikinya." Hanya itu yang harus Anda katakan, karena hanya itu yang diperhatikan kebanyakan orang.
Bob Murphy

@ Bob Murphy, mengapa repot-repot dengan "maaf?" Kenapa tidak bilang saja, "Tercatat, selanjutnya?" Maaf adalah bagian dari siklus menyalahkan. Itu rusak dan perlu diperbaiki. Tidak ada yang meminta maaf.
Dan Rosenstark

@ Bob Murphy: Ya, Anda tahu, saya minta maaf terlalu sering digunakan waaay, dan biasanya itu tidak berarti bahwa seseorang menyesal - itu hanya kata kunci protokol. Apakah kita perlu frasa protokol di mana tindakan dan sikap nyata adalah apa yang sebenarnya dibutuhkan?
sharptooth

1
@ Seven: Saya sepenuhnya setuju. Bahkan, saya sering berpikir politik Amerika akan mendapat manfaat besar dengan kembali ke duel.
Bob Murphy

1

Bagaimanapun, Anda membuat kesalahan, jadi Anda harus mengakuinya. Anda mungkin memiliki peluang kecil yang sangat kecil untuk menghindarinya, tetapi Anda menulisnya dan dirilis.

Ketika berhadapan dengan orang-orang yang tidak memiliki keahlian teknis atau domain, mengapa Anda memberikan penjelasan terperinci? Entah itu terdengar seperti alasan atau penjelasan yang ada di atas kepala mereka yang akan mereka tafsirkan sebagai alasan.


0

Dalam banyak hal saya tidak berpikir Anda bisa menghindari konflik ini.

Menjelaskan alasan mengapa Anda sampai pada titik mana pun Anda berada adalah penting dalam memahami "gambaran besar" seputar masalah dalam banyak kasus, tetapi akan selalu ada orang yang melihat ini sebagai alasan.

Memilih dengan siapa Anda berkomunikasi adalah yang paling dekat dengan saya dalam mengelola masalah ini. Secara umum, intinya adalah untuk tidak membicarakannya dengan para pelaku bisnis dan hanya mendiskusikannya dengan orang-orang yang akan terlibat dengan solusi teknis.

Bahkan pendekatan itu gagal di kali karena kesalahan hari ini sering dikaitkan dengan persyaratan sebelumnya dan Anda tetap mendapatkan obat di jalur itu.

Secara umum saya mencoba untuk tidak terlalu khawatir tentang hal itu seolah-olah orang akan memilih itu sebagai sesuatu untuk mengangkat sebagai masalah tentang Anda, mereka cenderung cukup termotivasi mereka akan menemukan masalah lain segera setelah Anda dapat "memperbaiki" yang satu ini.


0

Bertanggung jawablah untuk itu. Steven Covey menyebutnya sebagai kemampuan respons: kemampuan Anda merespons. Katakan apa yang akan Anda lakukan di masa depan untuk mencegah melakukan hal seperti itu lagi, dan tindak lanjuti. Secara keseluruhan, Anda harus peduli dengan reputasi jangka panjang Anda, dan bukan momen langsungnya.

Jika Anda mengakui kesalahan, orang akan menghargainya dan lebih menghargai Anda. Ini akan memberi Anda lebih banyak kredibilitas ketika sesuatu bukan kesalahan (atau setidaknya bukan milik Anda sendiri) dan memang perlu penjelasan.

Juga, bahkan jika tidak disampaikan dengan baik, anggap itu sebagai umpan balik yang membangun dan terima kasih kepada siapa pun yang menunjukkan masalahnya. Jika Anda tidak yakin apa yang mereka katakan salah dengan kode Anda, ajukan pertanyaan tindak lanjut.


Saya tidak yakin jawaban Anda menjawab tanggapan saya secara langsung. Saya bertanggung jawab untuk masalah ini dan mencoba memberikan solusi yang baik, tetapi untuk melakukan ini pertama-tama saya harus menemukan mengapa saya melakukan kesalahan kode. Apa pun alasannya, itulah penjelasannya (atau fakta untuk mencoba menjelaskan mungkin?) Yang tampaknya memicu "Anda membuat alasan" memotong kalimat yang hanya menghentikan Anda mencoba menjelaskan apa pun. Yang mengatakan, itu bukan masalah besar bagi saya karena saya masih bisa menyelesaikan masalah, tetapi lebih merupakan masalah komunikasi yang saya dapatkan.
Klaim

Keinginan Anda untuk "menjelaskan" berusaha menyelamatkan wajah. Saya mengatakan Anda harus melakukan itu dengan cara yang berbeda. Saya tidak menjawab pertanyaan Anda di permukaan, saya membantu Anda dengan akar penyebabnya.
Macneil

0

Inilah yang Anda katakan:

"Saya bertanggung jawab penuh. Saya akan melakukan yang terbaik untuk memperbaikinya dan tidak melakukannya di masa depan."

Apa yang bisa seseorang katakan? Mereka menerima apa yang Anda katakan dan terus maju atau mereka mendisiplinkan Anda. Itu dia. Ini menempatkan tanggung jawab kembali pada mereka untuk melakukan sesuatu atau, seperti yang saya katakan, lanjutkan.


Tidak begitu baik ketika alasan kesalahan Anda adalah kesalahan orang lain yang juga perlu diperbaiki.
Kate Gregory

@kate Anda mungkin akan terkejut betapa banyak orang yang bertanggung jawab bisa lolos.
johnny

" hampir selalu) jauh lebih penting daripada siapa yang harus disalahkan
Kate Gregory

@kate tergantung pada pengawas dan suasananya. Dia selalu bisa mengatakan saya bertanggung jawab penuh atas apa pun bagian saya.
johnny

Dia juga bisa berkata, "Maaf ada masalah. Saya akan bekerja dengan anggota tim saya yang lain untuk memperbaikinya."
Bob Murphy

0

Sebagian besar kesalahan ada di sana, karena programmer lupa untuk mempertimbangkan semua kasus. Terkadang Anda menulis kode mengingat satu skenario dan kemudian skenario lainnya gagal. Dalam hal ini jika seseorang meminta jawaban Anda harus "Kasus itu tidak dipertimbangkan. Biarkan saya memperbaikinya, dan kami akan mendokumentasikan bahwa siapa pun yang menyentuh bagian ini dari kode harus kode sesuai dengan kasus ini juga".
Biasanya membuat kesalahan bukanlah masalahnya, tetapi mengulanginya adalah masalah. Oleh karena itu ketika seseorang menunjukkan kesalahan Anda, Anda harus mengatakan, "Terima kasih telah menemukan itu. Saya akan memperbaikinya, dan menyebutkannya dalam pedoman pengkodean."
Tetapi jika seseorang terus menerus menemukan kesalahan bodoh dan jika itu mengganggu Anda, maka setiap kali Anda mengubah kode, pergi ke orang itu dan katakan padanya untuk memeriksa kode untuk kesalahan. Suatu hari dia akan frustasi dan menghentikannya.


1
Jika seseorang terus menemukan kesalahan bodoh dalam kode Anda, Anda harus memastikan untuk memeriksa ulang pekerjaan Anda sebelum mengganggu orang itu untuk melakukan kesalahan Anda memeriksa Anda. Tujuannya adalah untuk menghilangkan kesalahan, jadi mencoba menggagalkan seseorang yang mencoba meningkatkan kualitas bukanlah cara yang tepat.
Adam Lear
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.