Grit your teeth and ship it
บทความจาก Sean Goedecke การ "สร้างของให้ดี" กับการ "ship ของออกไป" อาจเป็นคนละทักษะกัน และอาจสวนทางกันด้วยซ้ำ
คนที่เก่งในการสร้างของมักมีรสนิยมที่ดี มองเห็นว่าของที่ตัวเองทำยังมีข้อบกพร่องตรงไหน โค้ดตรงไหนยังไม่สวย หรือยังมีวิธีที่ "ถูกต้องกว่า" อยู่ สิ่งเหล่านี้เป็นส่วนหนึ่งที่ทำให้คนนั้นเก่ง แต่ขณะเดียวกันก็อาจจะทำให้ ship ยาก เพราะยิ่งเห็นปัญหามาก ก็ยิ่งรู้สึกว่างานยังไม่พร้อม
เรื่องนี้ยิ่งชัดใน software engineering โดยเฉพาะเมื่อทำงานกับ codebase ใหญ่ ๆ ในบริษัทจริง ที่แทบไม่มีทางสวยหรือถูกต้องทุกจุด และยังเต็มไปด้วยข้อจำกัดจากเวลา + legacy code + การตัดสินใจในอดีต + requirement ที่ซับซ้อน งาน engineering เลยไม่ใช่การหา perfect solution แต่เป็นการหา best solution ภายใต้สภาพของ codebase นั้น ๆ
บางทีความ consistent กับระบบเดิมยังสำคัญกว่าการเขียนสิ่งใหม่ให้ "ถูกต้อง" ในถึงขั้นที่อาจจะต้องตั้งทำเขียน bug บางอย่างซ้ำ หากมันไม่ได้ร้ายแรงและทำให้ระบบสอดคล้องกัน
ซึ่งปัญหาคือโปรแกรมเมอร์เก่ง ๆ ที่มี taste สูงอาจติดอยู่ที่ว่าพอ feature ใหญ่ไม่มีทางทำให้สะอาดได้ทั้งหมด ก็ถอยไปทำสิ่งที่ควบคุมความถูกต้องได้ง่ายกว่า เช่น refactor test ปรับ dev environment หรือไล่จัดการรายละเอียดเล็ก ๆ แทน
Sean สรุปว่าบางทีการสร้าง bad diff ยังเอาไปแก้ต่อได้ แต่ no diff แก้อะไรไม่ได้เลย
เขายังเจอประสบการณ์คล้าย ๆ กันในการเขียนบทความ มีหลายครั้งที่เขาเขียน blog post เสร็จแล้วรู้สึกว่ามันยังไม่ดีพอ แต่ก็ publish อยู่ดี แล้วสิ่งที่น่าสนใจคือเมื่อย้อนกลับไปดูภายหลัง จริง ๆ เขาแทบจำไม่ได้ว่าบทความไหนตอนเขียนรู้สึกดีหรือไม่ดี และความรู้สึกตอนเขียนก็ไม่ได้สัมพันธ์มากนักกับว่าบทความไหนคนจะสนใจอ่าน
เราเองจึงคาดเดาได้ไม่ดีนักว่าสิ่งไหนจะมีประโยชน์หรือ resonate กับคนอื่น การผลิตงานแล้วปล่อยออกไปจึงอาจให้ข้อมูลมากกว่าการใช้เวลาจำนวนมากขัดงานเพียงชิ้นเดียวให้สมบูรณ์ เพราะ feedback จากโลกจริงเป็นสิ่งที่เราไม่สามารถจำลองได้ทั้งหมดในหัว
Sean เรียกแนวคิดนี้ว่าให้เป็น momentum-based มากกว่า outcome-based คือแทนที่จะผูกการลงมือทำกับคำถามว่า "งานชิ้นนี้จะสำเร็จไหม" หรือ "มันดีพอหรือยัง" ให้รักษาจังหวะของการทำและการ ship ต่อไป แล้วดูว่าอะไร work จริง
คหสต อีกประเด็นที่ชอบคือ เราไม่จำเป็นต้องหวงไอเดีย เพราะกลัวว่าจะใช้มันได้ไม่ดีพอในครั้งแรก ถ้าเรื่องหนึ่งสำคัญ เราสามารถเขียนหรือสร้างมันซ้ำได้หลายครั้ง แต่ละครั้งอาจเข้าใกล้สิ่งที่เราอยากสื่อมากขึ้น Sean เองก็เขียนเรื่อง shipping, tech companies และ emotional regulation ซ้ำมาแล้วหลายครั้ง
จุดที่รู้สึกอยากเพิ่มจากข้างบนคือ ในงานบางประเภท momentum อาจสำคัญกว่า correctness มาก เช่นในสถานการณ์ที่ความ correctness ไม่ได้ถูกนิยามตายตัว
ถ้าเป็น algorithm ที่มี spec ชัด ก็อาจตรวจได้ตรงไปตรงมาว่าถูกหรือผิด แต่ในงาน product, software design, writing หรือ research คำตอบที่เหมาะสมมักขึ้นกับข้อมูลที่เรายังขาด เช่น feedback จากคนอื่น ผล experiment ใหม่ ๆ หรือข้อจำกัดที่จะเจอระหว่างทาง
research project เป็นตัวอย่างที่อาจเห็นภาพได้ดี ช่วงต้นงานวิจัย เราอาจยังไม่รู้ด้วยซ้ำว่าคำถามที่ตั้งไว้น่าสนใจจริงมั้ย หรือ experiment ที่กำลังทำมันตอบคำถามสำคัญเปล่า
การเก็บงานไว้จนทุกอย่างดูสมบูรณ์ก่อนค่อยเอาไปคุยกับคนอื่น อาจทำให้เสียเวลา optimize direction ที่ไม่ดีตั้งแต่แรก ในทางกลับกัน การเอา result ที่ยังไม่สมบูรณ์ หรือ presentation ที่ยังไม่ได้สวยมาก ไป present ให้ advisor, lab mate หรือ collaborator ฟังเร็ว ๆ อาจทำให้ได้คำถามหรือมุมมองที่เปลี่ยน direction ของ project ก็ได้
บางครั้ง slide ที่ยังหยาบ แต่มี result หลักพอให้คนอื่นเข้าใจ อาจมีประโยชน์มากกว่า slide ที่สวยในอีกสองสัปดาห์ ถ้าสิ่งที่เราต้องการในช่วงนั้นไม่ใช่ perfect presentation แต่เป็น feedback ว่า "คำถามนี้น่าสนใจไหม", "experiment นี้สำคัญรึเปล่า", หรือ "มี direction อื่นอีกมั้ย" การใช้เวลาเพิ่มเพื่อทำ solution ปัจจุบันให้ "ถูกต้องที่สุด" อาจไม่ได้มีค่ามากเท่ากับการเอาของที่ดีพอออกไปให้เกิด momentum รับข้อมูลใหม่ แล้วค่อยปรับรอบถัดไป
แต่ correctness สำคัญอยู่แล้ว โดยเฉพาะตอนที่จะสรุปผลหรือ publish งาน research หลักฐาน วิธีทดลอง และ claim ต้องเข้มงวด แต่ในช่วง exploration การพยายามทำทุกอย่างให้สมบูรณ์ก่อนขอ feedback อาจขัดกับธรรมชาติของงานวิจัยเอง เพราะหนึ่งในหน้าที่ของ feedback คือช่วยเราค้นหาว่าอะไรคือสิ่งที่ควรทำให้ถูกตั้งแต่แรก
บางครั้งการแยกให้ออกว่า ณ ตอนนี้เราต้องการ correctness หรือ information เพิ่ม ก็อาจจะเป็นทักษะที่ควรฝึกฝนอยู่เรื่อย ๆ ก็ได้
พอกลับมานั่ง edit บทความอีกรอบ การที่เน้น momentum อาจจะไม่สามารถสร้างผลงานแบบ masterpiece ที่นึกภาพเป็นหนังของ Christopher Nolan ออกมาก็ได้มั้ง หรือจริง ๆ แล้ว Nolan อาจจะไม่ได้ชอบหนังทุกเรื่องที่เขากำกับก็ได้ (?) เดามั่ว ไม่ได้ไปนั่งค้นประวัติ / บทสัมภาษณ์จริงจัง
https://www.seangoedecke.com/grit-your-teeth-and-ship-it/