ประสบการณ์การทำงานที่ GitLab
(yorickpeterse.com)- ช่วง 6 ปีที่เข้าร่วม GitLab ในเดือนตุลาคม 2015 ในฐานะพนักงานลำดับที่ 28 และทำงานจนถึงเดือนธันวาคม 2021 เป็นประสบการณ์ที่ผสมผสานทั้ง การทำงานทางไกลเต็มรูปแบบ, ความโกลาหลของสตาร์ทอัพที่เติบโตอย่างรวดเร็ว, ปัญหาด้านประสิทธิภาพ·การดีพลอย·วัฒนธรรมองค์กร และภาวะหมดไฟ
- ในช่วงแรกของ GitLab ข้อร้องเรียนใหญ่ที่สุดจากผู้ใช้คือ ประสิทธิภาพต่ำและระบบล่มบ่อย แต่โครงสร้างพื้นฐานสำหรับมอนิเตอร์ประสิทธิภาพยังไม่เพียงพอ และยังต้องสร้างเครื่องมือที่ลูกค้าแบบ self-hosting ใช้ได้ไปพร้อมกันด้วย
- ในปี 2017~2018 ทีม Database ได้สร้าง database load balancer และในช่วงเดียวกันก็เกิดเหตุลบฐานข้อมูล production โดยไม่ตั้งใจพร้อมกับความล้มเหลวของระบบสำรองข้อมูล ทำให้สูญเสียข้อมูลประมาณ 6 ชั่วโมง และใช้เวลาฟื้นฟูประมาณ 24 ชั่วโมง
- ในปี 2019~2021 ทีม Delivery ได้รวมโครงสร้าง repository ที่แยกกันระหว่าง Community Edition และ Enterprise Edition ทำให้กระบวนการตั้งแต่ commit จนถึงดีพลอยไปยัง GitLab.com ซึ่งกรณีแย่สุดเคยใช้เวลา 3 สัปดาห์ ลดลงเหลือ ระดับไม่กี่ชั่วโมง~หนึ่งวัน
- บทเรียนที่ได้จาก GitLab คือ scalability ต้องกลายเป็นส่วนหนึ่งของวัฒนธรรม การตัดสินว่าอะไรคือ “minimum viable” โดยไม่มีข้อมูลนั้นอันตราย การทำ SaaS ควบคู่กับ self-hosting ทำให้ requirements ขัดแย้งกัน และการดีพลอยที่รวดเร็วกับ ค่าตอบแทนตามบทบาท เป็นเรื่องสำคัญ
ก่อนเข้าร่วม GitLab และบทบาทช่วงแรก
- ก่อนเข้าร่วม GitLab เขาทำงานที่สตาร์ทอัพเล็ก ๆ ในอัมสเตอร์ดัม และบริษัทอยู่ในสถานการณ์ยากลำบากถึงขั้นต้องปล่อยเช่าพื้นที่สำนักงานบางส่วนเพราะขาดเงินทุน
- ในเวลาส่วนตัว เขาทำงานกับ Rubinius และอยากทำให้มันเสถียรพอสำหรับใช้งานใน production จึงเริ่มมองหางานที่เกี่ยวข้อง
- เขาได้พบ Sytse ที่งาน Ruby meetup และเวิร์กช็อป Rails Girls จนเริ่มสนใจ GitLab หลังจากส่งอีเมลไปในช่วงฤดูร้อนปี 2015 ก็เข้าร่วมในเดือนตุลาคม 2015 ในฐานะ พนักงาน #28
- งานที่รับผิดชอบคือ ปรับปรุงประสิทธิภาพ ของ GitLab และสามารถใช้เวลา 20% ของเวลาทำงานกับ Rubinius ได้
- ตลอด 6 ปี เขาผ่านหลายทีม มีอิสระในการทำงานสูง รายงานต่อผู้จัดการต่างกัน 10 คน และได้เห็น GitLab เติบโตจากคนราว 30 คนเป็นประมาณ 2,000 คน
ปี 2015~2017: การทำงานทางไกลและการสร้างเครื่องมือด้านประสิทธิภาพ
- เขาเริ่มงานที่ GitLab ในวันถัดจากวันทำงานสุดท้ายของบริษัทก่อนหน้า เปลี่ยนจากการทำงานในออฟฟิศ 5 วันต่อสัปดาห์มาเป็น การทำงานทางไกล 5 วันต่อสัปดาห์
- GitLab ช่วงแรกเป็นบริษัททางไกลเต็มรูปแบบ แต่มีบรรยากาศทางสังคมค่อนข้างเข้มข้น และมีงานรวมตัวกับกิจกรรมของบริษัทบ่อยครั้งในเมืองอย่างอัมสเตอร์ดัมและออสติน
- ช่วงนี้ GitLab เผชิญการเติบโตระยะแรก มีพนักงานใหม่เข้ามาประมาณ 100 คน ขนาดบริษัทเพิ่มจากราว 30 คนเป็นราว 130 คน ก่อนลดลงเหลือราว 80 คนแล้วกลับมาเติบโตอีกครั้ง
- ในเวลาเดียวกันก็เจอปัญหาแบบสตาร์ทอัพที่เติบโตเร็ว ทั้ง ปัญหาประสิทธิภาพ รุนแรง ระบบล่มแทบทุกสัปดาห์ และการจัดการที่ยังไม่สุกงอม
- “GitLab is slow” เป็นข้อร้องเรียนใหญ่ที่สุดของผู้ใช้
- บน Hacker News ก็มีเสียงบ่นเรื่องความช้าของ GitLab อยู่บ่อยครั้ง
- การปรับปรุงประสิทธิภาพยากขึ้นเพราะขาดเครื่องมือ
- ตอนนั้นการมอนิเตอร์ประสิทธิภาพมีเพียงบัญชีทดลองของ New Relic และมอนิเตอร์ได้เพียง 1~2 เครื่องจากเซิร์ฟเวอร์ทั้งหมด 15~20 เครื่อง
- ข้อมูลที่เข้ามาไม่ได้สะท้อนภาพรวมอย่างแม่นยำ
- GitLab ต้องการให้เครื่องมือที่ใช้สามารถให้ลูกค้า self-hosting ใช้ได้ด้วย และถ้าเป็นไปได้ก็อยากให้เป็นโอเพนซอร์ส
- หากจะปรับปรุงประสิทธิภาพก็ต้องสร้างเครื่องมือก่อน และผลลัพธ์ได้นำไปสู่ฟีเจอร์ทางการอย่าง GitLab Performance Monitoring
- ในช่วงนี้ยังสร้าง Sherlock ซึ่งเป็น profiler หนักสำหรับสภาพแวดล้อมการพัฒนา
- GitLab ตระหนักว่าปัญหาประสิทธิภาพไม่ใช่สิ่งที่คนเดียวจะแก้ได้ จึงตั้งทีม Performance พร้อมมอบหมายผู้จัดการโดยเฉพาะและงบจ้างงานขนาดเล็ก
- มีความพยายามทำให้ Rubinius ทำงานกับ GitLab ได้ แต่ไม่สำเร็จ และเมื่อรวมกับทิศทางการบำรุงรักษากับข้อถกเถียงในชุมชน Ruby ในที่สุดก็หยุดทำงานนี้
ปี 2017~2018: ทีม Database, load balancer และเหตุการณ์ฐานข้อมูล production
- หลังจากความโกลาหลในปีครึ่งแรก ประสิทธิภาพดีขึ้นอย่างมาก และ GitLab ก็เริ่มให้ความสำคัญกับประสิทธิภาพอย่างจริงจังมากขึ้น
- ทีม Performance เปลี่ยนขอบเขตจากการปรับปรุงประสิทธิภาพทั่วไปไปเน้น ประสิทธิภาพฐานข้อมูล และกลายเป็นทีม Database
- งบจ้างงานเพิ่มขึ้น และมีการจัดสรร infrastructure engineer เพื่อช่วยเรื่องการตั้งค่าฐานข้อมูลใหม่ ๆ
- ฟีเจอร์หลักที่สร้างขึ้นในช่วงนี้คือ GitLab database load balancer
- งานที่เกี่ยวข้องเผยแพร่ใน Scaling the GitLab database
- นักพัฒนาเขียน DB query ได้ตามปกติ และ load balancer จะ route ไปยัง primary หรือ replica
- หลังการเขียน จะใช้ sticking เพื่อให้ใช้ primary ต่อไปจนกว่าการเปลี่ยนแปลงจะถูกสะท้อนไปยัง replica ทั้งหมด
- มันส่งผลดีต่อประสิทธิภาพอย่างมาก และการนำเข้าใช้ได้อย่างโปร่งใสยังคงเป็นสิ่งที่น่าภูมิใจที่สุด
- วันที่ 31 มกราคม 2017 เกิดเหตุลบฐานข้อมูล production ของ GitLab.com โดยไม่ตั้งใจ
- รายละเอียดเหตุการณ์เปิดเผยใน GitLab.com database incident
- ระบบสำรองข้อมูลไม่ได้ทำงานอย่างถูกต้องมานาน และระบบที่ควรแจ้งเตือนข้อผิดพลาดของ backup ก็ไม่ทำงาน
- โชคดีที่มีการคัดลอกข้อมูล production เมื่อประมาณ 6 ชั่วโมงก่อนหน้าไปยังสภาพแวดล้อม staging จึงสามารถกู้คืนได้
- การกู้คืนใช้เวลาประมาณ 24 ชั่วโมง และเกิด การสูญเสียข้อมูลประมาณ 6 ชั่วโมง
- ในช่วงเดียวกัน GitLab ยังต้องการทำ database sharding ต่อไป แต่จากข้อมูลและดุลยพินิจของวิศวกรในตอนนั้น มันไม่เหมาะกับการแก้ปัญหา
- GitLab มี request อ่านมากกว่าการเขียนประมาณ 10:1
- ปริมาณข้อมูลที่จัดเก็บก็ยังไม่ใหญ่พอจะสมเหตุสมผลกับความซับซ้อนของ sharding
- ที่ปรึกษาคนหนึ่งก็ให้ความเห็นในทำนองว่า แม้กับลูกค้าที่มีโหลดและขนาด repository ใหญ่กว่านี้มาก sharding ก็ยังเกินความจำเป็น
ปี 2019~2021: ทีม Delivery และการปรับปรุงเวลาในการดีพลอย
- ราวปี 2018~2019 เขาเหนื่อยล้าจากงานด้านประสิทธิภาพและความน่าเชื่อถือ จึงย้ายไปทีม Delivery ที่ตั้งขึ้นใหม่
- เป้าหมายของทีม Delivery คือปรับปรุงกระบวนการ release และเครื่องมือของ GitLab ซึ่งตอนนั้นอยู่ในสภาพสับสน
- หลัง commit เข้า main branch แล้ว กว่าจะดีพลอยไปยัง GitLab.com ใช้เวลาเฉลี่ยหลายวัน และกรณีแย่สุดใช้เวลา สูงสุด 3 สัปดาห์
- คอขวดใหญ่ที่สุดคือ GitLab Community Edition และ GitLab Enterprise Edition อยู่คนละ Git repository
- ต้องมี manual merge และ conflict resolution เป็นประจำ
- เพื่อแก้ปัญหานี้ มีงานหลายเดือนเพื่อรวมสองโปรเจกต์ให้เป็นหนึ่งเดียว
- งานที่เกี่ยวข้องเผยแพร่ใน Merging CE and EE codebases
- ทีม Delivery ปรับปรุงกระบวนการ release อย่างมาก จนสามารถดีพลอยการเปลี่ยนแปลงได้ภายในไม่กี่ชั่วโมง
- การลดจากกรณีแย่สุด 3 สัปดาห์เหลือราวหนึ่งวันในกรณีแย่สุด ถือเป็นการปรับปรุงครั้งใหญ่
- อย่างไรก็ตาม ความเร็วนี้ก็ยังไม่เร็วพอในอุดมคติ
การเปลี่ยนแปลงวัฒนธรรมองค์กรและกระบวนการที่นำไปสู่การลาออก
- ปี 2018 เป็นปีสุดท้ายของ GitLab summit ที่เน้นพนักงาน และตั้งแต่ปี 2019 เป็นต้นมาเปลี่ยนเป็นรูปแบบใกล้เคียงกับงานประชุมแบบดั้งเดิมที่มุ่งลูกค้ามากขึ้น
- การรวมตัวของคนมากกว่า 2,000 คนมีค่าใช้จ่ายสูงมาก การเปลี่ยนแปลงนี้จึงเข้าใจได้ในเชิงการเงิน แต่ในแง่ประสบการณ์ทางสังคม เขามองว่าสนุกน้อยลงกว่าเดิม
- ปัญหาการจัดการแล็ปท็อปก็เป็นปัจจัยขัดแย้งซ้ำ ๆ
- GitLab กำหนดหรือพิจารณาให้พนักงานที่เข้าถึงทรัพยากร GitLab ผ่าน Mac ของบริษัทหรือฮาร์ดแวร์ส่วนตัวต้องติดตั้งซอฟต์แวร์จัดการระยะไกล
- เครื่องมือที่เสนอมีลักษณะล่วงล้ำ เพราะอาจใช้บันทึกกิจกรรมผู้ใช้ได้ และรู้สึกว่ายังขาดหลักประกันป้องกันการใช้งานในทางที่ผิด
- feedback จำนวนมากจากพนักงานมักถูกเพิกเฉย จนกว่าพนักงานแกนหลักจะกดดัน
- ในที่สุด GitLab เลือกโซลูชันจัดการแล็ปท็อปที่ใช้ SentinelOne
- เมื่อการเปลี่ยนแปลงด้านวัฒนธรรมทับซ้อนกับการเปลี่ยนแปลงส่วนตัว แรงจูงใจและ productivity ลดลง ขณะที่ความเครียดเพิ่มขึ้น
- หลังจากผู้จัดการที่ได้รับการประเมินดีถูกย้ายไปบทบาทอื่นและผู้จัดการคนใหม่เข้ามาดูแลทีม ก็เกิดความขัดแย้งและมีการใช้ performance enablement plan
- PEP เป็นขั้นตอนก่อน PIP เพื่อทำให้ความสัมพันธ์และงานกลับมาเป็นปกติ
- ตอนแรกได้ยินว่าเป็นกระบวนการที่ทั้งสองฝ่ายต้องปรับปรุง แต่ในทางปฏิบัติรู้สึกว่ามุ่งเน้นเฉพาะการเปลี่ยนแปลงที่เขาต้องทำ
- เดิมกำหนดไว้หนึ่งเดือน แต่ขยายเพิ่มอีกหนึ่งเดือน และหลังสองเดือนผลลัพธ์ถูกประเมินว่าน่าพอใจ
- หลังจากนั้น เขารู้สึกว่า GitLab กับตัวเขากำลังมุ่งไปคนละทิศทาง และเริ่มคิดเรื่องลาออก
- ด้วยช่วงเวลาการเข้าตลาดหลักทรัพย์ของ GitLab และการใช้สิทธิ stock option ทำให้สามารถลาออกได้ในเดือนธันวาคม 2021
- ตอนนั้นในเนเธอร์แลนด์ เมื่อใช้สิทธิ stock option ต้องจ่าย ภาษีเงินได้ 52% จากส่วนต่างระหว่างราคาใช้สิทธิกับมูลค่าประเมิน ไม่ว่าหุ้นจะมีสภาพคล่องหรือไม่
- ภาระภาษีสูงมากจนก่อน GitLab เข้าตลาดหลักทรัพย์ เขาแทบไม่สามารถใช้สิทธิได้
- ต่อมากฎหมายเปลี่ยนให้เลือกได้ว่าจะจ่ายภาษีตอนใช้สิทธิหรือตอนหุ้นมีสภาพคล่อง
- ในเดือนธันวาคม 2021 เขาออกจาก GitLab และเริ่มโฟกัสกับ Inko แบบเต็มเวลา
บทเรียนจากประสบการณ์ที่ GitLab
-
Scalability ต้องเป็นวัฒนธรรมของบริษัท
- GitLab ไม่ได้ให้ความสำคัญกับ scalability มากพอ และเขามองว่าปัญหานี้ยังคงอยู่แม้ในเวลาที่ลาออก
- รายได้หลักของ GitLab ไม่ได้มาจาก GitLab.com แต่มาจากลูกค้าที่ self-host GitLab Enterprise Edition
- GitLab.com มีค่าใช้จ่ายสูงกว่ารายได้ที่สร้างได้มาก จึงทำให้โฟกัสไปที่ตลาด self-hosting
- ปัญหาประสิทธิภาพจำนวนมากของ GitLab.com ไม่ได้ใช้ได้โดยตรงกับลูกค้า self-hosting จำนวนมาก
- นักพัฒนาหลายคนอยากปรับปรุงประสิทธิภาพ แต่ไม่ได้รับเวลาและทรัพยากรสำหรับทำสิ่งนั้น
-
ทีมควรขับเคลื่อนด้วยข้อมูลและนักพัฒนา
- GitLab มีลักษณะขับเคลื่อนโดย product manager ค่อนข้างมาก และฟีเจอร์ที่จะ implement มักถูกกำหนดโดย product manager กับ director
- บางการตัดสินใจสมเหตุสมผล แต่บางการตัดสินใจให้ความรู้สึกเหมือนต้องสร้างสิ่งที่เห็นว่าเป็นไอเดียดีบน Hacker News
- เขามองว่าหากนำโครงสร้างลำดับชั้นที่เรียบง่ายกว่านี้มาใช้เร็วขึ้น ให้อำนาจกับ team lead มากขึ้น และให้พวกเขาโต้ตอบกับผู้ใช้มากขึ้น อาจได้ผลลัพธ์ที่ดีกว่า
- เขามองว่าบทบาท product manager ควรเป็นบทบาทที่เชื่อมทีมกับผู้ใช้ พร้อมทั้งมีส่วนร่วมเชิงเทคนิคในการสร้างผลิตภัณฑ์
-
หากไม่มีข้อมูล ก็ยากจะตัดสินว่าอะไรคือ “minimal viable”
- หนึ่งในหลักการสำคัญของ GitLab คือเริ่มต้นด้วย minimal viable change เสมอ
- ปัญหาคือแต่ละคนให้คำนิยาม “minimal” ต่างกัน
- บางทีมมองว่าประสิทธิภาพหรือ usability ที่ดีเป็น requirement ของ viable แต่บางทีมไม่ให้ความสำคัญกับสิ่งนี้
- ผลคือมีการสร้างฟีเจอร์ที่ไม่เป็นประโยชน์ต่อผู้ใช้
- serverless platform ที่ไม่มีใครขอและสุดท้ายถูกยุติ
- การรองรับการจัดการ Kubernetes cluster ที่ไม่ทำงานนาน 3 สัปดาห์แต่ไม่มีใครสังเกต
- โซลูชัน chatops ที่สร้างบน CI แทนโซลูชันเดิม
- ฟีเจอร์ requirements management ที่ทำได้แค่สร้างและดู แต่แก้ไขหรือลบไม่ได้
- GitLab ทำ user survey รายไตรมาส และบางทีมเข้าถึงข้อมูลการมีส่วนร่วมของผู้ใช้ได้ แต่จากความทรงจำและการพูดคุยกับอดีตเพื่อนร่วมงาน ข้อมูลนี้ถูกใช้เป็นครั้งคราวมากกว่าจะเป็นแกนหลักของ workflow ของทีม
-
SaaS กับ self-hosting ดำเนินควบคู่กันได้ยาก
- GitLab ให้บริการทั้งการติดตั้งแบบ self-hosting และ SaaS
- ทั้งสองโมเดลมีโครงสร้างรายได้ requirements และวิธีการนำ update ไปใช้ต่างกัน
- SaaS ต้องการการดีพลอยที่รวดเร็ว รวมถึงการจัดการข้อมูลและ workload ขนาดใหญ่บนโครงสร้างพื้นฐานส่วนกลาง
- instance แบบ self-hosting ส่วนใหญ่เล็กกว่า SaaS มาก ดังนั้นปัญหาและวิธีแก้ของ SaaS จึงใช้ตามตรงไม่ได้
- ผลลัพธ์คือหลายส่วนของแพลตฟอร์มต้องพิจารณา code path สองชุด สำหรับ SaaS และ self-hosting
- หากโฟกัสที่ SaaS หรือ self-hosting อย่างใดอย่างหนึ่ง ก็จะสามารถทุ่มความสนใจทั้งหมดให้กับประสบการณ์ที่เหมาะกับรูปแบบการดำเนินงานนั้นได้
-
คนมากขึ้นไม่ได้รับประกันผลลัพธ์ที่ดีขึ้น
- GitLab จ้างคนจำนวนมากตลอดหลายปีที่ผ่านมา และปัจจุบันมีพนักงานมากกว่า 2,000 คน
- ไม่ทราบจำนวน developer ที่แน่นอน แต่เมื่อกวาดดูหน้าทีมแล้วคาดว่าอย่างน้อยมีหลายร้อยคน
- การเพิ่มคนเข้าไปในโปรเจกต์ไม่ได้ทำให้ productivity และผลลัพธ์ดีขึ้นเสมอไป ซึ่งเกี่ยวข้องกับ “The Mythical Man-Month” ด้วย
- แม้ไม่มีข้อมูล แต่เขามองว่าบริษัทส่วนใหญ่มี developer ไม่เกิน 20 คนก็เพียงพอ บางบริษัทอาจต้องใช้ 20~50 คน และมีเพียงน้อยมากที่ต้องใช้ 50~100 คน
- หากมี developer เกิน 100 คน ควรคิดว่าขอบเขตผลิตภัณฑ์กำลังใหญ่เกินไปหรือไม่
- การประเมินนี้เกี่ยวกับ software developer และถือว่าส่วนอย่างการผลิต custom hardware, sales, support ซึ่งมีต้นทุนการประสานงานต่างออกไปเป็นข้อยกเว้น
-
การประเมิน Ruby on Rails มีสองด้าน
- GitLab ถูกสร้างด้วย Ruby และ Ruby on Rails และการผสมผสานนี้มีส่วนอย่างมากต่อความสำเร็จของ GitLab
- ในขณะเดียวกัน เมื่อโปรเจกต์ใหญ่ขึ้นและมี contributor หลากหลายระดับประสบการณ์ Rails ก็ทำให้สร้างโค้ดที่มีประสิทธิภาพไม่ดีได้ง่าย
- ตัวอย่างปัญหาที่เด่นคือ N+1 query problem
- ActiveRecord ของ Rails มีฟีเจอร์แก้ปัญหานี้ แต่เป็นแบบ opt-in
- หาก developer ลืมใช้ ก็จะเกิด query ต่อ row และทำให้เกิดปัญหาประสิทธิภาพ
- ปัญหาประสิทธิภาพจำนวนมากที่แก้ในช่วงปีแรก ๆ ของ GitLab คือ N+1 query
- Ruby เองก็เป็นภาษาที่ยอดเยี่ยม แต่ลักษณะที่ใช้ meta programming มากทำให้ยากสำหรับโปรเจกต์ขนาดใหญ่
- Go, Rust, Node.js อาจมีประสิทธิภาพกว่า Ruby แต่เขามองว่าไม่มี framework ที่ทรงพลังเท่า Ruby on Rails
- Python กับ Django ก็อาจเป็นตัวเลือกได้ แต่เขามองว่ามีแนวโน้มจะเจอปัญหาบางส่วนแบบเดียวกับ Ruby และ Rails
-
เวลาในการดีพลอยสำคัญต่อความสำเร็จขององค์กร
- เขามองว่า code ควรถูกดีพลอยได้ภายในไม่เกินหนึ่งชั่วโมงหลัง push ไปยัง branch หรือ tag ที่เป็นเป้าหมายการดีพลอย
- GitLab ใช้เวลาประมาณ 4 ปีกว่าจะเข้าใกล้จุดนี้ และยังเหลือทางอีกไกล
- การดีพลอยที่รวดเร็วช่วยรับมือเหตุขัดข้อง
- หากการดีพลอยใช้เวลาหลายชั่วโมง อาจจำเป็นต้องทำ hot-patch
- การดีพลอยที่รวดเร็วยังส่งผลต่อแรงจูงใจ
- เมื่อได้เห็นและใช้งานการเปลี่ยนแปลงที่สร้างขึ้นจริง ก็ทำให้รู้สึกพอใจ
- สถานการณ์ที่การเปลี่ยนแปลงซึ่งทำมาหลายสัปดาห์ต้องรออีก 2 สัปดาห์จึงจะดีพลอย ทำให้หมดกำลังใจ
- องค์กรควรก้าวร้าวอย่างมากในการลดเวลา deploy และเวลาที่ test suite ใช้ในกระบวนการ deploy
- ประเด็นสำคัญไม่ใช่ว่าการทดสอบและการดีพลอยทั้งหมดต้องต่ำกว่ากรอบเวลาหนึ่งเสมอไป แต่คือการให้ priority กับการดีพลอยให้เร็วที่สุดเท่าที่ข้อกำหนดทางธุรกิจอนุญาต
-
เงินเดือนตามตำแหน่งที่อยู่เป็นการเลือกปฏิบัติ
- เงินเดือนของ GitLab ได้รับผลจากหลายตัวแปร และหนึ่งในนั้นคือ ตำแหน่งที่อยู่
- หากบริษัทมีสำนักงานจริงและต้องจ้างงานในบางภูมิภาค การปรับตามตำแหน่งที่อยู่อาจเข้าใจได้ แต่สำหรับบริษัททางไกลเต็มรูปแบบ เขามองว่าไม่มีเหตุผลที่ชอบธรรมในการจ่ายเงินเดือนต่างกันให้คนสองคนที่มีประสบการณ์และความรับผิดชอบเท่ากัน เพียงเพราะอยู่คนละที่
- ตอนลาออก เงินเดือนที่ได้รับในเนเธอร์แลนด์อยู่ที่ ประมาณ €120,000 ต่อปีก่อนหักภาษี หรือ ประมาณ €8,500 ต่อเดือน
- เขามองว่าหากอาศัยอยู่ใน Bay Area ก็น่าจะได้รับอย่างน้อยสองเท่า หรืออาจมากกว่านั้น
- ทางแก้คือให้ค่าตอบแทนตาม requirements ของงาน ไม่ใช่ตำแหน่งที่อยู่ของผู้สมัคร
- 0xide Computer Company ถูกกล่าวถึงว่าเป็นบริษัทที่จ่ายจำนวนเดียวกัน ไม่ใช่ตามตำแหน่งที่อยู่
- เนื้อหาที่เกี่ยวข้องกล่าวไว้ใน Compensation as a Reflection of Values
สรุป
- ช่วงเวลาที่ GitLab เป็นประสบการณ์ที่มีทั้งด้านบวกมาก ๆ และด้านลบปะปนกัน
- เขารู้สึกภูมิใจอย่างมากกับผลงานที่ทำในหลายทีมและผู้คนที่ได้ทำงานร่วมกัน
- เป็นเรื่องน่าเสียดายที่ช่วงประมาณหนึ่งปีสุดท้ายทำให้ประสบการณ์โดยรวมมีรสขม
- เขาไม่เสียใจที่ได้ทำงานที่ GitLab และหากย้อนกลับไปทำได้อีกครั้ง ก็คงทำบางอย่างต่างออกไปจากบทเรียนที่มองเห็นเมื่อมองย้อนกลับ
- แม้จะมีข้อบกพร่อง แต่เขาคิดว่า GitLab ยังดีกว่าบริษัทอื่นจำนวนมาก และยังคงแนะนำว่าเป็นบริษัทที่น่าทำงานด้วย
1 ความคิดเห็น
ความเห็นจาก Hacker News
ถ้าบริษัทลดค่าจ้างเพราะสีผิวหรือเพศ นั่นย่อมเป็นปัญหาใหญ่ แต่การเปรียบเทียบว่าทำไมการลดค่าจ้างเพราะที่อยู่อาศัยถึงโอเค อาจต้องคิดกันให้ลึกกว่านี้
สีผิว·เพศ กับ ที่อยู่อาศัย แตกต่างกันในแง่ว่าเปลี่ยนได้หรือไม่ และเกี่ยวข้องกับงานจริงหรือไม่
ที่อยู่อาศัยเกี่ยวข้องกับงาน เพราะบริษัทต้องรับภาระเรื่องการตั้งนิติบุคคลท้องถิ่น ความเข้าใจระบบกฎหมาย·ภาษี เขตเวลา ค่าเดินทาง เป็นต้น
จะถกเถียงได้ว่าค่าตอบแทนตามภูมิภาคนั้นถูกต้องหรือไม่ แต่ถ้าเอาไปเทียบกับการเหยียดเชื้อชาติ·การเลือกปฏิบัติทางเพศ ก็เท่ากับทำให้ GitLab ดูเหมือนเป็นองค์กรที่เหยียดเชื้อชาติ·เพศ และการถกเถียงก็จะจบลงอย่างรวดเร็ว
ถ้าอาศัยอยู่ใน Bay Area ก็น่าจะได้มากกว่าสองเท่า แต่การบอกว่าไม่ยุติธรรมเพียงเพราะอยู่คนละที่ ดูจะไม่ใช่ประเด็นที่น่าเรียกร้องความเห็นใจตรงนี้
ข้อโต้แย้งนี้ออกจะใกล้เคียงกับการไม่เข้าใจเศรษฐศาสตร์มากกว่า
ตอนนี้เงินเดือนที่ได้รับในสหรัฐฯ ราวกับเป็นสองเท่าของตอนอยู่สหราชอาณาจักร แต่ระดับคุณภาพชีวิตกลับใกล้เคียงกัน บางด้านแย่กว่า บางด้านดีกว่า
ถ้าผู้เขียนต้นฉบับย้ายไป Bay Area จริง แม้ค่าตอบแทนจะสูงขึ้น คุณภาพชีวิตก็มีโอกาสลดลงด้วยซ้ำ
ต้องพิจารณาทั้งรายได้ สวัสดิการสังคม ภาษี และวัฒนธรรม และก็ยังคิดอยู่เหมือนกันว่ายอมลดเงินเดือนก้อนใหญ่เพื่อกลับยุโรปแล้วใช้ชีวิตให้สบายขึ้นก็คุ้ม
เหตุผลของ GitLab ในการกำหนดค่าตอบแทนตามภูมิภาคอธิบายไว้ที่ https://handbook.gitlab.com/handbook/total-rewards/compensat... และดูมีเหตุผลพอสมควร
ถ้าจ่ายเงินเดือนระดับ Bay Area ให้ถึงฟิลิปปินส์หรือยูเครน ผู้คนอาจถูกผูกไว้ด้วย กุญแจมือทองคำ จนแม้ถึงเวลาต้องออกก็ออกไม่ได้ และอาจหมดไฟได้
ในทางกลับกัน ถ้าจ่ายตามค่ากลางของโลก ก็จะจ้างคนในแคลิฟอร์เนียหรือลอนดอนไม่ได้
ข้ออ้างที่ว่าผู้จัดการผลิตภัณฑ์ไม่จำเป็น และผลิตภัณฑ์หนึ่งไม่ควรมีนักพัฒนาเกิน 100 คน ก็เป็นเรื่องที่ถกเถียงกันได้
ผู้เขียนต้นฉบับดูเป็นวิศวกรที่เก่งมากและมีอิสระในการทำงานสูง ซึ่งน่าจะมีความสุขและประสบความสำเร็จมากกว่าในสตาร์ทอัพขนาดค่อนข้างเล็ก
ถ้าไม่ต้องรอการเปลี่ยนแปลงกฎภาษี ก็อาจลาออกได้เร็วกว่านี้และเขียนบันทึกประสบการณ์ที่ดีกว่านี้ก็ได้
และก็น่าคิดเหมือนกันว่าถ้าได้นอกจากหุ้นแล้ว ยังได้ ค่าตอบแทน $300k ในอัมสเตอร์ดัมด้วย การตัดสินใจลาออกจากบริษัทจะยากแค่ไหน
ถ้าบังคับให้จ่ายค่าตอบแทนเท่ากันทั่วโลก บริษัทก็น่าจะหันไปจ้างเฉพาะคนท้องถิ่น เพราะมีข้อได้เปรียบเรื่องออฟไซต์ เขตเวลาเดียวกัน และการสื่อสาร
โดยเฉพาะในสภาพเศรษฐกิจที่แม้แต่ในพื้นที่ค่าครองชีพสูงก็ยังมีคนอยากสมัครงานมาก ก็ยิ่งเป็นแบบนั้น
อนาคตอาจเปลี่ยนไปได้ แต่การมองดูโครงสร้างแรงจูงใจที่เป็นจริงนั้นมีประโยชน์
ยังมีความเสี่ยงที่บริษัทต้องรับเมื่อจ้างคนจากต่างประเทศด้วย และสิ่งนี้ก็มีผลทิ้งทั้งความรู้และเมล็ดพันธุ์ของบริษัทในอนาคตไว้ในท้องถิ่นนั้น
การเข้าออฟฟิศทำให้ค่าครองชีพของพื้นที่นั้นกลายเป็นอำนาจต่อรองเรื่องค่าจ้างของพนักงาน แต่ในบริษัทและวัฒนธรรมที่ทำงานระยะไกลเต็มรูปแบบ บริษัทสามารถจ้างคนจากที่ไหนก็ได้และจ่ายเงินเดือนที่ใกล้เคียงกับ ตัวหารร่วมต่ำสุด
การทำงานระยะไกลทำให้ทุกคนกลายเป็นเหมือนผู้รับจ้างอิสระที่ต้องแข่งขันกับแรงงานทั่วโลก ขณะที่การทำงานในออฟฟิศทำให้ต้องแข่งขันเป็นหลักกับคนในพื้นที่เดียวกัน
ดูเหมือนเป็นเรื่องของคนที่เป็นพนักงานคนที่ 28 เคยรายงานตรงกับ CEO แต่แล้วค่อย ๆ มีผู้จัดการหลายชั้นเข้ามาแทรก และเมื่อหนึ่งในนั้นใส่เขาเข้า PEP เขาก็จับสัญญาณได้แล้วเลือกออกไป
เป็นลำดับเหตุการณ์ที่ค่อนข้างมาตรฐาน และอาจเป็นหนึ่งในเหตุผลที่คนในบริษัทใหญ่ทำเรื่องใหญ่ ๆ ได้ไม่ดี
ต่อให้คุณเริ่มโปรเจกต์ในบริษัทและทำให้มันสำเร็จ บริษัทก็จะเอาคนระดับบนเข้ามาแทรก สุดท้ายคุณอาจกลายเป็นพนักงานลำดับที่ n ในโปรเจกต์ที่ตัวเองเริ่ม แล้วถูกบอกว่าผลงานไม่พอ
อยากทำแต่เรื่องสนุกและน่าสนใจ สุดท้ายก็มีความเห็นแรงกล้ากับเรื่องที่ไม่สำคัญ และถ้า individual contributor ที่สนิทกับ CEO ไม่ยอมรับการตัดสินใจของผู้จัดการ การบริหารก็จะกลายเป็นฝันร้าย
สามารถขยับตัวไปมาโดยไม่ต้องรับผิดชอบต่อการตัดสินใจ แล้วสร้างปัญหาได้
ความปลอดภัยของ endpoint และการใช้อุปกรณ์ส่วนตัวเป็นหนึ่งในเบาะแส
วัฒนธรรมที่ผ่อนปรนแบบนี้ขยายต่อไม่ได้เพราะต้นทุนด้าน compliance และ productivity ของการพัฒนา
การไปดึงนักพัฒนารุ่นเก่าที่ยืนกรานจะใช้ Linux distro ที่ตัวเองชอบออกมานั้นทำได้ยาก แต่สำหรับงานก็ควรใช้คอมพิวเตอร์ของบริษัท และให้บริษัทจัดการการอัปเดต
เรื่องการสำรองข้อมูลฐานข้อมูลก็เหมือนกัน ถ้าเป็นทีมฐานข้อมูล งานอันดับหนึ่งก็คือ backup
จะใช้รูปประธานถูกกระทำว่า “ไม่มี backup” เพื่อกลบเรื่องนี้ไม่ได้ และก็ดูเหมือนว่าเจ้าตัวสนใจการถกเถียงเรื่องสถาปัตยกรรม sharding มากกว่าการดูแลไซต์ในชีวิตประจำวัน
ข้อสรุปที่ว่า GitLab ลงทุนกับประสิทธิภาพของผลิตภัณฑ์โฮสติ้งไม่พอก็เช่นกัน ถ้าผลิตภัณฑ์นั้นขาดทุนหนัก การไม่ใส่ทรัพยากรเพิ่มก็อาจเป็นเรื่องธรรมดา
ต้องโน้มน้าวด้วย เหตุผลทางธุรกิจ จริง ๆ ว่าทำไมงานนั้นถึงสำคัญกว่าและทำเงิน ไม่ใช่เพราะมันเป็นงานวิศวกรรมที่สนุก
มีผู้จัดการคนหนึ่งที่เคยเริ่มโปรเจกต์ที่ประสบความสำเร็จร่วมกัน แต่ฝ่ายบริหารดึงการเมืองและภาวะกลืนไม่เข้าคายไม่ออกทางสังคมเข้ามาอย่างละโมบ แล้วสอดแทรกชั้นผู้บริหารเข้ามา พร้อมพยายามแทนที่ทั้งฉันและผู้จัดการคนนั้น
ฉันได้เรียนรู้แล้วว่าไม่ควรใส่ใจกับงานมากเกินไป และเพราะอย่างนั้นจึงรู้สึกว่าโปรเจกต์จะพังและถูกยุบในที่สุด
บรรยากาศตรงนี้เหมือนตั้งต้นว่าพนักงานคนนั้นเป็นคนผลงานสูงจริง ไม่จำเป็นต้องมีผู้จัดการ และไม่สมควรโดน PEP แต่สมมติฐานแบบนั้นไม่ปลอดภัยนัก
ฉันเคยเห็นพนักงานยุคแรกในสตาร์ตอัประยะแรกที่เติบโตไม่ทัน หรือไม่อยากเติบโตให้ทันกับความเร็วที่บริษัทและบทบาทงานขยายตัว
มักปล่อยให้อยู่ต่อเพราะความเคารพต่อผลงานในอดีต ความรู้เชิงประวัติศาสตร์ที่แทนยาก และความสัมพันธ์กับผู้ก่อตั้งรวมถึงพนักงานยุคแรกที่กลายเป็นผู้นำ
แต่การเป็นพนักงานยุคแรกและเคยมีส่วนร่วมในโปรเจกต์สำคัญช่วงต้น ไม่ได้แปลว่ายังเป็นคนที่ดีที่สุดหรือเหมาะสมที่สุดสำหรับงานนั้นเสมอไป
บางคนอาจเก่งมากในการประคองอะไรบางอย่างด้วยวิธีเฉพาะหน้า งาน
cronและการแทรกแซงด้วยมือ แต่ในบริษัทใหญ่ วิธีปฏิบัติการแบบนั้นอาจไม่เหมาะเลยถ้าปรับตัวไม่ได้ หรือไม่พอใจที่ต้องทำงานแบบบริษัทใหญ่ ก็อาจให้โทษมากกว่าประโยชน์
ทุกบริษัทระยะเริ่มต้นต่างก็มีพนักงานยุคแรกที่เติบโตไปด้วยกันไม่ได้ แต่ก็ไม่ใช่ตอนจบแบบเดียวหรือแบบที่พบบ่อยเสมอไป
GitLab ก็มีพนักงานที่อยู่นานจำนวนมาก แต่ในโพสต์บล็อกที่เต็มไปด้วยความคับข้องใจ เราจะไม่ได้ยินเสียงจากคนเหล่านั้น จึงควรคำนึงถึง selection bias
ฉันใช้ GitLab มานาน และตัวผลิตภัณฑ์ก็ยังพัฒนาต่อเนื่อง ดังนั้นจึงไม่เห็นด้วยกับข้ออ้างว่ามันเป็นผลิตภัณฑ์ที่หยุดนิ่งแล้ว
ต้องรอให้ผ่านไป 3 ปีจนเห็นว่าการรีลีสล้มเหลวซ้ำ ๆ ถึงกลายเป็นปัญหา แต่ก็ดูเหมือนไม่ใช่เพราะอิทธิพลของฉัน แต่ออกจะเหมือนมีใครไปค้น Google ว่า “จะหยุดการรีลีสล้มเหลวได้อย่างไร” มากกว่า
ฉันไม่รู้วิธีแก้ และตอนนี้ก็ยังเจอเรื่องเดิมซ้ำอีกในหัวข้ออื่น
ตอนแรกก็แค่ทำงานที่จำเป็นให้เสร็จ แต่ต่อมาทุกขั้นตอนต้องผ่านตำแหน่งผู้จัดการที่เพิ่งถูกสอดเข้ามาใหม่ โดยอ้างว่าเพื่อให้แน่ใจว่าจะไม่ทำสิ่งผิด
มันเกิดขึ้นโดยไม่เกี่ยวอะไรกับไอเดียและผลงานช่วงแรกที่ทำให้บริษัทเติบโตมาได้
ฉันสงสัยว่าฉากหลังที่ทำให้ issue เก่า ๆ เกี่ยวกับ GitLab CI ค้างอยู่นานหลายปีจะเกี่ยวข้องกับเรื่องนี้ด้วยหรือไม่
จากมุมมองคนนอก GitLab ดูเหมือนสูญเสียความสามารถในการสร้างสิ่งยอดเยี่ยมไปหมดแล้ว และให้ความรู้สึกว่าแม้บั๊กอายุหลายปียังคงเกิดซ้ำ ก็ไม่ได้พยายามจะแก้
ประเด็นที่อนุญาตให้พนักงานใช้คอมพิวเตอร์ส่วนตัวนี่แทบจะน่าตกใจเลย
ไม่ว่าองค์กรจะเล็กแค่ไหน ก็ควรจัดหา อุปกรณ์ที่บริษัทเป็นเจ้าของ และให้ทำงานของบริษัททั้งหมดบนอุปกรณ์นั้น
บริษัทได้ประโยชน์มากในแง่การควบคุมทรัพย์สินทางปัญญา พนักงานเองก็ได้ประโยชน์มากในการแยกเวลางานกับเวลาส่วนตัว และค่าใช้จ่ายก็ไม่ได้สูงมากขนาดนั้น
จะไปที่ไหนก็ยังใช้ชุดเครื่องมือแบบเดิมที่ต้องการได้ และความสามารถในการลบทิ้งแล้วสร้างใหม่อย่างรวดเร็วก็ดีต่อการดีบักปัญหาประเภท “เครื่องฉันทำได้/ทำไม่ได้” ด้วย
ปลายด้านหนึ่งคือวิธีที่พึ่งความจำ และอีกปลายคือการทำบิลด์ที่ทำซ้ำได้ครบถ้วนจากที่ไหนก็ได้ด้วย https://nixos.org/
ระหว่างนั้นก็ยังมีตัวเลือกอีกมาก และผมก็เคยเห็นคนที่ดูแลชุดไฟล์ Ansible สำหรับติดตั้งสิ่งที่ต้องใช้ด้วย
host: localhostผมใช้ Ubuntu เวอร์ชันล่าสุด และดูแลเชลล์สคริปต์อยู่ไม่กี่ตัว [1] ที่ติดตั้งสิ่งที่ผมต้องการได้ราว 80% บนเครื่องที่เพิ่งติดตั้งใหม่
ถ้าอยากเข้าหาแบบเป็นวิทยาศาสตร์หน่อย ก็อาจติดตั้งอะไรอย่าง https://atuin.sh/ เพื่อเก็บสถิติจากประวัติเชลล์ระยะยาวว่าจริง ๆ แล้วเราเรียกใช้โปรแกรมไหนบ่อย
[1]: https://github.com/hiAndrewQuinn/shell-bling-ubuntu
มันไม่ใช่วิธีแก้ที่สมบูรณ์แบบ แต่ถ้าอย่างน้อยเป็นอุปกรณ์ของบริษัท การรั่วไหลก็จะเป็นผลจากการกระทำโดยเจตนาร้าย หรือจากความไร้ความสามารถที่ย้ายข้อมูลอ่อนไปยังช่องทางที่ไม่ได้รับอนุญาต
ถ้าบริษัทถูกฟ้อง เนื้อหาในอุปกรณ์ส่วนตัวก็อาจกลายเป็นเป้าหมายของหมายเรียกไปด้วยสารพัดอย่าง
การบังคับให้ต้องมีอีกเครื่องหนึ่งแยกต่างหากไม่ได้ให้ประโยชน์ด้านสมดุลงานกับชีวิตกับผู้ใช้มากนัก มีแต่จะไม่สะดวก
พฤติกรรมในการแยกเวลางานกับเวลาส่วนตัวนั้น ส่วนใหญ่ขึ้นอยู่กับนิสัย ความสามารถ และท้ายที่สุดคือการตัดสินใจของตัวเอง
เมื่อก่อนผมเคยรู้สึกว่าการจ่ายเงินเดือนตามภูมิภาคเป็นการเลือกปฏิบัติ แต่ตอนนี้ส่วนใหญ่เลิกคิดแบบนั้นแล้ว
สุดท้ายมันคือการเรียกร้องเงินเดือนแบบ SF และคนอินเดียก็จะเรียกร้องเงินเดือนแบบเนเธอร์แลนด์หรือ SF
ถ้าเป็นแบบนั้นก็มีโอกาสสูงที่จะเกิดการแข่งขันกดราคาลงสู่ข้างล่าง
ข้อเท็จจริงง่าย ๆ คือแต่ละคนก็ได้เงินพอจะอยู่ดีในพื้นที่ของตัวเอง
ถ้าต้องการมากกว่านั้นก็ย้ายได้ และถ้าไม่ย้ายก็น่าจะมีเหตุผลของตัวเอง
ทุกคนอยากได้ทั้ง เงินเดือนแบบ SF และค่าครองชีพแบบ Indiana หรือ India แต่ด้วยเหตุผลที่ชัดเจน มันเกิดขึ้นได้ยาก
ถ้าถูกจ้าง ไม่ว่าคุณจะอยู่ San Francisco, Poland หรือ Indonesia ก็จะได้ เงินเดือนระดับสหรัฐฯ
ตำแหน่งแบบนี้แข่งขันกันดุเดือดมาก
มันเหมือนกับการเปิดประตูให้คนทั้งโลกแล้วบอกว่า “เอาสิ่งที่คุณมีมาโชว์” ดังนั้นบริษัทจึงมองฐานผู้สมัครและฐานคนเก่งที่ใหญ่กว่ามากได้ และในนั้นก็มีคนเก่งระดับพิเศษที่ฉลาดและมุ่งมั่นมากจากประเทศที่ยากจนจำนวนมาก
อุปสงค์และอุปทานก็ทำงานแบบนั้น
ถ้าบอกว่าจะจ่ายมากขึ้น โดยปกติก็จะได้เลือกผู้สมัครที่มีคุณภาพสูงขึ้น
ผมรู้จักคนจำนวนไม่น้อยที่ทำงานทางไกลจากหลายรัฐในสหรัฐฯ และได้เงินเดือนระดับ SF
มันเป็นไปได้อยู่แล้ว
SF เองก็ไม่ควรมั่นใจตัวเองเกินไป
Detroit เองก็เคยเป็นทั้ง Motor City และ Music City และเคยเป็นศูนย์กลางด้านวัฒนธรรมและเทคโนโลยีระดับโลก แต่ความสามารถหลักของมันก็ถูกสั่นคลอนโดยแรงงานจากพื้นที่อื่นที่ถูกกว่าและมีประสิทธิภาพกว่า
สิ่งที่เรียกร้องคือ งานเท่ากัน ค่าจ้างเท่ากัน
ถ้าคนในทีมทำงานเดียวกัน แต่คนอื่นได้เงินเต็มจำนวนแล้วตัวเองได้แค่บางส่วน นั่นถือว่าผิดเพี้ยนอย่างมาก
การมีส่วนร่วมต่อทีมไม่ได้ขึ้นอยู่กับว่าตอนนี้คุณอยู่ที่ไหน
เวลาที่ใช้ไปกับการเดินทางไปทำงานก็ไม่ได้เปลี่ยนความคาดหวังต่อผลงาน
ถ้าทำเลที่ตั้งสำนักงานแพงเกินไป บริษัทก็ควรแก้ปัญหาด้วยการหาที่ตั้งที่ถูกกว่า ไม่ใช่ให้พนักงานมาช่วยอุดหนุนการเลือกทำเลสำนักงานที่แย่ของบริษัท
เงิน 100k ที่พนักงานได้รับกับต้นทุนของบริษัทไม่ใช่สิ่งเดียวกัน
แต่ละประเทศมีภาษี ประกันสังคม และสวัสดิการที่บริษัทต้องจ่ายเพิ่มต่างกัน และหลายกรณีก็ต้องมีนิติบุคคลท้องถิ่นหรือรูปแบบกิจการเสมือน ตลอดจนทรัพยากรเพื่อช่วยให้ปฏิบัติตามกฎหมายท้องถิ่น
ผมเองก็อยู่ฝั่งพนักงานที่ทำงานบทบาทระดับโลกในบริษัทข้ามชาติ แต่ได้รับเงินเดือนตามมาตรฐานท้องถิ่น และเรื่องนี้ก็มีสิ่งให้ต้องพิจารณามากกว่าที่เห็นภายนอก
โดยพื้นฐานคือปรับตาม ค่าครองชีพ ไม่ใช่ตามต้นทุนการจ้างงาน แต่ก็ยังตั้งเป้าให้เงินเดือนมีความเท่าเทียมกัน
ผู้จัดการห่วย ๆ คือปัญหาเรื้อรังของอุตสาหกรรม
ในทางกลับกัน สตาร์ตอัปจำนวนมากก็เกิดขึ้นเพราะผู้ก่อตั้งเคยเจอผู้จัดการห่วย ๆ ในที่ทำงานเดิม
มันทำให้นึกถึงเรื่องของ traitorous eight กับ Fairchild Semiconductors
ในกรณีของผมเอง ถ้าไม่ได้เจอผู้จัดการที่ไม่ใช่สายเทคนิค เล่นการเมือง และชอบเอาคืนในงานก่อนหน้า ผมก็คงไม่มีแรงจูงใจจะเริ่มสตาร์ตอัปของตัวเอง
พอมองย้อนกลับไป บางทีก็ยังคิดว่าถ้าเจอผู้จัดการแย่ ๆ แบบนั้นให้เร็วกว่านี้ในช่วงต้นอาชีพก็คงดี
และก็คงดีถ้าจะย้ายไปหาบริษัทที่ต้องการทักษะของผมจริง ๆ ได้ง่ายขึ้น โดยไม่ต้องแบกรับภาระของกระบวนการ HR มากนัก
มีข้ออ้างว่าโมเดลการเขียนโปรแกรมโดยรวมของ Ruby ตั้งอยู่บนสมมติฐานว่าเวลาส่วนใหญ่หมดไปกับการรอ I/O หรือเครือข่าย จึงไม่ต้องให้ความสำคัญกับความเร็วของภาษา
แต่ตอนนี้ฝั่ง Node.js และ JVM มีโมเดลที่สามารถทำงานอย่างอื่นไปพร้อมกัน หรือรองรับคำขอได้มากขึ้นระหว่างรอ I/O·เครือข่าย
การใช้ Ruby/Rails ในปี 2024 อาจเป็นความสิ้นเปลือง แต่ก็อาจเป็นตัวเลือกที่ดีสำหรับแอปองค์กรที่มีจำนวนผู้ใช้จำกัด กรณีที่ความเร็วในการพัฒนาสำคัญอย่างยิ่ง หรือการทำต้นแบบอย่างรวดเร็วเพื่อทดสอบตลาด
Rails เป็นเฟรมเวิร์กที่ยอดเยี่ยมและมีประสิทธิภาพในการพัฒนาสูงมาก แต่โปรเจกต์ Rails ที่มีอายุ 2~3 ปีมักดูแลรักษายากเสมอ
โปรเจกต์ Rails ไม่ได้ยากกว่าโปรเจกต์ Django หรือ Express แต่อย่างใด
ไม่ว่า codebase ไหนก็ต้องมีวินัยและการดูแลอย่างสม่ำเสมอเพื่อไม่ให้รกเป็นวัชพืช
ถ้าจะบอกว่าจุดอ่อนของ Ruby และ Rails คืออะไร ก็ยังคงเป็นเรื่อง ประสิทธิภาพดิบของภาษา และความต้องการ·การใช้หน่วยความจำที่สูงกว่า จึงน่าดึงดูดน้อยกว่าสำหรับงานที่ต้องการ latency ต่ำหรือ memory footprint เล็ก
จากประสบการณ์ ปัญหามักเกิดตอนทราฟฟิกแกว่งขึ้นลงอย่างรุนแรงแบบฉับพลัน หรือเมื่อมีผู้ใช้ที่ active จำนวนมากใช้ WebSocket และฝั่ง WebSocket ก็แก้ได้เกือบหมดด้วย anycable
แต่มีผลิตภัณฑ์น้อยมากที่จะชนข้อจำกัดแบบนั้น และต่อให้ชนก็ยังแก้ได้
Stripe, GitHub, Shopify เป็นตัวอย่างเด่นที่แสดงว่า Rails ขยายระบบได้โดยไม่มีปัญหาในหลายรูปแบบ
แรงผลักดันสำคัญของ Rails คือแนวคิดเรื่อง ความสุขของนักพัฒนา ของ DHH ซึ่งเชื่อมโยงอย่างใกล้ชิดกับความเร็วในการพัฒนา
ที่ชุมชน Rails มีการพูดถึง I/O ก็เพราะมันสำคัญต่อการรันเว็บเซิร์ฟเวอร์ ไม่ใช่เพราะมันเป็นจุดสนใจเดียวหรือจุดสนใจหลักในการตัดสินใจเลือกระหว่างภาษาและเฟรมเวิร์ก
ถ้าเป้าหมายคือทำให้การใช้ CPU ของเว็บเซิร์ฟเวอร์สูงสุด Rails ก็ทำได้มานานแล้วด้วยการรันหลายโปรเซส ซึ่งคล้ายกับการรันหลายเธรดบน JVM
มันอาจไม่สะดวกเท่า แต่เป็นโมเดลที่ใช้กันมาตั้งแต่ยุค 90 และโดยทั่วไป web request มักทำงานแยกจากกัน จึงบ่อยครั้งที่การสื่อสารระหว่างโปรเซสไม่ใช่ปัญหาใหญ่
การเหมารวมว่าเป็น “ความสิ้นเปลือง” นั้นแรงเกินไป
การเขียนแอปด้วย Rust ก็อาจเป็นความสิ้นเปลืองได้เช่นกัน ขึ้นอยู่กับว่าแรงกดดันอยู่ตรงไหน
ในช่วงเริ่มต้น สิ่งที่น่ากังวลกว่ามากคือการยังปล่อยผลิตภัณฑ์ไม่ได้ และแม้ในช่วงกลางถึงปลาย ความเร็วของนักพัฒนาก็ยังเป็นหนึ่งในปัจจัยที่ขยายได้ยากที่สุด
ในฐานะ CTO ของบริษัทที่ใช้ Rails ฝั่ง backend และ React ฝั่ง frontend ความเร็วในการพัฒนาสำคัญมาก และความเร็วในการพัฒนาด้วย Rails ก็ยังเป็นข้อได้เปรียบใหญ่อยู่เสมอ
ปัญหาการขยายระบบมีอยู่ แต่ 99% ไม่ใช่ปัญหาของ Rails ทว่าเป็นปัญหาของ ฐานข้อมูล
มองว่าการที่บริษัทพยายามจ่ายเงินให้วิศวกรตามที่ตั้งก็เป็นการเลือกปฏิบัติอีกรูปแบบหนึ่ง
ควรจ่ายตามความสามารถของพนักงาน ไม่ใช่ตามที่ตั้ง
กฎของรัฐบาลบอกว่าอย่าเลือกปฏิบัติด้วยเหตุอย่างเพศ ศาสนา รสนิยมทางเพศ ฯลฯ แล้วการเลือกปฏิบัติด้านค่าจ้างตามที่ตั้งยุติธรรมหรือ?
เคยเห็นเพื่อนที่ย้ายจาก Europe ไป Asia ในตำแหน่งเดิม เป็นคนเดิม แต่ได้เงินน้อยลงเพียงเพราะย้ายที่อยู่
ถ้าย้ายไปตลาดที่แข่งขันน้อยกว่าและหางานอื่นได้ยากขึ้น ก็มีโอกาสมากขึ้นที่จะยอมทำงานด้วยเงินเดือนที่ต่ำลง
แม้การทำงานทางไกลจะดูเหมือนไม่ถูกผูกกับตลาดท้องถิ่น แต่หลายครั้งรัฐบาลก็ตั้งกำแพงสูงมากต่อการจ้างงานข้ามประเทศ ทำให้บางประเทศกลายเป็นตลาดที่แข่งขันน้อยกว่าได้
ถ้าทำงานแบบเดียวกันในบริษัทเดียวกันแล้วเงินเดือนลดลงเพราะย้ายประเทศ ก็แทบจะแน่นอนว่าเป็นเพราะคุณยอมรับการลดนั้น
มองว่าบริษัทควรจ่ายโดยอิงจากความสามารถของพนักงานในการมีชีวิตที่ สะดวกสบายและมีสุขภาพดี มากกว่ามาตรวัดคุณค่าแบบสากลใดๆ
คิดว่ามาตรวัดสากลแบบนั้นเป็นไปไม่ได้
การยืนยันว่าควรจ่ายตามความสามารถเพียงอย่างเดียวอาจนำไปสู่การทำลายชุมชนโดยไม่ตั้งใจ และทำให้ gentrification กับการสลายตัวของความยึดเหนี่ยวทางสังคมรุนแรงขึ้นผ่านความเหลื่อมล้ำ
ที่ตั้งจึงสำคัญ
เพราะเป็นการจ่ายเพื่อให้มีคุณภาพชีวิตแบบเดียวกัน ที่อยู่อาศัยประเภทเดียวกัน โอกาสในการเลี้ยงดูครอบครัว และโอกาสส่งลูกเข้าโรงเรียนระดับใกล้เคียงกัน
ค่าใช้จ่ายของสิ่งเหล่านี้ต่างกันไปในแต่ละประเทศ ดังนั้นรายได้ที่จำเป็นก็ต้องต่างกัน
บริษัทต้องการความสามารถบางอย่าง และตลาดตีมูลค่าความสามารถนั้นไว้เท่าไร บริษัทก็จะจ่ายเท่านั้น ไม่มากไปกว่านั้น
ตลาดให้ราคาความสามารถเดียวกันต่างกันไปตามที่ตั้ง ดังนั้นเงินเดือนจึงต่างกัน
ศาสนาอาจเป็นข้อยกเว้นที่กำกวม แต่ไม่ว่าจะยุติธรรมหรือไม่ นี่ก็ไม่ใช่การเลือกปฏิบัติ
ถ้า GitLab.com มีต้นทุนสูงกว่ารายได้ที่ทำได้อยู่เสมอ และบริษัทหาเงินหลักจากลูกค้า GitLab Enterprise Edition แบบ self-hosted ก็ชวนสงสัยว่าการไม่ลงทุนเรื่อง scalability ให้เพียงพอนั้นเป็นความผิดพลาดจริงหรือไม่
ในเบื้องต้น บริษัทควรลงทุนในสิ่งที่ทำเงินมากกว่าสิ่งที่ทำให้ขาดทุน
จะมองในเชิงกลยุทธ์ระดับสูงได้ว่า gitlab.com ที่มีประสิทธิภาพดีกว่าอาจนำมาซึ่งลูกค้าและชื่อเสียงมากขึ้น แต่ถ้าธุรกิจจริงคือการขาย ซอฟต์แวร์แบบ self-hosted การทุ่มทรัพยากรพัฒนาไปตรงนั้นก็สมเหตุสมผล
เคยซื้อไลเซนส์ GitLab จริง และพอรู้ว่าค่า seat เท่ากันไม่ว่าจะให้ GitLab โฮสต์ให้หรือเราโฮสต์เอง ก็อดคิดไม่ได้ว่าทำไมเราต้องเป็นฝ่ายรับภาระค่าโครงสร้างพื้นฐาน
ถ้าจะทำ GitLab.com แบบครึ่งๆ กลางๆ ก็สู้ทำให้ดีไปเลย หรือไม่ก็เลิกผลิตภัณฑ์นั้นแล้วไปโฟกัสที่ลูกค้า self-hosting อย่าง GitLab Enterprise Edition อย่างเดียว อาจดีกว่าในระยะยาว
แต่คงไม่มีใครในฝ่ายบริหารอยากตัดสินใจแบบนั้น
เลยกลายเป็นการทำผลิตภัณฑ์แบบ ครึ่งๆ กลางๆ
สำหรับคนที่ใส่ใจกับตัวผลิตภัณฑ์เอง สถานการณ์แบบนี้อาจน่าอึดอัด
ทุกครั้งที่มีนักพัฒนาใหม่เข้ามา ก็จะพูดว่า “เราต้องใส่ใจเรื่อง scalability ให้มากกว่านี้” แล้วพวกรุ่นพี่ก็จะตอบว่า “ใช่ๆ รู้แล้ว…”
หากในเชิงเศรษฐศาสตร์นักพัฒนาใน Amsterdam สามารถสร้างคุณค่าได้เท่ากับนักพัฒนาใน Bay Area ก็น่าจะสมเหตุสมผลที่จะจ่ายเงินเดือนเท่ากัน
แม้อัตราค่าจ้างตามตลาดท้องถิ่นของนักพัฒนา Amsterdam จะต่ำกว่า แต่คุณกำลังสร้างบริษัทระดับโลกและแข่งขันกับบริษัทระดับโลกอื่น ๆ
ตอนนี้คุณอาจจ้างนักพัฒนา Amsterdam ได้ในราคาที่ลดแล้ว แต่สุดท้ายคู่แข่งก็จะเสนอค่าตอบแทนที่ใกล้เคียงกับคุณค่ามากกว่า หรือไม่พวกเขาก็จะออกไปทำงานของตัวเอง
บริษัทที่แข็งแกร่งที่สุดน่าจะลงเอยด้วยการจ่าย ค่าตอบแทนที่ไม่ขึ้นกับสถานที่ ให้กับคนเก่ง
ท้ายที่สุด สิ่งสำคัญคือคุณค่าที่ส่งมอบ
หากคุณมี codebase Ruby ขนาดใหญ่แบบ GitLab และอยากขายให้กับองค์กรขนาดใหญ่ที่ให้ความสำคัญกับประสิทธิภาพและความเสถียร ก็น่าจะต้องจ่ายให้คนแบบนี้มากกว่าปีละ €120k
วิศวกรส่วนใหญ่ที่ให้ความสำคัญกับประสิทธิภาพ type safety และความเสถียรมักไม่สนใจ Ruby ดังนั้นราคาตลาดของชุดทักษะแบบนั้นย่อมสูงกว่าอย่างชัดเจน
ไม่แน่ใจว่าจะถึงระดับปีละ $500k แบบ Bay Area หรือไม่ แต่บริษัทที่แข็งแกร่งซึ่งต้องการคนระดับท็อปจะสูญเสียคนเก่งไป หากไม่ผูกค่าตอบแทนเข้ากับคุณค่าที่ส่งมอบแทนที่จะผูกกับสถานที่
ผมมองว่าเวลาที่ใช้ในการ deploy โค้ดเป็นหนึ่งในตัวชี้วัดที่สำคัญที่สุด หรืออาจสำคัญที่สุด สำหรับการรักษาความเร็วของนักพัฒนาเมื่อสตาร์ทอัพขยายตัว
การสลับบริบท เป็นหนึ่งในงานที่มีต้นทุนสูงที่สุดในชีวิตประจำวันของนักพัฒนา แต่กลับถูกมองข้ามได้ง่ายที่สุดอย่างหนึ่ง
ผู้จัดการมักชอบจัดตารางทีมให้เข้ากับตารางของตัวเอง แต่สิ่งนี้มักรบกวน “maker schedule” ของผู้มีส่วนร่วมรายบุคคล
หลายองค์กรเริ่มตระหนักเรื่องนี้และให้ความสำคัญกับต้นทุนของการสลับบริบทในแง่ของตารางเวลา แต่สำหรับนักพัฒนา เวลาตั้งแต่ build จนถึง deploy ก็สำคัญพอ ๆ กัน หรืออาจสำคัญยิ่งกว่า