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


49

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

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

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

ความลับคืออะไร?


24
เป็นคำถามที่ดีมาก ผู้จัดการส่วนใหญ่ที่ฉันทำงานให้ดูนักพัฒนาที่แย่ที่สุด (รหัสและการออกแบบที่แย่จริงๆ) ว่าดีที่สุดในทีมเพราะพวกเขาส่งมอบตรงเวลาเสมอ จากนั้นก็เป็นคนอื่นในทีมที่กวาดและดูแลพวกเขา ผู้จัดการควรอ่านโค้ดตอนนี้จากนั้น ...
Martin Blore

18
โปรดทราบว่าสิ่งที่ทำให้ 'โปรแกรมเมอร์ที่ดี' สำหรับโปรแกรมเมอร์อาจไม่เหมือนกับสิ่งที่ทำให้ 'โปรแกรมเมอร์ที่ดี' กับผู้จัดการ
GrandmasterB

11
เวลาส่วนใหญ่ที่พวกเขาทำไม่ได้
biziclop

1
ดูเหมือนว่าคำตอบของผู้จัดการควรรู้ได้อย่างไรว่าคน ๆ นั้นเป็นโปรแกรมเมอร์ที่ดีหรือไม่ดี?
Jigar Joshi

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

คำตอบ:


31

โดยทั่วไปผู้จัดการจะดู

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

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

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


ฉันคิดว่าสิ่งที่สำคัญที่สุดของหัวข้อเหล่านี้คือโปรแกรมเมอร์ทำสิ่งต่าง ๆ ให้สำเร็จหรือไม่? - ฉันเพิ่งทำเสร็จโดยเพิ่มโปรแกรมเมอร์ทำสิ่งต่าง ๆตามกำหนดเวลาหรือไม่?
Herberth Amaral

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

4
Herberth: "สิ่งที่ทำเสร็จแล้ว" (ตรงเวลาหรือไม่) ไม่เพียงพอเพราะสมาชิกในทีมคนอื่น ๆ
Cercerilla

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

23

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

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

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

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

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

นอกจากนี้ยังมีปัจจัยในการจัดการกับมนุษย์ด้วย ไม่มีวิศวกรคนใดเหมือนคนอื่น ๆ ดังนั้นพวกเขาจึงไม่เปล่งประกายในแสงเดียวกัน หนึ่งเขียนรหัสข้อบกพร่องที่ยอดเยี่ยมฟรี แต่อีกคนช่วยแก้ปัญหาตัดขวางที่ทำลายรหัสของทุกคน หนึ่งดีมากในบุคคลหนึ่งดีกว่าในการเขียน หนึ่งอันไม่ต่อเนื่องกันเวลา 9:00 น. อันหนึ่งออกจากที่นี่ภายในเวลา 15.00 น. มีความจำเป็นบางอย่างที่ต้องถอยออกไปค้นหาว่าอะไรเป็นประโยชน์ต่อทีมมากที่สุดและอะไรคือปัจจัยของความลำเอียงส่วนตัว (เช่นความปรารถนาที่จะฆ่าเจ้าผู้นั้น 4:00 น. เพียงเพราะฉันไม่สามารถทำงานได้จนถึง 11: 00 น.)


2
ดูเหมือนว่าคำตอบของผู้จัดการควรรู้ได้อย่างไรว่าคน ๆ นั้นเป็นโปรแกรมเมอร์ที่ดีหรือไม่ดี?
Jigar Joshi

จากประสบการณ์ของฉันที่องค์กรฉันเคยทำงานกับผู้จัดการเศร้าไม่มีแบนด์วิดท์เพื่อดูรหัสนักพัฒนาทุกคน
Doug T.

@ Jigar Joshi - ไม่ทราบว่าผู้จัดการทุกคนทำได้อย่างไร - นี่คือสิ่งที่ฉันทำเมื่อถูกขอให้แสดงความคิดเห็นเกี่ยวกับประสิทธิภาพหรือให้คำแนะนำ
bethlakshmi

