Incompetence misconception (TH)

เรามักเชื่อว่าสิ่งที่ขัดขวางการพัฒนาคือการไม่โทษตัวเอง เราเชื่อว่าการโทษคนอื่นแต่ไม่โทษตัวเองทำให้ย่ำอยู่กับที่

แต่ผมมองว่าในการเขียนโปรแกรม โปรแกรมเมอร์มักจะไม่โตขึ้นเพราะโทษตัวเองเสียมากกว่า

หลายๆ ครั้งเวลาที่เราเขียนโค้ดไม่ออก ทำงานไม่เวิร์ค ทำงานช้า เราเลือกจะโทษความไร้ความสามารถของตัวเอง โดยไม่ตั้งคำถามกับสิ่งที่เป็นอยู่

ผมแนะนำว่าถ้าพบว่าตัวเองทำงานได้ไม่ดี เราควรจะตั้งคำถามกับทุกอย่าง

Architecture ของซอฟต์แวร์มันดีหรือไม่: ทำไมฉันจะเขียนโค้ดบรรทัดนี้แล้วต้องไปค้นหาที่มาที่ไป 5–10 ไฟล์ (ฟะ) จริงๆ มันควรจะมีวิธีแบ่งที่ดีกว่านี้มั้ย?

Programming language มันดีพอหรือไม่: ทำไมเราไม่สามารถสั่งการคอมพิวเตอร์ให้ทำแบบนี้ได้ในคำสั่งที่สั้นลงนะ ภาษาอื่นมันก็ต้องยาวๆ ยุ่งยากๆ แบบนี้ด้วยเหรอ

Design pattern ที่ใช้อยู่มันเหมาะสมมั้ย: ทำไมเราจะเขียนคลาสเพิ่มหนึ่งอันแล้วต้องไปเอา 4 Factory มาสร้าง 4 Class แล้ว DI ไปสร้างอีกออบเจ๊กต์นึง แล้วก็เอาออบเจ๊กต์นั้นมาเป็นใส่ใน Contructor ตัวสุดท้าย มันมีวิธีที่ดีกว่านี้มั้ย

Code ที่เป็นอยู่มันเหมาะสมมั้ย: โค้ด 400 บรรทัดในไฟล์เดียวมันทำให้เราหาอะไรไม่เจอหรือเปล่า มันมีการแบ่งที่ดีกว่านี้มั้ย

เมื่อเรื่องพวกนี้เกิดขึ้น คุณควรจะตั้งคำถามกับทุกอย่างที่มันเป็น

ตรงข้าม ถ้าคุณโทษว่ามันลำบากเพราะ “ความไร้ความสามารถ” ของตนเอง โทษว่าเออฉันเก่งไม่พอสินะ โดยไม่ตั้งคำถามกับอะไรเลย

คุณสูญเสียโอกาสที่จะเรียนรู้ Better architecture

คุณสูญเสียโอกาสที่จะเข้าใจ Design pattern

คุณสูญเสียโอกาสที่จะเข้าใจ Core concept ของ Programming

คุณสูญเสียโอกาสมากมายจริงๆ

ในวินาทีที่คุณเลิกตั้งคำถาม

แล้วหันมาโทษความไร้สามารถของตน

ส่วนตัวผมชอบอ่าน Architecture ไม่ใช่เพราะผมรัก Clean code อะไร

คือ ผมน่าจะเป็นโปรแกรมเมอร์ที่ใจร้อนที่สุดคนนึงด้วยซ้ำ ผมอยาก Hack ทุกอย่างจากไอเดียที่มี ให้ออกมาเป็นรูปร่าง แล้วขึ้น Production เลยภายใน 5 นาทีด้วยซ้ำถ้าทำได้

และเวลาหลายๆ ครั้งที่เขียนโปรแกรม แก้โค้ดเก่าด้วยความใจร้อน ก็มักจะรู้สึกว่าทำไมมันช้าขนาดนี้ มันไม่ทันใจเลย

ทำไมเราไม่ทำเสร็จตั้งแต่ชั่วโมงที่แล้ว ทำไมเราไม่ทำเสร็จตั้งแต่เมื่อวาน ทำไมเรายังต้องมานั่งอ่านนั่งไล่โค้ดอะไรก็ไม่รู้มากมายอยู่เนี่ย

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

นั่นแหละคือ Software architecture in Nutshell

คำถามถัดมาคือ เอ๊ะ แล้วเราจะจัดให้มันดีขึ้นได้มั้ยนะ รอบหน้าจะได้ไปเร็วๆ

ผมเริ่มสนใจ Architecture เพราะการตั้งคำถามแบบนี้

ผมสนใจ Clean code เพราะการตั้งคำถามแบบนี้

ผมสนใจ Functional programming เพราะการตั้งคำถามแบบนี้

ผมสนใจ Test-driven development เพราะการตั้งคำถามแบบนี้

ผมเริ่มเขียนโปรแกรมหลายภาษา เพราะการตั้งคำถามแบบนี้

(Sidenote: ผมเคยได้ยิน Gary Bernhardt บอกเหมือนกันว่าเขาเป็นโปรแกรมเมอร์ที่ใจร้อนมากๆ เลยต้องเขียน Test และต้องเป็น Unit test ด้วย อันนี้เข้าใจและมีความรู้สึกเดียวกันอยู่)

ซึ่งมันเกิดขึ้นไม่ได้ ถ้าเมื่อเราโค้ดไม่ได้ โค้ดไม่ออก เราไม่ตั้งคำถาม แต่ใช้การต่อว่าความไร้ความสามารถของตนเองแทน

(นั่นเป็นสาเหตุนึงที่ Agile Retrospective ถึงเน้นการไม่ตัดสิน แต่เน้นว่าจะทำยังไงให้ดีขึ้นมากกว่าที่จะไปบอกว่าใครไร้ความสามารถ)

ดังนั้น คำแนะนำนึงที่ผมคิดว่าผมอาจจะบอกไม่เหมือนคนอื่น

โปรแกรมเมอร์จะพัฒนาตัวเอง ให้ตั้งคำถามกับ Status quo มากๆ อย่าโทษตัวเอง แต่ให้ตั้งคำถามกับทุกอย่างแทน

ปล. อนึ่ง การ “ต่อว่า” (Blaming) กับ “ตั้งคำถาม” (Questioning) ไม่เหมือนกันนะ ผมไม่เคยต่อว่า Programming language หรือ Design แต่ผมตั้งคำถามเสมอว่า “มันต้องลำบากขนาดนี้ด้วยเหรอ ถ้าทำแบบอื่นจะง่ายกว่านี้มั้ย แล้วมีข้อดีข้อเสียอะไร” ไม่ใช่ต่อว่าว่า “เออ ภาษามันห่วยเลยทำงานได้ไม่ดีไง จบนะ” มันต้องไปต่อถึงว่า ห่วยยังไง แล้วที่ดีกว่าจะเป็นแบบไหนด้วย มันถึงจะเรียกว่าตั้งคำถาม