ตลอดระยะเวลาที่ผมทำงานมา มักจะมีน้อง ๆ Dev ชอบถามว่า “ทำยังไงผมถึงจะเก่งครับ” “ทำยังไงผมถึงจะโตได้มากกว่านี้ครับ” หลาย ๆ ครั้งผมก็จะตอบไปว่าแต่ละคนควรพัฒนาจุดไหน หรือควรเรียนรู้อะไรเพิ่ม แต่หลายครั้งที่เมื่อเวลาผ่านไป น้อง ๆ ก็กลับมาพร้อมคำถามเดิม เพิ่มเติมคือ “ผมก็รู้เรื่องนี้มากขึ้นแล้ว ทำไมผมยังไม่เก่งขึ้นเลย”
นั่นแหละครับ เพราะมันไม่ใช่แค่ “รู้” มากขึ้นเท่ากับ “เก่งขึ้น” …
ในโลกของ Software Engineering, การเติบโตไม่ได้วัดจากจำนวน Commit, จำนวนบรรทัดที่คุณเขียน, จำนวน Project ที่คุณทำ หรือคลังความรู้ในหัวคุณ แต่มันวัดจาก “Mindset” และ “ความสามารถในการปรับตัว” ของคุณ ซึ่งสะท้อนผ่านสิ่งที่คุณพูดบ่อย ๆ บทความนี้รวบรวมมาจากที่เคยสังเกตว่า Dev ที่ ”เก่ง” จะไม่พูดประโยคพวกนี้
หากคุณเคยใช้ 10 ประโยคนี้บ่อยครั้ง… ถึงเวลาที่คุณต้องหยุดสำรวจตัวเองก่อนว่า เพราะแบบนี้หรือเปล่าที่หยุดตัวคุณเองจากการเป็น Dev ที่เก่งขึ้น เพราะมันคือประโยคที่คนเก่งเค้าไม่พูดกัน
1. "ก็ task เขียนมาไม่ละเอียด”📋
การคาดหวังว่าทุก Requirement จะต้องสมบูรณ์ 100% คือความคิดที่ทำให้เรากลายเป็นผู้รับคำสั่งที่ไม่มีความคิดสร้างสรรค์ ไม่คิดวิเคราะห์ให้รอบด้านแบบที่คนเก่งเค้าทำกัน
Dev ที่เก่งคือผู้เชี่ยวชาญในโดเมน (Domain Expert) ที่สามารถ ‘ค้นพบ‘ ข้อมูลที่ขาดหายไปได้เอง การบ่นโดยไม่เสนอทางออก คือการโยนปัญหาการสื่อสารกลับไปที่ผู้ใช้งาน
ที่จริงแล้ว การรู้ว่า Task มีข้อมูลไม่พอที่จะทำงานก็ถือเป็นการเริ่มต้นที่ดี เพราะแปลว่าคุณวิเคราะห์ได้ว่า ถ้าทำไปตามนี้อาจจะเกิดความเข้าใจผิดได้
แล้วในการเป็น Dev ที่เก่งขึ้น ควรพูดว่าอะไรถ้า Task ที่เราได้รับมีข้อมูลไม่พอ คำตอบก็คือ คุณควรทำความเข้าใจใน Context ของ Task นี้และควรบอกได้ว่ามันยังขาดอะไร และคุณคิดว่ามันควรเป็นยังไง เช่น
“ผมอ่าน Task นี้แล้ว ผมคิดว่ามีจุด A B และ C ที่ขาดไป ผมอยากขอนัดซัก 15 นาทีเพื่อเล่าความเข้าใจต่อเรื่อง A B และ C ให้ฟังว่าผมเข้าใจถูกมั้ย เพื่อให้เริ่มทำ Task นี้ได้ ได้มั้ยครับ?”
2. "Requirement เปลี่ยนอีกแล้ว/Spec ไม่นิ่งเลย" 🔄
ในมุมมองของคนที่ทำงานในแวดวง Tech การบ่นแบบนี้ไม่ใช่แค่การแสดงความหงุดหงิด แต่มันคือสัญญาณเตือนของความล้มเหลวที่มาจากรากฐาน 2 อย่าง:
- Mindset ที่ไม่เข้าใจธรรมชาติของ Agile Development (ที่ความเปลี่ยนแปลงคือ ‘Input’ สำคัญและหลีกเลี่ยงไม่ได้) และ
- ‘การขาดความยืดหยุ่นทางสถาปัตยกรรม‘ (Architectural Rigidity)
หากคุณเป็น Dev ที่เก่งและเข้าใจหลักการนี้แต่แรก คุณจะออกแบบโค้ดและโครงสร้างให้มี Low Coupling และใช้ Abstraction Layer เพื่อคาดการณ์และรองรับการเปลี่ยนแปลงในอนาคต การบ่นจึงเป็นเหมือนการยอมรับว่า “ฉันออกแบบไว้แบบไม่ยืดหยุ่นเพียงพอที่จะปรับตัวตาม” แทนที่จะเป็นผู้แก้ปัญหาอย่างสร้างสรรค์ วิธีคิดของ Dev ที่พยายามพัฒนาตัวเองแทนที่จะบ่นก็คือ
“เราจะปรับโครงสร้าง/เพิ่ม Abstraction Layer อย่างไรเพื่อรองรับการเปลี่ยนแปลงประเภทนี้ได้ง่ายขึ้นในอนาคต?”
3. "ขอ Hard Code ไปก่อน, เดี๋ยวค่อยมาแก้/Refactor ทีหลัง" 🚀
คำว่า ‘เดี๋ยวค่อยมาแก้‘ มักจะไม่เคยเกิดขึ้นจริง การคิดแบบนี้ คือการตัดสินใจสร้าง ‘Technical Debt’ ตั้งแต่วันแรก ทั้งที่รู้ว่าต้องมีการแก้ไขต่อในอนาคต และนำมาซึ่งการออกแบบที่ล้มเหลว
เพราะการใช้ทางลัดเพื่อแลกกับความเร็วในระยะสั้นจะนำมาซึ่ง Tight Coupling และความยุ่งยากในการ Maintain ในอนาคต
สิ่งที่ควรจะพูดก็คือ การบอกผลกระทบ รวมถึงการคาดการณ์โอกาสที่ต้องมาแก้ไขในอนาคตและประเมิน Effort ในการแก้ไขในอนาคต เพื่อให้ผู้ที่เกี่ยวข้องรู้ข้อมูลเพื่อตัดสินใจ เช่น
“การออกแบบนี้จะทำให้เกิด Dependency X ซึ่งจะกระทบต่อการแก้ไขในอนาคต ในกรณีที่ต้องเพิ่ม Y เป็นไปได้ไหมที่ผมจะขอใช้เวลาเพิ่มอีก N ชั่วโมง เพื่อสร้าง Interface/Configuration Layer ที่ถูกต้องตั้งแต่ตอนนี้ เพื่อให้รองรับการทำงานในอนาคตซึ่งมีโอกาสเกิดขึ้นสูง ซึ่งการที่จะต้องกลับมา Refactor ในภายหลัง อาจจะต้องใช้เวลาหลายเดือน“
4. "ผมไม่แน่ใจ... ต้องทำ Proof of Concept (PoC) ก่อน" 🧪
การตัดสินใจเลือก Solution อะไรซักอย่าง ควรอยู่บนพื้นฐานของ Engineering Fundamentals, Design Patterns, และ Best Practices การใช้ PoC เกินความจำเป็นสำหรับทุกเรื่องคืออาการของ Analysis Paralysis หรือการขาดความมั่นใจในหลักการที่เราเรียนรู้
การ PoC ควรมีไว้สำหรับ ‘การลดความเสี่ยง‘ ในเทคโนโลยีใหม่ที่มีข้อมูลรองรับน้อย หรือการที่ใช้เพื่อเคสที่เฉพาะเจาะจงที่แทบไม่เคยมีคนใช้มาก่อน ไม่ใช่ใช้เพื่อยืนยันทุกทางเลือก
ดังนั้น สิ่งที่ควรทำคือ การศึกษาจาก Evidence และหลักการทั่วไป และประเมินความเสี่ยงหรือผลกระทบที่เป็นไปได้จากการที่ยังไม่ได้ PoC เพื่อให้ผู้ที่เกี่ยวข้องรับทราบ เช่น
“จากเอกสาร X และหลักการ Y และจาก Case study ที่ผมไปศึกษามา โซลูชัน A ควรทำงานได้ดีในเคสที่เราจะนำมาใช้งาน จะมี Case N ที่ผมยังไม่มั่นใจ แต่คิดว่าเราสามารถปรับปรุงเพิ่มเติมจาก Solution A ได้ในอนาคตแบบไม่ยาก โดยที่ผมคิดว่าไม่จำเป็นต้อง PoC ก่อนเพราะการ PoC จะทำให้เราใช้เวลามากขึ้นโดยไม่จำเป็นครับ“
5. "โอเค/ผมทำได้... (แต่ไม่ได้บอกปัญหาให้ใครรู้)" 🤫
การสื่อสารที่โปร่งใสคือเสาหลักของ Project Management
Dev ที่เก่งจะเข้าใจว่าปัญหาที่เราเก็บไว้กับตัวคือ Bottleneck ที่จะทำลาย Productivity ของทั้งทีม การเก็บปัญหาเพราะกลัวหรืออายไม่ใช่การเป็น Individual Contributor ที่ดี แต่คือการขัดขวางการเติบโตของ Project
และรวมถึงตัวคุณเองด้วย!
Dev ที่มีศักยภาพที่จะเก่งขึ้น หรือ Dev ที่เก่งแล้ว จะรู้ว่าปัญหาของตัวเองคืออะไร และพร้อมจะบอกเพื่อแก้ไข เราจึงควรบอกปัญหาอย่างตรงไปตรงมาว่า:
“ผมเจอ Blocking Issue X ต้องใช้เวลา/ทรัพยากรเพิ่ม Y ชั่วโมง/วัน เพื่อแก้ปัญหานี้ ทีมมีใครเคยเจอเคสนี้มาก่อนไหม? พอจะมีคำแนะนำหรือช่วยอะไรได้บ้างมั้ยครับ“
6. "ผมเขียนโค้ดนี้เมื่อปีที่แล้ว จำไม่ได้แล้วว่ามันทำงานยังไง" 🤔
ในทางวิศวกรรม โค้ดที่ดีย่อมสามารถอธิบายตัวเองได้ (Self-Documenting Code) การจำไม่ได้ว่าโค้ดตัวเองทำงานอย่างไรแสดงว่าโค้ดนั้น ขาดความชัดเจน (Clarity) และบริบท (Context) ซึ่งมาจากการตั้งชื่อตัวแปรที่ไม่สื่อสาร หรือการเขียน Function ที่ทำหลายอย่างเกินไป
หรืออาจหมายถึงเราขาดทักษะในการอ่านโค้ดเพื่อทำความเข้าใจ Flow และ Architecture ของมันด้วย
สิ่งที่เราต้องทำคือ: ทันทีที่เขียนโค้ดเสร็จต้องแน่ใจว่ามัน Clean, Testable, และใช้หลักการ Solid (หากเป็นไปได้) เพื่อให้โค้ดสื่อสารกับตัวเราเองในอนาคตและเพื่อนร่วมทีมได้ทันที
“ผมเขียนโค้ดนี้เมื่อปีที่แล้ว จำไม่ได้แล้วว่ามันทำงานยังไง แต่คิดว่าสามารถกลับไปอ่าน Code และทำความเข้าใจได้โดยน่าจะใช้เวลาไม่นานครับ”
7. "มันเป็นปัญหาของ Environment/Network/Infrastructure ไม่เกี่ยวกับโค้ดผม" 🖥️
การเข้าใจระบบโดยรวม (System Thinking) เป็นทักษะสำคัญที่เหนือกว่าการเขียนโค้ด ดูเผิน ๆ อาจจะเหมือนเป็นแค่การโยนความรับผิดชอบ แต่การพูดประโยคนี้ สะท้อนการมีขอบเขตความรู้ที่จำกัดและการขาด Growth Mindset ของ Dev คนนั้น ๆ ด้วย
Dev ที่เก่งหรือมีศักยภาพในการพัฒนา จะต้องเข้าใจหรือมีความพยายามที่จะเข้าใจ Lifecycle ทั้งหมดของระบบ ไม่ว่าจะเป็น Code หรือ Environment/Network/Infrastructure จนถึง Production Monitoring
เราควรเปลี่ยนเป็น:
“ผมตรวจสอบ Log ใน X (เช่น Grafana/Prometheus) แล้ว พบว่ามี Latency สูงที่ Y อาจจะมีปัญหาบางอย่างที่ Z ขอให้ทีม Infra/Ops ช่วยตรวจสอบ Config/Resource ที่ Z หน่อยครับ”
ซึ่งเป็นการแสดงความรับผิดชอบในการสืบสวนปัญหาเบื้องต้น รวมถึงสามารถ Scope สาเหตุของปัญหาได้ ซึ่งสะท้อนถึงความเข้าใจในภาพรวมของระบบอย่างที่ควรจะเป็น
8. "Code นี้เขียนมาไม่ดี มันเป็นโค้ดของ Dev คนเก่า" 👻
กฎข้อเดียวคือ: โค้ดทุกบรรทัดที่คุณแตะ คือโค้ดของคุณ การอ้างถึง “Legacy” เป็นข้ออ้างในการไม่ปรับปรุงหรือทำความเข้าใจโค้ดเก่า
Dev ที่เก่งจะมองเห็น “โอกาส” ในโค้ดเก่าเพื่อเริ่มกระบวนการ Incremental Refactoring (การปรับปรุงทีละเล็กละน้อย) เราควรเปลี่ยนการพูดถึงโค้ดเก่าเป็นการวางแผนเชิงรุก:
“ผมกำลังวางแผนที่จะ Isolating และ Refactor ส่วนของ X โดยใช้ Strangler Fig Pattern เพื่อลด Technical Debt ส่วนนี้ลง โดยแผนการทำส่วนนี้จะไม่ได้กระทบต่องานใน Feature หลักครับ“
9. "ผมทำไม่ได้ (หรือ) ไม่น่าจะเสร็จทัน... (แต่ไม่เสนอทางออก)" ⏰
การยอมรับข้อจำกัดโดยไม่สร้างทางเลือก คือการส่งมอบความล้มเหลว
Dev ที่เก่งมาจากการเป็น Problem Solver และ Risk Mitigator การพูดว่า ‘ไม่ทัน‘ โดยไม่มี Mitigation Plan คือการโยนปัญหาให้ Project Manager/Team Lead แก้ไขแต่เพียงผู้เดียว
เมื่อเสนอทางเลือก ต้องมองในมุม Business Impact เสมอ เช่น “จากข้อมูลปัจจุบัน X จะไม่เสร็จทัน D (Due Date) ผมขอเสนอ 3 ทางเลือก โดยเน้นถึงผลกระทบต่อธุรกิจในแต่ละข้อดังนี้:
- Scope Down: ตัด Feature Y ออกไปก่อน (Impact: ลูกค้าจะยังใช้ฟังก์ชัน F ไม่ได้)
- Minimum Viable Solution (MVS): แทนที่ Feature F ด้วย G (Impact: ฟังก์ชัน G ทำงานได้ไม่สมบูรณ์เท่า F แต่ยังตอบโจทย์หลักของธุรกิจได้ในเวลานี้)
- Resource Boost: ขอให้ Z มาช่วย Pair Program เพื่อเร่งงานนี้ (Impact: เพิ่มค่าใช้จ่าย/ดึง Z ออกจากงานสำคัญอื่น)
- 4. Delay: เลื่อน D ไปเป็น D+n (Impact: อาจพลาดกำหนดการเปิดตัว/ส่งผลต่อ Revenue R ในไตรมาสถัดไป)
ส่วนตัวผมแนะนำตัวเลือกที่ 2 มากที่สุดครับ เพราะใช้เวลาไม่มาก และได้ผลพอ ๆ กัน“
10. "อยากได้อะไรก็เปิด task มา" 🧱
การยึดติดกับกระบวนการ (Process) มากกว่าการร่วมมือ (Collaboration) เป็นสัญญาณอันตราย
Dev ที่เก่งจะเข้าใจว่าการแก้ไขเล็กน้อยที่ใช้เวลาไม่กี่นาที แต่มีมูลค่าทางธุรกิจสูง ควรทำทันทีตามหลักการของ Agile
การปฏิเสธทุกสิ่งที่ไม่ใช่ Ticket ก็เหมือนการที่คุณทำตัวเป็นคนเฝ้าประตู ไม่ใช่ Team contributor อย่างที่ควรจะเป็น และแน่นอนว่า ทุกวันนี้ Dev ที่เก่งถึงขนาดที่สามารถทำงานแบบฉายเดี่ยวน้อยลงทุกวัน ทุกองค์กรต่างมองหาคนที่ทำงานเป็นทีมได้ และเป็นคนที่เข้าใจภาพรวมมากกว่าการมองแค่ความสะดวกสบายของตัวเอง
การเป็น Dev ที่เก่งขึ้นไม่ได้อยู่ที่การเรียนรู้ Framework ใหม่ล่าสุด แต่คือการ “ปรับเปลี่ยนวิธีคิด” ให้เป็น Engineer ที่เน้น ความรับผิดชอบ (Ownership), ความยืดหยุ่น (Flexibility), การบริหารความเสี่ยง (Risk Management) และ การปรับปรุงอย่างต่อเนื่อง (Continuous Improvement)
Dev ที่เก่ง ไม่ใช่ Dev ที่แค่เขียนโค้ดได้ แต่คือคนที่เข้าใจในสิ่งที่กำลังทำ เป็น Team player มี Mindset ที่พร้อมจะปรับปรุงและพัฒนาตัวเองอย่างต่อเนื่อง จึงสื่อสารออกมาด้วยประโยคที่ทำให้คนรอบข้างรับรู้ทัศนคติที่พร้อมเติบโตได้
แล้วคุณล่ะ ยังพูด 10 ประโยคนี้อยู่หรือเปล่า?
ติดตามบทความใหม่ ๆ คลิกเลย
