โพสนี้อาจจะมีศัพท์โปรแกรมเมอร์หลุดมาเยอะนิดนึงนะ
เพราะคิดว่าเหมาะสมกับการอธิบายประสบการณ์การทำงานสำหรับโพสนี้ได้ดีที่สุด
หมายเหตุ
ตรงไหนที่เราเขียนค่อนข้างคลุมเครือๆ แปลว่าเราลงรายละเอียดไม่ได้นะๆ
และสิ่งที่เราเขียนทุกอย่างนี้เป็นความเห็นส่วนตัวทั้งหมด 100%
ความเห็นของ Google สามารถหาได้ที่ offical blog ของบริษัท
โปรเจค
จากที่เกริ่นไว้ตอนที่เล่าเรื่องสัมภาษณ์
(อ่านประสบการณ์ตอนสัมภาษณ์ได้ที่นี่)
เราได้คุยกับ tech lead ของทีมที่เราจะเข้าไปทำงานด้วย
ก็พอได้รู้เรื่องคร่าวๆว่าจะทำโปรเจคอะไร
สรุปว่าเราได้ไปพัฒนาระบบ continuous integration (ตัวย่อว่า CI) ของ Google
หรือก็คือไอ้ระบบที่มันคอย compile กับ test ทุกอย่างที่เรา commit โดยอัตโนมัติ
ระบบ CI ทั่วไปมันก็มีแบบ open source ที่โหลดมาใช้ได้ง่ายๆเช่น jenkins
แต่ Google กลับพัฒนาระบบ CI ของตัวเอง
แล้วทำไม Google ถึงต้องอินดี้ด้วยวะ
สาเหตุที่ต้องอินดี้เพราะว่าของที่มีให้โหลด ไม่ตอบสนองความต้องการของ Google
ความต้องการนั้นก็คือ ขนาดของ repository มันใหญ่มาก และมีคน commit code ทุก 5 วินาที
ระบบทั่วไปทำงานไม่ทัน
โปรเจคหน้าร้อนของเราคือทำให้ระบบนี้ทำงานได้เร็วขึ้น
โดย tech lead มีไอเดียคร่าวๆมาให้แล้ว
สิ่งที่เราต้องทำคือ ทดสอบ แต่งเติม ตัดทิ้ง พัฒนา และลงมือทำไอเดียให้เป็นจริงถ้าเหมาะสม
orientation
สำหรับคืนก่อนวันทำงานวันแรก ก็ดูแผนที่ล่วงหน้า
โอ้ยชิวครับ บ้านห่างออฟฟิสไปแค่ 25 กม.
ขับรถ 100-120 กม./ชม. แค่ 15 นาทีก็ถึง
"ซะที่ไหนเล่า เจ้าเซ่อ" เราพูดกับตัวเองขณะขับรถวันถัดมา
เมื่อได้เจอพลังรถติดแห่ง silicon valley เข้าไป
ไปเลทแต่วันแรกเลยกรู
สัปดาห์แรกเข้าไปเจอ orientation ทั้งสัปดาห์
ยังไม่มีอะไรตื่นเต้นเท่าไร
ตัว orientation มันก็แบบประมาณว่า
อยากให้รู้ว่าบริษัทคิดยังไง ทำงานกับเพื่อนร่วมทีมยังไง อะไรสำคัญบ้าง ใช้ tool อะไร
ซึ่งก็มาตรฐาน orientation ของบริษัททั่วๆไป
เจอทีม
หนึ่งสัปดาห์ผ่านไปเราถึงได้มีโอกาสเจอทีมตัวเป็นๆซักที
ตัว tech lead ที่เราคุยด้วยทางโทรศัพท์ก็จะเป็นคนหลักๆที่จะคอยทำงานกับเรา ชื่อ เอริค
เอริคก็แนะนำเราให้ทีมรู้จักเป็นที่เรียบร้อย
เป็นทีมที่ค่อนข้างหลากหลายทางเชื้อชาติและอายุ แต่ที่เห็นชัดๆคือทุกคนดูอัธยาศัยดีและเป็นมิตร
ที่สำคัญคือเราได้ไปเจอเด็กฝึกงานอีกคนนึงที่ทำงานอยู่ทีมเดียวกัน ชื่อ แพททริก
มันมาทำก่อนหน้าเราสามสัปดาห์แล้ว เหมาะสมที่จะเข้าไปดูดความรู้
วอร์มอัพ
สัปดาห์แรกๆของการทำงานก็จะเป็นการ set up เครื่องคอม
เรียนรู้ว่าระบบต่างๆของ Google มันทำอะไรบ้าง
เวลาจะ commit code มีขั้นตอนยังไง ฯลฯ
ช่วงนี้เราใช้ประโยชน์จากแพททริกอย่างเต็มที่
มีอะไรก็ถามมันตลอด ให้มันสอนนู่นสอนนี่
นอกจากนั้นเราก็ยังให้เอริคอธิบายคร่าวๆเกี่ยวกับระบบ CI ของ Google
ว่ามันทำงานยังไง แล้วโปรเจคเราทำอะไรกันแน่ เพราะจนป่านนี้รู้สึกว่าโปรเจคยังคลุมเครือ
หลังจากได้พูดคุยกับเอริค
เรากับเอริคก็เลยตัดสินใจสร้างโปรเจคย่อยออกมา เพื่อเป็นการวอร์มอัพ
ทำให้คุ้นเคยกับการเขียนโปรแกรมที่ Google และระบบต่างๆที่เราจะต้องใช้งาน
code review
เนื่องจากโปรเจคย่อย มีขนาดเล็ก เราก็เลยทำแบบชิวๆ ใช้เวลาประมาณ 5 วัน
ก่อนที่เราจะส่ง code ให้ เอริคทำ code review
ที่ Google เค้าจะมีที่เรียกว่า style guide ให้ตาม
หลักๆก็จะเป็นการตกลงกันทั้งบริษัทว่า code ภาษานี้ เราจะเขียนกันยังไง
จะใช้ space กี่ตัว จะตั้งชื่อตัวแปรยังไง จะใช้วงเล็บยังไง
หลักๆก็คือ อะไรที่เกี่ยวกับ format และไม่เกี่ยวกับความหมายของโปรแกรม
ดูตัวอย่าง style guide ของ java ได้ทีนี่
สาเหตุที่จะต้องมี style guide เป็นเพราะมีพนักงานเยอะมากๆ
ถ้าทุกคนใช้ format ต่างกัน จะทำให้อ่าน code ยากมาก
ในทางกลับกัน ถ้ามี style guide จะทำให้สายตาพนักงานชินกับการอ่าน code ที่ format เหมือนๆกัน
เนื่องจากเราเคยทำงานใน start up ซึ่ง founder ก็เป็นพนักงาน Google เก่า
เค้าก็ให้บริษัทใช้ style guide พวกนี้เหมือนกัน เราก็เลยชินกับตรงนี้
แต่หลังจาก code เราได้ format ตาม style guide
ทีนี้ก็เหลือส่วนการ review ความหมายของโปรแกรม
ว่าทำงานถูกต้องหรือไม่
อ่านง่ายแค่ไหน
ใช้ data structure หรือ algorithm เหมาะสมไหม
ใช้ library เหมาะสมหรือเปล่า ไม่ใช่เขียนอะไรที่มี library อยู่แล้ว
class member ที่ควรจะ private ได้ private ไว้หรือเปล่า
class นี้ทำหน้าที่เกินหนึ่งอย่างหรือเปล่า
ฯลฯ
อันนี้แหละได้ feedback มาให้แก้ เพียบ
ก็แก้ไปแก้มาหลายรอบ
บางอย่างเราคิดว่าที่เราเขียนไปตอนแรกดีแล้ว เราก็อธิบายว่าเราคิดยังไง แล้วไม่แก้
เอริคก็โอเค รู้สึกว่าให้ความเคารพในการตัดสินใจกันดี
อีกอย่างนึงที่อยากจะพูดถึงเกี่ยวกับ code review ที่ Google
คือ Google มันจะมีระบบ code review แบบที่ไม่ต้องมานัดประชุม
หรือเรียกคนมาดู code หน้าคอมหรือผ่านโปรเจคเตอร์พร้อมกัน
start up ที่เราเคยทำงาน ใช้ระบบที่ชื่อว่า gerrit
(github ก็มีอะไรคล้ายๆกัน หน้าตางี้)
หลักๆก็เป็นเหมือนว่าเรา commit code ไปแล้ว code มันก็ไปอยู่ใน "สถานบำบัด code" ก่อนที่มันจะเข้า repository หลัก
จากนั้นเราก็ส่งอีเมลให้คนอื่นบอกว่ามา review ให้หน่อยๆ
คนอื่นก็จะเปิด browser เข้าไปดู ซึ่งหน้าตามันจะคล้ายๆ tkdiff หรือ meld หรือโปรแกรม GUI อะไรก็ตามที่ใช้ diff code
แล้วคนอื่นอยากเม้นอยากกดไลค์กับ code บรรทัดไหน ก็เข้าไปเขียนได้เลย
ซึ่ง code ที่อยู่ในสถานบำบัด code จะไม่ถูกปล่อยเข้า repository หลักจนกว่าจะ approve
ส่วน Google ก็อินดี้ตามสไตล์ มีระบบของมันเองที่หน้าตาคล้ายๆกัน
สิ่งหนึ่งที่เราคิดว่าเจ๋งที่สุดก็คือ
เราสามารถดู code review ของใครก็ได้
ลองคิดดูดิ
นี่มันเป็นวิธีเรียนรู้ที่สุดยอดเลยนะ
อย่างแรกคือเราเข้าไปดู code review ที่เอริค review ให้แพททริกได้ เราจะได้ไม่ทำความผิดพลาดคล้ายๆกัน
อย่างที่สองคือเราเข้าไปดู code และ review ของพวกเทพทั้งหลายใน Google ได้
ว่าคนระดับ top ของ Google เวลาเค้า review code เค้าโหดแค่ไหน เค้าเม้นอะไรบ้าง เค้าชอบอะไรบ้าง ฯลฯ
สนุกมาก
เขียน code โปรเจคหลัก
หลังจากโปรเจคเรียกน้ำย่อยเสร็จไปแล้ว
เราก็เริ่มชินกับระบบต่างๆ รวมไปถึงสไตล์การ review ของเอริค
ทีนี้ก็ได้เวลาทำโปรเจคหลักแล้ว
โปรเจคหลักก็เลยกลายเป็นอะไรที่ตรงไปตรงมา
มีต้องติดต่อกับทีมอื่นเพื่อถามคำถามบ้างเล็กน้อย แต่ไม่ได้ลำบากอะไรเลย
สาเหตุเพราะว่า ที่ Google เราสังเกตว่าทุกคนเป็นมิตรมาก
เท่าที่เจอมาระหว่างการฝึกงาน ไม่มีใครที่ทำให้เรารู้สึกว่าเราด้อยกว่า ทั้งๆที่ทุกคนเก่งกว่า
(อันนี้ยอมรับว่า ที่ไทย เจอเยอะ คนเก่งๆก็จริง แต่ชอบพูดแล้วคนฟังรู้สึกด้อยกว่า)
นอกจากนั้นเราเริ่มชินกับทีมด้วย มีอะไรจังหวะนี้ เราก็ไม่อายที่จะเดินไปถามตลอดเวลาแล้ว
(ตอนที่เราเพิ่งได้เข้ามา บางทีเราไม่กล้าถามอะไรคนอื่นเท่าไร)
ก็เขียน code เสร็จ ผ่าน code review เรียบร้อย เพิ่งถึงประมาณครึ่งทางการฝึกงาน
เหมือนว่าโปรเจคใกล้จะเสร็จ
แต่ความสนุกเพิ่งเริ่มตะหาก
จ้องข้อมูล
จากที่เขียนด้านบน โปรเจคเราคือทำให้ระบบ CI ของ Google ทำงานได้เร็วขึ้น
หลังจากเราเขียน code เสร็จอะไรเรียบร้อย
เราก็ให้มัน run แล้วรอดูว่า มันทำให้ระบบเร็วขึ้นจริงหรือเปล่า เร็วขึ้นแค่ไหน
เนื่องจาก Google เป็นบริษัทที่เก็บข้อมูลเยอะมากกกกกกกกกกกกก
สิ่งที่เราต้องทำตอนนี้ก็คือการจ้องข้อมูล
จ้องว่า ข้อมูลอย่างนี้ แปลว่าที่เราทำไปได้ผลไหม ได้ผลแค่ไหน
จ้องว่า ข้อมูลอย่างนี้ แปลว่าที่เราทำไปถ้าไม่ได้ผล จะแก้ยังไง
จากประสบการณ์นี้ นอกจาก software engineer
เรารู้สึกว่าเราได้ทำงานเป็น data scientist ด้วย
มีข้อมูลจำนวนมหาศาล เราก็นั่งเขียน script ดึงข้อมูลที่ตัวเองสนใจออกมา
เพื่อจะได้เปิดใน excel แล้วมองเห็นเป็นสีๆง่ายๆ
อันนี้ใช้เวลาอาจจะนานกว่า code อีกเลยมั้ง ถ้าจำไม่ผิด
แล้วก็จ้องข้อมูลจนมึนเลย
แต่จากการใช้เวลาจ้องข้อมูล ทำให้เรารู้ว่า เราควรจะแก้ code อะไรของเราเพิ่ม
เพื่อให้ที่เราเขียนไปมันได้ผลดีขึ้น
เขียน code รอบสอง
ที่นี้เราก็กลับไปเขียน code ต่อ
เอาผลที่ได้จากการจ้องข้อมูล มาใส่ใน code
มาถึงตอนนี้เอริคบอกว่าให้ส่ง code ไปให้ tech lead อีกคนนึงบ้าง ชื่อ ซานจีฟ
ตอนจบการฝึกงานเค้าจะได้เขียน evaluation ให้เราด้วย
เราก็ส่ง code ไปให้ซานจีฟ review เป็นชุดใหญ่
แต่ช่วงนั้น ซานจีฟงานเข้าเยอะมาก รวมถึงมีวันลาพักพอดี
กว่าจะ review ได้ครบก็ถึงสองสัปดาห์สุดท้ายของการฝึกงานแล้ว
ส่วนนึงที่เรารู้สึกว่าเราทำพลาด คือ การไม่ทำให้แต่ละ commit มันเล็กพอ
ซานจีฟซึ่งไม่คุ้นกับ code เราต้องมานั่งเรียนรู้ commit ใหญ่ๆก็เลยใช้เวลามากกว่าปกติด้วย
ได้ผล
หลังจาก code ใหม่ที่ commit ไปมัน run มาซักพัก ก็ยังดูเฉยๆเนือยๆอยู่
ไม่ได้มีผลอะไรมาก เหมือนประมาณว่า ไอ้ที่เราทำอะ มันเฉยๆ ไม่ได้เจ๋งอะไร ไม่ได้ช่วยให้ระบบมันเร็วขึ้นเท่าไร
ในขณะที่เราได้ยิน ซานจีฟชมแพททริกว่า "เฮ้ย งานมึงสุดยอด"
เราก็อดคิดในใจไม่ได้ว่า
"ไอ่ แพททริก อย่าเก่งนักดิวะ ช่วยทำงานออกมาเฉยๆหน่อยดิ
กรูโดนเปรียบเทียบกับเมิง กูก็ซวยดิวะ"
แต่แล้วก็มีปาฎิหาริย์เหมือนในพระคัมภีร์อีกแล้ว
สัปดาห์นั้นมีคน commit code ซึ่งมีปัญหากระทบคนจำนวนมาก
แล้วไอ้โปรเจคที่เราทำไปมันเก่งด้านตรวจจับแบบนี้ได้พอดี
โปรเจคของเราอยู่ๆก็เลยเหมือนช่วย Google แบบเห็นได้ชัด
โอ้โห กรูดูดีขึ้นมาทันทีเลย จังหวะนี้กรูเก่งที่สุดในโลกทันที
ก็เลยกลายเป็นว่าไอ้ที่เรานั่งจ้องข้อมูลจนมึน
มันก็ส่งผล ทำให้โปรเจคเราดูดีขึ้นมา
พอได้ผลดี ทีนี้ เอริคก็บอก "อย่าลืมโชว์ให้ manager ดูนะจ๊ะ"
เราก็อีเมลให้ manager
manager ชอบ ก็ forward ไปบอก director "น้ำตาจะไหล ขอแชร์"
director ก็อีเมลมาชมเป็นการส่วนตัว
รู้สึกเท่เลยงานนี้ ถือว่ามาทำงานบรรลุเป้าหมายแล้ว
สรุป กูยอด :)
present
มาถึงสัปดาห์ใกล้ๆสุดท้าย สิ่งที่เค้าแนะนำให้เด็กฝึกงานทำ ก็คือให้ present งานที่ตัวเองทำ
ด้วยความที่เราเพิ่งไป present เปเปอร์มาช่วงต้นๆหน้าร้อน
ทำให้เราได้ฝึกทักษะการ present มาประมาณนึงแล้ว
ก็ไหลลื่น ไม่มีอะไรเครียด
มีการซ้อมกับตัวเอง ซ้อมกับเอริค ซ้อมกับ manager ก่อนถึงวันจริง
วันจริงก็มีคนโผล่มาเต็มห้อง รู้สึกดีเหมือนกันที่มีคนสนใจงานเด็กฝึกงานอย่างเรา
ก็ present ผ่านไปด้วยดี ไม่มีอะไรตื่นเต้น
คนถามคำถามมา ก็ถามเพราะอยากรู้จริงๆ
รวมไปถึง ทุกคนดูเป็นมิตรด้วย เลยไม่มีความเครียดอะไร
อันไหนเราตอบไม่ค่อยดี เอริคก็ช่วยตอบอีกตะหาก
วันต่อมาหลังจาก present ก็เป็นวันสุดท้ายของการฝึกงาน
ก็แทบไม่ได้ทำงานเลย เก็บกวาดโต๊ะ จดอีเมลคนใหม่ๆที่ได้รู้จักให้ครบ
แล้วก็จบการฝึกงานที่สนุกของหน้าร้อนนี้
สิ่งที่น่าสนใจและสิ่งที่เรียนรู้
อาวหละครับ ได้เวลามานั่งคิดว่าสิ่งที่น่าสนใจและสิ่งที่ได้เรียนรู้มีอะไรบ้าง
เผื่อเราจะได้เอาไปใช้ในชีวิตประจำวัน
ความขี้อาย
สำหรับพนักงานใหม่ ไม่ว่าที่ไหนก็ตาม
สิ่งที่จะทำให้เรียนรู้ได้เร็วมากๆก็คือ การถามคนอื่นในทีม
ถึงเราจะเก่งแค่ไหน หลายๆครั้งคนอื่นมักจะรู้ตัวระบบภายในได้ดีกว่าเรา
และการถามคนอื่นทำให้สนิทกับคนในทีมอีกตะหาก
ยิ่งขี้อายเท่าไร ก็จะยิ่งอายที่จะถามคนอื่นและงานจะออกมาได้ช้าลง
ถ้าเป็นไปได้ ควรจะต้องกล้าถามมากกว่านี้ โดยเฉพาะถ้าเราเห็นว่าคนอื่นเป็นมิตร เราต้องถามได้
สำหรับเจ้านายที่จ้าง พนักงานใหม่เข้ามา
มักจะบอกพนักงานใหม่ว่า "มีอะไรถามได้ตลอด"
แต่บอกขนาดนั้นบางทีมันก็ไม่พอสำหรับพนักงานใหม่ขี้อาย
ถ้าเจ้านายอยากให้พนักงานพวกนี้สามารถผลิตงานได้เร็วขึ้น
ตัวเจ้านายเองอาจจะเป็นฝ่ายเข้าไปถามถี่กว่าปกติ จนพนักงานใหม่เริ่มชินกับการถามเอง
ความเก่ง
พนักงานที่เที่ยวบินเยอะๆ มีความเก่งขึ้นเรื่อยๆ ต้องอย่าลืมที่จะทำตัวเป็นมิตรและมีความถ่อมตัว โดยเฉพาะกับพนักงานใหม่
พนักงานใหม่ๆเหล่านี้มีโอกาสจะเติบโตไปเป็นพนักงานดีๆได้
ถ้าไปทำตัวให้เค้ารู้สึกแย่ ไม่ว่าจะเป็นการ "หวง code" หรือการพูดให้อีกฝ่ายรู้สึกด้อยกว่า
อาจจะทำให้พนักงานพวกนี้ไม่อยากทำงานด้วย
เขียน code ให้อ่านง่ายไว้ก่อน
เอริคบอกเราว่า code เราจะถูกอ่านมากกว่า code เราถูกเขียน
แปลว่าอะไร
แปลว่า ถ้าเราเขียน code ที่อ่านง่าย ใช้เวลาทำความเข้าใจน้อยลง 5 นาทีจาก code ที่อ่านยาก
ถ้า code นั้นมีคน 2 คนอ่านเดือนละครั้ง แล้วจะอยู่ในระบบไปอีก 5 ปี
เราสามารถประหยัดเวลารวมไปได้ 10 ชั่วโมง
ถ้าเราเขียน code ด้วยความคิดนี้ทั้งระบบ ซึ่งมีคนอ่าน code ตลอดเวลา จะประหยัดเวลาได้มหาศาล
commit เล็กๆ
ส่วนตัวคิดว่าอันนี้ทำยาก ทั้งๆที่เป็นความคิดง่ายๆ
เหมือนกับการที่หนึ่ง class ควรมีหนึ่งหน้าที่
หนึ่ง commit ก็ควรมีเป้าหมายเดียว
ถ้าจะแก้ค่า constant ก็แก้ในหนึ่ง commit
ถ้าจะ refactor บางอย่างก็ให้แก้ในหนึ่ง commit
การจะเปลี่ยน logic ก็ให้เปลี่ยนในหนึ่ง commit
หลายๆครั้งเรามักจะรวมการ refactor กับการเปลี่ยน logic เข้าไปด้วยกัน
เพราะรู้สึกว่าที่เรา refactor มันก็เพื่อจะได้ใส่ logic ใหม่เข้าไปง่ายๆ
แต่ผลลัพธ์คือ มันทำให้ review code ยากขึ้น แทนที่จะ review logic อย่างเดียว
ต้องมาทำความเคยชินกับ code ที่ refactor ด้วย
การแยก commit ให้เล็กๆ จะทำให้แต่ละ commit เข้าใจง่ายและ review ได้ง่าย
ทำให้ความผิดพลาดน้อยลง และอาการ "เอ๊ะ review อันนี้ใหญ่ ไว้ทำทีหลังดีกว่า" น้อยลง
เรียนรู้จากคนอื่น
สิ่งหนึ่งที่เราชอบที่สุดที่ Google คือเราสามารถเห็น code review ทุกคนได้
วิธีการเรียนแบบนี้สามารถเอาไปประยุกต์ได้นอกจากการเขียน code
เช่น ในมุมมองของเจ้านาย
ถ้าบริษัทเรามี culture ที่สามารถติชมผลงานกันได้ด้วยความเคารพ จริงใจ และเป็นมิตร
เราสามารถที่จะแบ่ง feedback ที่เรามีต่องานของคนนึง ให้คนอื่นเรียนรู้ได้
ในมุมมองพนักงาน
แบบนี้เราจะลดการเสียเวลา แก้ปัญหาความขี้อาย แก้ปัญหากลัวถามโง่ได้
เพราะแทนที่เราจะต้องเข้าไปถามพนักงานคนอื่นว่า "เฮ้ย ทำอันนี้ ทำยังไง มีข้อแนะนำหรือเปล่า"
เราก็เข้าไปดูตัวอย่างและ feedback ของงานเก่าๆของพนักงานคนนั้นได้
อไจล์
สมัยนี้ คนเค้านิยมอไจล์กัน เลยเอามาเขียนนิดนึง
ดูเหมือนว่า อย่างน้อยทีมที่เราทำงานด้วย เค้ามีความอไจล์สูง
เราไปอ่านเจอมาว่า Google โดยรวมก็มีความอไจล์สูงเหมือนกัน
ไม่ใช่สูงเพราะใช้ scrum หรือ kanban หรือ ฯลฯ เก่ง
แต่สูงเพราะว่า ในทีมเค้ามีไอเดียประมาณว่า "ทำอะไรก็ได้ทีมทำงานได้ลื่นที่สุด"
ไม่ว่าจะเป็นการ pair programming เฉพาะเวลาที่คุยกันต่อหน้าเร็วกว่าอ่าน code review
หรือการ refactor รัวๆ เพราะจะได้ประหยัดเวลาคนในอนาคต
หรือการ standup ที่เน้นว่าติดอะไรอยู่ เผื่อคนในทีมจะช่วยแก้ได้
เหมือนเค้าเลือกเฉพาะอะไรที่น่าจะมีประโยชน์กับการทำงานมากกว่าที่จะทำตามตำรา
Google ต่างจากบริษัทอื่นยังไง
อาหารฟรี? บริษัทอื่นๆเดี๋ยวนี้มีเยอะแยะแล้ว
จำนวนและขนาดข้อมูล? เราคิดว่า twitter ก็อาจจะไม่แพ้กัน
พนักงานเก่งๆ? บริษัทอื่นๆแถว silicon valley มีหมดแหละ
เงินเดือนสูง? บริษัทที่เงินเดือนสูงกว่า Google มีอยู่
สิ่งที่เราคิดว่า Google ต่างจากบริษัทก็คือ
(1) จำนวนทีมและโปรเจค
Google ในจังหวะนี้มีขนาดใหญ่มาก
เรียกได้ว่าถ้าได้เข้ามาแล้ว แล้วอยากย้ายไปหาอะไรที่ชอบมันก็น่าจะมีแหละ
เช่นโปรเจคประมาณแบบเขียน compiler หรือ ออกแบบ programming language ใหม่
ซึ่งบริษัททั่วๆไปไม่มาเสียเวลาทำกัน
(2) ระบบ infrastructure ที่มีอยู่
Google อยู่มาซักพักแล้ว เกิดก่อนบริษัทดังๆบริษัทอื่นที่มี infrastructure ดีๆ เช่น facebook หรือ twitter
ทำให้ได้เปรียบว่าได้เริ่มก่อน
มันก็จะมีระบบอะไรๆที่เข้าที่เข้าทางพร้อมให้ใช้งาน เช่น big table, map reduce ฯลฯ
ไม่ต้องมานั่งเขียนใหม่
ซึ่งตรงนี้จะทำให้พนักงานสามารถโฟกัสกับงานตัวเองได้มากกว่างาน infrastructure
ในตอนที่เราทำงานอยู่ start up เราต้องเขียน database ขึ้นมาเอง
เพราะว่า ไม่มี open source หรือ service ที่ตอบสนองความต้องการของบริษัท
มันก็สนุกไปอีกแบบเพราะได้จับทุกอย่าง
แต่ว่าแทนที่จะได้เขียนส่วนที่ทำเงินให้บริษัทโดยตรง ก็ต้องมาเขียน infrastructure ก่อน
(3) โปรเจค "บ้าไปแล้ว"
เนื่องจาก Google เหมือนจะมีเงินเหลือ
มันเลยสามารถส่งเสริมให้พนักงานทำโปรเจคประเภท บ้าไปแล้ว โดยไม่เจ๊งได้
อย่างเช่น google glass หรือรถไร้คนขับได้
ซึ่งเรารู้สึกว่ายังไม่มีบริษัทไหนที่มีโปรเจคบ้าไปแล้วเยอะแบบ Google
บริษัทอื่นมีอะไรที่ Google ไม่มี
เรารู้จักคนที่ลาออกจาก Google และพนักงานปัจจุบันที่คิดจะลาออกด้วย
สาเหตุใหญ่ๆที่คนเหล่านี้มองหาประสบการณ์อื่นๆ ฟังดูเหมือนจะเป็นเหตุผลต่อไปนี้
เนื่องจาก Google มันใหญ่ขึ้นเรื่อยๆ การจะทำอะไรที่รู้สึกว่าส่งผลให้บริษัท หรือการจะทำอะไรเร็วๆง่ายๆ มันยากขึ้น
พนักงานแต่ละคนก็เป็นเพียงฟันเฟืองเล็กๆในเครื่องจักรใหญ่ ซึ่งถ้าฟันเฟืองนั้นหลุดไป Google ก็หามาแทนได้
การออกไปทำบริษัทที่เล็กกว่า หรือ start up มันรู้สึกว่าตัวเองได้ทำอะไรที่มีผลกระทบกับโลกโดยตรงมากขึ้น
บน quora มีคนถามคำถามนี้ด้วย ลองไปอ่านเพิ่มก็มันส์ดี
เรายังไม่ได้ทำงานนานพอที่จะเจอเรื่องพวกนี้ที่ทุกคนเล่า
แต่เราก็เรียนรู้มาว่ามันไม่มีที่ไหนที่ดี 100% หรอก
ตราบใดที่เรารับอะไรที่แย่ๆได้ และชอบในส่วนที่ดี เท่านั้นก็โอเคแล้ว
ฉันใดก็ฉันนั้น การจะหาเจ้าชายในฝันมันไม่มี
ตราบใดที่เรารับข้อเสียของอีกฝ่าย และรักในข้อดีของอีกฝ่ายได้ รู้จักปรับตัว
เราก็จะมีความสุข
(เข้าเรื่องนี้ได้งัยวะ)
จบแล้ว
โดยรวมเรารู้สึกว่า ประสบการณ์ส่วนตัวของเราที่ Google มันโอเคเลย
หวังว่าที่เราเอามาแบ่งปัน จะเอาไปประยุกต์ใช้กันได้นะ
บ๊ายบาย
