Fanboi Channel

12 + __ = 20

ผู้ใหญ่มองเห็น "สมการ" และมองว่านี่คือการแก้สมการ ....

สิ่งที่ผมเห็นคือ คำถามง่ายๆ และใกล้ตัวเด็ก ....

"มีของเล่น 12 ชิ้น ซื้ออีกอีกกี่ชิ้นถึงได้ 20"
"เดินมา 12 ก้าว เดินอีกกี่ก้าวถึงได้ 20"

และเท่าที่ดูวิธีการหาคำตอบ ตามที่เขียนในหนังสือคือ "ให้นับ" (ดูภาพประกอบได้)

ซึ่ง "การ reason ด้วยการนับ" ถือเป็นการคิดและให้เหตุผลตามวัยที่เหมาะสม กับเด็ก ป. 1 นะ ถ้าถามผม ....

แต่เราจะให้เขาให้เหตุผลกับเรื่องอะไรด้วยการนับ นี่อีกเรื่อง

ถ้าเราคิดจะแก้สมการ เราจะได้สมการ ... แล้วเราก็จะคิดแบบ "คนรู้จักสมการแล้ว" คือ เจอบวก ก็เอาไปลบอีกข้างหนึ่ง ....

แทนที่จะเป็น "เรื่องของการให้เหตุผลด้วยการนับ" .... มันก็กลายเป็น "โจทย์ arithmetic" ไป

ผมบอกเลยว่านี่จะเป็น unpopular opinion ถ้าผมบอกว่า "ถ้ามองเรื่องของระดับการคิดและให้เหตุผลด้วยการนับ สิ่งที่นับได้" ผมคิดว่าสมเหตุผล .... (โดยเฉพาะถ้านับได้ด้วยนิ้วมือสองข้าง ไม่มากกว่านั้น)

"สมการ" เป็น abstract ของเรื่องนี้ ที่มาทีหลัง เราอย่าเพิ่งไปทำให้มันเป็นเรื่องของการแก้สมการ ก็ได้ไหมนะ

ตอนเอด้าอยู่อนุบาล ผมก็ถามพวกนี้เล่นบ่อยๆ นะ ให้เขาหัดให้เหตุกับการนับ สิ่งที่เขานับได้

เล่น Minecraft กับพ่อนี่ประจำเลย .... จากตรงนั้นถึงตรงนี้ ต้องใช้ block กี่ก้อนนะ .... ก็นับมาทีละก้อนสิ แค่นั้นแหละ

เดินออกจากบ้านกันไป 10 ก้าว ถามว่าถ้าจะเดินกลับบ้านต้องเดินกี่ก้าวนะ ... หรือพ่อเดินไปอีกหน่อย ... ถ้าเอด้าจะมายืนตรงพ่อต้องเดินกี่ก้าวนะ ...

ฯลฯ

ส่วนโรงเรียนจะสอนยังไงก็อีกเรื่องแหละ ..... ซึ่งผมเห็นว่าถ้าโรงเรียนมีครูที่ไม่เข้าใจ มองว่านี่คือ "สมการ" แล้วสอนเด็กแบบ "แก้สมการ" (อย่างที่ผู้ใหญ่หลายคนก็มองน่ะแหละ) มันก็เกินไป

แต่นั่นคือเรื่องการสอน ของคนที่ไม่เข้าใจ "การให้เหตุผลตามวัย" ซึ่งวัยนั้น การให้เหตุผลคือ "นับทีละหนึ่ง" ก็ถูกแล้ว

ผมขอแปะรูปไว้หน่อยละกัน ว่าเขาก็สอน "นับทีละหนึ่ง" นะ ไม่ได้สอนอะไรยากกว่านั้นหรอก .....

ปัญหาเดียวของเรื่องนี้ที่ผมคิดออกและมองเห็น คือ การที่ทำให้มันกลายเป็น "สิ่งที่หน้าตาเป็นการคำนวน" และ "ตัวเลข" มากกว่า "การให้ reasoning กับชีวิตประจำวันด้วยการนับ"

นั่นคือ "เน้นการใช้ abstraction ด้วยตัวเลข และเครื่องหมายสัญลักษณ์ +, - อะไรพวกนี้มากเกินไป และอาจจะเร็วเกินไป" .... จนมันมองเห็นแต่เรื่องพวกนี้ .... มากกว่า "การให้เหตุผลด้วยการนับ"

ผู้ใหญ่เห็นแล้วก็กลายเป็นเรื่องคำนวน กลายเป็น arithmetic กลายเป็นสมการ กลายเป็นอะไรไปหมด ..... ครูก็อาจจะสอนแบบนั้นไปด้วย .... แน่นอน ถ้าครู (ซึ่งก็คือผู้ใหญ่คนหนึ่งน่ะแหละ) ไม่เข้าใจเรื่องพวกนี้ ...​เรียนคณิตศาสตร์เน้นคำนวน เน้นหาคำตอบมา ก็อาจจะพาไปพังได้ง่ายๆ แหละครับ

คณิตศาสตร์ คือ การให้เหตุผลครับ และการให้เหตุผลพื้นฐานที่สุด ก็คือ การให้เหตุผลด้วยการนับ ครับ

>>272 ชอบคำแนะนำหลายๆอย่าง กับที่เค้าออกมาแฉพวก HR, CEO ที่เอาเปรียบพนักงานนะ
แต่อย่างอันนี้ https://www.youtube.com/watch?v=6ufwxkurKKg กูว่ามันอันตรายเกิน
คนโดนไล่อออกเพราะทำแล้วโดนจับได้ทีหลังมันก็มีตัวอย่างเยอะแยะ

เช้านี้ตื่นขึ้นมาเห็นคนแชร์โพสตำแหน่งใหม่ที่เรียกว่า prompt engineer กันเยอะ เป็นตำแหน่งที่งานหลักคือ คุยและสั่งงานให้ AI เช่น chatgpt ทำงานได้ตามที่ต้องการ
ผมเดาว่า กระทรวง อว บ้านเราคงจะตื่นเต้นสั่งการให้มหาวิทยาลัยไทยเปิดหลักสูตร prompt engineers ในอีกไม่ช้า หลังจากที่สั่งให้เปิด cybersecurity ก่อนหน้านั้น และก่อนหน้า cybersecurity ก็สั่งให้เปิดหลักสูตร AI เป็นที่เรียบร้อย
การเปิดหลักสูตรตามความต้องการของตลาดเป็นวิธีที่ไม่ยั่งยืนครับ
วิธีที่ยั่งยืนคือ สอนพื้นฐาน fundamental ทั้งหลายให้แน่น เช่น คณิตศาสตร์ ฟิสิกส์ อัลกอริทึม วิชาที่สอนกระบวนการคิดหาเหตุผลทั้งหลาย และภาษาอังกฤษ เพื่อที่ผู้เรียนจะได้มีความสามารถในการเรียนรู้ได้เอง ไม่ว่าจะมีอาชีพใหม่อะไรเกิดขึ้นมาอีกในอนาคต
ไม่เช่นนั้น กระทรวง อว บ้านเราก็จะต้องไล่เปิดหลักสูตรใหม่ ๆ ตามตลาดอยู่รำ่ไปครับ
#reinventing #university

เห็นเพื่อนโพสต์เรื่อง SolidJS ผมแนะนำเลยนะว่าใครทำ Frontend น่าจะศึกษา SolidJS นะ

ต่อให้ไม่ได้ใช้งานลองศึกษาวิธีออกแบบ API ออกแบบ Library และกลไกของมันดู ผมคิดว่ามันคือ React ที่ API Surface ดีและสวยกว่ามากๆ

ถ้าลองเปรียบเทียบวิธีการออกแบบของมันกับ React ดูว่ามันทำงานยังไงถึงออกแบบมาได้แบบนั้น แล้วทำความเข้าใจ ผมว่ามันช่วยให้คุณเป็นโปรแกรมเมอร์ที่ออกแบบโค้ดได้เก่งขึ้นแน่ๆ

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

การตัดสินใจเล็กๆ ตรงนี้ทั้งขยายศักยภาพของตัว SolidJS แล้วยังเป็นการสื่อสารชัดเจนเลยว่าสิ่งนี้มีความลับ อะไรที่เป็นตัวแปรมัน Imply ว่าเป็นค่าที่เสร็จแล้ว อะไรที่เป็นฟังก์ชั่นมัน Imply ว่ามันการทำอะไรบางอย่างภายใน ผมล่ะชอบ Consistency และ Semantic ของ API Surface ตรงนี้จริงๆ

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

ตามข่าวบอกว่ามหาวิทยาลัยบางแห่งไม่กล้าที่จะลงโทษอาจารย์ที่ซื้อขายงานวิจัย เพราะเกรงว่าถ้าให้อาจารย์พวกนี้ออกไป คะแนน impact factors และ citations จากคนเหล่านี้จะหายไป และจะไปทำให้อันดับมหาวิทยาลัยโลกของตนตกลง
ถามว่า ทำไมต้องแคร์ครับ การจัดอันดับพวกนี้ ให้จุฬาลงกรณ์มหาวิทยาลัยดีกว่า University of Virginia ให้ University of Tehran ดีกว่า University of Cambridge คนที่มีปัญญาเขาก็ไม่เชื่อถืออยู่แล้ว
แล้วพวกวารสาร Q1 ที่อาจารย์พวกนี้ไปซื้อขายมา ใครส่งไปตีพิมพ์ครับ เห็นผู้แต่งมาจากประเทศโลกที่สามทั้งสิ้น
ทำไมมหาวิทยาลัยไทยต้องให้ความสำคัญกับการจัดอันดับมหาวิทยาลัยโลกครับ ยังไม่เห็นอีกเหรอครับว่ามันเป็นต้นเหตุของปัญหาทั้งหมด เน้นคุณภาพจริง ๆ ไปได้ไกลจริง ๆ นะครับ แม้ว่าจะใช้เวลานานหน่อย
#ติดกระดุมเม็ดแรกผิด

อ่านเจอ 11 factors วิกฤตในการพัฒนา ERP ให้สำเร็จ เคยเป็นผู้บริหารและคอนซัลให้หลายองค์กร เวลาเลือก Software Package สำเร็จรูปเข้ามา เตือนทุกที่ว่า อย่า Customize เยอะ สำหรับ Sofware Package ที่ไม่ได้ออกแบบมาให้ Customize หรือ Manday โหดมากๆอะนะ เพราะ Customize ได้ก็ใช่ว่าจะคุ้มค่ากะราคาที่ต้องจ่ายไป
*
ถ้าจะเชื่อมต่อกัน ผมเสนอ ให้มีที่พัก data ตรงกลาง ใช้ Message Queue หรือ Event Driven Architecture ต่างฝ่ายต่างอ่านตรงกลาง มี trigger ให้แต่ละระบบเมื่อ data changed แล้วบอกอีกระบบให้ไปทำอะไรต่อ เวลาแก้โครงสร้างอะไร จะได้เห็นตั้งแต่ตรงกลาง ไม่กระทบ performance อีกฝั่ง หรือถ้ายุคนี้ก็ใช้ grpc หรือ protocol อะไรที่มี contract เปลียนโครงสร้างแล้วเห็นผลกระทบก่อน อย่าไปใช้ REST ต่อกันตรงๆถ้าต้องการ Realtime ไม่ได้บอกว่าวิธีการนี้ดีที่สุด อาจจะมีวิธีดีกว่า แต่ที่ทำมาก็ Success ดี
*
หลายที่ก็ไม่เชื่อ มีทั้งไม่เข้าใจเทคนิค และเรื่องดันให้รีบใช้รีบขาย Sofware Package นั้นให้ได้ หลายองค์กรจากมาหลายปีแล้วคนทำงานก็บ่นไม่ได้ใช้งานแต่ต้องจ่ายตังค์มหาศาล หรือประสิทธิภาพซอฟท์แวร์ระดับโลกไม่เห็นสมชื่อ คนต้องมา manual อดหลับนอนกลับบ้านดึก ก็เพราะเราไปเปลี่ยนมาตรฐานที่เขาทำมาไม่ได้คิดมาเพื่อเรานะแหละ ผลกระทบมันเลยเยอะ
*
ยิ่งซอฟท์แวร์ต่างประเทศเขารีบขาย License แล้วรีบกลับต่างประเทศทั้งนั้น ไม่เสียเวลาลง Details เพราะ Manday เขาแพง เราก็จ่ายเขาไม่ได้อีก เจอค่า license ไปก็ไม่เหลือค่า Customize Maintenance อะไรแล้ว ถ้าให้ไปคอนซัลที่ไหนก็แนะนำทางนี้เท่านั้นอย่า Customize ให้แลกเปลี่ยนดาต้ากันนอกระบบอย่าต่อกันตรงๆถ้าไม่มีทีมพร้อมCustomize ระบบที่เกี่ยวข้องอะนะ เห็นพังกันมาเยอะละ ส่วนใหญาเห็นหลายที่ทำใหม่เสร็จก่อนไป Customize ออกนอกมาตรฐาน Software Package นะ
*
บทความนี้เก่ากว่า 17 ปี ละ ก็คงจะได้ยินปัญหาเหล่านี้น้อยลง หรือประวัติศาสตร์จะซ้ำรอย สำหรับองค์กรที่กำลังมองหาซอฟท์แวร์แพ็คเกจใหม่ๆ ก็ขอให้ใช้งานมันได้อย่างเต็มประสิทธิภาพคุ้มค่าราคาที่จ่ายไปนะครับ

เอามาแป่ะไว้ให้คิด พอดีวันนี้ Doppio Academy Software Testing course สอนมาถึงการ Investigate Bug/Issue เลยอยากเอามาฝากในกลุ่มไว้หน่อยว่า อันนี้แอบเป็น skill ที่แยกระหว่าง QA ทั่วไปที่ Test แล้วก็ raise bug ในทุกสิ่งที่เจอ กับ QA ที่เป็น A player อยู่เหมือนกันนะ ยกตัวอย่างให้พอเห็นภาพ
QA 1: พี่ๆ ผม test แล้วเจอรูปบางส่วนมันโชว์ error บนหน้า app ผม log bug ไว้ให้แล้วนะ
QA "A" player: พี่ๆ ผม test แล้วเจอรูปบางส่วนมันโชว์ error บนหน้า app ผมลองไปยิง Image API หลังบ้านเช็คแล้ว ได้ error เหมือนกัน แปลว่าตัว App ไม่มีอะไรผิดพลาด น่าจะโอเค ทีนี้ผมเลยไป Query Database ดูต่อ ปรากฎว่าใน Database มีข้อมูลปกติ ผมเช็คต่ออีกนิดเลยเจอว่า Image API จะ return error ให้ App เฉพาะกับ image ที่มีตัวเลขใน image file name ผมเลยไป Log bug เป็น High severity ไว้ให้ทีม Image API แล้วนะครับ ผม log bug เป็น minor/low severity ไว้ให้ทีม Mobile App ด้วยเพราะว่า ตัว App น่าจะทำ Error Handling กับ image error จาก image api ได้ดีกว่านี้ไม่ใช่ โชว์ error message ให้ user เห็น แต่ bug ตัวนี้ของ App ไม่ได้ block release ของ app เราครับ
** ให้พอเห็นภาพตัวอย่างว่า QA "A" Player จะทำอะไรต่างจาก QA ทั่วๆไปจริงๆ **
** ของ QA 1 เนี่ย หลายๆครั้งจะเจอว่า Dev ของ App บ่นใส่อีก log bug มาให้ชั้นทำไม ไม่เกี่ยวกับของชั้นซักหน่อย **
ถ้ามีเวลา ไปลองศึกษาวิธีทำ Bug/Issue investigation กันด้วยน้าาาาาา

Chakrit Riddhagni
2 h
·
ใน Medium ได้ Recommend Article นึงมา คนเขียนเปิดมาว่าสัมภาษณ์คนทำงานที่เคยทำเกี่ยวกับ Payment Integration แล้วคนสัมภาษณ์ตอบว่าแก้ปัญหาเรื่องสถานะของ Payment ด้วยการ Sync ข้อมูล
คนเขียนรับไม่ได้บอกประมาณว่าต้องใช้ต้องรู้จัก Distributed transaction pattern สิ แล้วก็เขียนเรื่อง 2-phase commit, Saga, etc. แล้วก็วางตัวหล่อไปที
ผมนี่อ่านแล้ว Cringe มาก
คือจะบอกว่าบางทีคุณต้องทำความเข้าใจ Domain ก่อน งานการเงินมัน Rollback ไม่ได้เว้ย จะมาบอกว่าทำ Distributed transaction, Two-phase commit ทำ Saga Pattern เพื่อ Rollback ถ้าทุกอย่างไม่สำเร็จ มันไม่ใช่กับโดเมนการเงิน
ผมยกตัวอย่างง่ายๆ เลย ถ้าคุณออก Invoice ไปแล้ว แล้วจ่ายเงินไม่สำเร็จ จะมา Rollback Invoice ไม่ได้ คุณต้องออก Transaction ทับว่าใบแจ้งหนี้นี้ถูกปิดแล้วยืนยันโดยนาย X ไม่ใช่ไป Rollback Invoice ให้เหมือนไม่มีอะไรเกิดขึ้นแบบที่ทำในระดับฐานข้อมูล
หรือถ้าจ่ายเงินเสร็จแล้วออกใบเสร็จรับเงินไม่ได้ คุณจะไปบอกเห้ยไม่สำเร็จ Rollback แม่งหมดคืนเงินไปซะ ลบใบแจ้งหนี้ทิ้งซะ ก็ไม่ได้เฟ้ย มันจ่ายเงินไปแล้ว คุณยกเลิกก็เสียค่าปรับอ่ะ เอาค่าปรับไปลงตรงไหนในบัญชีล่ะ
แล้วตอนจบจะเดินไปบอก Audit ว่าในระบบไม่เคยมีการรับเงินเลย (จริงๆ rollback ไปหมดแล้วตาม Design Pattern บอกมาให้ทำ) ไม่มีใบเสร็จไม่มีใบแจ้งหนี้อะไรทั้งนั้นแหละ ทั้งๆ ที่ธนาคารมีหลักฐานว่าเคยโอนเงินมาและคุณเคยแคนเซิลไป อันนี้ได้เป็นเรื่องใหญ่เรื่องโตนะ
จะบอกว่าคนเราบางทีรู้จัก Design Pattern มากไปจนประมาทและ Oversimplify domain requirement ไปจัดมันเข้ารูปของ Design Pattern ไปหมดทั้งๆ ที่มันจัดเข้ารูปนั้นไม่ได้ อันนี้นี่น่าเป็นห่วงมากเลย
(แต่กรณีของไอ้คนเขียนคนนี้ ผม Cringe นะ ไม่ใช่ผมห่วง เพราะคนเขียนดันวางตัวหล่อว่าแบบเห้ยการ Sync นี่มันไม่โอเลยนะ ต้องรู้จัก Pattern เทพๆ บ้างนะถ้าจะเป็น Software Engineer ที่ดี หืมมมมม)

ความเสื่อมขององค์กร

ปัญหา classic ของผู้บริหารระดับสูงมาหลายพันปีคือเราควรจะแต่งตั้งคนที่ไว้ใจได้โอกาสทรยศเราน้อย หรือคนเก่งที่มีโอกาสทรยศเรามากกว่า
.
จุดเริ่มต้นของความเสื่อมขององค์กรทางหนึ่งคือเมื่อองค์กรเริ่มแต่งตั้ง คนสนิท ญาติพี่น้อง ลูกหลาน เด็กฝาก เข้ามาทำงาน ไม่ว่าจะในประวัติศาสตร์หลายพันปี หรือในปัจจุบันเราดูข่าวก็จะเห็นความชิบหายจากเคสแบบนี้อยู่เรื่อยๆ
.
มันมีปัญหายังไง เราก็อยากได้คนที่ไว้ใจได้มาทำงาน?

1. ความสามารถไม่ถึงแต่ได้มาทำเพราะมีเส้นสาย
2. mentality ผิดๆ ข้อนี้สำคัญกว่าข้อแรกและแก้ยาก คือคิดว่านี้เป็นบริษัทของพ่อแม่ สามีภรรยา อะไรก็ว่าไป จะทำงานยังไงก็ได้ ยังไงก็ไม่มีใครกล้าทำอะไรเราได้
.
สิ่งเหล่านี้สร้างความเสียหายต่อองค์กรมากกว่าที่เราคิดในหลายมิติ ถ้าคนนั้นอยู่ในระดับปฏิบัติการก็สร้างความเสียหายสำหรับ functions งานนั้นๆ ถ้าเป็นระดับผู้จัดการก็สร้างความเสียหายทั้งแผนก ถ้าเป็นผู้บริหารก็สร้างความเสียหายทั้งองค์กร
.
สร้างความเสียหายยังไง?

