เรื่องนี้เป็นเรื่องที่ติดค้างในความคิดมาหลายปีเหมือนกัน
หลายปีแล้วที่ผมสงสัยว่าทำยังไงให้คนเข้าใจ Fundamental ของการทำซอฟต์แวร์ ได้นะ ซึ่งก็นำไปสู่คำถามว่า Fundamental คืออะไรกันแน่ ซึ่งที่ผ่านมาผมก็ยังนิยามไม่ออก
ในแง่นึงก็จะมีคนบอกว่าต้องเรียนรู้ระดับฮาร์ดแวร์ ระดับลึก นั่นอ่ะพื้นฐาน แต่กลับกันก็มีบอกว่าต้องเป็นพวก Math ถึงเป็นพื้นฐาน
ซึ่งส่วนตัวถ้าเอาความรู้สึกตัวเองวัด ผมเคยเจอคนที่แบบว่าเข้าใจฮาร์ดแวร์ลึกซึ้งแต่ผมรู้สึกว่า “พื้นฐาน” เขาไม่แน่น หรือรู้จักพวก Math แต่ก็พื้นฐานไม่แน่นด้วย
เรื่องนี้กลับมาย้อนอีกครั้งคือในเวลาที่ผ่านมานี้ มีโปรเจ๊กต์ที่เราจำเป็นต้องเข้าไปทำความเข้าใจระบบของลูกค้า แล้วก็มีน้องคนนึงถามผมว่า ทำไมผมอ่านอะไรแล้วปะติดปะต่อรวบรวมข้อมูลสร้างความเข้าใจได้เร็วจัง
ผมไม่รู้จะตอบอะไรนอกจาก “พื้นฐานมั้ง”
วันที่ผ่านมาผมได้มีคนสอนเรื่องพื้นฐานของสิ่งที่เรียกว่า Undertanding ผมถึงได้เริ่มมองเห็นละว่า อ้อ การทำความเข้าใจมันคืออะไรกันแน่
และมันมาปลดล็อกว่า เวลาที่ผมรู้สึกว่าคนพื้นฐานดีอ่ะ คือคนที่มันเข้าใจเรื่องที่มันทำอยู่ ดังนั้นต่อให้เป็น Mario Maker Programming ผมก็จะรู้สึกว่ามันพื้นฐานดีนะ
และมันปลดให้ผมเข้าใจบางอย่างว่าทำไมผมเรียนรู้ระบบใหม่ได้เร็วกว่าคนอื่น
โอเค งั้นเรามาดูกันเลยดีกว่าว่า วิธีการเรียนรู้ให้เข้าใจมีอะไรบ้าง
ก่อนอื่นเพื่อให้แยกแยะได้ ผมขอนิยามก่อนว่า การเรียนรู้ที่ผมเห็นอาจจะแบ่งเป็นสองอย่างใหญ่ๆ
การเรียนรู้แบบที่จำได้ ทำได้ แต่ไม่เข้าใจ การเรียนรู้แบบที่เกิดความเข้าใจ ซึ่งเดี๋ยวเราจะมาดูว่าจะทำให้เกิดแบบที่สองได้ยังไง
Manipulating Information
กฎข้อแรกในการเรียนรู้ให้เข้าใจคือ ทำการเล่นกับข้อมูลที่เราได้เสมอ
ถ้าสมมติมีคนสอนเราว่า หมูทอดกะเทียมต้องใส่ซีอิ๊วขาวสองช้อน เราจะสามารถทำหมูทอดกะเทียมได้ ซึ่งอันนี้เป็นการเรียนรู้แบบที่ 1
แต่หากเราอยากจะเข้าใจหมูทอดกะเทียมอย่างลึกซึ้ง เราจะต้อง
ลองใส่ซีอิ๊วสามช้อน ลองใช้เกลือแทนซีอิ๊ว ลองใช้น้ำปลาแทนซีอิ๊ว ลองใช้หมูหลายๆ ส่วนที่แตกต่างกัน และอื่นๆ อีก และนั่นแหละเราถึงจะเริ่มสร้าง “ความเข้าใจ” ที่แท้จริงกับเมนูที่ชื่อว่าหมูทอดกะเทียมได้
เชฟที่ทำหมูกะเทียมเก่งมากๆ ไม่ใช่เชฟที่จำสูตรที่ตัวเองคิดค้นได้แม่นยำทุกตัวอักษรใช่มั้ยครับ แต่เป็นเชฟที่เข้าใจทุกส่วนประกอบในสูตรอย่างลึกซึ้งว่าถ้าเปลี่ยนอะไรจะได้อะไรบ้าง
นั่นแหละคือความเข้าใจที่มากกว่าแค่การทำได้
และนั่นแหละที่ผมมองว่าเป็น “พื้นฐาน”
การมีพื้นฐานความเข้าใจ ทำให้เชฟคนนี้สามารถทำหมูกะเทียมที่อร่อยพอตัวได้ แม้แต่เวลาอยู่ในประเทศที่ไม่มีซีอิ๊วให้ใช้
เช่นกันครับ เวลาที่เรามีพื้นฐานความเข้าใจในหลักการของ Programming จะทำให้เราสามารถเขียนโปรแกรมได้ดีประมาณนึง แม้เวลาที่สถานการณ์รอบข้าง Requirement ต่างๆ หรือโครงสร้างองค์กรอาจจะไม่เอื้อให้ทำเต็มที่แบบนั้น
ในทางจิตวิทยา มันจะมีโจทย์ข้อนึงที่เกิดขึ้นในโรงพยาบาล
สมมติคนไข้มีอาการป่วย ที่ต้องให้ทางเลือกในการรักษา 2–3 อย่าง แต่คนไข้ก็ดูจะสติไม่สมบูรณ์ด้วย ก็เป็นโจทย์ที่น่าสงสัยว่า ตกลงคนไข้พร้อมจะเลือกวิธีการรักษาด้วยตัวเองหรือเปล่า แล้วตกลงเขาเข้าใจทางเลือกที่หมอมอบให้ก่อนจะเลือกมั้ย
โจทย์แบบนี้เขาจะให้นักจิตวิทยามาประเมินความสามารถในการทำความเข้าใจทางเลือกของคนไข้ ไม่ใช่เลือกไปแล้วงงทีหลัง (ตรงนี้ไม่แน่ใจว่ามีในไทยมั้ยนะครับ)
ซึ่งเงื่อนไขนึงที่ใช้คือเรื่องนี้เลยครับ คนไข้สามารถ Manipulate information ที่หมอมอบให้ได้มั้ย สามารถอธิบายสิ่งที่หมอบอกออกไป เป็นภาษาของตัวเองได้มั้ย สามารถมองออกมั้ยว่าแต่ละทางเลือกถ้าเปลี่ยน Factor บางอย่างนิดหน่อยเกิดอะไรขึ้น
อันนี้เป็นตัวนึงเลยที่ใช้วัดความเข้าใจของคนครับ
และถ้ากลับมาในวงการซอฟต์แวร์ เวลาที่ผมอธิบายเรื่อง Software Architecture หรือเรื่องอื่นๆ แล้วดูเข้าใจ เพราะผมเล่นกับมันมาเยอะมาก
ทันทีที่คนสอนเรื่องอะไรซักอย่าง เช่น หลักการ DRY
ผมจะลองใช้มันเต็มๆ ใช้มันครึ่งๆ กลางๆ ไม่ใช้มันเลย
และนั่นทำให้เกิดความเข้าใจ
หรืออย่างตอนที่ไปลองเรียนโปรเจ๊กต์ลูกค้าเหมือนกัน
ทันทีที่อ่าน Document แล้วบอกว่า “ระบบนี้คิดราคาสิ้นค้าจากตารางนี้” สิ่งที่ผมมักจะทำคือ หาวิธีการรันใน Local ให้ได้ก่อน
ไปหาโค้ดที่เกี่ยวข้องกับตรงนี้ให้เจอ ลองเปลี่ยนค่าในตารางเล่นดู ลองหาจุดที่มันไปดึงข้อมูลจากตาราง แล้วเปลี่ยนให้ดึงจากตรงอื่น ใส่ค่าตายตัวแทนไปเลย (อาจจะไม่ได้ทำทั้งหมดกับทุกๆ เรื่อง แต่จะลองเล่นกับข้อมูลบางอย่างเสมอ)
ซึ่งตรงนี้มันจะขัดกับความรู้สึกทั่วไปประมาณนึง เพราะหลายๆ คนจะมองว่า เรียนแบบนี้มันช้า อ่านแล้วยังมาเล่นอะไรไม่รู้เสียเวลา ยังมีอีกหลายอย่างต้องเรียน อ่านเสร็จจำๆ ไว้แล้วก็ไปอ่านอันถัดไปเลยไม่ Efficient กว่าเหรอ
แต่แปลกมั้ย ผมกลับเรียนรู้ระบบใหม่ได้เร็วจนหลายๆ คนที่เคยทำงานด้วยทึ่ง
เพราะพอมันเกิดความ “เข้าใจ” แล้ว มันจะไม่ต้องจำอะไรมากแล้วครับ
ถามว่าเรื่องพวกนี้ไปประยุกต์ยังไงได้บ้าง
- ถ้าคุณเรียน Distributed System คุณเรียน CAP Theory ที่มันสรุปว่าคุณไม่สามารถดีไซน์ระบบที่มี Consistency, Availability พร้อมกัน คุณควรจะลองเล่นกับข้อมูลว่า พยายามดีไซน์ระบบที่ได้ทั้ง Availability พร้อม Consistency ดูสิ แล้วจะตายตรงไหน
- ถ้าเรียนเรื่อง API Design Best Practice คุณควรจะลองเล่นกับข้อมูลโดยการดีไซน์อะไรที่แหก Best practice ดูสิ แล้วดูว่ามันจะสร้างปัญหาตรงไหน
- ถ้าเรียนเรื่องเทคโนโลยีใหม่ๆ อย่าง Go มี Goroutine ที่เขาว่าเทพลองถามตัวเองว่าถ้าดีไซน์แบบอื่นมันจะมีข้อดีข้อเสียต่างกันยังไง
- เวลาที่ผู้บริหารขั้นเทพเป็นที่นับหน้าถือตาเป็นที่ยอมรับกันในระดับโลกโน่นนี่นั่น ออกมาสอนว่าชีวิตต้องทำแบบนั้นแบบนี้ บริหารองค์กรให้ดีต้องทำแบบนั้นแบบนี้ ถ้าอยากทำความเข้าใจ ลองเล่นกับข้อมูลตรงนั้นดูครับ
- ถ้าอยากให้แค่ทำเป็น ทำงานได้ เราไม่ต้องลองเล่นครับ ก็แค่จำวิธีการไป
แต่ถ้าอยากให้เกิดความเข้าใจ หลักการข้อแรก คือ ทำการลองเล่นกับข้อมูลที่ได้มาเสมอครับ
แล้วเชื่อผมว่า “ความเข้าใจ” จะทำให้เราจำได้โดยไม่หนักสมองมากครับ
และนี่ทำให้ผมเห็นละว่าการสอนแบบนึงที่สอนให้จำแล้วทำตามให้ถูก ไม่เคยเวิร์คเลย
Judging vs Understanding
ตรงนี้มี Caveat นิดนึงอีกหล่มที่เจอบ่อย
“ทำไมพี่ทำอะไรซับซ้อนจัง ทำแบบ A ดิง่ายกว่า”
ประโยคแบบนี้จะได้ยินเสมอ
แต่ถ้าคุณไม่ไปจนสุดทางพอว่าทำแบบ A ง่ายกว่าที่ว่า มีข้อดีข้อเสียต่างกันยังไง
อันนี้ยังไม่ถือว่าคุณได้เล่นกับข้อมูลนะครับ ไม่ใช่ว่าคุณเกิดความเข้าใจนะครับ
คุณ “ชิงตัดสิน” ไปแล้วว่า A ง่ายกว่าต่างหาก ยังไม่ได้เล่นอะไรเลย
แต่ถ้าคุณเล่นกับ A ง่ายกว่า ไปจนสุดแล้ว อันนั้นอ่ะครับถึงจะเรียกว่าเกิดความเข้าใจ
อันนี้เป็นหลักการข้อแรกที่ทำให้เราสามารถเรียนรู้สิ่งต่างๆ อย่างเข้าใจได้
ว่างๆ มาเขียนภาคสองต่อ
เดี๋ยวผมจะบอกอีกทีว่าทำไมคนขี้ลืมในชีวิตประจำวัน เวลาทำงานกับ System ต่างๆ ดันเหมือนรู้ไปหมดทุกอย่าง ในภาคสอง
“ความเข้าใจไม่ได้เกิดจากการรับข้อมูลภายนอก แต่เป็นการสร้างโลกภายใน”