[รู้อะไรไม่สู้รู้งี้ ตอนที่ 2] กรณีศึกษาและคำแนะนำสู่น้อง ๆ ที่เริ่มต้นในสายงาน Software Engineer (Junior/Entry level)
Reference To Another Part
[รู้อะไรไม่สู้รู้งี้ ตอนที่ 1] คำแนะนำน้อง ๆ วัยเรียนหรือผู้ที่ต้องการทำงานสาย Software Engineer
[รู้อะไรไม่สู้รู้งี้ ตอนที่ 2] กรณีศึกษาและคำแนะนำสู่น้อง ๆ ที่เริ่มต้นในสายงาน Software Engineer (Junior/Entry level)
[รู้อะไรไม่สู้รู้งี้ ตอนที่ 3] มุมมองของผมเกี่ยวกับการพัฒนาในสายงาน Backend Software Engineer จาก Mid Level สู่ Senior และต่อ ๆ ไป
Introduction
สวัสดีครับทุกคน สำหรับบทความนี้เป็นตอนที่ 2 จะเกี่ยวข้องกับการที่เราผ่านจุดเริ่มต้นมาแล้ว ได้เป็น SWE ในบริษัทต่าง ๆ แล้ว แล้วคราวนี้เราจะไปยังไงต่อ? แล้วเราจะวางแผนต่อไปยังไง? ในบทความนี้ก็จะเป็นองค์ความรู้ และ Mindset ที่เกี่ยวข้อง ซึ่งไม่จำเป็นต้องเชื่อทุกอย่างที่ผมบอกก็ได้ ผมเพียงแต่นำมาเล่าสู่กันฟังและเป็น Case Study ให้สำหรับบุคคลที่สนใจ
เนื้อหาไม่ได้เจาะจงไปที่ Roleใดเป็นพิเศษ (General SWE) สามารถไปปรับใช้ได้ตามสถานการณ์เลย เพียงแต่ว่าทางฝั่งของผู้เขียนคุ้นชินจากการทำ Backend เฉย ๆ
ดังนั้น สูดหายใจเข้าลึก ๆ แล้วไปเริ่มกันเลย
ตัดสินใจเลือกสิ่งที่เราถนัดและให้ความสำคัญกับมันมาก ๆ หรือตามหาสิ่งที่เราชอบภายใน 1–2 ปีนี้
FE (Website), FE (Mobile), BE, , Full-Stack, DevOps, Cloud Engineer, QE, Blockchain, Data Engineer, Data Scientist, IoT, Embedded, etc.
Buzzwords ของสายงานก็คงจะไม่พ้นตามด้านบน แล้วทำไมเราถึงต้องเลือกสิ่งที่เราถนัดแล้วเข้าชน? ใช่ครับ คุณสามารถเก่งทุกอย่างได้ ถ้าคุณมีพลังวิเศษ หรือคุณเก่งมาก ๆ แต่เวลาเป็นตัวแปรที่มีค่ามาก ๆ ครับ บริหารให้ดี ความคิดผมผมว่าเราเอาเวลาแบ่งไปทำอย่างอื่นด้วยก็ดีครับ
และพอขึ้นเป็น Mid-Level ขึ้นไป คุณอาจจะได้ Focus ไปที่อย่างใดอย่างนึง ถ้าเจอตัวเองแล้ว ก็ใส่นัวกับอนาคตได้เลยครับ
แต่ละ Job Title ใช้พื้นฐานแตกต่างกันออกไป บริหารเวลาศึกษาให้ดี
ยกตัวอย่างเช่น
General ทั่ว ๆ ไป — Programming paradigm, API, Testing, Design Patterns, Agile, DevOps, Security, OWASP, OAuth 2.0, Cloud computing, etc.
FE (Web)— HTML, CSS (SCSS), JS (TS), Web Frameworks, etc.
FE (Mobile) — Kotlin (Android), Swift (iOS), MVC/MVP/MVVM, etc.
BE — Service communication (RESTful, Graphql, Message Queue, Pub/Sub), Backend frameworks, API Gateway, Microservices Architecture, Cloud-Native Architecture, Site Reliability Engineer, etc.
ที่กล่าวมาข้างต้นเป็นเพียงแค่เสี้ยวเล็ก ๆ ในอุตสาหกรรมเท่านั้น ดังนั้นการเรียนรู้อะไร อาจจะอิงตามสายงาน หรือจุดแข็งของตัวเองเป็นหลัก แต่การข้ามไปเรียนเรื่องอื่น ๆ ก็ไม่ใช่เรื่องผิด และเป็นเรื่องดีด้วย ทั้งนี้ทั้งนั้นพื้นฐานของสายนั้น ๆ ถ้าแน่นมากเท่าไหร่ ยิ่งทำให้เจอของใหม่ ๆ เข้าใจได้ดี/ประติดประต่อได้ดีมากขึ้น
Notes: พื้นฐาน 2 อย่างด้านล่างนี้ จำเป็นกับทุกสาย
- Software Architecture
- System Analysts and Design
- Large-Scale Design Applications/Systems
บางเนื้อหาผ่านไปประมาณ 5 ปีก็ยังไม่เก่า
ซึ่งส่วนมากก็จะเป็นในเรื่องของพื้นฐาน, Architecture, Data Communications, etc. ยกตัวอย่างเช่น
What is the OSI Model? — Cloudflare
OAuth 2.0 (ตัวอย่างคือ Authorization Code Flow)
Microservice architecture style
OWASP Top Ten
ที่วางไว้ให้เป็นเพียงแค่ส่วนหนึ่งส่วนเล็ก ๆ บนโลกที่กว้างใหญ่เท่านั้น อยากให้ประเมินว่าสายที่เรากำลังเดิน มีสิ่งใดที่ต้องใช้ในระยะยาว
เราเลือก Career Path ให้ตัวเราเองก่อน (ถ้าคิดไม่ออกค่อยให้ Talent Sourcer แนะนำ)
ในมุมนี้ สิ่งที่ผมอยากจะสื่อก็คือ
- เรารู้จักตัวเราเองดีที่สุด การได้ Feedback หรือคำแนะนำจากคนอื่น ๆ ก็คือเป็นตัวเสริมการตัดสินใจเท่านั้น
- เราสามารถประเมินพลังของตัวเองได้แม่นกว่าคนอื่น ๆ
- คุณสามารถทำงานไปวัน ๆ ได้เช่นกัน ก็คือคุณไม่สนตำแหน่งงาน คุณอยากจะทำกระโดดไปเรื่อย ๆ แหละ แต่ก็ไม่สนที่จะโตเหมือนกัน (ซึ่งผมก็ห้ามไม่ได้เหมือนกันถ้าเป็นแบบนั้น)
- แต่ถ้าเกิดว่า Talent Sourcer เขาเสนอสิ่งที่แตกต่างจากที่เราคิด เราอาจจะสอบถามเขาได้ว่า เขามีเกณฑ์อะไร ที่ทำให้เขาคิดอย่างนั้น ถ้าเรารู้สึกสมเหตุสมผล และอยากจะลองก็ไม่เป็นไรครับ
เลือกเนื้อหาที่จะเรียนได้แล้ว ต้องฝึกทักษะประเมินเนื้อหาที่ไม่ต้องเสียเวลาเรียนด้วย
เพราะอะไรน่ะหรอครับ? เวลาอีกแล้ว 55555555 ใช่ครับ บางทีเราต้องวางลำดับความสำคัญของสิ่งที่จะเรียน เลือกเรียนที่ใช้ในงาน เลือกเรียนในสิ่งที่รู้สึกชอบและอยากจะทำ คุณสามารถเรียนให้รู้เฉย ๆ ได้เช่นกันครับ แต่ถ้าไม่ได้ถูกใช้ หรือแปลงออกมาเป็น Output โอกาสลืมมีสูงมาก ๆ
และเพราะ Technology มาไวไปไวเช่นกันในบางตัว และบางตัวก็อาจจะเป็น Trend ดังนั้นก็อาจจะต้องหาข้อมูลจากหลาย ๆ แหล่งพอสมควรจนรู้สึกคุ้นชิน
อย่างกรณีของผม สาย Backend + DevOps + Cloud สามารถหาได้จากแหล่งเรียนตาม Platform ต่าง ๆ ได้เลย ด้านล่างก็เป็นตัวอย่างที่ผมนำมาแนะนำถ้าผมจะเรียนเกี่ยวกับด้าน Cloud Computing บางทีเขาก็ไม่ได้ Focus ที่ Tools นะ ยกตัวอย่าง Scenarios ขึ้นมาเลย พอเรา Matching กับเหตุการณ์ได้ หัวเราจะจินตนาการไปเองครับ
แต่ถึงกระนั้น ตอนที่เข้าไป ผมก็ต้องคัดกรองสิ่งที่อยากรู้ และสิ่งที่จำเป็นต้องใช้มาเป็นความสำคัญแรก ๆ ก่อนเช่นเดียวกัน
DevOps จริง ๆ แล้วไม่ใช่ตำแหน่งงานและไม่ใช่ Infrastructure Team Rebranding
DevOps คือ Culture, แนวคิด และ Tools ผสมผสานกันเพื่อ Objective ในด้านการ delivery & deployment product ให้มีความ
- Fast
- Reliable
- Secure
- Monitoring
- Improve Collaboration (Developer กับ Operation Team ตีกันน้อยลง)
และ SWE ที่มี DevOps ในใจ คือผู้ที่ช่วยให้การ Deliver product นั้นไวมากยิ่งขึ้น
Keywords ที่เกี่ยวข้องเบื้องต้น (CI/CD)
- Continuous Integration
- Continuous Delivery
- Continuous Deployment
นอกจากนี้ยังมี Buzzword อย่าง DevSecOps เหมือนกัน ซึ่งเอาจริง ๆ ผมมองว่า DevSecOps เป็นเหมือน superset ของ DevOps ที่ใส่ Security เข้าไปตรงกลาง Process กล่าวคือจำพวกด้านล่างนี้ ถูกเพิ่มเข้ามาในกระบวนการ Delivery
- Vulnerability Libraries & Security Risk checking
- Secure Coding จากทางทีม Dev
GitOps ก็เหมือนกัน แนวคิดก็คือ เราทำแบบกระบวนการ Delivery Software เหมือนด้านบนเลย แต่เราทำในเรื่องของ Infrastructure เรียกว่า Workload ก็ได้ ด้วย Git commit และ Event Triggers ของเรานี่แหละ และก็จะไปเกี่ยวข้องกับเรื่อง Infrastructure as Code (IaC) ทำให้ tracking change ของ Workload ได้
เริ่มลึกละ ผมขอพอแค่นี้ก่อนดีกว่าครับ ลองไปศึกษาดูกันครับ
Blameless postmortem แม้ apply ไม่ได้ 100% ที่นี่ ก็ต้องพยายามทำให้ได้ใกล้เคียงที่สุด
เวลาเกิดปัญหา เน้นแก้ปัญหาครับ ลองรวบรวมข้อมูล ระดมสมองกันว่าปัญหาเกิดจากอะไร ถ้าคิดว่านี่แหละอาจจะใช่ หรือใช่แน่ ๆ ให้แก้ปัญหา ในระหว่างนั้นก็ Tracking วิธีการที่เราทำกัน
เมื่อแก้ปัญหาเสร็จแล้ว มาทบทวนกันครับ ว่าอะไรผิด พังอะไร สาเหตุคืออะไร แก้ยังไง ไม่ต้องโทษกัน แล้วไปหาทางป้องกันให้ดีมากขึ้นในระดับต่อ ๆ ไป
กล้าที่จะลงมือทำ แม้ผิดพลาด เราจะได้รู้วิธีทำพลาดเพิ่มขึ้นอีก 1 วิธี
เวลาได้รับงานจริงมาครับ เวลาทำงานแรก ๆ บางทีเราก็จะรู้สึกตื่นเต้น กลัวผิด ไม่กล้าถาม และอะไรอีกมากมาย
อยากให้ลองแก้ปัญหาดูครับ ตราบใดที่คิดว่ามันยังไม่ได้ส่งผลกระทบกับ Users, Clients หรือกับคนส่วนมากในโปรเจค ทำไปเลย ลองแก้ปัญหาด้วยสิ่งที่เราเข้าใจ สิ่งที่เราคิดว่ามันควรจะเป็น
ถ้าแก้แล้ว มันดันไม่เหมือนกับสิ่งที่เราคิด ก็ไม่ต้องตื่นตระหนก ให้เวลากับตัวเองค่อย ๆ คิดแก้ปัญหา หรือค้นหาใน Internet ด้วย Error keywords
และถ้าเราใช้เวลาไปพอสมควรแล้ว ถามครับ ถามคนในทีมได้เลย โดยปกติผมจะให้เวลาตัวเองคิดแบบ 1 Hour ถ้าในกรณีที่แบบ No clue at all moment เกิดขึ้นมา ผมจะถามทันที ไม่อยากเสียเวลา นอกจากจะกระทบ Manday แล้ว ยังส่งผลกระทบ Deliver Timeline ด้วย บริหารเวลาที่ใช้ในแต่ละวันให้ดีครับ
เมื่อคุณผ่านมันมาได้แล้ว คุณจะจำครับ จำทั้งสิ่งที่ถูกต้อง และสิ่งที่เราทำผิดพลาด และข้อควรระวัง ถ้า Actions นั้นไม่ใช่ Best Actions ที่ควรจะทำ เราควรจะจำไว้ว่า มันอาจจะยังมีแนวทางที่ดีกว่านี้ แต่เราดันทำไปแบบนี้ไปก่อน มันอาจจะคุ้นชินและทำให้เราไม่เปลี่ยนแปลงแนวทางที่แก้ในอนาคตได้ครับ
หา Focus Completely Time ให้ตัวเอง และ Do one thing at a time
- บางคนชอบตอนเช้าเพราะหัวโล่ง
- บางคนชอบตอนบ่าย เพราะรู้สึกตื่นตัว
ช่วงเวลาไหนก็ตามแต่ สิ่งที่ผมอยากจะบอกคือ จำกัดช่วงเวลาในแต่ละวัน 3–4 Hrs Focus แบบหักโหมไปที่งานตรงหน้า
- จัดลำดับความสำคัญงานที่สำคัญที่สุดมาก่อน
- แยกมันออกเป็น Task เล็ก ๆ
- จัดลำดับขั้นตอนว่าตัวไหนควร Take Actions ก่อน
ไม่ตั้งเป้าที่ความสมบูรณ์แบบ [อีกแล้ว]
Perfect is enemy ครับ เพราะจะมัวแต่วางแผน มัวแต่ทำให้สมบูรณ์ จะทำให้ช้า ทำให้มันพอที่จะใช้งานได้แล้วมีคุณภาพพอสมควร และตอบโจทย์ Requirements ที่ต้องก็เกินพอครับ แต่ถ้าอยาก Improve Process ไปด้วย ก็ต้องวาง Tradeoff เรื่องเวลาไว้เช่นกัน
อย่าลืมว่า เมื่อเราได้ทำงานจริง ๆ แล้ว เราแข่งกับเวลา ทั้งเดดไลน์ของ Task และ Delivery Timeline
Speed Matter in Business
หากทำตัวเราได้ดีแล้ว ดึงคนอื่น ๆ ขึ้นไปด้วย
จริง ๆ ก็คือเราสามารถแชร์ความรู้ให้กับทีม, Leader, Manager ได้หมดเลยครับ นอกจากจะเพิ่มคุณภาพโดยรวมให้กับทุกคนแล้ว เราจะเข้าใจในมุมมองเดียวกัน เข้าใจตรงกันครับ (แต่ถ้าเข้าใจผิดทั้งทีม ก็ GG ครับ 🥲)
เปิดรับความคิดเห็นที่แตกต่าง หยุดคิดและไตร่ตรองประโยคที่ได้รับ และ การวิจารณ์และการ Feedback สามารถทำได้ด้วยความจริงใจ
บางทีเราอาจจะมีทางเลือกอื่น ๆ ที่สามารถทำได้ เพราะเราก็จะมีความเข้าใจในมุมมองของเรา เราก็อาจจะผิด ไม่ว่าจะทั้งความไม่รู้ ความเข้าใจผิด หรือความคิดไปเอง และ Mentor, Manager หรือคนอื่น ๆ ที่เราคิดว่าเขาเก่ง ก็คนเหมือนกัน บางทีก็ผิดพลาดได้ บางทีก็ลืมได้ ดังนั้นการหยุดคิด และคิดถึงผลลัพธ์ที่ดีที่สุดหรือผลลัพธ์การประนีประนอม จึงเป็นทางเลือกที่สมควรจะทำครับ
แต่ทั้งนี้ทั้งนั้นการพูดคุยกันอย่างจริงใจ แล้วบอกว่าทำไมความคิดของเราถึงออกมาเป็นแบบนี้ มีสาเหตุและเหตุผลต้นกำเนิดเป็นอย่างไร จะทำให้การสื่อสารดีมากยิ่งขึ้น ความเห็นของแต่ละบุคคลควรถูกเคารพครับ
[ส่วนตัว] ที่ทำงานอาจจะไม่จำเป็นต้องสนุกสนาน แต่คือที่ที่ทำให้คุณเห็นตัวเองก้าวหน้าในการงาน
ผมไม่รู้เหมือนกันนะ ว่าคนอื่น ๆ คิดเหมือนผมมั้ย ซึ่งถ้าผมคิดผิดก็บอกหรือเตือนผมได้นะครับ
เนื่องจากว่า ตอนช่วงนี้ก่อนช่วงอายุ 30 เป็นช่วงที่เราต้องวางรากฐานการทำงานในอนาคต ถ้าพื้นฐานเราไม่ดี ในอนาคตก็จะส่งผลดีได้ไม่เต็มที่ และทางผู้เขียนก็ไม่ใช่คนเก่งแต่เป็นคนบ้า 555555 บ้าที่จะใช้และดึงเวลามาเพื่อที่จะเรียนรู้ให้ดี เพื่อที่จะเก่งมากยิ่งขึ้น มากกว่าสนใจสุขภาพตัวเองตอนนี้ซะอีก Mental Health เป็นสิ่งที่ต้องคิดถึงมาก ๆ ก็จริง แต่ถ้าพร้อมและเตรียมใจไว้แล้วก็ใส่ให้สุดไปเลยครับ ไม่ได้เชิญชวนให้เอาอย่างนะครับ แต่ทางผู้เขียนมีวิธีนี้แหละ ที่ทำให้ Keep-up กับคนอื่น ๆ ได้
แม้ตำแหน่งงานเหมือนไม่ต้องคุยกับคนอื่น แต่ที่จริงแล้วตรงกันข้าม
Software Engineer เป็นโปรแกรมเมอร์ใส่ Hood นั่งปิดไฟ เขียนโค้ด ทำงานคนเดียว Solo Player ม่ายยยย มันไม่ใช่อย่างงั้นเสมอไป 5555555
เวลาทำงาน จะมี Role เป็นของตัวเอง และเราก็เป็นสมาชิกในทีม ในทีมก็อาจจะมี Requirements ของตัวเองที่ต้องแก้ แถมนอกเหนือจากนั้นอาจจะมีคุยระหว่างทีม บางทีมีคุยกับ Clients อีก ดังนั้นเราก็ต้องมีการ Communicate กันเพื่อที่สร้าง และส่งผลงานได้อย่างถูกต้อง ครบถ้วน พึงพอใจทั้ง Client, Team และเรา
Certificate หลังจากเรียน Courses ต่าง ๆ อาจจะช่วย แต่บางทีมันอาจจะเป็น Gimmick ดังนั้นสนใจเนื้อหาที่ผู้สอนมอบให้เป็นสำคัญ
สังเกตเห็นมั้ยครับว่า เวลาเราไปเรียนหรือโฆษณาเชิญชวนไปเรียน แล้วถ้าเรียนจบ Course เขาจะบอกว่า เรียนจบแล้ว เราจะได้ Certificate ไปใช้เป็นเครื่องรับประกันว่า เราเรียนเรื่องนี้มาแล้ว ผ่านมาแล้ว แต่คำถามคือ
มัน Effective ขนาดนั้นเลยรึเปล่า?
ผมไม่มีคำตอบทางสถิติให้กับทุกคน ผมไม่สามารถพูดได้เต็มปากว่ามันสร้างผลกระทบใหญ่หลวงมากน้อยแค่ไหน หรือสามารถอัพเงินเดือนของคุณได้มากเพียงใด
แต่สิ่งที่คุณจะได้รับแน่ ๆ คือความรู้ต่าง ๆ ที่เกี่ยวข้องที่เขาตั้งใจ และออกแบบมาเพื่อสอนเรา เพื่อมอบความรู้ในการทำงานให้กับเรา ดังนั้นการคัดกรองที่มาของ Course ต่าง ๆ จึงต้องใช้วิจารณญาณของเราเองเข้าช่วย ลองเปรียบเทียบว่า Course ในความรู้ที่เท่ากันจากที่ต่าง ๆ สามารถแทนกันได้หรือไม่ ถ้าสามารถแทนกันได้ แล้วเรารู้สึกว่า Certificate ไม่ได้สำคัญขนาดนั้น เราก็ต้องเลือกที่ที่ประหยัดที่สุด
Accomplish more with less
คราวนี้ในเรื่องของ Certificate หรือชื่อภาษาไทยว่าใบรับรอง ผมนึกออกมี 3 ประเภทใหญ่ ๆ
- Certificate of Course Completion เรียนจบคอร์ส
- Certificate of Participation เข้าร่วมงาน, ร่วมกิจกรรม
- Certificate as Recognized ใบรับรองความสามารถ
ดังนั้นผมไม่ได้ห้ามว่าคุณไม่ต้องไปเรียน Course เพื่อเอา Certificate มา ให้เราคิดซะว่าเป็นเงินลงทะเบียนเรียนธรรมดา เพราะการมีคนสอนแบบที่เรารู้สึกเข้าใจง่าย มีคนชี้นำ มันเป็นอะไรที่ดีอยู่แล้วครับ แต่ถ้าเป็น Certificate as Recognized เช่น AWS, Azure, GCP อันนี้ผมสนับสนุนครับ แต่ถ้าคาใจข้อนี้ของผม ก็เปิดไปที่ LinkedIn ของผมก็ได้ครับ น่าจะมีตัวอย่าง Certificate หลากหลายรูปแบบให้ดูซักหน่อย ซึ่งผมก็คัดออกไปเยอะแล้ว
ผมอาจจะเจ็บมานิดหน่อย 555555555 สุดท้ายก็เอาไปใส่ Resume ไม่ได้เลยครับ สิ่งที่เหลือติดตัวก็คือทักษะความสามารถที่ได้จากการเรียน ยังไงก็ขึ้นกับวิจารณญาณ และลองเก็บไปคิดดูเล่น ๆ ครับ ไม่แน่อาจจะเป็นเพราะ Online Certificate ก็ได้นะ
ออกจาก Tutorial Hell!
Tutorial Hell เป็นสิ่งที่อันตรายมาก ๆ อย่างนึงในช่วงเวลานี้ ที่เรากำลังจะเติบโตมากขึ้น สาเหตุเกิดจาก
- ดู Tutorial แล้วก็โอเคเรียนให้รู้แล้วนะ
- ไม่ได้เอาไปใช้งานต่อ
- เรียนใหม่
- เรียนใหม่ x2
- เรียนเรื่องอื่นอีก
มันจะวนอยู่แบบนี้ครับ มันดีแหละที่ว่าพอมันมีโอกาสมา เราจะพร้อมทำอะไรทันทีบ้าง แต่บางครั้งการที่เราไม่ดูแล้วบีบ Resources ที่มีอยู่ให้จำกัด
- ประหยัดเวลา
- เราได้พื้นฐานแล้ว เราก็วนกลับไปใช้สูตรเรียนรู้จาก Error แทน
ส่งผลดีมากกว่าครับ (ทางผู้เขียนก็ตกไปพักใหญ่ ๆ เลยครับ ตอนนี้อาจจะขึ้นมาแถว ๆ ปากหลุมแล้ว) แต่ถ้ารู้สึกไม่เคลียร์อยู่ดี อันนี้เปิดหาดูเหมือนเดิมครับ แต่ว่าอย่างน้อยเราจะบีบเหลือแค่เรื่องที่เราไม่รู้ครับ
ทำ Side Projects ในแบบที่เราอยากจะทำ
ผมไม่รู้ว่ามันมีคำจำกัดด้านล่างมั้ย แต่เวลาเรียนรู้อะไร จะถูกแบ่งเป็น 2 หมวด
- Focus คือเรียนและลองทำเพื่อเน้นย้ำสิ่งที่เราถนัด และเกี่ยวข้องกับงานโดยตรง ทำให้เข้าใจลึกมากยิ่งขึ้น
- Expand คือเรียนเพื่อขยายความเข้าใจในสิ่งต่าง ๆ ให้กว้างมากขึ้น
และถ้านึกไม่ออกให้ลองหา Inspiration ว่า Company ต่าง ๆ ใช้ TechStack แบบไหน แล้วดูว่าในแต่ละแบบ เขาใช้ Technology หรือ Technique แบบไหนมาใช้แก้ปัญหา
Tech Stack at Ascend Money 2022
เปิด Tech Stack เบื้องหลังบริการ LINE MAN 2022
และถ้ายังไม่รู้ว่าจะทำอะไรดี และ company ที่เราอยากเข้าก็ไม่มีโชว์ TechStack?
เปิดดู Job Description ของ Company ที่อยากเข้า
อ่าน Stack ที่เกี่ยวข้องกับ Role นั้นและเริ่มทำ Project จากจุดนั้น
80/20 Rule => 20% เป็นของใหม่ แต่ผมรู้สึกว่าไม่จำเป็นต้อง 20 เสมอไปก็ได้เหมือนกัน แต่เกิน 40 ไม่ไหวนะ มึน นึกว่าถอดสมองเรียนใหม่ 😅
Subscription ในสื่อที่เราสนใจ แม้จะเสียค่าใช้จ่ายบ้างก็ไม่เป็นไร
เมื่อคุณกด subscribe Youtube channel ที่เกี่ยวข้องกับสายงาน ส่วนใหญ่แล้วหน้า Feed ของคุณจะปรับกลายเป็นสิ่งนั้น แล้วนอกจากนี้ยังมีตัวเลือกอื่น ๆ อีก ที่เป็นประโยชน์ต่อเรา รายการด้านล่างเป็นเพียงตัวอย่างที่มีอยู่
Medium Subscription
ออกไปเข้า Conference & Meetup บ้าง
การออกไปตามงาน Conference ที่จัด บางครั้งก็อาจจะมี Unlock Moment ให้กับตัวเอง หรือในบางครั้งสำหรับคนที่อยากสร้าง Connection หรือทำความรู้จักคนใหม่ ๆ ก็สามารถไปร่วมงานได้เช่นกัน
แต่สำหรับใครที่ไม่อยากออกข้างนอก แต่อยากเรียนรู้เพิ่มเติมก็สามารถติดตามได้จาก Livestream ตามเพจต่าง ๆ, LinkedIn หรือดู Conference ย้อนหลังจากต่างประเทศได้ ยกตัวอย่างเช่น
การสร้าง Impact ไม่จำเป็นต้องดัง แต่ถ้าอยากดังต้องสร้าง Impact
โดยส่วนตัวของผู้เขียน ชอบช่วยเหลือคนลับหลังมากกว่า พอเริ่มเป็นที่รู้จักทำให้ขยับตัวลำบากขึ้น แต่ก็ไม่ใช่ว่าจะหลบในมุมมืดตลอด เพราะการก้าวหน้าทางการงานมีสิ่งที่เรียก Visibility เป็นส่วนประกอบหลัก
ไม่ต้องรอให้คนชมว่าเราทำได้ดี เมื่อจบงานใด ๆ ให้ชมตัวเองด้วย
เป็นการรักษา Motivation ในความก้าวหน้าการงานของเรา เราผ่านปัญหาที่ต้องแก้มาแล้ว มันอาจจะหนักหนา หรือซ้ำซาก การชมตัวเอง การให้รางวัลตัวเอง ด้วยอาหารที่อร่อย ด้วยการออกไปเดินเล่น อย่างน้อยทำให้ไฟในใจดับช้าลง บ่อยครั้งที่ผมลืมข้อนี้ไป เพราะการวางมาตรฐานงานตัวเอง การคาดหวังจากตัวเอง จนทำให้มันเป็นวัน Bullshit หรือ Just a bad day ไป เป็นความรู้สึกที่ไม่ดีเอาซะเลย
ไม่ต้องเก่งที่สุด ถ้าแค่ไม่ล้ม เราก็แข็งแกร่งสุด ๆ แล้ว
ถ้าคุณไม่มีความรู้สึกเปรียบเทียบตัวเองกับใคร ขอแสดงความดีใจด้วยครับ คุณสามารถผ่านข้อนี้ได้ฉลุยเลย แต่สำหรับผมไม่ใช่อย่างนั้น บางทีผมก็มีภาพ Image ตัวเองที่เราอยากจะเป็น หรือคนที่ไหนก็ไม่รู้ที่เราดันอยากไปเปรียบเทียบตัวเองเอาเฉย ๆ
พอมันเกิดจังหวะนั้นขึ้น มันทำให้เวลาเราทำอะไรที่คนอื่นมองว่า “นายเก่งมากนะ” ผมกลับรู้สึกว่า “อ้าว มันก็เรื่องธรรมดาที่คนอื่น ๆ เขาก็ทำได้ไม่ใช่หรอ ผมก็แค่ทำตามปกติ” พอมันเป็นแบบนั้นขึ้นมา ทำให้เรารู้สึกว่ารั้งท้าย หรืออยู่กลาง ๆ เสมอ แต่รั้งท้ายนี่คือไปเทียบกับอะไร ไปเทียบกับใคร ไปเทียบกับมาตรฐานโซนไหนของโลกนี้ ผมก็ไม่รู้คำตอบของตัวเองเลย
สำหรับผมข้อความ “แค่ไม่ล้ม ก็แข็งแกร่งสุด ๆ แล้ว” มีที่มาจาก My Hero Academia ตอนที่บาคุโกบอกกับคิริชิม่า ที่กำลังคิดค้นท่าไม้ตายโจมตีแต่ก็คิดไม่ออกซักที บาคุโกได้ให้คำนี้ไปกับคิริชิม่า ทำให้ได้ท่าไม้ตายป้องกัน “Unbreakable” ขึ้นมา เป็นท่าที่ทำให้เราทนทานการโจมตีทุกสิ่งทุกอย่างที่เราสามารถทนได้ และเดินไปข้างหน้าได้
ดังนั้นพอเกิดอารมณ์แบบนี้ขึ้นในหัว หรือมีเหตุการณ์ที่ผมดันต้องไปเปรียบเทียบตัวเองขึ้นมา Quote นี้จะพุ่งเข้ามาที่หัวผม และทำให้เดินไปข้างหน้าต่อไป
เราอยากทำงานที่ Home country หรืออยากไปทำงานต่างประเทศ
อยากให้ทุกคนทำความรู้จักตัวเองมากกว่านี้ว่ามีปัจจัยใดที่ทำให้เราอยู่หรือเราอยากไป ส่วนของผมคิดว่าอยากไปเห็น Scale ที่ใหญ่กว่านี้ อยากสร้างคุณค่าให้คนมากกว่านี้ อยากทำ Backend ที่ Traffic มากกว่านี้ และโปรไฟล์ผมเหมือนมีภาพจำบางอย่างทำให้ไม่เตะตากับ Big Tech ที่นี่เลย ดังนั้นวิธีเดียวคือการ Reset
ด้านล่างก็เป็นลิงค์ทั่ว ๆ ไป ถ้าเกิดว่าอยากสมัครงาน
สามารถ Apply ได้ทั้งใน และต่างประเทศ (สามารถตั้งแจ้งเตือนได้)
สำหรับ Apply ต่างประเทศเท่านั้น
ทักษะ Technical/Behavioral Interviews
ปฏิเสธไม่ได้เลยว่า การที่จะเติมเต็มความฝันการได้ทำงาน Product based ระดับโลก เราจะต้องทำตามกระบวนการของเขา และโดยส่วนมากจะเกี่ยวข้องกับโจทย์ Coding Interview ที่เกี่ยวกับ Data Structures & Algorithms ซึ่งผมก็ไม่ได้เก่งมากมายอะไร ก็ฝึกฝนกันต่อไปครับ 😁
Free resources [Video-based]
การออกแบบและวิเคราะห์อัลกอริทึม โดย รศ.ดร.สมชาย ประสิทธิ์จูตระกูล ภาควิชาวิศวกรรมคอมพิวเตอร์ จุฬาลงกรณ์มหาวิทยาลัย
MIT 6.006 Introduction to Algorithms, Spring 2020
CSE 373 — Fall 2020 by Steven Skiena (Algorithms Design Manual)
Free resources [Text-based]
Tech Interview Handbook
Grind 75 questions ⭐️
NeetCode 150 ⭐️
LEETCODE PATTERNS ⭐️
Strivers A2Z DSA Course/Sheet ⭐️
Techie Delight
GeeksforGeeks
Grokking Algorithms เป็น Free-Ebook ถ้าอ่านบนเว็บ
Paid resource
Educative (ใช้เองแล้ว ตอนแรกหวือหวา หลัง ๆ ก็ Search หาจากข้างนอก)
Element of Programming Interviews (EPI)— (ของผมใช้ Java) ⭐️
Coding Interview Platform
Leetcode (ส่วนตัวใช้ Premium แต่ว่าใช้ฟรีก็ได้เหมือนกัน) ⭐️
AlgoExpert (Platform ดีนะ แต่โจทย์เกือบครึ่งนึงเหมือนมาจาก EPI)
Codewars
CodeSignal
System Design Interviews
Youtube: ByteByteGo
Youtube: System Design Primer Course
Youtube: System Design
Book: System Design Interview — An insider’s guide ❤️
Book: System Design Interview — An Insider’s Guide: Volume 2 ❤️
Low-Level Design Interviews (Object-Oriented Design Interviews)
Youtube: Low Level Design Primer Course
Behavioral Interviews (Culture Fits)
จากที่ผมฟังโดยส่วนตัว ผมชอบ Approach นี้มากกว่า STAR Method ซะอีก
Transparency Process from Big Tech
กระบวนการ Interview จะใกล้เคียงตามนี้ แต่แตกต่างไปตามแต่ละบริษัท
Google Interview tips
Interviewing at Amazon (Software Development Interviews)
ลองติดตาม Life at ??? กับที่ที่เราอยากจะไปเพื่อสร้างกิเลสให้ตัวเอง
Life at Spotify
Engineering at Uber | Uber
หัวข้อสมัครไปทำงานต่างประเทศกับทักษะ Technical/Behavioral Interviews ทางผู้เขียนวางแผนจะ Publish ประสบการณ์ตัวเอง (Fail 10+)ในวันปีใหม่ 2023รอติดตามกันด้วยนะครับ (รอผ่านโปรก่อนนั่นแหละ จะได้พูดได้)
อันนี้คือ Github resources ของผมเอง กำลังทำไว้แต่ยังไม่เสร็จดีครับ
https://github.com/marttp/java-tech-interviews-prep
Customer Obsession Mindset
คิดถึงผู้ใช้ เราทำอะไร เราสร้าง Impact อะไรให้เขา ในส่วนนี้ไม่จำเป็นต้องเป็น Customer เสมอไป ถ้าเราทำเพื่อ Developer Experiences ของทีม จริง ๆ แล้ว Customer ก็คือ เพื่อนร่วมทีม ร่วมโปรเจคของเรานั่นเอง
การคิดแบบคิดถึงผู้ใช้ จะตัดเรื่องเทคโนโลยีที่ใช้ออกไปก่อน เราแก้ปัญหา User ก่อน ปรึกษาแล้วคุยกัน แล้วค่อยทำย้อนกลับมา (Work Backwards)
Leadership Mindset
The best one สำหรับผมใน Leadership thinking ก็คือ Amazon Leadership principles ไม่ใช่ว่าอวยหรืออะไรแต่นี่คือสิ่งที่เราต้องคิดจริง ๆ เวลาทำงานสาย SWE เราคือ Engineering ที่ทำอะไรซักอย่างเพื่อ Customers ให้ดีที่สุด
ด้านล่างนี้ จะเป็น Playlist ที่อธิบายความหมายออกเป็นข้อ ๆ
Where do you see yourself in the next 5 years?
ลองตั้งคำถามในอนาคตว่า ถ้าเรายังทำงานสายนี้ เราจะเป็นยังไง เราจะเป็นแบบไหน ซึ่งจากที่ผมรู้มา ก็จะแบ่งใหญ่ ๆ เป็นดังนี้
Individual Contributor path (IC)
จะเป็น Path Advanced ไปเลย ก็คืองานก็จะเกี่ยวข้องกับทาง Technical นี่แหละ แต่ด้วยความที่ตำแหน่งสูงขึ้น จะ Focus ไปทาง Developer Experiences และคุณภาพของงาน รวมถึงกำหนด Culture ของโค้ดด้วยเช่นกัน คือ Principal Software Engineer, Staff Software Engineer
Manager path
จะเป็น Path ที่ดูเรื่องคนเป็นหลัก คอย Support และผลักดัน Engineer ก็คือ Focus ไปที่ด้านคนเป็นหลัก คือ Engineering Manager, Engineering Director, etc.
ในหลาย ๆ คน ก็อาจจะอยากไปเป็น Enterpreneur หรือผู้ประกอบการไปเลยก็มีครับ ก็จะถือว่าเป็นแนวความคิดอีกแบบนึงที่เป็นไปได้
English
ต่อมาจากตอนที่ 1 เลยครับ สำคัญมาก ๆ เลยนะ ทั้งด้าน Listening, Speaking, Reading, Writing
โลกนี้มันกว้างใหญ่ ใหญ่เกินกว่าที่เราจะจินตนาการ
ยังมีอะไรอีกมากมายเลยครับที่เรายังไม่รู้
- มีคนที่เก่งกว่าเรา และก็มีคนที่รู้น้อยกว่าเรา
- มีสิ่งที่เรายังไม่รู้
- มีสิ่งที่อาจจะเกิดขึ้นมาใหม่ก็ได้ในวันพรุ่งนี้
ดังนั้นการบริหารตัวเองให้มีความสุขในงานที่ทำ หรืออยากจะออกไปพักผ่อน ก็แล้วแต่ความสบายใจครับ แค่เรารู้สึกว่า เราทำแล้วมันดีต่อเรา ไม่กระทบคนอื่น และถ้าเราสามารถเป็นหนึ่งในแรงผลักให้กับคนอื่น ๆ รวมถึงเป็นประโยชน์กับโลกใบนี้ได้ จะดีมาก ๆ ครับ
Summary
เป็นยังไงกันบ้างครับ บทความนี้ไม่ได้ลงลึก Technical อะไรเลย ไม่ได้วาง Roadmap หรืออะไรด้วย เพราะว่าถ้าเราเข้ามาใน Career Path แล้ว เราจะเหมือนโดนบังคับให้เรียนรู้ตลอดเวลา ทางฝั่ง Technology ก็ไม่นิ่ง Company ที่เราทำงาน เพื่อนร่วมงานก็อาจจะมีทั้งที่ถูกใจ และไม่ถูกใจเรา
ดังนั้นบทความนี้ผมวางออกมาให้เป็นการดึงสติ ให้ข้อคิดและอยากให้ทุกคนคิดถึงเหตุผลในการใช้ชีวิตในสายงาน Software Engineer รวมถึงคิดถึงการใช้เวลาที่มีอยู่ของตัวเองให้คุ้มค่ากับคนที่เรารักมากที่สุด หวังว่าจะเป็นประโยชน์กับทุกคนไม่มากก็น้อย
สุดท้ายนี้ หากผู้อ่านมีข้อสงสัยเพิ่มเติม สามารถติดต่อได้ช่องทางด้านล่างนี้ หากผมสามารถช่วยได้ ก็ยินดีช่วยเหลือครับ
Facebook: Thanaphoom Babparn
LinkedIn: Thanaphoom Babparn
(ยังไม่รับ Opportunity ใด ๆ นะครับ ขอบคุณมาก ๆ ครับ)
