Videos → Shipping open source software in a fully remote company

แนะนำตัวและบริษัท Metabase0:00

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

เดี๋ยวแนะนำตัวเร็วๆ ก่อนดีกว่า สวัสดีครับ ผมชื่อ Kelvin นะครับ ก็คือทำงานเป็น front end engineer อยู่ที่ Metabase ตอนนี้ ก็คือ Metabase เนี่ย เรียกว่าเป็นโปรดักต์ตัวหนึ่งละกัน ที่เป็น open source อยู่ใน GitHub นะครับ มีดาวเยอะมาก จำได้เหมือนกับ GitHub star 20,000 กว่าดาวมั้ง แต่ก็คือเป็น tool ที่เอาไว้ เล่นกับ data ก็คือคุณมี data คุณอยากเข้าใจ ว่า data ของคุณมันเป็นยังไง อยากเข้าไปเล่น เข้าไป visualize หรือว่า

สงสัยอะไรเกี่ยวกับ data ของตัวเอง ก็คือใช้ Metabase นะครับ แล้วเนื่องๆ ด้วยที่มันเป็น open source

คนส่วนใหญ่คือเป็น remote หมดเลย ก็คือไม่มีออฟฟิศเนอะ แล้วก็จ้างคนทั่วโลก ก็เลยรู้สึกว่ามันน่าจะเป็นแบบ topic ที่ หลายๆ คนน่าจะไม่เคยรับรู้มาก่อน ก็เลยอยากจะมาแชร์ให้ฟัง ว่าการทำงานภายในบริษัท ที่เขาทำเป็น open source เนี่ยเขาเป็นยังไง ตอนแรกที่ผมเข้ามาผมก็ว้าวมากนะเพราะว่า core product มันเป็น open source ใช่ไหม ปกติเราไม่เคยคิดว่าแบบ open source แล้วมันจะแบบ commercialize ยังไง มันจะขายยังไง open source แต่ก็สุดท้ายมันก็ขายได้ หลักๆ ก็คือ topic วันนี้จะพูดประมาณนี้นะครับ การทำงานข้างในเป็นยังไงของบริษัทนี้ การคุยกันอะไรเป็นยังไงนะครับ ทุกคน remote หมดเลย culture เป็นยังไง สั้นๆ แค่นี้ อยากจะมาคุยเป็นเบาๆ แล้วก็อยากจะเน้น Q&A มากกว่านะครับ

เชิญชวนเข้าร่วม English Club for Developer1:53

ก่อนอื่นนะครับ ก็อยากจะขอ plug หน่อย จริงๆ plug ก็คือถ้าใครไม่ชิน ก็คือ advertise นั่นแหละ ก็คืออันนี้ต้อง props to น้องจุ้น เห็นเขาเป็นคนริเริ่มอันนี้ขึ้นมา เป็น English Club for Developer ช่วงนี้ห้องก็ใน Discord เขาค่อนข้างร้างๆ นิดนึง อยากจะชวนคนเข้ามา เข้ามาคุยหน่อยนะครับ จริงๆ ผมก็ลืมนะ ผมลืมเข้าไปบ้าง

ตอนแรกน้องจุ้นเขาขยันมากเข้ามาช่วยโฮสต์อีเวนต์ แต่จริงๆ ผมอยากเห็นเป็น ให้เป็นพื้นที่ที่ทุกคนเข้ามา แล้วเข้ามาคุยกันเอง ห้องมีอยู่แล้ว เข้ามาก็ไปจอย join voice channel แล้วก็ไปหาคนคุยได้ คืออันนี้ จุดประสงค์คือเราอยาก encourage ให้ developers จริงๆ ก็ไม่ใช่แค่ developers นะ เป็นใครก็ได้ในประเทศไทยเนี่ย เข้าไปอยากจะฝึก practice English ก็เข้าไปได้ จริงๆ ตอนแรกทอล์กนี้ผมก็เตรียมมาเป็นอังกฤษ นั่นแหละ แต่ก็พูดไทยก็ได้ครับ ง่ายดีนะฮะ อ่ะ มีใครอยากจะสแกนจอย Discord แล้วยังไม่ได้เข้าอีกไหม

โอเค ไปต่อแล้วนะ ก็ถ้าเกิดใครจอยเข้าไปแล้ว ว่างๆ เข้ามาคุยกันได้ ผมอยากเห็นทุกคนเข้ามาฝึกพูดกันนะครับ เราจะได้ international นะครับ international การทำงานใน Metabase เป็นยังไงครับ

สถิติและข้อมูลเกี่ยวกับ Metabase3:10

อันนี้เดี๋ยวพูดถึง statistics ของ Metabase ก่อน ทุกคนจะได้พอเห็นภาพว่าบริษัท Metabase เป็นยังไงนะ บริษัทที่ผมทำงานอยู่ ก็คือตอนนี้มีพนักงานอยู่ 52 คนนะครับ ทำงานอยู่ 16 time zone จริงๆ ไม่ใช่ 16 time zone หรอก 16 ประเทศ มันอาจจะมี time zone เหมือนกันบ้าง แต่ก็คือ เห็นภาพว่าแต่ละคนอยู่ทั่วโลกเลย เพราะฉะนั้นส่วนใหญ่เวลาเราทำงาน เราก็จะมักทำงานไม่ค่อยพร้อมกันนะครับ แล้วก็ engineers ตอนนี้มีประมาณ 30 คน ที่เหลือก็เป็นฟังก์ชันอื่นๆ ก็ตามรูปที่เห็นนะครับ รูปนี้ก็ visualize ผ่าน Metabase นะครับ ขายของอีกและ ขอถามอีกอย่างหนึ่ง มีใครใช้ Metabase ไหมครับ มีบ้างนะ ผมดีใจมากเลยนะ ตอนแรกที่ผมเข้ามาทำงานนี่คือคนอื่นรู้จัก Metabase เพราะผมเนี่ยครับ ผมยังไม่รู้เลยบริษัททำอะไร ผมแค่รู้ ผมเข้าไปแบบ โอ้ย UI สวย อยากทำงานที่นี่นะ

ต่อไปอันนี้ อันนี้เป็น PR นะครับที่ merge อันนี้มัน group by อะไรอะ มันเล็กมากเลยรายเดือนนะ ก็คือแต่ละเดือนเนี่ยมีประมาณสัก 300-500 ก็คือเฉลี่ยประมาณ 10-20 PR ที่มัน merge ต่อวันนะครับ อันนี้ก็คือเป็นตัว core product ก็คืออยากให้ เห็นภาพว่าประมาณนี้ คือสำหรับผมเนี่ย รู้สึกมันเยอะนะ เพราะผมทำบริษัทที่มันเล็กกว่าก่อน บางทีวันหนึ่งอาจจะไม่มี merge เลย หรืออาจจะแบบสองสามวัน merge ทีอะไรอย่างนี้ แต่สำหรับใครที่ทำบริษัทใหญ่ๆ corporate มี 100-200 คน เลขอาจจะดูน้อย แต่สำหรับผมคือรู้สึกมันเยอะ ก็เลยอยากจะสื่อว่าเนี่ย วันหนึ่งมี merge ตั้ง 10-20 PR ก็ทำงานกันยังไง

เลยอะไรเปล่าวะ ไม่เลยเนอะ อ่ะ มีอะไรอีก

ประวัติและการพัฒนาของ Metabase4:44

ก็คือ Metabase มันมีมาตั้งแต่ประมาณต้นปี 2015 นะครับ

จะเห็นได้ว่าจริงๆ คือมันเป็นโปรเจคที่มันแบบ establish แล้วอะ เรียกว่าเป็น legacy ได้เลย เพราะว่ามีมาตั้งแต่เท่าไหร่นะ 2015 ประมาณ 7 ปีนะครับ เกือบ 7 ปี ผมว่าผมจำไม่ถูกอะ ประมาณนั้นแหละ ประมาณ 7-8 ปี