ทางตรงความสามารถไม่ถึง งานไม่ได้ประสิทธิภาพตามตำแหน่งงาน และขาดความรับผิดชอบเพราะ mentality ผิดๆ
.
ทางอ้อมด้านการปกครอง
พอพนักงานคนอื่นเห็นว่ามีเส้นสาย ทำงานดี ผลงานดี ไม่สู้คนมีเส้นสาย พนักงานที่เก่งๆจะถูกกลืนโดยระบบ กลายเป็นทำงานเช้าชามเย็นชาม เพราะจะเหนื่อยไปทำไม ทำดีก็เท่าเดิม แทนที่พนักงานจะมุ่งเน้นทำงานให้มีประสิทธิภาพ ก็มุ่งเน้นเล่นการเมืองภายในแทนเช่น ประจบนาย เลื่อยขาเก้าอี้คนอื่น เพราะ culture องค์กรมันเป็นแบบนั้นไปแล้ว พนักงานส่วนหนึ่งรับกับระบบแบบนี้ไม่ได้ก็ลาออกไป พอองค์กรเหลือแต่คนไม่ทำงานให้มีประสิทธิภาพองค์กรก็เริ่มเสื่อมไปเรื่อยๆ
.
สิ่งนี้เป็นปัญหา classic ของผู้บริหารระดับสูงเสมอมาหลายพันปี ว่าเราควรจะแต่งตั้งคนที่ไว้ใจได้หรือคนเก่ง
.
การแต่งตั้งคนสนิทที่สำเร็จก็มี แต่ต้องมีกระบวนการที่จะทำให้มันสำเร็จที่เข้มงวด แต่โดยส่วนใหญ่ไม่ work 80%
.
คนเก่งที่ไว้ใจได้ก็มีแต่หายากมาก ถ้าเจอต้องรักษาเอาไว้ด้วยชีวิตเลยและทำให้เขาก้าวหน้าไปพร้อมกับเรา

Pawoot Pom Pongvitayapanu

เจ้าของบริษัท เจ้าของทีม ในวันที่ Work from home กำลังเป็นที่นิยม โดยเฉพาะในกลุ่มทำงานด้าน Developer ตอนนี้เริ่มเจอปัญหา “การทำงานซ้อนหลายๆ บริษัทพร้อมๆ กัน โดยที่นายจ้างไม่รู้”
ที่บริษัท PaySolutions เพิ่งเจอปัญหานี้ไป เจอโปรแกรมเมอร์ ท่านนึง ทำงานไม่ทัน งานไม่มีคุณภาพ ทีมก็เริ่มแปลกใจ พอไปเช็กมา พบว่า “เค้ายังคงเป็นพนักงานบริษัทอื่นอยู่ด้วย ทั้งๆ ที่ยังเป็นพนักงานบริษัทเรา” โอ้ววว…. ตกใจมาก มันกล้ากันแบบนี้เลยเหรอ
สืบไปสืบมา.. พบว่าไม่ใช่รับซ้อนแค่ 2 บริษัท แต่ มันไปถึง 3 บริษัทกันเล้ยเว้ยยยยย…​โอ้ววว… ทำไมเดียวนี้ มันกล้ารับซ้อนกันขนาดนี้เลยเหรอ…
ลองไปเช็กทีมงานของคุณให้ดีนะครับ …

https://www.facebook.com/pawoot/posts/10163119699792178

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

ที่สำคัญ ไม่ต้องเสียเงินซื้อแม้แต่บาทเดียว

https://eng.libretexts.org/Bookshelves/Computer_Science/Programming_and_Computation_Fundamentals/Mathematics_for_Computer_Science_(Lehman_Leighton_and_Meyer)

“การเรียนด้านปัญญาประดิษฐ์หรือ AI ในไทย”

ในความคิดของผมที่เป็นอาจารย์สอนทางด้านอัลกอริทึมมานานกว่า 20 ปี ผมจะบอกว่าเรากำลังไปในทิศทางที่ผิดครับ

ผิดในที่นี้ ไม่ได้หมายความว่า เราไม่ต้องสอน AI นะครับ แต่ผิดที่ว่าเราเน้นสอน AI อย่างเดียวต่างหาก

การจะเป็นผู้ใช้ AI ในการแก้ปัญหาที่ดี ต้องมีความรู้อะไรหลาย ๆ อย่างครับ

1. คณิตศาสตร์ต้องดี หมายความว่าหาเหตุผลเป็น

2. ต้องรู้หลักการออกแบบและวิเคราะห์ non-AI algorithms ด้วย ซึ่งตามปกติจะสอนกันในวิชา introduction to algorithm design ในระดับปริญญาตรี ซึ่งวิชานี้จะต้องใช้คณิตศาสตร์เป็นอย่างมากครับ

3. ต้องรู้ข้อจำกัดของการคำนวณ เช่น ปัญหานี้แก้โดยใช้อัลกอริทึมที่ทำงานอย่างรวดเร็วไม่ได้ หรือแม้กระทั่งไม่สามารถใช้คอมพิวเตอร์โมเดลปัจจุบันในการแก้ได้เลย เป็นต้น ตามปกติสิ่งเหล่านี้จะเรียนกันในวิชา theory of computation ครับ

โดยทั่วไป คนจะต้องรู้ทั้งสามข้อนี้ ก่อนที่จะมาเรียน AI ครับ เพราะ AI จะเป็นทางออกสุดท้ายเมื่อไม่สามารถใช้ non-AI algorithms ในการแก้ปัญหาได้

ไม่ใช่ใช้ AI เป็นวิธีแรกในการแก้ปัญหาครับ หรือแย่ไปกว่านั้นคือ พยายามใช้ AI ในการแก้ปัญหาที่แก้ไม่ได้โดยใช้โมเดลคอมพิวเตอร์ในปัจจุบัน

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

Picture credit: Reddit

#my2cents

เวลาหลายคนพูดว่า "A.I." นี่ จริงๆ แล้วเบื้องหลังมีแค่นี้แหละ .... แต่มันเป็น buzz word ที่ขายได้

หลักการพื้นฐานคือ "คอมพิวเตอร์ตัดสินใจตาม predefined rules" (เรียกว่า rule-based system)

ส่วน rules พวกนี้มันจะมาจากไหนก็อีกเรื่อง .....

rules พวกนี้อาจจะเอามาจากคนที่ทำงานใน field นั้นๆ และมีประสบการณ์เยอะก็ได้ (ถ้างั้นก็เรียก expert systems) ซึ่ง rules พวกนี้อาจจะซับซ้อนเป็นโครงสร้าง if-else ซ้อนๆ กันเยอะๆ ก็ได้ (เป็น decision tree ... ถ้าตัดสินใจแบบนี้แล้วต้องไปตัดสินใจอะไรต่อ ฯลฯ) .... ในชีวิตทั่วไปเราก็เห็นบ่อยตามคู่มือ troubleshooting ของ call-center หรือการวินิจฉัยอาการป่วยเบื้องต้นด้วยตัวเองก่อนไปหาหมอ นั่นแหละ ... กฏพวกนั้นก็มาจากผู้เชี่ยวชาญทั้งนั้น

แต่ถ้ามันเอามาจากการเรียนรู้/ฝึกจากข้อมูลเยอะๆ ที่มาจากการตัดสินใจเยอะๆ และไปสอนมัน ฝึกมัน ก็เป็น Machine Learning .... ซึ่งก็อยู่ที่มันเรียนรู้ยังไงอีกน่ะแหละ มันก็มี model ของตัว "สมอง" มี model/methodology ในการฝึก การเรียนรู้ การสอน การวัดผล หลายแบบนะ ...... อันนี้เราก็ต้องไปดูคุณภาพของ "สมองมัน" และ "หลักสูตรที่สอนมัน" ..... ก็ไม่ต่างจากการสอนคน ..... การที่เราส่งคนไปเรียนก็ไม่ได้แปลว่ามันจะออกมาดีเสมอไป .... การสอน A.I. โดย Machine Learning ก็เช่นกัน

สรุปคือ โดยทางเทคนิคแล้ว .... A.I. ไม่ได้แปลว่า Machine Learning หรือต้องเรียนรู้จากอะไรเสมอไป ..... และ Machine Learning ไม่ได้แปลว่าดีกว่าคน

Expert Systems อาจจะดีกว่า Machine Learning based ก็ได้ สบายๆ (ให้ทำงานตามกฏที่ Consult บอก อาจจะดีกว่าให้คนไม่รู้เรื่อง เรียนรู้จากข้อมูลและกรณีศึกษาที่น้อย เป็นต้น)

===============================

กลับมาเรื่องเดิมก่อน ชักจะออกทะเล

ดังนั้น ถ้าพูดกันในทางเทคนิคจริงๆ แล้ว ถ้ามี "กฏในการตัดสินใจเพียงข้อเดียว" (single if, else ... ซึ่ง else อาจจะเป็น do-nothing) ที่ "กฏนั้นเอามาจากคนที่ออกกฏ หรือคนที่เคยตัดสินใจเรื่องนั้นแล้วออกมาดี" .... ก็ถือว่าเป็น A.I. ได้

ซึ่งเอาจริงๆ แล้วทุกโปรแกรมในโลกก็แทบจะเข้าข่ายแทบทั้งนั้นแหละ

ให้เห็นภาพชัดๆ คือ โดยทางเทคนิคแล้ว ผมสามารถบอกได้ว่าผมใช้ A.I. ตัดเกรด .....

นี่ไง ผมทำ expert system เลยนะ rules-base ผม extract มาจาก expert จริงๆ เลยว่าเขาทำยังไง (> 80 ได้ A, 71-80 ได้ B, ....) มี decision tree ด้วย (ถ้า "เข้าเรียนน้อยกว่า 50% หรือไม่เคยส่งการบ้าน" ให้ตกเลย) ฯลฯ ....

นี่มันโจทย์การบ้านโปรแกรมมิ่งพื้นฐาน โปรแกรมมิ่ง 101 ชัดๆ

===============================

คนทำ A.I. แบบจริงจังก็มีอยู่จริงครับ ไม่ได้บอกว่าไม่มี ..... ที่ทำระดับ deep learning ที่ทำ adaptive learning/adaptive neural networks สารพัด คิดวิธีการสอน/เรียนรู้ต่างๆ มากมาย ก็มี .....

ประเด็นของโพสท์นี้คือ เราอย่าไปบ้าเห่อมาก เวลามีคนบอกว่า "เราทำ A.I." .... และอย่าคิดว่ามันคืออะไรล้ำๆ นี่นั่นโน่น ..... ต้องถามเนื้อในดีๆ ว่าเป็นยังไง ...... และควรถามคนที่รู้จริงๆ (นักวิชาการ อาจารย์มหาลัย นักวิจัย ฯลฯ พวกนี้ให้ความเห็นได้ดี)

ของที่ขายได้ มันก็มีคนเอามาขายเยอะ ของดีก็เยอะ ของห่วยก็เยอะ แล้วก็มีคนปลอมเยอะ .... ในตลาดก็มีทั้งของจริงของปลอม ของดีของห่วย ปนๆ กันไป .....

ไม่ต่างจากกระเป๋าแบรนด์เนม ไม่ต่างจากรองเท้าแบรนด์ดัง (มีของปลอมขายเยอะ) ไม่ต่างของเครื่องกรองอากาศ ผ้าปิดจมูก (มีทั้งของดีของห่วย บางทีมีปลอม) ฯลฯ นั่นแหละครับ

ซึ่งพวก Buzzword พวกนี้มันก็ไม่ต่างกัน .... มันขายได้ คนก็ขายเยอะ .... ของจริงก็มี ของปลอมก็เยอะ ของดีก็มี ของห่วยก็เยอะ ไม่ต่างกัน

10 เรื่องพื้นฐาน essential statistics สำหรับ data analyst
1. ทำไมต้องเรียนสถิติ
2. การสุ่มตังอย่าง sampling
3. population vs sample
4. การวัดค่ากลาง mean median mode
5. การวัดการกระจายตัว sd var iqr range
6. normal distribution
7. empirical rules ของ normal dist.
8. การวัดตำแหน่ง min max percentile
9. รู้จัก five number summary ของ John Turkey
10. สร้างชาร์ทรูปแบบต่างๆได้ด้วย Excel, Google Sheets, R
ในงานประจำวัน พวกนี้ได้ใช้ทุกวันเลย ลุยค้าบทุกคน

