Fanboi Channel

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 กลับมาในลักษณะ คนนั้นจะลำบากแบบนี้ คนนี้จะลำบากแบบนั้น โอ๊ย ตอนนี้ยิ่งมีอันนี้น้อยๆ อยู่ ตอนนี้ยิ่งทำแบบนั้นลำบากอยู่
ก็จะให้ทำยังไงนะครับ ......
ผมบอกแบบเดียวกันได้ไหมนะ ว่าถ้าคุณจะเอามากกว่านั้น ใครต้องลำบากอะไรเพิ่มขึ้นบ้าง หรืออะไรมันจะเกิดขึ้นบ้าง
ผมบอกแบบเดียวกันได้ไหมนะครับ ว่าถ้าเอาแบบนั้นแบบนี้ ผมจะลำบากอะไรยังไงบ้าง
ไม่ได้หรอกมั้งครับ
อยากแก้ปัญหาด้วยกันไหมนะ .....​ หรืออยากจะบ่นกับทุกทางออกที่เป็นไปได้ .....
รู้สึกเหนื่อยๆ และรู้สึกแย่ๆ
โพสท์นี้จะลบตัวเองเร็วๆ นี้

วันนี้เป็นวันแรกของวิชา design and analysis of algorithms (CLRS) ที่เลื่องลือว่ายาก ผมเลยกระตุ้นนักศึกษาด้วยเรื่องจริงที่ผมได้ประสบมาจากการไปสอนวิชา algorithm design for working programmers (days 1-4) ให้กับคนในอุตสาหกรรมซอฟต์แวร์
1. อาชีพทางด้านนี้มี turn over สูงมาก โดยเฉพาะคนที่เก่งวิชานี้ ย้ายที่ทำงานทีหนึ่ง เงินเดือนก็ขึ้นทีหนึ่ง
2. คนที่เก่งวิชานี้มีเป็นจำนวนน้อย เงินเดือนจึงสูง ลูกศิษย์ผมในอุตสาหกรรมซอฟต์แวร์ที่เก่งวิชานี้ เงินเดือนจึงเป็นหลักแสนขึ้นไป
3. บริษัทยินยอมที่จะจ่ายเงินเดือนสูง ๆ เพื่อจ้างคนเก่งไปทำงานด้วย เพราะคนที่ไม่เก่งวิชานี้อาจทำงานแล้วเกิดความผิดพลาด เช่น ระบบล่ม ทำให้บริษัทต้องชดใช้เงิน เกิดความเสียหายกับลูกค้า เสียชื่อเสียง ความผิดพลาดเหล่านี้มีต้นทุนที่สูงมาก บริษัทจะยอมให้เกิดขึ้นไม่ได้ครับ การจ้างคนที่เก่งจึงเป็นการแก้ปัญหานี้โดยตรง เมื่อเทียบกับค่าความเสียหายที่อาจเกิดขึ้น เงินเดือนสูง ๆ จึงคุ้มค่ามาก
4. วิชานี้เป็นพื้นฐานที่สำคัญของ artificial intelligence (AI) ผมเอาตัวอย่างจากอาจารย์ชิดชนกมาเล่าให้ฟัง นั่นคือ การที่จะทำให้จานบินไร้คนขับ (drones) ที่ทำงานกันโดยบินไปเป็นกลุ่มและคุยกันเอง อันนี้ก็คือ การออกแบบอัลกอริทึมแบบขนาน (parallel algorithms) หรืออีกตัวอย่างคือ robot ที่ทำการประมวลผลแบบ online ที่มีข้อมูลเข้ามาเป็น streams อันนี้ก็เป็นการออกแบบอัลกอริทึมที่เรียกว่า online หรือ streaming algorithms นั่นเอง
5. ข้อนี้อาจไม่เกี่ยวกับการทำงานโดยตรง นั่นคือ วิชานี้เป็นพื้นฐานที่สำคัญในการเรียนต่อปริญญาโทและเอกในศาสตร์ที่เกี่ยวข้องกับคอมพิวเตอร์ โดยเฉพาะการเรียนที่มหาวิทยาลัยที่มีชื่อเสียงของต่างประเทศครับ

>>362 การออกแบบที่ดีก็เหมือนกางเกงโยคะ

พวกโปรแกมสร้างเกมโทรศัพท์พวกจอมยุทธ์อัพcpเติมเงินให้เก่งใช้โปรแกรมไรสร้าง