ที่ว้าวมากครับ คือตอนแรกมันเขียนด้วย Angular 1 แล้วก็ประมาณเกือบ 2 ปีให้หลัง เขาก็ convert เป็น React ผมไม่ได้เข้าไปสืบทราบว่าสาเหตุว่า ทำไมเขาถึงเปลี่ยนนะครับ มันก็คงมีเหตุผลอะไรของมัน เพราะฉะนั้นก็ยินดีกับทุกคนนะครับที่เลือก React นะครับ / ยินดีด้วย จะได้ไม่ต้อง migrate ครับ ขอโทษน้องเจมส์นะครับ ไม่ได้ว่าอะไรครับ ก็ตอนแรกเรา use Flow Type ไม่แน่ใจ ของ Facebook หรือเปล่า ก็จำไม่ได้เหมือนกัน แต่ว่า ถามคนในทีมแล้วเขาบอกว่า ใช้ไปเรื่อยๆ แล้วพอไฟล์เยอะๆ ปุ๊บ มันแบบ มัน crash อะ มัน check type ไม่ได้ สุดท้าย ก็เลยลบ Flow Type ออกหมดเลย แล้วก็ใช้ TypeScript แทน แต่ว่าค่อยๆ convert นะครับ gradually convert ไปเป็น TypeScript ไม่ใช่ว่าแบบ โอ้ Flow Type ออกทุกอย่าง JavaScript เป็น TypeScript ตายครับ เราก็ค่อยๆ convert ไปทีละ file

คอมเมนต์อะไรพวกนี้ TODO, hack, fix me อะไรพวกนี้ คอมเมนต์ที่เก่ากว่า 5 ปีก็ยังอยู่ในโปรเจกต์ นะครับ เพราะฉะนั้นใครที่แบบว่าอยากจะเขียนอะไร ลงไปในโปรเจคเนี่ยว่าแบบ เฮ้ย อย่าลืม refactor ตรงนี้ด้วยนะ พยายาม keep in mind นะครับ มันอาจจะอยู่ไปประมาณ 5 ปีก็ได้นะครับ comment ของคุณ ก็อะไรที่เขียนลงไป มันจะอยู่ไปตลอดไปนะครับตอนนี้ อันนี้ก็เป็นตัวอย่างที่ผมชอบที่สุดนะครับ คอมเมนต์นี้ก็ประมาณ 5 ปีแล้วเหมือนกัน มันเป็นฟังก์ชันที่เอาไว้ clone object อะฮะ สุดท้ายมันก็ยังเวิร์คของมันอยู่นะ ผมชอบมากเลย

การทำงานแบบ remote และการ ship งานอย่างต่อเนื่อง6:41

โอเค ก็คือ

เวลาเราทำตัว open source project เนี่ย เป็นบริษัท ตัว core product เป็น open source นะครับ เราก็ต้อง ship อยู่ตลอดเวลา เราจะมาแบบว่า จริงๆ ก็ทุกบริษัทนะ incrementally shipping แต่ว่าด้วยความที่มันเป็นเรียกว่าไง บริษัทที่มัน remote มันก็ต้องยิ่ง continuously shipping มากกว่าเดิม เพราะว่าเราไม่ได้มีเวลาอยู่ด้วยกัน อะไรอย่างนี้ครับ เพราะฉะนั้นทำยังไงให้เราสามารถ ship ของได้ บ่อยๆ เรื่อยๆ เยอะๆ อันดับแรกก็คือเราต้องพยายาม ไม่ introduce complexity เข้าไป จริงๆ ผมพยายามคิดคำไทยเยอะมาก ตอนแรกคือเตรียม talk เป็นภาษาอังกฤษเลย พยายามจะพูดเป็นไทยให้ได้เยอะที่สุดนะครับ ผมถ้านึกอะไรไม่ออก

pardon ผมไว้หน่อยแล้วกันนะครับ ผมนึกคำไทยไม่ออกบางคำนะ ก็คือพยายามอย่าใส่ความวุ่นวายเข้าไปในโปรเจค อย่างเยอะๆ พยายามแบบ favor อะไรที่มันซิมเปิลๆ คือไม่ต้องคิดว่า product ที่มันแบบดูว้าว ดูหรูหราอะไรอย่างนี้ต้องใช้อะไรที่มันยุ่งยาก อะไรเสมอไปนะ พยายามใช้เรื่องที่มันง่ายๆ ไว้ก่อนนะครับ เพราะว่าการทำงานกับหลายๆ คนไง ถ้าเกิดหลายๆ คนพยายามใส่อะไรที่มันแบบดู ดูหล่อ ดู geek ดูแบบอะไรอย่างเนี่ยเข้ามา มันจะทำให้สุดท้ายมันจะวุ่นวายแล้วมันจะ มันจะแก้ไขยากครับ การแก้ไขยาก การ maintain ยาก การ extend ยาก มันทำให้ product ล่มสลายได้ ควรระวังเอาไว้ แล้วก็การที่เราจะ ship ได้เรื่อยๆ เราก็ต้องมีเทส

ความสำคัญของการทดสอบในการพัฒนาซอฟต์แวร์8:16

มีเทสเพื่อที่เราจะได้มั่นใจว่าสิ่งที่เรา ship สิ่งที่เราโค้ดลงไป มันไม่ทำให้ของเดิมมันพัง มันไม่ทำให้เกิด regression อะไรอย่างนี้ ก็จะพูดคร่าวๆ ว่าแบบเนี่ยคือ Metabase มีเทสเป็นพันแหละ มีเยอะมาก front-end unit test คือมีแบบหลายพันอะ 4-5 พันเทส back-end เองก็คงมีเป็นพันมั้ง cypress test ก็มีเป็นพันเหมือนกัน แล้วก็ยังมีใช้ Percy test ด้วย Percy ก็คือเป็นเหมือนแบบ screenshot เขาเรียกว่าอะไรวะ visual testing อะ visual testing คือเหมือนแบบเช็คว่า UI เปลี่ยนหน้าตาเปลี่ยนอะไรประมาณนี้ เหมือนแบบเช็คพิกเซลเพอร์พิกเซลประมาณนั้น คล้ายๆ Selenium อะไรอย่างนี้เปล่าฮะ / เอ่อ Selenium มันเป็น Selenium เรียกว่ามันเทียบเหมือนก็คือ Cypress ปกติดีกว่าซึ่งเป็น E2E test แต่ว่า Selenium มันไม่ได้แบบ ผมไม่แน่ใจนะว่ามันทำ visual testing ได้ไหม แต่คือมันเหมือนแบบ มันเป็น เรียกว่าไงดีอะ มันเป็น scaffold สำหรับการทำเทสอื่นๆ ต่อไปได้

แล้วก็จริงๆ คือแต่ละ PR ที่เปิดไปในแต่ละ change มัน run นานมาก เทสส่วนใหญ่ run 20 กว่านาที อันนี้ก็พูดเป็นคำขำนะ ว่าให้เห็นภาพว่ามันเยอะจริงๆ

การทำงานร่วมกันในทีมที่อยู่ต่างสถานที่9:25

เวลามี PR แบบเปิดก็นั่นแหละ วันหนึ่ง merge 10-20 มันก็ต้องมีเปิดมาเยอะเหมือนกัน เวลาหลักการในการที่เรารีวิว PR คือเราพยายาม favor ไปทางที่ไม่ให้มัน block เค้า คือเราพยายามจะแบบ approve มากกว่า look good to me อะไรแบบนี้มา ประมาณเนี่ย ถ้าเกิดว่ามันไม่มีอะไรที่มันแบบ แย่มากๆ ที่มันควรจะแก้ไขแบบทำให้แบบ โปรดักต์พังอะไรอย่างเงี้ย เราก็จะคอมเมนต์ไป แค่แบบว่า โอเคคือคุณต้องไปแก้อย่างงี้ๆ ก็ เออ ดูโอเคแล้ว approve อะไรอย่างนี้ประมาณนี้ครับ

