Fanboi Channel

เราจะวิจารณ์หรือด่า Solution ได้ยังไงถ้าเรายังไม่เข้าใจเลยว่าเขาจะแก้ปัญหาอะไร
สมัยก่อนคนหลายคนวิจารณ์ Go ว่าห่วยเพราะไม่มี Generic โดยไม่เข้าใจว่า Go มันออกแบบมาเพื่อเน้นแก้ปัญหาอะไร คือเขาต้องการ System programming language ที่มี Dev productivity ที่ดีและ Learning curve ต่ำ เขาก็เลยไม่ได้ให้ความสำคัญกับเรื่องนั้นจนมันมาหลังๆ
สมัยนี้เห็นคนบ่นว่าเว็บ Complex กว่าทำ UI สมัยก่อน แต่ไม่ได้เข้าใจว่า Web app เดี๋ยวนี้มันมี Brand identity ที่ต้องใส่เข้าไปในแต่ละเว็บไซต์หรือแม้แต่เว็บแอพ ลองทำ ปุ่ม Label Textbox ที่แบบต้องได้สีได้ลุคแอนด์ฟีลที่ใช่ที่เข้ากับ Brand identity ในสมัยที่เรามี Winform ดิ เหนื่อยมากนะ
(นี่ผมยังไม่นับเรื่อง Interactivity นะ เว็บเดี๋ยวนี้กรอกฟอร์มเป็น Wizard แบบสมัยก่อนไม่ได้แล้วนะ)
บางคนอาจจะเถียงกลับว่า UI ที่ดีควรล้อเข้ากับ Native อะไรที่อยู่บนแมคก็ควรมี Look & Feel แบบแมค อะไรบนแอนดรอยด์ต้องเป็นตาม Guideline ของแอนดรอยด์ดิวะ ทำไมคนสมัยนี้ UX ทำตามใจแบรนด์ตัวเองหมดไม่เคารพแพลตฟอร์มเลย
อันนี้คือข้อแตกต่างระหว่างโจทย์ที่ว่า
"เราให้ความสำคัญกับปัญหานี้เยอะไปมั้ยทำไมเราต้องมาบ้าเรื่องทำ Custom UI ที่ตรงกับแบรนด์ Identity ขนาดนี้ มันใช่มั้ยเนี่ยที่จะเอาปัญหานี้มาเป็นจุดโฟกัสของงานแล้วสร้างเฟรมเวิร์คเยอะแยะไปหมด"
กับ
"ปํญหานี้ที่เราเลือกมาแล้วว่าจะแก้ เราจะสร้าง Custom UI ให้ได้แล้วเนี่ย เราได้สร้าง Solution ที่ดีสมเหตุสมผลมั้ย มัน Unnecessary bloat, ไร้ประสิทธิภาพและซับซ้อน complex เกินไปมั้ย"
เนี่ยเป็นข้อแตกต่างที่ชัดเจนมาก คำถามแรกคือ Design question ส่วนคำถามที่สองคือ Problem solving question สองโจทย์นี้เป็นโจทย์คนละระดับกันเลย มันเอามาปนกันแล้วจะงงไปหมด

