Amazing Thailand 10k

เข้าใจ technical principle ลึกซึ้งมาอีกขั้น

ปีที่ผ่านมาได้มีโอกาสเข้า session และอ่านบทความและหนังสือเกี่ยวกับ technical โดยเฉพาะ architecture และ principle มากขึ้น ในช่วงแรกคือทำความเข้าใจว่ามันคืออะไร ปัญหาที่แก้ไขคืออะไร ทำงานอย่างไร มีข้อดี-ข้อเสียอย่างไร แต่สิ่งที่เราได้เรียนรู้เพิ่มคือ แนวทางการนำไปใช้เพื่อส่งเสริมการทำงานร่วมกันกับคนอื่น เช่น ภายในทีมกันเอง หรือฝั่ง business และฝั่ง technical เป็นต้น เนื่องจากว่าในเนื้องานแล้วเราพัฒนา software เป็นทีม ถ้าเราสามารถทำงานร่วมกันได้อย่างราบรื่นได้มากเท่าไร เราจะมีความสุขในการทำงานมากขึ้นตามไปด้วย

สิ่งที่ได้เรียนรู้

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

ค้นพบแนวทางการเรียนรู้สิ่งใหม่ที่เข้ากับ style ตัวเอง

จากสิ่งที่อยากจะทำในปีนี้ต่อยอดจากปีที่แล้วคือ ทำให้ตัวเองได้เรียนรู้สิ่งใหม่ ๆ ทุกวัน จะเป็นเรื่องงานหรือไม่งานก็ได้ เราพยายามค้นหาแนวทางการเรียนรู้สิ่งใหม่มาตลอด แต่ก็ทำไม่ได้นานเพราะเราไม่ได้ชอบมัน จนกระทั่งเราค้นพบว่า การที่เราลองทำ project จำลองขึ้นมาเพื่อเรียนรู้สิ่งใหม่ เช่น ทำ project จำลองคล้าย ๆ กับที่พัฒนากับลูกค้าขึ้นมา (ห้ามเหมือนนะ ไม่งั้นโดนฟ้อง ฮ่า ๆๆ) หรือ ทำ project เพื่อลองใช้ technology ใหม่ ๆ คร่าว ๆ เป็นวิธีที่ใช้ได้กับเราเนื่องจาก

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

การให้-รับ feedback

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

สิ่งที่ได้เรียนรู้เพิ่ม

  • เราต้องเกริ่นตลอดว่าถ้าอยากให้ขยายความตรงไหน ก็มาคุยกันต่อได้ ตอนที่เขาได้รับ อารมณ์ของเขาอาจจะยังไม่พร้อม ต้องให้เวลาสักหน่อย
  • “Feedback เป็นของขวัญ รับมาแล้วจะเก็บไว้หรือโยนทิ้งก็ได้” จะจริงก็ต่อเมื่อ feedback นั้นมันเป็นความจริง ถ้าไม่จริงอย่ารับไว้
  • Feedback ที่ดีจะต้องให้ในเวลาที่เหมาะสมและมีข้อมูลครบถ้วน ถ้าเราพลาดโอกาสในการให้ตั้งแต่เนิ่น ๆ แล้วมาให้ทีหลัง เราอาจจะหลงลืมไปแล้ว

มุมมองในการตัดสินใจด้าน technical เปลี่ยนไป

จาก blog ที่เราเคยเขียนเกี่ยวกับการทำงาน consultant มา 1 ปี หนึ่งในเรื่องที่เราเปลี่ยนไปคือมุมมองในการตัดสินใจด้าน technical ซึ่งใช้วิธีการหาข้อมูลเพิ่มมากกว่าคิดให้หนักขึ้นเพื่อตัดสินใจให้เราสามารถต่อยอดได้ในอนาคต ทีนี้เวลาเราบอกว่าต่อยอดมันไม่ได้หมายความว่าทำให้ระบบยืดหยุ่นรองรับทุกทางที่ business จะตัดสินใจนะ เพราะการตัดสินใจโดยที่เราเลือกทางนึงส่งผลให้เราก็จะมีค่าใช้จ่ายเพิ่มเมื่อ business ต้องการเปลี่ยนไปอีกทางนึง ดังนั้นการออกแบบโดยเผื่อไว้ทุกทาง (หรือที่ได้ยินกันว่า flexible สุด ๆ) ถ้าไปเจอ edge case เข้า เราก็จะมีค่าใช้จ่ายสำหรับ edge case และการดูแลรักษาทางที่มีอยู่ ซึ่งเลวร้ายเลยอาจจะมี 10-20 ทางก็ได้

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

