เมื่อออกจาก LinkedIn

 (corecursive.com)
1 คะแนน โดย GN⁺ 2024-03-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อการทำงานให้ถูกต้องปะทะกับความเร็วอันรวดเร็วของบริษัท คุณจะเลือกอะไร?
  • เรื่องราวของวิศวกร Chris Krycho ผู้เลือกอย่างหลัง ระหว่างการยืนหยัดในความเชื่อและประนีประนอม กับการออกไปหางานที่สอดคล้องกับหลักการของตน
  • ในท้ายที่สุด Chris ออกจาก LinkedIn เพื่อเดินตามงานที่สอดคล้องกับหลักการของตัวเอง
  • สรุปเนื้อหาที่เขาเล่าไว้ในพอดแคสต์
  • เรื่องราวของเขาเน้นให้เห็นความตึงเครียดระหว่าง "ความจำเป็นของนวัตกรรม" กับ "ความสำคัญของสุขภาวะของโครงการ"

วันแรกของ Chris Krycho ที่ LinkedIn

  • Chris เข้าร่วม LinkedIn ในช่วงปลายเดือนมกราคม 2019 และผ่านกระบวนการ onboarding หลายอย่างแบบที่มักพบในบริษัทใหญ่หรือบริษัทขนาดเล็กที่มีระบบการทำงานที่ดี
  • เดิมที Chris วางแผนจะทำงานระยะไกลจาก Colorado แต่สองสัปดาห์แรกใช้ไปกับการ onboarding และใช้เวลาร่วมกับทีม

โค้ดนับล้านบรรทัด

  • เมื่อเทียบกับประสบการณ์จากบริษัทก่อนหน้า เขาตกใจกับขนาดของแอปฝั่งไคลเอนต์ frontend และบริการ backend ของ LinkedIn อย่างมาก
  • frontend ของ LinkedIn มีโค้ดมากถึง 2 ล้านบรรทัด ซึ่งมากกว่าโค้ดทั้งหมดของบริษัทก่อนหน้าของเขาเสียอีก

ทีมอินฟราสตรักเจอร์

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

การทำให้ JavaScript ทันสมัย

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

การนำ TypeScript มาใช้

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

แผน migration แบบช้า เทียบกับ 'Finger Gun's Plan'

  • Chris และทีมของเขาเสนอแผน 3~5 ปีในการ migration โค้ด Ember ไปเป็น React แต่มีอีกทีมเสนอ 'Finger Gun's Plan' ซึ่งสัญญาว่าจะทบทวนใหม่ทั้งหมดและเดินหน้าได้อย่างรวดเร็ว
  • ความแตกต่างของแนวทางนี้สะท้อนความขัดแย้งระหว่างปัญหาที่ Chris และทีมพบ กับวัฒนธรรมองค์กรที่ให้ความสำคัญกับความเร็วของบริษัท

ประสบการณ์และสิ่งที่ Chris ได้เรียนรู้

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

กระแสต่อต้านต่อเหตุการณ์

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

แรงกดดันที่เพิ่มขึ้น

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

การปรับโครงสร้างองค์กร

  • มีการปรับโครงสร้างองค์กรและเปลี่ยนบทบาทเนื่องจาก 'Finger Guns team'
  • เขามองเห็นประสบการณ์ใหม่และโอกาสในการเรียนรู้จากบทบาทอื่น

การทบทวนและการตระหนักรู้

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

บทสรุปและบทเรียน

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

