โปรแกรมเมอร์. NET เดี่ยวย้ายไปอยู่กับทีม [ปิด]


12

ฉันเป็นโปรแกรมเมอร์. NET เดี่ยวสำหรับการเริ่มต้นเล็ก ๆ ในช่วง 8 ปีที่ผ่านมา ฉันได้รวบรวมซอฟต์แวร์ที่ดีและฉันก็พยายามปรับปรุงตัวเองให้ดีขึ้นและปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดรวมถึงการควบคุมแหล่งที่มา (SVN / TFS) ฉันทำงานอย่างใกล้ชิดกับทีมวิศวกรของสาขาวิชาอื่น ๆ แต่เมื่อมันลงมากับซอฟต์แวร์ฉันเป็นคนเดียวที่เขียนโปรแกรม ฉันรักงานฝีมือของการเขียนโปรแกรมและรักการเรียนรู้สิ่งใหม่เพื่อแปลงเครื่องมือของฉัน

ใน 2 สัปดาห์ฉันจะเริ่มงานใหม่ในทีมนักพัฒนา 20. NET ตำแหน่งของฉันจะอยู่ในระดับกลางและฉันจะทำงานภายใต้โปรแกรมเมอร์บางคนที่มีภูมิหลังที่น่าประทับใจอย่างไม่น่าเชื่อ อีกครั้งการพัฒนาของทีมจะเป็นเรื่องใหม่สำหรับฉันดังนั้นฉันจึงมองหาเคล็ดลับ "คนใหม่" ทั่วไปที่จะช่วยให้ฉันมีประสิทธิภาพและง่ายต่อการเข้าร่วมเท่าที่จะเป็นไปได้

สิ่งใดไปรวมถึงเคล็ดลับระดับสูงและสิ่งเล็ก ๆ น้อย ๆ เกี่ยวกับการสื่อสารในแต่ละวัน

คำตอบ:


19

สามัญสำนึกส่วนใหญ่ แต่คำแนะนำของฉันจะเป็น:

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

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

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

ฟังและเขียนสิ่งต่าง ๆ ลงไปขอให้เพื่อนร่วมชั้นเรียนอธิบายขั้นตอนซ้ำ ๆ

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

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


1
ดื่มเบียร์ตอนอาหารกลางวัน? คุณต้องเป็นคนยุโรป: P คนส่วนใหญ่คิดว่าฉันเป็นคนติดเหล้าถ้าฉันทำที่นี่ในชายฝั่งแปซิฟิกของสหรัฐ
Edward Strange

@Crazy เอ็ดดี้: ผมแคนาดาและ บริษัท ของฉันจ่ายสำหรับเบียร์และได้มันมาในสำนักงานทุกวันศุกร์ ...
สตีเว่น Evers

@SnOrfus - ฉันเคยมีประสบการณ์สุดขั้วทั้งสองในแคนาดาจริง ๆ ฉันคิดว่า "เบียร์ที่อนุญาต" นั้นกำลังลดลง
Scott Whitlock

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

@Snorfus - หากคุณพบ บริษัท ในสหรัฐอเมริกาที่ทำเช่นนั้นอาจเป็นเพียง บริษัท เดียวเท่านั้น: PI คิดว่า CEO และผู้บริหารระดับสูงและผู้มีอิทธิพลอื่น ๆ อาจดื่มในช่วงอาหารกลางวัน แต่สถานที่ส่วนใหญ่มีอยู่ในคู่มือ "ไม่นำแอลกอฮอล์มาทำงาน" ถ้าไม่เข้มงวดมากขึ้น แม้ว่าสถานที่ของเราจะมีสิ่งนั้นและพวกเราที่ผลิตสิ่งของได้นำตัวอย่างรสชาติมาแลกเปลี่ยน เราแค่ไม่ดื่มพวกเขาในที่ทำงานจริง ๆ
Edward Strange

8
  • เรียนรู้! การพบกับโปรแกรมเมอร์ใหม่เป็นวิธีที่ดีในการเรียนรู้เทคนิคใหม่ ๆ การดูพวกเขาพิมพ์จะได้เรียนรู้เคล็ดลับการแก้ไขเล็กน้อยและการดูรหัสของพวกเขาจะให้แนวคิดใหม่ ๆ แก่คุณ

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

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

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


3

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

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


ตรงไปตรงมาผมไม่ได้ต้องการที่จะเพิ่มคำพูดรอบมันเพราะผมเชื่อมั่นมีเป็นสิทธิและเป็นวิธีที่ผิดกับซอฟต์แวร์เขียน แต่ผมไม่ได้รู้สึกเหมือนว่าอาร์กิวเมนต์ rehashing เก่า :)
เวย์น Molina

2

นอกจาก Jonno ฉันจะพูดว่า:

เตรียมพร้อมสำหรับการเปลี่ยนแปลง ทุกทีมทำงานแตกต่างกัน ทีม SW ที่ดีมีกฎการเข้ารหัส เตรียมพร้อมที่จะยอมรับพวกเขาแม้ว่าในตอนแรกพวกเขาดูแปลก

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


2

ฟังมากกว่าที่คุณพูด

ถามคำถามมากกว่าที่คุณพยายามตอบ (ยกเว้นคำถามจะส่งตรงถึงคุณ) "ตัวจับเวลาเก่า" ในทีมจะรู้ว่าคุณกำลังพัฒนาความก้าวหน้าในการเรียนรู้รหัสด้วยคำถามที่คุณถาม พวกเขาอาจมีรายการคำถามทางจิตใจที่พวกเขาคาดหวัง

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

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

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


1

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

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

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

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