คำถามติดแท็ก communication

ตัวอย่างเช่นมีตัวอย่างทั่วไปใน JS เพื่อรับค่าเริ่มต้น: function f(x) { x = x || 'default_value'; } ข้อมูลโค้ดประเภทนี้ไม่สามารถเข้าใจได้ง่ายโดยสมาชิกทุกคนในทีมของฉันระดับ JS ของพวกเขาต่ำ ฉันไม่ควรใช้เคล็ดลับนี้หรือไม่? มันทำให้โค้ดอ่านน้อยลงโดยเพียร์ แต่อ่านได้มากกว่าต่อไปนี้ตาม JS dev ใด ๆ : function f(x) { if (!x) { x = 'default_value'; } } แน่นอนว่าถ้าฉันใช้เคล็ดลับนี้และเพื่อนร่วมงานเห็นมันพวกเขาก็สามารถเรียนรู้บางสิ่งได้ แต่บ่อยครั้งที่พวกเขาเห็นสิ่งนี้ว่า "พยายามฉลาด" ดังนั้นฉันควรลดระดับรหัสของฉันหรือไม่หากเพื่อนร่วมทีมของฉันมีระดับต่ำกว่าฉัน

156 teamwork  communication  skills 

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

140 communication  skills 

ฉันได้รับมอบหมายให้สอน codebase ใหม่ให้กับทีมอื่น แต่ฉันก็ยังประสบปัญหาอยู่ เมื่อใดก็ตามที่ฉันไปจริงเดินผ่านรหัสกับคนที่เราไม่ได้ไกลมากก่อนที่จะออกกำลังกายทั้ง devolves เป็นbikeshedding (สมาชิกขององค์กรที่ให้น้ำหนักสัดส่วนกับปัญหาเล็ก ๆ น้อย ๆ ) การออกกำลังกาย เนื่องจากพวกเขาไม่รู้จัก codebase แต่คิดว่าพวกเขาต้องการช่วยปรับปรุงพวกเขาจึงมุ่งเน้นไปที่สิ่งที่พวกเขาสามารถเข้าใจได้: Why is that named that? (2 นาทีเพื่ออธิบายสาเหตุที่ตั้งชื่อนั้นใหม่ 10 นาทีอภิปรายชื่อใหม่) Why is that an abstract base class rather than an interface? (เพื่ออธิบาย 2 นาที, 10+ นาทีอภิปรายถึงข้อดีของการตัดสินใจนี้) ... และต่อไป ตอนนี้ไม่ได้รับฉันผิด - ชื่อที่ดีและดีการออกแบบที่สอดคล้องกันมีความสำคัญ แต่เราไม่เคยได้พูดคุยเกี่ยวกับสิ่งที่รหัสจริงไม่หรือวิธีการที่ระบบการออกแบบในลักษณะที่มีความหมายใด ๆ ฉันได้ทำผู้ตัดสินการประชุมเพื่อให้ผู้คนหลุดพ้นจากการเสียสละเหล่านี้ แต่พวกเขาหายไป …

139 design  communication  knowledge-transfer 

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

120 communication  estimation  release-management 

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

93 communication 

