สรุป software development journey ปี 2022
เข้าใจ 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 ของชุดการทดสอบด้วย Mutation testing
- ประหยัดเวลาการ setup บนคอมใหม่ด้วย Chezmoi
- สิ่งที่น่าสนใจจาก Thoughtworks Tech Radar ฉบับที่ 26
- สรุปสิ่งที่น่าสนใจจากงาน XConf Thailand 2022
- Query AWS และ cloud services อื่น ๆผ่าน SQL ด้วย Steampipe
- สิ่งที่น่าสนใจจาก Thoughtworks Tech Radar ฉบับที่ 27
เวลาที่ใช้ในการเขียน code
ปีที่ผ่านมาเราเริ่มใช้เครื่องมือ WakaTime เป็นตัวเก็บสถิติ ปีนี้สถิติจะอยู่ในเครื่องของบริษัทเท่านั้นเพราะไม่อยากเอา API key ของส่วนตัวไปลงเครื่องลูกค้า
- เขียน 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! 💪