ข้อผิดพลาดที่นักพัฒนาระดับ Junior มักจะทำ
การส่งโค้ดที่ทำงานได้คือมาตรฐานขั้นต่ำ แต่มันไม่ใช่เป้าหมาย
ครั้งหนึ่งผมเคยรีวิว pull request ที่ต้องใช้เวลาถึง 45 นาทีกว่าจะเข้าใจ ตรรกะนั้นถูกต้อง การทดสอบผ่านหมด แต่โค้ดกลับถูกเขียนขึ้นราวกับว่าจะมีแค่ผู้เขียนคนเดียวเท่านั้นที่จะได้อ่านมัน
เมื่อผมให้คำแนะนำ (feedback) นักพัฒนากล่าวว่า "แต่มันก็ทำงานได้นี่ครับ"
เขาพูดถูก มันทำงานได้ และนั่นแหละคือปัญหา
นักพัฒนาระดับ Junior มักจะมุ่งเน้นไปที่ทักษะทางเทคนิค แต่ช่องว่างที่แท้จริงมักจะอยู่ที่นิสัยและวิธีคิด (mindset)
และนี่คือข้อผิดพลาดเล็กๆ น้อยๆ ที่จะทำให้คุณทำงานช้าลง:
เขียนโค้ดให้ตัวเองอ่านแทนที่จะเขียนให้คนอื่นอ่าน โค้ดถูกอ่านบ่อยกว่าถูกเขียนมาก ฟังก์ชันที่คุณเขียนในวันนี้อาจถูกแก้ไขโดยคนอื่นถึงสามคนในช่วงเวลาสองปี หากคนแปลกหน้าไม่สามารถเข้าใจโค้ดของคุณได้ภายใน 30 วินาที แสดงว่าคุณล้มเหลว
คัดลอกโค้ดโดยไม่เข้าใจ การใช้ Stack Overflow นั้นไม่เป็นไร แต่การคัดลอก regex pattern โดยไม่รู้ว่ามันทำงานอย่างไรนั้นอันตราย คุณกำลังสร้าง "กล่องดำ" (black box) ไว้ใน codebase ของคุณ และคุณจะไม่สามารถ debug มันได้เลยเมื่อเกิดปัญหา
เพิ่มความซับซ้อนโดยไม่จำเป็น บ่อยครั้งที่ Junior มักจะเข้าใจผิดว่าความซับซ้อนคือทักษะ พวกเขามักนำ design patterns มาใช้กับงานง่ายๆ การทำ abstraction ที่ไม่จำเป็นจะทำให้โค้ด debug ยากขึ้นและแก้ไขยากขึ้น ให้เพิ่ม abstraction ก็ต่อเมื่อคุณเริ่มรู้สึกถึงความลำบากจากการที่ไม่มีมันเท่านั้น
เพิกเฉยต่อข้อความแสดงข้อผิดพลาด error messages คือเอกสารประกอบ (documentation) ที่ได้มาฟรีๆ อย่าเพิ่งรีบไป Google ทันทีที่เห็น stack trace ให้ลองอ่านข้อความทั้งหมดดู เพราะมันมักจะบอกคุณอย่างชัดเจนว่าบรรทัดไหนที่ผิดพลาดและเพราะอะไร
ขอความช่วยเหลือเร็วเกินไปหรือช้าเกินไป อย่าเสียเวลาสามชั่วโมงกับปัญหาที่ใช้เวลาแก้แค่ 10 นาที เพราะนั่นคือความไม่มีประสิทธิภาพ แต่ในขณะเดียวกัน ก็อย่าทักไปหา Senior ด้วยแค่ภาพหน้าจอโดยไม่มีบริบทใดๆ ให้ใช้ "กฎ 20 นาที": ลองพยายามแก้ปัญหาด้วยตัวเอง 20 นาที จดบันทึกสิ่งที่คุณได้ลองทำไปแล้ว จากนั้นจึงขอความช่วยเหลือพร้อมกับข้อมูลเหล่านั้น
สร้างสิ่งที่เคยมีอยู่แล้วขึ้นมาใหม่ ก่อนที่คุณจะเขียน utility ตัวใหม่ ให้ลองค้นหาใน codebase ดูก่อน ทีมของคุณน่าจะเคยแก้ปัญหานั้นไปแล้ว
เขียน commit message ไม่ดี ข้อความอย่าง "fix bug" ไม่ได้บอกอะไรทีมของคุณเลย จงอธิบายว่าอะไรเปลี่ยนไปและเพราะอะไร ให้ปฏิบัติกับ Git history เสมือนว่าเป็นเอกสารประกอบ
มองว่าความต้องการ (requirements) คือกฎเหล็ก บ่อยครั้งที่ requirements มักจะตกหล่นกรณีที่เป็น edge cases อย่าเพียงแค่ทำตามสิ่งที่ได้รับมอบหมายมา แต่จงถามด้วยว่า "จะเกิดอะไรขึ้นถ้ามีบางอย่างผิดพลาด"
หยุดแค่ตอนกดปุ่ม "Merged" ความรับผิดชอบไม่ได้สิ้นสุดลงเมื่อ PR ของคุณถูก merge ให้ติดตามฟีเจอร์ของคุณไปจนถึงขั้นตอน QA คอยดูการทำงานใน production และอ่านรายงานข้อผิดพลาด (error reports) ด้วย
ช่องว่างที่ใหญ่ที่สุดคือความรับผิดชอบ (accountability) นักพัฒนาระดับ Senior ไม่ได้แค่เขียนโค้ด แต่พวกเขาแก้ปัญหาโดยไม่สร้างปัญหาใหม่ขึ้นมา
เลิกมุ่งเน้นแค่การทำให้ "เสร็จ" (done) แต่เริ่มมุ่งเน้นที่การทำให้ "ดี" (good)