มันเหมือนคุณวิจารณ์ว่าค้อนแม่งแย่เพราะเอามาใช้ตีลูกปิงปองแล้วมันตีไม่เป็นโดนเลยเงี้ย มันไม่ได้เว้ย เออ คุณไม่สนใจเรื่องตอกตะปูสนใจแต่เรื่องตีปิงปองก็ไม่ผิดอะไรนะ แต่วิจารณ์ค้อนในกรอบที่ราวกับว่าคนสร้างและใช้ค้อนเขาไม่ได้อยากตอกตะปูแต่อยากตีปิงปองเนี่ยมัน..... ผิดที่ผิดทางไปหมด
ในซอฟต์แวร์นี่เจอบ่อยมากที่คนใช้เลนส์แบบฉันอยากจะตีปิงปองเลยวิจารณ์ทุก Design decision ราวกับว่าทุกๆ System ออกแบบมาตีปิงปอง
"Go ไม่มี Generic ไม่มี Type system ที่ดี กาก" โปรแกรมเมอร์ที่คิดว่าโลกนี้ Type safety เท่านั้นคือปัญหาที่สำคัญ
"Ruby on Rails ช้า กาก" โปรแกรมเมอร์ที่คิดว่า Machine performance เท่านั้นคือปัญหาที่สำคัญ
(ซึ่งแปลกไอ้แนวคิดแบบที่ว่าปัญหาที่กูสนใจเท่านั้นคือปัญหาสำคัญของโลกนี้ที่ทุกระบบต้องออกแบบโดยใส่ใจสิ่งนี้เป็นที่สุดนะเว้ย เจอบ่อยในโปรแกรมเมอร์ต่างชาติมากกว่าไทยแฮะ ถ้าจะมีอะไรที่คิดว่าโปรแกรมเมอร์ไทยโดยเฉลี่ยทำได้ดีกว่าก็เรื่องนี้)
"Modern web development สมัยนี้มัน Bloat และซับซ้อนไปหมด" เนี่ยเจอคนที่วิจารณ์อย่างเข้าใจว่า Modern tooling มันมีไว้แก้ปัญหาอะไรน้อยมากๆ คือผมก็คิดว่า Modern tooling มันมีอะไรให้พัฒนาได้เยอะและก็มีข้อให้ติเยอะมากเลยนะ
แต่เจอแบบ "ทุกคนควรกลับมาทำ DOM Manipulation เพราะมันเร็วกว่าเปลืองทรัพยากรน้อยกว่าและไม่ซับซ้อน" อันนี้คือดูไม่เข้าใจไปเลยว่านี่มันค้อนตอกตะปู ไม่ใช่ไม้ปิงปองเว้ย