เรากำลังทำงานเกี่ยวกับผลิตภัณฑ์ขนาดใหญ่ที่ได้รับการผลิตประมาณ 5 ปี codebase นั้น .. กำลังทำงานอยู่ ไม่ค่อยดี แต่มันใช้งานได้ ฟีเจอร์ใหม่ ๆ จะถูกนำไปผลิตและทดสอบด้วย QA ขนาดเล็ก ข้อบกพร่องได้รับการแก้ไข ฯลฯ แต่ไม่มีใครยกเว้นฉันเขียนการทดสอบหน่วย ไม่มีใครใช้พลังของ "การติดตาม" ข้อบกพร่องลงโดยการเขียนการทดสอบหน่วยเพื่อให้แน่ใจว่าข้อผิดพลาดพิเศษ (กรณีทดสอบ) นี้จะไม่เกิดขึ้นอีกเลย ฉันได้คุยกับฝ่ายบริหาร ฉันได้พูดคุยกับนักพัฒนา ฉันได้พูดคุยกับทุกคนใน บริษัท ทั้งหมด ทุกคนพูดว่า: "ใช่เราต้องเขียนบททดสอบเพิ่มอีก!" ประมาณหนึ่งปีที่แล้ว ตั้งแต่นั้นมาฉันได้บังคับให้แนะนำการตรวจสอบโค้ดล่วงหน้า ( Gerrit ) และการรวมอย่างต่อเนื่อง ( Jenkins ) ฉันจัดการประชุมเกี่ยวกับการทดสอบหน่วยและฉันก็แสดงให้เห็นถึงประโยชน์ของการเขียนการทดสอบหน่วย แต่ดูเหมือนไม่มีใครสนใจ คำถามที่ 1: ฉันจะกระตุ้นเพื่อนร่วมงานให้เขียนการทดสอบหน่วยได้อย่างไร Q2: ฉันจะยังคงมีแรงจูงใจในการปฏิบัติตามมาตรฐานคุณภาพรหัสส่วนตัวของฉันได้อย่างไร (บางครั้งมันน่าผิดหวังจริงๆ!) PS: ข้อเท็จจริงที่น่าผิดหวังบางอย่าง (เข้าถึงได้ใน 1 …

92 unit-testing  development-process  teamwork  communication 

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

90 management  communication  technical-debt 

ฉันสังเกตเห็นการกล่าวถึงมากขึ้นเรื่อย ๆ (ทั้งในโพสต์ที่นี่และในคำบรรยายลักษณะงานจริง) ของ "พอร์ตการลงทุน" ของโปรแกรมเมอร์ - โดยทั่วไปแล้วโปรไฟล์สาธารณะของพวกเขาในเว็บไซต์เช่นนี้GitHubฯลฯ เรื่องนี้มีความสำคัญขนาดไหนและ บริษัท ต่างๆ (โดยเฉพาะ บริษัท ที่เพิ่งเริ่มธุรกิจ) จะปฏิเสธ (หรือยกเลิกทันทีโดยไม่ต้องสัมภาษณ์เลย) ผู้สมัครที่โดดเด่นอื่น ๆ ที่ไม่มีสถานะออนไลน์? โดยส่วนตัวแล้วฉันต้องการให้โปรไฟล์ออนไลน์ต่ำมาก ชื่อของฉันที่นี่ไม่สามารถระบุตัวฉันได้และฉันมีที่จับอื่น ๆ สำหรับไซต์อื่น ฉันมีหน้า Facebook สปาร์ตัน (และเป็นส่วนตัวอย่างสมบูรณ์) ฉันทำโค้ดด้วยตัวเอง แต่รหัสอยู่ในที่เก็บในเครื่อง โดยทั่วไปข้อมูลเกี่ยวกับฉันที่ออนไลน์น้อยลง ฉันเห็นนักออกแบบที่ต้องการแฟ้มสะสมผลงานออนไลน์บางส่วน แต่สำหรับโปรแกรมเมอร์นี่เป็นผลลบที่ใหญ่มากเมื่อค้นหางานหรือไม่

77 communication  skills 

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

74 communication 

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

71 refactoring  teamwork  communication  code-ownership 

ตัวติดตามบั๊กสำหรับโปรเจคที่มีขนาดเหมาะสมดูเหมือนจะเป็นเรื่องง่ายสำหรับฉัน - มันทำให้การจัดระเบียบปัญหานับแสนเป็นเรื่องง่ายโดยไม่เกิดปัญหาการชนหรือการมั่วสุมกัน ดังนั้นเมื่อฉันเห็นโครงการขนาดใหญ่จริง ๆ เช่น Git โดยใช้รายชื่อผู้รับจดหมายเป็นวิธีหลักในการประสานงานการบำรุงรักษาและการพัฒนาฉันก็รู้สึกปลิวไปนิดหน่อย ตัวอย่าง: Git -หน้าชุมชน : ... รายงานข้อผิดพลาดควรถูกส่งไปยังรายการจดหมายนี้ ระบบติดตามบั๊ก Debianตาม Wikipedia: ... คุณสมบัติที่เป็นเอกลักษณ์คือมันไม่มีรูปแบบของเว็บอินเตอร์เฟสเพื่อแก้ไขรายงานบั๊ก - การแก้ไขทั้งหมดจะกระทำผ่านอีเมล เครื่องมือติดตามบั๊กสมัยใหม่หลายรุ่นมีการรวมที่ดีมากกับอีเมล (คุณสามารถรับความคิดเห็นหรือการแจ้งเตือนเกี่ยวกับข้อผิดพลาดที่คุณกำลังรับชมหรือที่ได้รับมอบหมายให้คุณ) รวมถึงระบบควบคุมเวอร์ชัน (คอมมิชชัน .) สิ่งนี้จะต้องทำด้วยตนเองพร้อมกับรายชื่อผู้รับจดหมายและคุณจะได้รับอีเมลจำนวนมากเกี่ยวกับข้อบกพร่องที่คุณไม่สนใจ ดังนั้นอะไรคือข้อดีหลักของรายชื่อผู้รับจดหมายผ่านตัวติดตามบั๊กบนเว็บ เหตุใดบางโครงการขนาดใหญ่จึงใช้รายการส่งจดหมายเท่านั้น

65 project-management  communication  issue-tracking  email 

นักพัฒนาซอฟต์แวร์เกือบทุกคนต้องตอบคำถามจากฝ่ายธุรกิจเช่น: เหตุใดจึงต้องใช้เวลา 2 วันในการเพิ่มแบบฟอร์มติดต่ออย่างง่ายนี้ เมื่อนักพัฒนาประเมินงานนี้พวกเขาอาจแบ่งออกเป็นขั้นตอน: ทำการเปลี่ยนแปลงฐานข้อมูล เพิ่มประสิทธิภาพการเปลี่ยนแปลงฐานข้อมูลเพื่อความเร็ว เพิ่มส่วนหน้า HTML เขียนโค้ดฝั่งเซิร์ฟเวอร์ เพิ่มการตรวจสอบ เพิ่มจาวาสคริปต์ฝั่งไคลเอ็นต์ ใช้การทดสอบหน่วย ตรวจสอบให้แน่ใจว่าการตั้งค่า SEO ใช้งานได้ ใช้การยืนยันทางอีเมล refactor และเพิ่มประสิทธิภาพรหัสสำหรับความเร็ว ... สิ่งเหล่านี้อาจอธิบายได้ยากสำหรับบุคคลที่ไม่ใช่ด้านเทคนิคซึ่งโดยทั่วไปแล้วเห็นว่างานทั้งหมดเป็นเพียงการรวบรวม HTML และสร้างตารางเพื่อเก็บข้อมูล สำหรับพวกเขามันอาจจะเป็น 2 ชั่วโมงสูงสุด ดังนั้นจะมีวิธีที่ดีกว่าในการอธิบายว่าทำไมการประมาณการจึงสูงถึงผู้ที่ไม่ใช่นักพัฒนา

60 communication  estimation 

ฉันจัดการทีมนักพัฒนาเล็ก ๆ ในแอปพลิเคชันซึ่งอยู่ในช่วงกลางของวงจรชีวิตภายใน บริษัท ใหญ่ น่าเสียดายที่นี่หมายถึงมีการแบ่งงานการเขียนโปรแกรม 30/70 เป็น "งานด้านเทคนิคอื่น ๆ " โดยทั่วไป งานนี้รวมถึง: ทำงานกับทีม DBA / Unix / Network / Loadbalancer ในงานต่างๆ การวางและจัดการคำสั่งซื้อฮาร์ดแวร์หรือโครงสร้างพื้นฐานในภูมิภาคต่างๆ กำลังรันการทดสอบที่ยังไม่ได้ย้ายไปยัง CI การวิเคราะห์ สนับสนุน / สืบสวน มันยุติธรรมที่จะบอกว่านักพัฒนาทุกคนชอบที่จะเขียนโค้ดมากกว่าที่จะทำภารกิจทางโลกมากกว่านี้ดังนั้นฉันพยายามแจกงานเขียนโปรแกรมสนุก ๆ ให้กับทีม ทีมส่วนใหญ่ได้รับการว่าจ้างเพราะถึงแม้ว่าพวกเขาอาจไม่มีทักษะการเขียนโปรแกรมยอดเยี่ยมในการเขียนคอมไพเลอร์ / เกมของตัวเอง / ระบบการซื้อขายที่มีความถี่สูง ฯลฯ พวกเขาเป็นนักสื่อสารที่ดี และค่อนข้างนำทางระบบราชการที่ซับซ้อนที่นี่ พวกเขาเป็นนักพัฒนาที่ดี แต่พวกเขาก็เป็นเจ้าหน้าที่เทคนิคที่ดีทุกด้าน อย่างไรก็ตามสมาชิกคนหนึ่งของทีมอาจมีทักษะการเขียนโค้ดโดยเฉลี่ยสูงกว่า แต่ทักษะการสื่อสารต่ำกว่าค่าเฉลี่ย ตามเนื้อผ้าผู้จัดการฝ่ายพัฒนาคนก่อนมีแนวโน้มที่จะให้งานการเขียนโปรแกรมแก่เขาและไม่ใช่งานทางโลกที่มีรายชื่อด้านบน อย่างไรก็ตามฉันไม่รู้สึกว่าสิ่งนี้ยุติธรรมสำหรับคนอื่น ๆ ในทีมที่แสดงความสามารถในการพัฒนาชุดทักษะรอบด้านที่จำเป็นสำหรับแผนกไอทีขนาดใหญ่ของธุรกิจ ฉันควรทำอย่างไรในสถานการณ์เช่นนี้? ถ้าฉันยังคงทำงานเขียนโปรแกรมให้เขาต่อไปฉันรู้ว่ามันจะเสร็จเร็วขึ้น …

52 teamwork  management  communication  maintenance  team-leader 

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

52 refactoring  communication  technical-debt 

ฉันกำลังคิดถึงการนำเสนอสั้น ๆ ที่ทำงานเกี่ยวกับการใช้ Stack Overflow เป็นทรัพยากรสำหรับงานประจำวันของคุณ ประสบการณ์ของคุณกำลังทำอะไรอยู่? คุณคิดว่าเป็นทรัพยากรที่ถูกต้องหรือไม่ที่จะบอกเพื่อนร่วมงานของคุณเกี่ยวกับมันหรือคล้ายกับบอกพวกเขาเกี่ยวกับ Google ว่าเป็นทรัพยากรหรือไม่ มีวิธีที่ดีกว่าในการทำมัน? ฉันเอนตัวไปถามด้านข้างของ Stack Overflow แทนที่จะตอบคำถามเหล่านี้เพื่อหลีกเลี่ยงการโต้แย้งที่คุณไม่ควรทำ เพียงแค่ติดตามผล เดิมทีฉันไม่ต้องการตั้งคำถามเฉพาะเจาะจงกับกรณีของตัวเองมากเกินไป งานนำเสนอของฉันจะเป็นการพูดคุยอย่างรวดเร็วสี่นาทีเท่านั้นซึ่งฉันจะพูดซ้ำหลายชั่วโมงไปยังกลุ่มต่าง ๆ ฉันอาจถามคำถามก่อนที่จะพูดคุยกับ Stack Overflow และอ้างถึงในระหว่างการนำเสนอ หวังว่าฉันจะได้รับกิจกรรมระหว่างชั่วโมง ฉันจะพูดคุยสั้น ๆ เกี่ยวกับเว็บไซต์ Stack Exchange อื่น ๆ ที่เหมาะสมกับผู้ชมเนื่องจากไม่ใช่นักพัฒนาทั้งหมด ฉันคิดว่า Super User, Server Fault และโปรแกรมเมอร์ควรทำงานได้ดี ฉันจะไม่ทำการนำเสนออีกสองสามเดือนเนื่องจากมีการจัดกำหนดการใหม่ แต่ฉันจะอัปเดตว่าฉันจะไปได้อย่างไร

45 productivity  communication