ลาออกครั้งแรกยากที่สุด

เมื่อปลายปีที่แล้วเราได้ลาออกได้บริษัทแรกที่ทำงานมา 3 ปี ที่รู้สึกว่าลาออกครั้งแรกยากที่สุดถึงกับกินไม่ได้นอนไม่หลับอยู่ 2-3 คืนคือ รู้สึกไม่มั่นคง (insecure) ว่าออกแล้วงานจะดีกว่าเดิมไหม อย่างเลวร้ายที่สุดคือแค่ไป up เงินเดือน ส่วนนึงคือความผูกผัน เพราะบริษัทก็ดูแลเราดี พาไป business trip ที่จีนและอเมริกา หลังจากผ่านการพูดคุยกับผู้ใหญ่และเพื่อนร่วมงานหลายคน ท้ายที่สุดแล้วก็เห็นแก่ตัวแหละ มองเรื่องความก้าวหน้าของอาชีพการงานและเงินดีกว่า

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

  • การลาออกครั้งแรกยากสุด ครั้งต่อๆ ไปมันจะเริ่มชินชา เพราะเมื่อประตูบานนึงปิดเอง ประตูบานอื่นๆ อีกหลายบานก็จะเปิดออก ฮ่าๆๆ

EMIT team

Lockdown ครั้งที่ 2

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

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

สัมภาษณ์งานมันเหนื่อยนะ

เรามีโอกาสได้ผ่านเข้าสัมภาษณ์กับบริษัทที่เคยทำงานด้วยในฐานะลูกค้า ตอนนี้กำลังจะกลายเป็นฝั่ง consultant แทน ซึ่งเรามีความฝันที่อยากจะทำงานที่นี่มาเป็นปีแล้ว เพราะพัฒนาการด้าน software development ของเราก้าวกระโดดขึ้นอย่างมากใน 2 ปีล่าสุด

บริษัทนี้มีชื่อเสียงในการสัมภาษณ์โหดอยู่แล้ว แต่ยังดีเพราะทาง People team ของเขาอธิบายขั้นตอนการสัมภาษณ์อย่างละเอียด พร้อมกับส่ง guidelines มาให้ดูด้วย บางรอบที่เป็นการสัมภาษณ์แบบ coding ก็จะมีการส่ง code มาให้ดูก่อน 1 วันล่วงหน้าเพื่อให้เราทำความเข้าใจก่อนด้วย

รอบการสัมภาษณ์

  • คุยกับ People team
  • Pair programming
  • Technical (domain modeling & tech solution)
  • Culture

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

สรุปเราก็ผ่านสัมภาษณ์และรับ offer แบบไม่ลังเล ฮ่าๆๆ

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

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

งานใหม่ดีกว่าที่คิด

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

  • มี community chat พูดเรื่อง topic ที่น่าสนใจทุกวัน ครอบคลุมหลาย area
  • เข้ากิจกรรม Hacktoberfest Bangkok 2021 เสียดายที่รู้ว่ามีงานนี้่ช้าไปหน่อน เลยไม่ได้ contribute ให้เยอะมากมาย
  • มีกิจกรรม lunch&learn, sharing session จาก community บ่อย อย่างที่เคยเข้าแล้วชอบสุดคือ role&responsibility และ software architecture ซึ่งมีโอกาสได้นำไปปรับใช้กันภายในทีมด้วย

นอกจากนี้ยังมีเรื่องของ feedback ที่สามารถ รับ-ให้-หา-ใช้ feedback ได้ตลอดเวลา ไม่ว่าจะจากการทำงานหรือการส่ง form ให้เพื่อนๆ ในทีม หรือคนที่ทำกิจกรรมด้วยกันเขียนได้ด้วย (ได้ยินจากรุ่นพี่ว่า สมัยก่อน COVID คือนัดกินข้าวไปคุยเล่นกันได้เลย) และคนที่ไม่ได้เข้าไปทำใน project ก็สามารถจับกลุ่มสร้าง project เล็กๆ ที่มีคุณค่าต่อบริษัท เช่น สร้างเครื่องมือที่ใช้กันภายในบริษัท เป็นต้น

Project ที่ทำอยู่