ตั้งแต่เห็น Frontend ใหม่ที่พยายามจะเอาชนะ React รู้สึกว่าตัวนี้ SolidJS น่าเชียร์สุดแล้ว
เห็น Vue, Svelte มา สิ่งนึงที่ผมไม่ชอบ (แต่คาดว่าคนส่วนใหญ่ชอบ) คือ มันมีความพยายามในการเบลอเส้นระหว่าง Primitive Variable กับ Reactivity โดยการบอกว่าถ้ามีตัวแปรตัวนึง ชื่อ x แล้วเราเอา x ไปใส่ใน template engine แล้วเราสามารถมอง x เป็นเหมือน Primitive ที่ใช้ได้เหมือนกันเด๊ะๆ เช่น x++ ไปเลย เดี๋ยว template engine จะไล่ตามเก็บให้เอง
(ซึ่งตรงนี้ส่วนตัวผมชอบ Vue มากกว่าที่อย่างน้อยมันพยายามจะบอกว่าช่วย wrap พวกนี้ไว้ใน class หน่อย)
คือการพยายามเบลอเส้นตรงนี้มันอาจจะทำให้ Learning curve น้อยลง เพราะเราสามารถคิดว่าก็แค่ variable ธรรมดาเองได้ แต่มันทำให้สองคอนเซปต์ คือ real primitive variable กับ reactive variable มันรวมกันแยกจากกันไม่ออก ทำความเข้าใจการทำงานได้ยากขึ้น
ส่วน React มันบังคับว่าต้องเปลี่ยนผ่าน setState ซึ่งมันทำให้แยกออกง่ายขึ้นว่าทำไมถึงเกิด reactivity ได้ อ้อ เพราะการเซ็ตมันต้องเซ็ตผ่านตัวนี้นี่เอง แล้วทุกตัวแปรเป็น Immutable นี่เอง ทำ API แบบนี้มันอาจจะเพิ่ม Learning curve ในช่วงแรกเพราะมันไม่คุ้นเคย แต่มันไม่ทำให้ผมต้องบอกคนอื่นว่า "จงศรัทธา ใช้ count++ ไปซะ เดี๋ยวมันทำ Magic ให้เอง" ระยะยาวผมว่ามันเข้าใจง่ายกว่าแถม extensible กว่าด้วย
ผมเชื่อในหลัก Simple > Easy ความไม่เอาคอนเซปต์สองอย่างมาจับรวมจนเป็นยำเนื้อแปลกๆ SImple คือแต่ละอย่างไม่ผสมกัน ทำความเข้าใจแต่ละส่วนของระบบได้ง่ายเพราะมีระเบียบชัดเจน ส่วน Easy คือเริ่มง่าย ผมก็ชอบระบบที่ Simple มากกว่าถึงแม้อาจจะต้องเริ่มเรียนเยอะกว่า
SolidJS นี่ก็ออกแบบด้วย Philosophy แบบเดียวกัน วิธีที่ใช้คือทุกๆ Reactive ต้องเรียกผ่าน function เสมอ ซึ่งเพิ่มไปทั้งทั้งจังหวะดึงมาใช้และจังหวะ set ซึ่งโอเคมากๆ (และตรงนี้เปิดโอกาสให้ใช้ Primitive set ได้ด้วยโดยที่ยังชัดเจนว่าทำไมถึงใช้ได้ เพราะคุณเข้าถึง variable ตรงๆ ไม่ได้ถ้าไม่ผ่าน function) ทำให้ผมไม่รู้สึกแหม่งๆ กับตัวนี้ ดังที่เขาบอกไว้ในเว็บเลย
"Simple is better than easy. A lesson that comes hard for fine-grained reactivity. Explicit and consistent conventions even if they require more effort are worth it. The aim is to provide minimal tools to serve as the basis to build upon."
(ขอจิกกัดหน่อยว่าตอน Rich Harris คนสร้าง Svelte โฆษณาว่า เราเชื่อมกับ Primitive เลยไม่ต้องเรียนรู้อะไรเพิ่ม คุณแค่ count++ มาเดี๋ยว Svelte ฟังให้เอง นี่สิคือ Reactivity ที่แท้จริงไม่เหมือนใน React ผมคิดในใจแหละว่านั่นแหละคือ Blur Magic ที่แท้จริง และส่วนตัวในขณะที่คนฟังเฮว่าเจ๋งมากๆ ผมน่ะรู้สึกว่า that's not a feature นะ แต่ก็เข้าใจได้ว่าทำไมคนชอบ มันเริ่มง่ายกว่าจริงแหละ)
ฟีเจอร์ของ SolidJS ที่ดีกว่า React คือเวลาใช้พวก effect ไม่ต้อง track dependency จัดการได้ในตัวเองไม่ต้องให้เราบอก สามารถทำ bundle size น้อยกว่า ทำงานเร็วกว่า สามารถแยกออกได้ในตัวเองว่าต้อง re-render เยอะขนาดไหน และก็ตัว State ต่างๆ สามารถอยู่นอก Component ได้ตราบใดที่อยู่ใน reactive scope (ทำให้ไม่จำเป็นต้องใช้ Store เลย แต่ก็มี API สำหรับการสร้าง Store มาให้)
ถ้าไม่นับพวกแยกภาษาใหม่ไปเลยอย่าง Elm ผมว่ามันเป็น Frontend ที่เข้าใจ Reactivity และออกแบบ Fundamental API มาดีตรงกับ Philosophy ที่ผมใช้เขียนโปรแกรม และทำหลายอย่างได้ดีกว่า React ก็เหลือแต่ ecosystem ละจะไปได้ดีขนาดไหน

ยิ่งอ่านงานของ fasterthanlime ยิ่งประทับใจ
เขาเป็นคนเขียนบล็อกและทำวิดีโอที่ลงลึกมากไปจนถึงขั้นที่ว่าดูว่า Rust, Go คอมไพล์ออกมาได้ไบนารี่แบบไหน ทำวิดีโอสอนว่า x86 instruction ทำงานยังไงประวัติความเป็นมายังไงทำไมมันยังงี้
แต่ที่ผมชอบที่สุดมาจากคลิป The fist of megabytes ที่เขาออกมาบอกว่า ทำไมใน reddit, hn ชอบด่า Electron กันว่าเป็นแค่แอพแชททำไมต้องใช้ ทำไมต้องกินเมมเยอะ เขามาสาธยายเลยว่าการทำ Text rendering, Text input ให้รองรับทุกภาษาทุกสไตล์ในโลกและซูมเข้าออก มันมีอะไรบ้าง ต้องทำ anti-aliasing ในฟอนต์ยังไงให้สวย Networking มีอะไรบ้างที่ต้องคิด
และที่ประทับใจจริงๆ คือเขาบอกว่ายิ่งเขาลงลึกเข้าไปเข้าใจอะไรพื้นฐานมากมายแแบบนี้ ยิ่งได้เรียนรู้ ก็ยิ่งเกิดความ Appreciate (ชื่นชมและรู้สึกขอบคุณ) ในงานที่มันเกิดมาแล้ว ในสิ่งที่คนอื่นทำทิ้งไว้ให้ ทำให้เขายิ่งมี Humility มากขึ้นกับเครื่องมือพัฒนาต่างๆ ที่มันเกิดขึ้นบนโลก
ที่ผมเจอมากับโปรแกรมเมอร์หลายคนที่ยิ่งเข้าใจอะไรมาก ยิ่งทำอะไรได้ลึกหรือกว้างมากขึ้นเท่าไหร่ก็ยิ่งโอหัง ยิ่งดูถูกงานคนอื่น ทำไมทำอะไรซับซ้อนมากมายบ้าง ใช้เป็นแต่เครื่องมือบ้าง โดยที่ไม่ได้พยายามเข้าใจที่มาที่ไปอะไรเลย ตัดสินกันแค่ผิวๆ ผมคิดว่าทัศนคติของ fasterthanlime ที่น่ารักและเป็นทัศนคติที่ดีมากสำหรับการเป็นโปรแกรมเมอร์ครับ และทำให้ผมดีใจที่ยังมีคนน่ารักแบบนี้อยู่ร่วมสายงานสายอาชีพอยู่ด้วยครับ
ผมแนะนำบล็อกและวิดีโอของเขา เนื้อหาดีมาก Search ได้เลยหรือดูที่ผมแชร์อีกโพสต์ก็ได้

dev Java ลองเทียบ base64 กับ Rust แล้วมาโพสใน reddit ว่า Rust ช้ากว่า Java ล่ะเธอ บังเอิญเทพ Rust+SIMD ผ่านมาเลยจัดให้ 1 กรุบ
.
แกบอกว่าสมัยนี้เค้าใช้ Rust+SIMD กันครับลุง แล้วผลคือ Rust+SIMD มันเร็วกว่า Java แบบเลขคนละหลักเลย ถถถ
.
จบข่าวบันเทิงภาคค่ำ ใครอยากสนุกจำ keyword ไว้ครับ Rust, Wasm, Wasi, SIMD, WebGPU, LLVM, eBPF, QUIC, Web3, PostgresML รับรองบันเทิงทุกตัว 😆

🦀 Javascript vs Rust // กำลังแกะ code friktion จาก js ไปเป็น rust เลยเอามาเทียบให้ดู
1. ใครต้องเขียน code BigNumber หรือ Decimals ใน js จะเจอกับภาพซ้ายเพราะ js ไม่มี operator overloading ทำให้ต้องเขียน method add mul div ยาวๆ ส่วนใน Rust + * / ได้เลย
2. ถ้า rust ล้วนแล้วไม่ต้อง generate ABI หรือ ts ก็ใช้ struct ของ program ได้เลย (ของ anchor ต้อง + discriminator 8 bytes)
3. ถ้าใช้ nonblocking client จะใช้กับ wasm, yew (rust-react) ได้ และใช้ web3 (rust) บนเวบได้ด้วย
ตั้งแต่ frontend(yew) 👉 web3(wasm) 👉 cloudflare(worker-rs) 👉 smart contract(solana) เขียนได้ด้วย rust ทั้งหมดไม่ต้องแปลงเป็น ts หรือ js ไปมาให้ปวดหัว
แต่ยังสอนไม่ได้ เพราะไม่รู้จะเริ่มตรงไหนดี มันเยอะไปหมด ใจเย็นๆ นะทุกคน 😅

รากำลังเปิดรับ Rust Smartcontract Engineer นะครับ
ภาษาปราบเซียน หาคนที่ได้ทั้งสองอย่างน่าจะยาก
ดังนั้น..
📍 เขียน Rust เทพๆ มาก่อน แต่ไม่เคยเขียน Smartcontract ก็มาสมัครได้
📍 หรือเขียน Solidity เทพๆ มาก่อน แต่ไม่เคยเขียน Rust ก็สมัครได้
เราสอนให้ครับ http://ava.fund/recruitment
PS. ใครสนใจ Rust แต่ไม่เคยเขียน ลองดูคลิปของ Natechawin Suthison ทีม Ava ที่เล่าเรื่อง Rust ให้ฟังกันครับ https://www.facebook.com/kubeOpsSk.../videos/231369932096437

ลองเขียน Rust เล่นไปสองร้อยกว่าบรรทัด .... รู้สึกดีกว่าตอนลองเขียน Go ...
ตอนนี้ยังบอกอะไรไม่ได้มากกว่านี้ เดี๋ยวลองเขียนเล่นไปอีกสักพัก พอรู้ basic ของภาษาหมดแล้ว เอามาลองเขียน basic data structures กับ algorithms บางตัว แล้วลองทำ toy project (เช่น log parser, json parser, sudoku solver) นั่นแหละ ถึงจะรู้ว่าเป็นยังไงกันแน่

สรุปทอล์คที่ 16 ของงาน #JavaScriptBangkok: ทำ Data Visualization ให้เร็วปรี๊ด ด้วย WebAssembly และ Rust! 🤯
- ปัญหาคือ ก่อนที่จะแสดงผลกราฟสวยๆ ได้ มันต้องคำนวณข้อมูลเยอะมากๆ การวาดก็ซับซ้อน แถมตอนเรนเดอร์ก็จะเจอปัญหาเรื่อง repaints และ reflows อีก ทำให้แอพช้า กระตุก และค้างไปเลย 🙁
- เจ้า WebAssembly มันเป็น low-level bytecode ทำให้ควบคุม performance ได้ดีกว่า และ Rust ทำงานกับ WebAssembly ได้ดีมากๆ มีระบบไทป์ที่ดี ไม่ต้องมี GC ด้วย
- Rust สามารถคอมไพล์ออกมาเป็น WebAssembly Target โดยใช้ wasm-bindgen ในการเชื่อมระหว่าง JavaScript กับ WebAssembly โดยสามารถเรียกไปมากันได้ (wasm call js, js call wasm)
- งานที่บริษัทแอพแมนต้องนำเสนอข้อมูลลูกค้าด้านประกันภัยเยอะมากๆ ทำให้การคำนวณเยอะ
- ลองเขียนส่วนของการคำนวณที่เคยเป็น JS เปลี่ยนไปเขียนเป็น Rust แทน ปรากฎว่าเร็วขึ้น 50% เลย!
- แต่เนื่องจาก chart ที่ใช้ มันไม่ได้ทำงานบน canvas/webgl แต่ดันไป manipulate dom เอง ทำให้ตอน render ไม่ได้เร็วขึ้นมากขนาดนั้น (ถ้าใช้ canvas/gl ส่วนนี้คงเร็วขึ้น)
- การเข้าถึง JS Object ตรงๆ จะช้าอยู่ดี (น่าจะต้องใช้ SharedArrayBuffer) และยังเข้าถึง DOM ตรงๆ ยังทำไม่ได้ (ต้องรอ WebIDL หรือ mutate shared canvas memory เอา)
- การนำไปใช้ที่น่าสนใจ เช่นการทำ pathfinding หรือ physics ในกราฟ น่าจะไปลองเล่นในอนาคต 😉
#สรุปJavaScriptBangkok #JSBangkok

Thanawat Suriya · Follow
osptnoeSrd
u
32
y

33
l
,
0

a
J
32714t5u0hf07
2
lf8h0f
4
gtc2tu
2
18
0
84
2
097
·
ผมไม่ใช่ Expert ด้านภาษา Rust นะครับ งานผมส่วนใหญ่จะออกไปทาง main c/c++ ซะเยอะเลย และผมก็ยังเชื่อมั่นใน performance ของ C/C++ อยู่จนถึงปัจจุบัน... ทีนี้ผมมีโอกาสได้ลองไปนั่งอ่าน และศึกษา Rust โดยบังเอิญ ทำให้ผมเริ่มรู้สึกว่า เห้ย เอาเรื่องอยู่นะ คือเรื่อง performance นี้ถือว่าเร็วในระดับเดียวกันกับ C/C++ เลย แต่ผมก็ยังไม่มีโอกาสได้นั่งเล่นมันจริงจังเลยครับ ถ้าใครพอทราบว่าตัวไหนเร็วกว่ากันก็สามารถคอมเม้นท์แชร์ความรู้ได้นะครับ... ทีนี้ Rust มันน่าสนใจตรงไหนหละ ในเมื่อ performance มันพอๆ กัน แล้วทำไมต้องไปสนใจมัน? คำตอบไม่ได้อยู่ที่ performance ครับ แต่มันน่าสนใจเพราะเรื่องการจัดการ memory ของมันครับ คนที่เขียน C/C++ มาก่อน ผมเชื่อเลยว่าต้องเคยมีปัญหาเกี่ยวกับเรื่องนี้อย่างแน่นอน บางโปรเจคเล่นเอากินไม่ได้นอนไม่หลับเลยก็ว่าได้ แต่ Rust มันเก่งครับเรื่องนี้ และมีข้อดีอีกหลายๆ อย่างที่ผมเชื่อว่ามันจะดันให้ Rust เป็นที่นิยมมากขึ้นในอนาคตอย่างแน่นอน แถม performance มันก็สูงพอที่จะสามารถหยิบเอาไปทำอะไรที่มันอยู่ในระดับ low layer ได้อีกหลายอย่างเลย...
ถ้ามี Expert คนไหนใจดีสามารถทักเข้ามาให้คำแนะนำผมได้เลยนะครับเพราะอยากลงไปยำ และชำแหละมันมากตอนนี้ หรือถ้ามีกลุ่ม และ Community ดีๆ ก็ดึงผมเข้าไปด้วยหน่อยนะครับ ^__^ เดี๋ยวหลังจากปล่อยโปรเจคหลายๆ ตัวออกไปผมก็จะเริ่มมีเวลาว่างมากขึ้น อยากจะไปนั่งเรียนจริงจังดูสักตั้ง >__< ตั้งใจว่าน่าจะเอามาลองปรับใช้กับงาน Backend ดูครับ...
.
https://pcwalton.github.io/.../an-overview-of-memory...
.
https://www.rust-lang.org/ — feeling motivated.

RUST ผู้มาแทน C/C++
.
มีคนบอกว่าอยากให้เขียนอธิบายเกี่ยวกับภาษา Rust โดยย่อ ผมจึงเขียนโพสนี้ขึ้นเพื่อตอบสนองต่อคำขอนั้น
.
เป็นภาษา "หลากกระบวนทัศน์" ( multi-paradigm ได้แก่ concurrent, functional, generic, imperative, structured) สำหรับเขียนโค้ดคุมระบบ (system programming) อาทิ ระบบปฏิบัติการ ไดร์เวอร์ (เมาส์ การ์ดจอ และอื่น ๆ) งาน IoT หรืองานฝังตัว
.
เป็นภาษาเน้นความปลอดภัย โดยเฉพาะอย่างยิ่งความปลอดภัยระหว่างทากส์ของการทำงานแบบคู่ขนาน มีซินแทกซ์คล้าย C++ แต่คุมความปลอดภัย (หน่วยความจำ) ได้สะดวกกว่าและมีเพอร์ฟอร์แมนซ์สูงกว่า
.
เป็นภาษาน้องใหม่ อายุสิบปี มีในโอเอสต่าง ๆ ดังนี้ Linux, macOS, Windows, FreeBSD, OpenBSD, Redox, Android
.
ตัวแปลภาษาเป็นโอเพ่นซอร์ส มีในซีพียูต่าง ๆ ดังนี้ ARM, IA-32, x86-64, MIPS, PowerPC, SPARC, RISC-V
.
ถูกออกแบบมาเพื่อการเขียนโค้ดเลเยอร์ล่างสุด (คือชั้นที่ติดกับฮาร์ดแวร์) แทนที่ C/C++ ที่ไม่ค่อยสะดวก หรือเขียนเว็บบราวเซอร์ หรือโอเอส หรือทำ "เอจคอมพิวติง" เช่นเพลตฟอร์ม Azure IoT Edge ของไมโครซอฟท์ เขียนด้วยภาษา Rust
.
ภาษาอะไรก็ดีทั้งนั้น เลือกภาษาให้เหมาะกับงานเป็น (หนึ่งใน) สิ่งบ่งชี้ว่าโปรเจ็กต์จะรอดหรือจะล่ม
.

RUST ผู้มาแทน C/C++
.
มีคนบอกว่าอยากให้เขียนอธิบายเกี่ยวกับภาษา Rust โดยย่อ ผมจึงเขียนโพสนี้ขึ้นเพื่อตอบสนองต่อคำขอนั้น
.
เป็นภาษา "หลากกระบวนทัศน์" ( multi-paradigm ได้แก่ concurrent, functional, generic, imperative, structured) สำหรับเขียนโค้ดคุมระบบ (system programming) อาทิ ระบบปฏิบัติการ ไดร์เวอร์ (เมาส์ การ์ดจอ และอื่น ๆ) งาน IoT หรืองานฝังตัว
.
เป็นภาษาเน้นความปลอดภัย โดยเฉพาะอย่างยิ่งความปลอดภัยระหว่างทากส์ของการทำงานแบบคู่ขนาน มีซินแทกซ์คล้าย C++ แต่คุมความปลอดภัย (หน่วยความจำ) ได้สะดวกกว่าและมีเพอร์ฟอร์แมนซ์สูงกว่า
.
เป็นภาษาน้องใหม่ อายุสิบปี มีในโอเอสต่าง ๆ ดังนี้ Linux, macOS, Windows, FreeBSD, OpenBSD, Redox, Android
.
ตัวแปลภาษาเป็นโอเพ่นซอร์ส มีในซีพียูต่าง ๆ ดังนี้ ARM, IA-32, x86-64, MIPS, PowerPC, SPARC, RISC-V
.
ถูกออกแบบมาเพื่อการเขียนโค้ดเลเยอร์ล่างสุด (คือชั้นที่ติดกับฮาร์ดแวร์) แทนที่ C/C++ ที่ไม่ค่อยสะดวก หรือเขียนเว็บบราวเซอร์ หรือโอเอส หรือทำ "เอจคอมพิวติง" เช่นเพลตฟอร์ม Azure IoT Edge ของไมโครซอฟท์ เขียนด้วยภาษา Rust
.
ภาษาอะไรก็ดีทั้งนั้น เลือกภาษาให้เหมาะกับงานเป็น (หนึ่งใน) สิ่งบ่งชี้ว่าโปรเจ็กต์จะรอดหรือจะล่ม
.

น้องๆ ในออฟฟิศลองเล่น Bard (AI คล้ายๆ ChatGPT ของ Google) กัน .... โดยลองถามประวัติแต่ละคนในออฟฟิศ ... รวมทั้งผมด้วย
บันเทิงดี ถูกครึ่งไม่ถูกครึ่ง (โดยประมาณ) เหมือนอ่านนิยายอิงประวัติศาสตร์ ที่มีการแต่งนี่นั่นโน่นเพิ่ม
คำถามสำคัญๆ มาก ก็คือ "คนที่ไม่ใช่เจ้าตัว นี่จะรู้ไหมนะ ว่าส่วนไหนเป็น fact ส่วนไหนเป็น fiction" .......
===============
สำหรับพวก Generative AI นี่ ถ้าจะเอามาใช้กับอะไรก็ตามที่มีความถูกต้องชัดเจน เช่น ข้อเท็จจริง เหตุการณ์ประวัติศาสตร์ การพิสูจน์คณิตศาสตร์ ทฤษฎีทางวิทยาศาสตร์ ผลการทดลองทางวิทยาศาสตร์ รวมถึงโปรแกรมคอมพิวเตอร์ และ Algorithm นี่ต้องระมัดระวังอย่างมาก
นั่นคือ เราต้องมีความรู้และความสามารถเพียงพอในการตรวจสอบสิ่งที่มันบอกเรา ไม่เช่นนั้นก็แย่หน่อย
ซึ่งเรื่องนี้จะแตกต่างจากการที่เอามันมาแต่งนิยาย แต่งสุนทราพจน์ สร้าง flow ของการบรรยาย ออกแบบแผนการท่องเที่ยว ฯลฯ ที่พวกนี้มันสร้างออกมายังไงก็ได้ ให้คนยอมรับได้ (ก็คือตามสิ่งที่มันเรียนรู้รูปแบบการเขียนต่างๆ ของคนมาน่ะแหละ) ก็พอแล้ว ....
อย่างที่ผมเคยบอกไว้ด้วยความเป็นห่วง ว่าการที่เรามี Generative AI ที่สามารถสร้างภาพออกมาได้สวยงามเหมือนกับจิตรกรนักวาดภาพจริงๆ เขียนข้อความสวยๆ งามๆ ออกมาได้ราวกับคนเก่งๆ มาเขียน ..... อาจจะทำให้คนเชื่อว่า AI สามารถทำหลายต่อหลายอย่างแทนคนได้แล้ว .... ซึ่งมันก็จริงในบริบทแคบๆ ของการ Generate สิ่งที่ไม่มีถูกมีผิดชัดเจน มีแต่ถูกใจกับไม่ถูกใจ ใช้ได้กับใช้ไม่ได้ ที่พิจารณาโดยคนเป็นคนๆ ไปเท่านั้น ...
แต่มันก็ทำให้หลายคนคิดว่าจะเอา AI มาทำนั่นทำนี่แทนคนได้เลย ... รวมถึงการคัดกรอง จัดกลุ่ม และตัดสินใจต่างๆ ด้วย ....
แต่ถ้าเราจะเอามันมาใช้ในการทำ classification ตลอดจนการตัดสินใจแทนเรา ใน decision problem ต่างๆ อย่างอัตโนมัติ นี่จริงๆ แล้วยากกว่ามากๆ ...... ถ้าจะทำ ก็ต้องลงรายละเอียดเรื่องพวกนี้กันมากๆ ว่าสิ่งที่มันตัดสินใจนั้น ถูกต้องหรือไม่
วันที่แทบทุกคนจะใช้ AI เป็นเครื่องมือในการช่วยทำงานในทางใดทางหนึ่ง กำลังจะมาถึงครับ และวันนั้นเราต้องการคนที่มีวิจารณญาณ ความรู้เชิงลึกในเรื่องที่เขาใช้ AI ช่วยงาน และความละเอียดรอบคอบในการตรวจสอบ ตรวจงาน ในทุกรายละเอียด .... มากกว่าวันนี้เสียอีก ......

https://ohshitgit.com/th

Git

ฐานะคนจ้าง ตั้งแต่เปิด บ มาคนที่เรียน code camp ยังไม่ผ่านสัมภาษณ์ บริษัทได้เลยซักคนครับ ไม่รู้เรียนอะไรมาบ้าง แต่ถามตอบไม่ได้เลยก็มี บางทีรู้แค่ที่เรียนเลยครับ พื้นฐานแทบไม่มีเลยครับ เอาจริงๆสู้เด็กจบใหม่บางคนไม่ได้ เพราะจะตรงสายกว่าและได้เปรียบเรื่อง logic ครับ

🎉 QA Hive ขอแบ่งปันเว็บฝึกฝีมือสำหรับน้องๆ QA ของเรา ให้ทุกท่านได้ร่วมใช้งานด้วยกันครับ เหมาะสำหรับ QA มาลอง Manual, UI Automated Test หรือ API ก็ได้ทั้งนั้น
.
ขอแค่อย่า Load Test นะครับ 555
.
https://web-demo.qahive.com/landing
.
ปล. ถ้าอยากได้ Component อะไร Feedback กันมาเยอะๆนะครับ

> be Linus Torvalds
> grow up in Finland, realize there's more to life than saunas and reindeer
> stumble upon UNIX, fall in love but broke as a joke
> say "screw it" and decide to make your own Kernel
> announce Linux on some obscure mailing list, who reads those anyway?
> surprise, a few enlightened souls do
> they start contributing, but not without Linus' "quality control"
> you don't like GPL? tough luck, kiddo, Linus loves it
> Windows is for normies who can't handle a terminal
> macOS is for those too artsy to understand a real OS
> Linux begins to take over servers, because it doesn't suck
> you're not using Linux? you must be one of those NPCs
> only true 200IQ programmers dare contribute to the Kernel
> Richard Stallman? yeah, he's cool, but it's LINUX, not GNU/Linux
> Linus gets mad at bad code, rants in mailing lists, becomes legendary
> he doesn't have time for your lackluster contributions
> GitHub? More like TrashHub for mediocre devs
> continues to insult anyone who writes crappy code, because life's too short
> takes a break to think about being nice, realizes it's overrated
> comes back, Linux still king, open source still the only way
> if you're not running Linux, what are you even doing with your life?
> Linus Torvalds, the rude genius who gave us Linux, keeps mic-dropping
> Windows users still confused, Linux users still enlightened
> end of story, go install Linux or remain a normie forever

น่านน้ำใหม่ไม่ควรมีฉลามเร็วเกินไป
ปลาฉลามเนี่ยมันเก่งในการล่าเหยื่อในทะเลที่มีอยู่เป็นอย่างมาก มันจะสามารถตักตวงเก็บเกี่ยวได้เยอะแยะไปหมดจนอ้วนพีอิ่มหนำ
แต่น่านน้ำใหม่ที่พึ่งสร้าง พึ่งมีปลาไม่กี่ตัว กำลังค่อยๆ ก่อเกิดปะการัง ก่อเกิดลูกหลาน สร้างฝูง ก่อเกิดความหลากหลายทางสายพันธุ์ ก่อเกิด ecosystem ถ้ารีบปล่อยฉลามลงไปก็มีแต่พังพินาศ ฉลามก็กินไม่อิ่ม น่านน้ำใหม่ก็ไม่เกิด ไมามีใครได้อะไร
คนอาจจะเห็นว่าในน่านน้ำเดิม ฉลามสามารถทั้งตักตวงและทำให้ ecosystem ใหญ่แข็งแกร่งขึ้น สร้าง natural selection process ที่ดี คัดกรองปลาที่ไม่แกร่งพอออกจากทะเลได้ แล้วเห็นน่านน้ำใหม่มีโอกาสเติบโต เลยรีบปล่อยฉลามลงไปบ้าง ฉลามเองก็เห็นโอกาสลงไปหากินบ้าง
แต่น่านน้ำใหม่ไม่ควรมีฉลามเร็วเกินไปเสมอ
ผลก็คือน่านน้ำไม่สามารถเติบโตได้จนพังทลายละหนึ่ง และเหล่าฉลามก็หงุดหงิดกับความหิวโหยเก็บเกี่ยวไม่ได้อีกหนึ่ง
Investor: บ้านเราไม่เห็นมี startup คุณภาพเลยว่ะ ลงไปก็มีแต่เสีย หา founder เก่งๆ ทีพร้อมลงมาก
Founder: หาเงินทุนไม่ได้ ไม่มี investor เข้าใจเลย แถมหาทีมงานโปรแกรมเมอร์ดีๆ ก็ไม่มี คนไทยไม่เห็นมีคนเก่งเลย บางคนบอกจะเอา deep tech อ่ะมีมั้ยมีมั้ย มีแต่พวกทำผิวเผิน บางคนปัญหาคือมีแต่พวด geek เกินไม่เข้าใจธุรกิจ ก็ต่างมุมมองกันไป
Programmer: startup เงินเดือนน้อย มีแต่มาหลอกให้ทำงานฟรีให้แต่หุ้นปลอมๆ ถึงเวลาก็รวยกันไปคนเดียว มี liquidity trick อีกมหาศาลที่จะมาเกรียนใส่ ทำไม่คุ้มหรอก
ถ้าดูแต่คำบ่นพวกนี้อ่ะทั้ง ecosystem ไม่มีใครเก่งซักคนครับ ซึ่งก็อาจจะจริง เพราะมันเป็นน่านน้ำใหม่มากๆ ในประเทศมานาน จะไปคาดหวังคนมีประสบการณ์แล้วเก่งรู้หมด ฉันจะมาเก็บเกี่ยวก็คงยากครับ
นั่นแหละภาพที่ผมเห็นในวงการ startup ไทยจากสมัยที่ผมอยู่ มีเพื่อนมีฝูงหลายคนทำก็เจออารมณ์ประมาณนี้ตลอด
และภาพนี้เป็นเหตุผลนึงทำให้ผมบอกกับตัวเองว่าทำงานประจำดีกว่า อย่างมากก็เป็นลูกจ้างใน startup พอละ ขี้เกียจขยายน่านน้ำในดงฉลามที่หิวโหย
ใครพร้อมสู้ ถ้าจริงใจต่อภารกิจตัวเอง ก็ให้กำลังใจอ่ะครับ
ส่วนอีกเหตุผลนึงคือไม่เห็นว่าความฝันตัวเองต้องสเกลมหาศาลอะไรด้วยแหละ เปิดคอร์สเอาประสบการณ์เอาความรู้มาสอนคนที่อยากเรียนอยากเติบโตจริงๆ รู้สึกสบายใจกว่าในเวลานี้
คุณเชื่อมั้ยว่าถ้า openai ได้เงินทุนจำนวนมหาศาลเร็วกว่านี้ chatgpt ไม่เกิดแบบนี้หรอก
ผมเชื่อยังงั้นนะ

จริงป่ะ

ผ่านมา 10 ปีแล้ว คนที่บอกว่าเงินเดือนโปรแกรมเมอร์ไทยเฟ้อมานาน ก็ยังบอกว่าเฟ้อมานานอีกต่อไปอ่ะนะ
ผมก็บอกแบบเดิมอ่ะว่ามันไม่ใช่ปัญหาเฟ้อเลย ขึ้นกับนิยามยังไงแหละ
แต่ผมบอกง่ายๆ ละกัน คุณเห็นเขาซื้อโรนัลโด้กัน 100 ล้านปอนด์ ถ้าคุณเห็นว่านั่นคือค่าตัว “นักบอลคนนึง” ไม่ใช่ค่าตัวโรนัลโด้ หรือคุณไม่รู้ว่าจะเอาโรนัลโด้มาเข้ากับระบบการเล่นของคุณยังไง คือมันก็จะเห็นว่าค่าตัวแพงแหละ
แน่นอนไม่ใช่ว่าโปรแกรมเมอร์ทุกคนเป็นโรนัลโด้หรอก แต่นักบอลเกรดเอ กับนักบอลเกรดบี value ที่เขาทำให้กับสโมสรได้ และความสามารถของสโมสรที่จะใช้เขามันไม่เท่ากัน(คืออาง่ายๆ นะ คุณซื้อโรนัลโด้มาในภารกิจลากทีมขึ้นจากดิวิชั่นสามเป็นดิวิชั่นสอง มันไม่ได้คุณค่าเท่ากับลากทีมให้ได้แชมป์ยุโรปอยู่แล้วอ่ะ)
นั่นแหละ ถ้าคุณเห็นบริษัทเขาซื้อโปรแกรมเมอร์กันแพงๆ แล้วไปมองว่าตลาดมันเฟ้อ มันก็ไม่จริงทั้งหมดอ่ะ โอเคแหละ มันอาจจะทำให้โปรแกรมเมอร์บางคนฝืนขึ้นค่าตัวได้ และสร้างความคาดหวังที่สูงเกินสำหรับคนที่ทักษะไม่ถึงได้ ก็เป็นปัญหาแบบนึง
แต่ตราบใดที่โรนัลโด้ยังเป็นโรนัลโด้ ตลาดบนเขาก็ซื้อขายเกรดนั้นกันแล้วคุ้ม ผมคิดว่าความคาดหวังที่จะรอให้คนมันเลิกซื้อกันแพงๆ แล้วตลาดลดลงมาเอง ผมว่ายากอ่ะ นี่รอกันมาสิบปีแล้วนะ อ่ะ ถ้าคิดว่ารอไปหน่อยจะเกิดขึ้นได้ มันจะ “หยุดเฟ้อ” ก็รอไปครับ ไว้ดูกัน
ผมจำได้ว่าผมบ่นเรื่องนี้ก่อนคบภรรยาอีก แล้วนี่พึ่งฉลองครบรอบสิบปี ดังนั้นบ่นมาเกินสิบปีแน่ๆ
ผมว่าปัญหามันเรื่องการคัดคนมากกว่าอ่ะ คือตราบใดตลาดบนเขาซื้อโรนัลโด้ร้อยล้านแล้วเขาคุ้ม แล้วคุณไม่เข้าใจว่ามันต่างกับคนอื่นยังไง มันก็จะมีคนที่คิดว่าตัวเองควรจะได้เท่านั้นมาสมัครงานเรื่อยๆ แหละ
ผมไม่ตัดสินละกันว่าใครผิดใครถูก ไม่ว่าเราจะบอกว่าโปรแกรมเมอร์ห่วยๆ แม่งโอหัง หรือ บริษัทกากจ่ายไม่ได้บริษัทเก่งๆ เขาให้ได้เยอะ ผมว่าไม่ว่าอันไหนจะจริงจะเท็จ มันไม่ได้นำไปสู่ทางออก คือเราห้ามคนพยายามอัพค่าตัวไม่ได้ แล้วเราก็ห้ามไม่ให้บริษัทพยายามหาคนที่คุ้มไม่ได้
ทางออกสำหรับโปรแกรมเมอร์ผมก็บอกว่าเออทำตัวให้เก่งขึ้นนะ โอกาสจะมามากขึ้น ทางออกสำหรับบริษัทผมก็บอกว่าเข้าใจการ recruit และการบริหารทีมให้มากกว่านี้นะ แล้งจะช่วยได้ แล้วใครคิดว่าเป็นปัญหาก็ดิ้นกันไปตามนี้แหละ
ถ้าโปรแกรมเมอร์คิดว่าเงินเดือนตัวเองเป็นปัญหาแต่ไม่ดิ้นรนเอาแต่เบลมคนอื่นก็จุดจุด ถ้าบริษัทคิดว่าค่าตัวโปรแกรมเมอร์เป็นปัญหาแต่ไม่ดิ้นรนเอาแค่เบลมสภาพตลาดก็จุดจุดพอกันนะผมว่า
(มันง่ายมากเลยนะที่จะมโนว่าคนอื่นแม่งไม่ดิ้นรนมีแต่กูดิ้นรนอยู่คนเดียว ระวังให้ดี)
ผมไม่ได้คิดว่าทุกคนต้องการโปรแกรมเมอร์ขั้นเทพ คำถามแรกๆ เลยนะคือ ต้องการแบบไหน เพราะอะไร (ผมไม่ใช้คำว่าระดับด้วยซ้ำ เพราะโปรแกรมเมอร์มีเก่งหลายแบบ เคยอ่านข่าวโปรแกรมเมอร์ขั้นเทพวงการคริปโต ไปทำงานทวิตเตอร์ ทำงานเป็นเดือนแค่ปรับหน้าต่างใน ui อันนึงยังทำไม่ได้มั้ย นั่นแหละ มันไม่แมตช์ ไม่ใช่ไม่เก่ง)
ถ้าตอบไม่ได้ บอกแค่ว่า “ก็จะเอาแบบที่เก่งๆ อ่ะ ทำ value ให้ได้เยอะๆ อ่ะ มีเงินจ่ายนะ” ผมว่าคุณมีการบ้านต้องทำอีกเยอะครับ
เรื่องนึงที่ผมมั่นใจคือยิ่งนานวัน วงการนี้คนที่ไม่ใช่ของจริงยิ่งอยู่ยาก ทั้งคนที่ไม่ได้มีความสามารถจริงๆ บริษัทที่ไม่ใช่ของจริง แยกคนที่เหมาะกับตัวเองไม่ออก สองกลุ่มนี้อยู่ยากทั้งคู่อ่ะครับ
(สถานะนี้อาจจะทำลายตัวเอง บ่นเฉยๆ)

เปิดรับสมัคร frontend dev แต่คนสมัครมีแต่คนเปลี่ยนสาย ที่จบ bootcamp มา สงสัยว่า bootcamp เขาไม่หางานให้หรอ
หรือว่า........ 🤔

Quote ที่ได้จาก Course System Design วันนี้
*
ถ้าระบบยังไม่ใหญ่พอ คนใช้ยังไม่เยอะ หาเงินได้ยังไม่เยอะ ให้ Monolith ก่อน เพราะ
Overhead ในการ Communication ทีม Latency การเชื่อมต่อระหว่างระบบ Boundary จะน้อย pattern ในการเขียนโค้ดก็จะไม่ต่างกันมาก จะทำงานกันคล่องตัวกว่า
*
จนถึงวันที่ระบบใหญ่มาก ค่อยทำ microservice ขยายทีม ขยายระบบ
*
แต่ก็ไม่ได้มีผิดถูก ถ้าอยาก microservice ตั้งแต่วันแรกก็ต้องแน่ใจว่าทีมดูแลได้ มีประสบการณ์มากพอ ต้นทุนไม่บาน ไม่สวนทางกับรายได้ ที่ตัองจ่ายให้ทีม ให้ hardware software resources ต่างๆ
*
เพราะเมื่อเริ่มทำระบบแยกกัน แค่ A ไป B นั่นหมายความว่าระบบคุณจะมีปัญหาเกิดขึ้นแน่นอน แค่ Integration pattern ก็มีมากกว่า 20 แบบ คุณจะ trade off เลือกวิธีการเชื่อมต่อกันแบบไหน
*
data ระหว่างสองระบบจะมีโอกาสสูญเสีย Consistency มากขึ้น มีระบบ monitoring มั้ย มี Alert Notofication มั้ย ถ้าข้อมูลนั้นสำคัญมาก
*
เช่น ลูกค้าโอนเงินไปอีกระบบ แล้วไปไม่ถึงปลายทาง ต้องเพิ่ม process refund อีกมั้ย
*
วันใดวันนึงไม่ A ก็ B ย่อมเจอปัญหาทำงานผิดพลาดได้เสมอ
นี่แค่ฟังก์ชันเดียว แต่งานจะงอกขึ้นอีกมากมาย ถ้าทีมยังไม่พร้อมขยายเร็วไป ปัญหาก็เพิ่มเร็วตามไปด้วย
*
ไม่ว่าจะเลือกใช้อะไรก็มีข้อดีข้อเสีย เตรียมวิธีรับมือแก้ปัญหาคือสิ่งที่ตัองคิดถึงเพื่อให้แก้ปัญหาที่อยู่ในระดับรุนแรงนั้นได้อย่างทันท่วงที

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

1. ช่วงแรกตอนเป็น Manager Level เก็บ Technical Skills และ Certificated ให้มากที่สุด (มันได้ใช้แน่ๆ เมื่อเติบโต และต้องบริหารทีม ซึ่งจะมีบางกลุ่ม บางคน doubt ในทักษะเราว่าเหมาะสมไหมกับการถูกโปรโมท)

2. เมื่อขึ้นระดับ Director - SEVP ฝึกเรื่องความคิดมากๆ ทั้ง Conceptual/Design/Communication จริงๆเรื่องพวกนี้ หัวหน้าผู้ชายไม่ค่อยสอนหรือแนะนำ ผมโชคดีที่ได้ หัวหน้าผู้หญิง 3 คนแนะนำ แม้วิธีการไม่เหมือนกัน แต่ผลลัพธ์ปลายทางเหมือนกัน ทั้งพี่จุ๋ม สุพัตรา ที่พฤกษา, พี่เปิ้ล พรชนก ที่เซ็นทรัล และคุณ จูดี้ 1 ในผู้ก่อตั้ง อาลีบาบา มีหลักสูตรมากมาย และกระบวนการมากมายให้เราเรียนในด่านนี้

3. ด่านสุดท้ายเมื่อขึ้นสู่ C-Level ฝึกเรื่อง Human Skill มากๆ โดยเฉพาะการบริหารจัดการองค์กร ต้องขอบคุณ ดร.วิรัช รองอธิการบดี ม.ศรีปทุม ตอนนั้นที่บอกให้มาลงเรียน หลักสูตร โทควบเอก ผมก็เลยลงในเอก บริหารองค์กร และทำวิจัยเรื่องการบริหารองค์กร ในธุรกิจการให้บริการด้านดิจิทัล มีหลายทฤษฏีที่นำมาใช้อยู่และได้ผลแบบเห็นชัดขึ้นมาก

และสุดท้าย ในอีกแกน ของความเป็นมนุษย์เงินเดือน ที่ต้องมีไม่ว่าอยู่เลเวลไหน หลักๆมีอยู่ 5 ประเด็นที่ได้จากหัวหน้าผู้ชายซะส่วนมาก

A. ความอ่อนน้อม
B. ความไม่หลงในตำแหน่งหน้าที่ พร้อมจะดันทุกคนให้สูงขึ้น หรือ เก่งเท่าตัวเราเองให้ได้
C. อารมณ์ดี อารมณ์ขัน ได้หมด อย่าเป็นคนอารมณ์เสียง่าย เพราะจะไม่มีใครอยากเข้าใกล้
D. หาความรู้ใส่ตัวตลอดเวลา อะไรที่ไม่รู้แต่คนในทีมรู้ ไม่ว่าเค้าจะอยู่เลเวลไหน อย่าอายที่จะยกมือถาม และขอเวลานัดกันไปให้เค้าถ่ายทอดความรู้ให้ เพราะมันสำคัญกับข้อ 2)
E. ไม่ต้องสร้างภาพอะไรมากมาย ให้เป็นตัวเองให้มากที่สุด แต่ก็อย่าทำให้คนอื่นอึดอัด หรือ ลำบากใจ

