มีวิธีใดที่จะได้เร็วขึ้นในการแก้ข้อบกพร่อง? ฉันเพิ่งได้รับคำเตือนจากหัวหน้าของฉัน [ปิด]


129

เจ้านายของฉันเพิ่งบอกฉันว่าฉันจะได้รับการตรวจสอบประสิทธิภาพเชิงลบในวันจันทร์ เขาต้องการพูดคุยกับฉันเกี่ยวกับสาเหตุที่ฉันช้ามากและทำไมอัตราการแก้ไขข้อบกพร่องของฉันจึงต่ำมาก

ฉันรักการเขียนโปรแกรมและการแก้ปัญหา แต่จริง ๆ แล้วฉันหางานของฉันได้ยากจริงๆ

ฉันเป็นโปรแกรมเมอร์มาประมาณ 10 ปีแล้ว แต่นี่เป็นงานลินุกซ์ฝังตัวแบบมัลติเธรดครั้งแรกของฉัน - ฉันอยู่ที่นี่มา 2 ปีแล้วและเห็นได้ชัดว่าทุกคนยังคงดิ้นรนอยู่ และฉันคิดว่าฉันกลายเป็นคนขวัญเสียและรู้สึกว่าด้อยโอกาสฉันได้สูญเสียไฟจำนวนมากที่เกิดขึ้นตอนเริ่มงาน

มีใครเคยอยู่ในสถานการณ์ที่คล้ายคลึงกันและคุณจะเพิ่มอัตราการแก้ไขข้อบกพร่องอย่างไร?


อัปเดต: ฉันมีความเห็น ฉันได้รับ 'โปรแกรมการพัฒนาพนักงาน' 3 เดือน (ประเภทที่ Dunk กล่าวถึง) ไม่แน่ใจว่าฉันจะหันไปทางนี้ได้ไหม แต่ถึงแม้ว่าฉันต้องเดินหน้าต่อไปฉันก็ได้เรียนรู้มากมายจากประสบการณ์นี้

การปรับปรุงอื่น

ตอนนี้ประมาณ 6 สัปดาห์ตั้งแต่รีวิวครั้งแรก คำแนะนำของฉันกับทุกคนที่เผชิญสถานการณ์เดียวกันคือการอ่อนน้อมถ่อมตนพอที่จะวิจารณ์และเรียนรู้จากความผิดพลาด และไม่ต้องกลัวที่จะดูโง่ ถามคำถามมากมาย บอกให้ทุกคนรู้ว่าคุณกำลังพยายามเรียนรู้และถามต่อไปจนกว่าคุณจะเข้าใจ แต่ต้องเตรียมพร้อมสำหรับมันที่จะไม่ออกไปทำงาน ฉันกำลังสร้างแฟ้มสะสมผลงานของรหัส ... รวมทั้งให้ภาพที่ดีที่สุดของฉัน

ยังเป็นอีกหนึ่งการปรับปรุง

ฉันลังเลที่จะใส่สิ่งนี้ไว้ที่นี่เนื่องจากฉันกังวลว่าฉันจะไม่สามารถอ้างถึงนายจ้างในอนาคตไปยังโปรไฟล์สแต็คโอเวอร์โฟลว์ของฉัน ... แต่อย่างไรก็ตามมันอาจจะเป็นที่สนใจสำหรับใครบางคนที่อ่านคำถามนี้ งานไม่กี่สัปดาห์ที่ผ่านมา ฉันอยู่ท่ามกลางการแปรงของทักษะทั้งหมดที่ฉันต้องการ - ฉันได้รับมากจากคำแนะนำที่ได้รับที่นี่


170
ปล่อยให้หัวหน้าของคุณรู้ว่ามันดีจริง ๆ ที่เขาจะเก็บไว้ใช้ในการตรวจทานแทนที่จะพูดถึงเมื่อเขาสังเกตเห็นว่ามันเป็นปัญหา
Blrfl

13
การเขียนโปรแกรมการบำรุงรักษาต้องการบุคคลบางประเภท บางทีมันอาจไม่ใช่สิ่งที่คุณต้องการ ในทำนองเดียวกันการพัฒนาใหม่ต้องมีคนประเภทอื่น คุณพูดถึงการค้นพบเครื่องมือ / เคล็ดลับ / ลูกเล่น คุณสร้างเครื่องมือเหล่านี้ไว้กี่รายการเพื่อใช้เอง? ถ้าคำตอบคือไม่ฉันก็คิดว่าคุณไม่ใช่คนเขียนโปรแกรมบำรุงรักษา หากคุณได้รับการสับเปลี่ยนระหว่างโครงการหลายโครงการเนื่องจากขาดประสิทธิภาพให้ใช้ข้อความดังกล่าวเป็นข้อความที่ชัดเจนว่าคุณไม่ผ่านการรับรองสำหรับตำแหน่งที่คุณอยู่ไปหาสิ่งที่เหมาะสมกับคุณ
Dunk

40
หากคุณต้องเดาว่าคุณถูกสับเปลี่ยนเพราะประสิทธิภาพของคุณการจัดการกำลังทำอะไรผิดพลาด ในทำนองเดียวกันหากคนแรกที่คุณได้ยินเรื่องประสิทธิภาพต่ำกว่า 2 ปีฝ่ายบริหารกำลังทำอะไรผิดพลาด
Michael Shaw

32
@Bee: โดยทั่วไปเมื่อมีคนได้รับการวิจารณ์ที่ไม่ดีก็ถึงเวลาที่จะออก พวกเขาอาจนำคุณไปสู่ ​​"โปรแกรมการพัฒนาพนักงาน" แต่ฉันไม่คิดว่าฉันเคยเห็นใครหายเมื่อพวกเขามาถึงขั้นนั้น เวลาที่ง่ายที่สุดในการหางานคือเมื่อคุณมีงานอยู่แล้ว ดังนั้นถ้าฉันเป็นคุณฉันจะอัปเดตประวัติย่อและเริ่มมองหาที่อื่นเร็ว ๆ นี้ คุณควรระวังให้มากกับประเภทของงานที่คุณทำ ประสบการณ์ 7 ปียังคงออกจากตัวเลือก เมื่อคุณอายุครบ 10 ปี บริษัท จะคาดหวังถึงความเชี่ยวชาญเฉพาะด้าน เลือกพื้นที่ที่คุณชอบและทำได้ดี อ๊ะเพิ่งเห็นคุณเข้าชม 10 แล้ว
Dunk

8
ไม่เพียงพอที่จะเป็นคำตอบ แต่เกี่ยวกับ "วิธีที่จะทำให้เร็วขึ้น": คุณระบุว่าเป็นโดเมนที่คุณกำลังใหม่ใช่หรือไม่ว่าคุณกำลังจะแก้ไขคือการลองผิดลองถูกมากเกินไปและไม่รู้ว่าเกิดอะไรขึ้น "ลึกลงไป"? ในกรณีเช่นนี้การเรียนรู้พื้นฐานอย่างละเอียดจะช่วยให้คุณมองเห็นปัญหาที่อาจเกิดขึ้นได้ดีขึ้น
Matsemann

คำตอบ:


80

คำตอบมากมายได้ตั้งคำถามถึงวิธีการ / ยุทธวิธี / ตัวชี้วัดของเจ้านายของคุณ แต่นั่นอยู่ด้านข้างจุด บางทีคุณช้า ห้องของผู้พัฒนาทุกคนจะต้องมีห้องที่ช้ากว่าห้องอื่นใช่มั้ย (นั่นเป็นเพียงทฤษฎีเซตตรง) ดังนั้นสมมติว่านั่นคือคุณ คำตอบคือทำไมคุณช้า (ชัดเจนว่าเป็นคำถามที่คุณต้องตอบก่อนที่คุณจะสามารถแก้ไขคำถามที่ระบุไว้ของคุณเกี่ยวกับวิธีการได้เร็วขึ้น)

