แม่งจริง เพราะว่าฟีเจอร์ที่ผมเปิด PR ไปนั้น ถ้าเป็นสมัยก่อนผมน่าจะใช้เวลาทั้งอาทิตย์แต่รอบนี้คือผมใช้เวลาแค่บ่ายวันเดียวกับ Agent ก็เสร็จ ผมยัดทุกอย่างลง PR ด้วยความภาคภูมิใจกับความสามารถในการคุม Agent ของผมทั้ง Spec ทั้ง Implementation เป็นร้อยๆ บรรทัด

พอส่งให้รีวิว เพื่อนร่วมงานผมบอกว่า มันลำบากมากในการทำความเข้าใจโค้ด หรือไล่โค้ดอย่างเป็นระบบ เพราะว่ามันจะมี Spec หรือคำอธิบายที่ Agent เติมแต่งขึ้นมานอกจากโค้ดมาทำให้ไขว้เขว มาขัด Flow ในการทำความเข้าใจอยู่เรื่อยๆ

สิ่งที่พังจริงๆ

หลังจากผ่านมาซักพักใหญ่ ผมว่าผมเริ่มเข้าใจละว่ามันเกิดอะไรขึ้น และผมสามารถพูดได้เต็มปากว่า

ต้นทุนในการผลิตโค้ดมันลดลงจนแทบไม่เหลือ แต่ต้นทุนในการทำความเข้าใจมันไม่ได้ถูกลงเลย

ทุกๆ Practice ที่เราถูกสอนกันมา ถูกสร้างมาสำหรับโลกที่ “การเขียนโปรแกรม” คือส่วนที่แพงที่สุด ถูกสร้างจากสมมติฐานว่าโค้ดเกิดขึ้นได้เพราะผ่านการคิดมาแล้ว ในอดีตการคิดนั้นถูกส่งต่อผ่าน Code Review ที่ซึ่งคนในทีมจะได้ถ่ายทอดการเรียนรู้ให้กัน แต่พอปริมาณโค้ดที่ผลิตมีมากขึ้นเกินกว่าที่คนๆ หนึ่งจะรับไหว สิ่งนั้นแหละที่ทำให้เกิดช่องว่างทางการเรียนรู้ และมันขยายใหญ่ขึ้นมากเรื่อยๆ

สิ่งที่ผมลองทำ

พอผมรู้ตัวว่า PR ผมมันปนกันระหว่าง Spec กับ Implementation การทดลองแรกผมเลยลองแยก Spec ออกมาเป็น PR หนึ่ง ตามด้วย Implementation ออกมาเป็นอีก PR หนึ่งที่ Stack อยู่บน PR แรกอีกที ถ้าเพื่อนร่วมงานผมไม่สนว่า ผมสั่ง Agent ผ่าน Spec ยังไงบ้าง เค้าก็แค่ Skip PR แรกไปดูโค้ดเองได้เลย

ซึ่งเหมือนจะเวิร์ค แต่ก็สร้างปัญหาใหม่ตามมาทันทีเพราะ Stack PRs ต้อง Merge ตามลำดับ ทำให้ผมต้องจัดการ Dependency ในการ Merge เพิ่มมาอีกต่อหนึ่งด้วย และก็ต้องอธิบายเพิ่มด้วยว่า PR อันนี้ต้องเข้าก่อนอันนี้นะ แทนที่จะแค่โฟกัสกับสิ่งที่สำคัญที่สุดจริงๆ ซึ่งก็คือ Implementation นั้นแหละ

แต่ในความซับซ้อน มันก็มีข้อดีอยู่นะ เพราะหลังจากทำอย่างนี้ได้ซักพัก ผมก็เริ่มรู้ตัวว่าสิ่งที่ควรแก้จริงๆ ไม่ใช่ Workflow ในการ Merge แต่คือความเข้าใจว่าเรามี Spec เอาไว้ทำไม

ผมใช้ Spec เพื่อที่จะสร้าง Implementation เวอร์ชั่นแรก แล้วหลังจากนั้นค่อย Refactor ตามมา ตัว Spec จะถูกใช้เป็น Reference ของ Logic แต่จะไม่เคยถูกอัพเดทตามมาเลย พอถึงจุดที่ผม Refactor จนพอใจแล้ว ถึงแม้ Business Logic (What) จะยังเหมือนเดิมอยู่แต่วิธีการที่ Implement (How) มันต่างจากที่อธิบายไว้ใน Spec ตอนแรกไปแล้วครับ

งั้นก็อัพเดท Spec หลัง Refactor ด้วยสิ ผมลองละครับและมันไม่เวิร์ค เพราะ Spec ถูกเขียนออกมา “ก่อนที่เราจะรู้อะไร หลายๆ อย่าง”

เราไม่มีทางที่จะออกแบบ Software ได้อย่างสมบูรณ์แบบก่อนที่จะ Implement ไม่ว่าเราจะพยายามมาแค่ไหนก็ตาม เพราะว่าความรู้บางอย่างจะเกิดขึ้นได้ในระหว่างที่เรากำลังสร้างมันออกมาเท่านั้น หลายครั้งที่เรากำลังเขียนโปรแกรมอยู่ก็นึกวิธีการที่ดีกว่าได้ออกและ Agent ไม่สามารถทำสิ่งนี้ได้ ไม่ใช่เพราะว่ามันจำ Context ไม่ได้เก่ง แต่เพราะมันไม่ได้เห็นภาพใหญ่ของงานที่คุณกำลังทำอยู่ และ “คุณไม่เคยบอกมัน เพราะคุณไม่รู้ตัวด้วยซ้ำว่าต้องบอก”

เพราะฉะนั้นเนี่ยในมุมมองผม Spec มันได้ทำงานตอบโจทย์ของมันแล้วตั้งแต่เราสั่งมัน Implement จนเสร็จเป็นเวอร์ชั่นแรก เวอร์ชั่นที่เราจะได้เล่น ได้แกะ ได้แงะดูว่าเป็นอย่างที่เราต้องการมั้ย และทุกอย่างที่เราเรียนรู้หลังจากจุดๆ นี้มันเกิดขึ้นกับเรา และการที่เราต้องกลับไปถ่ายทอดความรู้นี้กลับไปที่ Spec ทำให้เราต้องดูแล knowledge ถึง 2 ที่ซึ่งก็จะผิดทันที ถ้าเรา Refactor ต่อไป

พอถึงจุดนี้เนี่ยผมโยน Spec ทิ้งละครับ สิ่งที่เหลืออยู่คือ Business logic ที่ถูก Implement ลงไปอยู่ในโค้ดเรียบร้อยแล้วและได้ถูก Refactor มาถึงจุดที่ผมสามารถอธิบายทุกส่วนของมันได้

ผมไม่ได้บอกว่าวิธีนี้ดีที่สุดนะ แต่อย่างน้อยโค้ดมันก็เล็กลง ถึงจุดที่ผมสามารถรับผิดชอบมันได้และไม่ต้องให้ใครไปอ่าน Spec ถึงจะเข้าใจมันครับ

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

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

อีกครึ่งหนึ่งของปัญหา

ในอีกสถานการณ์หนึ่ง ผมกำลัง Pair กับเพื่อนร่วมงานผมอยู่กับฟีเจอร์ที่เค้าสร้างด้วย Agent ตัวฟีเจอร์ถูกสร้างมาอย่างละเอียดครอบคลุมทุก edge case ที่ควรจะเป็นไม่มีอะไรขาด

ผมเลยเริ่มถามคำถาม

• อันนี้เราต้องการจริง ๆ เหรอ?
• เคสนี้มันจะเกิดขึ้นจริงไหม?
• ทำให้ง่ายกว่านี้ได้ไหม?
• ใช้ X แทน Y ได้หรือเปล่า?

สังเกตุว่ามันไม่ใช่คำถามที่ยากเลย แต่พอได้ดูโค้ดที่เกิดขึ้น ผมคิดอะไรขึ้นได้อย่างนึงกับวิธีการที่เราอ่านโค้ดกันในตอนนี้

ทุกครั้งที่มีโค้ดถูกผลิตมากขึ้นเกินกว่าจุดที่เราสามารถจะทำความเข้าใจได้ เราจะหยุด Evaluate มันและจะเริ่มปรับโหมดสมองเป็น accept / reject ตัว Agent อาจจะมาปิด gap ของ requirements ได้ทุกๆ branch condition ดูก็รู้ว่าถูกต้อง ในใจเราก็คิดว่า เยี่ยม ดีครับผม เหมาะสมครับ Agent ไม่มีการหยุดคิดเพราะว่าตอนนี้ Input ที่เราต้องตัดสินใจมันมากกว่าเกินกว่าที่สมองเราจะรับได้แล้ว

มันเลยกลับมาที่หลักการง่ายๆ 2 อย่างที่ผมยึดเป็นหลักเวลาทำงานกับโค้ดที่ถูก Agent สร้างขึ้นมา

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

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

แต่ว่า Model มันเก่งขึ้นทุกวันนะ

ผมยอมรับ เพราะมันก็เก่งขึ้นทุกวันจริงๆ วันนึงโค้ดที่มันผลิตออกมาก็จะดีขึ้น แล้วบล็อกนี้ก็จะไม่ต่างอะไรกับคน gen y กำลังบ่นคน gen z แต่เอาจริงๆ มันก็ถูกครึ่งนึง หลายเรื่องที่เราต้องคิดเยอะๆ เวลาเขียนโค้ดเดี๋ยวนี้เราก็คิดน้อยลงแล้วอย่างพวก Syntax หรือ Semantic อันนี้ Agent มันเก่งจริง

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

นั่นแหละครับคือราคาที่เราต้องจ่ายจริงๆ ถ้ายังอยู่กับ Agent เพราะฉะนั้นถามตัวเองดังๆ ตลอดครับว่าเรายังอยู่ได้โดยไม่มีมันมั้ย

สรุป

ตอนที่ผมยังเป็น Junior อยู่ Lead ผมเคยสอนไว้ว่า แม้แต่ ช่องว่างระหว่างบรรทัดก็สามารถเล่าเรื่องราวได้ เพราะว่าสิ่งที่เราเขียน เราเขียนเพื่อให้คนอื่นมาอ่านต่อ แล้วพอมามองในยุคนี้ คำสอนนี้ยิ่งสำคัญมากขึ้นไปอีก เพราะว่าคนอื่นนั้น ไม่ใช่แค่เพื่อนร่วมงาน แต่อาจจะเป็นเราในอีก 6 เดือนข้างหน้า หรือแม้แต่ Agent ที่เราสั่งเพื่อที่จะให้มันแก้บางอย่าง

สุดท้ายแล้ว Spec จะ Obsolete ตัว Context จะเต็ม Session หมดอายุ แต่อะไรก็ตามที่เราเรียนรู้ระหว่างที่ปรับโค้ดจะอยู่กับเราตลอดไปและจะถูกส่งต่อไปยังคนที่มาอ่านต่อถ้าเค้าถามเกี่ยวกับโค้ดนั้น

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

We can solve any problem by introducing an extra level of indirection

Developer หลายๆ คนน่าจะคุ้นเคยกับ Theorem ข้างบนมาบ้างจาก Fundamental theorem of Software Engineering (FTSE) ซึ่งหลายๆ คนก็น่าจะเห็นด้วย เพราะมันฟังดูเข้าใจง่ายมาก แค่เพิ่ม Interface หรือ Wrapper ขึ้นมาแค่นั้น แต่จริงๆ แล้วนี่เป็นความเข้าใจคลาดเคลื่อนไปมาก เพราะส่วนใหญ่ Developer เราจะสับสนระหว่าง Abstraction กับ Indirection ถ้าไม่ระวังให้ดี และไอความสับสนนี่แหละที่ทำให้ code เราเปลี่ยนจาก clean ๆ กลายเป็น Spaghetti ได้เลย

Abstraction vs Indirection

ความเข้าใจผิดมากที่สุดของเรื่องนี้คือ การที่คิดว่าสองสิ่งนี้มันเป็นสิ่งเดียวกัน เรามาลองดูนิยามมันคร่าวๆ ของสองสิ่งนี้กันครับ

• Abstraction is about “What” ตัว Abstraction ทำหน้าที่เป็นสัญญา ที่ซ่อนความซับซ้อน (complexity) ของการทำงานหนึ่งๆ ทุกครั้งที่เราใช้ Interface เป็นการบอกว่า “เราไม่สนนะว่าข้างในมันจะทำงานยังไง ตราบใดที่มันยังทำงานได้ตามกรอบที่เราวางไว้” เรียกว่าเป็นมุมมองแบบ Passive ก็ได้
• Indirection is about “Where” ในส่วนของ Indirection สามารถอธิบายได้ง่ายๆ ว่าเป็นป้ายบอกทางมากกว่า โดยทำหน้าที่เป็นตัวกลาง (middleman) คอยบอกว่าให้เลี้ยวซ้าย เลี้ยวขวานะ ตาม Action ที่ได้รับมา หรือมองในอีกมุมของเป็นการตอบรับแบบ Active ครับ
  อีกจุดหนึ่งที่ทำให้ Indirection แตกต่างจาก Abstraction อย่างชัดเจนคือการต้องมี Registry ครับ ยกตัวอย่างกลับไปที่ Analogy ของป้ายบอกทางก็ได้ ถ้าเราอยู่ที่ 3 แยก มันต้องมีคนมาเขียนป้ายบอกว่า ถ้าเลี้ยวซ้ายไปไหน ถ้าเลี้ยวขวา แล้วจะไปถึงไหน นั่นแหละครับการ Registry ซึ่งนี่เป็นหลักการพื้นฐานไม่ต่างจากการที่เรามี DNS Resolver (เชื่อมระหว่าง Domain -> IP) หรือ built-in Python method อย่าง getattr() (เชื่อม String -> class method)

ทุกอย่างมีราคา

ย้อนกลับไปที่ FTSE ข้างบนครับ จริงๆ แล้วมันไม่จบแค่นั้น มันยังมีครึ่งหลังที่คนไม่ค่อยรู้อยู่ กล่าวไว้โดย David Wheeler ว่า

…except for the problem of too many levels of indirection

ลองจินตนาการภาพตามนะครับ ทุกครั้งที่เราเพิ่มของเข้ามาใน Indirection ตัว Register ที่ทำงานอยู่จะทำงานหนักขึ้นเรื่อยๆ ครับ และเราจะเริ่ม Debug ยากขึ้นเรื่อยๆ เพราะมันไม่ใช่การเรียก function ตรงไปตรงมา แต่เราต้องไปที่ Register ก่อนว่า action นี้หมายถึง function ไหน แล้วค่อยไล่ไปจากตรงนั้น แค่คิดก็ปวดหัวแล้วใช่มั้ยครับ กลับมาที่ Analogy ป้ายบอกทางครับ ตัวอย่างที่ชัดเจนมากก็คือ ห้าแยกลาดพร้าวนี่แหละครับ
เพราะฉะนั้นแล้วเนี่ย กฏข้อสำคัญที่เราควรจะพึงระลึกไว้เสมอคือ เราควรพึ่ง Indirection ก็ต่อเมื่อ Complexity ที่เกิดขึ้นนั้นน้อยกว่า การเรียก Action มันตรงๆ ครับ

เราจะเป็นคนควบคุมมันหรือจะเป็นคนที่ถูกมันควบคุม

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

แต่เอาจริงๆ ผมก็ไม่ได้ตั้งใจว่าจะเก็บเป็น Specialization อะไรหรอกครับ จุดเริ่มต้นของเรื่องราวนี้คือ ผมรู้จัก Joe Reis จากหนังสือ Fundamentals of Data Engineering มาก่อนหน้านี้แล้วกับ Subscribe newsletter ของเค้าด้วย พอช่วงประมาณเดือนสิงหาถ้าผมจำไม่ผิดนะ อาจารย์ Andrew Ng เปิดตัวเว็บ deeplearning.ai ขึ้นมา แล้วผมก็เหลือบไปเห็นคอร์ส Data Engineering ในนั้นมาว่าจะเปิดตัวเร็วๆ นี้ แถมสอนโดย Joe Reis อีก ผมรอจนถึงเวลาเปิดตัวแล้วเค้าก็เลื่อนเปิด จนช่วงปลายๆ เดือนกันยาถึงเปิด ผมก็เริ่มเรียนตั้งแต่วันแรกเลย

อาจารย์ Joe

Course Format

ตัวคอร์สนี้จั่วหัวว่า Specialization สำหรับคนที่ไม่เคยเรียน Coursera ตัว Specialization หมายความว่าจะเป็นชุดคอร์สที่จะประกอบไปด้วยคอร์สย่อยๆ หลายคอร์ส ถ้าเรียนจบครบทุกตัว นอกจากเราจะได้ Certificate ของแต่ละคอร์สแล้ว เราจะได้ตัว Cert Specialization เพิ่มอีกด้วยครับ ซึ่งโดยตัว Specialization เองสามารถมองเป็น Learning Path ได้ด้วย เพราะจากประสบการณ์ผมแต่ละคอร์สที่เรียงมาให้จะ support ความรู้ให้เราต่อยอดใน Course ถัดๆ ไปได้ครับ

ซึ่งใน Specialization นี้จะแบ่งเป็น Course ย่อย 4 คอร์สคือ

ในแต่ละคอร์สย่อยจะใช้เวลาประมาณ 3-4 สัปดาห์แล้วแต่คอร์ส (แต่ส่วนใหญ่ 4 ยกเว้นคอร์ส 3) โดยในแต่ละสัปดาห์นั้น จะแบ่งเป็น Video Lecture ประมาณ 1.30 - 2 hrs ตามมาด้วย Lab Assignments 2-4 ตัว อันนี้แล้วแต่สัปดาห์เลย แล้วปิดท้ายด้วย Weekly Quiz 10 ข้อทุกสัปดาห์ โดยตัว Lab Assignment บางตัวกับ Weekly Quiz จะเป็นตัวตัด Grade ว่าเราจะเรียนผ่านหรือไม่ผ่านในตอนจบแต่ละคอร์สโดยต้องผ่าน 80% ขึ้นไปถึงจะผ่านในหัวข้อนั้นๆ

ด้วยความที่ตัวคอร์สวางตารางเป็นสัปดาห์ให้ทำให้แต่ละอาทิตย์จะมี Deadline ของแต่ละ Assignment, Quiz ที่ต้องเรียนให้จบภายในอาทิตย์นั้น แต่จริงๆ จะเกินก็ได้ แต่ส่วนตัวผมแนะนำว่าให้พยายามเรียนของแต่ละอาทิตย์ให้จบภายในอาทิตย์นั้น เพราะพอมันสะสมไปเรื่อยๆ มันเหนื่อยมากครับ (แค่พยายามเรียนให้จบแต่ละอาทิตย์ก็เหนื่อยละ)

สุดท้ายครับ ถ้าจะได้ Certificate กับทำ Lab ต้อง Subscribe Coursera ด้วยซึ่งอยู่ที่ $49 ต่อเดือนครับ ตั้งแต่เริ่มจนจบคอร์สใช้เวลาประมาณ 3 เดือนหรือ 15 สัปดาห์ ผมแนะนำมากๆ ว่าให้จัดสรรเวลาเรียนกับชีวิตดีๆ ครับเพราะมันกินเวลาประมาณ 3-6 ชม. ต่อสัปดาห์เลย แต่ไม่แนะนำให้เรียนอัดรวดเดียวครับ เพราะเนื้อหามันเยอะจริงๆ แล้วอาจจะไม่ค่อยได้อะไรกลับไป

Who should taking this course

ส่วนตัวผมที่เป็น Role Data Engineer มาเกือบๆ 3 ปีกับประสบการณ์ Software Engineer รวม 10 ปี ผมขอแบ่งคำแนะนำหัวข้อนี้ออกเป็น 2 กลุ่มใหญ่ๆ ละกันครับ

Beginner / Freshly Graduated

สำหรับมือใหม่ Specialization นี้ผมมองว่าเก็บภาพกว้างได้หมด ตั้งแต่ต้นน้ำ ไปจนถึงปลายน้ำในกลุ่มงาน Data Engineering ครับไล่ตั้งแต่เก็บ Business objective แปลงมาเป็น Technical Requirements มาจนถึงการเลือกใช้เทคโนโลยีแต่ละส่วน ไปจนถึงรูปแบบ data model ที่ส่งมอบตัวข้อมูลเพื่อไปใช้ประโยชน์ต่อไปครับ

แต่ด้วยความที่มันไม่ใช่ Lecture นั่งฟังอย่างเดียวแต่มี Lab ด้วยทำให้ได้มีโอกาสได้ลองใช้เทคโนโลยีหลายๆ อย่างเพื่อประกอบเป็น data pipeline ทั้ง Batch, Streaming เพื่อเพิ่มความมั่นใจและความพร้อมในการจะไปทำงานต่อจริงๆ ด้วย

Lab Course นี้สนุกมากครับ

Experienced / Seasoned Engineer

ในส่วนของคนที่มือเปื้อนมาบ้าง ผมว่ามันเป็นการเติมเต็มส่วนที่ขาดมากกว่า เพราะในงานจริงๆ แต่ละบริษัทอาจจะเป็นได้ทั้ง Green field, Brown field แตกต่างกันไป ทำให้โอกาสที่เราจะได้ลอง Tooling / Pattern / Practice ต่างๆ อาจจะไม่ได้ครบทั้งหมดเช่น งานส่วนใหญ่อาจจะทำแต่ Batch processing pipeline ไม่ได้ทำ Streaming pipeline บ่อยๆ หรืออย่างเช่น การทำ Data modeling ให้แต่ละ data user ก็อาจจะตกเป็นงานของ Role อื่นอย่าง Analytic Engineer หรือ Data Analyst แทน ตัวคอร์สนี้เลยเข้ามาเติมเต็มในส่วนที่ขาดหลายๆ ส่วนให้เราได้กลับมารื้อฟื้นปัดฝุ่นความรู้เรา ว่าของพวกนี้ควรจะออกแบบยังไง ส่งมอบยังไงครับ

ต่อไปเป็นรายละเอียดแต่ละคอร์สจากประสบการณ์ผมเองครับ

Course 1: Introduction to Data Engineering

สำหรับคอร์สแรกนี้พอมามองย้อนกลับไป ก็ยังคงใช้คำเดิมว่ามันคือความ Overview และ Definition ครับ เพราะคอร์สแรกจะพาเราไปรู้จักนิยามต่างๆ ของคำที่เกี่ยวข้องใน Data Engineering Field แล้วต่อด้วยพระเอกอย่าง Data Engineering Life Cycle ครับ

ตัว Life Cycle พยายามจะวางกรอบงานและเครื่องมือให้อยู่ในรูปแบบเดียวกัน แต่ก็ยังไม่ละองค์ประกอบที่จำเป็นอื่นๆ ในการทำงานเพราะ Data Engineering ก็เป็น kind of Software Engineering แบบนึง ในส่วนของ Undercurrent เลยเป็นส่วนที่ อาจจะไม่อยู่ในรูป flow หลัก แต่เป็นองค์ประกอบที่ขาดไม่ได้ที่เติมเต็มให้ flow หลักทำงานได้ดี