ส่วนเรื่อง ethics ก็ไม่มีอะไรมาก ที่ต้องจำไว้ให้ดีคือ สังคมในยุคนี้และ อนาคตมันแคบเพราะ social ที่ต้องละ เลิกให้ได้คือ

- อย่าฉ้อฉล หาประโยชน์จากหน้าที่
- อย่าให้ร้ายใคร อย่าทำร้ายใคร เพราะผลประโยชน์
- อย่ากลับขาวเป็นดำ เพราะเกรงใจใคร
- อย่าเข้าข้างคนของตัวเอง อย่าสร้างพรรคพวกในองค์กร
- อย่าพูดเอาดีเข้าตัว
- อย่าทำอะไรโดยอ้างส่วนรวม แต่ผลพลอยได้เข้าตัวเองมากกว่าส่วนรวม
- อย่าสตอ อย่าประจบ อย่าทำตัวเป็นคนโปรด

สุดท้ายคือ ต้องค่อยฝึกทำให้ได้ทีละนิด และรู้ให้ทันความคิดของเราและคนรอบตัว find out ให้ได้ว่าลึกๆแล้ว ที่เค้าสื่อสารกับเรา เค้าอยากได้อะไรแน่ๆ ให้ชัดๆ

วิศวกรที่แย่ที่สุด
หัวหน้าเก่าผมคนหนึ่งได้เคยบอกไว้ว่า the software engineer is the worst kind of engineer ทั้งๆ ที่เขาทำอาชีพนี้เช่นกัน
เขาพูดอย่างนี้เป็นเพราะอาชีพวิศวกรเป็นอาชีพที่ต้องให้ความสนใจกับทุกสิ่งทุกอย่าง และพยายามสร้างสิ่งที่แข็งแรง ทนทาน ทำให้สิ่งที่ยากเป็นไปได้ ไม่ว่าจะเป็นการออกแบบตึกให้แข็งแรง สร้างเสาเข็มที่รับน้ำหนักได้มาก สร้างบ้าน และอาคารที่ประหยัดพลังงาน ออกแบบเขื่อนที่รับน้ำได้มาก และปลอดภัยเป็นต้น แต่ software engineer ใครก็เป็นได้แล้ว ขอเพียงแค่เขียนโปรแกรมเป็น แต่กลับเขียนโค้ดมีบั๊กเต็มไปหมด ไม่ได้สร้างสิ่งของที่ผู้ใช้ต้องการ รองรับผู้ใช้มากๆ ก็ไม่ได้ นั่นเป็นเพราะต้นทุนความผิดพลาดมันดูเหมือนไม่เยอะ ผิดก็แค่แก้โค้ดเท่านั้นเอง พลาดก็ไม่่ค่อยมีใครตาย จึงเขียนโดยไม่ได้วางแผน ไม่ได้มีการออกแบบโครงสร้างที่ดี ไม่ได้เขียนให้คนอื่นเข้าใจ ไม่ค่อย comment และเขียน documentation
เขายังบอกอีกว่า ถ้าปล่อยให้ software engineer ไปทำงานวิศวกรจริงๆ แล้ว สร้างบ้านบ้านคงออกมาโย้เย้ สร้างสะพานสะพานคงพังตั้งแต่ยังสร้างไม่เสร็จ สร้างเขื่อนน้ำคงรั่วไปหมด ป่านนี้คนในโลกคงจะตายไปเยอะเลย เพราะไม่ค่อยมีคนที่ระมัดระวัง และคิดเยอะพอ
ในขณะเดียวกัน ก่อนหน้านี้ได้มีโอกาสไปฟังผู้บริหารเต่าบินเล่าให้ฟังว่า การออกแบบ hardware นั้นไม่ง่ายเลย ต้นทุนของความผิดพลาดสูงมาก ชิ้นส่วนก็ต้องไปซื้อมาจาก supplier ต่างๆ ผิดพลาดที ก็อาจจะต้องรอชิ้นส่วนเป็นเดือน ชิ้นส่วนมีขนาดไม่เหมาะสมก็ต้องหาชิ้นส่วนใหม่ เพิ่มชิ้นส่วนในพื้นที่จำกัด ก็ต้องมานั่งคิดว่าจะเปลี่ยนกล่อง/ตู้ใหม่ หรือจะรื้อใหม่หมด ทำให้ทำอะไรต้องคิดเยอะ และวางแผนให้ดี
เราจะทำอย่างไร ให้เราเป็น software engineer สมชื่อ engineer กันดีนะ?

