ออกจาก LinkedIn
(corecursive.com)- Chris Krycho ทำงานที่ LinkedIn ราว 5 ปี รับผิดชอบโครงสร้างพื้นฐานฝั่งฟรอนต์เอนด์และประสบการณ์นักพัฒนาของเว็บแอปเดสก์ท็อป และเผชิญความขัดแย้งระหว่าง การเปลี่ยนแปลง codebase ขนาดใหญ่อย่างปลอดภัย กับความต้องการให้ผลิตภัณฑ์เดินหน้าอย่างรวดเร็ว
- ตอนเข้าทำงาน แอปเดสก์ท็อปของ LinkedIn มี JavaScript ประมาณ 2 ล้านบรรทัด และต่อมาเติบโตเป็น monorepo ราว 3.2 ล้านบรรทัด ทำให้การ migration แทบเป็นไปไม่ได้ในทางปฏิบัติหากไม่มีระบบอัตโนมัติและไม่ลดภาระของทีมผลิตภัณฑ์ให้เหลือน้อยที่สุด
- การปรับ Ember ให้ทันสมัยและการนำ TypeScript มาใช้มุ่งลดข้อผิดพลาดและยกระดับคุณภาพการพัฒนา โดยมีการใช้การวิเคราะห์ภายในเพื่อโน้มน้าวว่า การย้ายไป TypeScript สามารถลดปริมาณ error ใน application log ได้อย่างน้อย 25%
- แผนย้ายจาก Ember ไป React กลายเป็นจุดปะทะระหว่าง กลยุทธ์อัตโนมัติแบบค่อยเป็นค่อยไป 3–5 ปี ของทีม Chris กับแนวทางที่ต้องการออกแบบวิธีเดิมใหม่ครั้งใหญ่เพื่อให้ทดลองผลิตภัณฑ์ได้เร็วขึ้น
- ระหว่างรับมือ incident ขนาดใหญ่ ข้อจำกัดด้านการแจ้งเตือน observability resilience และ code review ถูกเผยให้เห็น และ Chris ตัดสินใจลาออกเพราะทิศทางองค์กรที่ให้ความเร็วเป็นอันดับหนึ่งไม่สอดคล้องกับคุณค่าของเขา
งานที่รับผิดชอบตลอด 5 ปีและขนาดของ codebase
- Chris Krycho เข้าร่วม LinkedIn ช่วงปลายเดือนมกราคม 2019 และทำงานอยู่ราว 5 ปี
- ขอบเขตที่รับผิดชอบไม่ใช่ server infrastructure แต่เป็น frontend infrastructure และการปรับปรุงประสบการณ์นักพัฒนาของเว็บแอปเดสก์ท็อปของ LinkedIn
- เขานำโปรเจกต์ปรับปรุง JavaScript ขนาดใหญ่ให้ทันสมัยในแอปเดสก์ท็อปที่รับผิดชอบประสบการณ์ใช้งาน LinkedIn.com บนเบราว์เซอร์ที่ไม่ใช่มือถือ
- แอปของบริษัทก่อนหน้ามีขนาดราว 150,000 บรรทัด แต่ฟรอนต์เอนด์ของ LinkedIn ตอนเขาเข้าทำงานมี โค้ดประมาณ 2 ล้านบรรทัด
- ในแอปเดียวกันนี้ มีวิศวกร 150–200 คน commit ต่อไตรมาส และมีทีมหลายสิบทีมที่ deploy ผลิตภัณฑ์เดียวกันอย่างต่อเนื่อง
- ตอนเข้าทำงาน วิศวกรที่ทำงาน remote มีไม่ถึง 100 คนจากทั้งหมดหลายพันคน และ Chris เป็นกรณีที่พบไม่บ่อยซึ่งทำงาน remote จาก Colorado
วิธี migration จากโค้ด 2 ล้านบรรทัด
- งานใหญ่ช่วงแรกอย่างหนึ่งคือการนำ class syntax สมัยใหม่ของ JavaScript มาใช้กับโค้ดที่อิง Ember
- มีปัญหาที่ class แบบเดิมของ Ember และ native JavaScript class ปะปนกันใน inheritance chain และภายในเรียกสิ่งนี้ว่า “Zebra Striping”
- migration ระดับนี้จำเป็นต้องทำให้อัตโนมัติมากที่สุดเท่าที่ทำได้
- หากแก้โค้ด 2 ล้านบรรทัดด้วยมือ อาจต้องใช้เวลาหลายเดือนขึ้นไป
- เป็นเรื่องยากที่จะขอให้ทีมผลิตภัณฑ์หยุดพัฒนาฟีเจอร์แล้วมาทำแค่การนำ syntax ใหม่มาใช้
- LinkedIn มีกระบวนการ horizontal initiatives ที่ครอบคลุมหลายทีม และมีหลักการปฏิบัติที่พยายามคงการมีส่วนร่วมของทีมผลิตภัณฑ์ไว้ไม่เกิน 10%
- ทีมของ Chris เห็นว่าแนวทางที่ทีม infrastructure สร้าง PR ด้วยระบบอัตโนมัติ แล้วให้ทีมผลิตภัณฑ์รับผิดชอบการ review และ smoke test จะได้รับการยอมรับง่ายกว่าวิธีให้ทีมผลิตภัณฑ์ไปรัน codemod เอง
- งานที่เกี่ยวกับ Ember ใช้เวลารวม 18 เดือน โดยส่วนใหญ่ดำเนินไปภายใน 6 เดือน แต่มีหางยาวจากความล่าช้าของบางทีม
เหตุผลเรื่องการลด error ที่ใช้โน้มน้าวให้นำ TypeScript มาใช้
- หลังปรับ Ember ให้ทันสมัยแล้ว ทีมของ Chris เลือก error จำนวนมากของ JavaScript ที่เกิดในฟรอนต์เอนด์เป็นเป้าหมายถัดไป
- LinkedIn มีปริมาณ error log สูงมาก จึงใช้ logging infrastructure ภายในแทนบริการภายนอก
- LinkedIn มีจำนวนสมาชิกเกิน 1 พันล้านคน ในปีก่อนหน้า และตอนที่ Chris ลาออก monorepo มีขนาดราว 3.2 ล้านบรรทัด
- ครึ่งหนึ่งเป็นโค้ดทดสอบ
- อีกครึ่งหนึ่งเป็นโค้ด production
- ทีมของ Chris วิเคราะห์แยกประเภท error ที่ TypeScript สามารถตรวจจับได้
- error บางส่วน TypeScript ก็ตรวจจับไม่ได้ แต่พวกเขามองว่าหาก migration ทั้งหมดเสร็จสมบูรณ์ จะลดปริมาณ application log ได้อย่างน้อย 25% จาก JavaScript error ระดับหลายล้านครั้งต่อวัน
- เอกสารการย้ายไป TypeScript ที่ Chris เขียนถูกแชร์ซ้ำ ๆ ระหว่างวิศวกรและผู้จัดการ
- ปัญหาที่ต้องการแก้
- ประโยชน์ที่คาดหวังได้
- การเปรียบเทียบด้านความสามารถในการแข่งขันในการสรรหาบุคลากร
- เหตุผลประกอบการตัดสินใจเมื่อเทียบกับลำดับความสำคัญอื่น
- หลังจากนั้น Chris กลายเป็นผู้เชี่ยวชาญภายในที่ช่วยแก้ปัญหา type ของ TypeScript ที่ยาก ๆ
จาก Ember ไป React: การเปลี่ยนผ่านแบบค่อยเป็นค่อยไปกับการคิดใหม่ทั้งระบบ
- LinkedIn เป็นผู้ใช้ EmberJS รายใหญ่ที่สุดในโลก แต่งานของ Chris ท้ายที่สุดก็เปลี่ยนไปสู่การวางแผนย้ายจาก Ember ไป React
- ผู้นำระดับสูงมองว่าต้นทุน migration ของ LinkedIn สูงเกินไปและทำให้ความเร็วของผลิตภัณฑ์ช้าลง
- แผนของทีม Chris คือ กลยุทธ์อัตโนมัติแบบค่อยเป็นค่อยไปในระยะ 3–5 ปี
- เพิ่มระบบอัตโนมัติเพื่อให้ทีมผลิตภัณฑ์แทบไม่ต้องหยุดงาน
- แยกและเปลี่ยนผ่าน build pipeline, data layer, routing layer, reactivity system และ view layer ตามลำดับ
- ตอนท้ายจึงเปลี่ยนระบบ rendering และ reactivity ของ Ember ไปทาง React
- อีกทีมหนึ่งมุ่งแก้ปัญหาความเร็วโดยตรงมากกว่า
- เป้าหมายคือการลดเวลาจากไอเดียไปจนถึง A/B test จากหลายเดือนให้เหลือระดับไม่กี่สัปดาห์
- พวกเขามองว่า stack ที่ต่างกันของเว็บเดสก์ท็อป เว็บมือถือ iOS และ Android รวมถึง cycle time ที่ยาว เป็นปัญหา
- Chris มองแนวทางของทีมนั้นว่าใกล้เคียงกับท่าทีแบบ “finger guns mode”
- เขารู้สึกว่าแนวทางนั้นไม่ได้จัดการปัญหาที่จะเกิดขึ้นเมื่อขยายจากการรองรับคนไม่กี่สิบคนไปเป็นการรองรับวิศวกรหลายร้อยคนอย่างเพียงพอ
- เขามองว่ามีการตอบคำถามหลายครั้งในทำนองว่า “มันจะไม่เป็นปัญหา”
- แผน 3–5 ปีของทีม Chris ไม่ได้รับการตอบรับที่ดีจาก leadership
- ตัวแผนเองยาวและไม่น่าตื่นเต้น
- ทีมเองก็นำเสนอเหมือนเป็น “ตัวเลือกที่แย่น้อยที่สุด” จึงมีพลังโน้มน้าวไม่มาก
ปัญหา resilience ที่เผยให้เห็นจากการรับมือ incident
- หลัง Chris กลับจากวันหยุดคริสต์มาส เกิดปัญหาที่ผู้ใช้ LinkedIn บางส่วนมองไม่เห็นหน้า LinkedIn.com นานสูงสุดราว 20 นาที
- ปัญหาเกี่ยวข้องกับ บริการ prerendering ที่รันโค้ดฝั่ง client ด้วย Node.js เพื่อรวบรวมข้อมูลจาก backend และส่งต่ออย่างรวดเร็ว
- บริการมี memory leak และมีโครงสร้างที่ container จะ restart เมื่อใช้หน่วยความจำเกิน limit
- มีหลายปัจจัยซ้อนกันที่ทำให้ incident ขยายตัว
- การแจ้งเตือนเกี่ยวกับ memory kill ไม่เพียงพอ
- การตั้งค่าจำนวน container ที่สามารถ restart พร้อมกันได้อยู่ในรูป key ของไฟล์ YAML
- ค่านั้นเป็นค่าที่เป็นไปได้ตาม type แต่เป็นค่าที่ผิดสำหรับระบบนี้
- ค่าที่ตั้งไว้แทบจะใกล้เคียงกับจำนวนบริการทั้งหมดที่กำลังรันอยู่
- เมื่อการหยุด deploy ยืดนานเหมือนช่วงสุดสัปดาห์ยาว บริการต่าง ๆ ใช้หน่วยความจำจนหมดในเวลาใกล้เคียงกัน แล้ว restart พร้อมกัน ทำให้ไม่สามารถประมวลผลคำขอของผู้ใช้ได้
- เมื่อ server บางส่วนล่ม ภาระของ server ที่เหลือเพิ่มขึ้น และการใช้หน่วยความจำของ server เหล่านั้นก็เพิ่มเร็วขึ้นด้วย จนเกิดสถานการณ์ที่ server ล่มเป็นระดับ data center
- ขณะเดียวกันมีงาน rightsizing เพื่อลดการใช้ CPU และหน่วยความจำของ fleet ดำเนินอยู่ ทำให้พื้นที่สำรองลดลง
- Chris และวิศวกรคนอื่น ๆ เห็นว่าจำเป็นต้องมีการแจ้งเตือน observability และ resilience ที่ดีกว่านี้
- แม้ Node server ตัวหนึ่งจะเข้าสู่สภาวะ runaway ก็ไม่ควรทำให้ host process ตายไปด้วย
- การ terminate เฉพาะ Node process แจ้งเตือน แล้ว restart จะปลอดภัยกว่า
- พิจารณา fallback path ที่เปลี่ยนไปใช้ client-side fetch เมื่อ service ล่มด้วย
ความขัดแย้งว่า code review อย่างเดียวป้องกันไม่ได้
- การประชุมรับมือ incident จัดขึ้นหลายครั้งต่อสัปดาห์ มีลักษณะเป็นการแชร์ความคืบหน้าและรายงานต่อผู้บริหาร
- ผู้จัดการจากอีกทีมหนึ่งเข้ามารับผิดชอบการรับมือ incident และเพิ่มกำลังคน โดย Chris มองว่านี่เป็นกระแสที่ไม่ไว้วางใจคำตอบของเขาและทีมเดิม
- ในกระบวนการนั้น วิศวกรอาวุโสคนหนึ่งถามว่า “ทำไม code review ถึงแก้เรื่องนี้ไม่ได้?”
- Chris เห็นว่า code review อย่างเดียว ไม่สามารถรับประกันได้ว่าเหตุการณ์แบบเดิมจะไม่เกิดขึ้นอีก
- คนเราผิดพลาดได้
- วิศวกร junior ย่อมยากที่จะตั้งข้อสงสัยว่าค่า config ใน PR ของ SRE ที่ senior มากนั้นสมเหตุสมผลหรือไม่
- ระบบควรทำงานอย่างปลอดภัยไม่ใช่เฉพาะในวันที่ดีที่สุดของวิศวกร senior แต่รวมถึงวันที่แย่ของวิศวกร junior ด้วย
- สำหรับ Chris วิศวกรรมซอฟต์แวร์รวมไปถึง การออกแบบระบบ ที่สนับสนุนวิศวกรให้สร้างผลลัพธ์ผลิตภัณฑ์ได้
- incident ทางเทคนิคและการสื่อสารในองค์กรไม่ได้แยกขาดจากกัน และเช่นเดียวกับคำพูดของ Charity Majors ในระดับสูงจะไม่มีปัญหาที่เป็นสังคมล้วน ๆ หรือเทคนิคล้วน ๆ
Leadership, วัฒนธรรม remote และความขัดแย้งด้านคุณค่า
- Chris มองว่าทีมและแนวทางของเขาถูกข้อเสนอของอีกทีมเบียดออกไป
- แผนของอีกทีมขยายไปเป็นทิศทางที่คิดใหม่ทั้งแอปเดสก์ท็อปและมือถือ และกลายเป็นการทบทวนวิธีสร้างผลิตภัณฑ์ของ LinkedIn โดยรวม
- Chris อยากทำให้ข้อเสนอนั้นดีขึ้น แต่รู้สึกว่าข้อกังวลหรือคำถามของเขาไม่ได้รับการรับฟังอย่างเพียงพอ
- เขาเล่าว่าผู้จัดการคนหนึ่งบอกเขาว่า “คุณอุดมคตินิยมเกินไป ไม่ใส่ใจเรื่องกำไรขาดทุนมากพอ และควรเปลี่ยนคุณค่าของตัวเอง”
- Chris มองว่า การทำงาน remote ส่งผลต่อการสร้างความสัมพันธ์
- LinkedIn มีวัฒนธรรมแบบพบหน้ากันสูง และหลายคนสร้างความสัมพันธ์อย่างเป็นธรรมชาติในโรงอาหารหรือทางเดิน
- เขารู้สึกว่าการได้พบปะทางกายภาพซ้ำ ๆ กับวิศวกรระดับสูงและผู้บริหารสามารถสร้างความแตกต่างในสถานการณ์ขัดแย้งได้
- Chris ยังทบทวนว่าตัวเขาเองก็มีจุดอ่อนด้านการสร้างความสัมพันธ์เช่นกัน
เหตุผลที่ท้ายที่สุดเขาลาออก
- Chris มองว่าปัญหาจำนวนมากของ codebase เดิมเป็นผลจากการประเมินความเร็วสูงเกินไป และไม่ได้แก้ไขหรือตัดเส้นทางรองที่มีปัญหาออกไป
- เขาตัดสินว่าหากความเร็วกลายเป็นคุณค่าอันดับหนึ่ง แม้จะได้ความเร็วในช่วงแรก แต่เมื่อเวลาผ่านไปก็จะรักษาไว้ได้ยาก
- เขาเคยประสบภาวะ burnout ในงานก่อนหน้า และเล่าว่าเคยมีอาการไมเกรนรุนแรง ปวดท้อง ออกกำลังกายไม่ได้ ร้องไห้กะทันหัน และ panic attack
- เขามองว่าหากทำงานที่ LinkedIn ต่อไป เขาจะต้องใช้ความพยายามทุกวันเพื่อไม่ให้ตัวเองโกรธ
- เขาเปรียบสถานการณ์เหมือนพยายามเปลี่ยนทิศทางองค์กรขนาดยักษ์ด้วยเรือพายลำเล็ก และตัดสินใจว่าจะไม่ใช้เวลาหลายปีกับวิธีการและงานที่เขาไม่ได้เชื่อมั่น
- Chris ได้เรียนรู้เรื่องแอปขนาด 3 ล้านบรรทัด การ migration ไป TypeScript ในองค์กรขนาดใหญ่ และปัญหาวิศวกรรมขนาดใหญ่จาก LinkedIn แต่เขาลาออกเพื่อไปหางานที่สอดคล้องกับคุณค่าของตัวเอง
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
มองว่าช่วงที่น่าสนใจที่สุดในพอดแคสต์คือฟีดแบ็กที่ว่า “คุณอุดมคติมากเกินไป ไม่ใส่ใจกำไรขาดทุนมากพอ และต้องเปลี่ยนค่านิยม” ก่อนอ่านก็รู้สึกแบบนั้นอยู่แล้ว และแม้ระหว่างทางจะได้รับ ฟีดแบ็กที่มีคุณค่า อยู่บ้าง แต่ก็ฟังดูเหมือนจงใจเพิกเฉย
สิ่งที่ยากสำหรับวิศวกรระดับ senior staff ไม่ใช่แค่การ ‘ถูกต้อง’ แต่คือการทำให้องค์กรทั้งองค์กรเกิด alignment ไปสู่แนวทางแก้ปัญหาที่ถูกต้อง เรื่องนี้ยิ่งน่าสนใจเป็นพิเศษเพราะในปี 2019 ฉันเคยร่วมงานรีไรต์ facebook.com ด้วย React
ฉันสื่อสารได้ในระดับหนึ่ง แต่ระหว่างที่อยู่ LinkedIn ก็ไม่ได้ประสบความสำเร็จมากนักในการทำให้เกิด alignment นั้น ส่วนหนึ่งเป็นความรับผิดชอบของฉัน และอีกส่วนก็เป็นความรับผิดชอบของ LinkedIn ด้วย
แต่ในกรณีนี้ คำว่า “อุดมคติมากเกินไป” จริง ๆ หมายถึง “อย่าไปสนใจสิ่งที่ไม่ส่งผลต่อกำไรขาดทุนโดยตรง” และฉันปฏิเสธแนวคิดนั้นอย่างถึงแก่น กำไรขาดทุนสำคัญก็จริง แต่ ประสบการณ์ผู้ใช้, developer experience และจริยธรรมพื้นฐานเกี่ยวกับสิ่งที่เราสร้างก็สำคัญเช่นกัน
ในองค์กร เราต้องสนับสนุนสิ่งที่เราเชื่อว่าถูกต้องให้ดีที่สุด แล้วให้คนอื่นหรือฉันทามติเป็นผู้ตัดสินว่าจะเห็นด้วยหรือไม่ ส่วนจะยอมรับผลลัพธ์นั้น ยอมประนีประนอม หรือจะจากไป เป็นเรื่องที่ฉันต้องตัดสินใจเอง และตลอดอาชีพการงานฉันก็เคยทำมาทั้งสองแบบ
ที่ยูนิคอร์นชื่อดังแห่งหนึ่ง มีวิศวกรระดับ senior staff ที่ทั้งฉลาดมาก มีเหตุผล และใจดีมากคนหนึ่ง เขาผลักดันให้อัปเกรดเฟรมเวิร์กที่บริษัทใช้กับงานมูลค่าระดับ 50 ล้านดอลลาร์ต่อปีจาก v2 ไปเป็น v3 ซึ่งถ้าเทียบกับการย้ายจาก Python 2 ไป 3 แล้วถือว่าเป็นการเปลี่ยนแปลงเล็กน้อยมาก
จากการตรวจสอบพบว่าน่าจะคาดหวัง ประสิทธิภาพดีขึ้น 10% ได้เป็นพื้นฐาน แต่ผู้บริหารกลับไม่อยาก “เสียเวลา” กับการอัปเกรดเวอร์ชัน สุดท้ายวิศวกรคนนั้นผลักดันต่อด้วยตัวเอง สร้างเวอร์ชันพรีวิวได้ภายในไม่ถึงหนึ่งเดือน และภายในสองเดือนก็ย้ายงานบางส่วนที่ให้ผลลัพธ์สูงมากได้สำเร็จ จนประหยัดเงินได้หลายเท่าของเงินเดือนตัวเอง
เมื่อจ่ายต้นทุนทางการเมืองและต้นทุนทางวิศวกรรมช่วงแรกไปแล้ว ทุกคนก็อยากย้ายตาม และหนึ่งปีต่อมาเมื่อดีพลอยเสร็จ โครงสร้างผู้บริหารด้านบนก็แตกกระจายไปครึ่งหนึ่งจากการปลดคนและลาออก แต่ตัววิศวกรกับการ migration นั้นยังอยู่ บางครั้ง staff engineer ไม่ได้ดื้อรั้น แต่อาจเป็นคนเดียวที่ยังมีสติอยู่ในโลกที่บ้าคลั่ง
ฉันเคยอยู่ในตำแหน่งแบบนั้น และเลือกไม่เข้าร่วมได้ แต่ก็ไม่ได้แปลว่าจะทำแบบนั้นได้เสมอไป
ฉันเคยเห็นคนที่ไม่ได้มีไอเดียหรือแผนที่ดีที่สุด แต่มีคอนเนกชันที่ใช่ ได้นั่งมื้อกลางวันที่ใช่ และใช้คำพูดที่ใช่ในการโน้มน้าวผู้บริหาร
คำว่า “คุณอุดมคติมากเกินไปและไม่ใส่ใจกำไรขาดทุนมากพอ” ก็อาจเป็นแค่คำตีตราเพื่อผลักใครบางคนออกไป โดยเฉพาะถ้าคนที่พูดเป็นคนประเภทที่ขายตัวเองและไอเดียของตัวเองให้ผู้บริหารมาตลอดก็ยิ่งเป็นไปได้
โดยส่วนตัวฉันเคยทำ การเปลี่ยนแปลงและอัปเกรดขนาดใหญ่ เกี่ยวกับ Ruby, Rails, Postgres หลายครั้งในองค์กรที่เล็กกว่า Facebook แต่มีวิศวกรหลายร้อยคนและโค้ดเบสขนาดใหญ่ วิธีการที่ Chris อธิบายนั้นสมเหตุสมผลมาก และก็สอดคล้องกับแนวทางที่ฉันรู้สึกว่าประสบความสำเร็จ
เห็นด้วยว่าบทบาทผู้นำจะมีประสิทธิภาพได้ต้องมีทั้งความไว้วางใจและความเคารพ แน่นอนว่าเพื่อให้ความไว้วางใจนั้นมีประโยชน์ ก็ต้องเป็นฝ่ายถูกจริงด้วย ความก้าวหน้าในทิศทางที่ผิดไม่ใช่ความก้าวหน้า
แม้จะไม่เคยทำงานกับโค้ดเบสของ LinkedIn และไม่ได้รู้จักมัน แต่ฉันเคยเห็นโค้ดเบสกับโครงสร้างองค์กร·การเมืองที่ฟังดูคล้ายกันอย่างน่ากลัวหลายครั้ง เลยปกติจะสนับสนุนแนวทาง finger-guns
การเขียนใหม่แบบ finger-guns ก็ทำให้ดีได้เช่นกัน ถ้ามีไคลเอนต์หลายตัวที่ทำงานอย่างเดียวกัน ก็อาจใช้หนึ่งในนั้นเป็นฐานสำหรับอีกแพลตฟอร์มได้ และถึงจะเริ่มใหม่ทั้งหมดก็ยังทำให้สะอาด เร็ว และกระชับได้
กุญแจของความสำเร็จคือมอบระบบใหม่ให้กับ ทีมทหารผ่านศึกขนาดเล็ก ที่เป็นทั้งผู้เชี่ยวชาญด้านโดเมนและด้านเทคนิค เรื่องนี้อาจเป็นประเด็นถกเถียง แต่ฉันมองว่าความสำเร็จทั้งหมด รวมถึงปัญหางานปฏิบัติการดูแลระบบทั่วไป ก็มาจากตรงนี้ ที่เหลือมีแต่ทำให้ช้าลง
ปัญหาใหญ่ที่ผู้บริหารสายเทคโนโลยีส่วนใหญ่มักทำซ้ำคือ มอบหมายระบบใหญ่ถัดไปให้กับคนที่มีประสบการณ์น้อยที่สุด อยากฟังมุมสัมภาษณ์อีกด้านจากฝั่ง finger-guns เหมือนกัน
ซึ่งก็เป็นธรรมชาติ เพราะเป็นสิ่งที่พิสูจน์แล้วว่าใช้ได้ผลสำหรับพวกเขา แต่ก็ไม่ใช่ว่าจะดีที่สุดเสมอไป อีกอย่าง ต่อให้ทีมทหารผ่านศึกเป็นคนเริ่มโปรเจ็กต์ ก็มักไม่ค่อยอยู่จนจบ และถ้าไม่ต้องรับผลลัพธ์หรือผลกระทบตามมาเอง การตัดสินใจก็ง่ายเกินไป
แผนงานควรมีตัวเลือกที่เป็นจริงในการจัดการอุปสรรค และนั่นไม่ใช่แค่ตัวเลือกทางเทคนิค แต่รวมถึงเวลาและความสามารถของคนที่จะทำงานนั้นด้วย เช่น ถ้าแผนคือหลายทีมต้องมาดูแลเซิร์ฟเวอร์ แม้ทางเทคนิคจะทำได้ แต่ถ้าทีมไม่มีเวลาหรือความสามารถ มันก็ไม่ใช่ตัวเลือกที่เป็นจริง
ในทางกลับกัน การวางเส้นทางซับซ้อนเพื่อหลบอุปสรรคทุกอย่างก็ไม่ดี เพราะกว่าจะไปถึง อุปสรรคอาจขยับไปแล้ว และบนเส้นทางอาจยังมีอุปสรรคที่เราไม่รู้จักอีก ถ้าวางแผนไว้แค่เส้นทางเดียว ก็จะหยุดอยู่ตรงนั้น
แต่สิ่งที่เราเห็นตอนนี้ก็เป็นแค่คำอธิบายพอดแคสต์ที่สรุปข้อถกเถียงเรื่องสถาปัตยกรรมที่ซับซ้อนให้เป็นการ์ตูน จึงไม่มีทางรู้ได้ว่าที่ LinkedIn ฝ่ายไหนกันแน่ที่ใกล้เคียงกับตรรกะแบบหุ่นไล่กา
เขาบอกว่าคณะกรรมการถึงขั้นบอกทีมวิศวกรรมทั้งหมดว่า ต่อไปนี้ในทุกโปรเจ็กต์ จะไม่มีใครสั่งรายละเอียดการทำงานของใครได้อีก
ฟังดูเหมือน Chris ตัดสินใจพลาดอยู่หลายอย่าง เขาเสนอ แผน 5 ปี, พาเหตุการณ์ไปสู่การกล่าวโทษแทนที่จะเป็นภาวะผู้นำ, พูดถึงปัญหามากกว่าจะแก้ปัญหา และดูเหมือนจะสร้างความสัมพันธ์ได้ไม่พอ
แม้จะเห็นใจ Chris แต่ก็ดูเหมือนเขาไม่รู้ว่าจะสร้างผลงานในสภาพแวดล้อมแบบนี้อย่างไร ซึ่งก็ไม่เป็นไร ไม่ใช่ทุกคนจะต้องเรียนรู้วิธีทำงานท่ามกลางปมราชการ และในแง่นั้นสตาร์ตอัปก็ง่ายกว่า
มีเหตุผลที่บริษัทใหญ่ ๆ ค่อย ๆ สูญเสียความเฉียบคมไปตามเวลา จนวันหนึ่งผู้บริหารคนหนึ่งต้องนั่งในห้องประชุมเผชิญผลขาดทุน -10% เมื่อเทียบกับปีก่อน โดยไม่มีรองประธานคนไหนกล้าพูดตรง ๆ
เวลาอยู่ในสถานการณ์แบบนี้ มันทำให้เสียการรับรู้ทิศทางทางจิตใจ ฉันน่าจะถูก แต่ฉันถูกจริงหรือเปล่า? คนรอบตัวไร้ความสามารถขนาดนั้นจริงหรือ และไม่สนใจจะเรียนรู้จากเพื่อนร่วมงานจริงหรือ?
พออีกหลายปีต่อมาคุณออกมาแล้วหันกลับไปมอง คนเหล่านั้นก็ถูกไล่ออกหรือไม่ก็ลาออก องค์กรก็ยังทำ X ไม่ได้ และความคล่องตัวกับความสามารถของทีมที่เข้ามาทีหลังนั้นมีอยู่จริง
อีกด้านหนึ่ง มันอาจเป็นความหยิ่งยโส ความไร้ทักษะทางการเมือง หรือการปรับตัวเข้ากับวัฒนธรรมการทำงานที่ป่วยผิดปกติไม่ได้ก็ได้ แต่อีกด้านหนึ่ง นั่นอาจเป็นปฏิกิริยาที่ถูกต้องก็ได้
ถ้าองค์กรกำลังอยู่ในช่วงวัฒนธรรมป่วยผิดปกติจริง ก็อาจเป็นเรื่องถูกต้องที่คนเก่ง รอบคอบ และมีแพสชันจะค่อย ๆ เสียสติไปเพราะมัน ส่วนคนที่ไม่เป็นบ้าเพราะเรื่องนี้ อาจไม่เกี่ยวอะไรกับผลิตภาพและการเติบโต หรือแย่กว่านั้นคือเป็นผลลบสุทธิ
เพราะแบบนี้สภาพแวดล้อมเช่นนี้จึงกลายเป็นละครจิตวิทยา สถานการณ์มันแย่จริง ๆ หรือว่าฉันแค่ไวเกินเหตุ
แต่ในสถานการณ์ที่ผู้บริหารพูดว่า “ต่อให้เป็น migration ที่เราขอเอง ก็ห้ามทำให้ความเร็วในการ iterate ของผลิตภัณฑ์ช้าลงแม้แต่นิดเดียว” มันก็เป็นแผนเดียวที่เรารู้สึกว่ายังถือไปเสนอได้
ส่วนที่บอกว่าพาเหตุการณ์ไปสู่การกล่าวโทษ ฉันไม่ค่อยเข้าใจว่าหมายถึงอะไร เพราะจริง ๆ แล้วฉันพยายามทำตรงกันข้าม และไม่ได้โทษคนที่ลด memory threshold หรือคนที่พิมพ์ค่าผิดใน YAML เพียงแต่ยืนกรานว่าอย่าปล่อยให้สาเหตุรากเหง้าค้างอยู่จนคนถัดไปโดนอีก แต่ให้แก้มันจริง ๆ
เรื่องที่ว่าพูดมากกว่าแก้ปัญหาก็ไม่ค่อยเข้าใจเหมือนกัน ฉันแค่ไม่ได้ใช้เวลาในรายการมาอวดสิ่งที่ตัวเองทำสำเร็จยืดยาว แต่ปัญหาที่ฉันแก้ที่นั่นก็ทำได้ค่อนข้างดี
เรื่องสร้างความสัมพันธ์ไม่พอ อย่างที่บอกไว้ในเอพิโซด นั่นคือจุดอ่อนที่สุดของฉัน ฉันเข้ากับวิศวกรได้ดี แต่ล้มเหลวอย่างมากในการสร้าง ความไว้วางใจทางการเมือง โดยเฉพาะกับผู้บริหารชั้นบน
ถึงอย่างนั้น ฉันก็ไม่ได้มองว่าเป็นแค่เพราะไม่รู้วิธีสร้างผลงานในสภาพแวดล้อมนั้นเท่านั้น ฉันมองเห็นวิธีที่จะประสบความสำเร็จได้ แต่ก็เลือกด้วยว่าจะไม่ทำตัวในแบบที่ตัวเองไม่เชื่อ วิศวกรหลายคนที่ฉันเคารพก็เต้นตามเกมการเมืองเพื่อสิ่งที่พวกเขาเชื่อ แต่จะไม่ทำแบบนั้นเพื่อสิ่งที่พวกเขาไม่เชื่อ
ตอนนี้ทำงานอยู่ที่ LinkedIn บทบาทและพอดแคสต์ของ Chris ดูเหมือนจะพูดถึง Ember และการพัฒนาเว็บฟรอนต์เอนด์ และจำนวนบรรทัดโค้ดกับการบิลด์ที่เขาพูดถึงก็น่าจะเป็น voyager-web ซึ่งเป็นเว็บแอปหลักแบบโมโนลิทิกของ LinkedIn
ที่ LinkedIn ยังมีระบบอื่นที่มีโค้ดหลายล้านบรรทัดและใช้เวลาบิลด์นานอีก เช่น เลเยอร์กลาง สแตกข้อมูลออฟไลน์ ระบบเมตริก และพวก KafkaKafkaKafka
น่าเสียดายที่ บิลด์ 17 นาที ถือว่าค่อนข้างดีเลย ถ้าทำได้ 17 นาทีโดยไม่มีปัญหาโครงสร้างพื้นฐานล่มชั่วคราวก็ถือว่าดีมากแล้ว
ทั้งบริษัทแทบไม่มีแนวคิดเรื่องการทดสอบ และไม่มี QA ด้วย วิศวกรมักยัดโปรเจกต์ที่ยังสุกๆ ดิบๆ เข้าไปเพื่อเอาไปใส่ในเอกสารขอเลื่อนตำแหน่ง แล้วก็ย้ายไปทำอย่างอื่นต่อ
ตอนใช้เครื่องมือภายในในชีวิตประจำวัน ต้องคอยแก้ปัญหาด้วยตัวเองเยอะมาก จนโครงสร้างมันกลายเป็นว่าวิศวกรที่พยายามทำงานให้เสร็จนั่นแหละคือ QA โดยพฤตินัย
ทั้งที่จริงควรไปทาง ทำให้บิลด์เร็วขึ้น หรือทำให้โครงสร้างพื้นฐานสำหรับบิลด์เร็วขึ้นและถูกลงแทน
อย่างน้อยในทีมที่ผมอยู่ มีการให้ความสำคัญกับคุณภาพโค้ดค่อนข้างมาก และวัฒนธรรมก็ดีขึ้นเรื่อยๆ แต่ผมเคยทำงานกับ voyager อยู่ครั้งหนึ่ง และจำได้ว่ามันเป็นฝันร้าย
การเขียนใหม่ครั้งใหญ่ เป็นเรื่องเสี่ยงแม้กระทั่งกับโค้ดเบสที่ยังพอจัดการได้ และเศษซากที่เหลือก็ดูจะไม่หายไปจนจบจริงๆ ผ่านไปไม่กี่ปี ใครจะอยากได้คะแนนจากการกลับไปเขียนหน้าตั้งค่าที่ถูกทิ้งไว้ตามมุมใหม่กัน
ผมเห็นความพยายามแบบนี้มาเยอะมากจนคิดว่าน่าจะมีเฟรมเวิร์กสำหรับรีไรต์โค้ดเบสแล้ว แต่ก็ไม่มี เครื่องมือแก้โค้ดอัตโนมัติต้องการความสม่ำเสมอ แต่มีไม่กี่ที่ที่รักษาความสม่ำเสมอแบบนั้นได้ แพตเทิร์นของโค้ดวิวัฒน์ไปมากตามเวลา จนให้ความรู้สึกเหมือนกำลังดูวงปีของต้นไม้
โดยพื้นฐานแล้วเรากำลังเอาโค้ดใส่กล่อง ย้ายกล่องไปมา และอธิบายอย่างมีเหตุผลว่าการจัดวางแบบไหนมีประสิทธิภาพกว่า แล้วทำไมเราถึงหาวิธีที่ดีกว่านี้ไม่ได้? ระบบอัตโนมัติทำงานในระดับโค้ด แต่ไม่ทำงานใน ระดับกล่อง
นี่คือตัวอย่างของการทำงานของ กฎของคอนเวย์ องค์กรไม่ได้เปลี่ยน ดังนั้นก็มีโอกาสสูงที่จะสร้างซุปโค้ดแบบเดิมขึ้นมาอีก
จากมุมของคนที่เคยนั่งเรือลำเดียวกัน ความริเริ่มด้านวิศวกรรมในทางบวกต้องมาจากบนลงล่างผ่านผู้สนับสนุนที่อยู่ในตำแหน่งสูงมาก คุณเปลี่ยนองค์กรจากล่างขึ้นบนไม่ได้ และสุดท้ายแล้วสิ่งที่สร้างโค้ดเบสก็คือองค์กรนั่นเอง
กฎของคอนเวย์ไม่เปลี่ยน แต่ก็ไม่ได้ต้องพึ่งแค่ผังองค์กรทางการเสมอไป ถ้าสร้างโครงสร้างการสื่อสารชั่วคราวระหว่าง tech lead ที่ใช่กับผู้จัดการที่มีความสามารถได้ ก็ยังพอรับมือได้
แต่ถ้ามีผู้จัดการไม่กี่คนที่อ่อนด้านเทคนิคหรือพยายามสร้างอาณาจักรของตัวเองแทรกอยู่ตรงกลาง ทุกอย่างก็พังได้ง่าย และขึ้นอยู่กับวัฏจักรชีวิตของบริษัท มันอาจหมดหวังไปแล้วเพราะ กฎเหล็กของระบบราชการของ Pournelle
เช่น ถ้านักพัฒนาทุกคนห่วย ก็แค่ยัดเฟรมเวิร์กยอดนิยมให้พวกเขา มันเป็นข้ออ้างเพื่อจะได้ไม่ต้องจัดการปัญหาคน และเหมือนปล่อยให้เด็กเล็กมาบริหารศูนย์รับเลี้ยงเด็ก
ถ้าต้องการความเป็นเลิศ ก็ต้องตั้งมาตรฐานสูงด้วยกฎที่มีการตรวจสอบความรับผิดชอบ กำหนดความเป็นเจ้าของ รวมถึงรางวัลและความรับผิด มันไม่ซับซ้อน แต่คนข้างบนต้องเด็ดขาดและไม่กลัวการปะทะ
แต่ก็อาจทำให้คุณหมดความหวังทั้งหมดที่ว่าบริษัทอย่าง Microsoft จะสร้างอะไรขึ้นมาแล้วไม่พังมันทีหลัง
ผมอยู่ที่ LinkedIn มา 12 ปี น่าเศร้าที่มันห่างไกลจากองค์กรวิศวกรรมในอดีตมาก ยุคที่ Kevin Scott เป็นคนนำทีมวิศวกรรมดีมากจริงๆ เมื่อเทียบกันแล้ว
แค่บอกว่ามี JavaScript หลายล้านบรรทัด ก็เป็นร่างอวตารของความ เทอะทะ ในตัวมันเองแล้ว
ผมคิดมาตลอดว่าอยากทำอะไรแบบ LinkedIn ขึ้นมาใหม่ หรือพูดให้แม่นกว่านั้นคือทำฐานข้อมูลรายชื่อติดต่อของตัวเองที่ไม่มีฟีเจอร์สไตล์ “Facebook”
ปัญหาคือจะย้ายรายชื่อติดต่อของผมเข้ามาจำนวนมากได้อย่างไร ต่างหากจากเรื่องความเทอะทะแล้ว ปัญหาหลักของ Microsoft LinkedIn คือมันไม่ยอมให้ส่งออกข้อมูลรายชื่อติดต่อ ซึ่งสำหรับแพลตฟอร์มรายชื่อติดต่อนี่เป็นฟีเจอร์ที่จำเป็น
https://queue.acm.org/detail.cfm?id=2567673
สรุป: https://www.pixelstech.net/article/1395463142-Why-does-Linke...
LinkedIn ย้ายไป Node ในช่วงต้นปี 2010
แต่พอดูปฏิกิริยาในเธรดนี้แล้ว ก็เริ่มสงสัยว่าตัวเลขนั้นอาจผิดหรือเปล่า
ผมไม่ได้ทำกับ LinkedIn แต่เป็นลูกเล่นสกปรก ๆ ที่ผมใช้เวลา export รายชื่อผู้เข้าร่วมงานประชุมจากเว็บไซต์สาธารณะ ทั้งนี้ก็ขึ้นอยู่กับสถานการณ์
ผมประทับใจวิธีที่ Chris Krycho พูดถึงความยากลำบากของตัวเองอย่าง ตรงไปตรงมา โดยไม่พาไปเป็นเกมโทษกันไปมา CoRecursive เป็นหนึ่งในพอดแคสต์ที่ผมชอบ เพราะมันพูดถึงบริบทอันซับซ้อนที่อยู่เบื้องหลังโค้ด
ฟังดูเหมือนเป็นบทบาท ภาวะผู้นำเชิงนุ่มนวล ที่หนักอยู่เกือบตลอดเวลา เป็นตำแหน่งที่มี “ความรับผิดชอบ” ต่อบางอย่าง แต่แทบไม่มีหรือไม่มีอำนาจเหนือส่วนอื่นขององค์กรเลย
ถ้ามีภาวะผู้นำทางเทคนิคจริง คนคนนั้นอาจไม่อยู่แล้ว หรืออยู่มานานจนแม้จะเป็น “ผู้เชี่ยวชาญระบบ” ก็ไม่ได้เชื่อมโยงกับปัญหาจริง ๆ อีกต่อไปแล้ว ผมเคยเจอมาแล้ว และขอไม่เอาอีก