Data Engineering Lifecycle

ด้วยความที่คอร์สนี้มีความ Partner กับ AWS ด้วย ส่วนหนึ่งของคอร์สแรกคือการ Intro ให้รู้จัก AWS ด้วยครับ ซึ่งพาให้เราไปรู้จักกับ Well-architected Framework ที่เป็นเซ็ตของคำถามให้เราคิดเวลาเราจะ implement อะไรบน Cloud แต่ที่เสริมขึ้นมาด้วยความเป็นคอร์ส Data Engineering คือการแนะนำให้เรารู้จักสิ่งที่เรียกว่า Principles of Good Data Architecture ครับ ส่วนตัวผมชอบ Section นี้มาก เพราะจากประสบการณ์มันคือเรื่องสำคัญแต่ไม่ใช่ Hard work แต่เป็น Soft work ที่ต้องทำคู่ไปด้วยเพื่อจะทำให้งานหลักออกมาดี

Principles of Good Data Architecture

ในส่วนสุดท้ายของคอร์ส 1 จะพาเราไปแมพความรู้ของ Data Engineering Life Cycle กับวิธีคิดของ Data Engineer ออกมาเป็น Requirements ที่เราจะเอาไปทำงานต่อครับ ซึ่งดีมากๆ ใครยังรับงาน Data Engineer แต่ไม่รู้จะเก็บ requirements ออกมาให้เป็นรูป เป็นร่างยังไง ผมแนะนำในส่วนของสัปดาห์ที่ 4 คอร์สนี้เลย

Think like a Data Engineer

Course 2: Source Systems, Data Ingestion, and Pipelines

พอเรารู้จักภาพกว้างในคอร์สแรกแล้ว คอร์สสองตัวนี้จะพาเราไปลงลึกใน 2 ก้อนแรกของ Data Engineering Life Cycle คือ Data Generation, Ingestion แล้วเสริมด้วย Undercurrent ทั้ง Security, DataOps, Orchestration ครับ

ส่วนของ Source System ก็คือ Data ต้นน้ำที่เราต้องไปทำงานด้วยในคอร์สนี้พาไปรู้จักทั้งในแกน Structured, Semi-Structured, Unstructured Data และลงลึกไปแต่ละประเภทอีกทั้ง Database (Relational, NoSQL) ที่เล่าไปจนถึง ACID Compliance หรือประเภทอย่าง Object storage, REST API, Logs เรื่อยมาจนถึง Streaming System

Batch Ingestion Patterns

ส่วนของ Data Integration นี่จะลงใน Pattern ที่จะอยู่ในกรอบของ frequency ไล่ตั้งแต่ Batch, Micro-batch ไปจนถึง Streaming หรือจะมองในมิติ ETL vs ELT ว่ามีข้อดี ข้อเสียต่างกันยังไง แล้วด้วยความที่คอร์สนี้พื้นฐานอยู่บน AWS เราจะได้ใช้ components อย่าง AWS Glue Job, AWS Kinesis ในการทำแล็บ Data Integration ด้วยครับ

ส่วนของ Undercurrent ในมุมของ Security คือพาไปรู้จัก IAM Security กับ AWS Networking ว่าจะ control ยังไงรวมไปถึงหัด debugging ปัญหา ACL ใน AWS ด้วย ส่วนของ DataOps ในส่วนของทฤษฏีจะแบ่งเป็น 3 pillars: Automation, Observability & Monitoring, Incident Response

DataOps Pillars

โดย Automation จะเน้นไปที่การใช้ Terraform มาช่วย Provision component ต่างๆ ใน AWS แบบ Infrastructure as a Code (IaaS) และ Observability & Monitoring จะเน้นไปที่การใช้ Great Expectation มาช่วยทำ Data Quality กับ AWS Cloudwatch ในการทำ Monitoring ครับ

ในส่วนสุดท้ายของคอร์สนี้คือ Data Orchestration / Pipelines จะสรุปง่ายๆ ว่าไปเรียน Airflow ก็ได้ครับ แต่จะลงไปตั้งแต่ Cron, DAGs, และพาไปรู้จักองค์ประกอบของ Airflow server เรื่อยไปจนถึง API ของ Airflow เช่น Operators, XCom, Variables หรือ TaskFlow API

Managed Apache Airflow on AWS

พอมามองย้อนกลับไป Course 2 นี่มันเนื้อหาเยอะจนร้องขอชีวิตจริงๆ แหะ

Course 3: Data Storage and Queries

ถ้าคอร์ส 1 กับคอร์ส 2 คืองานที่เราจะได้ทำจริงๆ เป็นการวางองค์ประกอบให้แต่ะละส่วนประสานงานกัน Course 3 นี่ผมเปรียบว่าเป็นรากฐานที่ทำให้ 1+2 ทำงานได้ครับ โดยในคอร์สนี้จะเน้นไปที่การทำงานและการเลือกใช้ Storage ของ data ที่เราดึงมาจาก Source Systems แล้วครับ

Data Storage System & Abstraction

โดยเนื้อหานี่ไล่ตั้งแต่ Physical storage อย่าง Magnetic Disk, SSD, RAM, CPU Cache ขึ้นมาเป็น Logical storage อย่าง File Hierarchy, Block Storage, Object Storage มาจนชั้น Application storage อย่าง Key-value in-memory, Rows, Columnar, Graph, Vector

พอ components แน่นแล้วก็ยกระดับขึ้นมาเป็น Abstraction อย่าง Data Warehouse, Data Lake, Data Lakehouse ซึ่งไม่ใช่แค่ Abstraction ที่พูดถึง แต่ยังลงไปที่ tooling ที่ช่วยให้มันเกิดขึ้นได้อย่าง MPP (Redshift), Open table format (Iceberg) ด้วยครับ

Data Lakehouse on AWS

และแน่นอนว่าเราจะพูดถึง Application Storage โดยไม่พูดถึง Queries ไม่ได้ครับ ใน ส่วนนี้นั้นเรียกได้ว่าเขียน Queries จนต้องร้องขอชีวิตตั้งแต่ basic อย่าง select, from, where, join, aggregation เรื่อยไปจน advance statement อย่าง SQL Functions, CTEs, condition expression, sub-queries, และ Sliding windows ครับ นอกจากนี้ยังพาเราไปรู้จักกับเทคนิคการ Optimize queries บน database อย่างการ Index บน RDBMS หรือ Sort key บน Columnar DB และปิดท้ายด้วยการเขียน Queries บน Streaming System โดยอาศัย Window pattern หลายๆ แบบครับ

Course 4: Data Modeling, Transformation, and Serving

พอผ่านคอร์ส 1-3 มาเราจะเริ่มมีไอเดีย, เครื่องมือและเทคนิคแล้วว่าจะพา Data จากจุด A → B ยังไง ในส่วนของคอร์ส 4 จะเป็นเรื่องของการวาง Model ของ Data เพื่อให้ Downstream system หรือ Data User เอา Data ไปใช้งานได้ง่ายและเกิดประโยชน์สูงสุดครับ

พาร์ท Data Modeling นี่ส่วนหนึ่งเหมือนกลับไปเรียนวิชา Database สมัยมหาลัยมาก ไล่ตั้งแต่ Normalization (1NF → 3NF), Star Schema แต่ก็เพิ่งรู้ว่าในโลก Data Warehouse เค้าแบ่งกันเป็น 2 ค่ายคือ ค่าย Inmon ที่เน้น Join ทำ 3NF กับค่าย Kimball ที่เน้นการวาง Star Schema ซึ่งในคอร์สนี้ไล่ให้เห็นแต่ละแบบเลยว่ามีข้อดี ข้อเสียยังไงบ้าง นอกจากนี้ยังมีค่ายที่ 3 อย่าง Data Vault ที่แบ่ง Model เป็น Hub, Link, Satellite ด้วย รวมไปถึงเทคนิคที่ง่ายที่สุดอย่าง One Big Table (OBT) ด้วย ซึ่งเราจะได้ฝึกการวาง Data modeling เหล่านี้ผ่านเครื่องมืออย่าง dbt ด้วยครับ

Data Modeling Approaches

ในส่วนของ Data Modeling ยังมีอีกส่วนคือการเตรียม Data ของเราเพื่อสนับสนุนการทำ Feature Engineering ใน ML Project Lifecycle Framework ครับ ทั้งในส่วนที่เป็น Numerical data อย่าง Handling missing, Scaling Numerical, Encoding หรือส่วนของ Text data อย่าง Cleaning, Normalization, Tokenization, Remove stop words, Lemmatization ซึ่งในแล็บได้เขียน Pandas กับ Scikit-learn เตรียม data อย่างเมามันครับ

พอเข้าเนื้อหา Data Transformation จะเป็น Transformation ในส่วนของปลายน้ำมากกว่าตอนที่เราทำ Data Ingestion ครับ โดยจะพูดถึงเทคนิคอย่าง Truncate & Reload, Capture update, Capture delete มีแวะมาเล่าเรื่อง Hadoop ให้เราเข้าใจก่อนจะยกระดับไปถึง Spark แล้วเน้นไปที่การเลือกใช้ระหว่าง Spark UDF, DataFrame API, Spark SQL และ Spark Streaming

Spark DataFrame API

ในส่วนสุดท้ายของคอร์ส Serving จะย้ำเราถึงรูปแบบของการส่งมอบครับว่าจะทำยังไงถึงจะส่งมอบ Data แต่ยัง Compliance กับ Data Management อยู่ ซึ่งแต่ละ Use case ทั้ง Analytics, ML ก็จะมีความต้องการรวมถึงรูปแบบที่แตกต่างกัน เลยต้องเกิดสิ่งที่เรียกว่า Semantic Layer ขึ้นมาขั้นอีกชั้นนึง ซึ่งตัว Semantic Layer นี้จะ Implement ในรูปแบบของ View / Materialize View / Dataset ใน Superset แตกต่างกันไปแต่ละ Use case ครับ

Semantic layer

ตัวคอร์ส 4 จะจบด้วย Capstone project ครับ เป็นเหมือนการทวนเราอีกรอบให้เราใช้ความรู้ตั้งแต่ต้นน้ำการเก็บ requirements เลือกเทคโนโลยีทำ data pipeline โดย Ingest และทำ Data Quality check ผ่าน component บน AWS อย่าง Glue, transforms เป็น Star Schema ผ่าน dbt แล้ว Serving ด้วย Superset โดยทั้งหมดถูก Orchestrate ผ่าน Airflow

Capstone Lab

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

จบครบ 4 Course ได้ Certificate Specialization มาเท่ๆ อีกใบ

ต้องย้อนไปว่าปีนี้ผมกลับมาวิ่งแล้วครับ หลังจากหยุดวิ่งจริงจังไปหลายปีมากๆ แล้วผมจะมีความคาใจอยู่นานตั้งแต่สมัยวิ่งไปถึง Half Marathon แล้วว่าผมไม่สามารถวิ่งยาวๆ จนจบได้เลย แต่เป็นวิ่งสลับเดินมาตลอด ถึงแม้จะพยายามเก็บระยะ จะพยายามซ้อมตามตารางแล้วก็เถอะ

จนกลับมาวิ่งรอบนี้ผมตั้งเป้าหมายง่ายมาก (น่าจะง่ายแหละ) คือขอแค่วิ่งยาวๆ จบ ไม่ต้องหยุดเดินตามระยะที่ต้องการได้ก็พอ ทีนี้พอเข้าโปรแกรมซ้อมกับนาฬิกา สิ่งที่ค้นพบหลังจากผ่านไปไม่กี่สัปดาห์คือ ผมกลับมา Loop เดิมคือยังวิ่งตามโปรแกรมซ้อมจนจบไม่ได้ Pace ลั่น จนหมดแรงแล้วก็เดินอีกแล้ว จนเริ่มเรียนรู้ที่จะคุม Pace ให้เป็นซึ่งเป็นจุดเปลี่ยนมาก เพราะผมเริ่มวิ่งได้ไกล ได้นานขึ้นเรื่อยๆ แล้วพัฒนาการมันเพิ่มขึ้นแบบรู้สึกได้

แต่พอผ่านไปได้ประมาณ 3/4 ของโปรแกรมมันก็ถึงจุดที่ผมกลับมาคาใจอีก ผมเริ่มที่จะรู้สึกว่า Hit-the-wall เหมือนมีกำแพงที่ข้ามไปไม่ได้คือไป Pace ที่ต้องการไม่ได้ซักที อีกจุดที่คาใจคือ เริ่มรู้สึกว่านาฬิกามันโชว์ Heart Rate Zone แปลกๆ เวลาวิ่งคือไป Zone 3-4 ทั้งๆ ที่ผมรู้สึกว่าเอะ มันก็ยังไม่เหนื่อยนี่หว่า แต่บางวัน Zone 4 ก็เหนื่อยมากๆ เลยรู้สึกว่ามันมีอะไรผิดปกติละ

จังหวะนั้นคือเริ่มมองหาตัวช่วยละ เลยไปเจอใน The Running Channel ว่ามันมีตรวจอะไรแบบนี้ด้วย หลังจากนั้นก็เริ่มหาข้อมูลเลยมาเจอของไทยมีหลายที่เลย แต่ผมเจอของ Health Performance Team กับคุณหมอแอร์ที่เป็นนักกีฬาด้วย เลยตัดสินใจนัดเลย

การนัดหมายกับการเตรียมตัว

อย่างแรกคือการนัดหมายคือทักไปในเพจ Health Performance Team เลยครับ แล้วเดี๋ยวมีเจ้าหน้าที่ติดต่อกลับมา จริงๆ มีหลายโปรแกรมตรวจให้เลือกด้วย แต่ผมเลือกเป็น VO2 Max เลยเพื่อมาตอบคำถามที่คาใจตัวเองอยู่

หลังจากนัดหมายเสร็จก่อนวันตรวจจริงมีเจ้าหน้าที่โทรมายืนยันนัดหมายอีกที แล้วก็บอกให้เตรียมตัวเช่น งดออกกำลังกายหนัก นอนอย่างน้อย 8 ชม. งดอาหารอย่างน้อย 4 ชม. แล้วก็เตรียมชุดกีฬากับรองเท้ากีฬามาเปลี่ยนด้วย

การทดสอบ

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

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

อย่างที่สองคือติดเหมือนตัววัดคลื่นหัวใจ ซึ่งติดไว้หลายจุดหลายมุมมาก 10 กว่าจุด รวมถึงสายวัด Heart rate ที่หน้าอกด้วย ณ จุดนี้คือตรงหน้าท้องไปจนถึงหน้าอก เต็มไปด้วยอุปกรณ์พะรุงพะรังเต็มไปหมด ถึงจุดนี้คือเริ่มกังวลละว่าจะวิ่งได้ปะวะ ของห้อยเยอะขนาดนี้ พอทุกอย่างเรียบร้อยก็ถึงขึ้นสายพานครับ ซึ่งคุณนักวิทยาศาสตร์การกีฬาก็มาอธิบายวิธีการทดสอบเพิ่ม ว่าสายพานจะเร็วขึ้นเรื่อยๆ แล้วให้เรายกมือบอกระดับความเหนื่อยของเรา ที่เพิ่มขึ้นเรื่อยๆ หลังจากนั้นก็ถึงเวลาทดสอบจริง

ขั้นแรกของการทดสอบคือ ยืนนิ่งๆ 90 วิครับ หลังจากนั้นลู่วิ่งจะเริ่มเคลื่อนตั้งแต่ช้าๆ แล้วเร็วขึ้นเรื่อยๆ ระหว่างนั้นคุณนักวิทย์ก็จะถามเรื่อยๆ ว่าระดับความเหนื่อยถึงไหนแล้วเช่น ถ้าถึงระดับ 5 แล้วยกมือบอกครับ ซึ่งช่วงแรกๆ มันก็ช้ามากๆ แต่ความเข้มข้นมันเริ่มตอนที่มันเร็วพอที่เราจะต้องก้าววิ่งนี่แหละครับ จังหวะนั้นคือค่อยๆ ไล่ไปเรื่อยๆ 6 7 8 จากที่เคยหายใจแค่จมูกก็เริ่มใช้ปากช่วย จากตอนแรกที่รู้สึกว่าวิ่งได้เรื่อยๆ เริ่มวิ่งเซไปทางขวาของลู่เรื่อยๆ จนทุกคนต้องคอยบอกให้กลับมาทางซ้าย พอถึงระดับ 8 ใกล้ๆ 9 ตอนนั้นคือหายใจถี่มากๆ หายใจดังมากๆ ได้ยินคุณหมอถาม กต ว่าปกติผมหายใจแรงแบบนี้มั้ย เป็นหอบหืดมั้ย แต่ตอนนั้นคือหายใจจะไม่ทันละ เลยถึงจุดที่พอละก็ยกมือบอก คุณนักวิทย์ฯ ก็ช่วยนับถอยหลังให้ หลังจากนั้นลู่วิ่งก็ค่อยๆ ลดความเร็วลงเรื่อยๆ จนหยุด ใช้เวลาประมาณ 15 นาทีครับตั้งแต่เริ่มยืนจนถึงหยุด

ผลการทดสอบ

หลังจากหายเหนื่อยถอดอุปกรณ์เรียบร้อยแล้ว คุณนักวิทย์ก็จะมาสรุปผลการทดสอบให้เลย ในส่วนนี้ขอแบ่งเป็น 4 Section ย่อยๆ

Performance Analysis

ส่วนนี้คุณนักวิทย์ของเราพาเราแปลผลจากกราฟ 9 Plots ซึ่งเยอะมาก แต่ช่วยให้เราเห็น Trending แต่ละ Aspect เลย ซึ่งสุดท้ายแล้วสรุปหลักๆ ออกมาเป็น 3 เรื่อง

• VO2 Max — ตัวนี้ผลออกมาวันนี้ต่ำกว่าเกณฑ์คนทั่วไปที่อายุเท่ากันอยู่ แต่ข้อสังเกตุอีกอย่างของผมเองคือ ค่ามันต่ำกว่าค่าที่อ่านได้จากนาฬิกาแหะ
• Oxygen Pulse — ค่าบีบตัวของหัวใจสูงสุดวันนี้ก็ยังต่ำกว่าเกณฑ์คนทั่วไปที่อายุเท่ากัน เหมือนกัน แต่คุณนักวิทย์อธิบายเพิ่มว่า ถ้าดูในเชิง Performance ยังยอดเยี่ยมอยู่เพราะ Heart Rate กับการบีบของหัวใจทำงานต่อเนื่องสัมพันธ์กันไปอยู่ตั้งแต่ต้นจนจบการทดสอบ
• Lung Function — ประสิทธิภาพของปอดต่ำกว่าเกณฑ์คนทั่วไปที่อายุเท่ากันอยู่ แต่ช่วงความเหนื่อยสูงสุดยังมีช่วงที่ปอดยังไม่ได้ใช้งานอยู่เยอะระดับนึงเลย แปลว่ายังมีช่องว่างที่พัฒนาต่อไปได้อีก

Exercise Program Based on VO2 Max test

ส่วนนี้คุณนักวิทย์ของเราจะช่วงวางโปรแกรมออกกำลังกายให้จากค่าหัวใจกับความเร็วที่ได้จากการทดสอบโดยแบ่งเป็น

• Session 1: Base Aerobic
• Session 2: Anaerobic threshold (Tempo) Interval (1000m x 4)
• Session 3: HIIT at 100% VO2 Max (ลงคอร์ทหรือ Treadmill)
• Session 4: Fat Burn Zone

ซึ่งแต่ละ Session เราจะได้ทั้งตัวเลขความเร็วที่เป็น Pace (min/km) และความเร็วบน Treadmill (km/hr) ให้เราเอาไปใช้ต่อได้ครับ

Goal Race Pace

อย่างที่เกริ่นไปตอนแรกว่า Goal ผมตอนนี้คือ จบ 10K ได้แบบวิ่งยาวๆ ไม่เดินเลย คุณนักวิทย์เลยช่วยคำนวนให้ได้ค่า Pace ที่เหมาะสมให้ ซึ่งเป็นจุดที่ใช้พลังงานจาก ไขมัน 70% และจากคาร์บ 30% อันนี้หลังจากได้ผลเอามาเทียบกับค่า VDOT กับ Race Estimator ที่เคยคำนวนได้คือใกล้เคียงมากๆ (อาจจะช้ากว่านิดหน่อยหลักหน่วยวินาที)

Heart Rate Zone

ค่านี้คือค่าที่ผมมาตามหาครับ ซึ่งก็แบ่งเป็น 5 Zone อย่างที่เราเข้าใจเลย

• Zone 5 (Top)
• Zone 4 (Development)
• Zone 3 (Intensive Endurance)
• Zone 2 (Extensive Endurance)
• Zone 1 (Compensation)

ซึ่งคุณนักวิทย์เราแนะนำว่า ของวันนี้ที่ทดสอบอยู่ใน Control environment เป็นห้องแอร์ ถ้าออกไปวิ่งข้างนอกอากาศร้อน ให้บวกไปประมาณ 7 bpm ทุก Zone กำลังดี ซึ่งผมเอามาเทียบกับ Zone ที่นาฬิกาคำนวนให้ Based On %Max. HR นี่คือคนละเรื่องกันเลย จะมีส่วนที่เป็น %HRR ที่ดูใกล้เคียงไปทางเดียวกันหน่อย แต่ก็ยังไม่ตรงกันอยู่ดี

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

ในส่วนของคุณหมอแอร์สรุปผลให้ ผมขอแบ่งเป็น 3 Section ย่อยๆ ครับ

Running Form Analysis

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

อาการเท้าล้ม (Over Pronation)

ในเคสนี้ผมรอดไปครับ หมอบอกว่าลงน้ำหนักได้ดีทั้งสองข้างแบบ Neutral ไม่บิดเข้าบิดออกเลย

ความสมดุลของกล้ามเนื้อทั้งสองข้าง

เคสนี้หมอจะดูจากอาการขาไขว้ (Cross Running) ครับ ซึ่งผมมีปัญหา ขาขวามีอาการไขว้เป็นพักๆ ซึ่งมีมัดกล้ามเนื้อที่มีปัญหาคือ Gluteus Medius, Gluteus Maximus ที่ทำให้เกิดอาการ Hip Drop วิ่งแล้วสะโพกตก

ในส่วนของการนี้คุณหมอแนะนำว่าให้ไป Weight Training เลย ซึ่งผมไม่ได้เล่น Weight มาหลายปีมากตั้งแต่เปลี่ยน Trainer หลายปีที่แล้ว ซึ่งหมอก็ให้โปรแกรมมาแก้เรื่องนี้คือ

• Squats เพื่อแก้ Gluteus Maximus หมอย้ำมากว่าต้องลงลึกๆ ตั้งฉาก 90 องศาเลย
• Abduction เพื่อแก้ Gluteus Medius แต่ต้องเล่นน้ำหนักเบามากๆ หรือจะใช้ยางยืดเปิดสะโพกแทนเอาก็ได้

