ต้องการเป็นเว็บดีเวลอพ์เกอร์ที่เก่งจริง ต้องมีอะไรบ้าง?
งานแรกหลังจบบูทแคมป์/มหาวิทยาลัย — รู้สึกตื่นเต้น แต่จริงๆ แล้วไม่ง่ายเลย ต่างจากดูทูทอเรียล อ่านหนังสือ ทำพอร์ตโฟลิโอ ต้องสร้างเว็บจาก spec จริง ตรงไดดไลน์ และสำคัญที่สุด: ทำให้บอสและลูกค้าพอใจ!
เทคโนโลยีเปลี่ยนเร็วมาก อาจรู้สึกว่าต้องไล่เทรนด์ตลอดเวลา ไม่อยากล้าสมัย
แต่มีความลับ: คุณไม่ต้องกลัว
เวลาผ่านไป คุณจะได้ประสบการณ์ คล้ายกับการเรียนโค้ด — สามารถเรียนรู้การทำงานระดับสูงได้
เป็น self-taught developer 7 ปี ผ่าน learning curve และ impostor syndrome มา — แต่ก็ได้ประสบการณ์และทักษะมากมาย
1. เข้าใจว่าการเชี่ยวชาญทุกอย่างเป็น Marathon ไม่ใช่ Sprint
เพิ่งได้งาน — อยู่จุดเริ่มต้นของการเดินทางโค้ด Web development กว้างขวาง ต้องใช้เวลานานถึงจะเก่งจริง
ไม่ต้องรู้ทุกอย่างตอนนี้ — คุณเป็น beginner การคาดหวังสูงเกินไปทำให้เครียด
ผมพี่สาวอ่าน SAT (สอบเข้ามหาวิทยาลัย) ผมพยายามทำโจทย์ ไม่ถูกข้อไหน โกรธที่ไม่ได้คะแนนเต็ม — เหมือนเวลาโค้ดไม่出來 ไม่ต้องคาดหวังว่าเก่งทันที
มองภาพใหญ่ (bird's eye view) ของความก้าวหน้าในระยะยาว ไม่ใช่แค่ขณะนี้
2. พยายามแก้ปัญหาเองให้มากที่สุด ก่อนขอความช่วยเหลือ
ตอนเผชิญปัญหาใหม่ มี 2 ทาง: 1) บอกบอส "ไม่รู้ทำยังไง ทำให้หน่อย" — บรรเทาเครียดชั่วคราว แต่นักงานที่ไม่หาวิธีแก้ปัญหาเองจะเสียเวลาคนอื่น 2) Research เองจนหมดทาง แล้วค่อยไปถาม: "ลองทำ这样这样แล้ว คิดว่าอาจเกี่ยวกับ..."
พยายามเองมากที่สุด แล้วค่อยถามพร้อมแสดงว่าลองทำอะไรไปแล้ว
ประโยชน์: เรียนรู้ทักษะใหม่ระหว่างงาน (ได้เงินมาเรียน) + ไม่เสียเวลาทีมกับคำถามที่หาคำตอบเองได้ = เป็นทรัพย์สินของบริษัท
แต่มากเกินไป (ค้างหลายวัน) ก็ไม่ดี — ต้องหาจุดสมดุลเอง
3. คงความอยากรู้ (Stay Curious)
เริ่มงาน ได้ฟีดแบคดีว่า "ดูดข้อมูล nhưฟองน้ำ" ลองทุกอย่าง แม้ไม่รู้วิธี — มีความอยากรู้จริงว่าสิ่งต่างๆ ทำงานยังไง
ความอยากรู้เข้าใจ "ทำไม" เป็นหัวใจของวิศวกร อย่าปิดมันไว้เพื่อให้เสร็จเร็ว
หาคำตอบใน Stack Overflow แล้วอย่าหยุด — ใช้เวลาอ่านดูว่า solution เหล่านั้น fit กับโค้ดตัวเองยังไง ทำไมโค้ดเดิมพัง ทำไมตอนนี้ทำงาน — เข้าใจ concept แม้ไม่ครบ 100% ครั้งหน้าจะเก่งขึ้น
4. ปรับปรุงตัวเองตลอดเวลา (Always Be Improving)
ใช้ได้กับทุกด้าน: ปรุงอาหาร ขับรถ ความสัมพันธ์
พบว่าสิ่งไม่ราบรื่น — ถอยหลังมองภาพใหญ่: อยากให้เกิดอะไร ทำไมไม่เกิด?
- โค้ดพังเว็บ: เกิดอะไรขึ้น? กันยังไงครั้งหน้า? <โต้เถียงกับเพื่อนร่วมงาน: พูดอะไรทำให้โกรธขึ้น? ควรพูดยังไงให้ดีกว่า?
วิเคราะห์สถานการณ์ไม่ดี → หาสาเหตุ → หาขั้นตอนปฏิบัติจริง (actionable steps) ป้องกันซ้ำ
ยากเพราะ 본อินสติงค์อยากลืมสิ่งไม่ดี — แต่คิดเหมือน debugging ชีวิต: bug ซ้ำๆ = มีสิ่งที่ต้องเรียนรู้
แม้ผิดพลาดเล็กๆ การฝึก self-awareness + self-improvement ให้ผลดีระยะยาว
5. เก่งจริงในการแก้ปัญหา (Problem Solving)
งานใหญ่ของ developer = แก้ปัญหา (เขียนโค้ดใหม่ / debug โค้ดเก่า) เป้าหมาย: ทำให้มันทำงานได้ตามที่ต้องการ
ขั้นตอน: เข้าใจว่า "ควรทำงานยังไง" และ "ส่วนประกอบทั้งหมด" → หาจุดที่พัง → แก้ไข
ตัวอย่าง: ซ่อมโคมไฟ
พฤติกรรมที่ควรเป็น: กดสวิตช์ On → โคมสว่าง
ถ้าไม่สว่าง ตรวจสอบทีละขั้น:
- ไฟฟ้าบ้าน/ปลั๊ก ทำงานไหม?
- โคมเสียบปลั๊กไหม?
- สายไฟ/สวิตช์โคม ใช้งานได้ไหม?
- หลอดไฟ ชำรุดไหม?
ทดสอบทีละขั้น ใช้การกำจัด (process of elimination) หาตัวต้องหา
Debug โค้ดซับซ้อนกว่านี้มาก แต่กระบวนการเดียวกัน — debugging น่าหงุดหงิด อาจค้างวัน/สัปดาห์ แต่เมื่อแก้ได้ = รู้สึกเก่งมาก (exultation) = ส่วนที่ดีที่สุดของการเป็น dev
ทักษะ Non-technical (Soft Skills)
2 ข้อสุดท้าย ไม่เกี่ยวโค้ดเลย — เรียกว่า people skills
เราทำงานกับโค้ด แต่สุดท้ายทำงานกับ มนุษย์ เว็บ/แอพ สร้างให้คนใช้ ทำงานกับลูกค้า/เพื่อนร่วมงาน
Dev ที่เก่งจริง ไม่ได้แค่โค้ดเก่ง — เข้าใจ big picture และทำงานกับคนได้ดี
ทักษะเหล่านี้ยาก เพราะต้องการการคิดแบบต่างออกไป — หลาย dev ไม่คิดว่าต้องพัฒนา — จุดที่คุณแตกต่างออกไป
6. ปลูกฝัง Empathy (ความเข้าใจในอารมณ์ผู้อื่น)
Empathy = รู้สึกเข้าใจ อารมณ์ ความต้องการ มุมมองของผู้อื่น = วางตัวอยู่ในสถานการณ์ของเขา
ผมกับภรรยาโต้เถียง — เริ่มรู้สึกถูกต้อง 100% (ซึ่งไม่มีในความเป็นจริง) คุยกันจนเข้าใจกัน มุมมองของอีกฝ่าย — ไม่ใช่เรื่องชนะ/ถูกต้อง แต่เป็นเรื่องเข้าใจกัน
งานเหมือนกัน: จะมีข้อขัดแย้ง อย่าตัดสินเร็ว/เดาเรื่องร้ายของอีกฝ่าย — ส่วนใหญ่ไม่ได้เจตนาส่วนตัว
ลองคุยหา root cause: อาจ busy ลืมตอบอีเมล, อาจ meeting แย่สะสม stress มาทะเลาะ
Empathy ยังรวม: รู้จัก workload ของคนอื่น — คราว deadlines ใกล้ ไม่รบกวนเรื่องไม่ด่วน แต่อาจถามภายหลังว่า "เป็นไงบ้าง"
อ่านเพิ่ม: Ask a Manager (บล็อกให้คำแนะนำ workplace etiquette)
7. เป็น Proactive ไม่ใช่ Reactive
คุณสมบัติแยกคนสำเร็จกับคนธรรมดา
- Reactive: ทำงานที่มอบหมายเท่านั้น พัง纔修 不思考ป้องกัน ไม่มอง big picture "ไม่เกี่ยวกับฉัน = ไม่ใช่ปัญหาของฉัน" = short-term thinking
- Proactive: ทำงานมอบหมาย + ปรับปรุงเล็กๆ น้อยๆ ตลอดเวลา พัง → วิเคราะห์ → ป้องกันซ้ำ คิดกระบวนการให้มีประสิทธิภาพมากขึ้น
Proactive = ทำงานในปัจจุบัน เพื่อปรับปรุงอนาคต มอง big picture ยินดีลงมือทำ
เรียนรู้ผ่าน trial & error + observation — benefit ล้นหลามถึงชีวิตส่วนตัว
ปิดท้าย
ขอบคุณที่อ่าน! หวังว่าเคล็ดลับเหล่านี้จะช่วยนักพัฒนาใหม่ๆ ความคิดเห็น/คำถาม ยินดีตอบในคอมเมนต์ครับ