อันนี้ปัญหาใหญ่ อีกปัญหาใหญ่หนึ่งของบริษัทนี้ คือทุกคนอยู่ทั่วโลกใช่ไหม เพราะฉะนั้น บางทีผมตื่น ผมทำงานเนี่ย ทำงานเสร็จปุ๊บ เพื่อนเพิ่งตื่นมาทำงานอะไรอย่างนี้ เพราะฉะนั้นมันก็จะเกิดปัญหา ก็คือปัญหา time zone ไม่พร้อมกัน เพราะฉะนั้นเราแก้ยังไง ก็คือบริษัทที่เป็น remote ส่วนใหญ่อย่างเนี่ย GitLab เอง หรือว่าอะไรก็ตาม ส่วนใหญ่ทุกคนน่าจะตาม GitLab กันหมดนะ เหมือนแบบเค้าเป็น pioneer มาก่อน ก็คือเราพยายามที่จะทำทุกอย่างให้มันเป็น asynchronous เพราะว่าแต่ละคนมันตื่นไม่พร้อมไง เราจะมาแบบว่า วันนี้แบบชิลมากประชุม 10 โมง อีกคนตี 3 อะไรอย่างนี้ มันก็ทำไม่ได้ถูกปะ เพราะฉะนั้นเราก็ต้องทำทุกอย่างให้มันเป็น asynchronous ส่วนใหญ่ by default ทุกอย่างจะถูกเขียนออกมาเป็นแบบ แล้วแต่อย่างบริษัทผมใช้ Notion ก็จะเขียนลงมาปึ๊บๆๆ

แล้วก็อย่างส่วนตัวผมเองคือที่เนี่ย เฉลี่ยๆ ประชุมน้อยมาก ก็คืออาทิตย์นึงประชุมไม่ถึง 2 ชั่วโมง

การสื่อสารแบบ asynchronous และการใช้ long-form writing10:55

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

ก็ไม่ได้โค้ดรัวๆ หรอก ก็มีตามอ่าน อะไรพวกนี้แหละ ไม่ได้โค้ดรัวๆ แต่ว่า ให้เห็นว่าเวลาที่ควรว่าเราต้องไป attend meeting อะไรอย่างนี้มันน้อยมาก แล้วก็ต้องเน้นทุกอย่างเป็น long form writing หมดเลยนะครับ ก็คือ เวลาอย่าง ทุกอย่างที่มันจะแทนที่ประชุมได้ เราก็จะเน้นเป็นแบบ เขียนออกมาเป็น พารากราฟ ยาวๆ คุณอยากจะทำอะไร what, where, when, why, how อะไรประมาณนี้ ทุกอย่างโปรเจกต์ แทนที่เราจะต้องมามี planning มีอะไรอย่างนี้ๆ ทุกคนเข้ามาคุยกัน discuss กัน เราก็เขียนเป็นอย่างนี้ เราก็เขียนเป็นเรียกว่า writing ออกมาอย่างหนึ่ง เหตุผลเพราะว่า อย่างที่บอกคือทุกคนทำงานไม่พร้อมกัน บางที stakeholder ของเราที่เกี่ยวกับ โปรเจคๆ หนึ่ง เขาอาจจะอยู่คนละ time zone ก็ได้ การที่เราเขียนออกมาเป็น writing ทำให้ทุกคนสามารถเข้ามา contribute ได้ ในเวลาที่ตัวเอง เหมาะสมอะ เพราะว่าแต่ละคนมันทำงาน ไม่พร้อมกันไงประมาณนี้เนอะ

เดี๋ยวจะพูดเรื่อง long form writing นี้ต่อไปนะครับ มีอีกพอยต์หนึ่งจะขยายเข้าไปหน่อย

การ over-communicate ดีกว่าการ under-communicate12:11

แล้วก็พยายาม over communicate เยอะๆ อันนี้เป็นอีกอันหนึ่งเลยที่ค่อนข้างสำคัญมากๆ คือถ้าเกิดว่าเวลาเราอยากจะคุยอะไร เราอยากจะสื่อสารอะไรกับใครสักอย่างเนี่ย อย่างเช่นเอาง่ายๆ เลย อย่างเช่นแบบคอมเมนต์ PR แบบ ตรงนี้ทำไมไม่ปุ๊บๆ อะไรอย่างนี้ ถ้าเกิดเราเขียนน้อยมาก แล้วสมมติเรานอนไปใช่ไหม อีกคนหนึ่งตื่นมา แล้วมาอ่านคอมเมนต์เราแล้วแบบ อิหยังวะ คำถามคือมันจะเกิดอะไรขึ้น มันจะเกิด turnaround time สูงมาก เพราะว่าเราอันนี้เรียกว่า เรา under communicate เพราะแทนที่จะแบบ มันจะแบบรอบเดียวแล้วมันจบ มันกลายเป็นแบบ อ่ะ ก็สงสัยก็ถามต่อ แล้วเราก็วันถัดมาก็ตื่นมา บอกไม่ใช่อย่างนี้ๆ เราก็นอน วันถัดมาก็ตื่นมาเราก็คุย เนี่ยเคยเป็นอย่างเนี่ย ผมเคยเป็นอย่างนี้เลยที่เนี่ย มันทำให้แบบบางทีสิ่งที่มันควรจะจบภายในวันเดียว มันกลายเป็นแบบ 2-3 วัน เพราะฉะนั้นเราไม่มีทางที่เราจะ over communicate ได้ คือ communicate ไปเยอะๆ เลย over มันไม่สร้างผลเสีย แต่ under เนี่ยคือสร้างผลเสียมากๆ เพราะฉะนั้นเวลามีอะไรอย่างนี้พยายาม over communicate ไว้ก่อนนะครับ

การสร้าง rapport หรือความสัมพันธ์ในทีมงานระยะไกล13:16

แล้วก็สร้าง rapport นะครับ อันนี้อ่านว่า rapport นะครับ ไม่ใช่ rapport นะครับ rapport ก็คือเราสร้างความสัมพันธ์ที่ดีกับ

เพื่อนร่วมงานนะครับ มันจะทำให้เราทำงาน ด้วยกันดีขึ้น เนื่องด้วยว่าบริษัทมันเป็น remote ถูกปะ แล้วแบบเราแทบไม่เจอใครเลยอะ คือเพื่อนผมก็แบบอยู่คนละประเทศหมดเลย อะไรอย่างเงี้ย การที่เราได้มี session บางอันที่แบบ

2-3 อาทิตย์ครั้งเราเข้ามาคุยกัน คือบริษัทก็มีใช้ tool บางอย่างที่ทำให้แบบ match พนักงานการเข้ามาคุยเพื่อให้ทำความรู้จักกันว่า แบบ เอ๊ย คนนี้เป็นยังไงเนี่ย มันทำให้เรารู้สึกแบบ connect กับ เพื่อนร่วมงานมากขึ้น ทำให้เราทำงานด้วยกันง่ายมากขึ้นครับ

การใช้ PodOS ในการทำงาน13:58

เรื่องต่อไปเป็นเรื่อง communication นะครับ ก็คืออันนี้เดี๋ยวจะพูดคร่าวๆ ว่าเราใช้สิ่งที่มา เรียกว่า PodOS ก็คือ คือบริษัทผมเนี่ยมันคิดขึ้นมาเองแหละ เออ มันคืออะไร ก็คือ PodOS เป็นวิธีการทำงานแบบหนึ่ง จะคิดว่ามันเป็นอีกแบบ alternative หนึ่งของ Scrum หรือว่า agile อะไรประมาณนี้ก็ได้นะครับ ก็คือ PodOS เนี่ย มา optimize throughput ก็คืออยากจะทำให้งาน ออกมาได้มากสุดนะครับ วิธีทำก็คือ เขาจะกรุ๊ปโปรเจกต์ต่างๆ นะครับ โปรเจกต์อาจจะเรียกว่าเป็น task หรือว่าเป็น user story ก็ได้ ก็คือเขาจะกรุ๊ปโปรเจกต์ ให้มันอยู่ในธีมเดียวกัน อาจจะอยู่ในแอเรียเดียวกัน อาจจะกรุ๊ปเป็นปึ๊บ เป็นๆ อย่างงี้ใช่ไหมครับ แล้วก็แต่ละ cycle เนี่ย 2 เดือน ก็จะ ฟอร์มทีมขึ้นมาใหม่ทุกๆ 2 เดือน เพื่อมาทำงานในแต่ละ theme ของมันไป อันนี้ก็จะเรียกว่าเป็น PodOS นะครับ พูดคร่าวๆ เพราะว่าเดี๋ยวต่อไปจะพูดถึง เรื่อง pod นิดหนึ่ง แล้วก็อันนี้เป็นสิ่งที่สำคัญในการทำงาน จริงๆ ทุกอันสำคัญหมดแหละ พูดไปงั้นแหละ