และอย่างที่หมอแนะนำคือ ยังไงก็ต้องกลับมาพัฒนา Core body จะ Isometric Plank หรืออะไรก็ได้

ฟอร์มการวิ่งด้านข้าง

จุดนี้เหมือนคุณหมอจะโฟกัสการลงน้ำหนักกับการยกเข่า แล้วหมอชมว่า ถือว่าเป็นคนน้ำหนักเยอะ แต่วิ่งดีนะ ท่าวิ่งนี้สวยเลย มีการเทน้ำหนักไปข้างหน้า วงสวย ดีดส้นดี ไม่ Overstride แทงเข่าได้ไกลใช้ Hip Flexor เป็น ถ้าเทียบน้ำหนักตอนนี้วิ่งได้ขนาดนี้ ถ้าตัวลีนแล้วจะวิ่งได้เร็วและแรงมาก… หมอชมมาขนาดนี้ ผมก็ลอยสิครับ 555

ในส่วนของการลงน้ำหนัก ยังลงที่ส้นอยู่ แต่ไล่เท้าได้เร็วมากจนเกือบๆ จะเป็น Mid Foot Strike แล้ว ซึ่งก็ไม่น่าต้องปรับอะไรแล้วเพราะไม่มีความเสี่ยงในการบาดเจ็บจากการลงน้ำหนักเลย

ตัว Core body อาจจะต้องดูว่าถ้าวิ่งนานๆ จะมีโยกหรือเปล่า ส่วนการแกว่งแขนนี่ใช้ได้แล้ว เป็นการแกว่งจาก Shoulder Joint แค่ระวังอย่าให้ Cross mid-line ก็พอ

Health Analysis

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

Life Plan Summary

ถึงจุดนี้เหมือน คุณหมอวางแผนชีวิตให้เลย ซึ่งคุณหมอก็วางให้สัมพันธ์กับ Goal ที่บอกไปก่อนหน้านี้แบ่งเป็น 3 แกนหลักๆ

ออกกำลังกาย

ไม่ต้องโฟกัสมากว่าต้อง Zone 2 แต่คือซ้อมไปปกติ ตามที่วางแผนมาให้เลย แต่ถ้ารู้สึกว่าที่เทสมาวันนี้มันเบาไปก็เอาตามความรู้สึกเลยก็ได้ แล้วเสริมด้วย Strength training ด้วย

อีกส่วนที่เป็น Optional คือ NEAT (non-exercise activity thermogenesis) พูดให้เข้าใจง่ายๆ คือการขยับตัวระหว่างวัน เพราะบอกหมอไปว่าผมเป็นโปรแกรมเมอร์ครับ ถ้าใช้โต๊ะยืนได้จะดีมาก แต่ถ้าไม่ได้จริงๆ ก็ตั้งเวลาไว้แล้วออกไปขยับร่างกายบ่อยๆ

การกิน

ส่วนนี้หมอแนะนำให้ไปเรียนรู้การแยกความรู้สึกของความหิว ความอิ่มดีๆ แล้วพยายามกินอยู่ที่ 80% ของความอิ่ม ถ้าจะ cut ให้เริ่มที่ Carb แต่ห้ามลดโปรตีนเด็ดขาด

การนอน

อันนี้ไม่ต้องทำอะไร เพราะนอนได้ดีอยู่แล้ว

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

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

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

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

ผมเป็นชาว Chemical Guys

หลังจากนั้นก็เป็นช่วงเวลาที่ผมเริ่มศึกษาครับ ซึ่งผมเคยเล่าไปแล้วบางส่วนในบล็อก มือสมัครเล่นเมธอด ถ้าใครยังไม่ได้อ่านก็ลองไปดูได้ ในช่วงแรกๆ ผมมีเพื่อนอยู่ 2 คนครับที่ทำให้ผมรู้จักวิธีการล้างรถที่ถูกต้องสองคนนั้นชื่อว่า Joey กับ Henry จากช่อง Chemical Guys ครับ

เพื่อนโจอี้ เพื่อนเฮนรี่

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

ผมยึดวิธีการล้างตามคลิปนี้เป็นพื้นฐานมาจนถึงทุกวันนี้ครับ ไม่ว่าจะเป็น Wheel first, 2 Buckets Method, Pre-rinse, Top to Bottom ฯลฯ สิ่งที่ผมเห็นในคลิปนี้ไม่ใช่แค่ Process ครับแต่มันเป็น Practices ซึ่งตอนนี้พอมามองย้อนจริงๆ มันเหมือนการเขียนโปรแกรมที่เรามักจะมีคำพูดว่า “เขียนโปรแกรมได้ กับเขียนโปรแกรมเป็น”

ขยายความอีกนิดที่ผมบอกว่ามันเหมือนกับการเขียนโปรแกรมคือ ตอนเราเขียนโปรแกรมเนี่ย ถ้าเรามีปัญหา A→B ถ้าคิดแบบง่ายที่สุดคือเราต้อง do whatever it take ที่จะแก้ปัญหาเพื่อให้โปรแกรมได้ผลลัพธ์จาก input ไปเป็น output แบบที่เราต้องการใช่มั้ยครับ แต่ถ้าเรามีประสบการณ์มากขึ้นใช่ครับ มันไม่ใช่แค่จาก A→B สิ่งที่เวลาเราเขียนโปรแกรมมอง เราต้องมองว่า Code มัน Maintain ได้มั้ย, Design Principle ได้มั้ย, Performance ได้มั้ย, Testable มั้ย ซึ่งถ้าเราไม่ระวังเนี่ย Side effect ที่จะเกิดขึ้นก็คือ Technical dept ครับและยิ่งทำให้การเขียนโปรแกรมครั้งต่อๆ ไปที่ต้องยุ่งกับจุดนี้ยากขึ้นเรื่อยๆ

กลับมาที่การล้างรถ ไอการล้างรถเนี่ยถ้าเปื้อนดินมา แค่เอาน้ำฉีดมันก็ (ดู) สะอาดครับ มัน (ดู) สะอาดตอนฉีดน้ำเสร็จนั่นแหละ แต่พอเราปล่อยทิ้งไว้ คราบน้ำก็จะมาละ แล้วพอเรามองดูดีๆ คราบหลายอย่างมันก็ยังอยู่ครับ เราก็เลยต้องมี Practices หลายๆ อย่างเกิดขึ้นมาเพื่อที่จะให้เราได้ผลลัพธ์ที่ดีที่สุดและเกิด Side effect น้อยที่สุดครับ ยกตัวอย่างเช่น ทำไมถึงต้องล้างจากบนลงล่าง เพราะว่าน้ำมันไหลจากบนลงล่างนั่นก็เหตุผลหนึ่ง แต่ที่สำคัญคือ ส่วนบนของรถจะสกปรกน้อยกว่าด้านล่างครับ และสิ่งสุดท้ายที่เราต้องการให้เกิดคือการ cross contaminate คราบดินโคลนหรือผงเบรคจากข้างล่าง ขึ้นไปข้างบน หรืออีกตัวอย่างนึง ทำไมถึงต้อง 2 buckets method เพราะเราหลีกเลี่ยง Side effect ที่เราไม่ต้องการที่สุดคือ Scratch & Swirl หรือรอยขนแมวให้ได้มากที่สุดครับโดยการหมั่นล้าง Wash mitt เราบ่อยๆ ระหว่าง Contact Wash ซึ่งถ้าเราไม่ป้องกันไว้แต่เนิ่นๆ รอยขนแมวพวกนี้ก็จะสมเป็น Technical debt ต่อไปให้รถเราไม่เงา หรือแม้กระทั่งตัวอย่างสุดท้ายว่า ทำไมล้างเสร็จเราต้องลง Wax/Sealant ด้วย ก็เพื่อที่จะปกป้องผิวรถให้คราบสกปรกมันติดยากขึ้น ทำให้การล้างครั้งต่อๆ ไปง่ายขึ้น เหมือนกับที่เราเพิ่ม Unit tests ไว้เพื่อให้โค้ดมัน maintain ง่ายขึ้นกับการต่อเติมในอนาคตครับ

จากตัวอย่างจะเห็นว่านี่แหละครับ มันไม่ใช่แค่ Process A→B แต่ในนั้นถ้าเรามองดีๆ มันมี Practices หรือ Art หลายๆ อย่างที่ช่วยให้เราได้ผลลัพธ์ที่ดีขึ้นด้วยครับ

โลกนี้ไม่ได้มีแค่ Chemical Guys

พอผ่านช่วงสามเดือนแรก ก็เป็นช่วงที่เริ่มขยายจักรวาลไป Youtube channel อื่นๆ แล้วไม่ว่าจะเป็น Vermijl Car Detail, Pan the organizer, The Rag Company, Proper Care หรือจะเป็น Channel คนไทยอย่าง O2CARS แม้กระทั่งกลุ่ม Facebook: TWCC : Thai Washer Car Club ก็เป็นแหล่งความรู้ให้ผมเยอะมากครับ จนเริ่มบอกไม่ถูกว่า รู้อะไรมาจากที่ไหน แต่สิ่งสำคัญที่ได้มายิ่งกว่าความรู้คือการโดนป้ายยาครับ ซึ่งพอเรา Expose ตัวเองมาเกินกว่า 1 Brand ก็จะเริ่มมีความอยากลองนั่น ลองนี่เต็มไปหมด เห็นคนอื่นเค้ามี Water Beading ก็อยากลอง Wax ตัวนั้นบ้าง Sealant ตัวนี้ก็ดี

เอาจริงๆ ต้องขอบคุณคุณแฟนอย่าง กต มากๆ ที่ห้ามไว้ว่าให้ใช้ของที่มีให้หมดก่อน โดยเฉพาะ Wax/Sealant อย่าง Butter Wet Wax หรือ JetSeal ถึงแม้จะเติมใส่รถเรื่อยๆ ในช่วงแรกๆ พยายามใช้หนักมาก แต่นี่ยังเหลืออีกเกินครึ่งขวด จนกระทั่งเข้าหน้าฝนแบบจริงจัง ตกวันเว้นวันนี่แหละถึงเริ่มเปิดจักรวาลมากขึ้น

Water Beading ที่เราตามหา

อย่างแรกที่เริ่มเปิดหลังจากออกมาจากโลกของ Chemical Guys คือ P&S Bead Maker ครับ อยากสัมผัสคำว่า Water Beading ที่ราคาถูกที่สุด แต่ยังคงมาตรฐานสากลอยู่ แล้วก็ไม่ผิดหวังเลย เพราะลุยฝนในช่วงนั้นนี่น้ำเป็นหยดกลมสวยงามมาก ผิดกับ JetSeal ที่เป็น Sheeting มาตลอด

อย่างที่สองคือน้ำยาเคลือบกระจกครับ จริงๆ ดูไว้หลายเจ้ามากทั้ง RainX, CarPro FlybyForte หรือแม้กระทั่ง Chemical guys HydroView แต่สุดท้ายก็มาจบที่ Glaco ทั้งระบบตั้งแต่เตรียมผิวกระจก Compound, เคลือบด้วย Ultra Glaco, Maintain ด้วย Glaco De Cleaner ซึ่งทำให้ผมได้สัมผัสกับหยดน้ำไหลผ่านกระจกไปแบบน่ารักมาก แล้วไม่เคยเห็นน้ำเป็นแผ่นในกระจกอีกเลย

ที่มาที่สุดท้ายเลือก Glaco มาจากคลิปนี้ครับ

แต่สิ่งที่มันคาใจอยู่นานมาก ช่วง 6 เดือนนั้นคือ ถึงแม้เราจะมีกระบอกฉีดโฟมที่ดีที่สุดในโลกอย่าง MJJC Foam Canon Pro แต่ก็ไม่สามารถสร้าง Foam หนาๆ ได้แบบที่ตั้งใจ จนสุดท้ายต้องอัพเกรดเครื่องฉีดน้ำไปใช้ตัวแรงอย่าง Flow Energy M9 130 bar จากตัวเก่า Bosch Aquatek 100 bar ซึ่งเป็นการอัพเกรดที่คุ้มค่ามาก นอกจากจะได้โฟมหนาแบบที่ต้องการแล้ว ยังเสียงเบาลงนิดนึงด้วยถ้าเทียบกับตัวเดิมๆ

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

เข้าสู่โลกของ Rinseless

ถึงจุดนี้น่าจะเริ่มเห็นแล้วใช่มั้ยครับว่า มันไม่ใช่แค่ Practice ละ มันเป็นอุปกรณ์เต็มบ้านละที่ทำให้งานมีประสิทธิภาพซึ่งถามว่ามันดีมั้ย มันก็ดีแหละ แต่ก็เป็นช่วงเดียวกันที่ผมเริ่มจะ Realize ว่ากว่าจะล้างได้แต่ละทีนี่ เสีย Overhead เตรียมของเกือบชั่วโมง ล้างอีก 2 ชั่วโมง ซึ่งมันใช้เวลานานมากๆ แล้วคือ ล้างเสร็จผลลัพธ์ถึงจะพอใจมา แต่ก็หมดแรงมากๆ เช่นกัน นี่ยังไม่พูดถึงตอนเก็บของที่ล้างมาเหนื่อยๆ ต้องเก็บอุปกรณ์ทั้งหมดอีก ช่วงนี้แหละครับที่ทำให้ผมค้นพบอาจารย์คนใหม่ผม คนนั้นมีชื่อว่า Yvan Lacroix ครับ

อาจารย์ไอแวน

จริงๆ ต้องย้อนไปช่วงหน้าฝนหนักๆ เนี่ย ผมเริ่มมองหาวิธีที่จะล้างรถได้เร็วๆ เพราะแปปๆ ฝนก็ตก แต่เราอยากให้รถสะอาดตลอด ช่วงแรกๆ คือไปทาง Quick Detailer แต่ตัว Quick detailer เองก็ไม่สามารถจะ Lift คราบไคลที่เกิดจากน้ำผสมฝุ่นแห้งติดรถได้มากครับ ผมเลยมองไปที่ตัวเลือกที่สองคือ Waterless ที่เป็นอารมณ์ประมาณ Spray ฉีดแล้วเช็ดที่ Emulsify คราบขึ้นมาได้ดีกว่า แต่ส่วนตัวผมก็ยังไม่ชอบ Waterless มากเพราะรู้สึกว่ามันทิ้งคราบน้ำยาไว้หลังจากเช็ดระดับนึงอยู่ ถึงจะพยายาม Buff ออกแล้ว แล้วก็เปลืองด้วยครับ ล้างรอบคันด้วย Waterless เนี่ยแทบจะหมดไป 1/5 ของขวด 16oz ละ นั่นเป็นจุดที่ทำให้ผมมาเจอสิ่งที่เรียกว่า Rinseless Wash ครับ

ต้องบอกว่าตอนแรกๆ ที่ผมลอง Rinseless Wash กับ ONR เนี่ย ผมไม่ประทับใจเลยครับ เอาตั้งแต่การ Mix น้ำยาตอนแรกที่อัตรส่วน 1:256 ซึ่งมันไม่ใช่อะไรที่จำได้ง่ายๆ ในตอนแรก ทำให้เราก็ไม่มั่นใจว่าน้ำยาได้อัตราส่วนที่ต้องการรึเปล่า เพราะผสมเสร็จมันไม่ได้ลื่นๆ เหมือนสบู่เลยครับ รู้สึกแทบไม่ต่างจากน้ำเปล่าเลยไม่รู้ว่ามันจะลื่นพอที่จะทำ Contact wash โดยไม่เกิด Scratch ได้มั้ย และถึงแม้จะผลัดๆ ใช้ผ้าหลายๆ ผืนแล้ว แต่รู้สึกว่าคราบไคล มันไม่ค่อยออกเท่าไร สุดท้ายก็มาล้างใหญ่จัดเต็มระบบ Foam Canon อยู่ดีถึงรู้สึกว่าสะอาดกว่าแล้วผมก็ลืม Rinseless ไปเลย

Rinseless ครั้งแรกสุด

ผ่านมาหลายเดือนจนผมกลับมาอีกครั้ง แล้วมารีวิวว่าตัวเองพลาดอะไรไป (วิธีเดิมครับ ผมดูทุกคลิปใน Youtube ที่เจอจากการ Search ว่า Rinseless Wash) ทำให้ผมเจอว่าสิ่งที่ผมพลาดไปมากๆ ในครั้งที่ผมไม่ประทับใจคือ ผมไปใช้ Foam Sprayer ทำ Pre-rinse ครับ เลยทำให้ตัวน้ำยามันไม่ได้กระจายตัวไป Emulsify คราบเท่าที่ควร พอรอบนี้กลับมาใช้หัว Spray ธรรมดาๆ นี่แหละ กลายเป็นการ Emulsify คราบทำได้ดีกว่ามากๆ อีกอย่างที่ผมพลาดไปคือผ้ายังไม่หมาดพอครับ ทำให้พอมันชุ่มๆ เนี่ยมันดึงคราบติดออกมาได้น้อยกว่าตอนผ้าหมาดมากๆ (Yvain จะใช้คำว่า On the verge of dripping) เลยทำให้รู้สึกว่าล้างไม่สะอาดเลยในตอนก่อนหน้านี้

พอรู้จุดที่พลาดก็ลอง Practice ครับ ซึ่งผลลัพธ์มันก็ดีขึ้นมากครับเพราะพอปล่อยให้ Pre-rinse มันอยู่กับผิวนานขึ้น มันยิ่ง Emulsify คราบขึ้นมากับน้ำยา พอเช็ดแล้วเห็นน้ำเป็นสีขุ่นๆ นี่คือรู้เลยว่าเวิร์คละ ยิ่งพอเริ่ม Standardize practice ใช้ถ้วยตวงกับขวดน้ำลิตรช่วยเป็น 1 ฝาตวงน้ำยาต่อน้ำเปล่า 4 ขวดลิตรการเตรียมก็ยุ่งยากน้อยลงไปอีก กลายเป็นนี่เป็นวิธีหลักที่ผมใช้ล้างรถตอนนี้เลยครับ สามารถจบงานได้ในเวลาไม่ถึงชั่วโมงนับตั้งแต่ เตรียมน้ำยาไปจนถึงเช็ดแห้ง ข้อเสียเดียวที่คิดออกตอนนี้คือพอมาใช้ Spray ธรรมดานี่เมื่อยมือมากครับ ซึ่งมันก็มีวิธีแก้ (ด้วยเงิน) แหละ แต่ตอนนี้อยาก Keep It Simple Stupid ก่อนเพื่อที่จะได้ keep momentum ของการดูแลรถต่อไป ทุกที่ ทุกเวลา

สภาพปัจจุบัน

หลังจากเล่ามาทั้งหมด น่าจะเห็นแล้วใช่มั้ยครับว่าการล้างรถเนี่ย มันไม่ได้มีแค่ล้างรถ มันมี Practices ที่พัฒนาขึ้นทุกยุค มันมี Process ที่เราสามารถพัฒนาให้มีประสิทธิภาพได้ มันมี Reward ที่ให้เราได้มองดูรถเราที่มันสะอาดในทุกๆ วันและที่สำคัญที่สุด มันมีอะไรให้ผมเรียนรู้ได้เรื่อยๆ ไม่หยุดเลยครับตลอดหลายเดือนที่ผ่านมา

และสำหรับใครที่อ่านมาจนถึงจุดนี้แล้วรู้สึกว่า ผมพูดอะไรฟะ มีแต่ศัพท์เฉพาะก็ไม่ต้องตกใจไปครับ เพราะมีเรื่องระหว่างทางที่ผมไม่ได้อธิบายหลายอย่างมากทั้ง Practice ระหว่างล้าง Technology ที่พัฒนาขึ้นมาตลอดหลายปี ฯลฯ ซึ่งบล็อกเกี่ยวกับการล้างรถแบบ Detailing ผมไม่ได้จบแค่นี้แน่นอนครับ บอกไว้ล่วงหน้าเลยว่าจะมีอีก 3 บล็อกตามมาหลังจากนี้คือ

• Full scale wash, clay and seal — จะลงรายละเอียดเครื่องมือ, สารเคมี, Practices และ Process ในการล้างแบบเต็มระบบครับ
• Interior detailing — จะเห็นว่าผมไม่ได้เล่าเรื่องการทำความสะอาดภายในเลย เพราะว่าอันนี้เป็นอีกศาสตร์นึงเลย คิดว่าจะมาลงรายละเอียดในบล็อกนี้
• Rinseless wash — จะเหมือนบล็อก Full scale เลยครบ แต่เป็นอีก Paradigm ที่ผมตกหลุมรักมันอยู่ตอนนี้

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

💡 TL;DR How I utilize Notion for everyday work

จะนับว่าบล็อกนี้เป็นภาคต่อ ของต่อของต่อของซีรีย์บล็อกที่ผมเล่าว่าใช้ Bullet Journaling ยังไงมาตลอดหลายปีก็ได้ แล้วผมใช้ System นี้มาตั้งแต่ประมาณช่วงปลายปี 2021 จนถึงปัจจุบัน ถึงแม้มันจะมีการปรับเปลี่ยนรูปมาเรื่อยๆ แต่มันก็ได้พิสูจน์แล้วว่า มันช่วยผมจำและทำงานได้ดีมาตลอดหลายปีที่ผ่านมา และแม้กระทั่งบล็อกนี้เองก็เขียนอยู่บน Notion เป็น First draft เช่นกัน

First Version

ต้องบอกก่อนว่าก่อนหน้าจะมาอยู่บนนี้เป็นยุคที่ผม Hybrid อยู่บน Notion + Physical Notebook มาก่อน แต่ปัญหาหลักที่เจอคือ พอมันต้องแยกสองโลก ชีวิตจะเริ่มหาของยากขึ้นเรื่อยๆ ถึงแม้ผมจะเคยเชื่อว่าเราควรจะอยู่ในโลก Physical แต่ด้วยธรรมชาติของงาน Software ต้องอยู่บนคอมพิวเตอร์เกือบตลอด ต้องเก็บลิ้งค์หรือ Code snippet มันเลยทำให้ไม่สามารถไปใช้สมุดได้เต็มตัว จนถึงจุดนึงผมยอมแพ้แล้วย้ายกระบวนการในสมุดมาอยู่ใน Notion ทั้งหมด

ด้วยความที่ทีมที่ผมทำงานด้วยยังอยู่บนรอบ Sprint เพราะฉะนั้นการแบ่ง Section หลักๆ จะยังเป็น Sprint based อยู่ แต่จะมี Highlight ว่าวันไหนเป็นวันหยุดด้วยการเปลี่ยนวันเป็นสีแดงไว้ด้วย แต่ก็จะมีความใช้ practices ของ Bullet Journaling อยู่คือเขียนวันของทั้งเดือนลงมาเลยทั้งหมดในหน้าเดียว วิธีนี้ช่วยให้เห็นภาพรวมของทั้งเดือนว่ามันมี Event อะไรบ้าง แล้วสิ่งที่ Notion มาช่วยเติมเต็มการทำ bullet journaling คือการที่เราสามารถ Merge ตัว Monthly Log กับ Daily Log เข้าด้วยกันได้แบบแนบเนียนมาก โดยการใช้ Toggle List ครับ