คำตอบคือหาข้อมูลเพิ่มก่อน จากนั้น

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

The most flexible way to design a system that is flexible in every direction is basically not design for any flexibility. Everything should be hard-coded. - Chris

Technical public speaking ครั้งแรก

ช่วงนั้นมีฝ่าย marketing ติดต่อมาว่าสนใจพูดเรื่อง technical ไหม เราก็รับปากไปว่าถ้ามีจะเอามาพูดเลย ด้วยความที่เราสนใจในเรื่องของการทดสอบในด้านต่าง ๆ ทำให้เราได้รู้จักกับ mutation testing พบว่าเป็นแนวคิดที่น่าสนใจมากและยังไม่ค่อยมีการพูดถึงในไทย (จากงาน conference ที่เคยไปเข้า) ก็เลยเป็นโอกาสที่จะได้ออกจาก comfort zone มาแบ่งปันประสบการณ์ตรงบ้าง

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

สิ่งที่ได้เรียนรู้

  • เราต้องดูแล code ของชุดการทดสอบให้เหมือนกับที่เราดูแล code บน production
  • เราต้องระบุให้ชัดว่าสิ่งที่เรานำเสนอนั้นมันเป็นแนวทางปฏิบัติ (practice) หรือเครื่องมือ (tool) กันแน่ หากเป็น practice อย่าเริ่มขายด้วยเครื่องมือ เช่น เราเริ่มจากการสาธิต mutation testing แบบไม่ใช้ tool ก่อน แล้วค่อยบอกว่า tool มันมาทำให้เราทำตาม practice ได้ง่ายขึ้นอย่างไร
  • สุดท้ายแล้วเราจะเจอจุดตรงกลางระหว่างความสมบูรณ์ของเนื้อหาและแนวทางการเล่าเรื่องด้วยการออกไปพูดหลาย ๆ รอบ
  • ไม่ต้องกังวลว่าใครจะมาดูมากน้อยขนาดไหนเพราะมันอาจจะยังไม่แพร่หลายมากต้องใช้เวลา เปรียบเสมือนเป็นน้ำซึมบ่อทราย

เติบโตในด้าน soft skill มากขึ้น

ปีที่ผ่านมาพบว่าเรามี learning curve ในด้านของ soft skill ขึ้นมาก ไม่จะว่าเป็น

  • Senior developer
  • Consulting จากหนังสือ Flawless Consulting
  • Personality จากหนังสือ Surrounded by Idiots และ Surrounded by Psychopaths เพื่อเข้าใจตัวเองมากกว่าไปชี้ว่าคนอื่น
  • Habit และ Goal settings จากหนังสือ Atomic Habits
  • Productivity จากการอ่านหนังสือ ความลับของคนที่ไม่เคยเอางานกลับไปทำที่บ้าน
  • ความรู้เรื่องสุขภาพและการออกกำลังกาย (จบงานวิ่ง 10k ไป 2 งาน ได้ COVID มาเป็นของแถม 🤣)
  • ความรู้เรื่องการพัฒนาตัวเอง เช่น style การสื่อสาร การทำงานร่วมกับผู้อื่น การลงทุน ระหว่างรอ project ใหม่เข้ามา
  • เรื่องอื่น ๆ จากการทำกิจกรรมอาสา

สถิติ

ปีที่ผ่านมาเขียนไป 44 blog โดยเรื่องที่เขียนเยอะที่สุดคือ

  • practice (7)
  • java (5)
  • productivity (4)
  • agile (4)
  • soft-skill (3)
  • career (3)

มี 6 blog ที่เอาไปแชร์กับพี่ ๆ ผ่าน Medium

เวลาที่ใช้ในการเขียน code

ปีที่ผ่านมาเราเริ่มใช้เครื่องมือ WakaTime เป็นตัวเก็บสถิติ ปีนี้สถิติจะอยู่ในเครื่องของบริษัทเท่านั้นเพราะไม่อยากเอา API key ของส่วนตัวไปลงเครื่องลูกค้า

Code stats for 2022

  • เขียน code ด้วย Markdown เยอะสุดเพราะเขียน blog ล้วน ๆ รองลงมาถึงจะเป็น Java กับ YAML
  • เขียน code เฉลี่ยวันละ 1 ชั่วโมง 20 นาที ถือว่าเกินความคาดหมายไว้จากที่คิดว่าไม่เกินวันละ 1 ชั่วโมง

Feedback

