🔥อย่าเรียกตัวเองว่า Dev ถ้ายังทำสิ่งนี้อยู่

1. “เขียนโค้ดโดยไม่ใส่คอมเมนต์”

ตอนเขียนนึกว่าเข้าใจหมด

แต่พอผ่านไป 3 วัน...

ก็กลายเป็น โค้ดของคนแปลกหน้าในอดีตเราเอง 😭

จำไว้: คอมเมนต์ = ของขวัญให้ตัวเองในอนาคต

2. “แก้โค้ดโดยไม่เข้าใจปัญหา”

เห็นบั๊ก → รีเฟรชสมองไม่ทัน → “ลอง if else เพิ่มอีกอันละกัน”

สุดท้ายกลายเป็น Spaghetti Code ระดับพรีเมียม 🍝

อย่าแก้ปัญหาด้วยความรู้สึก ต้องเข้าใจสาเหตุก่อนเสมอ

3. “ไม่เขียน test เพราะขี้เกียจ”

“ไว้ค่อยเทสต์ตอนใกล้เสร็จ” — นี่คือคำพูดก่อนวัน Deadline ล่มสลาย 🧨

เขียน test วันนี้ เพื่อไม่ต้องร้องไห้พรุ่งนี้

4. “พึ่ง AI ทุกอย่างโดยไม่คิดเอง”

พิมพ์ “fix this bug” แล้ว paste โค้ดทั้งก้อน

ผ่านแน่… ผ่านไปนรกของโปรดักชัน 🫠

AI ช่วยได้ แต่ Dev ต้องเข้าใจสิ่งที่มันทำก่อนเสมอ

5. “ไม่ดูแลสุขภาพ”

นั่งยันเช้า กินกาแฟแทนน้ำ

ได้ commit เยอะ แต่ได้หมอนรองกระดูกแถมฟรี

โค้ดดีแค่ไหนก็ไม่มีค่า ถ้า Dev ไม่เหลือแรงจะใช้ชีวิต

“Dev ที่ดี ไม่ได้วัดกันที่ Framework แต่ที่วัดคือ นิสัยเวลาเจอปัญหา”

แล้วคุณล่ะ… ยังทำข้อไหนอยู่บ้าง?

#สายDevต้องรู้ #โปรแกรมเมอร์ไทย #ชีวิตDev #ลาออก #ถามตอบ

2025/11/8 แก้ไขเป็น

... อ่านเพิ่มเติมถ้าคุณกำลังค้นหาเรื่อง “ตำแหน่งโปรแกรมเมอร์” แล้วรู้สึกว่างาน Dev มันกว้างจนเลือกไม่ถูก อันนี้คือภาพรวมแบบที่ฉันเคยใช้ทำความเข้าใจตอนหางาน + เช็กลิสต์นิสัยการทำงานที่ทำให้เรา “ดูเป็นมืออาชีพ” มากขึ้น (ไม่ใช่แค่เขียนโค้ดได้) 1) ตำแหน่งโปรแกรมเมอร์ที่เจอบ่อย ๆ (และต่างกันตรงไหน) - Frontend Developer: โฟกัสหน้าบ้าน/ประสบการณ์ผู้ใช้ เช่น UI, state, performance บนเว็บหรือแอป สิ่งที่โดนถามบ่อยคือการจัดการ component, การเรียก API, และการ debug หน้าจอ - Backend Developer: ดูแลหลังบ้าน เช่น API, database, auth, scalability ความเสถียรของระบบ และการแก้บั๊กแบบตามรอย log - Full-stack Developer: ทำได้ทั้งหน้าและหลัง แต่ความคาดหวังมักคือ “ทำงานได้ครบวงจรในขอบเขตหนึ่ง” ควรชัดเจนว่าเราถนัดฝั่งไหนมากกว่า - QA / Test Engineer: ทำให้ระบบพัง “อย่างมีเหตุผล” เพื่อกันพังในโปรดักชัน เน้น test case, automation, regression และร่วมมือกับ Dev เพื่อคุณภาพงาน - DevOps / SRE: ดู deployment, CI/CD, monitoring, incident response ทำให้ปล่อยของได้เร็วและปลอดภัย - Mobile Developer: โฟกัส iOS/Android เรื่อง lifecycle, performance, build pipeline และการดีบักบนเครื่องจริง 2) อ่านประกาศงานตำแหน่งโปรแกรมเมอร์ยังไงไม่ให้หลง ฉันจะดู 3 ส่วนนี้ก่อน: (1) งานที่ทำทุกวัน (responsibilities) (2) สิ่งที่ต้องทำได้จริง (must-have) (3) เครื่องมือที่ “มีไว้ใช้” ไม่ใช่ “ต้องเทพ” (nice-to-have) แล้วจับคู่กับโปรเจกต์ที่เราเคยทำ เพื่อเล่าเป็นเรื่องเป็นราวได้ 3) เช็กลิสต์นิสัย Dev ที่ทีมส่วนใหญ่ให้คะแนนสูง (ต่อยอดจากโพสต์นี้) - คอมเมนต์/เอกสารแบบพอดี: ไม่ต้องเขียนทุกบรรทัด แต่เขียนเหตุผลของการตัดสินใจ (why) จะช่วยตัวเองและคนอื่นมาก - แก้บั๊กแบบมีขั้นตอน: ทำซ้ำให้ได้ → เก็บหลักฐาน (log/stack trace) → หาสาเหตุ → แก้ → ใส่ test กันพังซ้ำ - เขียน test เท่าที่คุ้ม: เริ่มจากส่วนที่พังแล้วกระทบผู้ใช้ก่อน เช่น validation, calculation, business logic แล้วค่อยขยับไป integration/e2e - ใช้ AI ให้ปลอดภัย: ใช้ช่วยอธิบาย/ยกตัวอย่างได้ แต่ก่อน paste ควรถามตัวเองว่า “โค้ดนี้ทำอะไร, edge case คืออะไร, มี test ไหม” โดยเฉพาะงานโปรดักชัน - ดูแลสุขภาพเพื่อระยะยาว: งาน Dev ต้องใช้สมาธิ ถ้านอนน้อย/กาแฟแทนน้ำ สุดท้าย productivity ตกและบั๊กเพิ่มแบบไม่รู้ตัว 4) ถ้ากำลังเลือกตำแหน่งโปรแกรมเมอร์ให้เริ่มยังไง ลองเลือกจาก “สิ่งที่สนุกเวลาทำ” มากกว่า framework เช่น ชอบทำหน้าจอ/UX → frontend, ชอบตรรกะ/ข้อมูล → backend, ชอบคุณภาพและการจับผิด → QA, ชอบระบบและการปล่อยงาน → DevOps แล้วทำโปรเจกต์เล็ก ๆ ให้มีหลักฐาน (Git, README, วิธีรัน, และ test ขั้นต่ำ) สรุปคือ ตำแหน่งโปรแกรมเมอร์มีหลายทาง แต่ไม่ว่าคุณจะเป็นสายไหน “Dev ที่ดี” มักชนะด้วยนิสัยเวลาเจอปัญหา: อธิบายได้ แก้เป็นขั้นตอน มี test เท่าที่จำเป็น ใช้ AI แบบคิดเอง และดูแลสุขภาพให้ไหวระยะยาว