ความดีงามของ Toggle List คือการที่มัน Encapsulate ข้อมูลที่เกี่ยวกับวันนั้นไว้ในตัวเองซ้อนเป็น Level ได้เลยทำให้จากแต่ก่อนต้องมีหนึ่งหน้าในสมุด dedicate ให้กับ Monthly log แล้วตัว Daily Log ก็ขยายไปเรื่อยๆ สองอย่างนี้ก็มารวมกันได้

อีกหนึ่งฟีเจอร์ที่ดีงามมากของ Notion คือ To-do list เลยครับเป็นอีกฟีเจอร์นึงที่แมพลงกับ Tasks ใน Bullet Journal พอดิบพอดี และความดีงามคือนอกจากจะมี checkbox ให้กดข้างหน้าแล้ว พอกดแล้วยัง fade ตัวหนังสือของ task นั้นให้เป็นสีเทาด้วย เรียกได้ว่าให้เราโฟกัสเฉพาะงานที่ยังไม่เสร็จ ตัวที่เสร็จแล้วก็ลืมมันไปได้เลย

Second Version

หลังจากใช้งานเวอร์ชั่นแรกมาซักพัก ผมเริ่มจะรู้ตัวว่ามันมี Monthly Log อีกแบบด้วยจริงๆ ต้องบอกว่าอารณ์มันจะกึ่งๆ Future Log คือ เรารู้ว่ามันเป็นสิ่งที่ต้องทำเดือนนั้นแหละ แต่ยังไม่รู้ว่าจะทำวันไหน แล้วการจะไปยัดวันใส่มันเลยใน Version แรกมันทำไม่ได้เลยเกิดการจัดระเบียบ Section ใหม่โดยแยกในเดือนเดียวแบ่งเป็น Monthly Log กับ Daily Log ไปเลย ซึ่ง Monthly Log นอกจากจะเป็นที่รวม Tasks ที่ต้องทำภายในเดือนนั้นแล้ว ยังมีอีกฟีเจอร์ที่เติบโตขึ้นมาตามการใช้งานซึ่งก็คือ Page ครับ

ตัว Page ที่ผมใช้ใน Monthly Log จะเป็นที่รวบรวมเรื่องที่เกี่ยวข้องกัน แล้วแทนที่จะเขียนมันกระจายไปในแต่ละวัน ซึ่งทำให้ชีวิตลำบากมากๆ กลายเป็นทุกอย่างจะถูกรวบรวมอยู่ในเพจๆ เดียวแทน ผมใช้เพจหลักๆ กับ Project, Research topic หรือเวลาไปเรียน Course อะไรก็จะรวบไว้ในนี้เลย พอรวบไว้ใน page เดียวแล้วแต่ละวันมันเลยกลายเป็นการ reference กลับไปหาเพจผ่านฟีเจอร์ Mention to a page แล้วเป็นการจดโน๊ตสั้นๆ แทนว่าวันนั้นทำอะไรเกี่ยวกับ page นี้

อีกวิวัฒนาการที่เกิดขึ้นในช่วงเวอร์ชั่นที่สองคือ พอเราเริ่มใช้ Toggle list แทน Tasks ในแต่ละวันเพราะมันต้องการ detail มากกว่านั้นด้วย กลายเป็นว่าเราสูญเสียความสามารถในการติ๊ก To-do ไปแทน ซึ่งแรกๆ ผมก็แก้ text ของ Toggle list นั้นให้ขีดฆ่าแล้วเปลี่ยนเป็นสีเทาเอง แต่รู้สึกว่ามันใช้พลังงานเยอะเกินไป เลยกลายเป็นว่ามาจบที่การใช้ emoji prefix convention แทน 2 แบบคือ ✅ สำหรับ Task ที่เสร็จแล้วกับ 🚧 สำหรับ Task ที่ยังทำค้างอยู่ แล้วต้องทำต่อวันต่อไป

Third Version

เวอร์ชั่นถัดมาอาจจะเรียกว่า Minor change ก็ได้ เกิดจากตอนที่เปลี่ยนงาน แล้วมันมีของที่ต้องรู้ใหม่เยอะมากๆ เลยทำให้มีพวก Note ไว้คอยจดว่าเรียนรู้อะไรใหม่ปนกับ Tasks มากขึ้นเรื่อยๆ แล้วมันเละเทะมาก เลยเกิด Section ย่อยในแต่ละวันขึ้นมาเป็น #learntoday ซึ่งก็ใช้ Toggle List ทำการ encapsulate เหมือนเดิมมาช่วยให้แยกสิ่งที่ต้องโฟกัสแต่ละอย่างออกจากกัน

อีกอย่างนึงที่เริ่มใช้เยอะในเวอร์ชั่นนี้คือ Horizontal Rules มาช่วยแบ่ง Section ในหนึ่งวัน เพราะเริ่มมี Context มากขึ้นแล้วการ Encapsulate ผ่าน Toggle List มันลึกไป แต่ Practice นี้ใช้ไม่ได้นานก็เลิกๆ ไป แล้วกลับไป Encapsulate เหมือนเดิม เพราะสุดท้ายแล้วเราไม่ได้อยากดูทุกอย่างตลอดหรอก แต่ถ้าอยากดูจริงๆ ก็กางเอาก็ได้

4th Version

ถ้านับเวลาจริงๆ ต้องบอกว่าหลังจากปรับเป็น Version 2,3 นี่ก็ไม่ได้ปรับรูปแบบอะไรในนี้เลยมาหลายเดือนมากๆ จนกระทั่งมามองย้อนกลับดูแล้วเจอปัญหานึงว่า หาที่โน๊ตที่ประชุมไว้ไม่เจอ ซึ่งก่อนหน้านี้เวลาจดโน๊ตประชุมจะมีอยู่ 2 แบบใช้ปนๆ กันไปคือ ถ้าไม่แยก Page ประชุมไปเลยก็เป็น Toggle List ซึ่งสุดท้ายหลายครั้งก็ Convert ไปเป็น Page ด้วย

แต่พอมันเป็น Page ที่อยู่ในแต่ละวันแล้วการจะหามันเจอนี่ยากมาก ถ้า search ไม่เจอจริงๆ ก็ต้องมากดกางดูใน Page Hierachy ในเมนูทางซ้ายซึ่งเริ่มไม่สะดวกละ เลยทำให้สุดท้ายแยกออกมาเป็น Section: Meetings สำหรับเก็บโน๊ตประชุมไปเลย แล้วก็ใช้เป็น Toggle List ไปก็แก้ปัญหาที่หาโน๊ตประชุมไม่เจอใน Daily Log ไปได้ละ

อีกสิ่งหนึ่งที่ Introduce มาในเวอร์ชั่นนี้คือตัว Story ครับ มันเกิดจากปัญหาว่าเวลาทำงานเรื่องๆ นึงมันไม่ได้จบในวันเดียว แล้ววันนึงก็ทำอะไรหลายอย่างมาก การจะ Keep track ว่าเราทำแล้ว Progress ถึงไหน เหลืออะไรบ้างนี่ ถ้าต้องดูจาก Daily Log ทุกวันมารวมกันก็ลำบากอยู่ เลยเกิดมาเป็น Section: Story สำหรับเก็บเรื่องที่ทำไปเลย

วิธีนี้คือ Knowledge ที่เกี่ยวกับการทำเรื่องนั้นๆ จะถูกรวบมาไว้ที่เดียวเลย ทำให้เวลาดูภาพรวมมันง่ายขึ้น ส่วนในแต่ละวันก็จะเป็นโน๊ตสั้นๆ ว่าวันนี้ทำอะไรไปแทน ซึ่งจะมาอัพเดทตอนช่วง Wind down ในแต่ละวัน แล้วใช้งานเป็นหลักตอน Daily meeting ในวันถัดไป

ความดีงามอีกอย่างของการแยก Section: Story ออกมาคือ มันทำให้กลับมาย้อนดูได้ง่ายมากว่าเราทำอะไรไปตอนเดือนไหน ช่วยให้เขียน Performance Review ตัวเองง่ายขึ้น แล้วเสริมสร้าง self esteem นิดหน่อยว่าเรายังทำอะไรเป็นชิ้น เป็นอันบ้างนะ

อย่างสุดท้ายที่ Introduce มาในเวอร์ชั่นที่ 4 คือการกลับมาทำ Future Logs ครับ มันเกิดจากปัญหาที่ว่าอยู่ดีๆ ปีนี้ก็ถูกเชิญไปงานแต่งงานเยอะมาก แล้วเริ่มรู้ตัวว่ามีเรื่องบางอย่างที่ต้องแพลนไปไกลกว่าเดือนนี้แล้วเลยต้องแยกออกมาเป็นเป็น Page ใหม่ที่มีศักดิ์พอๆ กับ Monthy Log ในแต่ละเดือนเลย

Conclusion

ตอนนี้ผมอยู่ในเวอร์ชั่นที่ 4 ครับ ณ วันที่เขียนบล็อกนี้ ก่อนจบผมสรุปให้อีกทีว่ามาถึงเวอร์ชั่นปัจจุบันตอนนี้ Structure มันเป็นยังไงบ้าง

เริ่มจากมี Root Page ชื่อ Journal แล้วข้างในแบ่ง sub-page เป็นรายเดือนเช่น January 2023, February 2023 แล้วก็มีอีกเพจชื่อ Future Logs อยู่บนสุด แล้วพอหมดปีก็สร้าง Page ใหม่รวบ Page รายเดือนเข้าด้วยกันตามปี

Future Logs

เพจนี้มีไว้ในการเก็บเรื่องราวที่ไกลเกินกว่าเดือนปัจจุบัน ซึ่งส่วนใหญ่จะเป็นการนัด Event ต่างๆ แบ่ง Section ได้ตามใจชอบถ้ามันพอจะ Group ได้นะ

Monthly Logs (<Month> <Year>)

เพจนี้จะเก็บเรื่องราวในแต่ละเดือนจะสร้างใหม่ทุกๆ ต้นเดือน โดยแบ่ง Section ข้างในออกเป็น 4 Section

Ideas & Tasks — ไว้เก็บอะไรที่นึกขึ้นได้ อะไรที่อยากทำในเดือนนั้นแต่ยังไม่รู้จะทำเมื่อไร หรือบางทีเกิน Scope ที่จะทำได้ในหนึ่งวันก็เอามาโยนไว้ที่นี่ ตรงนี้คือไม่มีกฏเลย อยากโยนอะไรก็โยนมาใส่จะทำ Bullet, Toggle List, Page, Callout แล้วแต่อารมณ์เลย

Story — ไว้เก็บเรื่องที่เกี่ยวกับงานหลักที่ทำในเดือนนั้นๆ ที่เกิน Scope ของวันไปแล้ว จะทำเป็น Toggle List, Page ก็ได้แล้วแต่อารมณ์ ข้างในจะใส่ Note, รูปภาพ, Todo list ฯลฯ มี emoji convention 2 อย่างคือ ถ้ายังทำอยู่ใส่ 🚧 แต่ถ้าทำเสร็จแล้วให้ใส่ ✅

Meetings — ไว้จดโน๊ตเกี่ยวกับที่ประชุมหรือคุยกับใครก็ตามที่มันออกแนว “ประชุม” ตัวนี้ส่วนใหญ่ใช้ Toggle List แล้ว Convention หลักๆ คือชื่อต้องเป็น 📅[<meeting-date>] <meeting name> ข้างในก็จดตามอัธยาศัยเลย

Daily Logs
ตัวนี้แบ่งเป็น 2 ส่วนคือ Structure กับ detail แต่ละเพจ ในส่วนของ Structure จะเป็น List ของ Toggle List เรียงไปตั้งแต่วันที่ 1 จนถึงวันสุดท้ายของเดือน แล้วใส่วันกำกับไปด้วย ถ้าเป็นวันหยุด ตรงนี้จะใช้เป็นสีแดง

ในส่วนของ Structure ในแต่ละวันอันนี้ Free style เลยครับ ข้างบนเป็นแค่ตัวอย่างแบบนึง แต่ถึงเวลาจริง ผมก็ไม่ได้ทำแบบนี้ตลอด อยากจะทำ Todo list อยากจะใช้ Toggle list หรือจะแบ่ง Section ข้างในแต่ละวันอีก ไม่มีกฏตายตัวเลย สำคัญคือเอาที่มีประโยชน์กับเรา แล้วช่วย off-load สิ่งที่อยู่ในหัวเราออกไปได้ คำแนะนำกว้างๆ คือ ถ้าเป็นอะไรที่เราต้องกลับมาดูทีหลัง พยายามใส่ keyword เข้าไปให้ unique พอที่เราจะ search เจอทีหลังได้ด้วย

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

💡 The only thing to prevent better is good enough

Passion มันบังคับกันไม่ได้

จั่วหัวอย่างแรกเลยวิธีนี้ใช้กับเรื่องที่เป็นความอยากจาก External Factor ไม่ได้ หรืออย่างน้อยก็สำหรับผมนะ ความอยากจาก External Factor ยกตัวอย่างเช่น จะไปสอบ Something หรือเป็นสิ่งที่คนอื่นที่ไม่ใช่ตัวเราเองสั่งมาเช่น “พี่อยากได้ … ไปดูมาให้หน่อย” อะไรแบบนี้เป็นต้น

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

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

รู้ว่าเราชอบเรียนแบบไหน

ผมเป็นคนเกลียดการอ่านหนังสือสอบครับ ผมนับครั้งในชีวิตได้เลยว่าผมอ่านหนังสือก่อนสอบแบบจริงๆ จังๆ กี่ครั้ง หลายครั้งในชีวิตผมจะลงเองด้วยการเล่นเกมในคืนก่อนสอบ แล้วไปอ่านเอาหน้าห้องเอา แต่ผมค้นพบมานานแล้วว่าผมชอบโมเม้นตอนกำลังเรียนอยู่มากสุด แล้วผมจำไม่ได้แล้วว่าผมได้ยินประโยคนี้มาจากใคร แต่มันยึดติดเป็นหลักชีวิตผมมานานมากว่า “ถ้าตลอดทั้งเทอมไม่ตั้งใจเรียน แล้วมาตั้งใจอ่านหนังสือแค่วันก่อนสอบ มันจะมีประโยชน์อะไร” (disclaimer: ผมก็ไม่ได้ตั้งใจเรียนตลอดหรอก แต่ผมสนุกตอนเรียนเยอะอยู่)

พอเรารู้ตัวแบบนี้แล้ว ผมก็พาตัวเองไปอยู่ในโลกของเรื่องที่จะเรียนรู้แบบอัตโนมัติเลยครับ ซึ่งบางครั้งมันก็ตามมาติดๆ จากตัวที่จุดประกายความอยากเราแต่แรก ต้องขอบคุณการจัดหมวดหมู่ของห้องสมุดตั้งแต่สมัยเรียนเรื่อยมาจนถึง Recommendation system ของ Youtube เลยที่ทำให้เรื่องเดียวกันมันโผล่มาเติมเต็มตลอด ซึ่งบางครั้งมันก็คือจุดเดียวกับที่จุดประกายความอยากรู้มาตั้งแต่แรกนั่นแหละ ยกตัวอย่างเช่นคลิปข้างล่างใน Youtube น่าจะเป็นคลิปล้างรถคลิปแรกๆ ที่ผมดู หลังจากนั้นมันก็พาเพื่อนมาเพียบเลยในหมวด Auto Detailing

ถ้าถามว่าแล้วเราจะรู้ได้ยังไงว่านี่เป็นวิธีเรียนรู้แบบที่เราชอบ คำตอบคือ ถ้ามันเป็นอะไรที่เราทำได้ตลอด ทำโดยที่ไม่รู้จักเหน็ดเหนื่อย ทำตั้งแต่ตื่นมาจนนอน ทำโดยที่ไม่รู้สึกตัวว่ากำลังทำอยู่ เราอินอยู่กับเรื่องที่เราสนใจมากจนเราลืมไปแล้วว่าเรากำลังศึกษามันอยู่ นั่นแหละครับคือคำตอบ

The learn-practice-validate loop

Learn - Practice - Validate Loop

ถ้าใครรู้สึกคุ้นๆ มันคือ loop เดียวกับ Lean เลยครับ โดยแบ่ง Stage การเรียนรู้ของเราเป็น 3 stage หลักๆ

• Learn — เป็น stage ที่เรากำลังหาคำตอบให้กับตัวเองว่าเราไม่รู้อะไรอยู่ แล้วก็หาทางเติมเต็มมัน
• Practice — พอรู้สึกว่ามีเครื่องมือครบมือละ พอจะมีความรู้ละก็ได้เวลาลองของจริง
• Validate — หลายครั้งพอลองเสร็จก็จะรู้สึกขัดๆ ก็กลับไปลองเทียบกับสิ่งที่รู้มาว่าพลาดอะไรไป

แต่ถามว่า ตอนที่กำลังอินกับเรื่องอะไรอยู่นี่คิดถึง loop อะไรแบบนี้มั้ย ก็ไม่นะครับ แต่มันออกมาแบบธรรมชาติเลย ไม่ค่อยได้คิดถึงหรอกครับ มันจะมาของมันเองเดี่ยวผมยกตัวอย่างให้ฟังจากการล้างรถเองครั้งแรก

Stage ของการล้างรถ

Learn

ตอนผมรู้ตัวแล้วว่าผมอยากล้างรถแต่ผมไม่รู้เลยว่าต้องทำยังไงบ้าง ต้องใช้อะไรบ้างก็ค่อยๆ สะสมความรู้ไปเรื่อยๆ จนรู้ Stage ออกมาเป็นภาพข้างบน นี่ยังไม่นับ Practice หลายอย่างเช่น อย่า Swirl ให้เช็ดแบบ Straight direction หรือ Two bucket method หรือการเลือกใช้ brush กับแต่ละส่วน ผมบอกได้เลยว่าตอน Learn นี่แหละสนุกมาก เพราะความเป็นไปได้มันไม่มีที่สิ้นสุดมาก

Practice

อันนี้อยากโน๊ตไว้นิดนึงว่า บางครั้งเวลาผมอินกับอะไร ผมก็ไม่มาถึง Stage นี้เพราะแค่ Learn อย่างเดียวก็สนุกแล้ว หรือติดขัดเรื่องงบประมาณ แต่ถ้าเป็นเรื่องล้างรถมันมาถึงตรงนี้ได้ไวเพราะของครบเร็ว แต่ทุกครั้งเลยตั้งแต่พยายามทำ Ollie ครั้งแรกๆ, เขียนโค้ดครั้งแรกในภาษาใหม่หรือทำโฟมล้างรถครั้งแรก มันจะไม่ราบรื่นเหมือนที่เราเรียนมา ตรงนี้เอาจริงๆ ก็เป็นจุดที่สนุกมากที่เราต้องแก้ปัญหาเฉพาะหน้าที่หลายครั้ง “มันไม่ง่ายเหมือนที่ดูมาเลย” แต่ก็พยายามพาตัวเองไปจนจบให้ได้

Validate

ต่อจากขั้นลอง มันจะมีหลายครั้งที่มันจะเอ๊ะ อะไรบางอย่างติดในใจ อะไรที่ในหัวข้อที่แล้วคือ “มันไม่ง่ายแบบที่คิด” แล้วผมก็พยายามมาวนดูสิ่งที่เราเรียนใหม่ เทียบกับสิ่งที่เราทำว่าพลาดอะไรไป ความสนุกของขั้นนี้คือ บางครั้งเราก็ทำพลาดอะไรโง่ๆ ไปไม่รู้ตัวเช่น ปัดเท้าเบาไปตอนกระโดดขึ้นไป Ollie หรือใช้เวลาล้างรถนานเกินไปจนน้ำเริ่มแห้งก่อนเช็ดละ ไอของที่คาใจพวกนี้พอเรา Practice ครั้งถัดๆ ไปมันจะดีขึ้นนะ

จริงๆ validate มีอีก aspect นึงที่ผมใช้บ่อยคือ Show your work ครับ ต้องบอกว่ามันจะเหมือนขี้อวดหน่อยๆ แต่เวลาอวดแล้วเราจะได้ฟีดแบคกลับมาด้วย ซึ่งอันนี้แหละมีค่ามาก

รถผมเงามากครับ อวดๆ

ทำสิ่งเล็กๆ เพื่อเป้าหมายที่ยิ่งใหญ่

เคยได้ยิน Snowball effect มั้ยครับ มันคือการที่เราทำอะไรเล็กๆ หลายๆ อย่างเพื่อพุ่งเป้าไปที่เป้าหมายที่ใหญ่กว่า เหมือนกับก้อนหิมะที่ค่อยๆ กลิ้งลงจากภูเข้าแล้วเก็บหิมะระหว่างทางให้ตัวเองใหญ่ขึ้นเรื่อยๆ พอถึงตีนเขาก็กลายเป็นหิมะก้อนใหญ่ที่พร้อมซัดหน้าคนที่ขวางทาง ผิดๆ จริงๆ มีอีก analogy นึงที่คนใช้กันเยอะคือ Momentum ครับ ตราบใดที่เรายังรู้สึกว่ามี progress อยู่ แล้วเรา keep progressing ต่อไปเราก็ค่อยๆ ใกล้เป้าหมายใหญ่เราเอง

2 analogy ที่ผมยกตัวอย่างมาเพื่อที่จะบอกว่า ถ้าเราตั้งใจจะรู้ทุกอย่างให้ได้ตั้งแต่แรกเลย มันเหนื่อยครับ แต่ถ้าเราค่อยๆ Breakdown มันออกมาหลังจากเราเริ่มจะ “รู้ว่าเราไม่รู้อะไร” มันจะช่วยให้เราค่อยๆ สนุกกับ Progression ที่เพิ่มขึ้นเอง ถามว่าผมรู้มั้ยว่าล้างรถเนี่ยมันต้องมีขั้นตอนเยอะขนาดนั้นแต่แรก ก็ไม่ ผมรู้แค่ว่าเอาน้ำมาเช็ดๆ ก็น่าจะใหม่แล้ว แต่พอเห็นภาพกว้างว่าเออมันมีขั้นตอนอยู่นะ ก็ค่อยๆ แบ่งตัวเองไปดูทีละเรื่อง ดูว่าจะล้างล้อมันทำไงนะ, จะทำโฟมทำไงนะ, จะเช็ดกระจกยังไงนะ พอเป้าย่อยๆ มันโดนเก็บเราจะรู้สึกเองว่าเป้าใหญ่มันค่อยๆ เป็นไปได้มากขึ้นเรื่อยๆ ตามมาด้วย

ถ้าไม่สนุกแล้วก็เลิก ไปทำอย่างอื่นเถอะ

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

ประมาณนี้ครับ ขอย้ำอีกครั้งว่าเรื่องที่เราอยากรู้มันบังคับกันไม่ได้ แต่ถ้าเราเจอมันแล้วก็ go with the flow ครับ สิ่งสำคัญที่สุดคือ เรายังสนุกกับมันอยู่รึเปล่า ถ้าไม่สนุกแล้วก็ไปทำอย่างอื่นเถอะครับ ก็ประมาณนี้ขอให้สนุกกับการเรียนรู้ครับ

