สรุปความผิดพลาดของ Junior Dev ในมุมมองของ Dave Farley

คุณ Dave Farley เป็นผู้ก่อตั้ง Continuous Delivery Inc. เป็นนักคิดเกี่ยวกับเรื่อง CI/CD, Devops, Software Development

โดยคุณ Dave มองไว้อยู่ 8 เรื่องดังนี้

1. Software Development is all about coding

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

Software Development ก็เช่นกัน ไม่ได้มีแค่การ code แต่เป็นความเข้าใจและแก้ปัญหา ไม่ต่างจากช่างไม้

คนที่เป็น Software Dev ที่ดี นอกจากความสามารถแล้ว จะมีเรื่องความเข้าใจสิ่งที่จะทำอย่างลึกซึ้งด้วย

ซึ่งวิธีการคือการ ที่ต้อง Take Ownership กับปัญหานั้นๆ

2. Requirement ที่ถูกต้อง ต้องมาจากฝั่ง business เท่านั้น

ตรงนี้จะมีสมมติฐานต้นว่า

Software Dev ก็เขียนโค้ดไป แล้วมีคนป้อนให้ว่าทำยังไง เหมือนเป็นแค่ล่ามแแปลภาษา

ซึ่งก็เจ๊งกันมาหลายที่

สิ่งสำคัญคือ ไม่มีใครที่รู้คำตอบหมดทุกอย่าง มันต้องช่วยกันดูในแต่ละมุมมอง ไม่ว่าจะเป็น Business , Design, Technology

คน Business มันก็ไม่รู้หรอกว่า Code จาก Stack Overflow 3 ชิ้น ได้ผลลัพธ์เหมือนกัน แต่ Side effect อาจจะไม่เหมือนกันก็ได้

นอกจากนั้น พึงระลึกว่า ทุกสิ่งที่คิดคือการคาดเดา เราต้องค่อยๆ ทำเป็น step เพื่อมา proof ความคาดเดานั้น

3. Speed is all that matters

ความเร็วเป็นสิ่งสำคัญ แต่หลายครั้งไปให้ความสำคัญกับความเร็วที่ผิดตัว

เช่น Typing speed

ความเร็วที่อยากให้เป็นคือ ความเร็วจากการ work smart เช่นการเขียนโค้ดน้อยลงเพื่อแก้ปัญหา

ซึ่งจะเกิดขึ้นได้จาก การทำความเข้าใจปัญหา วาดรูป หาจุดเชื่อมต่อ พอเข้าใจแล้วค่อยโค้ด

ถ้าโค้ดเยอะๆ อาจจะยังไม่เข้าใจสิ่งที่จะทำก็เป็นได้

4. My job is to code, not to understand the problem domain

ปัญหาคล้ายๆ ข้อ 2 ก็จะได้งานที่ไม่เข้าใจ แล้วก็ต้องแก้บ่อยๆ

5. I can’t ask for help! It show that I don’t know enough

เรื่องนี้เป็นเหมือน imposter syndrome หลายคนมีความกังวลว่าถ้าถามจะแสดงความไม่ฉลาดออกมา

อย่างไรก็ตามคนที่เก่งขึ้นเท่าไหร่ จะรู้ว่าไม่รู้อะไรมากขึ้นเท่านั้น

คนเก่งๆ ก็จะถามคำถามมากขึ้น และเก่งขึ้นไปเรื่อยๆ

อย่างไรก็ตามข้อควรระวังคือ การถามปัญหาเดิมๆ ซ้ำๆๆๆ

ลอง limit ตัวเองให้ถามเรื่องเดิมไม่เกิน 2 ครั้ง ถ้าเกิน อยากให้ลองคิดอีกรอบว่า ปัญหาที่แท้จริงคืออะไร กันแน่

6. Software Architecture is for the expert

เขาอยากให้มองว่า Software Architecture คือ Tourist Map มันไม่จำเป็นต้องลง Detail เยอะ แต่ควรจะอธิบายเบื้องต้นได้ว่า ของทำงานยังไง

7. Testing is someone else’s job

ปัญหาคลาสสิก

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

Developer ควรจะเป็นคนที่ควรเขียน Test ที่สุดเพราะ

• เป็นคนที่มีโอกาสที่จะพัง Code มากที่สุด
• เป็นคนที่จะต้องซ่อมถ้ามันผิด
• เป็นคนที่จะต้องเจอปัญหาเป็นคนแรก

8. I would like to do a better job, but may boss won’t let me

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

ใครสนใจลองดูเพิ่มเติมได้ที่นี่ครับ