ทุกอย่างสำคัญหมดเลยที่บอกมาอย่างนี้ แต่ว่าการที่เราพยายามทำความเข้าใจก่อน

ความสำคัญของการทำความเข้าใจปัญหาก่อนการแก้ไข15:12

ก็สำคัญมากๆ ในการทำงาน เพราะว่าบางทีอย่างเนี้ย ถ้าเกิดว่าเรา เราไม่พยายามที่ทำความเข้าใจก่อน มันจะแบบ มันจะทำให้ เหมือนบางทีเรา jump ไปที่ solutions อะไรอย่างเงี้ย คือมันไม่ได้นะครับ ก็คืออันดับแรกก่อนที่เราจะเริ่มทำงาน เราต้องเข้าใจปัญหาก่อน ก็คือปัญหาที่มันถูกตั้งมาได้อย่างดีแล้วอะ

เรียกได้ว่ามันแทบจะเกือบถูกแก้ไปแล้ว ครึ่งหนึ่งเลย ยังไม่ต้องโค้ดเลยด้วยซ้ำ มันแทบจะแบบเสร็จถูกแก้ไปแล้วครึ่งหนึ่งเลยอะ ถ้าเกิดว่าคุณตั้งปัญหามาดีพอ ใช้ long form writing ใช่ไหม ตั้งมา state มาเลยปัญหานี้ ปึ๊บๆ คน stakeholder เป็นใคร user เป็นใคร ใช้วันไหน อะไรๆ เขียนมาให้หมด ปุ๊บ

แชร์ observation แทน opinion16:02

แล้วก็เวลาที่เรา contribute กับ

กับ conversation อะไรบางอย่างเนี้ย พยายาม state observation ก็คือคุณเห็นอะไรกับสิ่งๆ นั้นอะ อย่าพยายามแชร์ opinion เพราะว่า opinion แต่ละคนแบบสะเปะสะปะมาก observation คือสมมติเนี่ย เรามองสิ่งๆ นึง เช่นแบบปุ่ม ปุ่มเบี้ยว ก็คือคุยกันเรื่องปุ่มเบี้ยว ผมคิดว่าปุ่มมันควรจะไปอยู่ทางบนซ้ายนะครับ ปุ่มจะไปอยู่บนขวา ปุ่มไปอยู่ข้างล่าง ปุ่มมันจะวิบวับ แบบน้องเฟิร์สใช่ไหมครับ อย่าไม่ต้องอย่างนั้น การที่คุณแชร์ opinion อะ คือ opinion ของร้อยคนไม่สามารถเอามารวมกัน แล้วหารได้ แต่ observation ของ 100 คนสามารถเอามารวมกัน แล้วหาออกมาเป็นอะไรบางอย่างได้ เพราะว่าแต่ละคนกำลังคุยๆ เรื่องเดียวกันอยู่ คือปุ่มเบี้ยว อีกคนบอกว่าปุ่มมันอยู่ทางซ้ายไป 50px มันก็คือเรื่องเดียวกัน เพราะนั้นพยายามแชร์ observation มากกว่าแชร์ opinion นะครับ แล้วก็

ไม่ใช่ว่าทุกปัญหามันคุ้มค่าที่จะแก้ในเวลานั้น17:03

ไม่ใช่ว่าทุกปัญหามันคุ้มค่าที่จะ แก้ในเวลานั้น ก็ต้องเข้าใจตรงนี้ด้วย นั่นเป็นเหตุผลว่าทำไมเราต้องเข้าใจปัญหา อย่างมาก ไม่ใช่ว่าทุกปัญหาแบบว่า ปุ่มเบี้ยว เราต้องเสียเวลา 3 เดือนในการแก้อะไรอย่างนี้ มันก็ไม่ใช่ ถ้าเราเข้าใจปัญหาว่าปุ่มเบี้ยวมันแทบไม่ได้ affect ใครเลยหรือว่าไม่มี user complain ก็ไม่ต้องแก้ป่ะ ก็จบแล้ว ประมาณนี้

การรับมือกับความเห็นต่างในทีม: assume good faith17:30

assume good faith ครับ เนื่องด้วยว่าแต่ละคน ไม่เคยเห็นหน้ากัน บางทีใครมา disagree กับเรา หรือมี conflict อะไรบางอย่าง แล้วอย่าไปแบบ

เขาเรียกว่าอะไรวะ อย่าไปตั้ง defensive อะ อย่าไปแบบว่ามองว่า เฮ้ย ทำไมเขามองเราไม่ดี ทำไมเขา disagree กับเราอะไรอย่างนี้ คือคุณต้องคิดก่อนว่าทุกคนเนี่ย มี good faith ก็คืออยากให้โปรดักต์มันดีใช่ไหม บริษัทมันไปได้ด้วยดี อยากให้โปรดักต์ออกมาดี อยากให้ทุกอย่างออกมาดี เพราะนั้นคุณต้องคิดอย่างนั้นไว้ก่อนนะครับ อย่าพยายามที่จะ defend ตัวเอง อย่าพยายามที่จะ debate ฉันจะเอาไอเดียฉัน พยายามเข้าใจปัญหาก่อนว่า ที่เขา disagree มาเพราะว่าอะไรอย่างนี้ จริงๆ มันอาจจะกลับไปข้อแรกก็ได้ว่า ปัญหาคุณมันอาจจะ ไม่มีค่าพอให้มันแก้หรือเปล่า อะไรประมาณนี้ อย่าไปแบบ defensive ประมาณนี้

long form writing ทำให้ทุกคนเข้าใจคุณได้ง่ายมากขึ้น18:22

แล้วก็การใช้ long form writing เนี่ย พูดในตรงเมื่อกี้ไปแล้ว มันจะทำให้ ทุกคนเข้าใจคุณได้ง่ายมากขึ้น เพราะว่าการที่คุณเขียนออกมาเป็น long form มัน force ให้คุณพยายามที่จะคิด ออกมาเป็นรูปเป็นร่างใช่ไหม ไม่ใช่ว่าแบบ บางทีการมาพูดอย่างเนี้ย การประชุมกัน การพูดกันก็พูดเป็นเรื่อยอะ พูดน้ำไหลไฟดับวนเป็นเรืออยู่ ครึ่งชั่วโมงแล้วก็วนเรื่องเดิมอะไรอย่างงี้ แต่การที่เขียนออกมาเป็น long form writing มัน force ให้แบบ อะไรบางอย่างที่มันแบบขยุกขยิกอยู่ในหัวคุณ เอาออกมาให้มันเป็นรูปเป็นร่าง การที่เขียน long form writing มันทำให้ คนที่อยู่อีกฝั่งหนึ่งสามารถรับสารของคุณ ได้ง่ายกว่าด้วยครับผม

พยายามใส่ context เข้าไปเยอะๆ อย่าไป assume ว่าทุกคนรู้หมดแล้ว บางทีเรื่องที่มันแบบโง่ๆ ใส่ context ไปให้ก็ได้ ก็ไม่ใช่ว่าทุกคนจะรู้ทุกเรื่อง เรามาทำงานกัน บางคนก็ไม่รู้เรื่องนี้ บางคนก็ไม่รู้เรื่องนั้น เพราะฉะนั้นเวลาพูดถึงอะไรบางอย่าง ใส่ context เข้าไปเยอะๆ เลย ผมพูดถึงเรื่องนี้ ยัด screenshot เข้าไป เขียน form เสร็จไม่พอ ยัด screenshot เข้าไป อัดวิดีโอเข้าไปด้วย ผมหมายถึงตรงนี้ ใช่ไหม บางทีการคุยถึงเรื่อง interaction เนี่ยยาก อย่างสมมติให้ไอ้เฟิร์สมันเขียนเป็น form ยาวๆ อธิบายว่าเมื่อกี้ผมทำอะไร มันอาจจะยาก แล้วก็ default เป็น long form ไว้ก่อน เพื่อให้คนสามารถทำความเข้าใจได้ แต่ใส่ context เข้าไปเยอะๆ ด้วยอย่างนู้นด้วยอย่างนี้ด้วยอย่างนั้น ประมาณนี้นะครับผม