👨‍🦳💰 Dad & Dept

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

ในช่วงเวลาเดียวกันกับที่พ่อป่วย ตอนนั้นเลยได้รู้ความจริงอีกอย่างว่าที่บ้านที่หนี้สินอยู่จำนวนนึง อาจจะไม่ได้เยอะมากถ้าเทียบกับคนอื่น แต่ก็ไม่สามารถจ่ายให้หมดได้ภายในวันเดียว ซึ่งพอพ่อป่วยระบบที่พ่อคอยดูแลหนี้ตัวนี้มันรวนหมดเลย เพราะพ่อไปจ่ายเองไม่ได้ เลยทำให้ที่บ้านต้องช่วยกันจัดการกัน หลังจากตั้งสติได้แล้วก็คือต้องงัดทุกความรู้กับประสบการณ์ในการจัดการหนี้ตัวเองมาก่อนหน้านี้มาใช้ทั้งหมด จนได้แผนที่ตอนแรกถูก Projection ไว้ว่าหนี้ตัวนี้เนี่ย น่าจะหมดกลางๆ ปี 2025 แต่ Inspect & Adapt แผนมาเรื่อยๆ จนบอกได้เต็มปากเลยว่าหนี้ 95% ถูกจัดการหมดแล้วในปี 2022 นี้

ขอเล่าเรื่องหนี้ต่ออีกนิดนึงละกัน คือจริงๆ มันไม่ยากแต่เราต้อง Proactive กับมันแทนที่จะ Reactive ตอนบิลแจ้งหนี้มันมาถึงบ้านแล้วตลอดปีที่ผ่านมา Principle หลักๆ ที่ใช้ตอนจัดการจะมีอยู่ 3 อย่างเลยคือ cash flow ถ้าไม่มี cash flow เอาไปจ่ายหนี้อย่างเดียวจนหมดไม่มีตังค์กินข้าวทำอย่างอื่น เราจะไม่มีแรงไปทำงานหาเงินต่อเลย อันนี้คืออย่างแรก อย่างที่สองคือ Visualize คือตอนแรกที่เรารู้ว่ามีเรื่องหนี้นี้ไม่มีใครเห็นภาพเลยว่ามันมากแค่ไหน แล้วมาจากตรงไหนบ้าง พอเรา Projection ออกมาได้มันเลยทำให้วางแผนได้ง่ายขึ้นมากว่าจะจัดการยังไง อย่างสุดท้ายพูดไปข้างบนแล้วคือ Inspect & Adapt ทุกๆ 2-3 เดือนในปีนี้ผมกลับมารีวิวแผนที่วางไว้ แล้วแทบจะปรับใหม่ทุกครั้ง หลังเราเข้าใจธรรมชาติของหนี้หลายๆ อย่างมากขึ้นเลยทำให้ค่อยๆ ร่นเวลาเข้ามาได้จนหมดไปส่วนใหญ่ในปีนี้

👨‍💻 Lost & Found

ช่วงต้นปีนี่ยังมีความหลงทางอยู่ว่าตัวเองต้องการอะไรกันแน่ รู้แค่ว่าทำ Backend อยู่ไปเรื่อยๆ ไม่ได้ละ เลยพยายามหาลู่ทางออกนอกประเทศ พร้อมๆ กับเรียน Java Bootcamp ที่สุดท้ายเรียนไม่จบเพราะมีเรื่องข้างบนเข้ามาพอดี ในช่วงที่ in the void พอดีนี้ก็มีคุณภูมิใจนี่แหละทักมา เลยจับพลัดจับพลูได้มาทำงานอยู่ที่ปัจจุบัน

ในช่วงเวลาตอนต้นปีถึงกลางปีนั้นมีความทรงจำดีๆ หลายเรื่องอยู่หลังจากผ่านวิกฤติพ่อที่เล่าข้างบนมาได้ ไม่ว่าจะเป็น How to ลาออก ยังไงไม่ให้บ้านบึ้มหรือ👷📚 เล่าให้ฟัง: ย้ายสายจาก Software Engineer มาเป็น Data Engineer สามเดือนแรกหรือหลังจากนั้นถึงแม้ว่าจะไม่ได้เขียนเล่าออกมาเป็นบล็อกเท่าไร แต่บอกได้เลยว่างานที่ทำอยู่นี่มีอะไรให้ทำอีกเยอะมาก แล้วทุกวันที่ทำงานยังรู้สึกว่าเป็น A whole new world อยู่เพราะโลกหมุนไปเร็วเหลือเกิน แต่ถ้าจะมีอะไรที่อยากพูดถึงเรื่องงานมี 3 เรื่อง

ขอบคุณภาพจากคุณ Teera ด้วยคับ

อย่างแรกคือ Dagster รู้สึกโชคดีอย่างนึงที่เข้ามาใช้งานจริงๆ ในจังหวะที่ Dagster กำลัง move แบบก้าวกระโดดมากๆ พอดี เลยได้เห็นจังหวะกำลังเปลี่ยนจากโลกเดิมจาก solid, pipeline ไปเป็น ops, jobs เรื่อยมาจนถึงยุค Software-defined Assets ที่ได้มีโอกาสไปแชร์เรื่องนี้ที่งาน Grill The Data กับใน Internal Engineering Training ด้วย

อย่างที่สองคือไม่เคยคิดเลยว่าตัวเองจะทำงานบน Jupyter Notebook ได้และชอบด้วย ก่อนจะมาทำงานที่นี่ถึงแม้จะมีโอกาสได้ใช้บ้าง แต่ก็ยังเชื่อว่าเขียนเป็น Python file ง่ายกว่าเป็น comfort zone กว่า จนเริ่มมาอยู่กับ Notebook จริงๆ จังๆ ช่วงครึ่งปีหลังเลยได้รู้จักมันมากขึ้นว่า มันไม่ใช่แค่เขียนโค้ดได้ แต่มันเอาไว้ experiment, share knowledge, ทำเป็น artifact ฯลฯ คือมันทำอะไรได้เยอะมากๆ คล้ายๆ กับตอนใช้ emacs org mode แต่เข้าถึงง่ายกว่ามาก

อย่างที่สามคือโลก SQL เป็นอะไรที่ลึกล้ำมากและเปิดโลกมากๆ ตลอดปีที่ผ่านมาทำให้รู้เลยว่าตอนเขียน application วิธีที่ใช้ SQL อยู่คือน้อยกว่าคนทำงานทาง Data มากๆ แต่ก็รู้สึกหลายอย่างเหมือนกันว่า Practices จากฝั่งการทำ application ก็ไหลๆ มาหางานทาง Data ในแนวเดียวกันเหมือนกัน สังเกตุจากสิ่งที่ dbt ทำหรือ tooling ต่างๆ ที่เกิดขึ้นมาในโลก SQL แต่ถึง SQL จะ unified ขนาดไหนความรู้ในการ tuning database ที่สะสมกันมาเป็นสิบๆ ปีก็ยังใช้ได้เสมอ ทั้งการ optimize query plan, การทำ indexing ฯลฯ ของพวกนี้รู้ไว้ยังหากินได้อีกยาวไกลครับ

🏡 🚙 F A M I L Y

เอาจริงๆ ถ้าไม่มีกะตั๊กนี่จินตนาการไม่ออกเลยว่าชีวิตจะเป็นยังไง ตั้งแต่ที่ต้องกลับมาคอยดูแลพ่อกับแม่ตอนต้นปี ก็มีกะตั๊กบินกลับมาอยู่บุรีรัมย์ด้วย เลยได้ลองใช้ชีวิตอยู่บ้านแทนคอนโดที่อยู่มาหลายปี เลยเริ่มเข้าใจว่าชีวิตแบบนี้มันก็สบายอีกแบบนะ

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

That small home office we build from the ground up

ซึ่งสุดท้ายแล้วเดือนพฤศจิกายนก็เลยได้บอกลาการเป็นชาวเมือง มาเป็นชาวชานเมืองอยู่บ้าน ทำอาหารกินเองเต็มตัว แล้วทำให้ค้นพบว่าทุกๆ อย่างดูกว้างขวางขึ้นแล้วก็เงียบขึ้นแบบรู้สึกได้ อีกอย่างนึงที่ได้มาจากการออกมาอยู่บ้านแทนคอนโด คือการได้ทำห้องทำงานเองนี่แหละ ซึ่งสนุกนะแล้วมันเปลี่ยนวิธีใช้ชีวิตไปเลย เพราะการไปทำงานคือการไปเข้าห้องทำงานจริงๆ แยกออกมาจากการใช้ชีวิตในบ้านส่วนอื่นๆ ทำให้เวลาพักผ่อนมัน fully charge กว่าสมัยก่อนมาก

แต่การอยู่นอกเมืองก็มี cost ที่ต้องแลกมาคือต้องมีรถ ช่วงแรกๆ ที่อยู่นี่ ลำบากสัสๆ เรียก Grab ไม่ได้เลยจะมีแต่ LINE Man Taxi นี่แหละที่พอเรียกติดบ้าง แล้วการแค่ไปตลาดห่างจากบ้านไปแค่ 3km ที่อาจจะแวบไปแปปเดียว แต่ใช้เวลาตั้งครึ่ง ชม. เพราะกว่า Taxi จะผ่านมาซักคันนี่รอจนเมื่อย ซึ่งสุดท้ายแล้วมันทนไม่ไหวแล้วต้องใช้รถจริงๆ เลยไม่รอละ Civic FE ที่จองไว้แบบไม่รู้อนาคต เลยกระโดดไปหา Toyota Corolla Cross GR Sport ได้เป็นรถแฝดกับรถพี่เหน่งเฉย พร้อมกับความสามารถในการโม้ได้ว่าเลขตัวถังรถเราสวยมาก ฮ่าๆ

น้องแพนแพน

ปล.จริงๆ ปีนี้ติดโควิดด้วย จริงๆ เข้าโรงพยาบาลก็บ่อยนะ แต่โควิดนี่คือโหดมาก หนาวสั่นไปหลายวัน เจ็บคอไปหลายวันกว่าจะหาย แต่กะตั๊กก็ยังแข็งแกร่งอยู่ด้วยกันทุกวัน แต่ก็ยังไม่ติดจนถึงทุกวันนี้

บันทึกไว้ว่าครั้งหนึ่งในชีวิตเราเคยสองขีด

Ergodox EZ

ในบรรดาทุกตัวในรอบหนึ่งปี ตัวนี้เป็นคีย์บอร์ดที่มีวิวัฒนาการ layout เป็นหลักมาอย่างต่อเนื่อง เรียกได้ว่าปรับไปใช้โปรแกรมไหนก็มาปรับตรงนี้ตามเดี๋ยวเราค่อยๆ ดูไปทีละ layer เลย

layer 0 - Dvorak

ด้วยความที่ layout ภาษาอังกฤษหลังผมเป็น Dvorak เลยบังคับโดยปริยายว่า layer แรกต้องเป็น Dvorak ก่อนหน้านี้เคยใช้ Dvorak เป็น layer หลังๆ แต่ค้นพบว่ามันจำกัดการใช้งานคีย์บอร์ดลงเยอะมาก ถ้าเป็น layer รองๆ ซึ่งนอกจากจะใช้เป็น Dvorak ในตัว Base แล้ว Modifier ข้างๆ ก็ปรับตาม Ergodox เช่นกัน เพราะปุ่มน้อยลงตรงขอบๆ แต่มากขึ้นในส่วนที่เป็นนิ้วโป้ง ซึ่งพวก - = [ ] ที่ Dvorak เอาไว้ทางขวาบนผมก็แมพมาไว้ในแถวล่างสุด แล้วใช้นิ้วโป้งกดแทนครับ

เริ่มจากทางซ้ายบนผมแมพ Undo (Cmd + Z) เอาไว้ตรงที่คีย์บอร์ดอื่นๆ จะเป็น ESC หรือ grave ascent ซึ่งมีประโยชน์เพราะแทนที่จะต้องกดสองปุ่มก็เหลือปุ่มเดียวแทน ปุ่มถัดมาก็จะเป็น alt/option ปุ่มแรกแทน tab เพราะ tab ไปอยู่ตรงนิ้วโป้งขวาแล้ว ถัดลงมาที่ปกติจะเป็น Caplock ซึ่งไม่มีประโยชน์สำหรับผมเลยเปลี่ยนเป็น Ctrl เวลากด hold และเป็น ESC เวลากดปกติ ซึ่งสองปุ่มนี้พอมันย้ายมาอยู่ใกล้ๆ home row มันทำให้ผมไม่ต้องยกมือขึ้นมาบ่อยๆ เวลากด ESC เพื่อออกจาก Insert mode ของ Vim หรือทั้ง Ctrl, Alt ต่างก็เป็น lead key ใน Emacs ก็ช่วยลดอาการปวดนิ้วก้อยหรือ Emacs Pinky ไปได้บ้าง เรื่อยไปถึง Magnet ก็ช่วยให้กด lead key ที่ต้องกดทั้ง Ctrl + Alt ในการจัดระเบียบ Window ด้วย

ในส่วนของตรงกลางจะเป็นปุ่ม Screen capture ซึ่งพอเราต้องใช้ทั้งแบบ area และแบบ full screen เลยแมพแยกไปเลยจะได้ใช้ง่ายๆ ถัดมาทางซ้ายจะเป็น Copy/Paste ซึ่งจุดประสงค์เดียวกับ Undo คือไม่ต้องกด Lead key ให้มันจบๆ ไป ส่วนทางขวาจะเป็นปุ่มไว้ปรับไป Layer 3 ที่เป็น QWERTY ซึ่งปกติจะใช้ร่วมกับปุ่ม lang ซึ่งจริงๆ เป็น Macro ที่กด Win + Space ให้ไว้เปลี่ยนภาษาครับ จะเห็นว่าความลำบากนิดหน่อย (แต่ตอนนี้ชินแล้ว) คือไม่ใช่แค่เปลี่ยนภาษาแล้วจะพิมพ์ได้เลย แต่ต้องเปลี่ยน layout กลับมาเป็น QWERTY ด้วย

จุดเด่นของ Ergodox คือ Thumb Cluster ครับ ซึ่งทำให้นิ้วโป้งที่เคยเอาไว้แค่กด Space ง่อยๆ ทำอะไรได้มากขึ้น เช่นนิ้วโป้งซ้ายที่มีสองปุ่ม แต่ผมทำได้ 4 อย่างเลยคือ ซ้ายสุดถ้ากดจะเป็น Space แต่ถ้ากด hold จะเป็น Command/Win ส่วนซ้ายรองถ้ากดจะเป็น Backspace แต่ถ้ากด hold จะเป็น alt/option ปุ่มที่สอง ในส่วนของนิ้วโป้งขวาผมไม่ซับซ้อนมากเลยเป็น Tab, Enter ตามลำดับ ส่วนปุ่มม่วงๆ ข้างบนก็แมพคีย์ลัดไว้เปิดโปรแกรมเช่น raycast, 1password แทนที่จะกดหลายปุ่มก็กดปุ่มพวกนี้ปุ่มเดียวแทน

ทางขวาไม่มีอะไรพิเศษครับ แค่มีปุ่มที่ปกติจะเป็น Enter ให้เป็น Window แทนเวลา hold เพราะบางโปรแกรมใช้ Win + Space ซึ่งพอมันอยู่ด้วยกันตรงนิ้วโป้งซ้ายก็ไม่รู้จะกดยังไงเลยต้องมีแบคอัพไว้อีกปุ่มครับ

ย้อนกลับมาตรงกลางหน่อยคือเวลาเราวางมือตรง Home row นิ้วก้อยผมจะมีหน้าที่เป็น Layer toggle เวลากด Hold เพิ่มมาอีกทั้งสองข้างเลย โดยก้อยซ้ายจะ switch ไป Layer1 ส่วนก้อยขวาจะไป Layer2 ครับ

layer 1 - Symbols

พอผมกดนิ้วก้อยซ้ายตัวคีย์บอร์ดจะ switch มา layer1 ให้จนกว่าผมจะปล่อยซึ่งหลักๆ ใน layer นี้จะเป็นสิ่งที่ Ergodox เซตมาให้แต่แรกคือพวก F1 → F12 จะไล่เรียงกันไปตามแถวบนสุด แต่ use case หลักๆ ผมใน layer นี้จะเอาไว้กดคีย์ที่ใช้บ่อยๆ เวลาเขียนโปรแกรมครับ

โดยคีย์ที่ใช้บ่อยสุดในการเขียนโปรแกรมคือวงเล็บทุกแบบ ซึ่งจะอยู่ในระยะนิ้วกลางกับชี้ซ้ายในขณะที่นิ้วก้อยซ้ายกด hold อยู่ ทำให้เวลาผมเขียนวงเล็บไม่ต้องยกมือไปสุดขอบขวาบนเหมือนชาว Dvorak ปกติครับ รวมไปถึงพวกใช้บ่อยๆ รองลงมาใน Shell ทั้ง Tilde, Pipe, Grave Ascent ต่างก็อยู่ในนี้ให้กดง่ายๆ ด้วย นอกจากนี้จะเห็นว่าใน Layer นี้ผมแมพปุ่ม Copy/Paste ไว้เหมือนกัน แต่ใน Layer1 นี้จะเป็นของ Windows แทนครับซึ่งเป็นคีย์คนละคีย์กับ Mac

ส่วนทางขวาด้วยความที่ผมใช้ IDE อย่าง PyCharm, IntelliJ ด้วยแล้วมันจะมีคีย์ที่กดบ่อยๆ อย่างเช่น Code Generator, Refactor, Switch to Terminal, Goto Implementation ก็เอามาแมพไว้เป็นคีย์ใน home row เลยจะกดก็ไม่ต้องยกมือออก ส่วนคีย์ที่ใช้บ่อยรองลงมาเช่นพวกสั่ง Run, Debug ก็เอาไว้ข้างบนกับล่างแทน ซึ่งมีทั้งแบบกด Cmd กับ Ctrl แยกกัน

layer 2 - Navigations

ถ้ายังจำกันได้จาก layer 0 ผมจะใช้นิ้วก้อยขวาในการกดไป layer 2 ซึ่งจะพามาหา navigation นี่แหละครับ ซึ่งจะมีพวกลูกศรที่ถ้าใครเป็นชาว Vim ก็จะอ๋อทันทีว่า นี่คือการแมพ navigation แบบเดียวกับที่ Vim ใช้เลย นอกจากนั้นแล้วแป้นซ้าย ถ้าขี้เกียจยกมือ ยังสามารถทำตัวเป็นเมาส์แทนได้ด้วยครับ

ส่วน G,C,H,T เป็นคีย์ที่ผมเอาไว้กดคู่กับปุ่ม Alt + Left Ctrl ซึ่งถ้าจำได้มันเป็น Lead key ของ Magnet ทำให้ผมสามารถจัด Window แบบแบ่ง 4 หน้าจอได้ง่ายๆ เลยครับ

layer 3 - QWERTY

ในส่วนของ Layer 3 จะเป็น QWERTY ไว้ใช้ในกรณีที่ผมจะพิมพ์ภาษาไทยหรืออะไรที่ต้องการ QWERTY จริงๆ ครับโดยจะสลับมาผ่านปุ่ม toggle layer 3 ตรงกลางๆ ที่เป็นลายๆ จาก layer 0 ซึ่งประโยชน์ของ Layer นี้มีแค่นี้จริงๆ ครับ 555

layer 4 - FPS

Layer นี้จุดประสงค์ตามตัวครับคือเอาไว้เล่นเกม ซึ่งน่าจะใกล้เคียงกับคีย์บอร์ดปกติที่สุดละ ซึ่งถามว่าแล้วทำไมต้องทำแยกมาจาก layer 3 - QWERTY ต้องบอกว่าพวกปุ่ม Modifier ใน Layer นี้ถ้าจะสังเกตุดีๆ จะใกล้เคียงกับคีย์บอร์ดคนทั่วไปมากที่สุดละครับ ซึ่งมันก็คือคีย์บอร์ดที่เกมมันออกแบบมาให้ใช้เล่นเกมนั่นเอง ในขณะที่ QWERTY จะยังใช้ความสามารถของปุ่มที่แมพไว้ใน Layer 0 หลายปุ่มอยู่ครับ

layer 5 - Steno

อันนี้แถมเฉยๆ ด้วยความที่คีย์บอร์ดที่เป็น QMK Based firmware จะรองรับ Steno mode ด้วยทำให้ผมเซต layer นี้เอาไว้ใช้เล่น Steno ที่ทำให้เราพิมพ์คำผ่านการกดคอร์ดได้ครับ แต่ต้องบอกว่าหลังจากใช้แล้วมันไม่สบายมากๆ เพราะคีย์บอร์ดปกติเราปุ่มมันจะสูงๆ แล้วการกดคอร์ดมันต้องวางนิ้วไว้ระหว่างกลางของสองปุ่มเช่น T- K- พอต้องกดคอร์ดที่ต้องใช้สองปุ่มเลยเจ็บมากครับ ผมเลยแนะนำว่าถ้าอยากลอง Steno จริงๆ ไปซื้อคีย์บอร์ด steno หรือ low profile มาลองจะเจ็บนิ้วน้อยกว่าครับ ซึ่งผมก็มีอีกอันคือ Georgi keyboard ที่เป็น low profile ไว้ฝึก Steno โดยเฉพาะครับ

d60lite — 60% HHKB

จริงๆ มาเขียนบล็อกนี้เพราะว่าเพิ่งได้ตัวนี้มานี่แหละ แล้วหลังจากใช้งานมาอาทิตย์กว่าๆ รู้สึกว่ามันได้ Custom มาอยู่ในจุดที่ใช้ได้ใกล้เคียงกับตอนใช้ Ergodox บ้างแล้ว แต่ก็ยังต้องพัฒนาต่อไปเรื่อยๆ เดี๋ยวค่อยๆ ดูทีละ layer โดยต้องบอกว่าพื้นฐานของแต่ละ layer ก็จะมาจากที่เคยใช้ใน Ergodox นีแหละครับ

layer 0 - Dvorak

โดยใน Layer 0 นี้พื้นฐานจะเป็น Dvorak เหมือนกันจากประสบการณ์ที่ได้มาจาก Ergodox ที่ layer แรกจะมีความสามารถมากที่สุด แต่ก็จะเสียความสามารถของ Ergodox ไปที่ทำให้นิ้วโป้งเรามีความสามารถเยอะกลับกลายเป็นกด Space เหงาๆ เหมือนเดิมแทน แล้วยกภาระให้กับ Modifier ไปกองกันทางขวาแบบใกล้เคียงคีย์บอร์ดปกติแทน