(อันนี้อยากแชร์ เพราะจริงๆ ผมว่า Software engineer หลายคนมากที่อึดอัดหรือโมโหกับสิ่งที่เกิดขึ้นในฟิลด์เราหลายๆ เรื่อง เลยมักจะยกว่างานฟิลด์อื่นเขาละเอียดกว่าดีกว่า ซึ่งหลายๆ ครั้งมันเวอร์เกินจริงไปเยอะ หลายๆ คนฝันว่าโลกจริงจะมีงาน Engineer ที่ Very predictable ซึ่งมัน ไม่ใช่ เดี๋ยวผมเสริมความเห็นส่วนตัวทีหลัง)
มันมีคนนึงที่เขาไปทำการสำรวจว่า Traditional Engineering กับ Software Engineering ต่างกันยังไงผ่านการสัมภาษณ์คนที่ย้ายสายงานมาจาก Engineering field อื่นๆ มาทำซอฟต์แวร์
สรุปสั้นๆ คือ Software engineer มักจะ Romanticized งานของ Engineer ทั่วไปเยอะเกินไปมากครับ
ส่วนที่ Software Engineer ควรจะเรียนรู้และพัฒนาจากงาน Engineer สายอื่นได้มีครับ แต่ไม่เยอะเท่าที่หลายๆ คนมองหรือเคลม โดยเฉพาะที่ชาว Software Engineer มองครับ คนที่ย้ายสายจาก Engineer อื่นมาชื่นชม Software Engineering field หลายเรื่องเลยทีเดียว
ลองอ่าน Blog นี้ดู เป็นตอนที่สองของ บทความ The crossover project
https://www.hillelwayne.com/post/we-are-not-special/
อันนึงที่เป็นตัวอย่างง่ายๆ ในบทความเลยคือ ในสายอื่นเวลาเขาคำนวนเขามักจะใช้ Excel share กัน ดังนั้นไม่ต้องพูดถึงเรื่อง Rigourous ในการทำ Version control and change control เราทำได้ดีกว่าเขาหลายเท่า
(คหสต. นี่อาจจะเป็นส่วนนึงทำให้เราสามารถ Change ได้บ่อยกว่าสายอื่นหรือเปล่านะ เลยทำให้ Perception ว่าคนอื่นเขามี Process ชัดเจนมากเลยนะในการแก้อะไรซักอย่าง อาจจะเพราะ Tracking system เขาไม่ดีเท่าไหร่)
หรืออีกอันนึง
One time Carl’s team had to install a screw conveyor in an oil rig, then discovered it was just a couple inches too tall for the room. They couldn’t shrink the equipment, and they couldn’t raise the ceiling, since there were another four floors above it. The team’s solution? Cut a hole in the ceiling, put the equipment in, then put a box around the hole on the next floor so that nobody trips over it. Now that change is permanently part of the rig’s structure, something that has to be accommodated in every future change forever. And that leads to another difference: software engineers can undo their kludges. Trad engineers cannot.
--------------------------------
"Software is More Unpredictable”
*Laughter* -Dawn, Matt, Steve, Mike, Mat, Another Matt
จากที่ผมอ่านบทความนี้มานาน ผมพอสรุปได้ว่าจริงๆ ทุกงาน Engineering มันจะมีส่วนที่เละเทะกับส่วนที่ Rigorous หมดครับ อย่างแบบไอ้ที่ Carl เขาต้องตัดหลุมเพื่อทำ Shortcut ในการสำรวจ ก็คือมันส่วนที่คนในฟิลด์รู้อยู่แล้วว่ามันไม่ได้กระทบ Fundamental จนน่าเกลียด พวกนี้ก็จะเละๆ หน่อย
หรือคนที่ทำ Electrical engineering ก็มีการทำแบบ Spike บนเซอร์กิตเล็กๆ อย่าง Trial and error เพื่อออกแบบ Prototype ก่อน แล้วค่อยมาคำนวนเรื่องสเกล แต่ไอ้เวลาทำ Trial and Error ตอน Prototype เงี้ย บางคนก็ทำเละพอๆ กับที่เราทำเขียนโค้ดลองรันแล้วดูว่าเป็นยังไงนั่นแหละ แล้วมันค่อยมา Rigourous ตอน Prove ว่าสเกลต้นทุนสเกลสิ่งนี้ได้
ถ้ากลับมาฟิลด์ Software Engineering ก็มีส่วนที่ Rigourous มากๆ เหมือนกัน มากจนเรา Take for grant ไปแล้ว อย่างเช่น
- ไม่มีใครบ้าคุยกันบน Network outside of TCP/IP Protocol แล้วซึ่งอันนี้ Proof หนักมาก
- Hashing & Crytographic ก็พิสูจน์กันมาหนักแล้วก็ยังมีการเจาะกันต่อไป จนเราได้ Library สำเร็จรูปที่ใช้ได้ด้วยโค้ดสองสามบรรทัด จริงๆ ภายใต้นั้นมันมี Math ที่ Rigourous มาก
- Hardware driver ที่ใช้คุยกันตั้งแต่ 32-bit, 64-bit ไปจนถึง Apple อันใหม่ นี่ก็ Rigourous มากๆ
สิ่งที่เราโชคดีกว่าคนอื่นคือพอเราทำอะไรที่ Rigourous เสร็จพิสูจน์เสร็จ มันออกมาเป็นสูตรสำเร็จรูปที่ใช้ได้เลย เราสามารถทำ Abstraction ทิ้งได้ ทำให้ในฐานะคนทำงานเราไม่ต้องคิดซ้ำไปซ้ำมาเรื่องเดิมมาก เราเลยได้โฟกัสในส่วนที่ "เละเทะ" ของงาน Engineering ได้เยอะครับ

The reason companies hire so many programmers is all about power. If you have a team of 5 programmers, then those 5 people have huge power over the fortunes of the company, they can just leave and make the enterprise fail, or demand any level of salary. By having large teams, and none of those people responsible for anything more than a small aspect of the whole a company protects itself from having to deal with powerful workers. The workforce can be shed whenever cost cutting is required, no problem, and workers can be disciplined by the fear of being laid off

Little's law + Queueing theory + Theory of Constraints + Reactive Design patterns กันมั้ยครับ

เวลาทำระบบที่มีความซับซ้อนตามเวลา โมเดลเวลาในแบบ functional ก่อน แล้วค่อยคิดเรื่อง state เห็นภาพชัดกว่าพยายามโมเดล state ก่อนเสมอเลยนะ
สมมติเราบอกว่าถ้ามีเอกสาร 3 ชิ้นที่ approved หมด หลังจาก 5 วันที่เอกสารสุดท้าย approved จะต้องส่ง message เตือน มันอาจจะเริ่มดีไซน์ไก้สองแบบ
1. เราเริ่มจากคิดว่าหลังจากเอกสารแต่ละชิ้น approved เราจะสร้าง object/state อะไรมาเก็บเพื่อนับว่ามันครบไม่ครบ แล้วพอได้ object/state นี้แล้วเราค่อยดูต่อว่าส่ง message เตือนได้
2. เราเริ่มจากคิดว่าว่า approved state, approved time , current date time คืออินพุตของฟังก์ชั่นนึงที่รันตลอดเวลาที่จะตัดสินใจว่าจะต้องส่งเตือนวินาทีมั้ย แล้วค่อย simplify input output นี้เป็น intermediate state ในการ optimized
แบบแรกคือคิดแบบ state centric แบบหลังคือ functional centric
แล้วผมว่าระบบซับซ้อนเริ่มโมเดลจากแบบหลังง่ายกว่า มันตรวจว่าระบบถูกต้องไม่ตกหล่นเคสพิเศษได้ง่ายกว่าด้วย

การเรียนรู้ตามปกติมีหลายระดับ ถ้าจะเอาแบบเต็ม spectrum เลยก็ตามรูปข้างล่าง หลายท่านอาจไม่เคยสังเกตว่าการเรียนในแต่ละระดับมีความแตกต่างกันในเรื่องของความเป็นรูปธรรม (concreteness) กับความเป็นนามธรรม (abstract)

ความเป็นรูปธรรมคือ อะไรที่จับต้องได้ เห็นได้จริง การสอนแบบนี้จึงต้องมีเครื่องมือหรืออุปกรณ์ช่วยในการสอนครับ เช่น หากจะสอนการนับให้เด็กอนุบาล ก็อาจต้องมีของเล่นให้นับ เป็นต้น

ส่วนความเป็นนามธรรมคือ อะไรที่จับต้องไม่ได้ ไม่สามารถเห็นได้จริง การสอนแบบนามธรรมจึงเป็นการสอนกระบวนการคิดที่อยู่ในสมองและกระดาษเป็นส่วนใหญ่ เช่น การคิดค้นอัลกอริทึมใหม่ ๆ หรือ การพิสูจน์ทางคณิตศาสตร์ เป็นต้น

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

การเรียนรู้ทั้งสองแบบสำคัญไม่แพ้กันครับ แต่เรามีแนวโน้มที่จะสอนและให้ความสำคัญกับแบบรูปธรรมมากกว่า และละเลยการสอนแบบนามธรรม แต่การคิดแบบนามธรรมทำให้เราสามารถคิดอะไร #จากอากาศ ที่ไม่เคยมีมาก่อนได้ และความรู้ใหม่ที่ได้เหล่านี้ จะเป็นบ่อเกิดของเทคโนโลยีใหม่ที่เปลี่ยนแปลงโลกได้นั่นเองครับ การสอนการคิดแบบนามธรรมจึงเป็นสิ่งสำคัญในยุคปัจจุบัน #my2cents

บ้านเรามัน irony กว่านั้นครับอาจารย์ ....

เราเร่งการเรียนผ่าน abstraction กันเร็วเกินไป จนเราไม่มี grasp หรือ intuition อะไรเลย ว่า abstraction ที่เราเรียนๆ กัน มันคืออะไรในโลกความเป็นจริง

เราเรียนตัวเลข โดยยังไม่ได้เล่นกับจำนวนอย่างมากพอ ว่าตัวเลขเหล่านี้มันมาแทนจำนวนอะไร แล้วทำไมเราถึง reason กับตัวเลขได้ โดยที่จำนวนจริงๆ มันเป็นแบบนั้นจริงๆ

เราเรียนตัวแปร โดยยังไม่ได้เข้าใจสิ่งที่มันมาแทน .... เราเรียน abstraction หลายอย่างมาก โดยที่ไม่มี sense ไม่มี intuition ไม่มี grasp อะไรเลยกับความจริง ....

จนกระทั่งเรารู้สึกว่า เรียนไปทำไม เรียนไปไม่ได้ใช้เลย

ดังนั้น พอเราเรียนระดับสูงๆ .... เราก็เลยกลายเป็นเรียนผ่าน abstraction อะไรไม่ได้เลย .... ต้องมาเรียนอะไรที่เป็น concrete อย่างเดียวหมด ....

irony ดีไหมนะครับ .... เร่งเรียนผ่าน abstraction จนกลายเป็นต้องมาเรียนทุกอย่างเป็น concrete ....

เราไม่เชื่อว่าผู้ใหญ่ไม่มีอะไรจะสอนเด็กรุ่นใหม่นะ คือผมก็ทำงานสอน ไม่ได้รู้สึกว่าตัวเองไม่มีอะไรจะสอน และคนเรียนก็โอเคกับสิ่งที่เราจะสอนเยอะนะ (เปิดรอบทีไรก็เต็มเร็วนะ)
แต่คือการจะสอนอะไรใครมันต้องมีความใส่ใจในบริบทของคนเรียนอ่ะครับ ตั้งแต่ประสบการณ์ที่ต่างกัน บริบทสังคมที่แตกต่างกัน ความพร้อมที่แตกต่างกัน จังหวะเวลาที่แตกต่างกัน
ประสบการณ์ต่างกัน บริบทต่างกัน แปลว่าคุณต้องเข้าใจแก่นของสิ่งที่คุณจะสอน แล้วรับฟังบริบทที่มันเกิดขึ้นที่ต่างไปจากเดิม แล้วปรับให้มันตรงกับปัจจุบัน
สมมติเราอาจจะคุ้นเคยกับการไปสมัครงานแบบต้องเดินไปเจอเจ้านาย แต่สมัยนี้ไม่มีใครทำแบบนั้นแล้วมีแต่ส่งอีเมล์ แก่นคือการแสดงความจริงใจ ตรงนี้สอนกันได้ สอนในแก่นที่ว่าการแสดงความจริงใจมันเวิร์ค แต่จะบอกว่าต้องเดินไปยื่นใบสมัครต่อหน้าบริษัทไปหากล่องยื่นใบสมัครให้เจอก็อาจจะไม่เวิร์ค
นี่คือตัวอย่างการปรับแก่นให้เข้ากับบริบท
ความพร้อมต่างกัน ลองนึกถึงคุณไปสอนแคลคูลัสให้เด็กอนุบาลแล้วพอเขาเรียนไม่เข้าใจไม่ฟังก็บอกว่าเด็กมันสอนไม่ได้…… ใช่เหรอ
จังหวะเวลาต่างกัน ผมเห็นหลายคนชอบมากในการสั่งสอนเวลาที่ตัวเองหงุดหงิด หรืออีกฝั่งหงุดหงิดไม่พอใจ แต่เวลาปกติเวลาที่คนสบายๆ พร้อมจะรับคำสอน ตัวเองมีสติดีที่จะครุ่นคิดวิธีการถ่ายทอด ดันไม่สอน เอ้อ…. เอาสิ การสังเกตจังหวะเวลาที่เราพร้อมจะถ่ายทอด คนพร้อมจะรับ ก็สำคัญ
พูดง่ายๆ นะ ถ้าคุณชุ่ยกับการสอน คนเขาไม่รับก็ไม่แปลกครับ (และไม่ได้แปลว่าถ้าไม่ชุ่ยแล้วเด็กมันจะฟัง แต่แปลว่าถ้าชุ่ยอ่ะโอกาสฟังน้อยมาก)
ไอ้ที่สอนว่าเต้นกินรำกินไม่เวิร์ค ถ้าเข้าใจแก่นว่ามันคือประสบการณ์ของเรา เราเจอคนทึ่ทำแล้วเวิร์คน้อยในยุคเรา เราเลยเห็นว่าโอกาสมันน้อย แล้วรับฟังว่าความน่าจะเป็นในยุคปัจจุบันต่างกันยังไง มันก็สอนกันได้อ่ะครับ
(จริงๆ ยุคนี้จะสอนว่าเรียนปริญญาสูงๆ จะให้ได้งานผมว่ายังต้องอัพเดทตัวเองเลยว่าในอนาคตอาจจะไม่ใช่ เพราะรูปแบบของโอกาสมันต่างจากเดิม แต่แก่นที่ว่าการศึกษากับใบยืนยันบางอย่างช่วยสร้างโอกาสยังจริงอยู่ครับ แค่รูปแบบมันอาจจะต่างจากเดิม)
ฟังดูเหมือนยากมาก จะทำยังไงให้สอนเด็กมันได้วะ ต้องเข้าใจแต่ผมว่านะ หลักๆ คือสอนไปรับฟังไปอ่ะครับ แล้วก็ปรับมาอัพเดทตัวเอง
ไม่ใช่สอนแล้วคาดหวังว่าเขาจะทำตามโดยไม่เถียง
มันสอนยากมากๆ ก็ต่อเมื่อเราพยายามจะรักษาอีโก้ของเราอ่ะครับ
แต่ผมสอนไม่แคร์มากไง เด็กมันย้อนเกล็ด ถ้ามันย้อนแล้วฟังขึ้นก็ดี บอกไป เอ้อ พี่ผิดว่ะ เอ็งเจ๋งดีว่ะ เอ็งอนาคตไกลนะเนี่ยฉลาดเห็นจุดที่พี่พลาดด้วย ดีๆๆๆ
ถ้ามันย้อนแล้วไม่ใช่ ก็บอกไปว่าอะไรที่ไม่ใช่
ถ้าเราวุ่นก็บอกว่าเอ้อพี่ว่าไม่ใช่แต่ยังไม่มีเวลาอธิบายว่ะ แค่นี้เอง
ถ้าสอนแล้วไม่รับ ก็เข้าใจธรรมชาติว่าเวลาอาจจะไม่ถูก เขาพร้อมเขาก็คงจะรับเอง หรือถ้าเขาไม่ได้เกิดมาเพื่อเรียนรู้จากเรา ก็แค่ยอมรับ
ผมว่ามันไม่ยากนะ ถ้าเราไม่ยึดอีโก้เกินไปอ่ะครับ
แต่ถ้าเราพยายามหาว่าสอนยังไงให้ไม่หน้าแตก สอนยังไงให้ไม่โดนเด็กมันย้อนเกล็ดตั้งคำถาม อันนี้อ่ะยาก ผมว่ายากมากๆ ยากสุดๆ ผมก็ไม่มีคำตอบให้
ผมก็หน้าแตกหรือโดนเด็กมันย้อนประจำ (และในทางกลับกัน ที่บอกหน้าแตกบ่อยๆ เงี้ย ผมเปิดคอร์ส ไปทอล์ก จัดมีทอัพอะไรทีไรก็เต็มตลอดนะครับ มีคนชอบมาฟังเราไปย้อนเกล็ดเราไป เอ้ออออ)
แต่นั่นแหละ การไม่ยึดอีโก้ก็ยากครับสำหรับหลายๆ คน ผมก็เช่นกัน

เขาว่าคนแก่มี 2 แบบ
1. แก่เพราะอยู่นาน รู้น้อย อีโก้เยอะ เป็นภาระลูกหลาน
2. แก่เพราะมากประสบการณ์ รู้เยอะ ถ่อมตน ส่งต่อภูมิปัญญาให้ลูกหลาน
เพื่อนๆเจอแบบที่ 1 หรือ 2 เยอะกว่ากัน ? ร่วมแบ่งปันประสบการณ์ได้ครับ
แล้วเราจะทำยังไงให้โตไปเป็นคนแก่แบบที่ 2 หยุดยาวนี้ผมมีโอกาสได้อ่านหนังสือยาวๆ ตกผลึกเกิดไอเดีย คิดว่าน่าจะเป็นประโยชน์เลยนำมาแบ่งปันและมาวิเคราะห์ร่วมกัน
โดยทั่วไป คนเราจะเริ่มเรียนรู้น้อยลง ใช้สมองน้อยลง ในช่วงอายุ 30-40 ปี ผลการทดสอบพวก cognitive abilities, processing speed, memory, ... ก็จะออกมาเริ่มแย่ ที่เขาว่าไม้อ่อนดัดง่าย ไม้แก่ดัดยากก็อาจจะมาจากตรงนี้ด้วย
แต่จากการศึกษาที่สมองทำงานแย่ลง ปัญหามันไม่ได้มาจากวัยที่เพิ่มขึ้นซะทีเดียว ถ้าเรายังอายุไม่เกิน 60 ปี ปัญหาโดยส่วนใหญ่มาจากเพราะหยุดเรียนรู้
ลองมองในภาพนี้ตั้งแต่เด็กจนโต เราถูกบังคับเรียนจนจบปริญญาตรี อายุ 22 เริ่มทำงานเรียนรู้การทำงานในตำแหน่งต่างๆอีก 8 ปี ก็อายุ 30 ปี แต่หลังจากนี้จะไม่มีสภาพแวดล้อมบังคับให้เราต้องเรียนรู้อีกแล้ว หลายคนก็ แช่แข็งความรู้และทักษะไว้แค่ตรงนี้ไปอีก 30 ปี จนอายุ 60 ปี
30 ปีที่ว่างเปล่า + ยุคสมัยที่เปลี่ยนแปลง เรายังกล้าไปสอนลูกหลานได้อีกเหรอ อย่าว่าแต่ลูกหลานเลย ลูกน้องเราก็เอือม ไม่มีคนเก่งที่ไหนอยากทำงานกับหัวหน้า ที่เขาไม่สามารถเรียนรู้อะไรจากหัวหน้าได้เลย แต่แน่นอนว่ามีบางองค์ความรู้ที่ timeless ใช้ได้ทุกยุคทุกสมัยอยู่เหมือนกัน
ยิ่งเราอายุมากขึ้นงานที่เคยทำได้ดี ทำได้เร็ว ก็ยิ่งช้า ยิ่งแย่ขึ้นเรื่อยๆ ไม่ใช่เพราะเราโง่ลงหรืออายุมากขึ้น แต่เพราะเราไม่เคยลับขวานอีกเลยตั้งแต่เราเรียนจบมา
เพราะฉะนั้นถ้าเราอยากโตไปเป็นคนแก่แบบเท่ๆ ก็ลองทำ challenge กับตัวเอง เช่น ต้องเรียนทักษะใหม่ๆ, ทำกิจกรรมใหม่ๆ, งานอดิเรกใหม่ๆ 1-3 ทักษะต่อปี โดยทักษะนั้นจะเป็นอะไรก็ได้ จะเป็นทักษะที่ตรงกับเป้าหมายในชีวิต หรือทักษะที่จะทำให้อาชีพการงานก้าวหน้า หรือทักษะที่เราชอบอยากรู้ เช่น การลงทุน, การเงิน, การตลาด, เขียนโปรแกรม, การบริหาร, การขาย, ภาษาใหม่, ทำอาหาร, ทำขนม, เล่นดนตรี, วาดรูป, งานเขียน, เต้น, ถ่ายรูป, ตีกอล์ฟ, นั้งสมาธิ, เดินป่า, ปีนเขา, ดำน้ำ, ยิงปืน, snowboarding, ski, เดินเรือ, ขับเครื่องบิน, ... เห็นไหมโลกนี้มีอะไรสนุกๆให้เราเรียนรู้และ enjoy อีกเยอะ และจะดีถ้า balance กิจกรรมให้มีทั้งกิจกรรมใช้สมองซีกขวาและกิจกรรมใช้สมองซีกซ้ายให้ balance
3 ทักษะต่อปี 30 ปี ก็ 90 skills แก่แบบเท่ๆ ไป
การเรียนทักษะใหม่ๆ นอกจากเราจะมีทักษะทำสิ่งนั้นเป็นแล้ว
ยังมีประโยชน์กับเราอีกหลายด้าน เช่น
1. Learning is a Key to Happiness
2. Improves your brain health and memory
3. Fosters connection with others
4. Keeps you relevant
ยิ่งรู้เยอะ ยิ่งรู้ว่าโลกกว้างใหญ่แค่ไหน ความอ่อนน้อมถ่อมตนมันจะตามมาเอง เท่าที่เคยเจอคนอีโก้เยอะๆ คือคนรู้น้อย หรือรู้ลึกแค่เรื่องเดียว แต่คิดว่าตัวเองนี้เก่งที่สุดแล้วทุกคนต้องเชื่อกุประมาณนั้น 555+ เพื่อนๆเคยเจอแบบไหนมาบ้าง คิดเห็นอย่างไร ร่วมแบ่งปันกันใน comments ได้เลยครับ