การทำงานแบบเปิดเผย: work in the open19:43

แล้วก็อันนี้เป็นอีก culture หนึ่งของเรา ก็คือ work in the open เนื่องด้วยว่าทุกคนก็แทบไม่เจอกันอยู่แล้ว การที่ทุกคนทำงาน

work in the dark อยู่แล้วอะ คือเราไม่เห็นเลยว่าเพื่อนเราทำอะไรอยู่ถูกไหม ดังนั้นการที่ work in the open มันบังคับให้คุณ

ระวังมากๆ เช่นแบบว่า

ประมาณว่ายังไงไม่ทำให้คุณ ทำงานผิดพลาดอะไรประมาณเนี้ย

แทนที่เราอยู่เงียบๆ คนเดียว สมมติเราทำงาน เงียบๆ คนเดียว ไม่ได้สื่อสารกับใคร อีกหนึ่งอาทิตย์ออกมาแล้วบอกว่า ติดมากเลยครับผม อีกอาทิตย์หนึ่ง หนึ่งอาทิตย์ที่ผ่านมางานที่ทำมาต้องโยนทิ้ง มันก็ไม่เวิร์กถูกไหม

การรายงานความคืบหน้า20:25

เพราะฉะนั้นเราก็ควรจะทำทุกอย่างใน open

แล้วก็ communicate progress ใน open เหมือนกัน อย่างในบริษัทนี้ก็มี

มันจะมี pod channel แล้วก็มี weekly update ทุกๆ อาทิตย์ แต่ละทีมก็จะมาเขียน update ว่า project ที่แต่ละคนเขาทำกันไป มันไปถึงไหนแล้ว อะไรดีบ้าง อะไรไม่ดี อะไรเป็นยังไง เพราะเราทำสิ่งเหล่านี้ มันจะเกิด มันจะเกิด surface area ที่ให้ทุกคนสามารถ เข้ามา contribute feedback ได้ อันนี้ก็เป็นสิ่งที่สำคัญมากเพราะว่าเราทำงาน ต้องการ feedback มา iterate ใช่ไหมครับ ไม่ใช่ว่าแบบเราทุกคนจะเขียนงาน ออกไปแล้วมันดีเลย การทำงานมันเป็นการทำงานร่วมกันกับหลายๆ คน ไม่ใช่การทำงานคนเดียว เพราะฉะนั้นการที่เราสร้าง surface area work in the open คนอื่นที่เขามาเห็น เขาอาจจะ spot ได้ว่าแบบ เฮ้ย ตรงนี้เคยมีคนอาจจะทำ util ไว้แล้วอันหนึ่งนะ คุณไม่ต้องเขียนซ้ำอะไรประมาณนี้ หรือว่ามีคนบอกว่า คนอีกทีมนึงเขากำลังมา address ปัญหานี้อยู่ เออ ลองไปคุยกันไหม ลองไปจอยกันว่า มีแบบ solution อะไร สามารถ middle ground สามารถ compromise ซึ่งแบบ มันทำให้มันอาจจะ resolve ทั้งสองอันนี้ อาจจะประหยัดกว่าอะไรประมาณนี้ครับ

แล้วก็อันนี้เริ่ม

ความสำคัญของการประชุมแบบ one-on-one21:46

สายแล้วเดี๋ยวเราไปเร็วๆ นะครับ ก็ culture และก็ process ก็สั้นๆ จริงๆ อันนี้ อันนี้เป็นอะไรที่สำหรับผมว้าวมาก one-on-one เนี่ย คือของผมเป็นปัญหาคือ manager ผมเนี่ยอยู่ใน time zone ที่แบบ US อะ แล้วตลอดประมาณ 5-6 เดือนเนี่ย

เจอกัน 2 ครั้ง ผมก็แบบเครียดมาก ช่วงนึงเครียดมาก

เราทำงานดีป่ะวะ เราจะแบบว่าเราจะโดนปลิว ไปเมื่อไหร่ไหมวะ อะไรอย่างนี้ แต่ว่าพอมี one-on-one ปุ๊บ พอเขาเริ่มมาเซต one-on-one มาจริงๆ พอเริ่มมาคุยอย่างเนี้ย ก็ทำให้แบบ ผมเองเรารู้สึกว่า เออ ที่จริงที่ผ่านมาเราคิดไปเองว่า เวลาเราคิดอะไรไปเอง พยายามที่จะขอ one-on-one เลย แม้แต่เขาไม่มี พยายามขอ one-on-one เลย จัด one-on-one กับ manager ก็ได้ หรือจัด one-on-one กับคนที่ senior กว่าก็ได้ เพื่อแบบขอ feedback เลย อย่างผมก็ one-on-one แล้วก็ขอ feedback ว่า เอ้อเนี่ย คิดว่า ผมเองทำงานเป็นยังไง มีปัญหาไหม เพราะเค้าบอกว่าจริงๆ ไม่มีปัญหา ชีวิตดีเลยอะ คือแทนที่เราแบบตัวเองมานั่งเครียด ไปเองว่าแบบ เฮ้ย เราทำงานอยู่กับแบบ คนที่แบบเก่งๆ อย่างเนี้ย แล้วเรา doubt ตัวเองอะ การที่เรา doubt ตัวเองมันทำให้แบบ เหมือนกดตัวเองต่ำ เพราะเรารู้สึกตัวเล็กเนี่ย เราก็ทำงานมาไม่ดีไหมครับ เราก็ต้อง มีอะไรสงสัย อย่าคิดไปเอง ถามนะครับ

การใช้ guild ในการพัฒนาทักษะของทีม23:01

แล้วก็เรามีสิ่งที่เรียกว่า guild อันนี้ก็ค่อนข้าง inspire มาจาก Spotify เหมือนกัน เนื่องจากว่า pod เนี่ยเป็น cross-functional team ถูกไหม คือแต่ละทีมเนี่ย self-sufficient สามารถ ทำงาน product ของตัวเองไปได้ตั้งแต่ต้นน้ำยันปลายน้ำ มี product designer มี

product manager, engineer, frontend, backend แต่ว่า guild เนี่ยคือ

คือคนที่อยู่ในฟังก์ชันงานเดียวกัน เช่น front-end ก็คือมันจะมี ตอนนี้มี 2 guild มี front-end guild กับ back-end guild คนที่อยู่ใน work function เดียวกันก็จะเข้ามา guild meeting เพื่อคุยกับเรื่องต่างๆ ในเกี่ยวกับ work function ตัวเอง อย่างเช่น front-end ก็มีคุยถึงเรื่อง front-end ทั่วไปอะไรอย่างเงี้ยครับ เพื่อให้เรียกว่าไง เพื่อให้ช่วยกันพัฒนาตัวเอง การที่คนอยู่ในฟังก์ชันเดียวกัน เรียกว่าไง rate หรือว่าให้ feedback กันเอง มันดีกว่าให้คนคนละฟังก์ชันมาให้ feedback เพราะว่า feedback ที่ดีที่สุด ไม่ใช่ว่าไม่ดีนะ คือคน cross-functional feedback ก็ดี feedback ที่ดีที่สุดกับตัวเราคือมาจากฟังก์ชันเดียวกัน อย่างเช่นเราเป็น engineering อยากพัฒนา การเขียนโค้ดใช่ไหม ให้ designer มาให้ feedback ก็ไม่ได้ถูกไหม ประมาณนั้นเนอะ

นโยบายการจ้างงานและการให้อิสระในการทำงาน24:12

