การจัดการกับ Fanboys [ปิด]

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

ความคิดที่ฉันต้องจัดการกับเรื่องนี้:

1. หัวเราะออกไป - "ฮ่าฮ่าใช่บางทีภาษา X นั้นง่ายกว่านิดหน่อยฉันคิดว่าฉันเป็นนักทำโทษตัวเอง!"
2. ไปกับมัน - ฉันชอบที่จะหลีกเลี่ยงสิ่งนี้เพราะฉันไม่สามารถลดลงในการผลิตที่เกี่ยวข้องกับการเลือกภาษาใหม่
3. ซ่อนภาษาของฉัน - เป็นโปรแกรมเมอร์ตู้เสื้อผ้าและซ่อนจอมอนิเตอร์ของฉันทุกครั้งที่ฉันเขียนสคริปต์หรือทำอะไรบางอย่างอัตโนมัติ

คุณจะแนะนำอะไรสำหรับสถานการณ์นี้

มีบางสิ่งที่กระโดดออกจากคำถาม

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

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

มุมมองของฉันเกี่ยวกับสถานการณ์นี้เป็นเช่นนี้:

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

เป็นเพราะไม่มีใครรู้วิธีเขียนซอฟต์แวร์ที่ปลอดภัยและรวดเร็วในภาษาที่ไม่รู้จักและมีผู้พัฒนา gotchas ทั้งหมดต้องเรียนรู้ สคริปต์ที่โง่จะต้องได้รับการสนับสนุนมากกว่า 20 ปีหรือเขียนใหม่ กว่า 20 ปีที่นักพัฒนาอย่างน้อย 50 คนเปลี่ยนร้านโดยเฉลี่ย หากแต่ละคนเขียนสคริปต์แฟนซีเพียงไม่กี่ภาษาในภาษาใหม่คุณต้องใช้เวลา 50 ภาษาผู้เชี่ยวชาญ 50 คนในทีมและ codebase มีรหัสบั๊กใน 50 ภาษา และบางภาษาไม่ได้รับการสนับสนุนบน Windows หรือ Linux อีกต่อไป และความต้องการที่ไม่ได้เปรียบเซิร์ฟเวอร์ที่กำหนดเองอายุ 10 ปีไม่มีอะไหล่ที่ใช้ได้ 24/7

นอกจากนี้ยังไม่มีใครต้องการสนับสนุนภาษาที่ตายแล้วเช่น VB, Silverlight, D และอื่น ๆ เมื่อรหัสฐานอาจจะอยู่ได้นานกว่าภาษาตัวเอง

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

คุณทำงานอยู่ที่นั่นไม่เล่นที่นั่น ท้ายที่สุดมันก็พ้นมือคุณ

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

ใช้สิ่งที่ทีมส่วนใหญ่รู้

"2. ไปกับมัน"

นี่เป็นคำตอบที่สมเหตุสมผลเท่านั้น คุณมีโอกาสที่ดีที่นี่

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

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

• โครงการเจ๋ง ๆ ทั้งหมดอาจใช้ภาษาที่ชื่นชอบของนักพัฒนาอาวุโส การรู้ภาษานั้นทำให้คุณมีพรสวรรค์ที่สามารถทำงานในโครงการเหล่านั้นได้

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

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

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

โชคดี!

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

หากบุคคลนั้นหลงใหลเกี่ยวกับ C ++ และคุณกำลังทำงานในโครงการเว็บแอปพลิเคชันมันจะไม่ยากเกินไป ในทำนองเดียวกันบริบทบางอย่างมีความโน้มเอียงไปทางการเขียนโปรแกรมการใช้งานและการใช้ภาษาที่ไม่ใช้งานจะไม่ฉลาดมาก

หมายเหตุ:

• หลีกเลี่ยงสถานการณ์ที่ทั้งคุณและเขาต้องการภาษาที่คล้ายกันมาก

  ตัวอย่างเช่นฉันแทบจะไม่จินตนาการถึงบริบทที่ Java จะ "ดีกว่า" กว่า C # หรือ C #, "ดีกว่า" มากกว่า Java

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

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

คำตอบคือ 2) ไปกับมัน

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

มันเป็น win-win-win-win สนุก!

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

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

ความท้าทายที่นี่คือแฟนบอยเชื่อมโยงภาษากับตัวตนของเขาหรือเธอและการปฏิเสธที่เกี่ยวข้องกับภาษานั้นเป็นเรื่องส่วนตัว อย่าโจมตีหรือป้องกัน เพียงแค่เพิกเฉย

สิ่งเล็ก ๆ น้อย ๆ ในงานนั้นเป็นสคริปต์ที่ไม่ต้องทำ ฉันเลิกใส่หลาย ๆ อย่างในวิกิหรือในที่เก็บต่อไปในกรณีที่จำเป็นอีกครั้ง

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

อีกสปินคือเป็นไปได้ว่านักพัฒนาอาวุโสมีเหตุผลที่คุณไม่รู้เกี่ยวกับการใช้ภาษานั้น คุณเคยถามไหม

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

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

ตัวเลือกแบบพาสซีฟก้าวร้าว 1,3 นำไปสู่ความทุกข์ทางอารมณ์มากขึ้นดังนั้นให้ฉัน 2) เอามันไปที่คาง

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

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

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