ความเห็นส่วนตัว ที่อาจจะเป็น very unpopular opinion นะ

"ตราบใดก็ตามที่เราไม่ได้เป็นคนที่ต้องลำบากโดยตรงจากการกระทำของเราเอง เราก็ยังคิดว่าที่เราทำมันถูกแล้ว ดีแล้ว และไม่ได้เรียนรู้ที่จะปรับปรุงตัวอะไรทั้งนั้น" (generally speaking นะ)

ยกตัวอย่างโง่ๆ ง่ายๆ หลายๆ ตัวอย่าง:

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

สถาบันการศึกษา เช่น โรงเรียนประถม โรงเรียนมัธยม มหาวิทยาลัย ... ตราบใดก็ตามที่ไม่ได้รับผลกระทบโดยตรงจาก "ความรู้และคุณภาพของคนที่ตัวเองสอน" (ไม่ใช่ความพอใจของคนจ่ายเงิน) ก็ไม่ได้เรียนรู้อะไรมากเท่าไหร่เช่นกัน .... ก็จะสอนยังไงก็ได้ให้คนจ่ายเงินพอใจ แล้วก็ส่งปัญหาต่อๆ ไปให้สถาบันการศึกษาระดับต่อไป หรือคนที่รับเข้าทำงาน แก้ไขปัญหาเอา (คนหางานทำไม่ได้ ก็ "เรียนต่อสิ เราก็มีหลักสูตร" .... ฯลฯ เป็นคำพูดปกติระดับหนึ่งด้วยซ้ำไปนะ มี technical term ว่า "ภาวะตกงานแฝง" ด้วยซ้ำ)

โปรแกรมเมอร์ ที่เขียนโค้ดเฮงซวย ก่อบั๊กก่อปัญหา แต่ไม่ได้เป็นคนต้องแก้งานตัวเอง หรือรับผลอะไรจากการที่ตัวเองทำไว้ มีปัญอะไรก็คนอื่นแก้ (ไม่ว่าจะด้วยเงื่อนไขอะไรก็แล้วแต่) ก็เช่นเดียวกัน เขาก็ไม่ได้เรียนรู้อะไรเท่าไหร่หรอก ก็จะทำแบบที่เคยทำมาต่อไปเรื่อยๆ หลายเรื่องก็ "มันทำง่าย" หรือ "มันทำแบบมักง่ายได้ง่ายๆ" นั่นแหละ

คนออกแบบ product สร้าง product ทำ product อะไรก็แล้วแต่ ที่บอกว่าจะแก้ปัญหานี่นั่นโน่นให้ชาวบ้านชาวช่องเต็มไปหมด ฝันดีอุดมการณ์ดี ... แต่ถามว่าตัวเองล่ะ เป็นผู้ใช้ product ของตัวเองหรือไม่นะ .... ถ้ามันห่วย ตัวเองได้ผลกระทบอะไรบ้าง ..... หลายคนไม่ได้รับผลกระทบอะไรเลย เพราะตัวเองก็ไม่ได้ใช้ ..... ไม่มีการ eat your own dog food อะไรทั้งสิ้น ...

และอื่นๆ อีกมากมาย ........ ขี้เกียจเขียนล่ะ .....

บ่อยครั้งเกินไปที่ผมเจอเรื่องแบบคน คนก่อปัญหาไม่ได้ต้องเป็นคนแก้ ส่วนคนแก้ก็ไม่ได้ก่อ ....

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

ทั้งนี้ต้องบอกก่อนว่า คนที่แก้ปัญหาน่ะ ไม่ใช่ว่าไม่เคยก่อปัญหานะ .... เคยก่อปัญหากันมาทั้งนั้นแหละ ทุกคน .... ก่อเองเจ็บเองแก้เองจนกระทั่งรู้ว่าเรื่องไหนต้องแก้ยังไง หรือทำยังไงไม่ให้มันเกิดปัญหาก็เยอะ ...

โพสท์นี้จะทำลายตัวเองเร็วๆ นี้

สำหรับ developer ทักษะในการถามคำถามให้คนเข้าใจว่าติดตรงไหนและเรื่องที่ติดสำคัญยังไงสำคัญมาก
สำหรับ leader / manager ทักษะในการแกะจากคำถามงงๆ กว้างๆ ไล่ไปจนเข้าใจว่าทีมติดปัญหาตรงไหนสำคัญมาก
ของแบบนี้เป็น two way street และใครทำได้ทั้งสองฝั่ง ทั้งฝั่งพูด/เขียน และฝั่งฟัง/อ่าน นี่คือเก่งจนหายาก (อาจจะคิดว่าเป็นเรื่องง่าย แค่พูดกับฟัง ไม่เลยครับ หายากมากจริงๆ คนที่ทำได้ดีทั้งสองฝั่ง)

โปรแกรมเมอร์หัวโล้นกันเยอะใหม แล้วทำไงไม่ให้หัวโล้น หัวโล้นแล้วลูกน้องเอาไปแอบนินทา ไม่ฟังคำสั่งแก้ปัญหายังไงกันหรอ

เว็บนี้ดูrealดี งั้นขอถามว่า

แนะนำแนวทางอาชีพทีครับ

ผมอยู่ม.ต้น สนใจ programmingและกฏหมาย เลยสนใจทั้งสองอาขีพ ได้ไอเดึยมาจากที่อเมริกา มีคนจบmath physics engineer แล้วต่อlaw school ทำพวกlegal techหรือคดีเฉพาะทาง ปกติวิศวกรเรียนกฏหมายมีมากมาย แต่ผมสงสัยว่าสายคอมกับกฏหมายไปด้วยกันได้ไหม ไม่ค่อยเห็นต้วอย่างเท่าไหร่

อย่างคดีที่ตัวเลขมีผลต่อคดีเช่น
https://redirect.cs.umbc.edu/2011/10/bayes-theorem-found-guilty-by-a-uk-judge/
อนาคตเทคโนโลยีก็จะมีผลต่อกฏหมายแน่นอน จึงสนใจทางนี้ครับ ส่วนตัวชอบทั้งสองอย่างเลย แล้วกำลังฝึกฝนอยู่ด้วย

โรงเรียนผมมีระบบ homeschool คือไม่ต้องมา ทำงานส่ง สอบอย่างเดียว ได้ทั้งเรียน รด gapyear predegree ด้วย ผมน่าจะมาเอาทางนี้แทน ผมจะจบสายวิทย์ จึงสอบได้หลายคณะ หลายมหาวิทยาลัย

ตั้งใจว่าจะเรียน pre degree รามคู่ไปก่อน คิดว่าในระบบไม่ตอบโจทย์ครับ อยากออกมามากกว่า เอาเวลาที่เหลือไปฝึกความสามารถตัวเอง รู้สึกแปลกที่พี่ๆมปลายต้องเรียนในระบบแล้วยังต้องเรียนกวดวิชาเพิ่ม มันทับซ้อนครับ เอาในระบบอออกแล้วมี informal educationเลยดีกว่า มีgap yearด้วย ไปค้นหาตัวเอง ไปใช้ชีวิตด้วยครับ
จากนั้นจากอายุ18ก็สอบเข้าวิศวะคอมตามปกติครับ สอบเนติ สอบตั๋วทนาย คิดว่าวิศวะคอมมาเป็นทนาย รุ่งไหมครับในไทย ปกติไปสายfinancialกัน มาสายนี้น่าจะดี แต่ประสบการณ์ชีวิตผมน้อย แนะนำทีครับ

ถามเสริมครับ สมมติเป็นวิศวะคอมกับทนายแล้ว อยากสอบพวกlicenseทางการเงินไว้เป็นความรู้กับprofileกับเรียนภาษาที่3ด้วยรุ่งไหมครับ ส่วนตัวเล็งฝรั่งเศส เผื่อเรียนต่อทั้งกฏหมายกับวิศวะที่นู่นด้วย จะหาทุนไป ถ้ารุ่งว่างๆจะได้เริ่มฝึก

สรุปจะทำอะไรบ้าง :

ทีละอย่างคือ จบมต้น สมัครราม gapyear ฝึกskillหลักคือกฏหมาย วิศวะคอม มปลาย skillรองคือ ด้านการเงิน ภาษาฝรั่งเศส / สอบวิศวะติด / จบนิติพอดี รอสอบเนติ ตั๋วทนายหรืออัยการ / จบวิศวะ // ตอนจบคือ ได้นิติ วิศวะ สอบเทียบระดับภาษาฝรั่งเศสระดับต่างๆ จบปตรีสอบlicenceการเงินได้ ลงบัญชีได้เพื่อโปรไฟล์ ตามสอบใบcerสายtech ทำงาน ด้วยเวลาที่ผ่านมา โปรไฟล์แตกต่างแต่ตลาดต้องการ หาทุนต่อโทครับ ถ้าใจอยากไปฝรั่งเศสได้ทั้งกฏหมายทั้งวิศวะ นี้ครับ

ควรฝึกอะไรไหมครับ ชอบcybersecurity ctf

>>319 โกน

320 คลิกแล้วติดไวรัส

>>320
กูฝึกcompettive programmingตาม leet code topcodeพอมั้ยวะ แล้วก็โจทย์ olmpiad acm icpc
เวลากูงงๆ ก็ถามในstackoverflow art of problrm solving แม่งมีคนตอบด่วยนะ555
แต่พอกูจะถามแนวทางอาชีพในประเทศ ฝรั่งจะตอบกูยังไงวะ
มีพวกมึงนี่แหละที่จริงใจ

>>320
กูว่าจะเรียนเขียนโปรแกรมที่นี้อะ
https://expert-programming-tutor.com/why_expert_programming_tutor.php
ส่วนเนื้อหาวิชาการ กูขอพี่ๆมาละ กูใช้libgen โหลดเถื่อนหาเล่มที่กูใช้ได้เลย
แล้วกูก็เอาเวลาว่งไปเก็บprofile สอบใบcerเล่นๆ เช่น
https://developers.google.com/community/experts
https://partner.microsoft.com/en-US/
https://productexperts.withgoogle.com/what-it-is
https://grow.google/certificates/
https://www.facebookblueprint.com/student/catalog
https://ywc19.ywc.in.th/
พวกแข่ง hackathon ctf
เป็นเต้น

แล้วกูชื่อยังอยู่ในระบบใช่มะ กูก็ยังสอบ สอวนได้ อยากเป็นผู้แทนศูนย์ เสือกได้ขึ้นมากูเข้าวิศวะจุฬาสบายเลย

ส่วนกฏหมายกูจะมาเรียนที่นี้
https://www.ohmslawtutor.com/?gclid=EAIaIQobChMIyuKNpLuvhgMVkKpmAh1QggluEAAYASAAEgIqYfD_BwE
https://www.facebook.com/AjarnPae/?locale=th_TH
มียันเรียนกูสอบผู้พิพากษาเลย

มึงว่ากูวางแผนชีวิตเป็นยังไงมั้งวะ

>>320
https://casetext.com/cases/1cir/dma/2024/1
กูได้ไอเดียมาจากการอ่านพวกเนี่ย มันจะมีdefendant จบ md มาต่อ jd หรือจบวิศวะมาต่อ lawschool กูที่ชอบเขียนโปรแกรมเป็นเด็กค่ายสอวนคอม เลยสนใจ ดีหวะ มึงจิตนาการว่ากูไปต่อสายfinance กูเจอคนจบ mit sloanมา กูก็ไม่ได้งานละ แต่ถ้ากูมาสายนี้ยังไงก็ได้ ทนายแม่งโง่เลข พวกคอมแม่งไม่มากกฏหมายแน่นอน

อย่างเคสนี้เพื่อพวกมึงเลย
https://app.ediscoveryassistant.com/case_law/24054-u-s-v-wilbert
มันมีพวกชอบเก็บสื่อต่ำกว่า18 ก็cp แล้วแอพพวกนีเมันแจ้ง ncmec ncmecแจ้งfbi fbiไปขอip adress จาก internet provider (ดังนั้น การรู้ip address ipv6ในปัจจุบัน จึงไม่มีใครจะมาบ้านมึงได้ มันต้องไปขอที่อยู่ผู้ให้บริการอินเตอร์เน็ตก่อน) พอมาถึงก็ fbi open upตามmemeอะ โดนจับก็ขึ้นศาล u can contract your lawyer if you dont have we can provide one .u have the right to remain silent what u say can be and will be used against u in the court แล้วส่วนมากที่แม่งตายกันคือไม่ทำตามนี้ มึงมีสิทธิ์เงียบ การเงียบคือให้ค่าเป็นสูญ ไม่ใช่ขัดขืนการจับกุม มีสิทธิ์ให้ทนายมาตอนการสอบสวน
เนี่ย ถ้ากูเป็นทนายสายtech กูแก้ต่างให้ละ การรู้ipv6 คือที่อยู่ทางภูมิศาสตร์ ประเทศไหน ผู้ให้บริการอินเตแร์เน็ตอะไร แล้วก็รหัสเฉพาะของตัวอุปกรณ์ แปลว่าที่มึงมาจับอะ อาจจะเป็นเพื่อนกูที่ใช้ rounterบ้านกูก็ได้นะ แบบเนี่ย
https://www.komchadluek.net/news/crime/529289
https://pantip.com/topic/41746055
ประเทศเราก็มีนะแบบเนี่ย term of serviceมันห้ามอยู่ แถมแจ้งncmec fbi hsi ตำรวจไซเบอร์

ที่เค้าสนใจเพราะรองมาจากการค้ายาเสพติด การค้ามนุษย์คือปัญหาระดับสอง แล้วมันจะมีข่าวการขึ้นระดับความมั่นคงการค้ามนุษย์ในไทยเช่นข่าวนี้
https://www.thairath.co.th/news/crime/2593410
https://mgronline.com/politics/detail/9660000058026
ทำไมบิ๊กโจ๊กลงมาเอง คือยิ่งtierเราดี เรายิ่งส่งออกได้เยอะ นี่คือตัวอย่างhard power

อันนี้แค่ตัวอย่างนึงที่ทำให้กูสนใจทางนี้ พวกสวะสังคม คอลเซนเตอร์จะได้หมดไป
กูสนใจพวก cybersecurity capture the flag ethical hackerด้วย กูรู้กฏหมายละกูเจ๋งแน่นอน

>>325 >>324 >>323 >>320 คนเดียวกันนะ

ขออภัยที่ใช้กูมึง copyมาจากอีกโพสต์ขี้เกียจพิมพ์ใหม่

ตอนแรกว่าจะไม่เขียนถึงบทความที่บอกว่า 268% Higher Failure Rates for Agile Software Project, Study Finds แล้วนะ แต่เห็นแชร์กันแล้วรู้สึกว่าไปผิดที่ผิดทางกันประมาณนึง ทั้งคนเชียร์ Agile และคนไม่ชอบ Agile

คือถ้าไปอ่านงานวิจัยเขาอ่ะครับ เขาเอาว่าถ้าโปรเจกต์มันมี Requirement ในกระดาษชัดเจนแล้ววัดความสำเร็จกันที่ส่งมอบไอ้ที่บอกนั้นได้ตรงเวลา (ไม่ได้สนเรื่อง Satisfaction นะ) Agile จะแย่กว่ามาก ซึ่งผมอ่านดูผมก็คิดนะว่า "ก็แน่อยู่แล้วป่ะวะ"

คือถ้าสมมติคนขอเราสามารถระบุความต้องการได้ชัดเจนเขียนได้ละเอียดเป๊ะๆ แล้วงานทำซอฟต์แวร์แค่ทำตามที่เขียนนะ ไม่มีเข้าใจผิด ไม่มีการเปลี่ยนใจ หรือถ้ามีก็ช่างหัวมัน เข้าใจผิดก็ปัญหาของคนอื่นดันเขียนมาไม่ละเอียดเอง ฉันส่งงานตรงเวลานะห้าห้าห้าด่าไม่ได้นะห้าห้าห้า มันก็ไม่ต้องมีหรอกครับไอ้ที่มานั่งทำ Customer Collaboration, Individual interaction, responding to change ไอ้ที่ทำ Demo ทำประชุม Face-to-face เสียเวลาฟรีหมดเลยครับ
ดังนั้นไอ้ที่งานวิจัยพูดมันก็ถูก แต่มันถูกในบริบทนั้นไง
ที่ Agile เกิดมาแต่แรกเพราะมันก็ลองกันมนานแล้วว่ามันทำได้ยากมากๆ
งานวิจัยที่เขาสรุปเขาบอกว่าให้ใช้ Impact engineering (ที่เขาขาย) ทำ Requirement analysis ให้ดีจะดีกว่า อืมมมมม ถ้าคุณมีปัญญาทำ Requirement analysis ได้ดีขนาดนั้นก็ใช่แหละครับ แต่คุณก็ไม่ได้วัดไอ้วิธีทำ Requirement ของคุณแข่งกับ Agile ไง

คุณวัดแค่ว่า "ถ้าสมมติทำ Requirement analysis ได้เนี๊ยบมากๆ ไม่ต้องใช้ Agile ล้มเหลวง่ายกว่าเยอะ" เอ้อ ก็ถูกและ ถ้ามันทำได้เนี๊ยบก็ไม่ต้องมา Agile กันหรอก เสียเวลา เจอกันอีกทีปีหน้าเลยดีกว่า ถ้า Requirement doc คุณดีขนาดนั้นแล้วละก็นะ
แต่ที่ Agile เกิดมาเพราะพูดตรงๆ นะ คนมันยอมรับ (หรือจะบอกว่ายอมแพ้ก็ได้) กับการหาทางทำ Requirement analysis ให้เนี๊ยบให้นิ่งกันแล้ว เขายอมรับแล้วว่ามันทำไม่ได้ บางโปรเจกต์ผมเห็นตบ Requirement กัน 3 ปีก็ยังไม่เข้าที่เลย ซึ่งสถานการณ์แบบนี้อ่ะเราทำไปให้เขาดูไปแล้วปรับไป แล้ววัดความสำเร็จที่ Satisfaction น่าจะดีกว่าไง
แล้วการทำให้ requirement นิ่งมันยากมากๆ นะถ้าธุรกิจเปลี่ยนไว คือถ้าคุณใช้เวลาเก็บ Requirement 6 เดือนเพื่อเก็บทั้งองค์กร จบเดือน 6 ไอ้สิ่งที่คุณได้วันแรกๆ ก็ล้าสมัยไปหมดแล้วไง ตอนมา Final review เขาก็บอกไม่เอา ปรับมา แล้วก็วน Process เดิมกันไป นี่แหละถึงได้ยืดกันเป็นหลายๆ ปี ได้
แต่ถ้าคิดว่าสามารถทำให้มันนิ่งได้ ก็เอาเลยครับ
แต่สุดท้าย Agile ก็ต้องการ Requirement ที่มีคุณภาพระดับนึงนะ แค่ไม่ได้ต้องมาทีเดียวหมดค่อยเริ่ม แล้วไม่ได้ต้องรีบ Commit กับทั้งหมด ก็แค่นั้นเอง มันถึงได้เน้น Interaction กับ Collaboration
และนี่ไม่ได้จะอวยว่ามันดีกว่าอะไรเลย แต่ต้องเข้าใจก่อนว่า Assumption พื้นฐานของ Agile คือการยอมรับว่าทำให้ Requirement นิ่งเนี่ยมันยาก และถึงจะทำได้ ให้เขาเซ็น Requirement ด้วยเลือดและน้ำตาได้ เราส่งงานไปก็ไม่ได้แปลว่าเขาจะพอใจ