แล้วก็ hiring อันนี้ผมว่าเป็นอะไรที่ว้าวเหมือนกัน ของ Metabase เขาบอกว่า- แป๊บนึง

เขาบอกว่าเรา "hire for strength, not lack of weaknesses" ก็คือเวลาเราจ้างคน เราดูว่าคนนั้นเขาเก่งอะไร เราก็จ้างเขา ไม่ใช่ว่าเราจ้างเพราะว่า คุณเป็นคนแบบไม่มี weakness อะไรเลยอะ ไม่ใช่มีคนเป็นกลางๆ คือไม่ได้บอกว่ากลางๆ ไม่ดีนะ แต่บอกว่าอันนี้คือแชร์ว่าอันนี้เป็นเหมือนแบบ mindset ที่เขาใช้หาคน ว่าแบบเออเขาอยากหาคน ที่แบบมี strength อะไรบางอย่างเนี้ย คือคุณจะกากอะไรก็ได้ แต่คุณต้องมีเทพ อะไรบางอย่างอะไรประมาณนี้ แล้วด้วยการที่เขาจ้างคนแบบเนี้ย ส่วนใหญ่เขาจะจ้างที่ผมเจอนะ เขาจะจ้างแต่ senior นั้นเลย เพราะว่าสิ่งที่เขาให้กับคนในบริษัทนี้คือ autonomy autonomy ก็คือ แปลเป็นไทยว่าอะไรไม่รู้ แต่คือมันคือเขาให้ทุกอย่างกับคุณอะ คุณอยากทำงานกี่โมงก็ได้ คุณอยากลากี่วันก็ได้ วันหยุดไม่นับกัน คุณอยากวันไหนไม่เอาทำงาน อยากจะไปข้างนอกไปทำธุระอะไรอย่างนี้ก็ได้ แต่ว่าสิ่งเดียวที่คุณต้องทำคือ คุณต้องรับผิดชอบงานของคุณ communicate อะไรไปต้องทำให้ได้ สิ่งนี้คือเรียกว่า autonomy ก็คือผมชอบ manager ผมพูดคำนึงมากเลยว่า แบบเข้ามา we are all grown-ups เราโตๆ กันแล้ว ทำงาน แบบคนโตๆ กันแล้ว ดูแลตัวเองนะ อะไรประมาณนี้ ก็แบบเจ๋งดีว่ะ คือบริษัทผมแทบไม่ค่อยมี junior ที่ต้องเข้ามา

คอย coach คอยอะไรอย่างเนี้ย ถ้าไม่มีเลยส่วนใหญ่มันจะเป็น senior มากกว่า อันนี้ก็บอกว่าวิธีการ hiring ของ Metabase เป็นแบบนี้ จบครับ Q&A จริงๆ ครึ่งชั่วโมงพอดีเลย อยากจะไปให้เร็วกว่านี้ แต่ว่าก็ประมาณนั้นแหละ ใครมีคำถามไหมครับ

Q&A: อธิบายเพิ่มเติมเกี่ยวกับ asynchronous communication25:58

ก็คือเมื่อกี้คำถามคือขยายความ async communication ให้หน่อยใช่ไหม synchronous แปลว่าอะไร synchronous แปลว่าพร้อมๆ กัน asynchronous แปลว่าอะไร แปลว่าไม่พร้อมกัน asynchronous communication แปลว่า communication ที่เกิดเมื่อตอนที่ไม่พร้อมกัน เช่น ผมพูดวันนี้ปุ๊บ มี Facebook Live พรุ่งนี้มีคนมาดู asynchronous communication แต่ว่าถ้าเกิดว่าวันนี้ผม ทุกคนเข้ามาดูคุยกับผม คุณสามารถถามคำถามได้ เป็น synchronous communication ประมาณนี้ครับ

เพราะว่าผมเห็นว่าปัญหาจากการที่ทำ time zone มันต่างกันอย่างเงี้ย แล้วใช้วิธีนี้คือ มันโต้ตอบยากซึ่งอย่างที่บอกว่าเราใช้เรื่อง long form writing เป็นการแก้ปัญหานี้เป็นหลักเลย ใช่ไหมครับ / ใช่ครับ ผมลองถามให้คิดแล้วกันว่าถ้าเกิด บริษัทผมลองคิดภาพด้วย context แบบนี้ที่พูดมา แล้วทุกคนทำงานแบบ synchronous ต้องมี engineering ทุกคนที่เป็น front-end ต้องมาประชุมพร้อมกัน ลองจินตนาการว่ามันจะเกิดปัญหาอะไรได้บ้าง ก็ลองไปคิดดู อย่างผมเองผม suffer มาก ส่วนใหญ่ที่เขามีมีตติ้งกัน เขามีมีตติ้งกันตี 1 ตี 2 ไง ผมเข้าไม่ไหวนะ ใช่ไหม อันนี้ก็เป็น pain point หนึ่ง การที่เราไป favor time zone หนึ่ง บุ๊บ อีก 3 โซนหนึ่งก็ suffer เพราะฉะนั้นมัน force ให้มัน เป็น synchronous ทั้งหมดไม่ได้อยู่แล้ว ถ้าเกิดว่าเรา hire globally แบบนี้ครับ คำถามดีครับ

Q&A: สัดส่วนของการสื่อสารแบบ synchronous และ asynchronous27:26

แล้วที่ synchronous นี่มีประมาณกี่เปอร์เซ็นต์ครับ แล้วทำอะไรกันบ้าง ที่อยากรู้ว่าแบบอะไรที่เห็นหลายๆ บริษัท เขา synchronous กันแล้ว แล้วสุดท้ายมันเป็น asynchronous ก็ได้ แล้วก็อันไหนที่มันควรจะ sync จริงๆ ครับ ก็คือจริงๆ ส่วนใหญ่เรียกว่าโดย nature เป็น asynchronous หมดเลยดีกว่า แต่ว่า synchronous เนี่ย ส่วนใหญ่จะมีพวก อย่างของผม pod หนึ่ง ทำงานเป็น cycle แล้ว 2 เดือน ทุกๆ อาทิตย์เราก็จะมีมาคุยกันว่า progress เป็นยังไง อันนี้เป็น synchronous ก็คือเหมือนแบบเรียกว่าแบบแชร์ progress กัน เหมือนแบบเขาเรียกว่าอะไรวะ daily stand-up meeting จะเป็นแบบ weekly stand-up meeting อะไรประมาณนั้น คือผมมองว่าอันนี้มันดี มันคุยกันไม่นานเกินไป เพราะว่าจริงๆ ระหว่างอาทิตย์เรามีการเขียน จริงๆ daily stand-up meeting เราไม่มี แต่เราเขียนทุกวันว่าวันนี้เราจะทำอะไร วันนี้เราทำอะไร ได้บ้าง เขาจะเรียกว่า start of day วันนี้คุณอยากทำอะไร แล้วก็ end of day วันนี้คุณเสร็จอะไรบ้าง บางคนก็อาจจะเขียนว่าเสร็จอันนี้นี่นั่น ติดปัญหานู่นนี่นั่น เพราะฉะนั้นระหว่างทางมันมี async มาเยอะๆ อยู่แล้ว แล้วก็ทุกๆ อาทิตย์เราก็มาคุย synchronous กันทีนึง แต่ก็ต้องบอกอีกว่าอย่างผมเป็นแค่ engineer ผมอาจจะมี synchronous meeting น้อยกว่าคนอื่น คนอื่นที่เลเวลสูงกว่าก็จะมีคุย อาจจะคุยกับ management ข้างบน มันมี meeting อื่นๆ เอง

ที่ผมไม่ได้เข้า / มีคำถามต่อไปนิดหนึ่งครับ

Q&A: การจัดการกับปัญหาการรีวิวโค้ดในทีมระยะไกล28:59

เรื่องโค้ดรีวิวนี่ก็คือต้องรอนานไหมครับ ถ้ามันหลาย time zone แล้ว