ในส่วนของปุ่ม Tab, Caplock ถ้าเทียบกับคีย์บอร์ดปกติตัวนี้จะคล้ายๆ กับ Ergodox โดยปุ่ม Tab จะกลายเป็น Tab ถ้ากดแต่ถ้า hold จะเป็น Alt ส่วน Caplock จะเป็น Esc ถ้ากดและ Ctrl ถ้า hold ต่อมาส่วนของ home row เรายังใช้ประโยชน์จากนิ้วก้อยในการ switch ไป layer1 ตอน hold เหมือนเดิม

ส่วนที่ Tricky แต่ก็โชคดีคือการที่ HHKB layout ย้ายปุ่ม backspace ลงมาทำให้ผมมีปุ่มขวาบนที่ไม่มีในคีย์บอร์ดปกติเพิ่มขึ้นมา ทำให้ตรงจุดนี้ผมแมพ Macro เป็น Win + Space หรือปุ่มเปลี่ยนภาษาครับ ซึ่งจะใช้คู่กับปุ่ม TO(3) ซึ่งเป็นปุ่ม Switch ไป layer 3 ในการสลับระหว่าง EN(Dvorak) → TH(QWERTY) ได้ใกล้เคียงกับ Ergodox เลย

ซึ่งก็จะเหลือปุ่ม MO(1) กับ MO(2) ที่ไม่มีในคีย์บอร์ดปกติเหมือนกัน ผมเลยเอาไว้ทำงานพิเศษคือ switch ไป layer ตามตัวเลขมัน

layer 1 - Symbols + Navigations

อาศัย Practice จาก Ergodox เหมือนกัน แต่แทนที่จะแยก symbol, navigation layer ก็จับมันมารวมกันเลย นั่นหมายความว่า layer switch ที่ใช้นิ้วก้อยใน layer 0 คือชี้มาที่ layer นี้แทนหมด

ด้วยความที่ปุ่มตรงกลางๆ ที่ Ergodox มันหายไปเลยต้องที่ของ Curry Bracket เดิมให้กับ Copy/Paste แทน แล้วย้ายไปกด Curry Bracket กับตัวล่างแทนผ่านการกด Shift ทางขวาร่วมด้วย แต่ด้วยความที่ Curry Bracket ยังเจอไม่บ่อย (ยกเว้นเขียน template เลยยังไม่ปวดใจมากตอนนี้)

layer 3 - QWERTY

ตัว layer 3 ไม่มีอะไรมากมันคือ QWERTY ปกติเลย และปุ่มต่างๆ ใกล้เคียงกับ layer 0 มากยกเว้นเปลี่ยน TO(0) แทนเพื่อให้มันพากลับ layer 0

Drop x OLKB Planck Keyboard — 40% Ortholinear

ด้วยความที่เคยระเบิด Planck keyboard ไปรอบนึงแล้ว เพราะพยายามจะ Custom layout นี่แหละพอได้อีกตัวมาเลยใช้ง่ายๆ ละแทนที่จะ Custom ให้เหมือนตัวบนๆ ที่ผ่านมา ตัวนี้คือ มีอะไรให้ใช้ก็ใช้เลย ซึ่งด้วยความที่ Planck มี Dvorak Layer ให้ switch มาอยู่แล้ว พอปรับตัวมาจาก Ergodox ก็สามารถทำงานได้เลย ตัวปุ่มอาจจะเรียงแปลกๆ บ้างแต่ก็สลับมาใช้ QWERTY ได้แบบพิมพ์ไทยถูๆ ไถๆ ได้

src: https://www.reddit.com/r/olkb/comments/oll0oi/create_you_own_planckpreonic_keymap/

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

ก็ประมาณนี้ครับ จริงๆ ถ้ามามองย้อนดูจุดเริ่มต้นที่เริ่ม Custom layer เยอะขนาดนี้แรกสุดเลย ไม่ใช่เพราะ Ergodox แต่เป็นตอนที่วางแผนจะมาใช้ Planck แล้วต้องพยายามจัดการตัวเองให้อยู่ใน 40% layout ให้ได้ เลยทำให้เริ่มมาศึกษาการใช้ Layer จนออกมาแบบที่เล่ามาข้างบนนั่นแหละครับ

ส่วนใครใช้ Layer ยังไงอยู่มาแชร์กันได้ฮะ ผมอยากเห็นมากเผื่อจะเอาไปปรับใช้เองด้วย สำหรับบล็อกนี้ก็ประมาณนี้ครับ

💡 Disclaimer: ความเห็นต่างๆ ในโพสนี้เป็นความคิดเห็นส่วนตัว ไม่ได้เกี่ยวข้องกับบริษัทที่ผมทำงานอยู่ปัจจุบันแต่อย่างใดครับ

ก่อนเริ่มงาน 1 เดือน

จากตอนที่แล้วผมบอกไว้ว่ามันจะมีช่วงที่เรา lower your light ซึ่งเป็นเวลาที่ดีที่สุดที่เราจะเตรียมตัวกับงานใหม่ จังหวะนี้เป็นช่วงที่ผมหาข้อมูลงานใหม่ให้มากที่สุดครับ ซึ่งจากเท่าที่คุยตอนสัมภาษณ์ผมรู้แค่ว่า Tooling หลักคือ Dagster ช่วงแรกๆ ผมเลยดู Dagster เป็นหลักเลยซึ่ง ณ จุดนี้ถ้ามองย้อนไปผมบอกเลยว่า Tutorial ของ Dagster มันเป็นกับดักครับ 555 คือมันดูเหมือนจะเข้าใจง่าย job, ops, เขียนเทสได้ อะไรก็ว่าไป แต่ของจริงมันอยู่ใน Concept กับตัวอย่างใน GitHub ของ Dagster เองครับ อันนั้นคือถ้ากระโดดต่อมาจาก Tutorial ก็จะมีความช็อคน้ำหน่อยๆ แต่เดี๋ยว Dagster ผมมาเล่าต่อในอนาคต มีอีกหลายเรื่องเลยให้เล่าครับ

นอกจาก Dagster แล้วผมต้องขุดความทรงจำว่าเพื่อนร่วมงานผมในอนาคต (ซึ่งเป็นเพื่อนร่วมงานในปัจจุบัน) เค้าทำอะไรมาบ้าง ซึ่งโชคดีมากที่เค้าเคยเล่าไว้ใน LINE Developers Podcast ไว้ถึง 2 ตอนเลย เพราะใน Podcast นี้แนะนำไว้ชัดเจนเลยว่า เราควรจะรู้จัก Hadoop ecosystem นะ ซึ่งผมไต่ไปหลายบล็อกมาก ช่วงนั้นเพื่อจะอัพเดทความรู้ Hadoop ตัวเองที่ถูกแช่ไว้ตั้งแต่ปี 2013 ซึ่งในบรรดาบล็อกทั้งหมดที่ผมไล่อ่านมา ผมประทับใจบล็อก Good Old Days Hadoop นี้มากครับซึ่งเล่าประวัติ Hadoop ได้เห็นภาพมาก รวมถึงพูดถึง YARN, Spark ไว้นิดหน่อยด้วย ซึ่งตอนนั้นผมยังจับภาพไม่ได้เลยว่ามันเกี่ยวกันยังไง

💡 “Software Engineer ทุกคนเราอ่ะเป็น Data Engineer อยู่แล้ว เพียงแค่ความเข้มข้นในการเข้าไปจัดการข้อมูลของเรามันต่างกัน”
- ผมชอบประโยคนี้ของเพื่อนร่วมงานในอนาคตผมมาก

นอกจาก Podcast ข้างบนผมโชคดีอย่างนึงที่ผมพอจะรู้จักเพื่อนร่วมงานในอนาคตผมอีกคน ซึ่งผมก็ถามไปตรงๆ เลยว่าผมควรดูอะไรก่อนบ้างก็ได้รู้จัก Apache Spark มาซึ่งพอได้ยินแบบนั้นปั๊ป ผมกดเรียนคอร์ส Batch Data Pipeline with Spark แบบไม่ลังเลเลย แล้ว Live Project ของ Manning ดีอย่างนึงคือไม่ใช่แค่ก็อปโค้ดแปะแล้วรันได้ แต่จะคล้ายทำงานจริงๆ มากที่บอกว่า เราอยากได้แบบนี้แหละ แล้วก็มี resource guide ให้คร่าวๆ แต่เราต้องไปเปิด Doc API ของ Spark เองว่าจะใช้ฟังก์ชั่นอะไร มาทำให้งาน Ingestion, Cleaning data เป็นไปแบบที่เราต้องการ แล้วนอกจากนั้นยังมีพวก Tips อะไรแทรกอยู่ด้วยเหมือนเรามีเพื่อนร่วมงานระดับโลกคอยคุยกับเราผ่านตัวหนังสือไปอีก

แต่ยังไม่ทันได้เรียนจนจบคอร์สข้างบนผมก็มีโอกาสเจอเพื่อนร่วมงานในอนาคตผมอีกคน ซึ่งผมก็ถามแบบตรงๆ เหมือนเดิม แต่คำตอบที่ได้มาต่างกันคือผมน่าจะลองไปดู Apache Hive กับ Presto ดูซึ่งด้วยความที่เวลาเหลืออีกไม่กี่วันจะเริ่มงานละ ผมเลยลองดูหนังสือ Learn Hive in 1 Day ดู ซึ่งสำหรับคนจะไปดูนะฮะ ข้ามหนังสือเล่มนี้ไปเลยครับ เพราะผมซึ่งไปดู Spark มาก่อนหน้านี้บอกเลยว่าเล่มนี้ไม่ได้ให้ Concept อะไรใหม่ๆ กับเราเลย (แถมพิมพ์ผิดเยอะมากแบบน่ารำคาญ (น่าจะอ่าน Amazon Review ก่อน TT)) แต่อย่างน้อยก็เสียเวลาไม่ถึงวัน

ในส่วนของ Presto เราจะไม่สามารถเข้าใจมันได้เลย ถ้าเราไม่เข้าใจ Hive มาก่อนเพราะ Presto ยังต้องพึ่ง component สำคัญของ Hive อย่าง Metastore ในการทำความรู้จักกับข้อมูลที่เก็บอยู่ ซึ่งตอนเรารู้จัก Hive ใหม่ๆ เราคิดว่าว้าวแล้วนะ ที่มันมา Optimize ให้การทำ MPP บน HDFS มันง่ายขึ้นกว่าสมัย Map Reduce มากแล้วการเอา Compute ไปอยู่ใกล้ๆ Disk นี่ก็ว้าวแล้ว แต่พอรู้จัก Presto ก็จะว้าวไปอีกเพราะมัน Optimize ขึ้นมาอีกขั้นเพื่อ ad-hoc query โดยมาทำงานใน Memory แทน ซึ่งผมรู้ทั้งหมดนี่ผ่านลิ้งค์ต่อไปนี้ครับ [1][2][3][4]

จริงๆ ยังมี Source อีกหลายแหล่งไม่ว่าจะเป็น Data Engineer Cafe, Data Engineer Zoomcamp ฯลฯ ที่เป็นที่พึ่งให้ผมเตรียมตัวด้วย ซึ่งพอถึงจุดนี้เหลือเวลาไม่กี่วันหลังเริ่มงานผมบอกเลยว่าในหัวตอนนี้ทุกอย่างที่ผมเล่ามามันตีกันไปหมดมากๆ ซึ่งถ้าใครเคยมองมาวงการ Data Science/Engineering ก็น่าจะรู้สึกไม่ต่างจากผมว่าทุกอย่างมันถาโถม มันเยอะมากจนไม่รู้จะเริ่มจากตรงไหนดีแล้วในใจก็ยังรู้ว่ามันยังมี Unknow อีกมากที่ต้องไปเจอหน้างานถึงจะรู้ว่าอะไร

เดือนแรก

พอเข้ามาเดือนแรก ผมได้รับการบอกกล่าวเลยว่า Data Engineer ที่นี่น่าจะไม่เหมือนที่อื่นนะตาม Data Maturity ขององค์กร ซึ่งแรกๆ ผมก็ไม่ค่อยได้ยินใครพูดที่ไหนเรื่องนี้นอกจากกับเพื่อนร่วมงานผม จนกระทั่งเพิ่งเห็นพี่ทอยเขียนบล็อกนี้ เลยรู้ซึ้งว่าวิธีการแยกแบบนี้มันมาจากหนังสือเล่มนี้ ซึ่งพอมามองย้อนกลับไป เอ่อจริง เพราะตั้งแต่เดือนแรกไม่ใช่ผมกระโดดไปทำ Data pipeline เลย แต่ไปทำความเข้าใจว่า pyhive มันทำงานยังไงกับ Hive, Spark, Presto จนไปรู้จัก Thrift server ที่ทำงานอยู่ข้างหลัง รวมถึงไปทำความรู้จักกับ Hadoop ecosystem อีกครั้ง (แบบมีคนคุยด้วย)

แต่ก็ใช่ว่าจะไม่มีงาน Data pipeline เลย ซึ่งงานหนึ่งที่ Data Engineer ทุกคนที่นี่ได้ทำคือการ Migrate Dagster abstraction ของ data pipeline ให้มาใช้ตัวใหม่ครับ ซึ่งผมบอกเลยว่า การไปดูกับการมานั่งทำงานกับ production ready pipeline มันต่างกันเยอะมากครับ นอกจากจะต้องไปค้น Docs ว่า Abstraction ใหม่มัน migrate ยังไงบ้างตั้งแต่ระดับ repository, schedule เรื่อยไปจนถึง resource แล้ว support system, tooling, หรือ workflow ต่างๆ ก็ต้องไปทำความรู้จักกับมันเช่น GitOps, Earthly, หรือแม้กระทั่ง SQL ที่เหมือนจะรู้จักอยู่แล้ว แต่พอเห็นวิธีการเขียนแบบ CTEs รวมถึง Dialect ของแต่ละ Query engine ที่ต้องทำงานด้วยก็ตระหนักได้ว่าเรายังไม่รู้อะไรเลย

โชคดีที่เดือนแรกผมมีวันหยุดยาวอยู่กลางเดือนหลังจากไปทำงานได้อาทิตย์เดียว เลยเป็นช่วงเวลาที่กลับมาตั้งสติได้ดีมาก ซึ่งตัวช่วยทำให้ผมกลับมาเห็นภาพหลายๆ อย่างชัดขึ้นเป็นภาพข้างบน ต้องขอบคุณหนังสือ Designing Cloud Data Platforms เลยครับ เล่มนี้ช่วยดึงสติให้ผมกลับมาเห็น Data Platform ใน Mental model ได้ชัดเหมือนสมัยยังเป็น Software Engineer แล้วมองว่าแต่ละ components ของแอพมันคืออะไร มาทำหน้าที่อะไร ซึ่ง 3 บทแรกจะพาไป รู้จัก Data Platform ก่อน ส่วนบทที่เหลือในหนังสือจะพาไปเจาะลึกทั้ง tools, techniques ของแต่ละ component ตั้งแต่ Ingestion, Processing เรื่อยไปถึง Data Access ซึ่งส่วนตัวผมยังอ่านไม่จบ ถ้าจบแล้วก็น่าจะมีโอกาสมาเล่าให้ฟังกันในบล็อกนี้ครับ เรียกได้ว่าคัมภีร์คู่ใจผมเลยมาจนถึงทุกวันนี้

เดือนที่สอง

งานในช่วงเดือนที่สองมีความแตกต่างขึ้นไปนิดนึง เพราะพอเริ่มเข้าโปรเจ็คจะมีงานในส่วนของ Data Modeling กับ Data Exploration เพิ่มเข้ามา ในส่วนของ Data Modeling เรียกได้ว่าอาศัยประสบการณ์ Backend Engineer มาเอาตัวรอดไปได้ครับในการออกแบบ Schema ของ Data ที่เรา Provide ให้ Consumer ใช้ยังไงให้ตอบโจทย์ requirements และ Maintain ได้สบายไปพร้อมๆ กัน แต่ส่วน Data Exploration นี่เรียกได้ว่าเป็นประสบการณ์ที่แปลกใหม่มาก เพราะเราต้องไปตามหา Data ที่เราต้องการมาตอบโจทย์ Business requirements ความยากนอกจากต้องไปตะลุยทุ่ง Documents, Wiki เพื่อหา Data ที่ต้องการแล้ว ก็ต้องมา Verify ต่อว่าตอบโจทย์ที่เราต้องการจริงๆ มั้ยนะ หรือติด limitation อะไรด้วยรึเปล่า ซึ่งกินพลังชีวิตหนักมากทั้ง 2 ส่วนที่ผมว่าเลยครับ

ในส่วนของ Data pipeline ที่ยังต้องดูแลอยู่แต่พอเริ่มจะใช้ Dagster ได้อยู่มือขึ้น ก็เริ่มเห็นภาพว่าเห้ยการดูแล data pipeline อ่ะ มันไม่ต่างกับการดูแล Software อื่นๆ เลยนะ เพราะตัว pipeline มันมีอายุของมัน มีการ extend มีการ upgrade ฯลฯ เพราะฉะนั้น practices ต่างๆ ของ Software Engineering ในการสร้าง Maintainable software เข้ามาช่วยเยอะมากตอนนี้ครับ

เดือนที่สาม

พอเข้าเดือนที่สามมีโอกาสได้ไปแตะๆ งาน POC Platform บ้าง ผมมีโอกาสไปลอง POC ในส่วนเล็กๆ ที่ decoupling compute engine interface ออกมาโดยใช้ Apache Livy เป็นพื้นฐาน ซึ่งไองาน POC เล็กๆ ที่ว่าพาผมไปรู้จัก Hadoop, YARN, Spark เยอะขึ้นมากกว่าตอนที่ดูเองก่อนหน้านี้เยอะมากว่ามันคุยกันยังไงกว่าจะได้ processing, storage layer ใน Data Platform ขึ้นมาซักตัว

อีกสิ่งหนึ่งที่ค่อยๆ เห็นภาพชัดขึ้นแล้วค่อนข้างเป็น Pitfall หนึ่งของคนใช้งาน Dagster คือ Ops ไม่ใช่ function ซึ่งตอนแรกที่ได้ยินมาผมยังไม่เข้าใจ Dagster มากประโยคนี้เลยยังอยู่ในใจอยู่ แต่พอขึ้น data pipeline เส้นที่สองแล้วเริ่มรู้สึกว่าทำไมต้องมาทำซ้ำด้วยนะ เท่านั้นแหละเหมือนคนตรัสรู้เลย แล้วเส้นแบ่งมันนิดเดียวมากคือ Ops เราต้อง general ระดับนึงแล้วใช้ abstraction ของ Dagster ในการจัดการ input, output หรือ behavior ของ Ops นั้นแทน แล้วพอมองโลก Dagster ผ่านเลนส์นี้เท่านั้นแหละ ผมเห็นโอกาสเต็มไปหมดเลยครับและผมมั่นใจว่าพวกที่ทำ Tooling ในวงการ data ก็เห็นสิ่งนี้เหมือนกันมานานก่อนผมมาก เราเลยได้เห็น ความร่วมมือของ tool หลายๆ อย่างกับ Dagster เช่น Dagster x dbt, Dagster x Airbyte อะไรแบบนี้เป็นต้นครับ

คำแนะนำจากประสบการณ์ต๊อกต๋อยนี้

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

• อย่างแรกเลย มันมีความต่างเยอะมากระหว่างคนที่เป็น Consumer ของ Platform กับคนที่สร้าง Platform ผมเข้าใจภาพนี้ชัดมากถ้ามองย้อนไปตอนผมรู้จัก Spark ใหม่ๆ แล้วก็รู้สึกว่าเอ่อ มันก็ไม่ต่างจาก Pandas ที่เราคุ้นเคยมากนี่หว่า แต่พอต้องประกอบมันขึ้นมาจริงๆ แล้วโลกของ Spark นี่มันกว้างใหญ่โคตรๆ เลยครับ แค่เปลี่ยน Resource manager นี่โลกก็เปลี่ยนแล้ว เพราะฉะนั้นย้ำอีกครั้งว่า มันสำคัญมากที่เราจะต้องเข้าใจ Tooling ที่เราต้องทำงานหรือดูแลด้วยไม่ใช่แค่ใช้เป็น แต่เข้าใจเลยว่ามันทำงาน (ด้วยกัน) ได้ยังไง
• อย่างที่สองผมมาตกผลึกตอนต้องไปทำ Data Exploration นี่แหละครับ ด้วยความที่มันมีสิ่งที่เกิดขึ้นใหม่ๆ ในโลกของ Data ตลอดเวลา ไม่นับ Data Domain ที่เราต้องไปความเข้าใจด้วย สิ่งที่จะเกิดขึ้นตามมาคือ สิ่งที่เรารับรู้มันจะเยอะมาก จนหลายครั้งมันถาโถม วิธีการเอาตัวรอดจากตรงนี้ให้ได้คือ เราต้องจัดการความรู้ของเราเองให้เป็นครับ สามารถกลั่นความรู้ออกมาจากสิ่งที่รับรู้และต่อยอดเพื่อที่จะเข้าใจสิ่งใหม่ๆ ต่อได้ ซึ่งวิธีการที่ผมใช้หลักๆ คือจดครับและแน่นอนว่าเครื่องมือคู่ใจผมยังคงเป็น Notion ไม่ว่าใครจะชวนไปใช้ tooling ตัวไหนก็ตาม 555
• อย่างสุดท้าย ผมไปดู Live ของบอย BigData RPG หลายอาทิตย์ก่อนตอนกำลังดูประกาศรับสมัครงานสาย Data แล้วผมไปสะดุดใจกับคุณสมบัตินึงในประกาศคือ Self-Driven ซึ่งตอนที่ฟังแล้วมามองย้อนกลับไป มันจริงมาก เพราะพอถึงจุดหนึ่งหลังจากเราเริ่มเห็นภาพอะไรชัดขึ้นแล้ว ด้วยความที่ทะเลของงานในสาย Data Engineering มันเยอะมาก เราต้องเป็นคนตัดสินใจเองว่าอยากจะโฟกัสเรื่องอะไร โดยที่ยัง Align กับ Goal ของงานที่ทำอยู่ ต้องรู้ว่าไม่รู้อะไร จะได้ไปเติมสิ่งที่ขาดให้มันเต็ม และต้อง สั่งตัวเองเป็นด้วย เพราะอิสระมาพร้อมกับความรับผิดชอบสูงมาก

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

ปล.ผมชอบคำว่าต๊อกต๋อยมากเวลาได้ยินจากเพื่อนร่วมงานผม เวลาได้ยินแล้วรู้สึก Stand on the shoulder of giant มาก​ ฮ่าๆ

ย้อนไปปีนั้น #ProntoTools กลับมาเล่น Leader กันทั้งทีมเพื่อให้ทุกคนมีสิทธิกำหนดทิศทางของ Policy ต่างๆ ภายในทีมในช่วงระยะเวลาหนึ่งๆ น่าจะประมาณ 1 เดือนถ้าจำไม่ผิด แล้วตอนนั้นผมจับได้เป็น Leader คู่กับโครี่เป็นคู่แรก เลยกำหนด Policy ขึ้นมา 2-3 อย่างแล้ว apply กับทีม Pronto Tools หนึ่งในนั้นคือ #learntoday