ระหว่างปีที่ผ่านมา มาดู feedback ที่เราได้รับกันหน่อย

  • มีความถนัดทางด้าน technical ที่เกี่ยวข้องกับ project สูง
  • ช่วยเหลือทีมได้เยอะในเรื่องของการเก็บและแบ่งปัน context ที่เกี่ยวกับ business
  • ช่วย onboard เพื่อนร่วมทีมใหม่ให้เริ่มงานได้ราบรื่นและเร็ว
  • ทำ action items ที่ระบุไว้ใน retrospective อยู่สม่ำเสมอ
  • ค้นหาสิ่งใหม่ ๆ ที่จะช่วยปรับปรุงการทำงานอยู่เสมอ
  • การสื่อสารดีขึ้น สามารถสื่อให้ทุกคนเข้าใจในสิ่งที่เราต้องการได้
  • ช่วยทำการถ่ายโอนงานให้อีกทีมที่จะมาทำต่อ (knowledge transfer) ในฐานะ mentor เราผลักดัน mentee ให้นำ session
  • การที่เราจะเติบโตไปเป็น senior หรือ lead เราต้องระวังเรื่องการใช้อารมณ์และน้ำเสียง ให้เรามองว่าทุกคนที่เราพูดคุยด้วยคือคนที่เพิ่งรู้จักกัน (ตอนแรกเราจะถูกเสนอเป็น technical lead ของทีม แต่โดนข้างบนบอกว่าหยุดไว้ก่อนเพราะเรามีจุดอ่อนเรื่องนี้)
  • ก่อนที่เราจะพูดอะไรที่เกี่ยวข้องกับความเห็นที่เกิดจากเราและคู่ของเรา ควรจะพูดคุยกับคู่ของเราก่อนเพื่อทำความเข้าใจให้ตรงกัน
  • ในช่วง knowledge transfer ในฐานะที่เราเป็น mentor ควรจะเป็นเราที่เป็นคนนำ session ส่วนใหญ่มากกว่า mentee เพราะเราเป็นคนที่มี context มากที่สุดในทีม หรือถ้าเขาอยากทำ ก็ควรจะลองซ้อมกันเองก่อนเพื่อดูความถูกต้องในเนื้อหาและดูความมั่นใจ
  • ใน project ถัดไป ควรตั้งเป้าหมายในการเรียนรู้ของเราให้ชัดเจนตั้งแต่เริ่ม เช่น backend, infrastructure, จับฉ่าย
  • ตอนเราแบ่งปันเรื่อง technical ควรจะมีการเสริมด้วยการเล่าเรื่องเพื่อดึงดูดผู้ดูผู้ฟัง

สิ่งที่อยากจะทำในปีนี้จาก blog ปีที่แล้ว

✅ รักษา passion ที่มีต่อ software development
✅ ทำให้ตัวเองได้เรียนรู้สิ่งใหม่ ๆ ทุกวัน จะเป็นเรื่องงานหรือไม่งานก็ได้
✅ เขียน blog ต่อไปเรื่อย ๆ
✅ ปรับปรุงตนเองตาม feedback ที่ได้รับในปีที่แล้ว

สิ่งที่อยากจะทำในปีหน้า

  • เหมือนเดิมจากปีที่แล้ว ฮ่า ๆๆ
  • ถ้าคิดอยากจะลงมือทำอะไรที่ไม่มีอะไรจะเสีย ศึกษาแปบเดียวแล้วลงมือทำเลย จะได้ไม่มาเสียดายทีหลัง
  • คิดอะไร อยากให้ feedback ใครก็ให้เลย อย่าได้รอจนลืม
  • จดบันทึกสิ่งที่คิดว่าสำคัญให้ได้มากที่สุด เพื่อที่เราจะได้ไม่ต้องมาระลึกชาติ

เขียนไปเขียนมาจาก software development journey จะกลายเป็น life journey ละ 🤪

สรุป

สำหรับเราแล้วปี 2022 เป็นปีที่ยาวนานมาก เพราะเราได้ enjoy กับชีวิตในอีกด้านหนึ่งนอกจาก technical บ้าง เราได้ใช้ชีวิตในแบบของตัวเองโดยไม่เครียดจนเกินไป และเราได้บันทึกความทรงจำและสิ่งที่ได้เรียนรู้ไว้เกือบทั้งหมด เวลาที่เรากลับมาดูก็คงดีใจมากว่าใช้ชีวิตมาคุ้มในระดับนึงนะ ปีหน้าก็ดิ้นรนกันต่อไป Let’s go! 💪

Myself