ซึ่งถ้าคุณบอกว่าไม่เป็นไรไม่พอใจก็ช่างมันห้าห้าห้า ส่งตรงเวลาตามที่เขียนนั่นก็คือ "ความสำเร็จ" แล้ว เก็บตังค์ได้แล้ว จะไปอยากเอาอะไรมากกว่านั้น อันนี้ก็ไม่มีอะไรจะต้องมา Agile หรอกครับ ผมว่าคุณไปเน้นเรียนกฎหมายดีกว่าแบบนั้นอ่ะ
ซึ่งอันนี้ผมไม่ได้ต่อว่าหรืออะไรเลยนะ คือถ้าคุณต้องการแค่นั้น ถ้าความสำเร็จของคุณนิยามไว้แบบนั้น คุณต้องการเรียนกฎหมายเพื่อเขียนสัญญาให้ดี นี่พูดจริงๆ คุณก็ต้องเข้าใจว่าเครื่องมือไหนเหมาะไม่เหมาะกับคุณไง ใช้เครื่องมือให้มันถูกครับ
แต่ถ้าคุณเริ่มคิดว่าแบบเอ้อ แค่ส่งงานเก็บตังค์ได้แต่เขาด่ากันทั้งบางมันจะมีผลกับ Reputation ระยะยาวสิวะ ใครจะจ้างเราต่อ ดีไม่ดีเอาเราไปเมาท์กันทั้ง Industry ว่าอย่าจ้างคนนี้ ทำไง อันนี้คุณน่าจะเริ่มมองเห็นแล้วนะว่าทำไมแค่ส่งงานตรงเวลาตามที่เขียนในสัญญาไว้อาจจะไม่พอ
ตรงข้าม Agile โดยพื้นเองใน Manifesto เนี่ย ก็ไม่ได้เน้นแก้ปัญหาเรื่องทำไงให้เราเก็บตังค์ได้คุมสโคปได้ขนาดนั้นหรอกครับ เพราะมันก็อนุมาณประมาณว่าแค่ว่าเอ้อถ้าลูกค้าพอใจเดี๋ยวอะไรๆ ก็ดีเอง ซึ่งก็จริงประมาณนึงแต่ไม่ได้ทั้งหมด เจอคนแย่ๆ มาก็มีปัญหาได้
ผมว่าก็ไม่ได้ต้องอวยมันเกินไปเหมือนกัน มันมีข้อจำกัดและมีจุดประสงค์ของมันเอง
ปล. ไม่ได้บอกว่า waterfall ทำให้ลูกค้าพอใจไม่ได้นะ มันได้ แต่มันไม่ใช่จุดโฟกัสของ waterfall คือเขาอนุมานกันว่าทำงานส่งตรงเวลาตามสโคปที่เขียนไว้ได้ลูกค้าก็จะพอใยเอง ซึ่งจะคิดว่า assumption นี้ใช่หรือไม่ แล้วแต่จะคิดครับ

"When you commit code at 2 AM and the build passes on the first try, you start questioning the very fabric of reality. Is this the Matrix? Am I the Chosen One?"

#มิตรสหายนักพัฒนาซอฟต์แวร์ท่านหนึ่ง

สอน MySQL ให้น้องใหม่ เพราะหลายระบบยังใช้ ให้โจทย์
Insert ข้อมูลในตาราง orders ล้านรายการ
เป็นโจทย์​ที่มักให้คนที่เคยทำงานเสกลใหญ่ทำ
โครงสร้างแบบนี้
CREATE TABLE `orders` (
`order_id` int PRIMARY KEY AUTO_INCREMENT,
`user_id` int NOT NULL,
`order_date` date,
`total_amount` decimal(15,2),
`created_at` timestamp DEFAULT (CURRENT_TIMESTAMP),
`updated_at` timestamp DEFAULT (CURRENT_TIMESTAMP)
);
จากโจทย์นี้ น้องๆได้คิด
1. ใช้ภาษาอะไรดี
2. Mock Data ยังไงดี
พอทำจริง เจอปัญหา
1. เจอ Error Memory Overflow
2. เจอ Process ว่าโหลดนานต้องแบ่งรอบทยอยเอาเข้าทีละชุด
ทำเสร็จให้เอาโค้ดมาพรีเซน
ทำคนทำวิธีคล้ายๆกันคือเขียนวนลูปหมด
ทุกคนใช้เครื่องเสปคเดียวกันคือ Mac Pro M3
- Golang ใช้เวลา 3 นาที
- Python ใช้เวลา 10 นาที
- JavaScript ใช้เวลา 5 นาที
สุดท้ายเฉลยให้น้องดู ผมใช้ JavaScript Nodejs เอาเข้าทีเดียวล้านรายการใช้เวลา 2 วินาที ถ้าเอาเข้าเยอะกว่านี้เจอ Mem Overflow จาก V8 เหมือนกัน
น้องๆว้าวกัน เลยให้วิชาน้องๆเข้าใจธรรมชาติของฐานข้อมูลไปว่ามันเก่งทำงานแบบไหนถึงจะเร็ว ได้วิชาติดตัวกันไป
ให้โจทย์ต่อ
ออกแบบฐานข้อมูลสำหรับโอนเงินข้ามธนาคารมีคิดค่าธรรมเนียม
นั่งถกกันใหญ่

>>332 Sql ตลกดี
order_date ทำไมไม่ใส่ NOT NULL เข้าไปวะ
updated_at น่าจับหยุมหัวใส่ ON UPDATE CURRENT_TIMESTAMP เข้าไปด้วยโว้ย

วันนี้ก็เป็นอีก 1 วัน ที่มีคนถามว่า Coraline เป็น Startup หรือเปล่า???
ไม่ใช่ค่ะ Coraline ไม่ใช่ Startup แป้งไม่เคยเรียกตัวเองว่า Startup เลยค่ะ และไม่ได้เข้าร่วมโครงการต่างๆ ที่เกี่ยวกับ Startup
เพราะแป้งศึกษา Definition แล้วรู้สึกว่า บริการของ Coraline มันไม่ตรงกับการเป็น Startup และไม่ได้ Focus เรื่องการระดมทุนค่ะ แต่ยอมรับว่า Goal ของแป้งคือการ IPO เพราะแป้งต้องการสร้างองค์กรที่ยั่งยืน
จุดอ่อนตอนก่อตั้ง Coraline ก็คือทีม เพราะ Coraline มีแป้งเป็นแกนหลัก ทุกวันนี้แป้งก็ยังคงเป็น Everything ของ Coraline แต่มีทีมงานที่แข็งแกร่งมากขึ้น ผ่านช่วงของการสร้างทีมมาแล้ว ตอนนี้เรื่องทีมงานไม่เป็นปัญหาของเรา แต่ที่ยังคงเป็น Everything เพราะพยายามอยู่ใน Loop ตลอด เมื่อใดที่เกิดปัญหาจะได้ปิดได้ทัน
เพราะเราไม่ได้มี Budget ให้ Burn เราจึงพลาดได้น้อยมากๆ ค่ะ และก็เคยพลาดมาแล้ว กว่าจะกู้คืนได้เรียกว่าสาหัส แต่เป็นประสบการณ์ที่ดีมาก แป้งขอบคุณเหตุการณ์นั้นเลย
ถ้าไม่ใช่ Startup แล้ว "เงินทุน" จะมาจากไหน

แรกเริ่มเลย ก็คือ เงินของตัวเองค่ะ ไม่เยอะมากหรอกเอาตรงๆ แล้วก็รีบหารายได้ให้ได้มากที่สุด เป้าหมายคือ ทำกำไรให้ได้ใน 5 ปี ซึ่งระหว่างทางก็จะมีนักลงทุนเข้ามาคุยด้วยอยู่เรื่อยๆ ทั้ง CV และ Angle โดยที่เราไม่ได้เข้าร่วมโครงการอะไรเลยนะ นักลงทุนเขาจะหาเราจนเจอค่ะ
แป้งมีนักลงทุนที่เข้าใจ และให้โอกาสค่ะ โดยที่เขาไม่ได้เข้ามาตรวจสอบอะไรเท่าไหร่ ซึ่งในฐานะที่เคยเป็นคนถูกยืมเงิน เข้าใจหัวอกนะ คนถูกยืมเงินก็อยากได้เงินคืนใช่มั้ยละ แป้งจึงตั้งเป้าเลยว่า จะต้อง Return คืนให้นักลงทุนให้ได้ ต้องไม่นานเกินไปด้วย เพื่อตอบแทนบุญคุณของเขา ที่เห็นค่าของเรา ทั้งๆ ที่ยังไม่ได้น่าสนใจอะไรด้วยซ้ำไป
พอผ่าน 5 ปี งบการเงินก็เริ่มเป็นบวก ทำให้สามารถคุยกันสถาบันการเงินได้ ก็เข้าโปรแกรม Finance กันไปตามหลักการ SME ปิดโครงการมาก็เอาเข้า Leasing หมุนเงินตามวัฏจักรของธุรกิจ
ตลอดเวลาที่ผ่านมา เราจะมีอะไรใหม่ๆ ออกสู่ตลาดทุกปี ตอนแรกทำแค่ Data Analytics เราก็ต่อยอดมา Data Management จนกระทั่งมี Data Governance ที่มี ​Template ของตัวเอง
ปีนี้ อยากให้จับตามอง Coraline นะคะ เรากำลังจะปล่อย Product ที่เป็น Subscription Model ครั้งแรกค่ะ เปิดตัวสิงหาคมนี้ แน่นอนว่าเกี่ยวกับ Generative AI ด้วย ซึ่งตอนนี้มีลูกค้าใช้งานแล้วค่ะ เพียงแต่ยังอยู่ใน Phase แรก รอให้ทุกอย่างนิ่ง จะเปิดตัวใหญ่แน่นอนค่ะ
Goal ของแป้งไม่เคยเปลี่ยนไป แป้งต้องการเป็น "บริษัทคนไทย ที่คนไทยต้องภูมิใจ" Coraline จะเป็นสถานที่ปล่อยของ ของนักพัฒนา Product นี้เป็น Product แรก และปีต่อๆ ไป เราก็จะศึกษาตลาดเพื่อออก Product อื่นๆ เรื่อยๆ
Direction ของแป้งเป็นแบบนี้ตั้งแต่ Day 1 นะคะ ไม่เคยเปลี่ยนเลย และที่บอกว่าไม่ใช่ Startup เพราะเราไม่ได้อยากมี Product เดียวที่เป็น SuperApp ค่ะ แป้งอยากทำหลากหลาย ทั้ง Consult, Implementation และพัฒนา Product สุดท้ายแล้วเราก็จะเป็นบริษัทเทคโนโลยี ที่ทุกคนจะเชื่อมั่นในฝีมือให้ได้ค่ะ
บางที การที่เราไม่ได้ระดมทุน มันก็เป็นข้อดีนะคะ เพราะเราระมัดระวังในการวางแผน โดยเฉพาะเรื่องการเงินมากๆ และการที่เราค่อยๆ โต มันก็ทำให้ทุกก้าวย่างมั่นคง แม้วันนี้จะยังไม่ถึง Goal ที่วางเอาไว้ แต่กราฟของเราก็พุ่งทยานขึ้นทุกๆ ปีค่ะ 🙂
สุดท้ายนี้ ขอบคุณผู้ถือหุ้นทุกท่าน แป้งรู้ว่าแป้งช้า แป้งรู้ว่าแป้งอาจจะทำให้พวกท่านผิดหวังในบางครา แต่สุดท้ายแล้ว แป้งจะทำทุกวิถีทาง เพื่อจะตอบแทนความเชื่อมั่นของทุกท่านให้ได้ค่ะ

ที่ #ไทยแลนด์

เราเรียนการประยุกต์ใช้ neural network และ machine learning

เราเรียนการประยุกต์ใช้ high performance computing

เราเรียนการประยุกต์ใช้ fiber optics

ส่วนที่ #ประเทศที่เป็นผู้นำทางเทคโนโลยี

เขาเรียนเพื่อหาข้อจำกัด (limitation) ของ neural network และ machine learning

เขาเรียนเพื่อหาข้อจำกัด (limitation) ของ high performance computing

เขาเรียนเพื่อหาข้อจำกัด (limitation) ของ fiber optics

เขารู้ข้อจำกัด เขาจึงสามารถคิดองค์ความรู้ใหม่สร้างเทคโนโลยีใหม่ ๆ ได้ครับผม

#my2cents

abcdefg

ccccccc

>>336 มีเหตุผล กุอยากเป็นอมตะ เราต้องชนะlimitของตัวเอง

กุเห็นคนขายคอร์ส ราคา 4-5000
เนื้อหาแม่งหาได้ตาม youtube ตามเน็ตเยอะแยะ

คอร์สพวกนี้มันเหมาะกับคนที่ไม่มีพื้นฐานเหรอวะ

>>340 มันเป็นคอสจำหรับคนที่ดู yt แล้วไม่รู้เรื่อง หรือไม่มีวินัยน่ะ หรือไม่คล่องอิงค์น่ะ ราคาแบบนี้เพราะคนเรียนมีไม่กี่คน

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

"nyaaa big news! >///< I started working at Crowdstrike! It was my first day yesterday and I pushed a really cool feature last night :3 I hope I impress the PM >///<"

#มิตรสหายนักพัฒนาซอฟต์แวร์ท่านหนึ่ง

ดันมู้

"feeling cute, might post some api secrets to onlyfans later"

#มิตรสหายนักพัฒนาซอฟต์แวร์ท่านหนึ่ง

เป็น 1 ใน 100 คน ที่เข้าไปฟังใน Zoom ของพี่รูฟ Twin Panitsombat ได้ทัน เลยอยากแชร์ความเห็นส่วนตัว
.
"การ WFH เหมาะกับพนักงานที่มีสกิลถึง และ ความพร้อมของบริษัท ด้วยเช่นกัน"
.
บริษัทมีนโยบาย WFH เพรา สามารถเพิ่ม Productivity หรือ ทำให้เท่าเดิมได้ โดยพนักงานไม่เสียเวลาเดินทางเข้ามาที่ออฟฟิส รวมถึงมีเวลาส่วนตัวมากขึ้น
.
แต่หากการ WFH แล้วทำให้ Productivity ลดลง ก็ไม่แปลกที่บริษัทจะให้กลับมาทำงานที่ออฟฟิส
.
ซึ่งเหตุผลส่วนมากที่ Productivity ลด เพราะ ตัวพนักงานสกิลไม่ถึง หรือ ไม่มีวินัยในตัวเองมากพอที่จะสามารถ WFH ได้ ซึ่งผมเห็นแอบเห็นด้วยกับประโยคที่ว่า "เราควรทำงานที่ออฟฟิสได้ดีก่อน ก่อนจะไป WFH เพราะ ถ้าหากเจอกันทุกวัน เห็นหน้าตลอด ยังทำงานและสื่อสารได้ไม่ดี การ WFH มีแต่จะทำให้ได้ผลลัพธ์ที่แย่ลง"
.
แต่ก็ไม่สามารถโทษตัวพนักงานอย่างเดียว เนื่องจากมีปัจจัยอื่นอีก เช่น ความพร้อมของระบบการทำงาน, รูปแบบการบริหารทีม, บริษัทมีจำนวน senior ไม่มากพอในการบริหารทีมแบบ Remote, Onboarding program ไม่ได้ถูกออกแบบสำหรับ Remote“
.
เลยอยากเขียนคำแนะนำให้น้องจบใหม่ ไม่อยากให้เลือกงานที่เน้น Remote เป็นหลัก แต่อยากให้เน้นงานที่้ให้เราได้เรียนรู้ดีที่สุด ซึ่งหากจะเลือกงาน Remote ก็ต้องมั่นใจว่าบริษัทนั้น มีความสามารถสอนงานแบบ Remote ได้ดีพอ เช่น ลองถามพนักงาน , ถาม Tools และ Process ที่ใช้ทำงาน
.
สุดท้ายสิ่งที่อยากบอก คือ
“งานที่แรกสำคัญมากๆ ให้เลือกงานที่ทำให้เราเรียนรู้ได้มากที่สุด จะเป็น Remote หรือ Onsite ก็ได้”

>>346 พี่รูฟ mentioned
👍👍👍

ไม่ชอบเลยเวลามีคนบอกว่าภาษาโปรแกรมกับการเขียนโค้ดไม่สำคัญแล้วในยุคนี้ เราเคยตั้งคำถามกับความเชื่อของคนสร้างภาษากันบ้างมั้ย ทำไมต้องมีหลายภาษา
ลองนึกถึงคนที่มีเลนส์เดียวในการมองโลก คนที่ใช้ศิลปะมองทุกอย่าง ใช้คณิตศาสตร์มองทุกอย่าง ใช้การเมืองมองทุกอย่าง เวลาที่ mental model นั้นมันไม่เวริคก็ยังดื้อมองทุกอย่างเป็นตะปู เอาค้อนทุบปัง คนนี้จะมองโลกยังไง
มีอะไรใต้ภูเขาน้ำแข็งของการสร้างภาษาที่ลึกกว่า syntax เป็นล้านอย่าง มี design decisions, paradigms, trade-offs ที่เค้าเชื่อว่ามันเหมาะกับบริบทงานและประสบการณ์ชีวิตของเค้ามากที่สุด ถ้าเค้าเลือกได้ไม่กี่อย่างเค้าจะโฟกัสอะไร
แต่พอคนมองว่า languages มันไม่สำคัญ เราก็จะลองอยู่ไม่กี่ภาษา เราไม่ยอมลอง clojure, haskell, scala, rust, erlang, elixir, ruby, racket แค่เพราะมองว่าที่บริษัทเราไม่ใช้ หรือหางานไม่ได้
หรือถึงเราลอง เราก็ไม่เปิดใจต่อ paradigm และความเชื่อของผู้สร้างภาษา เราก็จะเขียน rust แบบเขียน c, เขียน c แบบเขียน rust, เขียน go แบบเขียน scala, เขียน scala แบบเขียน go เพราะเรามองว่าวิธีคิดที่เรามีมันเพียงพอแล้ว
คือเวลามีคนบอกว่าเลิกสนใจโค้ด เลิกสอนโค้ด ให้ AI เจน เอาเวลาไปใช้ AI หรือแม้แต่เอาเวลาไปเรียนคณิตศาสตร์ เรียนอัลกอริทึมก็เถอะ เราว่าแม่ง reductive เกินไปจนคนเชื่อกันไปแล้วว่าไม่สำคัญ
กลับไปที่เรื่องเลนส์ในการมองโลก ทำไมในโรงเรียนเราไม่สอนวิชาเดียว สอนวิทยาศาสตร์อย่างเดียวพอ สอนศาสนาวิชาเดียวพอ สอนภาษาโปรแกรมเดียว ใช้ Python กับทุกงาน ใช้ Rust กับทุกงานอ่ะ จะโลกแคบกันเกินไปมั้ย
เวลาเราเรียน paradigm หรือ concept ใหม่ เรามั่นใจได้แค่ไหนวะว่า OOP in the context of Java มันมีส่วนไหนที่เป็น heart of OOP และส่วนไหนที่เป็น Java-specific details ถ้าเรารู้จัก Java แค่ภาษาเดียว
ภาษามันมีประวัติศาสตร์ ประวัติศาสตร์ไม่ได้สวยงามตลอด มีการฆ่าฟัน มีการล้างเผ่าพันธุ์ ภาษาโปรแกรมก็มี bad decisions มีการตัดสินใจในบริบทของคอมพิวเตอร์ในยุคนั้น ความสามารถของคอมพิวเตอร์ในยุคนั้น มันมี context
แต่ถ้าเราเขียนภาษาเดียว ยังไม่เคยเห็นตัวอย่างและบริบทที่มากและหลายหลายพอ เราจะรู้มั้ยว่าอะไรคือดีไม่ดี เราจะรู้มั้ยว่าแสงสว่างคืออะไรถ้าไม่เคยเห็นความมืด แต่ละภาษามันมีสิ่งที่ทำได้ดีและทำได้แย่เสมอ
เหมือนการมีคนเป็นไอดอลนี่แหละ เราก็มีหลายคนที่เราเคารพ แต่ทุกคนก็จะมีส่วนที่เราชอบเกี่ยวกับตัวเค้า และส่วนที่เราไม่ชอบ เราก็หยิบมาแค่อะไรที่เราชอบ
เราชอบฟังทอล์คของคนสร้างภาษามาก แบบทอล์คของ Rich Hickey, Martin Odersky มันชวนให้เราตั้งคำถามกับความเชื่อเค้า มัน apply ทุกบริบทมั้ย มีอะไรที่เราคิดว่าเวริคและไม่เวริค อะไรคือมุมมองต่อโลก
มันมีอะไรที่ยังอยู่ใน active theoretical research เยอะมาก มีความเป็นไปได้อีกเยอะ เช่นภาษา bend ที่ใช้ interaction nets & interaction combiners ที่มีมาตั้งแต่ปี 1970 แล้ว แต่เราเพิ่งเอาไอเดียนี้มาสร้างภาษาที่รันแบบ massively parallel บน GPU หมื่นกว่าคอร์ให้มันคำนวณพร้อมกันโดยธรรมชาติได้
แต่ถ้ายังมัวพูดกันว่า AI มาแล้ว เลิกสนใจการเขียนโค้ดได้แล้ว แปลว่ามันก็ถูกแช่แข็งทางวัฒนธรรมไป ไม่ต้องมีการพัฒนาอะไรต่อ วิธีคิดของเราก็ถูกแช่แข็งตามเลนส์ในการมองโลก มองซอฟต์แวร์เดิมๆ ต่อไป
น่าเศร้านะ พออะไรใหม่ๆ มา เราชอบ hype แล้วทิ้งของเดิมเพราะเรามองว่ามันไม่สำคัญมันมี ทั้งๆ ที่เรายังเรียนรู้อะไรจากมันได้เยอะ