หลังจากผ่าน program ล้างสมองที่ทางบริษัทจัดให้ ก็มีทีมติดต่อมาว่าอยากให้ไปทำ project นี้ด่วน เนื่องจากขาดคนที่ถนัด technology stack พวก Java + Spring Boot framework (ดูได้ที่ https://stackshare.io/raksit31667/tw-accounting-software) หลังจากตอบตกลงและร่วมงานกันไป 5 เดือน สิ่งที่เราชอบใน project นี้คือ

  • technology stack คุ้นมือช่วยให้บรรลุเป้าหมายของตัวเองคือ การช่วยเหลือแบ่งปันประสบการณ์และความรู้ให้กับเพื่อนๆ ในทีม
  • ลูกค้าเป็นกันเองมาก ช่วยเหลือเราเท่าที่จะทำได้ มี feedback ให้กับระบบที่เราทำอย่างเสมอ ทำให้เราคิดว่ามันมีความเป็นเจ้าของร่วมกันอยู่
  • ระบบ process หลังบ้านของบริษัทลูกค้าแข็งแรง เปิด request ไปแป๊ปเดียวได้ละ มี IT support คอยตอบคำถาม
  • ตัว product และ requirement น่าสนใจ คิดตามแล้วสนุก มีคนใช้จริงๆ บน production

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

  • ทีมทำงานเป็น mini-waterfall ก็คือเหมือนกับ waterfall ทุกอย่าง แค่มีสิ่งอุปโลกน์ที่เรียกว่า sprint เป็นการแบ่งงานเป็นรอบๆ ไป สุดท้ายก็ส่งมอบพร้อมกันทีเดียว 3 เดือน เนื่องจากลูกค้าอยากได้งานร้อน MVP แบบอลังการ โดยจ้างทีมที่มี DEV น้อย หลังจากนั้นเราบอกว่าจะลด release cycle ลง แล้วเราต้องเปลี่ยนแนวทางการทำงานอย่างไรบ้าง หรือจะทำแบบเดิม
  • ลูกค้าไม่ได้จ้าง QA ต้องยืมตัวมาจากทีมอื่น 2 วัน/อาทิตย์ ในเมื่อไม่มีใครสวมหมวกเด่นทางด้าน quality สิ่งที่น่าสนใจคือ ทีมจะมั่นใจได้ว่า software มี quality ได้จากอะไร
  • คำว่า “งานเสร็จ” ของเราไม่เท่ากัน การแบ่งงานของเราไม่เท่ากัน story wall แต่ละ lane แต่ละคนไม่เท่ากัน แล้วเพิ่งมารู้เมื่อเวลาผ่านไป 5 เดือนด้่วยซ้ำ เคยพูดคุยกันก่อนไหม ฮ่าๆๆ
  • ทีมไม่มี code review แล้วจะจัดการคุณภาพของ code จากอะไร feedback ที่ได้จะมาจากไหนแทน
  • ทีมเลือก assign งานให้แต่ละคนโดยดูจากความถนัดของแต่ละคน (frontend-backend-infra) อย่างสม่ำเสมอ น้อยมากที่จะมีการเปลี่ยนสาย คำถามคือถ้าคนที่ถนัด frontend ไม่อยู่แล้วมีปัญหาด้าน frontend บน production ใครจะเป็นคนแก้
  • การเชิญคนเข้าประชุม จะดูจาก topic ว่าเกี่ยวกับ business หรือ technical ทั้งทีมจะมาเจอกันเฉพาะตอน sprint planning, standup, sprint review, retro เท่านั้น การเชิญคนที่ไม่ได้เกี่ยวข้องมาถือว่าเสียเวลาทำงาน แล้วเวลาที่ระบบมีปัญหาจะเรียกทุกคนมาประชุมหรือไม่

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

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

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

สถิติการเขียน blog ทั้งปี

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

  • spring
  • productivity
  • security
  • angular
  • aws

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

Feedback

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

  • ทำความเข้าใจรายละเอียดปลีกย่อยของ business requirements ให้มากขึ้น
  • จำกัดกรอบเวลาการทำ tech analysis และการปรับปรุงระบบด้าน tech
  • ไม่เข้าใจคำถามที่เราถามเป็นบางครั้ง แนะนำให้ค่อยๆ พูด
  • หลีกเลี่ยงการโชว์รายละเอียดด้าน technical ให้ลูกค้าเห็น
  • ตอบ mail จากลูกค้าเท่าที่ทำได้
  • ทำ showcase นานไปนิดนึง บางทีเราอธิบาย process ในภาพรวมทั้งหมด แต่จริงๆ แล้วลูกค้าเค้าสนใจแค่ผลลัพธ์ที่ได้อย่างเดียว ดังนั้นต้องระวังเรื่องเวลาในประชุมกับคนเยอะๆ
  • Agile practice ต่างๆ ในอุดมคติของเราแตกต่างจากสิ่งที่เราทำให้กับลูกค้า โดยเฉพาะกับบริษัทใหญ่ ดังนั้นเราต้องปรับไปตามความเหมาะสม อย่าไปยึดติด

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

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

Myself