อาจมีเหตุผลทุกประเภท แต่นี่เป็นคำอธิบายที่เป็นไปได้ที่จะต้องพิจารณา:

  1. คุณมีความฉลาดน้อยกว่าพวกเขาจะ เป็นไปได้ใช่มั้ย (มีการศึกษาแสดงให้เห็นว่าเราทุกคนมีน้อยเป็นที่นิยม , น้อยที่น่าสนใจและ (มันจะปฏิบัติตาม) ฉลาดน้อยกว่าเพื่อนของเรา.) ดังนั้นบางทีคุณอาจเป็นเพียงแค่ช้าสติ จากนั้นอีกครั้งในกรณีของคุณฉันคิดว่ามันไม่น่าเป็นไปได้ ภาพรวมอย่างรวดเร็วของโปรไฟล์ StackOverflow ของคุณแสดงให้เห็นว่าคุณมีประวัติการถามคำถามที่ชาญฉลาดในหัวข้อที่หลากหลาย เห็นได้ชัดว่าคุณเป็นนักคิดและอาจเป็นคนดี

  2. คุณกระจายบางเกินไป โปรไฟล์ SO ของคุณแบบเดียวกันนั้นแสดงให้เห็นว่าคำถามของคุณครอบคลุมช่วงกว้างของเทคโนโลยีในช่วง 2 ปีที่ผ่านมา (กราฟิก, เว็บ, python, c ++, c, linux, ฝังตัว, กระทู้, ซ็อกเก็ต ฯลฯ ) โดยส่วนตัวฉันรู้ว่าเมื่อฉันได้รับในสถานการณ์ที่มี (หรือต้องการ) ที่จะเจาะลึกลงไปในลำธารที่แตกต่างกันจำนวนมากฉันพบว่าตัวเองว่ายน้ำในปัจจุบันอย่างรวดเร็วจริงๆ (หรือค่อนข้างช้าจริงๆ) บางทีสิ่งที่คุณต้องการจริงๆนี่คือFOCUS และอาจจะเป็นยาเพื่อสุขภาพของลำดับความสำคัญ มีอยู่แล้วคุณสามารถผลักไสหม้อที่มีความสำคัญน้อยกว่าลงในเตาเผาหลังและเพิ่มความร้อนในจานหลักได้หรือไม่?

  3. คุณไม่สนุก เมื่อเพลิงไหม้ตายเครื่องยนต์ไอน้ำจะถูกทำให้ช้าลง คุณยอมรับในโพสต์ว่ากำลังใจของคุณได้รับผลกระทบอย่างรุนแรงเมื่อเร็ว ๆ นี้ แต่น่าเสียดายที่คุณได้รับการกลืนกินเข้าไปในน้ำวนดูดของตัวเองเสริมประสานลบ - แรงที่ที่สามารถทำลายสะพาน มันเป็นเรื่องที่คุ้นเคยกันดีมาก: งานยาก -> ความเครียด -> พลาดเส้นตาย -> ความเครียดมากขึ้น -> กลไกการเผชิญปัญหาที่ไม่ดี -> ความเครียดเพิ่มขึ้น -> การผัดวันประกันพรุ่ง -> กำหนดเวลาที่ไม่ได้รับ -> วิจารณ์ / นินทา (จริงหรือจินตนาการ) - > เครียดมากขึ้น คุณได้รับรูปภาพ สิ่งนี้ไม่ค่อยนำไปสู่การมีประโยชน์ทุกที่ เรียนบทเรียนจากยุคของฉันในการล่องแก่ง: เมื่อคุณได้รับการดูดใต้น้ำโดยกระแสหมุนเวียนที่ด้านหลังของคลาส 4 อย่างรวดเร็วเสื้อชูชีพของคุณจะไม่ทุ่นให้คุณกลับไปที่ผิวน้ำ กลยุทธ์ที่ดีที่สุด (แม้ว่าจะไม่ใช่การหยั่งรู้) คือการหาก้นแม่น้ำและเดินออกไปจาก riptide ดังนั้นคำแนะนำของฉันสำหรับคุณคือหาพื้นดินเพื่อน (เพื่อนคริสตจักรนิสัยใหม่ที่ดีต่อสุขภาพ ฯลฯ ) และใช้ประโยชน์จากมันเพื่อเอาตัวคุณออกจากวังวน

  4. คุณไม่ได้อยู่ในโซนของคุณ Michael Jordan เป็นนักเบสบอลที่ค่อนข้างดี (ตกลงเขาก็ยังดีกว่าฉัน แต่ก็เป็นผู้เยาว์ตัวเล็ก ๆ ) บางที "ลินุกซ์ฝังตัวแบบมัลติเธรด" อาจไม่ใช่กิ๊กของคุณ แต่การพัฒนาซอฟต์แวร์เป็นสาขาที่กว้างมาก (อย่างที่คุณรู้; cf # 2 ด้านบน) บริษัท ของคุณกว้างพอที่จะหาช่องอื่นได้หรือไม่? ในงานสุดท้ายของฉันฉันได้รับการว่าจ้างเป็นนักพัฒนา SW ที่ฝัง (ฉันไม่เคยมีประสบการณ์ในอาณาจักรนั้น แต่ฉันบอกพวกเขาว่าฉันเป็น "ผู้เรียนรู้เร็ว") ฉันทรุดราวกับหิน แต่ฉันก็ทำงานหนักและพยายามหาปัญหาที่ฉันทำรู้วิธีแก้ปัญหาสำหรับพวกเขา เมื่อมันปรากฏออกมาฉันก็ค่อยๆสามารถย้ายไปสู่ความรับผิดชอบใหม่ที่ฉันสามารถส่องแสงและในที่สุดฉันก็ได้รับการยกย่องเป็นอย่างมาก ดังนั้นคุณอาจจำเป็นต้องสร้างแบรนด์ใหม่ด้วยตัวเอง

ประเด็นคือ: ถ้าคุณช้าก็มีเหตุผล แต่เฮ้ - คุณเป็นวิศวกรซอฟต์แวร์ครับ! แก้ไขปัญหาด้วยตัวคุณเอง!


2
คำตอบที่ยอดเยี่ยมคืออะไร ฉันคิดว่าทุกจุดของคุณจะบังคับให้ฉัน (และเกี่ยวกับ # 1 เดียวบางทีฉันamฉลาดน้อยผมได้ยินว่ามีชนิดต่าง ๆ ของหน่วยสืบราชการลับ -. ดังนั้นบางทีที่เกี่ยวข้องกับ # 4 บางทีฉันคนโง่ Embedded Linux dev แต่บางทีฉันอาจจะดีกว่าในเรื่องของเว็บ ... และตอนนี้ฉันก็คิดถึงสิ่งนี้จริง ๆ แล้วอาจเป็นจริง) อย่างไรก็ตาม - คุณเป็นคนเข้าใจมาก
BeeBand

14
3 และ 4 นั้นใหญ่กว่า (สำหรับโปรแกรมเมอร์) กว่าผู้บังคับบัญชาส่วนใหญ่สามารถจินตนาการได้ หากโปรแกรมเมอร์มีขวัญกำลังใจต่ำเขา / เธอไม่สามารถมีสมาธิในการทำงานได้ สำหรับโปรแกรมเมอร์แล้วขวัญและกำลังใจนั้นเป็นทุกอย่าง
TimG

7
คำตอบที่ยอดเยี่ยม แก้ปัญหาด้วยตัวคุณเองเป็นวลีที่ยอดเยี่ยม btw ฉันหวังว่าฉันจะสามารถลงคะแนนให้คุณอีกเป็นครั้งที่สอง
Kyeotic

2
"มันจะตามมา" ของคุณไม่ทำงานในจุดที่ 1 เนื่องจากความขัดแย้งมิตรภาพสร้างแบบจำลองความสัมพันธ์ระหว่างคนสองคนในฐานะที่เป็นแบบสองทิศทางที่ง่ายระหว่างจุดยอดสองจุดในกราฟในขณะที่กราฟของผู้ที่ "ฉลาด" กว่าใคร ปัจจัยอื่น ๆ อีกมากมายที่ไม่ต้องพูดถึงคือกฎของการถ่ายโอนความร้อนใช้ไม่ได้ ฉันเห็นด้วยกับคะแนน 2,3 และ 4 ในกรณีของ OP ฉันคิดว่าเจ้านายของเขาเป็น douchebag ที่ทนทุกข์ทรมานจากเอฟเฟ็กต์การติดตามหนี้
funkymushroom

1
โปรแกรมเมอร์ดีบั๊ก รักมัน :) คำตอบที่ดีเช่นกัน มีประโยชน์สำหรับฉันไม่ใช่เพราะฉันอยู่ในสถานการณ์นั้น แต่เพราะฉันเห็นได้ในขณะนี้ว่าจะหลีกเลี่ยงได้อย่างไร +1
jammypeach

56

เจ้านายของคุณอาจถูกต้อง: คุณอาจจะ "มีประสิทธิภาพต่ำกว่า" (มากกว่านั้นในอีกหนึ่งนาที) แต่มันอาจไม่ใช่แค่ระดับความสามารถของคุณที่จะตำหนิ ฉันไม่คิดว่ามันจะเป็นการเข้าถึงเพื่อแนะนำกำลังที่อยู่นอกการควบคุมของคุณทำให้คุณเครียดซึ่งส่งผลเสียต่อประสิทธิภาพการทำงานของคุณ

มาดูเหตุผลสองสามประการที่หัวหน้าของคุณอาจนำเสนอสิ่งนี้:

วัฒนธรรมและการเมือง

อาจมีกองกำลังที่อยู่นอกเหนือการควบคุมของคุณทำให้หัวหน้าของคุณต้องแสดงความกังวล สิ่งสำคัญคือต้องเข้าใจระบบที่คุณกำลังทำงานอยู่งานของคุณคือทำให้เจ้านายของคุณดูดี วิธีเดียวที่จะทำเช่นนั้นคือการเข้าใจแรงกดดันที่เขา / เธออยู่ภายใต้

ความสามารถ

เป็นไปได้ว่าความสามารถนั้นไม่ขึ้นอยู่กับที่คุณบอกว่าเขาเปิดเผยอย่างเปิดเผย นี่คือสิ่งที่ฉันจะทำในสถานการณ์นี้:

รับคำติชมจากเจ้านายของคุณเกี่ยวกับวิธีการวัดประสิทธิภาพ คุณไม่ได้ปิดบั๊กได้มากเท่ากับตัว X หรือเปล่า? มีข้อบกพร่องจำนวนหนึ่งที่คุณควรแก้ไขหรือไม่? หากคุณกำลังทำงานคนเดียวคุณต้องทำให้แน่ใจว่าคนที่วัดผลงานของคุณกำลังทำการวัดอย่างเป็นธรรมและไม่ได้ขึ้นอยู่กับแนวคิดที่คิดมาก่อน

หากประสิทธิภาพการทำงานของคุณช้าและขึ้นอยู่กับช่องว่างจริงให้ระบุช่องว่างนั้นและวางแผนอย่างละเอียดพร้อมกับหัวหน้าของคุณเพื่อปิดมัน

รีวิวนี้ยังเป็นโอกาสที่ดีที่จะนำความจริงที่ว่าคุณไม่ได้มีความสุข เป็นการดีที่คุณระบุว่าคุณไม่รักงานนี้ แต่หาสาเหตุ คุณชอบงานอะไรส่วนหนึ่งและคุณไม่ทำอะไร อาจเป็นได้ว่างานนี้ไม่ได้มีไว้สำหรับคุณ ...


2
นั่นเป็นคำตอบที่ดี ฉันมีความคิดที่จะทำเกี่ยวกับสาเหตุที่ฉันไม่สนุกกับงานนี้ ส่วนใหญ่เป็นไฟล์บันทึกที่พวกเขาให้เรามาพร้อมกับข้อผิดพลาดฉันมาเกลียดพวกเขามากกว่าคนอื่น - ฉันเริ่มต้นอย่างสมบูรณ์เสมอและอย่างเต็มที่ในที่มืดด้วยข้อผิดพลาดใด ๆ ที่พวกเขาให้ฉัน ฉันคิดว่านี่เป็น 'ความมืด' ที่ฉันเกลียด
BeeBand

4
หากไม่มีใครพบปัญหาที่คล้ายกันในโครงการเดียวกันนั้นคนส่วนใหญ่จะเริ่มต้น "ในความมืด" เมื่อพวกเขาได้รับข้อผิดพลาดใหม่ จากนั้นตามอาการคุณหาวิธีสร้างปัญหาขึ้นใหม่ซึ่งควรให้แนวคิดว่าจะเริ่มเดาสาเหตุของปัญหาได้จากที่ใด คุณดำเนินการทีละขั้นตอน ไม่มีอะไรที่วิเศษไม่ต้องเกลียดอะไร คุณบอกว่าคุณเกลียดไฟล์บันทึก คุณได้สร้างเครื่องมือสำหรับวิเคราะห์ไฟล์บันทึกเหล่านั้นโดยอัตโนมัติหรือไม่? เพิกเฉยต่อความจริงที่ว่าไฟล์บันทึกควรมีประโยชน์หากไม่เป็นเช่นนั้นไม่นานก่อนที่ฉันจะสร้างเครื่องมือเพื่อช่วยวิเคราะห์พวกเขา
Dunk

1
@ Dunk ใช่ฉันได้สร้างเครื่องมือในการแยกวิเคราะห์ไฟล์บันทึกในรูปแบบต่างๆ ฉันพบภายหลังว่ามีคนสร้างหนึ่งปีแล้วหรือมากกว่านั้น
BeeBand

@Bee: การสร้างเครื่องมือของคุณจะแสดงความคิดริเริ่มที่จำเป็น ไม่มีใครให้ภาพรวมของสภาพแวดล้อมการพัฒนาเมื่อคุณเปลี่ยนระหว่างโครงการหรือไม่ หากมีเครื่องมืออยู่แล้วก็จะแน่ใจว่าดูเหมือนว่าผู้นำโครงการควรแจ้งให้คุณทราบเกี่ยวกับพวกเขา
Dunk

@Dunk re ภาพรวม - ไม่ หัวหน้าทีมคนแรกของฉันแสดงเครื่องมือพิเศษให้ฉัน - แต่ไม่ได้ระบุว่ามันมีประโยชน์สำหรับการแก้ไขข้อผิดพลาดในรูปแบบเฉพาะหรือสามารถแปลไปยังโครงการอื่น ๆ ได้ เมื่อฉันถูกย้ายไปที่โครงการบำรุงรักษาใหม่นี้ไม่มีใครพูดถึงฉันผ่านสภาพแวดล้อมของ dev - ฉันต้องถามรอบ ๆ หลังจากดิ้นรนเพื่อสร้างเครื่องมือของตัวเองเท่านั้นที่ฉันถามเพื่อนร่วมงานและเขาบอกว่าฉันจะใช้เครื่องมือดั้งเดิมได้อย่างไร (NB นี้เป็นเครื่องมือที่แตกต่างจากความคิดเห็นก่อนหน้าของฉัน)
BeeBand

38

สภาพแวดล้อมการทำงานบางอย่างไม่สามารถทำงานได้ ฉันได้เห็นสภาพแวดล้อมที่ไม่มีใครสามารถอยู่รอดได้ (ประหยัดสำหรับผู้ที่อยู่ในช่วงเริ่มต้น) เพราะไม่มีเอกสารมากมายและคำถามก็ท้อใจอย่างเหลือล้น

คุณต้องซื่อสัตย์กับตัวเองเกี่ยวกับความคาดหวังและทรัพยากรที่มีให้เพื่อช่วยให้คุณพบพวกเขา ปัญหาอาจไม่ใช่คุณ

คุณพูดถึงว่ามีคนทำงานคล้าย ๆ กับคุณฉันคิดว่าไม่มีปัญหา แต่มีประสบการณ์มากกว่า 5 ปีกับคุณคุณรู้สึกอย่างไรเมื่อเปรียบเทียบกับเพื่อนของคุณ? พวกเขาเป็นร็อคสตาร์ที่เหนือกว่าคุณอย่างสิ้นเชิง (ในแง่นี้) หรือว่าพวกเขาเหมือนคุณหรือเปล่า บางทีพวกเขาอาจจะรู้จักระบบเมื่อมันง่ายขึ้น ... คุณพูดถึงประสบการณ์การเขียนโปรแกรม 8 ปีก่อนสายงานนี้ คุณไปที่นั่นได้อย่างไร ถ้าคุณทำได้ดีแล้วนั่นควรบอกคุณบางอย่าง

ส่วนที่หลงฉันเป็นบิตเกี่ยวกับคุณอธิบายตัวเองว่าอยู่ในความมืดด้วยความเคารพต่อข้อบกพร่องทั้งหมดที่มาในแบบของคุณ อาจเป็นไปได้ว่ารหัสฐานนั้นกว้างใหญ่และไม่จดที่ความคาดหวังนั้นอาจไม่สมเหตุสมผล

สำหรับคุณที่จะทำให้มันเท่าที่คุณมีหมายความว่าคุณทำสิ่งที่ถูกต้องและมีบางสิ่งบางอย่างที่จะให้คุณ

ฉันคิดว่าบรรทัดล่างคือคุณต้องรู้สึกดีกับตัวเองและสิ่งที่คุณทำ และถ้านั่นหมายถึงการเดินหน้าต่อไป

ดีกว่าที่จะไปกว่ามีงานทำลายชีวิตของคุณ


2
ฉันเคยเห็นทีมในอาชีพการงานของฉันที่ตรงตามที่คุณได้อธิบายไว้ รหัสที่พวกเขารักษานั้นมีขนาดใหญ่และเป็นความลับและข้อมูลเกี่ยวกับวิธีการใช้งานนั้นได้รับการปกป้องอย่างอิจฉาริษยา สมาชิกในทีมใหม่ถูกทิ้งให้อยู่ในอุปกรณ์ของตัวเองและตั้งใจถ่ายโอนเพื่อช่วยชีวิตการทำงานของพวกเขา
Anthony Giorgio

31

ก่อนอื่นหมายเหตุ: คำตอบนี้อาจใช้ได้เฉพาะบางภูมิภาคที่ผิดกฎหมายในการเลิกจ้างพนักงานโดยไม่มีการชดเชย ที่กล่าวว่า ...

นี่อาจเป็นกรณีของการเลิกจ้างที่สร้างสรรค์และเป็นสิ่งผิดกฎหมาย

ชั้นเชิงคือลดขวัญและลดความนับถือตนเองของพนักงานจนกว่าพวกเขาจะลาออกจากงาน เป็นวิธีที่ บริษัท จะประหยัดเงินโดยไม่ต้องจ่ายเงินชดเชยหรือแก้ไขปัญหาที่ต้องเผชิญหน้ากับพนักงานและไล่พวกเขาออก

เขาต้องการพูดคุยกับฉันเกี่ยวกับสาเหตุที่ฉันช้ามากและทำไมอัตราการแก้ไขข้อบกพร่องของฉันจึงต่ำมาก

ความผิดพลาดนี้คลุมเครือมาก เป็นไปไม่ได้ที่ฝ่ายใดฝ่ายหนึ่งจะอ้างสิทธิ์ผิดฝ่ายใดฝ่ายหนึ่ง คุณใช้เวลาหนึ่งเดือนเพื่อแก้ไขข้อบกพร่องหนึ่งข้อ แล้วอะไรล่ะ! นี่ทำให้คุณอยู่ในตำแหน่งที่รับได้โดยต้องนำเสนอข้อเท็จจริงเพื่อสนับสนุนการเรียกร้องของคุณว่าต้องใช้เวลาหนึ่งเดือน เมื่อพิจารณาจากทักษะประสบการณ์และความรู้ในปัจจุบันของคุณ ในฐานะนายจ้างมันเป็นหน้าที่ของนายจ้างในการจัดการเวลาและความพยายามของพนักงานของเขา นายจ้างต้องเป็นบุคคลที่มีส่วนร่วมในความเสี่ยงที่เกี่ยวข้องกับการแก้ไขข้อบกพร่อง ไม่ใช่พนักงาน เขามักจะเลือกที่จะมอบหมายข้อบกพร่องให้คนอื่น

หากคุณเป็นผู้รับเหมาและระบุไว้ในสัญญาของคุณที่จะต้องรับผิดชอบในการแก้ไขข้อบกพร่องนั่นเป็นเรื่องที่แตกต่างอย่างสิ้นเชิง

ผิดหรือไม่ที่นายจ้างจะบ่นว่าคุณใช้เวลานานเกินไป? ไม่อย่างแน่นอน แต่เขาไม่สามารถทำให้คุณต้องรับผิดชอบและเขาไม่สามารถยิงคุณได้ เขาสามารถพูดกับคุณได้ว่า "เราไม่มีข้อบกพร่องอีกแล้วที่ต้องใช้ทักษะของคุณและคุณก็ถูกลาไป" แต่พวกเขาต้องบอกคุณว่ามีปัญหาใหม่เกิดขึ้นที่คุณสามารถแก้ไขได้หรือไม่ มิฉะนั้นพวกเขาจะต้องยุติด้วยการแยก สิ่งที่เขาไม่สามารถทำได้คือให้งานที่คุณไม่สามารถจัดการได้แล้วบ่นเกี่ยวกับมัน ฉันคิดว่านี่ผิดกฎหมาย

ฉันรักการเขียนโปรแกรมและการแก้ปัญหา แต่จริง ๆ แล้วฉันหางานของฉันได้ยากจริงๆ

มีความแตกต่างอย่างมากระหว่างการทำงานที่คุณหายากและนายจ้างของคุณให้งานที่ยากเกินไป หากคุณรู้สึกว่างานที่มอบหมายให้คุณทำเพื่อกีดกันคุณไม่ให้มีอาชีพกับ บริษัท นี่อาจผิดกฎหมาย

ฉันเป็นโปรแกรมเมอร์มาประมาณ 10 ปีแล้ว แต่นี่เป็นงานลินุกซ์ฝังตัวแบบมัลติเธรดครั้งแรกของฉัน - ฉันอยู่ที่นี่มา 2 ปีแล้วและเห็นได้ชัดว่าทุกคนยังคงดิ้นรนอยู่

นี่คือเหตุผลที่ฉันคิดว่าคุณพบว่าตัวเองอยู่ในระหว่างการปลดออกอย่างสร้างสรรค์ พวกเขาไม่ได้มีความสุขกับคุณดังนั้นพวกเขาจึงกองพึมพำกับคุณจนกว่าคุณจะจากไป

และฉันคิดว่าฉันกลายเป็นคนขวัญเสียและรู้สึกว่าด้อยโอกาสฉันได้สูญเสียไฟจำนวนมากที่เกิดขึ้นตอนเริ่มงาน

นายจ้างมีหน้าที่จัดหาสภาพแวดล้อมการทำงานที่ปลอดภัยและเป็นบวก หากไม่มีข้อมูลเพิ่มเติม (น่าจะเป็นเรื่องส่วนตัว) เป็นเรื่องยากสำหรับบุคคลภายนอกที่จะบอกว่าเกิดอะไรขึ้นที่นี่ ขอคำปรึกษาฟรีจากทนายความการจ้างงาน พวกเขาจะสามารถบอกคุณได้ว่าคุณกำลังเล่นอยู่

อ้างอิง

ฉันไม่ใช่นักกฎหมาย แต่ Google มีเอกสารบางอย่างที่พูดถึงหัวข้อการเลิกจ้างที่สร้างสรรค์ซึ่งควรค่าแก่การอ่านก่อนที่คุณจะเข้าสู่การตรวจสอบในวันจันทร์ จุดสำคัญที่นี่คือระวังการลดเงินเดือนความอัปยศอดสูและการเปลี่ยนแปลงอย่างฉับพลันในอาชีพของคุณกับ บริษัท

ข้อเท็จจริงที่เกี่ยวข้องระวัง:

  • ความล้มเหลวในการสนับสนุนพนักงานอย่างเหมาะสมระหว่างสภาพการทำงานที่ยากลำบาก
  • มีระเบียบวินัยมากเกินไปของพนักงานกำหนดการเปลี่ยนแปลงในสถานที่ทำงานของพนักงานที่แจ้งให้ทราบสั้น
  • กำหนดลดเงินเดือนหรือค่าจ้าง

คำถาม & คำตอบทางกฎหมาย: การเลิกจ้างที่สร้างสรรค์

เหตุผลในการเรียกร้องสำหรับการเลิกจ้างที่สร้างสรรค์

วิกิพีเดีย

องค์ประกอบของการเลิกจ้างที่สร้างสรรค์


11
ไม่ใช่เรื่องผิดกฎหมายที่จะให้ความเห็นเกี่ยวกับประสิทธิภาพเชิงลบ แต่พวกเขาจะต้องมีวัตถุประสงค์และยอมรับเกณฑ์ที่เป็นไปได้สำหรับงานและสนับสนุนคุณ
pjc50

9
ฉันคิดว่าบางทีฉันอาจจะตอบสนองเกินจริงเมื่อฉันโพสต์คำตอบนั้น แต่การอ่านโพสต์ของคุณมันสะท้อนกับประสบการณ์ของฉัน การแก้ไขข้อบกพร่องไม่ใช่สิ่งที่สามารถวัดได้ด้วยบริบทด้านประสิทธิภาพ ฉันใช้เวลา 3 เดือนครั้งเดียวเพื่อแก้ไขข้อผิดพลาดเดียว โดยปกติแล้วพวกสมาร์ทเป็นคนที่ได้รับข้อบกพร่องอย่างหนัก
Reactgular

9
ฉันลงคะแนนเนื่องจากไม่เห็นหลักฐานใด ๆ ที่แสดงว่าคุณเป็นทนายความและอ้างว่าให้คำแนะนำทางกฎหมาย นอกจากนี้หากพนักงานคนอื่น ๆ กำลังแก้ไขข้อบกพร่อง X โดยเฉลี่ยต่อเดือน แต่ OP กำลังแก้ไข X / 10 นั่นคือวัตถุประสงค์และสมเหตุสมผลอย่างแน่นอน
Andy

7
@ ขอบคุณสำหรับการแบ่งปันว่าทำไมคุณถึงลงคะแนน ฉันยอมรับว่าอัตราส่วนการแก้ไขข้อบกพร่องเป็นตัวบ่งชี้ แต่สิ่งที่เป็นวัตถุประสงค์เกี่ยวกับการบอกใครสักคนในวันศุกร์ว่าพวกเขามีการทบทวนเชิงลบในวันจันทร์ถัดไป นอกเหนือจากการทำให้พวกเขาเหงื่อออกในช่วงสุดสัปดาห์อย่างแนบเนียน ไม่ปลอดภัยหรือไม่ที่จะสันนิษฐานว่าผลลัพธ์ที่ต้องการจะเป็นไปได้ว่าพนักงานจะไม่แสดงในวันจันทร์เพื่อการตรวจสอบ? จะไม่จัดว่าเป็นการเลิกจ้างที่สร้างสรรค์? ฉันหวังว่าฉันสามารถเปลี่ยนมุมมองของคุณเพราะการเลิกจ้างที่สร้างสรรค์เป็นปัญหาที่เกิดขึ้นในอุตสาหกรรมของเรา
Reactgular

7
ไม่มีวิธีที่ผู้พิพากษาจะตัดสินว่านี่คือการเลิกจ้างที่สร้างสรรค์ คุณสามารถปิดบังและอ่านหนังสือกฎหมาย แต่กฎหมายประเภทนี้มีไว้สำหรับกรณีที่พนักงานถูกคุกคามหรือถูกทารุณกรรมซึ่งเป็นสถานการณ์ที่ไม่เป็นมิตร จากสิ่งที่ OP บอกว่าพวกเขาได้รับแจ้งว่าพวกเขาได้รับการตรวจสอบในเชิงลบเพราะเขา / เธอไม่ได้ซ้อนกันกับเพื่อนเท่าอัตราการแก้ไขข้อผิดพลาด นั่นเป็นสถานการณ์ที่ยากลำบาก แต่ไม่ค่อยเป็นมิตรและไม่ผิดกฎหมาย บางทีเจ้านายอาจจะมีไหวพริบมากขึ้น แต่ข้อเสนอแนะไม่จำเป็นต้องถูกจำกัดความคิดเห็นอย่างเป็นทางการ
pdubs

26

บางทีคุณอาจถูกเปรียบเทียบกับหนึ่งในโปรแกรมเมอร์ต้นฉบับของโครงการ ฉันรู้ว่าในฐานะผู้พัฒนาดั้งเดิมของหนึ่งในโครงการที่ฉันทำงานฉันมีข้อได้เปรียบอย่างมากเมื่อแก้ไขข้อบกพร่องในนั้น ฉันไม่คิดว่ามันเป็นเพราะการขาดเอกสารมันเป็นเพียงแค่ที่ฉันสามารถกระโดดได้อย่างง่ายดายไปสู่ปัญหาที่อาจเกิดขึ้นเพราะสมองของฉันรู้รหัสทั้งหมด

หากคุณกำลังถูกเปรียบเทียบกับสิ่งนั้นคุณก็จะไม่สามารถวัดผลได้ มันจะทำให้คุณมีเวลามากขึ้นในการทำโปรเจ็กต์และคุณจะไม่รู้ว่าจุดโต้ตอบที่เป็นไปได้ทั้งหมดอยู่ที่ไหน

ฉันอ่านความคิดเห็นของคุณเกี่ยวกับการไม่หาข้อมูลเกี่ยวกับเครื่องมือและลูกเล่นอื่น ๆ ที่โปรแกรมเมอร์ใช้เพื่อแก้ปัญหา บางทีสำหรับการแก้ไขข้อบกพร่องครั้งต่อไปคุณต้องลองจับคู่การเขียนโปรแกรม มันมีประโยชน์อย่างเหลือเชื่อ ผลัดกันขับรถแป้นพิมพ์ ทำมากของการพูดคุย

คุณสามารถใช้โน้ตบุ๊กหรือไวท์บอร์ดเพื่อกำหนดเส้นทางของฟังก์ชันเธรดและอายุการใช้งานล็อกและทำเครื่องหมายตำแหน่งที่คุณสังเกตพฤติกรรมส่วนต่าง ๆ และตำแหน่งที่คุณสามารถแทรกโพรบใหม่ได้

การแก้ปัญหาการทำเกลียวในระดับต่ำเหล่านี้อาจเป็นเรื่องยากและฉันก็เห็นใจคุณมาก ฉันต้องวิเคราะห์ไฟล์บันทึกหลายกิกะไบต์ก่อนที่จะพบปัญหาสองบรรทัด และคุณรู้อะไรไหม ฉันจ้องที่นั่นหลายวันก่อนที่ฉันจะขอความช่วยเหลือจากวิศวกรผู้น้อยผู้ซึ่งเคยฝึกงานเมื่อหนึ่งปีก่อนและเขาก็พบวิธีการใหม่และพบปัญหาในหนึ่งชั่วโมง ดังนั้นหลังจากที่คุณใช้เวลาเป็นข้อผิดพลาดได้รับตาใหม่ในนั้น มันสามารถช่วยได้มาก!


3
นี่คือการตอบสนองที่ยอดเยี่ยม ฉันประทับใจมาก
Daniel Hollinrake

26

หนึ่งในความผิดปกติของการจัดการที่พบบ่อยที่สุดในอุตสาหกรรมนี้คือไม่เข้าใจว่าการแก้ไขข้อบกพร่องนั้นยากมาก ฉันมีประสบการณ์เกือบ 20 ปีและฉันยังต้องใช้เวลาตลอดสัปดาห์เพื่อหาข้อผิดพลาดบรรทัดเดียวที่ทำให้โปรแกรมขัดข้องหนึ่งครั้งจากห้าสิบครั้ง แล้วถ้าผู้จัดการของฉันไม่เข้าใจสิ่งเหล่านี้พวกเขาทำให้ฉันยุ่งยากในการเปลี่ยนรหัสบรรทัดหนึ่งสัปดาห์

คุณทำอะไรได้บ้าง

  • จดบันทึกในขณะที่คุณดีบัก เปิดหน้าต่างตัวแก้ไขเสมอและเขียนกระแสสำนึกของคุณ มันไม่จำเป็นต้องมีเหตุผลกับใครนอกจากคุณ คุณอาจพบว่าสิ่งนี้ช่วยให้คุณดีบักได้เร็วขึ้น แต่ก็หมายความว่าคุณมีสิ่งที่เป็นรูปธรรมที่จะแสดงให้เห็นว่าคุณไม่ได้เล่น Nethack ตลอดทั้งสัปดาห์

  • เปรียบเทียบบันทึกกับเพื่อนร่วมงานของคุณทั้งหมด โดยทั่วไปจะใช้เวลานานเท่าใดในการแก้ไขข้อบกพร่อง ข้อบกพร่องของพวกเขาคงที่? บ่อยครั้งพวกเขาเปลี่ยนสิ่งเล็ก ๆ น้อย ๆ และพบว่าตัวเองถูกฝังอยู่ใต้กองซ้อนของผลที่ตามมา คำตอบสำหรับคำถามเหล่านี้จะให้ความรู้สึกว่าคุณกำลังดิ้นรนจริงๆเมื่อเทียบกับส่วนที่เหลือของแผนก

  • ทำความรู้จักกับผู้คน QA และฝ่ายสนับสนุนลูกค้า พวกเขาเป็นคนที่มีแนวความคิดที่ดีที่สุดว่าบั๊กสำคัญแค่ไหน บ่อยครั้งที่สิ่งนี้มีความสัมพันธ์เพียงเล็กน้อยหรือไม่มีเลยกับความยากของข้อบกพร่องดังนั้นคุณสามารถเล่นเกมระบบได้เล็กน้อยและพยายามที่จะมอบหมายข้อบกพร่องที่มีความสำคัญสูงและต่ำ (นี่ไม่ใช่การโกงจริง ๆ ทีมที่มีการจัดระเบียบอย่างดีจะทำตามข้อบกพร่องเหล่านั้นก่อนเสมอ)

  • หากเจ้านายของคุณไม่ได้ให้ผลตอบรับที่เพียงพอต่อการทำงานของคุณเป็นเวลาสองปีนั่นเป็นปัญหาที่เกิดขึ้นก่อนในการตรวจสอบประสิทธิภาพการทำงานนี้และจากนั้นเมื่อคุณได้รับผลการทดสอบในครั้งนี้เพื่อยกระดับกับเจ้านายของคุณ สุภาพและโดยเฉพาะอย่าให้พวกเขาเห็นว่าคุณโกรธแค่ไหน


4
"การดีบักนั้นยากกว่าการเขียนรหัสสองเท่า" - Brian Kernigan (พ่อของ C, UNIX)
TimG

4
@TimG: และเหมือนกับโปรแกรมเมอร์คนอื่น ๆ Kernigan ก็ประเมินความยากลำบากต่ำเกินไป
mu สั้นเกินไป

ว้าวฉันอยากจะชี้ให้เห็นว่านี่เป็นคำถามที่ยากมากและฉันประหลาดใจจริงๆที่เห็นคำตอบที่ดีและลึกซึ้งที่นี่ ขอบคุณ
maksymko

12

ในขณะที่คุณอาจรักการเขียนโปรแกรมและการแก้ปัญหาอาจมีคำถามว่าคุณใช้สิ่งที่คุณเรียนรู้ไปยังพื้นที่อื่นได้ดีเพียงใด โหลสุดท้ายหรือข้อผิดพลาดที่คุณแก้ไขคล้ายกันมากแค่ไหนสิ่งที่ช่วยให้คุณแก้ไขได้มีประโยชน์หรือไม่ นี่เป็นส่วนหนึ่งของการมองย้อนกลับไปในสิ่งที่คุณทำและใช้เวลานานแค่ไหนในการทำสิ่งนั้น เพียงแค่ความคิดที่จะต้องพิจารณา

ประการที่สองฉันจะดูว่าคุณทำงานอย่างไร คุณได้รับการขัดจังหวะเป็นประจำและเมื่อคุณพยายามแก้ไขข้อบกพร่อง A คุณจะได้รับแจ้งว่าข้อบกพร่อง B และ C มีความสำคัญสูงกว่าหรือไม่ พิจารณาอย่างรอบคอบว่าการเปลี่ยนแปลงประเภทใดในงานที่คุณทำอาจช่วยคุณได้ที่นี่เนื่องจากเป็นส่วนหนึ่งของสิ่งที่หัวหน้าของคุณต้องการทราบ

ฉันมีที่ทำงานบางแห่งบอกฉันว่าพวกเขาไม่ชอบว่าใช้เวลานานแค่ไหนในการทำให้งานเสร็จ หลักสูตรเหล่านี้คือสถานที่ที่ถ้าฉันทำสิ่งหนึ่งสิ่งใหม่ 5 อย่างจะถูกทิ้งไว้บนตักของฉันและทำให้ง่ายต่อการถูกครอบงำ แม้ว่าฉันจะไม่ได้ทำงานที่นั่นอีกต่อไป แต่ฉันก็ไม่มีวิธีแก้ปัญหาที่ดีสำหรับวิธีที่จะให้ความสนใจกับสิ่งเล็ก ๆ น้อย ๆ เพื่อที่ฉันจะไม่รู้สึกว่าฉันกำลังพยายามที่จะชำนาญ 1,000 สิ่งในคราวเดียว หากฉันสามารถรู้สิ่งสำคัญสองสามอย่างที่จะทำให้เสร็จและวิธีการตัดสินงานของฉันฉันก็ดีกว่าถ้าฉันมีรายการ "สิ่งที่ต้องทำ" ที่มีความยาวหนึ่งไมล์และไม่มีใครสนใจถ้าฉันได้รับ ส่วนหนึ่งของมันทำ ดังนั้นอาจเป็นไปได้ว่ามีองค์ประกอบทางวัฒนธรรมภายในองค์กรแม้ว่าฉันจะระมัดระวังในการขอสิ่งต่าง ๆ ที่นี่เพื่อเปลี่ยนแปลง


2
ended up getting micromanaged until I was terminated- ฉันเพิ่งดูโปรไฟล์ SO ของคุณและคุณได้เด้งกลับมาจากนั้นอย่างชัดเจนดังนั้นฉันจึงพบว่าคำตอบของคุณดีขึ้น ฉันจะพูดคุยเกี่ยวกับจุดแรกของคุณในวันจันทร์ - ฉันได้รับข้อบกพร่องจากพื้นที่ที่แตกต่างกันมาก
BeeBand

10

หลังจากสองปีในการทำงานมันควรจะเห็นได้ชัดสำหรับทุกคน (คุณเจ้านายของคุณเพื่อนร่วมงานของคุณ) เป็นที่ที่คุณยืนอยู่ นั่นคือคุณไม่ควรทราบว่าคุณทำไม่ดีเพียงปีละครั้งเท่านั้น สภาพแวดล้อมการทำงานในอุดมคติจะให้ข้อเสนอแนะอย่างต่อเนื่อง

อย่างไรก็ตามเกี่ยวกับวิธีการแก้จุดบกพร่องรหัสแบบมัลติเธรด: คุณไม่ได้กล่าวถึงว่าเป็นรหัสของคุณหรือของคนอื่น มี debuggers ใหม่และตัววิเคราะห์แบบสแตติกที่สามารถจัดการพร้อมกันได้ แต่จริงๆแล้วการรู้รูปแบบจะเป็นทางออกที่ดีที่สุดของคุณเนื่องจากคุณจะรู้ว่าควรมองหาอะไร

หากคุณเข้าใจว่าส่วนสำคัญและเงื่อนไขการแข่งขันและการหยุดชะงักทำงานอย่างไรคุณจะอยู่ในตำแหน่งที่ดีกว่าในการมองเห็นสิ่งต่าง ๆ ที่ไม่คาดคิด หากคุณเห็น "การสื่อสาร" ระหว่างสองเธรดโดยไม่มีตัวแปรเงื่อนไขหรือหากมีการปิดการใช้งานทรัพยากรโดยไม่มีคำสั่งเฉพาะหรือหากมีการประกาศตัวแปรท้องถิ่นโดยstaticไม่มีเหตุผลชัดเจนแสดงว่าคุณมีข้อบกพร่องที่เป็นไปได้! ดังนั้นเรียนรู้แนวปฏิบัติที่ดีที่สุดของโดเมนของคุณและคุณจะอยู่ในตำแหน่งที่ดีกว่าที่จะตัดสินเมื่อบางสิ่งผิดปกติ


2
ใช่นี่ไม่ใช่รหัสของฉัน - มันเป็นระบบฝังตัวที่แผ่กิ่งก้านสาขากว้างใหญ่ได้รับการออกแบบครั้งแรกเมื่อ 10 ปีที่แล้ว ฉันคิดว่าคุณพูดถูกเกี่ยวกับรูปแบบ - ฉันต้องย้อนกลับไปสู่พื้นฐาน
BeeBand

1
@BeeBand มันจะเป็นการดีที่จะรู้ว่าคุณมี หวังว่าสิ่งที่ได้ผล
Daniel Hollinrake

10

อย่าดิ้นรนเพียงลำพังเว้นแต่คุณจะต้องทำ รับสมัครเพื่อนร่วมงาน ให้พวกเขาช่วยล่าสัตว์บั๊ก ถามพวกเขาเกี่ยวกับกระบวนการคิดและเครื่องมือของพวกเขา อาจกล่าวถึงสิ่งนี้ในการตรวจสอบของคุณเป็นส่วนหนึ่งของแผนการปรับปรุง หากทุกคนที่อยู่รอบตัวคุณทำได้ดีขึ้นในระบบนี้พวกเขาอาจรู้บางสิ่งที่เฉพาะเจาะจงหรือไม่


มันจะน่าสนใจถ้ารู้ว่า BeeBand ทำสิ่งนี้แล้ว การอ่านความคิดเห็นและคำตอบดูเหมือนว่าเป็นสภาพแวดล้อมที่ไม่เป็นมิตร
Daniel Hollinrake

1
ฉันเห็นอกเห็นใจกับสิ่งนั้น ฉันรู้ว่าสิ่งที่เป็นเหมือนอยู่ใน บริษัท ที่ทีมงาน dev อยู่ภายใต้การทำงาน โชคดีที่ในกรณีของฉันฉันทำงานกับเพื่อนร่วมงานที่ยอดเยี่ยมและเราก็มองหาซึ่งกันและกัน มีใครที่คุณสามารถจับคู่กับ? เวลาที่ใช้ในการฝึกอบรมคุณและช่วยให้คุณมีประสิทธิผลมากขึ้นจะเป็นประโยชน์แก่ทุกคน จากเสียงของสิ่งต่าง ๆ ที่คุณใส่ใจและมีความขยันขันแข็งเพื่อ บริษัท ของคุณจะได้รับประโยชน์จากการรักษาคุณไว้
Daniel Hollinrake

8

เจ้านายของฉันเพิ่งบอกฉันว่าฉันจะได้รับการตรวจสอบประสิทธิภาพเชิงลบในวันจันทร์ เขาต้องการพูดคุยกับฉันเกี่ยวกับสาเหตุที่ฉันช้ามากและทำไมอัตราการแก้ไขข้อบกพร่องของฉันจึงต่ำมาก

โปรดทราบว่าในสิ่งที่ บริษัท ไม่ผิดปกติจะไม่เกิดขึ้นกับคำสั่งซื้อนี้ หากหัวหน้าของคุณกังวลเกี่ยวกับผลงานของคุณเขาควรกำหนดเป้าหมายระยะสั้นและพูดคุยเกี่ยวกับผลลัพธ์ของคุณเพื่อค้นหาว่าปัญหาเกิดขึ้นที่ใด

แต่เขาตัดสินใจที่จะให้ความเห็นเชิงลบแก่คุณแล้วหาสาเหตุ ดูเหมือนว่าเขาไม่เต็มใจที่จะมีส่วนร่วมในปัญหาและเขาก็ต้องการผลลัพธ์ในตาราง

อย่ามุ่งหวังที่จะแก้ไขข้อบกพร่องได้เร็วขึ้น มุ่งประเมินความสามารถของคุณเองตรวจสอบว่าเพื่อนร่วมงานของคุณทำงานอย่างไรพวกเขารู้ว่าพวกเขารู้อะไรและรู้ว่านี่ไม่ใช่ บริษัท ในอุดมคติ

สำหรับเคล็ดลับที่เป็นประโยชน์ฉันใช้โค้ดขนาดสั้นและมีเดียวิกิของตัวเองเพื่อจดบันทึก ฉันมักจะนึกถึงสิ่งที่หนังสือที่จะอ่านต่อไปและทิศทางที่จะไปเรียนรู้ของฉันต่อไป การเรียนรู้เป็นเส้นทางสู่การทำงานที่ดีขึ้นและมีความสุขในชีวิต


7

ก่อนอื่นเพิ่มความมั่นใจ:

ทำไมต้องทนทุกข์ทรมาน? คุณสามารถหางานที่พวกเขาจะคิดว่าคุณเป็น "พระเจ้า" เพียงเพราะคุณสามารถทำสิ่งที่ฝังตัวลินุกซ์โดยไม่คำนึงถึงอัตราการแก้ไขข้อบกพร่องของคุณ

อย่างไรก็ตามมันเป็นไปไม่ได้ที่จะกำหนดเวลาในการตามล่าแมลง การล่าสัตว์เป็นทักษะไม่ต้องสงสัยเลยและประสิทธิภาพในการนั้นมีคุณค่าสูง

คุณอาจพลาดเคล็ดลับพื้นฐานที่คนอื่นรู้ซึ่งทำให้คุณช้าลง

ตัวอย่างเช่นถ้าคุณและฉันกำลังทำงานกับมิดเดิลแวร์ Linux บางตัวและฉันกำลังใช้ Valgrind เพื่อค้นหาปัญหาความเสียหายของหน่วยความจำและสภาวะการแข่งขันของข้อมูลในขณะที่คุณพึ่ง gdb และ printf ฉันอาจจะเตะก้นของคุณแม้ว่า คุณฉลาดกว่าฉัน

นอกจากนี้คุณมีความเข้าใจในการเกิดพร้อมกันอย่างไร? หากคุณพัฒนามาสิบปีแล้ว แต่ประสบการณ์ส่วนใหญ่นั้นไม่ได้มีรหัสแบบมัลติเธรดนั่นอาจเป็นปัญหา

คุณควรศึกษารายละเอียดมัลติเธรด: มากกว่าเพียงแค่รู้วิธีใช้ API แต่ "รับ" ในระดับลึก หากคุณกำลังเขียนโปรแกรมแบบมัลติเธรดคุณควรเป็นนักพัฒนาซอฟต์แวร์ที่สามารถดูโค้ดเบสจากระยะทางหนึ่งไมล์และตรวจสอบสถานการณ์การแข่งขันเดดล็อกผู้รุกรานลำดับความสำคัญความอดอยาก ...


1
ปัญหาที่ใหญ่ที่สุดที่เกิดขึ้นพร้อมกันคือการเขียนโค้ดที่ไม่มีข้อผิดพลาดง่ายกว่าการเขียนบั๊กในรหัสบั๊ก โดยเฉพาะอย่างยิ่งถ้ารหัสนั้นถูกต้องเกือบ และข้อบกพร่องมักจะไม่ได้อยู่ในที่เดียว แต่กระจายอยู่หลายแห่ง
gnasher729

5

ฉันเพิ่งอ่านหนังสือทำงานได้อย่างมีประสิทธิภาพด้วยรหัสมรดกและทำให้ฉันมีความมั่นใจเพิ่มขึ้นอย่างมากเมื่อจัดการกับปัญหาในรหัสฐานใด ๆ

หากรหัสที่คุณใช้มีน้อยกว่าที่สมบูรณ์แบบฉันคิดว่าหนังสือเล่มนี้น่าจะช่วยได้ ฉันพบว่าหลายครั้งเพื่อแก้ไขข้อผิดพลาดฉันต้อง refactor รหัสที่ล้อมรอบก่อนเพื่อให้เข้าใจได้และจากนั้นเมื่อฉันเข้าใจรหัสแล้วหวังว่าจะทำให้รหัสทดสอบได้ติดตามและ แก้ไขปัญหาน้อยของการทดสอบ (บางครั้งฉันก็เขียนโค้ดใหม่เพื่อทำความเข้าใจ แต่จากนั้นย้อนกลับการเปลี่ยนแปลงของฉันเพื่อลดความเสี่ยงในการแนะนำข้อบกพร่องใหม่จากนั้นฉันใส่การแก้ไขข้อบกพร่องของฉันเทคนิคนั้นใช้เทคนิคจากหนังสือเล่มนี้)

ฉันคิดว่าข้อเสนอแนะของฉันแก้ไขปัญหาของคุณได้เพียงบางส่วนและค่อนข้างทางอ้อม แต่หนังสือเล่มนี้คุ้มค่าที่จะอ่านไม่ว่าจะเกิดอะไรขึ้นเนื่องจากการทำงานกับรหัสดั้งเดิมนั้นเป็นสิ่งที่หลีกเลี่ยงไม่ได้สำหรับนักพัฒนาซอฟต์แวร์


ขณะนี้ฉันกำลังอ่านคำแนะนำของคุณ
BeeBand

3

ถามผู้บังคับบัญชาของคุณว่าความเร็วในการแก้ไขข้อบกพร่องของคุณคืออะไรและความเร็วในการแก้ไขข้อบกพร่องของทีมคืออะไร สำคัญกว่าถามเขาว่าความเร็วของการแก้ไขข้อบกพร่องวัดได้อย่างไร ...

นี่เป็นตัวชี้วัดชนิดหนึ่งที่ไม่ได้เป็นตัวชี้วัด ถ้ามันจะเป็นก็จะไม่น่าเชื่อถือยิ่งกว่า LOC (แม้ว่าการวัดสิ่งที่แตกต่างกัน) และหากไม่มีการวัดที่เหมาะสมก็ไม่มีเหตุผลที่จะกล่าวหาคุณในสิ่งใด


สันนิษฐานก็วัดเป็นปัญหาปิด / หน่วยของเวลา มันอาจจะสมเหตุสมผลที่จะพูดว่า "ดีข้อผิดพลาดบางอย่างใช้เวลานานกว่าตัวอื่น ๆ " แต่ถ้า OP ทำงานในส่วนที่ยากเป็นพิเศษของรหัสและคนอื่น ๆ กำลังทำสิ่งง่าย ๆ
Caleb

3

ยอมรับว่าคุณทำงานกับนายจ้างและ / หรือลูกค้าที่ไม่ใช่สำหรับพวกเขา อย่าลังเลที่จะพูดถึงว่าในการสัมภาษณ์เพียงเพื่อตั้งค่าบันทึกตรงจากจุดเริ่มต้น

คุณเป็นมืออาชีพที่ลงทุนในธุรกิจขนาดเล็กของคุณมากนั่นคือตัวคุณเอง

คุณยินดีที่จะทำงานในขณะที่มีสหภาพแห่งความสนใจขับเคลื่อนคุณออกจากชั้นวางในแต่ละวัน

หากแรงขับดันนั้นไม่อยู่ที่นั่นเป็นระยะเวลาหนึ่งให้เดินหน้าต่อไป

คุณกำลังเสียเวลาและพลังงานของคุณไปกับคนทำงานที่ไม่สนใจ / ทักษะที่ได้รับการปรับปรุง / การมอบหมายงานที่ท้าทายและ / หรือน่าสนใจสำหรับคุณในการทำงาน นั่นคืองานของฝ่ายบริหาร นอกเหนือจากนั้นพวกเขาบริสุทธิ์เหนือศีรษะ .....

ทำให้ความรักของคุณดำเนินต่อไปซึ่งเป็นกุญแจสำคัญ


2

ฉันเคยอยู่ในสถานการณ์ที่คล้ายกันเพราะกลัวที่จะขอความช่วยเหลือ ตัดสินโดยสิ่งที่คุณพูดในความคิดเห็นนี้ ...

"แต่สิ่งที่น่าผิดหวังคือมีเครื่องมือ / เคล็ดลับ / กลอุบายที่ฉันค้นพบหลังจากอยู่ที่นั่นมาหนึ่งปีครึ่งแล้วฉันเปลี่ยนจากทีมหนึ่งไปอีกทีมหนึ่ง เครื่องมือ 'ซ่อน' เหล่านี้บ่อยๆ "

... คุณอาจมีปัญหาแบบเดียวกันกับที่ฉันทำ การดีบักเป็นงานฝีมือมากพอ ๆ กับการเขียนโค้ดที่ไม่ต้องการการดีบักในครั้งแรก การเฝ้าดู devs อื่น ๆ ที่ทำงานผ่านปัญหาการแก้ไขข้อบกพร่องอาจมีความรู้สูง ขอความช่วยเหลือเมื่อคุณมีปัญหาในการคัดแยกบางอย่าง โดยเฉพาะอย่างยิ่งถ้าคุณกำลังคลุมดินที่คุณไม่เคยมีมาก่อน และทำอย่างนั้นก่อนที่จะถึงเวลาต้องตกใจเพราะคุณไม่ได้ทำอะไรเลย

ที่กล่าวว่าฉันเห็นด้วยกับความคิดเห็นที่ผู้บริหารกำลังทำอะไรผิด หากใครบางคนกำลังดิ้นรนกับบางสิ่งบางอย่างพวกเขาควรได้รับความช่วยเหลือก่อนที่ความคิดเห็นเชิงลบจะเริ่มต้นขึ้น นรกถ้าใครในทีมกำลังดิ้นรนและไม่เคยได้รับความช่วยเหลือฉันจะบอกว่าสมาชิกทุกคนในทีมกำลังทำอะไรผิดพลาด (แม้ว่านั่นอาจเป็นผลโดยตรงจากการที่คนดูอัตราการแก้ไขบั๊กอย่างใกล้ชิด)


2

สิ่งที่ขาดหายไปจาก OP คือการกล่าวถึงกระบวนการหรือวิธีการที่ทำซ้ำเพื่อแก้ไขข้อบกพร่อง

ดังนั้นก่อนอื่นให้จดบันทึกกระบวนการที่คุณทำตาม ตรวจสอบให้แน่ใจว่าได้บันทึกสิ่งที่แต่ละขั้นตอนในกระบวนการมีไว้เพื่อให้บรรลุ

คุณสามารถร่างกระบวนการว่ามีงานเช่นนี้:

  1. ตรวจสอบให้แน่ใจว่าคุณเข้าใจอย่างถ่องแท้ว่ารายงานนั้นมีปัญหาอะไร
  2. พยายามทำให้เกิดปัญหาอีกครั้ง
  3. เริ่มแบ่งปัญหาออกเป็นชิ้นเล็ก ๆ
  4. คิดถึงสาเหตุที่เป็นไปได้ของปัญหา
  5. ทดสอบสมมติฐานเหล่านั้น

มันจะช่วยได้หากทราบว่ามีข้อบกพร่องเกิดขึ้นเป็นเวลานานหรือมีการเปลี่ยนแปลงเมื่อเร็ว ๆ นี้ หากข้อผิดพลาดได้รับการแนะนำกับการเปลี่ยนแปลงล่าสุดที่ทำรีวิวโค้ดและ / หรือเพียงแค่อ่านรหัสที่ผู้คนกำลังสร้างสามารถช่วยได้

ฉันคิดว่าถ้าคุณสามารถกำหนดปัญหาได้อย่างชัดเจนตัวอย่างเช่น "ฉันมีปัญหาในการทดสอบสมมติฐานเพื่อทดสอบเมื่อพยายามแก้ไขข้อบกพร่อง" จากนั้นคุณจะได้รับคำแนะนำที่มุ่งเน้นมากขึ้น

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.