#learntoday เป็นไอเดียที่เอาจริงๆ ผมไม่ได้คิดขึ้นมาเองแต่แรกอันนี้ disclaimer ก่อนเลย มันเกิดจากตอนที่นั่งคุยกับโครี่อยู่แล้วอารมณ์ประมาณว่ามันน่าจะดีนะ ถ้าเรารู้สึกว่าเราได้เรียนรู้อะไรในทุกๆ วันชีวิตจะไม่น่าเบื่อเลย แล้วกว่าจะถึงวันศุกร์หรือการจะจัด sharing session กันความตื่นเต้นเวลาเราได้เรียนรู้อะไรใหม่ๆ มันจะหายไปหมดแล้ว เลยคิดว่าต้องหาอะไรที่มัน light weight กว่านั้นมาเป็นช่องทางในการแบ่งปัน เพื่อที่จะให้ทุกคนรู้สึกว่า มันไม่ใช่เรื่องยากเลยที่เราจะ share knowledge ซึ่งกันและกัน

แล้วผมจำได้ว่าย้อนไปไม่กี่เดือนก่อนหน้านี้ผมเคยอ่านบล็อกของ Basecamp ชื่อ “What did you learn at work today?” (https://m.signalvnoise.com/what-did-you-learn-at-work-today/) ซึ่งเล่าให้ฟังว่า DHH เค้าใช้ฟีเจอร์ Automatic check-ins ที่ basecamp ยังไงบ้าง แล้วผมรู้สึกว่าเห้ยนี่มันเป็นไอเดียที่ดีมากเพราะช่องทางการสื่อสารเราเป็นแบบ async ไปเลย แม้แต่ knowledge sharing ก็ตาม

ซึ่งตอนนั้น Pronto Tools ยังไม่ได้ใช้ Basecamp (แต่หลังจากนั้นไม่นานก็ใช้นะ แล้วเราใช้ check-in กันดุเดือดมาก) แต่ใช้ Slack เป็นช่องทางสื่อสารหลักในทีมอยู่แล้ว เลยเกิดไอเดียว่าเห้ยมาสร้างห้องใหม่เป็น #learntoday ดีกว่า แล้วใครรู้อะไรใหม่ๆ สำหรับตัวเองก็พิมพ์ไว้เลย นอกจากจะเป็นประโยชน์กับตัวเองว่า เห้ยเรารู้อะไรใหม่วันนี้นะ หลายคนที่ไม่ได้ทำงานในส่วนเดียวกันมาอ่านดูก็อาจจะได้รู้ท่าใหม่ๆ โดยไม่ต้องทำงานตรงจุดนั้นเองก็ได้ ยังเอาไว้ search หาว่าอ่อเคยทำท่านั้น ท่านี้ตอนนู้นก็สามารถ search หาเจอได้

ซึ่งเอาจริงๆ ตอนคิดตอนแรก ก็ไม่ได้คิดว่าจะใช้ยืนยาวต่อกันมานานขนาดนี้ จนตามไปหลายบริษัทที่ชาว Pronto Tools แยกย้ายกันออกไปด้วย ผมก็มาเห็นอีกทีว่าอ้าวมี #learntoday กันด้วยเหรอนี่ หรืออย่างตัวผมเองที่ใช้ Practice เดียวกับมิวเลยคือมี page: Learn Today อยู่ใน Notion ตัวเอง แล้วก็เขียนไว้ตลอดถ้าได้รู้อะไรใหม่ๆ ซึ่งมันช่วยได้มากจริงๆ สำหรับผมตอนที่ self-esteem เราตกมากๆ ว่าเห้ย เราก็ได้เรียนรู้อะไรใหม่ๆ อยู่ ไม่ได้กากอย่างที่มองตัวเองนี่หว่า และมันทำให้รู้สึกว่าตัวเองยังมีค่าอยู่นะ

สุดท้าย ผมเพิ่งมาค้นพบว่าจริงๆ ไอเดียนี้มันก็มีอีกคนคิดเหมือนกันอยู่ในวงการ Tech อยู่ ถ้าเราสังเกตุใน Twitter จะมีโพสประมาณแบบ #TIL ซึ่งแรกๆ ผมเห็นก็แบบ TIL อะไรวะ แต่พอไปหาดู อ่อมันคือ “today I learned” ซึ่งมันคือไอเดียเดียวกันเลยกับ #learntoday เลยครับ แต่ผมจะไม่เคลมว่าผมคิดก่อน เพราะอย่างที่บอกผมก็ได้ inspiration มาจาก Basecamp อีกที 555

ปล.ขอบคุณ Mils Burasakorn ที่พูดถึง #learntoday ด้วยเห็นแล้วใจฟูมากที่ยังมีคนใช้อยู่ทั้งๆ ที่ผ่านมาหลายปีแล้ว 🥹

⏰ The clock start ticking

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

💌 How to give a resign message

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

อีกคำแนะนำคือให้เวลาคนที่เราจะคุยด้วยซึมซับ Message ด้วยครับ ไม่ใช่จะออกเดี๋ยวนี้ ต้องคุยเดี๋ยวนี้เลย จะบินแล้วโว้ย ไม่ได้ครับๆ ถ้าให้อีกฝ่ายเลือกเวลาจะช่วยให้เค้ามีเวลาคิดอะไรมากขึ้น แต่อย่างที่บอกครับ เวลาเริ่มนับตั้งแต่วินาทีที่เรากด Enter ไปแล้วนั่นแหละ

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

อ่อและสิ่งหนึ่งที่ไม่ควรลืมเลยในการสนทนาคือ วันสุดท้ายที่เราจะทำงานกับทีมครับ เพราะเค้าจะได้เริ่มคิดถึงการหาคนมาทดแทนเราได้ หรือเริ่ม process ในการลบ Credentials ต่างๆ ออกจากระบบว่าต้องเสร็จเมื่อไรครับ

อีกอย่างนึงคือ การคุยกันอาจจะมีมากกว่าหนึ่งรอบครับ ก็ใจแข็งๆ ไว้นะครับ ช่วงนี้อึดอัดที่สุดละ แต่ถ้าผ่านไปได้ ที่เหลือไม่มีอะไรยากแล้วครับ

🌥 Lower your light

พอผ่านขั้นตอนแรกมาแล้ว ขั้นตอนต่อมาจะใช้เวลายาวนานหน่อยหรือก็คือตลอดช่วงเวลาที่เรานับถอยหลังอยู่ คือเราต้องค่อยๆ ลดบทบาทตัวเองในทีมลงครับ ซึ่งของพวกนี้ต้องค่อยๆ ให้ทีมซึมซับไป ในขณะเดียวกันเราเองก็ต้องปรับพฤติกรรมด้วย ยกตัวอย่างเช่น

• เวลา Meeting ถ้าเราเป็นคนที่ออกความเห็นบ่อย หรือมีคน Engage มาหาเราบ่อย สิ่งที่เราต้องเริ่มทำเวลานี้คือ หาตัวตายตัวแทนครับ แรกๆ Message มันจะเข้ามาหาเราอยู่ดี เราต้องคอยเตือนตัวเองอยู่ตลอดว่า เราต้องให้คนที่อยู่ข้างๆ เรา Step up ขึ้นมารับแล้วนะ ในกรณีที่เค้าไม่เคยรับ
• เวลามีน้องมาถามว่าทำนู้น ทำนี่ดีมั้ย ทำไงต่อดีพี่ สิ่งที่เราทำได้คือบอกน้องไปตามตรงว่า “พี่ไม่อยู่แล้วนะ ตัดสินใจเองเลย” แรกๆ น้องอาจจะไม่ชิน เพราะของมันเคยทำมาหลายเดือน จังหวะนี้อาจจะมีหลุดมาถามบ้าง ก็อาจจะช่วยตัดสินใจบ้าง ขึ้นอยู่กับเรา แต่พยายามอย่ามากเกินไปครับ

ถ้าเราเป็นคนนึงที่รู้สึกว่ามีความรับผิดชอบเต็มมือ แล้วพอเริ่มปล่อยมือแล้วมันเหงาๆ เบื่อๆ ก็ทำใจร่มๆ ไว้นะครับ ถ้าเรายังต้องทำแบบเดิมอยู่นั่นคือการทำร้ายทีมแบบตั้งใจเลยครับ ผมบอกได้แค่ว่า just let it go ซึ่งถ้ารู้สึกแบบนั้นจริงๆ คำแนะนำผมคือ เริ่มศึกษางานใหม่ไว้ก่อนเลยก็ดีนะครับ ว่าควรจะต้องรู้อะไรบ้าง ถ้าสมมติงานที่เราทำมันต่างไปจากเดิมทั้ง Business และ Tech จะช่วยลดความเบื่อลงไปได้บ้างครับ แต่สิ่งสำคัญคือ เรายังทำงานกับทีมปัจจุบันอยู่ เพราะฉะนั้นเคารพเวลาที่เราทำงานกับทีมตามที่ตกลงกันไว้ด้วยก็พอครับ

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

📚 Setting up your replacement to win

ผมได้ไอเดียนี้มาตอนอ่าน Designing Your Work Life ตอนช่วงหนึ่งเดือนสุดท้ายนี่แหละครับ ซึ่งไอเดียของมันคือ ถ้าเรามีโอกาสได้คุยกับคนที่จะเข้ามาแทนที่เรา เราอยากจะบอกอะไรเค้า อาจจะดูเหมือนยาก แต่จริงๆ แล้วสำหรับผมสนุกมากครับ เพราะตอนเราเขียนมันจะมีความรู้สึกแบบปรารถนาดี อยู่ในข้อความเราโดยอัตโนมัติ แล้วความรู้สึกของการได้ช่วยใครซักคนที่จะมารับช่วงต่อจากเรานี่ ผมบอกได้เลยว่ามันเติมเต็มจิตใจมากครับ ถึงเราจะไม่เคยเจอหน้า หรือไม่มีโอกาสที่จะได้เจอเค้าก็ตาม

ซึ่งเอาจริงๆ เหมือนขั้นตอนนี้น่าจะใช้เวลานาน แต่ผมใช้เวลา 1 วันเต็มๆ เขียนก็เสร็จแล้วครับ หัวข้อที่เขียนอันนี้แล้วแต่เราเลยว่าเราอยากให้เค้ารู้อะไรบ้างตัวอย่างที่ผมเขียนจะมี

• ทีมนี้เกิดขึ้นมาได้ยังไง
• อะไรคือความรับผิดชอบเรา
• สิ่งที่เราต้องทำในแต่ละวัน
• ช่องทางการติดต่อสื่อสารต่างๆ ที่เกี่ยวกับทีม
• Key Person ในทีมหรือที่เราต้องติดต่อด้วยมีใครบ้าง
• แหล่งข้อมูลต่างๆ ที่เกี่ยวกับงานที่เราทำจะไปหาได้ที่ไหน
• สิ่งที่เราต้องรู้ ถ้าจะทำงานให้ได้ดีเช่น เทคโนโลยีที่เราใช้หรือ Architecture ของงาน

คำแนะนำอีกอย่างผมคือ พยายามเขียนในแบบที่เราอยากอ่านครับ แล้วเราจะเขียนมันออกมาได้ดีเอง พอเขียนเสร็จแล้วเราก็ฝากไว้กับคนที่เราคุยด้วยตอนแรกนั่นแหละครับ เพื่อให้เค้าส่งต่อให้คนที่มาแทนเราต่อไป

🌻 The Final Gratitude

ผมเชื่อว่าหลายคนจะทำสิ่งนี้ในวันสุดท้าย ซึ่งผมก็ทำวันสุดท้ายเหมือนกัน เรียกได้ว่าไม่กี่ชั่วโมงสุดท้ายด้วย ผมบอกได้เลยว่ามันคือความทรงจำดีๆ สุดท้ายที่เราจะสามารถมอบให้กับทีมได้ครับ เพราะหลังจากนี้ปัญหาหรืออะไรต่างๆ ที่เป็นความทรงจำไม่ดี มันไม่ได้ตามเราไปด้วย เพราะฉะนั้นใช้เวลาให้คุ้มค่าครับ

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

และสิ่งที่อยากจะย้ำอีกอย่างคือ หลายครั้งจุดนี้มันเป็นแค่การจากลากันชั่วคราวครับ หลังจากนี้อีก 2 ปี 5 ปี 10 ปี สุดท้ายเราอาจจะวนเวียนกลับมาได้ทำงานกับหนึ่งในคนที่เรากล่าวลากันในวันนี้ก็รักษาน้ำใจกันไว้ดีๆ นะครับ

หมดแล้วครับ กว่าจะมาถึงวันสุดท้าย ผมหวังว่าคำแนะนำผมจะมีประโยชน์กับคนอื่นบ้างนะครับ 👋

Traditional Leader

ก่อนที่จะพูดถึงคำว่า Emergent Leadership ต้องย้อนกลับไปถึง Traditional Leader ก่อน ก่อนหน้านี้มาตลอดชีวิต (ใช่! ต้องใช้คำว่าตลอดชีวิต) ผมมีความเชื่อว่าถ้าเราจะเปลี่ยนแปลงอะไรบางอย่างให้ได้ เราต้องมี Power และการจะมี Power ได้เราต้องมี Role ต้องมีตำแหน่ง หรืออะไรก็แล้วแต่นะ ในการที่จะมอบ Power ให้เราสามารถเปลี่ยนแปลงบางอย่างได้

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

นอกจากนี้ผมบอกเลยว่า พอเรามี Role มีตำแหน่ง อยู่ข้างหลัง ไม่ว่าจะเป็น Senior, Lead, Manager หรืออะไรก็ตามติดหลังอยู่ เราจะมีความมั่นใจมาก (แต่ตอนนั้นยังไม่รู้สึกนะ) เวลาเราออกไปเจอคนอื่น ซึ่งอันนี้พอผมมามองย้อนกลับไปมันไม่ใช่เรื่องแปลกเลย เพราะโครงสร้างอำนาจทางสังคมที่ผมโตมาตลอดชีวิต มันนำให้เราต้องทำแบบนี้

My Story

ยังครับ ยังไม่ถึง Emergent Leadership เพราะพูดเลยอาจจะไม่เห็นภาพ ผมเลยจะมาโม้เรื่องราว Once in a life time ของผมและสิ่งที่ผมเพิ่งมาเรียนรู้ใน 3 ปีที่ผ่านมาให้ฟัง แต่ถ้าอดทนอ่านไม่ไหวอยากรู้ว่า Emergent Leadership คืออะไร ข้ามไปหัวข้อถัดไปได้เลยครับ

ย้อนกลับไปทีมแรกในเรื่องราวนี้ เรามีภารกิจต้องส่งมอบซอฟท์แวร์ตัวนึงซึ่ง ทั้งทีมไม่มีประสบการณ์ทำทั้งหมดเลย และยิ่งกว่านั้นคือไม่รู้จะเริ่มต้นยังไง สิ่งที่ผมตัดสินใจทำในเวลานั้นคือ “เราต้องเป็นคนนำทุกอย่างเอง เพราะเราเชื่อว่าเราเก่งที่สุด” (ขึดเส้นใต้คำนี้เลย) ซึ่งโอเคมันทำให้งานมันเดินหน้าไปได้ แต่ผมเหนื่อยมาก เพราะพอเราเชื่อแบบนี้ เราเลยคาดหวังสูงมากในสิ่งที่เรานำคนในทีมไป แล้วพอทีมทำไม่ได้ในสิ่งที่เราหวัง การผิดหวังสะสมมากขึ้นเรื่อยๆ มาวันนึงมันก็ระเบิดออกในวันสุดท้าย ซึ่งมันควรจะเป็นวันที่เราฉลองความสำเร็จ แต่กลับผิดหวังแทนและเราจมอยู่กับความผิดหวังนั้นนานใช้ได้เลย

ทีมที่สอง ต้องบอกว่าผมก็ลืมเรื่องก่อนหน้านี้ไปเลย เพราะเราได้เริ่มต้นใหม่และเราเด็กที่สุด เราก็ทำงานไปเรื่อยๆ ไม่ได้คิดอะไร แต่พอถึงจุดนึงช่วงใกล้ๆ จะทำงานครบปีแรก มันมีเหตุการณ์หลายเหตุการณ์มากที่ทำให้มันวนกลับมาตั้งคำถามว่า “เราจะอยู่รอดได้ยังไง"​ ซึ่งพอระบบมันตั้งคำถามแบบนี้ คำตอบอัตโนมัติ มันเลยเป็นคำตอบเดิมว่า “เราต้องเป็นคนนำทุกอย่างเอง เพราะเราเชื่อว่าเราเก่งที่สุด” พอคำตอบเป็นแบบนี้ตอน Review Performance สิ่งที่ผมทำคือ ผมบอกหัวหน้าผมว่า ผมอยากเป็นลีดนะ แล้วก็บอกเหตุผลกับเรื่องราว 1 2 3 4 หัวหน้าก็คุยกันอยู่แปปนึงสองคน แต่สุดท้ายผมก็ได้ Role นั้นมาและเป็นสิ่งที่ผมเข้าใจว่าผมได้ Power สำหรับการเปลี่ยนแปลงแล้ว

แต่ครั้งนี้ต่างออกไปจากทีมแรกที่พูดถึงข้างบน ความสัมพันธ์ของผมกับคนในทีมมันไม่ได้สร้างมาแบบนั้นแต่แรก เราเป็นเพื่อนกันมาตลอด แล้วอยู่มาวันนึงเราต้อง step up ขึ้นมา ตอนนั้นผมจำได้เลยว่าผมทำตัวไม่ถูก เพราะไม่รู้ว่าต้องทำไง แต่ตอนนั้นดันมีความเชื่อผิดๆ ประมาณว่าเราต้องไม่เหมือนเดิม พอผ่านมาผมเลยเริ่มที่จะวางตัวอีกแบบกับเพื่อนร่วมทีม แล้วลึกๆ ผมอึดอัดมากเพราะเชื่อว่าเราเป็นเพื่อนกันเหมือนเดิมไม่ได้แล้ว ถ้ามามองย้อนกลับไปตอนนี้ผมเดาว่าทำแบบนั้นไปเพื่อที่จะให้คนรอบตัวรู้ว่าผมมี Power นะ อะไรแบบนี้ ซึ่งเป็นเรื่องที่ผิดมาก เพราะมันไม่จำเป็นต้องทำอย่างนั้นเลย กว่าผมจะรู้ตัวเรื่องนี้ก็ผ่านมาซักพักนึงแล้วพี่ในทีมก็ให้ Feedback มาว่า ผมเปลี่ยนไปนะ ทำแบบนี้มันไม่โอเคนะ นั่นแหละผมเลยเข้าใจเรื่องนี้แล้วกลับมาเป็นเหมือนเดิม

ทีมที่สาม นี่แหละที่เรื่องราวมันจะต่างออกไปจากที่ผ่านมา ด้วยระบบความคิดที่ยังเชื่อว่า เราต้องมี Power และ Role นะถึงจะเปลี่ยนแปลงอะไรได้ และเราต้องไปอยู่ในจุดสูงสุดเราถึงจะบอกได้ว่าไปซ้ายสิ ไปขวาสิ ทุกการกระทำมันเลยออกมาคล้ายๆ หนังม้วนเดิมจากสองทีมที่ผ่านมา แต่สิ่งที่ต่างออกไปคือ ทีมไม่ได้เออ ออ ห่อหมกไปกับผมทุกเรื่องอีกแล้ว ผมโชคดีมากที่ทีมที่นี่คุยกันด้วยเหตุผลเยอะมาก แต่ตอนนั้นผมยังไม่เข้าใจหรอก สิ่งที่ผมเข้าใจตอนนั้นคือ สิ่งที่เราต้องการมันไม่ได้รับการตอบสนอง แล้วสิ่งที่แย่กว่าเข้าใจแบบนั้นคือการตัดสินใจว่า “อยากทำอะไรทำเลย เราจะไม่ออกความเห็นแล้ว” ซึ่งในความคิดเนี่ย มันคือความต้องการการรับฟัง แต่ผมเข้าใจว่าทีมไม่ได้รับฟังผมอีกแล้ว ซึ่งเป็นความคิดที่เข้าใจผิดไปไกลมาก

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

ทีมที่สี่ ก่อนจะมาถึงทีมที่สี่ต้องบอกเลยว่าสภาวะที่อยู่ก่อนหน้านั้นมันทำลายความมั่นใจทุกอย่างที่ผมเคยเชื่อไปเยอะมากและ Review performance จังหวะก่อนที่จะมาอยู่กับทีมที่สี่นี่คือจุดเปลี่ยนเลย ถ้ามามองย้อนกลับไปผมว่าครั้งนี้แหละที่ผมเปิดรับทุก Feedback แล้วจะเอาไปแก้ให้หมด เพราะมันไม่มีอะไรจะเสียแล้ว แล้วต้องการหาทุกทางที่จะออกจากสภาวะก่อนหน้านี้ไปให้ได้

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

ผมวาง Role และความอยากได้ Power อะไรทิ้งออกไปเยอะมาก แล้วเลือกที่จะเริ่มต้นใหม่หมด แต่ไม่ใช่วิธีเดิมอีกต่อไปแล้ว ผมไม่ได้เชื่อแล้วว่า เราทำ เราเก่ง เราจะได้ Power แต่กับทีมนี้ หลังจากที่อยู่มาความคิดมันเปลี่ยนไปเป็น เราเชื่อว่าเพื่อนร่วมทีมเราจะทำได้และเราจะช่วยเค้าเต็มที่เพื่อให้เค้าทำได้ (โดยที่เราไม่เป็น Hero) อาจจะฟังดู Abstract แต่ผมมีตัวอย่างง่ายๆ ครับ สมมติคนในทีมติดอะไรแล้วขอความช่วยเหลือ ก่อนหน้านี้ผมสารภาพเลยว่าเวลาเห็นคนพิมพ์ช้า พิมพ์ผิด พิมพ์ถูก ผมจะรำคาญมากแล้วจะ end up ด้วยการแย่งคีย์บอร์ดคนๆ นั้นมาพิมพ์เอง เพื่อให้มันผ่านไปได้ แต่พอเราเชื่อว่า เพื่อนร่วมทีมเราจะทำได้ มันยากมากที่ผมจะหยิบคีย์บอร์ดมาพิมพ์เองเลย แต่จะเอาใจช่วยให้เพื่อนร่วมทีมของผม ทำเรื่องนั้นสำเร็จได้ด้วยตัวเอง แล้วผมบอกเลยว่าเรื่องนี้เกิดขึ้นบ่อยจนผมเห็นผลตามมาเลยครับ

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

ถ้าเป็นเมื่อก่อนผมบอกเลยว่า พอเห็นคนหันมาอย่างนี้ผมจะรู้สึกเลยว่าเรามี Power ละและทีมคาดหวังเราอยู่ เราต้องไม่ทำให้เค้าผิดหวังซิ แต่นั่นคือ Hero ครับ ตอนผมรู้ตัวเรื่องนี้ผมก็เลยคิดค้นวิธีหลบเรื่องนี้ขึ้นมาคือ จังหวะที่ทีมหันมาหาผมทั้งทีม แทนที่ผมจะแก้ปัญหา ผมหันไปถามคนในทีมซักคนแทนด้วยคำถามง่ายๆ ว่า “เราคิดว่าไง” ง่ายๆ อย่างนั้นเลยครับ และเวิร์คทุกครั้ง ฮ่าๆ

ผมโชคดีมากตอนที่ผมมาอยู่ทีมที่สี่เราให้ Feedback กันบ่อยมากครับทั้ง 1:1 หรือ Retrospective เราจะรู้ตัวเองตลอดว่าสิ่งที่เราทำไปมันส่งผลกระทบแค่ไหน และเพราะการให้ Feedback ตลอดนี่แหละ เลยเป็นเครื่องยืนยันว่าผมเปลี่ยนความคิดไปแล้วจริงๆ มันมีเหตุการณ์นึงที่ยืนยันเรื่องนี้คือ มีครั้งนึงผม Vacation leave ไปหลายวันมาก แล้วหลังจากผมกลับมาแปปนึงก็ Retrospective พอดี แล้วน้องในทีมก็ให้ Feedback มาประมาณว่า “ขาดผมไปรู้สึกเหมือนขาดที่พึ่งทางใจ” จังหวะที่ผมเห็นโพสอิทใบนี้ ผมคิดในใจเลยว่า “ชิปหายแล้ว! เราเผลอเป็น Hero อีกแล้วเหรอวะ” ซึ่งผมมั่นใจเลยว่าถ้าเป็นผมก่อนหน้านี้ผมน่าจะยิ้มอยู่ในใจว่าเราได้ Power มาละ แต่จุดนี้ผมบอกได้เลยว่า ผมไม่ได้อยากได้ ผมอยากให้ทีมทำงานกันเองได้ แล้วผมจะได้ไปทำอย่างอื่นที่ผมอยากทำ

Emergent Leadership

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

หน้าที่ของ Emergent Leadership ในแบบที่ผมเข้าใจคือเราจะไม่ชี้ว่าไปซ้ายไปขวานะ แต่เราจะมีหน้าที่ทำให้ทีมเข้าใจว่าไปซ้ายแล้วจะเกิดอะไรขึ้นบ้าง ไปขวาแล้วจะเกิดอะไรขึ้นบ้าง แต่สุดท้ายแล้วการตัดสินใจอยู่ที่ทีมครับว่าจะไปทางไหน ซ้ายหรือขวา ซึ่งสุดท้ยแล้วมันอาจจะไม่ตรงกับที่เราคิดก็ได้ แต่สิ่งที่เราได้มาคือ ทีมได้ Ownership ของการตัดสินใจนั้นไปเลยโดยที่ไม่ต้องมาเกิดคำพูดทีหลังว่า นี่ถ้าตอนนั้นเราไปแบบนี้นะ…​ เพราะทุกคนตอนนี้รับผิดชอบร่วมกันไปแล้ว แล้วทุกคนจะมีอิสระที่จะทำอะไรก็ได้ให้เกิดผลลัพธ์ดีที่สุดสำหรับตัวเองและทีม ด้วยเป้าหมายเดียวกันไปโดยอัตโนมัติเลยครับ

Trust-Respect-Honest

ต้องบอกว่าหลังจากเรื่องราวทั้งหมดผมเลยเข้าใจคำว่า Emergent Leadership ครับ แต่บอกได้เลยว่าคำๆ นี้ไม่ได้อยู่ในหัวเลย ต้องบอกว่าพอความเชื่อเรื่อง Traditional Leaders ผมโดนทำลายลง ในหัวผมเริ่มพัฒนาความเชื่อขึ้นมาใหม่ครับ จิงๆ ต้องบอกว่าสภาพแวดล้อมทำให้ผมเชื่อเรื่องนี้ด้วย แล้วผมสรุปออกมาเป็น 3 value ที่สนับสนุนซึ่งกันและกัน

อย่างแรกเลยคือ Trust ครับ จากโมเม้นต์ที่ผมเชื่อว่าผมเก่งที่สุดไปจนถึงทีมติดปัญหาแล้วผมไม่จับคีย์บอร์ด อันนี้คือพัฒนาการเรื่อง Trust เลยครับ คือผมคิดว่าเราควร “เชื่อใจ"​ เพื่อนร่วมทีมให้มาก เชื่อว่าเค้าจะทำงานได้สุดความสามารถที่เค้ามีเพื่อที่จะแก้ปัญหาต่างๆ ไปได้

อย่างที่สองคือ Respect ครับ อันนี้ผมเชื่อว่า ไม่ว่าเค้าจะเพิ่งมาทำงานใหม่ๆ หรือเป็นเพื่อนร่วมทีมที่ประสบการณ์โชคโชน การที่เรา “ความเคารพ"​ ในความคิดเห็นของทุกคนสำคัญมากครับ เพราะเราจะได้เรียนรู้สิ่งใหม่ๆ อยู่เสมอและเราอาจจะเจอทางที่เราคาดไม่ถึงก็ได้

อย่างที่สามคือ Honest ครับ ต้องบอกว่าตอนแรกผมคิดได้แค่ 2 ข้อบนมานานมากแต่ก็รู้สึกว่าอะไรบางอย่างมันขาดไปจนมาเจอข้อนี้ครับ การที่เรา “ซื่อสัตย์” กับตัวเองว่าเราจะทำงานเต็มความสามารถที่เราทำได้ เราจะแสดงความคิดเห็นในสิ่งที่เราคิดจริงๆ เป็นสิ่งสำคัญมาก เพราะมันช่วยให้ทีมสามารถไปต่อได้ในกรณีที่เกิดความขัดแย้งครับและทำให้เราไม่ต้องมาเสียใจกับการตัดสินใจต่างๆ ทีหลังครับ

และผมขอเสริมทั้งสามข้ออีกว่า ทุกข้อที่ผมพูดมานี่ Go both way ครับคือของแบบนี้เราทำคนเดียวไม่ได้ แต่ต้องเกิดขึ้นกับทุกคนในทีม แต่ผมก็เชื่อว่าเราไม่ต้องรอให้คนอื่นเริ่มก่อนก็ได้ครับถ้าอยากได้สิ่งนี้ เราเริ่มจากตัวเองก่อนได้เลย และถ้าสุดท้ายแล้วมันไม่ go both way เราก็ยังสามารถไว้อาลัยกับความต้องการเหล่านี้ของเราได้อยู่ครับ

สุดท้ายแล้วต้องขอบคุณพี่เก๋ พี่กานต์ และทุกๆ คนที่ผ่านเข้ามาในชีวิตในเรื่องราวที่ผ่านมาที่สอนให้ผมรู้จักคำนี้ และทำให้ผมแขยงคำอย่างเช่น Senior, Lead, Manager ฯลฯ ไปอีกนานเลย

Original Post at: https://yothinix.blogspot.com/2020/03/emergent-leadership-most-important.html

ยิ่งพอเรามาอยู่ในสถานการณ์ที่ต้อง Work From Home กันหมดและต้องเปลี่ยนรูปแบบการสื่อสารมาอยู่บน Text, Voice (Discord) มากขึ้น วิธีการถามหลายๆ อย่างที่เคยใช้ได้ ก็ไม่ค่อยเวิร์ค ช่วงอาทิตย์ที่ผ่านมาผมเลยพยายามสังเกตุตัวเองเหมือนกันว่า “เราตอบคำถามยังไง” ก็เลยค้นพบ Set of practice ที่ผมใช้มาซักพักละ เลยออกมาเป็นบล็อกนี้ และต้องบอกก่อนว่าหลายๆ อย่างผมก็ไม่ได้คิดเองเลย แต่น่าจะเกิดจากการไปอ่าน ไปเรียน หรือได้ยินมา เลยต้องสารภาพตามตรงว่า จำไม่ได้จริงๆ ว่าไปรู้เทคนิคนี้มาจากไหนครับ

🤔 ถามยังไงให้ง่ายกับคนตอบ

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

• กำลังทำอะไรอยู่
• เกิดอะไรขึ้น
• เราคาดหวังว่ามันจะเป็นยังไง

เดี๋ยวผมจะลองยกตัวอย่างก่อนที่จะเข้า Format กับหลังปรับ Format แล้วนะครับ

• Before: ทำไมมันมีให้เลือกแค่ support เองอ่ะ
• After: ผมกำลังใช้ admin user ทำการสร้าง user ใหม่ ทำไมในระบบผมถึงมีให้เลือกประเภท user แค่ support นะ ทั้งๆ ที่ user ผมควรสร้างได้ทุกแบบสิทั้ง admin, support, finance

ซึ่งถ้าเราสังเกตุดีๆ จะค้นพบว่า เห้ยนี่มันรูปแบบเดียวกับ AAA Pattern เวลาเราเขียน Unit Test เลยนี่น่า สำหรับใครที่ไม่รู้เคยได้ยิน AAA Pattern มาก่อนนะครับ มันคือรูปแบบการเขียนโค้ดของตัว Unit test ให้ออกมาอยู่ใน Structure ที่เราสามารถมองแว็บเดียวแล้วเข้าใจได้เลย โดยแทนที่เราจะเขียนเทสโค้ดออกมาเป็นก้อนๆ เราจะแบ่งเป็น 3 กลุ่มใหญ่ๆ แล้วขั้นด้วย Blank line เป็น

• Arrange — การ setup ก่อนที่จะทำการเทสเช่นสร้าง database, mock request ฯลฯ
• Act — การเรียกระบบที่เราสนใจ ส่วนใหญ่เป็นการ call function/method
• Assert — การทดสอบว่าสิ่งที่คืนมาจากระบบเป็นไปอย่างที่เราคาดหวังไว้

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

🤗 ตอบยังไงให้ง่ายกับคนถาม

ถึงแม้ว่าคำถามจะถูก Format มาแล้วก็ตาม แต่สิ่งนั้นก็ไม่ได้รับประกันว่าทั้งสองฝ่ายจะเข้าใจตรงกันเสมอไปครับ เพราะฉะนั้นในฝั่งคนตอบผมมี 2 Practice ที่จับขึ้นมาได้ในช่วงอาทิตย์ที่ผ่านมาครับ

อย่างแรกเลยคือ บริบท (context) หลายๆ ครั้งที่คนที่มาถามเรา ไม่ได้มี Knowledge Domain ที่เรามีและเราจะเจอสถานการณ์ที่คนถาม ถึงแม้จะใช้ Format ว่ากำลังทำอะไรอยู่แล้ว แต่เราจะสัมผัสได้ว่ามีการใช้ พระเอก ใน Context นั้นปนๆ กันไปหรือสลับกันไปมา ซึ่ง สำหรับคนตอบมันคือ สัญญาณว่าคนถามยังไม่เข้าใจ context ของสิ่งที่ตัวเองถามทั้งหมด

เพราะฉะนั้นในฐานะคนตอบ ถ้าเราสัมผัสได้ว่าคนถามอยู่คนละ Context กับเราแล้ว สิ่งแรกที่ควรทำคือ “พาเขามาอยู่ใน Context เดียวกันก่อนครับ” ซึ่งจะใช้เวลานานแค่ไหนขึ้นอยู่กับว่า Scope ของคำถามใหญ่แค่ไหนด้วย แต่มันสำคัญที่ต้องปูพื้นฐานก่อน เพื่อที่จะลดคำถามที่ตามมาในช่วงที่เราตอบคำถามจริงๆ ไปได้ครับ

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

💬 “ผมตอบคำถามคุณไปรึยังนะ”

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

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

เทคนิคก็จะประมาณนี้ครับ ที่ผมสังเกตุเห็นกับตัวเองในหนึ่งสัปดาห์ที่ผ่านมา สิ่งสุดท้ายที่อยากฝากคือ ทุกครั้งที่เราถามหรือตอบคำถาม “พยายามเอาใจเขามาใส่ใจเรา” ครับ สำหรับผมถ้ามีคนมาขอความช่วยเหลือ ผมจะคิดเสมอว่าอีกฝั่งเค้าพยายามหาทางออก จนสุดความสามารถของตัวเองละ ถึงจะมาขอความช่วยเหลือ เพราะมันต้องรวบรวมความกล้ามาก ในการมาถามคำถามครับ

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

แต่ก็จังหวะพอดีที่คอร์สนี้ผมเรียนอยู่บน emacs ผมที่ค่อยๆ ใช้งานหนักขึ้นเรื่อยๆ เพื่อให้ตอบโจทย์การใช้งานที่สุด โพสนี้เลยจะเล่าว่าผมใช้ Emacs REST cilent ยังไง แล้วก็จะเปรียบเทียบ use case เดียวกันเทียบกับ REST client บน Intellij กับ VSCode ด้วยครับ

Installing

สำหรับ emacs สามารถโหลดจาก MELPA ได้จาก package ชื่อ restclient ครับ แต่ถ้าใครใช้ Doom ก็เพียงแค่เปิด option rest ; Emacs as a REST client ในไฟล์ init.el แล้วสั่ง doom reload ก็พร้อมใช้งานแล้วครับ

Basic Usage

วิธีการใช้งานของ restclient ทั้งสามเจ้าที่ผมพูดถึงข้างต้นจะคล้ายๆ กันหมดครับ คือให้เราสร้างไฟล์นามสกุล http ขึ้นมาหลังจากนั้นเราก็เขียน Request ลงไปครับ เหมือนตัวอย่างนี้

POST http://localhost:8081/todos
Authorization: Bearer token
Content-Type: application/json

{
  "text": "test request"
}

ซึ่งเราจะเห็นได้ว่ามันจะมีส่วนประกอบหลักๆ อยู่ 4 ส่วนคือ

• HTTP Method — ตรงนี้เราจะใส่เป็น GET, POST, PUT, PATCH, DELETE แล้วแต่เราเลย
• HTTP Endpoint — เป็น URL ที่เราจะไป consuming REST service ครับ
• Request Header (Optional) — ตรงนี้เป็นส่วนที่เราจะใส่ Request header เช่น Authorization หรือ Content-Type เป็นต้น ถ้าใส่ตัวใหม่ก็เคาะบรรทัดใหม่ แต่มีข้อแม้ว่าต้องติดกับบรรทัดที่เป็น Method + endpoint เสมอครับ
• Request Body (Optional) — ตัวนี้แล้วแต่ method ครับ แต่ถ้าเราต้องใช้ให้เคาะ เว้นบรรทัดมาจาก header 1 บรรทัด แล้วใส่ body ไปได้เลย แล้วแต่ type ที่เราตั้งไว้ ซึ่งในเคสข้างบนเป็น JSON ครับ

พอเราเตรียม Request query เรียบร้อยแล้ว เราสามารถสั่งให้ emacs เรายิง HTTP request ไปตามที่เราเขียนไว้โดยเลื่อน cursor ไปไว้ที่บรรทัด HTTP Method ครับ หลังจากนั้นกด C-c C-c ก็จะเป็นการยิง request ออกไปครับ ซึ่งถ้าเราไม่เคยยิงมาก่อนมันจะเปิด buffer window ของ HTTP Response ให้อัตโนมัติครับ

ซึ่งมันจะโฟกัส cursor มาที่ window ของ response อัตโนมัติด้วยครับ โดยเราสามารถสลับกลับไปที่ window ของไฟล์ http เราได้โดยกด C-x o ครับ

Tricks

จริงๆ รู้แค่ข้างบนก็พอใช้งานได้แล้ว 80% ครับ แต่เพื่อความสะดวกสบาย ผมมีทริก 3 อย่างที่ใช้บ่อยมาก หลังจากใช้ emacs REST client ตัวนี้มากซักพัก

เทคนิคแรกคือ เวลา cursor ของเราดีดมาที่หน้า response แล้วเราต้องคอย Switch กลับบ่อยๆ มันก็น่ารำคาญครับ ซึ่งเทคนิคนึงที่ช่วยได้คือ ให้เราสั่ง request โดยใช้ C-c C-v แทนครับ วิธีนี้จะทำให้มันไม่โฟกัสไปที่ Buffer ของ HTTP Response ถ้าเราต้องการแค่ดูผลลัพธ์เฉยๆ

เทคนิคที่สองคือ หลายๆ ครั้งการเขียน Request ของเรามันจะมีชื่อซ้ำๆ หรือใช้ Header ซ้ำๆ ใช่มั้ยครับ พอเราไม่อยากเขียนซ้ำหรือต้องแก้หลายที่ ตัว emacs REST client รองรับการสร้าง variable ด้วยในตัวโดย เราสามารถเขียนเป็น

:base_url = http://localhost:8081

หลังจากนั้น เราก็เอาตัวแปรนี้ไปใช้ได้อย่างเช่นในเคสนี้ผมจะเอาไปใช้กับ endpoint ผมก็สามารถเขียนแบบนี้ได้เลย

GET :base_url/tokenz

ซึ่งนอกจาก การแทนที่ variable แบบง่ายๆ นี้แล้ว เราสามารถทำ multiline variable ได้ด้วย โดยเปลี่ยนจาก = เป็น = << ซึ่งสามารถไปดูได้ใน GitHub ของ library นี้ได้เลยครับ

เทคนิคสุดท้ายคือ เป็นเรื่องธรรมดามากที่เราจะมีการป้องกัน API เราด้วย Authentication method แล้วเราต้องมาแปะ token ที่ยิงขอจาก API นึงมาใช้กับ API อื่นๆ ใน emacs REST client ตัวนี้เราสามารถทำได้เหมือนกันครับ โดยทำตามนี้

ใน Request ที่เราทำ Authentication แล้วเราได้ Token กลับคืนมาใน Response ให้เราใส่ Hook ตัวนี้ลงไปหลัง Request ที่เราทำการขอ Token ครับCOPY

 -> run-hook (restclient-set-var ":newtoken" (cdr (assq 'token (json-read))))

จะมีจุดสังเกตุอยู่ 2 จุดคือ

• “:newtoken” ตัวนี้คือชื่อตัวแปรที่เราจะเซตให้กับ token ที่เราอ่านขึ้นมาได้ครับ

‘token ตัวนี้เป็น key ใน response body ที่เราจะไปอ่านค่าของ token ขึ้นมาครับ

นอกจากนั้นจะเป็น function ที่ restclient.el เตรียมมาให้เราในการอ่านค่าจาก Response JSON ครับ

ใน Request ของ protected resource เราสามารถนำตัวแปรนั้นไปใช้ได้เหมือนกับวิธีการใช้ตัวแปรตัวอื่นเลย อย่างเช่นในเคสนี้ผมเอาไปใส่ไว้ใน Authorization header ครับ

 POST http://localhost:8081/todos
 Authorization: Bearer :newtoken

เพียงแค่นี้เราก็จะสามารถใช้ reuse authentication token กับ request อื่นๆ ได้แล้วครับ ซึ่งจริงๆ ตัว Library นี้ยังมีฟีเจอร์อื่นๆ อีกด้วยครับ สามารถลองกดคีย์ดูได้ ยังมีอีกหลายฟีเจอร์ที่ผมยังไม่ได้ใช้เลย

Comparison with Intellij REST client and VSCode REST client

ไหนๆ ก็พูดถึง Emacs แล้วก็ขอเทียบกับ REST client แบบเดียวกันของ Intellij กับ VSCode เลยละกันว่ามันมีข้อดีข้อเสียต่างกันยังไงบ้าง

เทียบกัน 3 เจ้า ถ้าไม่นับคีย์ emacs ที่กดง่ายมากในตัวอยู่แล้ว ผมยกให้ VSCode REST client นี่ UX ดีสุดเลยครับ ผมรู้สึกว่าการประกาศตัวแปร กับการใช้งานมันตรงไป ตรงมาดีแต่ที่ชอบที่สุดของตัว VSCode คือวิธีการที่มันดึงค่ามาจาก Response นี่ ง่ายที่สุดในทั้ง 3 เจ้า แล้วก็ตรงไปตรงมาที่สุดแล้วครับ โดยแค่บอกชื่อ request name แล้วก็แกะ body ออกมา bind ใส่ variable จบ ซึ่งมันควรจะแค่นี้จริงๆ ครับ

ในส่วนของ Intellij REST Client ผมว่าข้อดีคือมัน Integrate กับ ecosystem ของ Jetbrain ได้เนียนจนคนที่ใช้อยู่แล้ว จะไม่รู้สึกว่ามันขัดเลยอย่างเช่นปุ่มกด run request รวมถึง Response ที่หน้าตาไม่ต่างกับ test runner ที่คุ้นเคยกันอยู่แล้ว อาจจะมี function ที่เวิ่นเว้อหน่อยในการแกะ response ออกมา แต่ผมว่าก็ยังอ่านง่ายกว่าและตรงไปตรงมากว่า emacs ครับ

ข้อเสียหลักๆ ของ Intellij REST cilent คือการที่เราต้องประกาศ environment แยกไว้อีกไฟล์นี่แหละครับ ส่วนตัวผมรู้สึกว่ามันขัดใจมาก (หรือถ้ามันประกาศไว้ในไฟล์เดียวได้บอกผมหน่อยนะครับ) อีกข้อเสียนึงที่เป็นส่วนหนึ่งให้ผมเลิกใช้ตัวนี้ไปคือมันจะเก็บ Response ไว้ในไฟล์เป็น default ครับ ซึ่งพอเราเทสบ่อยๆ มันก็สร้างไฟล์ response ออกมาบานมา แล้วต้องมาคอยนั่งไล่ลบใน .idea เราที่บวมขึ้นเรื่อยๆ ครับ

Verdict

สุดท้ายแล้ว ผมรู้สึกว่าเรามาถึงยุคที่การเก็บ HTTP Request query เป็น Plain text นี้มันดูแลง่ายกว่าสมัยก่อนมากๆ ครับ เพียงแค่ยัดลง git เราก็จะ maintain ตัวนี้ได้ยาวๆ เป็น executable document ที่แท้จริง แล้วจะเห็นได้ว่าแทบจะทุก editor/IDE รองรับแล้ว แต่อาจจะแตกต่างกันไปตามสไตล์แต่ละ implementation ของตัวเองครับ ซึ่งในจุดนี้ถ้าทั้งทีมตกลงกันดีๆ ผมคิดว่าน่าจะไม่มีปัญหาอะไร ส่วนใครเอาไปปรับใช้กับตัวเองแล้วเจอเทคนิคอะไรดีๆ ก็แบ่งปันกันได้ครับ แล้วเจอกันใหม่ตอนหน้าครับ

ปล.นอกเรื่องนิดนึงตอนแรกซีรีย์ emacs diary นี้ผมว่าจะเขียนตั้งแต่ Basic ขึ้นไปเรื่อยๆ แต่คิดว่าทำแบบนั้นกว่าจะได้เขียนเรื่องที่อยากเขียน หรือพอมีเรื่องที่จะเขียนมันก็ต่อคิวยาว เพราะฉะนั้นผมเลยเปลี่ยนแนวทางใหม่เป็นลงตามอารมณ์เลยละกันครับ 555