มันเป็น pain ไหม เรื่องโค้ดรีวิว เพราะบางทีพอ asynchronous แล้ว ผม submit โค้ดไป สมมติว่า ต้องรอ 1 วันกว่าจะ merge ได้ มันมี pain อะไรแบบนั้นไหม หรือว่าแก้กันยังไงครับ มันก็มี pain ครับ คือไม่ใช่ว่าทุกคนเขาจะมารีวิว PR เป็นปกติ

เท่าที่ผมลองสังเกตดูว่า จะมีแค่บางคนที่ชอบรีวิว PR เยอะมากๆ

คือมันจะมีทุกๆ อาทิตย์อะ เราก็จะแบบส่ง Metabase มันจะส่งเหมือนแบบ

digest มาว่าเราก็จะเห็นว่าคนนี้รีวิว approve ไป 20-30 อัน บางคนอาจจะไม่ approve เลย เพราะฉะนั้นมันก็จะมีบางคนที่คอยช่วยรีวิวโค้ด ให้คนอื่นอยู่

แต่ว่า pain มันก็มีแหละ ที่ผมเห็นส่วนใหญ่คือ ถ้าเกิด PR ใหญ่มากๆ แทบไม่มีใครรีวิวเลย พอแบบเกิน 200-300 ไลน์อะไรอย่างเงี้ย เห็นวันนี้หรือเปล่านะที่เห็นใครแชร์ พี่แม็กซ์หรือเปล่า จำไม่ได้ PR ยาวๆ มากๆ อย่างเนี่ย คือพอ PR อย่างเนี่ย ผมเห็นผมปิดแล้วอะ แต่สมมติน้องไท submit PR มา +20 -20 อะไรอย่างเงี้ย มันก็แบบน่ารีวิวถูกปะ เราก็ไม่อยากให้ PR มันค้าง ผมอะคือผมเข้าไปปุ๊บ ผม sort แล้วผมจิ้มๆ มีอะไรต้องรีวิวบ้าง แล้วก็เอาน้อยสุดไว้ข้างหน้า รีวิวน้อยสุดก่อน เพราะฉะนั้นถ้า pain เนี่ย เท่าที่ผมเห็นนะครับ ส่วนใหญ่จะเป็น PR ที่มันยาวๆ ก็คือถ้า PR ใหญ่ก็รับกรรมไปอะไรประมาณนั้นแหละครับ ประมาณนั้นนะครับ ใช่ แต่คือมัน ผมมองว่าบางทีมันก็ห้ามกันไม่ได้ คือปัญหาบางอย่าง มัน complex มันก็ต้องยาวใช่ไหมครับ PR ยาว แล้วก็ถ้าเกิดว่ามันนานเกินไป เรียกว่าคน

เปิด PR ก็ต้องดูแลตัวเอง เราก็ไปปิงในห้อง engineering ใช่ไหม อันนี้คือ work in the open เราก็ work in the open ว่านี่ตั้ง 3 วันแล้ว ไม่มีใครมารีวิวของเราเลย ช่วยไปรีวิวหน่อย ก็ใช้วิธีแบบนี้ ไม่ใช่ว่าแบบเปิดไปแล้ว เดี๋ยวก็มีคนมา review เองแหละ - ก็คือเจ้าของ PR ก็ต้องคอย ping ถ้าเริ่มรู้สึกว่านานเกินไปแล้ว - ใช่ คือเราก็ต้อง ask for help เราก็ต้องรู้ว่าเมื่อไหร่ที่แบบ - จมน้ำแล้ว เราต้องไปต่ออะไรแบบเนี้ย - แต่มัน mandatory ใช่ไหมครับ คือต้องมีรีวิว ก่อนมันถึงจะ merge ได้ - ถ้าไม่มีรีวิวจะไม่ merge ครับ - อ๋อครับ เพราะผมเห็นบางเจ้า ที่เขาทำ continuous delivery กันโหดๆ เขาก็บอกว่า คุณ pair programming กันสิ เวลา commit ปุ๊บ 15 นาทีขึ้น production อะไรแบบนี้ ก็ได้ครับ บางทีก็สับสนข้างในว่าโอเค

- แบบแต่ละแบบเป็นยังไง - จริงๆ ก็คือ give context อย่างนี้ เนื่องด้วยจริงๆ เอ็นจิเนียร์ยังถือว่าน้อย 30 คนทั่วโลก มันแบบโอกาส pair อย่างผมมีโอกาส pair กับใคร แทบไม่มีแหละ มันน้อยมาก ก็แบบไม่ได้เป็น default แบบเรา เข้ามาออฟฟิศเดียวกัน แล้วก็ทำงานด้วยกัน แล้วก็พูดไปได้ มันก็ดีอย่างเสียอย่าง อะไรประมาณนี้ครับ ขอบคุณมากครับ

Q&A: การจัดการกับปริมาณข้อมูลและการอ่าน long-form writing32:02

มีคำถามอีกไหมครับ เราจำเป็นต้องอ่าน long form writing ของทุกคนไหมครับ หรือว่าอ่านแค่เฉพาะที่เกี่ยวกับเรา อันเฉพาะที่เกี่ยวกับเราแล้วก็เราสนใจครับ คือมันเป็นไปไม่ได้เลยที่เราจะรู้ everything ในบริษัท คำถามคือ ทำได้ไหม ทำได้ แต่คำถามคือคุ้มไหม สมมติเราไปอ่าน discussion ของ product manager หรืออ่าน discussion ของ designer โดยที่เราเป็น engineer คำถามคือคุ้มเวลาเราไหม เวลานั้นมันเอาไปทำ อย่างอื่นได้ไหม ไม่ใช่ว่าทุก problem worth solving กลับไปที่อันแรกประมาณนั้น ก็เราก็อาจจะอ่าน เฉพาะอันที่เราสนใจ เช่นแบบว่าตรงนี้มันเป็น ดีไซน์เกี่ยวกับ area ที่เราทำอยู่พอดี มันคล้ายๆ กันอะไรอย่างนี้ เราก็เข้าไปอ่าน เป็นเรื่องที่ดีแต่ก็ต้อง weigh กันนะครับ ต้องบาลานซ์ว่า เราอยากจะไปอ่านอะไรของใครบ้าง ส่วนใหญ่ผมก็อ่าน แค่ weekly update คร่าวๆ เพื่อไม่ให้มันเสียเวลามาก ไม่งั้นถ้าตามอ่านของคนอื่น ผมว่าผมสามารถอ่านได้ ทุกวัน โดยไม่ต้องโค้ดเลยก็ได้ มันมีเยอะมาก

แล้วเวลาบางทีถ้ามันสำคัญที่ต้องการ opinion ของเรา คนอื่นจะแท็กเรามาเองเหมือนกัน เพราะว่ามันเป็น culture ของการ work in the open ใช่ไหมครับ เราก็ต้อง state ไปเลย ผมทำงานนี้อยู่ ผมต้องการ input ผมต้องการ feedback จากคุณ 1 2 3 4 5 อะไรอย่างนี้ประมาณนี้

Q&A: การพูดคุยเรื่องเงินเดือนและค่าตอบแทน33:24

- rate หมายถึงเงินเดือนใช่ไหมครับ - ใช่ หมายถึงว่าเราทำงานอยู่ที่นี่ คนอื่นทำงานอยู่ที่นั่น - rate มันใกล้ๆ กันไหม - ผมไม่ทราบครับ แต่สามารถแชร์ได้ว่ามันเป็น public ว่า average salary ประมาณ 400,000 บาทครับ - ต่อเดือนเหรอครับ - ครับ มันมีตัวเลขตัวเลขนี้ แต่เพราะผมไม่รู้ว่าคนอื่นได้เท่าไหร่ ผมเดาว่าจริงๆ ปกติเวลาจ้างเนี่ย

มัน per area อยู่แล้วอะ เท่าที่ผมเห็นอะนะ ก็คือโซนแถวๆ เราก็คงได้ต่ำๆ หน่อยครับ

Q&A: คำแนะนำในการหางาน remote และ open source34:01

อยากให้ลิสต์บริษัทที่คล้ายๆ กับ Metabase คล้ายๆ ในแง่ครับ remote งาน remote

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