@ pythagras - คำถามตอบโต้ของฉันจะเป็น "ผู้จัดการคนไหน?" ผู้จัดการ 40 คน - ไม่แน่นอนไม่ได้ ผู้จัดการ 10 คน - อาจจะไม่ฆ่าคุณแอบใน 1 ชั่วโมงต่อคนสแกนรหัสที่รู้จักกันว่าเป็นพื้นที่ที่สำคัญ 1 ชั่วโมงต่อพนักงาน 10 คนในช่วง 6 เดือนที่ดูเหมือนจะเป็นไปได้ง่าย
bethlakshmi

12

สิ่งนี้แตกต่างกันไปขึ้นอยู่กับความเชี่ยวชาญด้านเทคนิคของผู้จัดการ

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

2
คุณรู้ไหมว่า "ผู้พัฒนานำ" ทำให้ฉันนึกถึงทฤษฎี exogenesis ซึ่งระบุว่าสิ่งมีชีวิตบนโลกถูกสร้างขึ้นโดยมนุษย์ต่างดาว ใช่ผู้จัดการอาจขึ้นอยู่กับการสังเกตของนักพัฒนาตะกั่ว แต่เป็นผู้จัดการคนนี้ที่ทำให้นักพัฒนา "นำ"! สิ่งใดที่นำเรากลับมาสู่ปัญหา: ผู้บริหารรู้ได้อย่างไรว่าใครจะเป็นผู้นำ
P Shved

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

if you're somehow able to look like you've having a direct influence on the outcome. นั่นคือสิ่งที่ถูกเอาเปรียบมากที่สุดจากการรับโบนัสที่ดี แต่ผู้พัฒนาโค้ดไม่ดี
IsmailS

7

โดยทั่วไปแล้วพวกเขาทำไม่ได้

นั่นคือเหตุผลที่การเขียนโปรแกรมเป็น "ตลาดสำหรับมะนาว" http://en.wikipedia.org/wiki/The_Market_for_Lemons

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

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

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


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

5

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

ฉันจะเริ่มต้นด้วยการวางนัยทั่วไปโดยรวม: ผู้จัดการส่วนใหญ่ไม่สามารถบอกโปรแกรมเมอร์ "ดี" จากโปรแกรมเมอร์ "ไม่ดี"

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

พวกเขาทำมันได้อย่างไร?

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

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

คนทำงานได้ดีถ้าเขาหรือเธอควรจะรับผิดชอบอะไรบางอย่าง

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


ฉันไม่เคยได้ยินเรื่องการแบ่งแยกระหว่างผู้จัดการที่มุ่งเน้นผลลัพธ์และมุ่งเน้นกระบวนการ +1 สำหรับสิ่งนั้น
mwilcox

4

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

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

  • พวกเขาทำทันที / สม่ำเสมอ / สม่ำเสมอเน้นที่มีปัญหากับการทำสิ่งต่าง ๆ เพื่อให้ตรงตามข้อกำหนดที่ระบุไว้ในปัจจุบัน ... และน่ารำคาญอย่างยิ่งเพราะมัน (นี่คือการพัฒนาซอฟต์แวร์หลังจากทั้งหมดถ้ามันไม่ซับซ้อนพอที่จะมีปัญหาเหล่านี้ มันไม่ใช่โครงการพัฒนาที่แท้จริง)
  • หากพวกเขาไม่แน่ใจเกี่ยวกับบางสิ่งพวกเขาจะพูดทันที - มีเพียงโปรแกรมเมอร์ที่มั่นใจในความสามารถของตัวเองเท่านั้นที่จะทำสิ่งนี้ได้ (และพวกเขารู้ว่าถ้าคุณไม่ชอบมันพวกเขาสามารถหางานได้ง่าย) ในทางกลับกันคนที่รู้ว่าพวกเขาอยู่ห่างจากความลึกอย่างจริงจังมีแนวโน้มที่จะซ่อนตัวและมองหาที่กำบัง
  • โปรแกรมเมอร์คนอื่น ๆ ในทีมพูดอะไร / บอกเป็นนัยถึงโปรแกรมเมอร์คนอื่น ๆ ? หากคุณเป็นผู้จัดการที่ดีครึ่งหนึ่งคุณอยู่ในสนามเพลาะกับทีมเขียนโปรแกรมของคุณโดยเฉพาะในช่วงเวลาทดสอบการรวม / แก้ไขข้อผิดพลาด ดังนั้นหากคุณไม่ได้รับความคิดเห็นเช่นนี้คนอื่นควรทำงานของคุณ
  • และสิ่งที่ฉันชอบ: สิ่งที่ฉันเรียกว่าโปรแกรมเมอร์ 'ทอมแคท' ถ้าหลังจากนั้นสักครู่ในขณะที่คุณสังเกตเห็นโปรแกรมเมอร์ต่าง ๆ มักจะโม่ไปรอบโต๊ะทำงานของโปรแกรมเมอร์คนเดียวกัน (สมมติว่าพวกเขากำลังทำงานและพูดคุยเกี่ยวกับปัญหาบางอย่างและไม่ใช่ตัวค้นหาผู้อาศัยของ webstuff เจ๋ง ๆ & ตลก) ... กำลังโน้มตัวไปที่โต๊ะทำงานของบุคคลนั้น หากพวกเขายังไม่ได้เป็นหัวหน้าทีมพวกเขาก็ควรจะทำอย่างใดอย่างหนึ่งโดยเร็ว