คือผมคิดว่าเราจำเป็นจะต้องเข้าใจว่า
1. Design กับ Problem solving มันเป็นโจทย์คนละแบบ การเลือกปัญหาที่ใช่ กับการแก้ปัญหาที่เลือกมาแล้ว มันคือโจทย์คนละอย่างกันเลย ถ้าไม่เข้าใจว่ามันคนละเรื่องก็จะมองหรืออ่าน Solution แบบผิดเพี้ยนไปหมด ยังไม่ต้องพูดถึงการวิจารณ์
2. การเลือกปัญหาให้มันทำผ่านการเข้าใจว่ามนุษย์เรามี Unmet need อะไรบ้างที่เป็นไปได้
3. ความสามารถในการเข้าใจ Empathize กับ Unmet need ที่ "ตัวฉัน" รู้สึกเฉยๆ เป็นทักษะสำคัญที่ต้องมีในการทำงาน Design Software, Solution and Architecture มากกกก มากกว่าที่หลายคนอาจจะตระหนักรู้ (อย่างเช่นหลายคนที่ทำงาน low-level ก็มีที่มองว่าไอ้พวกที่มันโอดร้องว่าอยากได้เครื่องมือที่ช่วยทำงานง่ายขึ้น ต้องการ Garbage collector มันก็แค่คนขี้เกียจไม่มีทักษะในการจัดการเมมโมรี่! เราต้องทำของที่ไวสิวะแล้วต้องเข้าใกล้ Machine level ให้มากที่สุดสิวะ! อันนี้ก็คือขาดสามารถในการ Empathize ไปเลย)
เลือกปัญหามาแก้ถูก บางทีทำงานไม่ตรงเป๊ะลูกค้ายังเซ็นผ่านเลย เลือกปัญหาผิดมาแก้ ตรงตามสโคปในสัญญาทุกตัวอักษรยังไฝว้กันได้เลย (ผมไม่ตัดสินละกันว่าอันนี้ดีหรือไม่ดี แต่เป็นเรื่องที่เกิดขึ้นจริง)
นั่นแหละที่สอน Humanistic architecture ก็คือตั้งใจจะ Address เรืองนี้ เป็นคอร์สที่ผมอยากสอนที่สุด คิดเอาเองว่ามีประโยชน์กับโปรแกรมเมอร์ที่พร้อมรับ อย่างน้อยผมก็พบว่าสำหรับตัวเองมันเป็นแกนกลางการทำงานของผมเลย
บางคนอ่านคอร์สและอ่านรีวิวอาจจะงงว่าเรื่องแบบจิตวิทยา การเข้าใจตัวเอง การเข้าใจคุณค่าและพื้นฐานของความต้องการมนุษย์ มันเกี่ยวข้องกับ Software architecture design ยังไง งาน Software Architecture มันน่าจะเรียนเรื่องแบบ Distributed system, database, horizontal scaling, idempotency, design pattern อะไรพวกนี้ไม่ใช่เหรอ
ผมคิดว่ามันเกี่ยวอย่างที่สุดแล้ว เกี่ยวแบบคือ Step 0 ในระดับรากฐานที่สุดเลย คุณเลือกปัญหาอะไรมาแก้ก่อนล่ะ ปัญหาระบบล่ม? ปัญหาต้นทุน? ปัญหาฟีเจอร์ออกช้า? หรือไม่เลือกอะไรเลยออกแบบไปเรื่อยเปื่อย? ถัดมา คุณ Trade อะไรทิ้งไป ลดความสำคัญของปัญหาอะไรลงไปบ้าง
นี่อ่ะคือแกนกลางของงานออกแบบ Architecture ชัดๆ
ทั้งทักษะการ Problem solving และทักษะการ Design มันสำคัญทั้งคู่ แต่ที่สำคัญเลย มันเป็นคนละทักษะกันครับ และถ้าไม่เข้าใจ คิดว่าโลกซอฟต์แวร์มีชุดปัญหาชุดเดียวเท่านั้นที่สำคัญ (เช่นระบบไม่ล่มบ้างล่ะ ความมี Resource efficient บ้าง ต้นทุนการรันอินฟรา ความปลอดภัยขั้นเทพบ้าง) คุณจะไม่สามารถเห็นคุณค่าของ Solution หรืองานออกแบบที่ออกแบบมาแก้ปัญหาที่คุณไม่ได้เลือกได้เลย
ในประเทศไทยผมยกและซูฮกให้พี่เดฟไปแล้วเรื่องการสอนทักษะ Problem solving ผมว่าผมสอนได้ทั้งไม่ดีและไม่ลึกเท่าแกหรอก ให้แกดีกว่า
(ถ้าพี่ผ่านมาอ่านแล้วอยากให้ Tag บอกได้ เผื่อให้คนตามไปดูพี่ออกคอร์ส)
ผมอยากเสริมจุดที่ผมว่านักพัฒนาหลายคนมองข้ามคือจุดของงาน Design เวลามีคนความต้องการขมุกขมัวที่อึดอัดไปหมดจนพร้อมจ่างเงินมากมาย เราจะออกแบบว่า Concrete problem ที่ช่วยเยียวยาความต้องการนั้นได้คืออะไรนะ
แล้วจากจุดนั้น จึงทำการ Problem solving ต่อไป
(นี่เริ่มมาจากฟังคลิปใหม่ของ Theo ที่นั่ง Defend web development จากพวก "ปรมาจารย์ด้าน Performance" ต่างๆ ที่นั่งด่าว่าทำเว็บสมัยนี้มัน Bloat มัน Complex ช้าไปหมดมีแต่เครื่องมือไร้สาระแก้ปัญหาไร้สาระ ก็แบบ...​.. ของขึ้นอ่ะนะ เข้าอกเข้าใจในโจทย์กันก่อนดีมั้ยคะ)
มันมีหลายภาษาและหลาย Solution design ที่ผมกล้าพูดว่ามันออกแบบมาโคตรดีและงดงามจัดๆ แต่ผมไม่ชอบ เพราะมันไม่ได้แก้ชุดของ Problem ที่ผมคิดว่า Matter ในประสบการณ์ส่วนตัว ผมก็สามารถซาบซึ้งในความสวยงามของมันได้ และเลือกใช้มันได้เวลาที่ต้องการอ่ะครับ

1000