ความเห็นของ GN⁺

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-03-07
ความคิดเห็นจาก Hacker News

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

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

  • ในปี 2019 ฉันเคยมีส่วนร่วมในการเขียน facebook.com ใหม่ด้วย React ฉันไม่ได้รู้รายละเอียดโดยตรงเกี่ยวกับ codebase หรือองค์กรของ LinkedIn แต่เคยเห็นบริษัทที่มี codebase และโครงสร้างองค์กรคล้ายกัน ฉันสนับสนุนแนวทาง 'finger gun' ซึ่งถ้าทำได้ดีจะนำไปสู่ผลลัพธ์เชิงบวก เมื่อมีไคลเอนต์หลายตัวพยายามทำสิ่งเดียวกัน คุณสามารถใช้ตัวหนึ่งเป็นฐานเพื่อให้บริการแพลตฟอร์มอื่นได้ หรือถ้าเริ่มใหม่ ก็สามารถทำให้มันสะอาด เร็ว และกระชับได้ ปัจจัยความสำเร็จที่พบได้บ่อยคือทีมเล็ก ๆ ที่มากประสบการณ์เป็นผู้สร้างระบบใหม่ และฉันเชื่อว่าความสำเร็จมาจากทีมวิศวกรขนาดเล็กที่รวมทั้งผู้เชี่ยวชาญด้านโดเมนและผู้เชี่ยวชาญด้านเทคนิค ปัญหาใหญ่ที่เกิดซ้ำในงานบริหารเทคนิคคือ คนที่มีประสบการณ์น้อยที่สุดกลับเป็นผู้สร้างระบบใหญ่ระบบถัดไป

    • แชร์ประสบการณ์การเขียนใหม่ด้วย React
    • เน้นแนวทาง 'finger gun' และความสำคัญของทีมเล็กที่มากประสบการณ์
    • ชี้ปัญหาการให้คนประสบการณ์น้อยสร้างระบบขนาดใหญ่

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

    • ความเสี่ยงของการเขียน codebase ใหม่และปัญหาตกค้าง
    • การไม่มีเฟรมเวิร์กสำหรับการเขียนโค้ดใหม่
    • ช่องว่างระหว่างระบบอัตโนมัติระดับโค้ดกับระดับกล่อง

  • ตอนนี้ฉันทำงานอยู่ที่ LinkedIn และคิดว่าบทบาทของ Chris ที่กล่าวถึงในพอดแคสต์กับงานพัฒนาเว็บฝั่งฟรอนต์เอนด์นั้นเกี่ยวข้องกับ ember น่าจะกำลังพูดถึง voyager-web ซึ่งเป็นเว็บแอปหลักแบบ monolithic ของ LinkedIn นอกจาก voyager-web แล้ว LinkedIn ยังมีระบบอีกมากที่มีโค้ดนับล้านบรรทัดและใช้เวลาบิลด์นาน เช่น ชั้นกลาง data stack แบบออฟไลน์ ระบบ metrics และ Kafka เวลาบิลด์ 17 นาทีถือว่าค่อนข้างดี และถ้าเป็น 17 นาทีโดยไม่มีความล้มเหลวของโครงสร้างพื้นฐานชั่วคราวเลย ก็ถือว่าดีมาก

    • แชร์ประสบการณ์การทำงานปัจจุบันที่ LinkedIn
    • อธิบายระบบต่าง ๆ และเวลาที่ใช้ในการบิลด์
    • ประเมินเวลาบิลด์ 17 นาที

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

    • ชี้ให้เห็นปริมาณโค้ด JavaScript ที่มากเกินไป
    • ความยากในการย้ายข้อมูลรายชื่อติดต่อ
    • ความสำคัญของฟังก์ชันส่งออกข้อมูลรายชื่อติดต่อ

  • ฉันอยู่ที่ LinkedIn มา 12 ปีแล้ว แต่ตอนนี้มันห่างไกลจากองค์กรวิศวกรรมในอดีตมาก เขามองว่ายุคที่ Kevin Scott นำทีมวิศวกรนั้นดีกว่ามาก

    • ประสบการณ์ทำงานระยะยาวที่ LinkedIn
    • ความแตกต่างระหว่างองค์กรวิศวกรรมในอดีตกับปัจจุบัน

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

    • มีโอกาสที่ความยุ่งเหยิงของโค้ดจะเกิดซ้ำหากองค์กรไม่เปลี่ยน
    • ความจำเป็นของความริเริ่มด้านวิศวกรรมจากผู้บริหารระดับบน

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

    • ชื่นชมความตรงไปตรงมาของ Chris Krycho และการไม่กล่าวโทษผู้อื่น
    • ประเมินพอดแคสต์ CoRecursive ในเชิงบวก

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

    • กรณีตัวอย่างการย้ายเทคโนโลยีจาก Ember ไป React
    • ภาษา 'Unhack' ที่ทำให้ค้นหาและแทนที่ในระดับ AST ได้

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

    • ปัญหาในการใช้งานเว็บไซต์ LinkedIn
    • การแจ้งเตือนปลอมและการตอบสนองของหน้าเว็บที่ช้า
    • ชี้ปัญหาของอัลกอริทึมแนะนำ