Remote OK อะไรประมาณนี้ คือมันเป็นเหมือนพอร์ทัล ของเว็บที่รวม remote job อะไรอย่างนี้ครับ ลองเข้าไปดูได้ แต่ว่าเอาจริงๆ นะ อันนี้เป็นแชร์เทคนิค ในการหางานส่วนตัวนะ ชอบโปรดักต์ไหนเข้าไปแล้วก็สมัครอันนั้น คือมันถ้าแบบ ผมมองว่าการที่เรามี passion กับอะไรบางอย่าง มันทำให้เราเข้าไปทำมันสุด เหมือน Metabase ผมเห็นเข้าไปแล้วว่า UI สวย อันดับแรกเลย UI สวย แล้วมันดูง่าย มันเรียกว่าไง values มันคลิกกันอะ เพราะเข้าไปทำงานแล้ว มันมีความสุขมาก มันไม่ใช่ว่าเหมือนทำไปเฉยๆ อะไรอย่างเนี้ย อย่างเช่นใช้อะไรอะ ใช้ Figma ใช้ VS Code ใช้ MUI อะไรอย่างเงี้ย ไปสมัคร ลองไปสมัครดู อันนี้เป็นเทคนิคของงานของผม ชอบ tool อะไร สมัครไปเลย แล้วก็ไปดูว่าเขามี remote หรือเปล่า ถ้าไม่มีก็หาไปเรื่อยๆ Reddit อะไรอย่างนี้ พวกนี้ก็มีนะ Reddit, Discord อะไรพวกนี้ครับ

ประสบการณ์การทำงานกับโปรเจค open source35:30

ก็ถ้าไม่มีแล้วก็คงประมาณนี้มั้งครับ ก็อยากมาแชร์ประสบการณ์

ตั้งแต่ทำงานมา 8 ปี ไม่ค่อยรู้จักใครที่ทำ open source เลยนะครับ จริงๆ เพิ่งมารู้จัก น้องจุ้นก็ไม่นาน น้องจุ้นได้ทำงานที่ MUI มันก็เป็น open source เหมือนกัน เขาทำก่อนผม แล้วผมก็เพิ่งมาทำ Metabase ได้ ประมาณเกือบ 1 ปีแล้ว ผมพึ่งมองว่ามันเป็น อะไรที่แบบ ว้าวดีอะนะ เราทำงาน เราทำโปรเจกต์ที่มันเป็น open source ด้วยแล้วมันทำเงินได้ด้วย อะไรอย่างนี้ครับ มันว้าวมาก ก็ขอบคุณทุกคน และขอบคุณทุกคำถามนะครับ ก็เดี๋ยวคืน

เซสชันให้กับออร์แกไนเซอร์แล้วกันเนอะ ขอเสียงปรบมือด้วยครับ มีคำถามเพิ่มครับผม มีคำถามจากทางบ้านครับ

อธิบายเพิ่มเติมเกี่ยวกับ PodOS36:18

- PodOS นี่ทำงานกันยังไงครับ - อ๋อ จริงๆ คือ ตามเมื่อกี้ที่บอกแหละ PodOS คือ เรา optimize throughput คือเราจะไม่แบบมีคน ปกติบางที่เขาจะฟอร์ม- ไม่แน่ใจว่าบางที่หรือหลายที่นะ ถ้าเกิดมีพนักงานเยอะๆ เขาก็จะมีทีมที่มัน fixed fix อยู่แล้ว แล้วแต่ละทีมอาจจะดูแล area อะไรบางอย่าง ใช่ไหมครับ อาจจะดูแล เช่น เซอร์วิสนี้ หรือว่าพาร์ตของโปรดักต์นี้ ฟีเจอร์นี้ อะไรอย่างนี้ แต่ว่า management ที่ Metabase บอกว่า มองว่าอันนั้นมันไม่ optimize throughput มันไม่สามารถทำงานออกมาได้เท่าที่เขาอยากทำ เพราะฉะนั้นสิ่งที่เขาอยาก ก็คือเขาอยากจะให้โปรเจกต์มันเสร็จเยอะมากที่สุด เขาก็กรุ๊ปมาว่าแบบ ช่วงนี้อาจจะมี user request มี bug มีอะไรมากรุ๊ปมาเป็นเรื่องเดียวกัน เพราะฉะนั้นเวลาคนไปทำงานในเรื่องนี้ มันจะเห็นทุกอย่างในภาพรวม ในภาพใหญ่ holistic ไม่ใช่ว่าแบบ อ่ะ ในทีมๆ นึง แยกไปสิ่งๆ หนึ่ง แล้วแบบดูแลแค่ area นั้นเล็กๆ อะ บางทีมันไม่สามารถ สร้าง impact ได้ครับ การที่ทำเป็น PodOS เนี่ย ทุกอย่างมันกรุ๊ปกัน แต่ละอย่างมัน connect กัน บางทีเรา solve อย่างหนึ่งมันไป solve อีก หลายอย่างได้ อย่างเนี้ย management เขาเลยมองว่ามัน throughput ดี ทำงานประมาณนี้ครับ เน้นจากโปรเจกต์ไว้ก่อน ทุกๆ 2 เดือนเขาก็จะสร้างมาว่ามีธีมนี้ ธีมนี้ ธีมนี้ แล้วก็ assign คนลง pod เพราะนั้นคนจะเปลี่ยนไปเรื่อยๆ engineer ก็สามารถใส่ input ไปได้นิดนึงว่าแบบ ผมอยากลองทำอันนี้เนี่ย ลองทำนี้ อย่างของผมบอกว่าผมอยากทำ visualization พวกวาดกราฟอะไรอย่างนี้ ผมก็บอกไปแล้วก็ได้เข้ามาทำ cycle นี้ สนุกดีนะ

ครับ ขอบคุณพี่เควินมากครับผม

โอเค ครับ จบแล้ว

สรุปและเน้นย้ำความสำคัญของภาษาอังกฤษในการทำงานระดับนานาชาติ38:19

ถ้าเกิดว่าหลังจากนี้ใครอยากรู้เรื่องอะไรเพิ่ม จริงๆ มีอย่างหนึ่งที่พี่ไม่ได้พูดใช่ไหม ก็คือเรื่อง รายได้ แต่ว่า อ่า ถามแล้วใช่มั้ย อ๋อ average สี่แสน โอเค สุดยอดมาก ผมว่านั่นแหละคือสิ่งที่ เย้ายวนใจ มาลอง

จริงๆ อยากพูดอย่างหนึ่งคือ ผมก็ไปดู live ของน้องจุ้นเนี่ย บอก US เงินหนาใช่ไหม คือหนาจริงครับ คือทุนหนามาก ยังบริษัทผมเนี่ย raise funding Series B มา 30 ล้านเหรียญ เงินก็ยังเหลืออยู่ แล้วก็รายได้คือรายได้เยอะมากอะ ผมจำไม่ได้แล้วประมาณ 4 ล้านเหรียญต่อปีมั้งรายได้ ก็ไปคิดเองเท่าไหร่ จำไม่ได้ 4×3=12, 4×4=16 แล้วราคา sales คุยกับ sales แล้ว คนละ job function กัน คือถ้าเกิดว่าคุณเข้าไปจอย English Club for Developer คุณจะมีโอกาสที่จะ สมัครงานต่างประเทศได้ เพราะอันนี้จริงเป็น อันหนึ่งที่ไม่ได้พูด คือถ้าเกิดว่าแบบ บางทีถึงแม้ว่าคุณเก่งมาก แต่ถ้าเกิดบางทีแบบ การสื่อสารมันติดขัดไปนิดนึงอะ มันทำให้มันเกิด flow ไม่ได้ หรือมันทำให้เกิด product team ไม่ได้ จริงๆ ผมมองว่ามันเป็นเรื่องที่น่าเสียดาย ที่ developer เก่งๆ ในไทยหลายคน ขาดโอกาสที่จะไปทำงานกับต่างประเทศ อะไรอย่างเงี้ย เพราะฉะนั้นภาษาอังกฤษ เป็นอะไรที่สำคัญมากๆ ครับ เพราะงั้นก็มาจอยที่ Discord กันนะครับ