คุณสามารถเป็นผู้จัดการและโปรแกรมเมอร์ในเวลาเดียวกันได้หรือไม่? [ปิด]

การจัดการโปรแกรมเมอร์คนอื่น ๆ ในขณะที่คุณเป็นส่วนหนึ่งของกำลังการเขียนโปรแกรม

เป็นรูปแบบทั่วไปมากอย่างน้อยใน บริษัท ที่ฉันทำงานให้

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

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

อัปเดต : คำถามของฉันรวมถึงการจัดการของ บริษัท (ซึ่งเป็นกรณีของฉัน) ไม่ใช่การจัดการทีมโดยเฉพาะ แต่ฉันสนใจทั้งสองอย่างแน่นอน

ขึ้นอยู่กับจำนวนและประเภทของการเขียนโปรแกรมที่คุณต้องทำและจำนวนและประเภทของหน้าที่การจัดการที่คุณต้องทำ

การเป็นผู้จัดการหมายถึงการถูกขัดจังหวะจำนวนมากการเปลี่ยนแปลงวิธีการและสิ่งต่าง ๆ เช่นการประชุม ฯลฯ

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

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

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

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

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

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

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

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

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

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

ฉันเป็นผู้จัดการโครงการเขียนโปรแกรมมาหลายปีโดยมี บริษัท โครงการและทีมต่างๆ

การจัดการโครงการและการเขียนโปรแกรมเป็นงาน / บทบาทที่แตกต่างกันอย่างมากซึ่งฉันขอยืนยันว่าคุณไม่สามารถทำได้ทั้งสองอย่างในเวลาเดียวกันในระดับ "ยอดเยี่ยม" มันเป็นการประนีประนอม - ปรมาจารย์ไม่มีแจ็คของการซื้อขายทุกประเภท

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

ฉันเห็นทั้งสองสถานการณ์ ผู้จัดการ Dev ที่ทำ {บางเปอร์เซ็นต์ของเวลา} ของการเขียนโค้ดและตัวจัดการ dev ไม่ได้ทำการเข้ารหัสเลย

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

(แน่นอนมี บริษัท ที่คุณสามารถเลื่อนผ่าน Dev, Dev นำ - แตกต่างจากผู้จัดการ Dev แน่นอน - ไปยังตำแหน่งเช่นสถาปนิก ฯลฯ )

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

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

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

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

สำหรับผู้ที่พิจารณาเส้นทางนี้คำแนะนำ:

• หาทางออกจากบทบาทสถาปัตยกรรมและระบุผู้นำในกลุ่มของคุณ

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

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

• ช่วยให้ทีมของคุณเติบโต: มีอิสระมากขึ้นจัดระเบียบตัวเองเชี่ยวชาญด้านเทคนิคเพิ่มระดับการรับรู้

• ในหลาย ๆ ทางคุณเป็นสะพานเชื่อมระหว่างทีมกับโลกภายนอก ส่วนสำคัญของการมุ่งเน้นของคุณควรอยู่นอกทีม

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

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

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

เป็นเรื่องธรรมดามาก (ตามที่คุณพูด) เพื่อดูสิ่งนี้ใน บริษัท ที่เริ่มต้น

ฉันคิดว่าไม่

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

ฉันรู้จักเพื่อนร่วมงานอีกคนที่รับบทบาทการจัดการจากบทบาทนำของทีมและหยุดเขียนโค้ดภายในหนึ่งเดือน (แม้ว่าเขาจะพยายามทำทั้งสองอย่าง)

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

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

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

Spolsky เขียนในบทความของเขาในDeveloper Abstraction Layerต่อไปนี้:

"ด้วย บริษัท ซอฟต์แวร์สิ่งสำคัญอันดับแรกของการจัดการจำเป็นต้องสร้างสิ่งที่เป็นนามธรรมสำหรับโปรแกรมเมอร์"

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

อดีตเจ้านายของฉันพยายาม มีการแทรกแซงจากบทบาทการจัดการของเขามากเกินไป

เขายังคงเป็นหนึ่งในนักพัฒนาที่ดีที่สุดที่ฉันรู้จัก

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

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

เพื่อให้แน่ใจว่าไม่มี !!

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

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

ด้วยความปรารถนาดีและพยายามโพสต์เหล่านี้ต่อไป พวกคุณยอดเยี่ยมมาก

อ่านส่วน "การขาดเส้นทางอาชีพการเขียนโปรแกรมเป็นศูนย์กลาง" ที่เว็บไซต์นี้ สิ่งที่ดีงามและมีความเกี่ยวข้องมาก: http://c2.com/cgi/wiki?ProgrammingIsNotFun

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

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

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

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

ดังนั้นฉันเดาว่าไม่มีคำตอบที่ชัดเจน แต่ฉันมักจะหลีกเลี่ยงการปะปนกันมากเกินไป 2 เซนต์ของฉัน

ฉันได้อ่านแล้วว่าผู้จัดการโครงการซอฟต์แวร์ควรเป็นผู้เขียนโค้ดเอง

ฉันคิดว่าผู้จัดการเป็นผู้จัดการด้วยเหตุผลหนึ่ง - เพื่อจัดการ ฉันจะใช้นี่เป็นกฎง่ายๆ ... บางคนสามารถเป็นดาบสองคม

ฉันรู้กรณีที่มันทำงาน ชายคนนี้เป็นคนบ้างานดังนั้นเขาจึงทำงานเต็มเวลาในฐานะผู้จัดการและเกือบเต็มเวลาในฐานะโปรแกรมเมอร์

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