หากมีข้อใดข้อหนึ่งหรือทั้งหมดคุณอาจมีโปรแกรมเมอร์ที่ดีอยู่ในมือ โปรดทราบว่าโดยโปรแกรมเมอร์ที่ดีฉันไม่เพียงให้คะแนนความสามารถในการเขียนโค้ด แต่ยังมีประโยชน์อื่น ๆ เช่นความสามารถในการสื่อสารกับมนุษย์คนอื่น ๆ ;-)


gee ขอบคุณ ... ถ้าเป็นเช่นนั้นจะเป็น meme แรกของฉัน ในกรณีที่ไม่ชัดเจนสำหรับทุกคนมันมาจากการเปรียบเทียบ 'แมวต้อนแกะ'
NomaderWhat

3

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


1
ฟังดูเป็นเรื่องการเมืองและทำให้ฉันนึกถึง บริษัท แห่งหนึ่งในอดีตของฉัน
IsmailS

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

2

ผู้จัดการคือโคเดอเรเตอร์เองและดังนั้นจึงสามารถสังเกตได้ง่ายว่าโคเดอร์นั้นดีหรือไม่

หากผู้จัดการของคุณไม่ใช่ผู้เขียนโค้ด (และคุณอยู่ในธุรกิจซอฟต์แวร์) คุณก็รู้สึกผิด


2

ในฐานะผู้จัดการนี่คือบางสิ่งที่ฉันมองเมื่อประเมินโปรแกรมเมอร์ของฉัน:

  • ข้อเสนอแนะเพื่อน ฉันถามโปรแกรมเมอร์ในทีมของฉันและโปรแกรมเมอร์จากทีมอื่นเพื่อส่งข้อเสนอแนะเกี่ยวกับคนของฉัน

  • เคารพเพียร์ เมื่อโปรแกรมเมอร์ของฉันประสบปัญหาพวกเขาไม่สามารถแก้ปัญหาได้พวกเขาพูดว่า "มาขอคำแนะนำกันเถอะ"

  • ได้รับสิ่งที่ทำ ฉันพูดว่า "ฉันต้องการ X" และในวันถัดไป X ก็เสร็จสิ้น

  • ได้รับสิ่งที่สมาร์ท ฉันพูดว่า "ฉันต้องการ X" และในวันถัดไปไม่เพียง แต่ทำ X เท่านั้น แต่สิ่งที่คล้าย X ทั้งหมดได้รับการแก้ไขและไม่ต้องการความสนใจเพิ่มเติม

  • แก้ไขฉัน ฉันพูดว่า "ฉันต้องการ X" และโปรแกรมเมอร์บอกว่า "X ไม่ถูกต้องเราควรทำ Y และนี่คือเหตุผล"

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


1

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

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

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

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

มันเป็นเรื่องไร้สาระ แต่คุณสามารถเลิกและหวังในสิ่งที่ดีกว่าได้เสมอ


1

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


1

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

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


1

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

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

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

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


1

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


1

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

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

บางครั้งฉันคิดว่ารหัสเกินจริง


0

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

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

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