เรามองว่ามันเป็น ผู้ช่วย ยังไงถ้าเราใช้งานมันเป็น มันก็คือ Co-pilot ช่วยทำให้งานง่ายขึ้น ไม่ได้มาเป็น กัปตันเองอยู่ดี เราแค่รู้ว่าต้องสั่งให้มันทำงานยังไง ช่วบเรายังไง ถ้าไม่เข้าใจโปรแกรม ก็อปแปะอย่างเดียว ทำงานช้าแน่นอน

เรื่องนึงที่พูดถึงในคลาสที่แล้วคือ คนเราหลายๆ ทีจะสับสนระหว่างการ “มีอำนาจ“ และการ “มีความสามารถในการควบคุมได้”
หรือภาษาอังกฤษคือ authority does not imply control.
เวลาที่เรา lead บนตำแหน่ง แน่นอนเรามีอำนาจในทีม เราอาจจะสามารถตั้งกฎหลายๆ อย่าง เราอาจจะเดินไปบอกให้ใครต่อใครต้องทำอะไร ต้องเป็นยังไง เรามี authority แน่ๆ
แต่สุดท้าย เราควบคุมใครไม่ได้เลย นั่นคือจริงๆ เราไม่เคยมี control เราทำได้มากสุดก็แค่ตั้ง consequence บางอย่าง แต่ถามว่าเราควบคุมใครได้มั้ย ไม่ได้เลย
ที่เขาทำตามเราคือเขา ”ยินยอม“ นะ อย่าสับสนว่าเราควบคุมคนอื่นได้
เราทำได้มากสุดคือใช้อำนาจที่มี รวมกับความสามารถในการคุมร่างกายตัวเอง พาเอาร่างกายตัวเองไปพูด ไปเคลื่อนไหว ไปกระทำการใดๆ แล้วหวังว่าคำพูดและความเคลื่อนไหวนั้นจะทำให้คนในทีมเรา ”ยินยอม“
เราควบคุมได้มากสุดแค่นั้นแต่เริ่มแล้ว ไม่เคยควบคุมอะไรได้มากกว่านั้น
(มีหลายคนบ่นว่าเด็กสมัยนี้คุมไม่ได้ ผมจะบอกว่าคุณไม่เคยคุมอะไรได้แต่ต้น ทุกยุคทุกสมัยอยู่แล้วแหละ คุณแค่เข้าใจผิด)
ทีนี้ถ้าเราตระหนักรู้ได้ว่าจริงๆ เราควบคุมใครไม่ได้เลย มันเปิดโอกาสให้เราเรียนรู้ตามความเป็นจริงครับ
มันเปิดโอกาสให้เราเรียนรู้กลไกที่จะทำให้มีโอกาสที่จะควบคุมในสิ่งที่เราควบคุมได้คือตัวเอง ไปทำในสิ่งที่เพิ่มโอกาสที่คนจะ ”ยินยอม“ ตามเรามากขึ้น โดยไม่สับสนว่าเราจะต้องควบคุมอะไรได้
เพราะเราควบคุมไม่ได้อยู่แล้วเว้ย
และเมื่อเข้าใจตามความเป็นจริงแล้ว มันจะไม่ฝืน
การ ”ควบคุม“ มันต้องเป็นดั่งใจหวัง แกต้องตามฉัน
การ ”ไม่ควบคุม“ แต่ให้ยินยอม เรารู้ตลอดว่าคนยอมตามคำพูด กฎ policy ต่างๆ จากอะไร เราใช้ต้นทุนตรงไหนอยู่
แล้วเมื่อเราเข้าใจต้นทุนที่เราใช้ เราก็บริหารได้ง่ายขึ้น
เรา appreciate เวลาคนมีศรัทธากับเราได้มากขึ้น
เวลาเราสั่งหรือฟาดใคร เราก็เข้าใจว่าเราจ่ายอะไรลงไปมากขึ้น
เราเข้าใจและทำใจว่า action ที่จะทำให้เกิดการ “ยินยอม” มันเปลี่ยนตามยุคสมัยมากขึ้น
ซึ่งมันต่างจากมุมมองแบบที่ว่าเราต้อง ”ควบคุมได้“ ไปเยอะมากครับ คนละเรื่องกันเลย
ถ้าเราเข้าใจว่าคำว่า “อำนาจ” มันมีพลังแค่ไหน ไม่มากเกินที่มันเป็น ไม่น้อยกว่าที่มันเป็น เราก็จะไม่หลงไปกับอำนาจครับ

วันก่อนฟังวิทยากรในงาน Ignite Thailand’s Brainpower ที่จัดขึ้นโดย #บพค. และกระทรวงอุดมศึกษา ฯ มีเรื่องจริงที่เล่าสู่กันฟังบนเวที คือ มีธนาคารแห่งหนึ่งในประเทศญี่ปุ่นต้องการจะหาบริษัทไทยที่สามารถรับงานทางด้าน semiconductor มาทำให้เขาได้ โดยบริษัทนี้จะต้องมีคนที่มีความรู้ทางด้านนี้ในหลักพันคนขึ้นไป เชื่อไหมครับว่า เราไม่มีบริษัทลักษณะนี้ในประเทศแม้แต่บริษัทเดียว

แน่นอนครับ เขาก็ไปหาบริษัทอื่นที่ประเทศคู่แข่งของเราแทน

ระบบการศึกษาบ้านเราต้องเรียกว่าเป็นระบบการศึกษาที่มองการณ์ไกลไม่เกิน 4 ปีครับ จะตอบสนองกับเหตุการณ์ที่เกิดขึ้นในระยะเวลาของรัฐบาลหนึ่งรัฐบาลใดเท่านั้น

ในขณะที่โลกเปลี่ยนแปลงเร็วขึ้นอย่างมาก เพราะเทคโนโลยีใหม่ ความรู้ใหม่ ที่เกิดขึ้นทั่วโลกแทบจะทุกวัน เรากลับแก้ปัญหาแบบเฉพาะหน้าไปวัน ๆ ไม่มีการวางแผนระยะยาว ให้ทันต่อสถานการณ์ที่อาจเกิดขึ้นในอนาคต

ผมจึงไม่แปลกใจครับที่เราไม่มีบริษัทที่มีคนทาง superconductors ในจำนวนที่เพียงพอเลย แม้แต่บริษัทเดียว เอาเข้าจริง กำลังคนขั้นสูงทางด้านอื่น ๆ เช่น AI IoT EV และ quantum computing ก็น่าจะตกอยู่ในสถานะการณ์คล้าย ๆ กันครับ #my2cents

Straight person: I’m straight
Gay person: I’m gay
Transgender person: I’m trans
Java developer: AbstractSexualityServiceBuilderFactory

#มิตรสหายนักพัฒนาซอฟต์แวร์ท่านหนึ่ง

>>352 cringe

>>351 เริ่มจากให้เด็กๆทำวงจรในมายคราฟก่อนได้ไหม

หลังจากไม่ได้ตาม React มานาน พึ่งเห็น Drama React 19 แล้วคิดว่าถ้า React core team ยังพยายามฝืนผลัก render-as-you-fetch paradigm ให้คนใช้ทำโดยบอกว่า “นี่มันดีกว่า” คิดว่า React ไม่ค่อยน่าใช้แล้วอ่ะ

คือเข้าใจแหละว่าการคิดหา data requirement ของแต่ละคอมโพเนนท์ก่อนแล้ว preload มาอ่ะมันดีที่สุดอยู่แล้วเว้ย แต่… ถัามันทำได้ง่ายนะเราคงไม่ต้องมาไกล มีReact Query และอื่นๆ กันยังงี้หรอก

ที่มันยากคือทำให้การประสานงานกันยากด้วย คือหลังจากนี้มี component นึง ก่อนใช้ก็ต้องมานั่งคิดว่าเอ้อเอาไปวางตรงนี้ใน app lifecycle เรามีข้อมูลยัง ยังงี้เหรอ โอ้ย ในแอพใหญ่ใครจะไปจำได้หมด หรือถ้า simplify structureให้เหลือไม่กี่ data life cycle ให้ทุกคนจำได้หมด ก็ over or under fetching แน่ๆ

สุดท้ายจำได้สมัยก่อนตอนเขียน React ใหม่ๆ 4-5 ปีก่อน ก็ผลักให้ state management lib จัดการให้ (Redux, Mobx) และถ้ายังฝืนไปต่อ สงสัยคนส่วนมากจะได้กลับไปท่าเดิม

อันนี้ดี เหตุผลว่าทำไมเราควรออกแบบ code ให้ greppable 🙂 มันค่อนข้าง underrate มากๆ และคนส่วนใหญ่พยายามจะทำให้ code DRY ที่สุดเท่าที่ทำได้ ซึ่งบางที DRY มาก ๆ มันไม่ได้ทำให้ maintain ง่ายเลยนะ

การตั้งชื่อตัวแปร การตั้งชื่อไฟล์ การวาง folder ขอให้คิดเผื่อว่าเอ้ะ จะมีคน search สิ่งนี้ไหมนะ จะมีคน run `$ tree | grep abc` ไหมนะ และอื่น ๆ อีกมากมาย

https://m.facebook.com/story.php?story_fbid=9029997357016448&id=100000188216896

ผมเคยสอนในคลาส tech leadership ว่าต่อให้เรามองคนในทีมเป็นเครื่องมือสำเร็จเป้า เราก็ต้องเข้าใจวิธีการดูแลเครื่องมือนั้นอยู่ดี
ลองนึกว่าถ้าเรามีรถคันนึงแล้วเหยียบคันเร่งจนเครื่องระเบิด เครื่องดับ แล้วเราไม่เข้าใจไอ้ไฟเขียวๆ แดงๆ ที่ขึ้นบนคอนโซลเลยว่ารถพังตรงไหน ไม่รู้ เหยียบต่อแม่ง
ผมว่าเราเป็นผู้ใช้เครื่องมือที่เรียกว่า “รถ” ที่กากมากนะครับ
ถ้าเรามีเครื่องจักรอุตสาหกรรมชิ้นนึง แล้วเราไม่รู้เลยว่าต้องหยอดน้ำมันหล่อลื่นเมื่อไหร่ เปิดเครื่องได้นานกี่ชั่วโมง แล้วกดซะจน overheat พังในสองเดือนแรก ทั้งๆ ที่อายุการใช้งานจริง 5 ปี
ผมว่าเราเป็นผู้ใช้เครื่องมือที่เรียกว่า “เครื่องจักร” ที่กากมากเลยนะครับ
จะใช้คนเป็นเครื่องมือไปสู่ความสำเร็จ ก็ช่วยใช้ให้เป็นหน่อยอ่ะครับ
อย่าเป็นผู้ใช้เครื่องมือที่ห่วย ใช้เป็นแต่เหยียบใช้แล้วพัง แล้วก็ต้องมาพรีเทนด์ว่าฉันไม่แคร์ พังก็ซื้อใหม่ได้ (เอ้อ ไม่เปลืองเนาะ หาคนใหม่ง่ายเนาะ) งี้เหรอครับ
ผมว่าไม่เวิร์คนะครับ หรือถ้ามันจะพอเวิร์คมันก็เวิร์ค despite of ความห่วยในการใช้งานของคุณอ่ะครับ

>>357 พังก็หาใหม่ครับ

วันก่อนคุยกับเพื่อนคนหนึ่ง เรื่องธุรกิจแบบ MLM จริงๆ vs แบบแชร์ลูกโซ่ ... ว่ามันต่างกันตรงไหน
ผมบอกไปว่า มันมี indicator อยู่ตัวนึง ที่ผมคิดว่าใช้ได้ดีมากๆ คือ สังเกตว่าคนที่ชวนเรา เขา "อวดอะไร" ....
ถ้าเขาอวด product เขาอวดชีวิตที่ดีขึ้น "จากการใช้ product" โดยไม่พูดถึงความร่ำรวย และอยากให้เราใช้ product บ้าง โดยไม่ต้องเยอะ ใช้ตามที่เราจำเป็น หรือตาม burn rate ของการใช้งานปกติ .... เวลาที่เขาโพสท์ใน FB เขาก็โพสท์แต่ product เป็นหลัก ....
อันนี้ MLM ..... แบบนี้ถ้าเราไปลองใช้ และอยากขายบ้าง ก็ว่ากันไป
แต่ถ้าเขาอวดความร่ำรวย อวดชีวิตที่สุขสบาย จากการที่เขาขาย product และพยายามชักชวนให้เราขายแบบเขา จะได้รวยแบบเขา
อันนี้แปะโป้งไว้หนักๆ เลย
=============
คนใกล้ตัวผมหลายคนมากพอ ที่เห็นชีวิตคนอื่นร่ำรวย บางคนโพสท์ story ขายนั่นนี่แล้วซื้อบ้านหลายสิบล้านให้แม่ได้ในกี่ปี มีชีวิตดีพาลูกเที่ยวต่างประเทศบ่อยๆ … มีรถหรู ... ไม่ต้องถึงขนาด exotic นะ เอาแค่ Benz, BMW นี่แหละ ตัวท็อปๆ หน่อย แล้วก็ Alphard ให้แม่ให้ครอบครัวนั่งสบาย พาครอบครัวไปเที่ยวนั่นเที่ยวนี่สบายทั้งครอบครัว .... แล้วต่อมลูกกตัญญู ต่อมพ่อแม่ที่ดี ทำงานหนัก … อยากเป็นอย่างเขาบ้าง .... อยากมีแบบนี้ให้ครอบครัวบ้าง …
”เมื่อก่อนเขาก็เหมือนเรา แต่เขาขายสิ่งนี้ เขาเป็นแบบนี้ใน 2-3 ปีเลยนะ“
“เราก็อยากให้ครอบครัวมีชีวิตดีบ้าง สบายบ้าง”
นั่นแหละ …
หลายคนเห็นแต่สิ่งนี้ โดยขายด้วยสิ่งนี้ .... product มีจริงไหม ดีจริงไหม นี่อีกเรื่อง .....
แต่ผมก็เตือนคนเหล่านี้ไปทุกคนแหละ .... ว่าพวกนั้นเขารวย ก็เพราะเขาวาดภาพชีวิตแบบนั้นให้คนอยากรวยแบบเขา แล้วไปขายแบบเขา ผ่านเครือข่ายของเขา .... โดยที่ต้อง​ "เปิดบิล" หรือซื้อมาไว้มากๆ ....
เขาได้เงิน เราได้ของ ที่เราไม่รู้จะขายยังไง ..... ทำไงล่ะ .... ถ้าเราทำแบบเขาไม่เป็น ..... เราทำเป็นแต่ขายทีละชิ้นแบบตรงไปตรงมา ...
อันนี้ก็เหนื่อยหน่อย ตัวใครตัวมัน ....
=============
มันมี Caveat นิดๆ ..... คือ เรื่องนี้มันเป็น mindset คนที่ขาย พอๆ กับตัวธุรกิจเอง ... บางธุรกิจ มันเป็นแชร์ลูกโซ่เลยแทบทั้งหมด .... หลอกให้คนมาเป็นเครือข่ายไปเรื่อยๆ .... อ้างว่าเป็นเครือข่ายนะ แต่จริงๆ มันเป็น "ลูกค้าเป็นทอดๆ" น่ะแหละ ..... ปลายน้ำไปซวยไปเรื่อยๆ .... ที่ตัวธุรกิจเลย สร้างมาเป็นแบบนั้น
แต่มันก็มีนะ คนที่มี mindset แบบนั้น กับการขายของปกติเลย กับธุรกิจที่ไม่ได้เป็นแบบนั้น .....
หลายคนที่ขายของที่ legit ... มี mindset แบบ "มาขายแบบผมแล้วรวย มาขายกันเยอะๆ ซื้อของจากผมไปขายเนี่ยแหละ ผมมีให้ซื้อไปขายเลย" ก็มีเช่นเดียวกัน
อย่างที่บอก มันเป็น indicator ที่ดีพอแหละ มี false positive / false negative ไหม ตอบเลย "มี" แค่มันดีพอที่จะทำให้เรากรองอะไร คัดแยกอะไร ได้เร็วๆ แค่นั้น
(พวกที่อวดสองอย่างก็มี …. อันนี้ดูน้ำหนักเอา … แต่อย่างไรก็ตาม โดยส่วนตัวผมแล้ว ถ้ามีอวดรวย อวดชีวิตดี จากการขายของ แล้วชวนขาย ผมแปะโป้งหมด … ซึ่งอันนี้ต่างจากคนที่โพสท์ งานๆๆๆๆๆ แล้วเขาโพสท์ชีวิตเขาเรื่อยๆ แล้วบังเอิญเราเห็นชีวิตเขาดีขึ้นเรื่อยๆ โดยเขาไม่ได้อวดอะไร)
=============
อยากรวย ไม่ผิด
แต่อย่าอยากรวยเร็วจนหลงผิด แค่นั้นแหละ
ทางลัดมันไม่มีหรอก นอกจากซื้อหวย แล้วโชคดี

เมื่อวานมีโอกาสได้ฟัง Leslie Lamport เป็น Turing award winner ปัจจุบันทำงานที่ Microsoft Research พูดว่าในปัจุบัน software engineers ที่บริษัทยักษ์ใหญ่ เช่น Microsoft Amazon Google Facebook ให้ความสำคัญกับความถูกต้องของโปรแกรม (program correctness) มาก
เพราะ การทดสอบด้วย test cases เพียงอย่างเดียว อาจทำให้เกิดความเสียหายอย่างมหาศาลในอนาคตได้ เพราะบริษัทเหล่านี้มีลูกค้าที่ใช้บริการที่มีต้นทุนความเสียหายสูงมาก หากเกิดความเสียหายขึ้นกับระบบ
นึกภาพครับ หากระบบ cloud เกิดความผิดพลาดทำให้ข้อมูลของบริษัทลูกค้าหายไป หรือ การโอนเงินของบริษัทครั้งละ 1 พันล้าน US dollars เกิดผิดพลาด เพราะระบบล่ม ทำให้บริษัทลูกค้าต้องเสียค่าปรับมหาศาลในการชำระเงินช้า เป็นต้น
ความถูกต้องของโปรแกรม (program correctness) หมายถึง โปรแกรมจะต้องทำงานให้ผลลัพธ์ได้อย่างถูกต้อง สำหรับข้อมูลนำเข้าที่เป็นไปได้ทั้งหมด
เน้นตรงที่ข้อมูลนำเข้าที่เป็นไปได้ทั้งหมดนะครับ ซึ่งในทางปฏิบัติ มีเป็นจำนวนไม่จำกัดเลยก็ได้
ความถูกต้องของโปรแกรมจึงต้องใช้คณิตศาสตร์ในการพิสูจน์เท่านั้นครับ ไม่มีวิธีอื่น คนแรกที่พูดถึง program correctness คือ Robert Floyd เป็น professor สอนที่ Stanford และได้รับ Turing Award ด้วย
กระทรวงอุดมศึกษาบ้านเราเน้น AI and Coding ซึ่งไม่มีอะไรที่เน้นเรื่องความถูกต้องของโปรแกรมเลย ทำให้เราแข่งขันกับต่างประเทศไม่ได้ อันนี้เป็นจุดอ่อนอย่างหนึ่งของระบบการศึกษาบ้านเราครับ #my2cents
Picture credit: Leslie Lamport

บ่อยครั้ง เวลาเกิดปัญหาบางอย่าง ..... แล้วเราเสนอทางออก ในแบบ step-by-step พร้อมบอก bottom line ทุกอย่าง ว่าจะ expect อะไรได้เมื่อไหร่ .....
"ดีที่สุดเท่าที่จะทำได้ given ทุกอย่างที่เราพอจะทำได้ตอนนั้น"
แล้วมันมี feedback กลับมาในลักษณะ คนนั้นจะลำบากแบบนี้ คนนี้จะลำบากแบบนั้น โอ๊ย ตอนนี้ยิ่งมีอันนี้น้อยๆ อยู่ ตอนนี้ยิ่งทำแบบนั้นลำบากอยู่
ก็จะให้ทำยังไงนะครับ ......
ผมบอกแบบเดียวกันได้ไหมนะ ว่าถ้าคุณจะเอามากกว่านั้น ใครต้องลำบากอะไรเพิ่มขึ้นบ้าง หรืออะไรมันจะเกิดขึ้นบ้าง
ผมบอกแบบเดียวกันได้ไหมนะครับ ว่าถ้าเอาแบบนั้นแบบนี้ ผมจะลำบากอะไรยังไงบ้าง
ไม่ได้หรอกมั้งครับ
อยากแก้ปัญหาด้วยกันไหมนะ .....​ หรืออยากจะบ่นกับทุกทางออกที่เป็นไปได้ .....
รู้สึกเหนื่อยๆ และรู้สึกแย่ๆ
โพสท์นี้จะลบตัวเองเร็วๆ นี้