Fanboi Channel

ปรึกษาหน่อยค่ะ

หนึ่งในเรื่องสำคัญที่หลายต่อหลายคนมองข้าม ก็คือ "พิมพ์ดีด"

ต้องฝึกให้คล่องนะ อย่างน้อยๆ นี่ 30 คำต่อนาทีขึ้นไปควรจะได้ ไม่งั้นจะ inefficient มากในการทำงาน

และแน่นอนว่าการพิมพ์ที่ดี ควรพิมพ์ได้โดยไม่ต้องมองแป้นพิมพ์เลยแม้แต่นิดเดียว

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

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

โปรแกรมฝึกพิมพ์ดีดดีๆ นี่ช่วยได้เยอะมากเลย

โปรแกรมที่ผมชอบมาก ก็คือ GNU Typist (gtypist) .... ที่มีลำดับในการสอนที่ดีมาก และมีปรัชญาในการสอนที่ดีเลย ก็คือแทนที่จะเน้นไปที่พิมพ์เร็ว .... เขาจะเน้นที่จังหวะการพิมพ์ (rhythm) และความถูกต้อง .... ถ้าพิมพ์ข้อความแล้วผิดเกิน 3% นี่จะไปต่อไม่ได้ (และผิดแล้วผิดเลย แก้ไม่ได้)

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

อ่อ แล้วการคิด WPM (Words-per-Minute) ของมัน จะเอาจำนวนที่เราพิมพ์ผิดมาคิดด้วย ว่าจริงๆ แล้วเราพิมพ์ได้กี่คำต่อนาทีกันแน่

จะเห็นว่าในรูปแรก ผมพิมพ์ถูกหมด WPM ก็เป็นไปตาม Raw speed (95 WPM) แต่รูปที่สองนี่มีผิดอยู่หน่อย (2%) ทำให้แม้ว่าจะพิมพ์ที่ Raw speed 83 WPM ก็ถูก adjusted เหลือ 75

ที่สำคัญที่สุด คือมันทำบทเรียนหรือแบบฝึกหัดเองง่ายมาก ..... อย่างรูปสุดท้าย นี่ผมเอาโค้ด Haskell ที่ผมเขียนไว้สอนใน Workshop หนึ่งมาเป็นแบบฝึกหัดเลย

เอาไว้ให้พวกเด็กฝึกงานหรือพนักงานใหม่ฝึกพิมพ์ดีดไปกับสไตล์การเขียนโค้ดที่ใช้ในทีมได้เลย

Redis ได้เงินลงทุนรอบใหม่ มูลค่ากิจการเกิน $1 billion แล้ว unicorn ของจริงช่วงนี้มีแต่สาย technical

ในไทยหาคนยังหาที่เคยใช้เยอะๆคุยด้วยได้ไม่กี่คน มันดีมากจริงๆ ยิ่ง module ที่ทำจริงจังช่วง 3-4 ปีหลังนี้ ทั้ง graph, timeseries, search คือดีทั้งหมด ถึง feature จะไม่เยอะเท่าคู่แข่งแต่ใช้ง่ายกว่ามาก เสียดายยังไม่มีโอกาสได้ลองใช้ redisAI ที่เพิ่งออกมาใหม่ไม่นาน เพราะงานตอนนี้ไม่ได้ทำเรื่อง ML, AI หรือ Data โดยตรงแล้ว

>>193 quote เก่าแล้วป่าววะ กูเห็นใครๆก็ใช้

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

อนาคต ทุกคนก็จะเขียนโปรแกรมเป็นหมด แต่โปรแกรมเมอร์ที่เขียนได้ดี ก็จะยังมีงานทำอยู่ดี

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

"เดี๋ยวนี้สงสัยไม่สอนเรื่องนั้นเรื่องนี้"
"ทำไมไม่สอนเรื่องนั้นเรื่องนี้"
"ต้องให้ความสำคัญกับเนื้อหานั้นนี้มากกว่านี้"

ฯลฯ

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

ปัญหาใหญ่กว่านั้นคือ "วิธีการสอน" และ "วิธีการเรียนรู้" ครับ

ถ้าเราคิดว่าปัญหาคือ "เนื้อหาการสอน" เราก็จะไปแก้ที่เนื้อหา ต้องยัดเรื่องนั้น ต้องมีเรื่องนี้ ฯลฯ

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

ส่วนหนึ่งก็เพราะคนสอนก็จะถูกบังคับให้ต้องสอนเรื่องนั้นเรื่องนี้ให้มีเนื้อหาเรื่องนั้นเรื่องนี้อย่างเร่งด่วน ปีนี้ยัดเนื้อหา ปีหน้าต้องสอน อะไรแบบนี้เป็นต้น ....

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

เข้าทำนอง ..... คนสอนก็ต้องจำไปสอน ท่องแบบนกแก้วนกขุนทอง พูดได้เป๊ะแต่ไม่รู้เรื่องรู้ราวรู้บริบทอะไร .... ในขณะที่คนเรียนก็เหมือนเครื่องถ่ายเอกสาร .... ที่อ่านเอกสารไปเขียนลงข้อสอบ แล้วก็ลืมไป (เครื่องถ่ายเอกสารไม่มี Hard disk ที่เก็บข้อมูลถาวร มันก็จะจำไว้แค่ช่วงเวลาที่มันต้องถ่ายเอกสารเท่านั้นแหละ หลังจากนั้น "มันก็คืนคนที่เอามาถ่ายไปหมด" -- คุ้นๆ ไหม ... "เรื่องนี้ผมคืนอาจารย์ไปหมดแล้ว")

ยิ่งเราบอกว่าต้องสอนเรื่องนั้นเรื่องนี้เพิ่มเข้าไปไม่มีที่สิ้นสุด ปัญหานี้ก็ยิ่งหนักขึ้นทุกวัน

ถ้าดูจากเนื้อหาและปริมาณ ผมว่าเราก็ให้ความสำคัญกับทุกเรื่องนะ ... คณิตศาสตร์ ภาษาอังกฤษ ประวัติศาสตร์ วิทยาศาสตร์ .... อีกหน่อยก็จะโค้ดดิ้ง และวิทยาการคำนวน ......

ปัญหาคือ "วิธีการสอน" และ "วิธีการเรียน" แหละครับ

มีแค่นี้จริงๆ

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

[Slide Story] น้องๆ และสหายหลายต่อหลายคน ที่มาเรียนเรื่อง Maths for Working Programmers และ Functional Programming กับผม หลายคนที่ยังใกล้ชิดมหาลัยอยู่ก็พยายามจะไปบอกให้มหาลัยสอนเรื่องพวกนี้บ้าง ...

ผมก็ต้องเตือนน้องๆ และมิตรสหายเหล่านี้เสมอว่า "สอนเรื่องนี้แบบผม เรียนเรื่องนี้แบบที่น้องเรียนกับผม น้อง/คุณก็อินแล้วก็สนุกแหละครับ" ....​ "เนื้อหาพวกนี้ มีในหลักสูตรนะ เรื่องนี้อยู่ตรงนี้ เรื่องนั้นอยู่ตรงโน้น ฯลฯ" .... เห็นไหม มีนะ ไม่ใช่ไม่มี ฯลฯ

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

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

รูป: นกแก้วบนเครื่องถ่ายเอกสาร ..... รูปที่อยู่ใน presentation slide ที่ผมเคยใช้บ่อยมาก เดี๋ยวนี้ไม่ค่อยได้พูดเรื่องนี้แล้ว

ใน reddit มีคนเอามาแปะ ก็เล่าไปใน reddit แล้วเอามาเล่าให้คนไทยฟังบ้าง

ที่ Wongnai ใช้ ArgoCD อยู่มันจะเป็น step แบบนี้ครับ

1. project build & push docker ใน gitlab ci
2. step สุดท้ายของ ci เรามี tool มา clone ceylon (deploy manifest) repo, create branch, update image tag, push branch แล้วเปิด merge request (MR)
3. tool มันจะ mark MR ให้ auto merge on pipeline success เป็นอันจบ pipeline ของ project
4. pipeline ของ MR ที่เข้า ceylon มี tool validate (หวังว่าจะมีเวลา open source ให้) มันจะ run ArgoCD template ได้ JSON มาแล้วโยนเข้า kubeval
(แปลว่ามี check 2 ที่ คือ Jsonnet assert สำหรับ best practice check + kubeval เช็คว่า valid)
5. MR merge เสร็จแล้ว argocd auto sync ยกเว้น prod ต้องกด sync เอง

ฉะนั้นจากในบทความนี้เราเลยไม่ค่อยเจอปัญหาเหมือนเค้า

1. ผมเข้าใจว่าเค้า clone แล้ว push master แข่งกัน มันเลย race แต่เราเปิด MR แล้วให้ gitlab merge มันเลยไม่ต้องแย่งกันเพราะเราไม่ได้ตั้งให้ rebase ก่อน merge
จะมี race ก็คือ MR project เดียวรัน 2 อันพร้อมกัน อันนี้ช่วยไม่ได้นอกจากไปตั้ง Gitlab ว่าให้ยกเลิก pipeline เก่าเมื่อมีอันใหม่กว่า (ซึ่งเราไม่ได้เปิด)
2. เราใช้ deployment monorepo แถม branch เดียวทุก env ด้วย เลยไม่มีปัญหาว่า repo เยอะ งง
ทีมบ่นอยู่บ้างว่าอยากได้ branch เพิ่มจะได้ทดลองของได้โดยไม่กระทบ prod อันนี้ยังมองๆ อยู่ว่าจะทำยังไงไม่ให้มันระเบิดแบบเค้า
3. Visibility ยากนี่เรื่องจริง มี git log ก็จริงแต่ไม่รู้ว่ากด sync ใน ArgoCD ตอนไหนต้องไปค้น ArgoCD log
4. Validation เรามี validate tool เลยชิล

ปัญหาที่ผมเจอจริงๆ น่าจะเป็นว่า

1. Rollback ยากมาก คือต้องถอย commit ออก แต่พอ change มันเป็นแค่ปรับ image tag มนุษย์ทั่วไปเข้าใจไม่ได้ว่าถอยเท่าไรถึงจะหายบั๊ก (ถอยโค้ดยังอ่าน commit message พอได้) แล้วมันหลายขั้นตอนมาก คนเลยชอบไปกดใน ArgoCD ซึ่งมันทำให้ decouple cluster state ออกจาก git state หรืออีกทีคือถอย commit ในแอพเลยแล้วรอ build ซึ่งนานมากกกกก
2. Post deploy step ทำยากมาก เช่น deploy dev เสร็จแล้วรัน automate test ไม่รู้จะเช็คยังไงเลยว่า deploy ยังไง (MR merge แล้วแต่ก็ต้องรอ sync + pod rollout) ที่ทีมทำกันอยู่มีแต่ท่า hackๆ

>>197 wongnai ไปทำไรใน reddit

สองสัปดาห์ที่ผ่านมาประชุมเยอะขึ้นมากๆ แต่รู้สึกว่าได้ทำงานเป็นชิ้นเป็นอันจากการประชุม ไม่ได้รู้สึกว่ามัวแต่ประชุมไม่ได้งาน

ทำให้เข้าใจอย่างนึง เวลาประชุมแล้วไม่มีประสิทธิภาพมันไม่ได้เกิดจาก Format ในงานประชุมเสมอไป แต่เรื่องนึงที่ทำให้ไม่มีประสิทธิภาพ รู้สึกว่าไม่ได้งาน คือ เวลาประชุมเพื่อ "สร้างความมั่นใจให้ผู้เกี่ยวข้อง"

ผมเริ่มเห็นว่าการประชุมแบบนี้ Effective ต่ำและกินพลังงานเยอะ ไม่ได้แปลว่าควรเลิก แต่แปลว่ามีช่องให้พัฒนาได้เยอะ

ในโดเมนการพัฒนาซอฟต์แวร์ เครื่องมือที่สร้างความมั่นใจที่ดีที่สุดคือ Working software รองลงมาคือ Demo ส่วนการทำสไลด์หรือการพูดคุยย้ำๆ ว่า โปรเจ๊กต์ยังไปได้ งานยังดี อันนี้สร้างความมั่นใจได้น้อยกว่าอย่างมาก แถมยังต้องพูดย้ำบ่อยๆ แล้วเปลืองเวลา

จะพบว่าเวลาคุณรัน Agile, Scrum, etc. แล้วคุณต้องสร้างความมั่นใจทุกๆ สองอาทิตย์ มันจะบังคับให้คุณต้องมี Demonstratable Progress ในเลเวลนั้น

และมันจะกระทบไปถึงวิธีเขียนโค้ด Process การทำงาน การวางโครงสร้าง

พอมาถึงหัวข้อนี้ ผมไม่ Buy เลยว่าพอทำ Scrum แล้วจะทำให้ Architecture ห่วย แต่มันต้องใช้ Architecture style และ Mindset ที่ต่างกัน

เช่น หลายคนเชื่อว่าคุณสมบัติของ Fundamental Architecture ที่ดีคือสิ่งที่ทำครั้งเดียวแล้วทนทานใช้ได้ตลอดกาล ซึ่งพอเปลี่ยนวิธีทำงาน คุณสมบัติที่สำคัญกว่าในการทำงานแบบ Agile (ที่มี Feedback loop สั้น) ถ้าต้องแก้ แก้ง่าย ทุกคนแก้ได้หมด เป็นคุณสมบัติที่มี Priority สูงกว่าความทนทานใช้ได้ไม่มีวันพังไม่ต้องแตะ ในโลกแบบ Agile

เขียนไปเขียนมาแตกหัวข้อไปหลายเรื่องแฮะ ขอสรุปหน่อยว่า Reflect อะไรได้บ้าง

- การประชุมเป็นเครื่องมือที่คนนิยมใช้เมื่อต้องการ "สร้างความมั่นใจให้ผู้เกี่ยวข้อง" แต่ มันเป็นเครื่องมือที่ Effective ต่ำมาก ถ้าประชุมอันไหนมีหน้าที่แค่ "รายงานให้คนเกี่ยวข้องสบายใจ" แปลว่ามี Room for improvement เยอะมาก อย่างเลเวลแรก จากสไลด์ 30 นาที คุณเปลี่ยนเป็นทำเป็นเดโม 5 นาที ได้ความมั่นใจมากกว่าโดยใช้เวลาน้อยกว่าเยอะ ถ้าเปลี่ยนเป็นแค่ Deploy working software แล้วบอกให้คนเกี่ยวข้องมาลองเล่นเองได้ ยิ่ง Effective เลยใช่มั้ย และสิ่งที่ Effective ที่สุดคือ ทำให้เขาเชื่อมั่นจนเขาบอกเองว่า "ไม่ต้องอัพเดทพี่แล้ว พี่ไว้ใจทีม มีอะไรให้พี่ช่วยมั้ย ถ้าไม่มี พี่เอาเวลาไปทำอย่างอื่นดีกว่าว่ะ" อันนี้คือ End game และตราบใดที่ยังไม่ถึงตรงนี้ เรายังสามารถหาทางดิ้นเพื่อพัฒนาได้เรื่อยๆ

- พอพัฒนาข้อแรกมันจะมากระทบ Process การทำงาน ไปจนถึงโค้ดที่เขียนแต่ละบรรทัดเลยนะ ซึ่งไม่เป็นไร กระทบก็กระทบ ผมไม่เห็นว่าเสียหายอะไร แต่ต้องเข้าใจว่ามันกระทบ ซึ่งบางครั้งกระทบไปลึกซึ้ง ถึงนิยามว่า Practice ที่ดีไม่ดีคืออะไร Architecture ที่ดีไม่ดีคืออะไร นิยามและความเข้าใจมันจะเปลี่ยนได้

เอาจริงๆ ผมขอบคุณประสบการณ์ตัวเองและอาจารย์ที่สอนสั่งมาหลายท่านว่าธุรกิจเขาคิดอะไรกัน คือผมมีประสบการณ์ในวงการ Startup ที่มี Exposure โดยตรงกับผู้เกี่ยวข้องมาตลอด ทำให้เวลาผมเรียงลำดับความเสี่ยงที่ทำให้โปรเจ๊กต์ล้มเหลวได้ ผมเรียงว่า
1. ทำไม่ได้ทรัพยากรไม่พอ อันนั้นลำดับหนึ่ง
2. ทำไปทำมา ระหว่างทางคนลงทุนขาดความมั่นใจจนถอนทุนแคนเซิลโปรเจ๊กต์ อยู่ลำดับสอง

แล้วปัญหาที่แบบวางโครงสร้างไม่ดี วางโค้ดไม่ดี ใช้ Tech stack ผิดแล้วล้มเหลวต้องแก้ไข ผมมองว่าเป็นความเสี่ยงลำดับล่างๆ อาจจะเกิน 10 ด้วยซ้ำไปมั้งถ้าแตกหัวข้อจริงๆ

ผมเลยไม่มีปัญหากับการ Bend ตัวโค้ด สถาปัตยกรรม โครงสร้าง เพื่อแก้ความเสี่ยงข้อ 2 ทำไงก็ได้ให้ทำให้คนเกี่ยวข้องมั่นใจไม่ถอนทุน ถ้าต้องมี Automated test ก็ต้องมี ถ้าต้องมี Evolutionary architecture ก็ต้องมี ถ้าวางอะไรลงไปแล้วต้องแก้ทีหลัง ก็ต้องทำ (ตรงนี้มันเถียงกับความเข้าใจผิดของหลายๆ คนได้อีกว่า การทำ Engineering practice ห่วยๆ จะทำให้ปั่นงานเร็วกว่า มีอะไรไปอัพเดทสร้างความมั่นใจบ่อยกว่า ซึ่ง ผมว่าไม่ใช่)

ซึ่งผมมองว่ามันเสี่ยงกว่าเรื่องที่ว่าเลือก Tech stack ผิด เลือกภาษาผิด แบบคนละเรื่องเลยนะ พวกนั้นไม่ทำให้โปรเจ๊กต์พัง แค่ทำให้เหนื่อยเฉยๆ อ่ะครับ

ความเข้าใจผิดที่เห็นบ่อย

"การเลือกใช้ RDBMS แล้วทีมพัฒนาจะคิดเรื่อง Schema ให้ดี วางแผนเรื่องข้อมูลเยอะๆ แล้วเราจะได้ Structure ของข้อมูลที่ดี"

ผมคิดว่าการใช้ RDBMS โดยคาดหวังผลลัพธ์ว่าจะได้บังคับทีมพัฒนาให้คิดเรื่อง Data structure ให้ดีก่อนทำอะไร ไม่เคยได้ผลจริงเลย

อันนี้มักจะเป็นความเข้าใจของคนที่ดูแลฐานข้อมูลหรือ Infrastructure แต่ไม่ได้ร่วมงานกับทีมพัฒนา ที่ว่าพอเสนอ Field Migration แล้วถูกตั้งคำถามจากฉัน เขาจะได้คิดดีๆ ก่อนเสนอ แล้วเราจะได้มี Data schema ที่งดงามไม่ Bloat โอ้ มันช่างดี มันต้องได้ผลแน่ๆ

ในความเป็นจริงผมเห็นมาหลายระบบแล้ว พอคุณทำให้ Field Migration มันยาก คนไม่ได้คิดให้ดีก่อนเสนอ Schema change ครับ คนเขาจะพยายาม Reuse field เก่ามาใช้หลายๆ อย่างแทนครับ เพราะเขามานั่งรอคุณตั้งคำถามไม่ได้ เขามีงานที่ต้อง Deliver

สิ่งที่เกิดขึ้นคือเราจะมีฟิลด์ที่มีหลายความหมาย ซึ่งไม่ใช่การออกแบบที่ Data ที่ดีเลยแม้แต่นิดเดียว

นั่นคือ Actual consequence ไม่ใช่การที่คนคิดให้ดี แต่เป็นการที่คนขี้เกียจทำไปเลย

แต่ถ้าคนที่เสนอสิ่งนี้ ไม่ได้อยู่ในทีมพัฒนา เช่น อยู่ในองค์กรที่มี DBA แยกกันกับทีมพัฒนาอย่างสมบูรณ์จนกระทั่งไม่รู้เลยว่าข้อมูลพวกนี้ไปใช้ในส่วนไหนของซอฟต์แวร์บ้าง จะไม่รู้ไง เห็นว่า Database schema/Structure เหมือนเดิม ก็เข้าใจผิดไปว่านี่คือออกแบบ Data มาดีแล้ว

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

จนกระทั่งต้องเริ่มทำ BI ถึงจะเห็นปัญหาว่าอ้าว ฟิลด์นี้มันหมายถึงหลายอย่างเลยนี่หว่า จะเอาไป Analyze ยังไงล่ะ

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

นี่คือเหตุผลหนึ่งที่คนทำงาน Infra ควรจะอยู่ในทีมพัฒนา ไม่ใช่แยกกันทำงาน ฉันดูแลระบบ แกพัฒนา พอมันแยกกัน ความเข้าใจผิดก็เกิดขึ้นได้ง่ายมาก

ไปร่วมชุมนุมปลดแอกไม่ได้ว่าอะไร แต่ถ้าหัดเขียน PHP ไล่ออกจากบ้านแน่ไอ้อ้วน

โดนปลุกมา zoom ฟังประชุมอันนึงคุ้มค่ามาก สรุปสั้นๆ Dev ที่เข้าใจ DeFi จะมีค่าตัวแพงมาก Dev ทั้งหลายจงไปลอง Uniswap , Compound , Sushiswap ให้เข้าใจกลไกอย่างถ่องแท้กันเถิด

ด้วยความเคารพ

Imperative “ไม่เท่ากับ” Loop
Functional “ไม่เท่ากับ” Map, Reduce

โว้ยยยยยยย

#ขอระบายหน่อย
#เจออะไรโง่ๆมา
#แค่เปลี่ยนLoopเป็นMapก็เขียนFPแล้ว

การศึกษาเรื่อง Deep Learning ในปัจจุบัน เรื่องแรกๆที่มักศึกษากันคือ "Computer Vision" ที่ใช้ Deep Learning ในการแปลผลด้วยเทคนิคต่างๆ ทำไมต้องเป็น "Computer Vision"?
ในยุค Cambrian (500+ ล้านปีก่อน) เป็นช่วงที่มีการเกิดขึ้นของสิ่งมีชีวิตที่เป็นสัตว์ (ไม่ใช่พืช) มากขึ้นอย่างชัดเจน เนื่องจากในช่วงนี้มีวิวัฒนาการที่สำคัญคือการรับรู้แสง หรือการมองเห็นนั่นเอง
การมองเห็นทำให้สัตว์ที่มีวิวัฒนาการด้านนี้เพิ่มจำนวนขึ้นอย่างมาก เนื่องจากการมองเห็นทำให้ หาอาหารได้ดีกว่า หลบหลีกศัตรูได้ดีกว่า และสามารถหาคู่เพื่อสืบเผ่าพันธ์ได้ดีกว่า ทำให้เกิดสายพันธุ์ของสิ่งมีชีวิตเกิดขึ้นมากมายอย่างเห็นได้ชัด
การจะพัฒนา Deep Learning ให้มีความฉลาด จึงเริ่มที่ Computer Vision เพราะเมื่อเครื่องจักรเข้าใจสภาพแวดล้อมในอย่างที่มนุษย์เข้าใจ (ด้วยการมองเห็น) ก็จะพัฒนาความฉลาดได้คล้ายคลึงมนุษย์ในอันดับต่อไปของการพัฒนา
เรื่องนี้ต่างจากการศึกษา Machine Learning หรือ Artificial Intelligence ในช่วงแรกที่มุ่งไปยัง "ความฉลาด" ที่มนุษย์มักคิดว่า "ฉลาด" เช่น กิจกรรมบางอย่าง แบบ เล่นหมากรุก เป็นต้น ซึ่งทำให้เราหลงทางในการพัฒนาด้าน AI ไปราวๆ 3 ทศวรรษ
บทความนี้ไม่ค่อยเกี่ยวกับ AI แต่เกี่ยวกับยุค Cambrian ที่มีความสำคัญต่อแนวคิดด้านการศึกษา AI

https://stem.in.th/kylinxia-zhangi/?fbclid=IwAR1YPs5oc1t-Nly1YGQX3sB9a7RDfA5o3HSyBUhReKTLKi2OitKmsh_YFxQ

>>204 มึงคิดได้ไงวะ แบบนี้ต้องมีการสูญพันธุ์ครั้งใหญ่ด้วยมะ พวก ai ที่เสียโอกาสจะได้มีโอกาสในการวิวัฒนาการ

พวก great dying ส่วนมากมันจพมาแบบสุ่ม

>>206 ถ้ารู้ล่วงหน้ามันก็ไม่ตายกันดิคุณ

2020 Reflection - ปีแห่งการปล่อยวางความคาดหวังและอยู่กับความจริงมากขึ้น 🌧❤️

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

...

📌 แบบสรุป

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

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

...

📌 แบบยาว​ 😂

🌪 #มรสุมใหญ่เข้ามาแบบไม่ทันตั้งตัว

ด้วยความประมาทที่วางแผนทางการเงินของบริษัทไม่ดีพอ เจอ timeline การขอใบอนุญาตที่ยาวอย่างคิดไม่ถึง ประกอบกับการที่เชื่อมั่นในดีลที่ยังไม่ได้มีสัญญาชัดเจนมากเกินไป ทำให้มองข้ามความเสี่ยงที่ดีลจะล้มไป กลายเป็นต้องเจ็บหนัก เพราะรีบย้ายออฟฟิศและ scale ทีมขึ้นเร็วเกินไป ทำให้ได้เรียนรู้เรื่องความสำคัญของการวางแผนการเงินและเผื่อ worst case ไว้เลย อะไรก็เกิดขึ้นได้จริงๆ 😂

🪔 #ในความมืดมิดยังมีความหวังอยู่เสมอ
ในช่วงที่ลำบากมากๆ ก็เลยโทรไปขอคำปรึกษาพี่ๆ ที่รู้จักหลายๆ คน ได้รับคำแนะนำและความช่วยเหลือมาเยอะมามาย และในที่สุดก็โชคดีที่ได้รับการแนะนำให้ไปช่วยทำระบบ digital banking ซึ่งอยู่ในส่วนที่ถนัดและอยากเรียนรู้พอดี และช่วยต่อชีวิตให้กับบริษัทอีกด้วย รู้สึกขอบคุณทุกคนมากๆ ที่ช่วยเหลือในช่วงที่ผ่านมา ขอบคุณครอบครัวสำหรับกำลังใจ และทีมที่ไม่ยอมแพ้ไปด้วยกันมากๆ 🙏🥺

🛣 #ตามหาทิศทางของบริษัท
ในช่วงที่กัดฟันเพื่อทำบริษัทให้อยู่รอด ก็เริ่มเห็นว่าการ consult หรือ outsource ระบบ IT ด้านการเงินเป็นที่ที่มีความต้องการค่อนข้างสูงและสามารถทำเงินให้กับบริษัทได้ดีและเติบโตได้ระดับหนึ่งเลย

แต่ว่าเราและทีมก็ยังรู้สึกว่ามันไม่ใช่ทาง รู้สึกว่า passion ของเรา เป็นการสร้าง product ที่ได้มีโอกาสดูแล คุยกับลูกค้าและกำหนดทิศทางเองมากกว่า ทำให้รู้สึกขัดกับการรับ consult ที่ทำอยู่

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

ต้องขอบคุณคนรอบๆ ตัวเราที่นำพาเราไปเจอสิ่งดีๆ เยอะแยะเลย

⏸ #ได้มีโอกาสกลับมาอยู่กับตัวเองมากขึ้น
หลังจากรับ consult มาตลอดก็มีโอกาสได้หยุดพัก เลยคุยกับทีมให้หยุดพักกัน 2 สัปดาห์เลย หลังจากที่วิ่งไม่เคยหยุดนานมาก

ตอนนั้นก็เลยตัดสินใจไปลองปฏิบัติธรรมแบบยาวๆ ที่อยากลอง แบบที่ไม่มีมือถือหรือ internet ตลอด 10 วันเลยทำให้ได้อยู่สังเกตตัวเองมากขึ้น ได้เห็นว่าจริงๆ ตัวเองขี้โมโหกว่าที่คิดมากๆ เพราะความคิดที่ว่า สิ่งต่างๆ จะต้องเป็นไปตามคาดเสมอ พอไม่ได้ก็โกรธและเครียด ซ้ำยังโกรธตัวเองที่โกรธอีก เป็น loop ไปปป 😡

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

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

🌲 #ละทิ้งและเริ่มต้นใหม่
แล้วเราก็เริ่มพับ Product เดิมลงได้ ทั้งที่ควรจะทำได้เร็วกว่านี้ เพราะการเก็บ Product ไว้ก็มีต้นทุนในการ maintain อยู่ดี ถึงจะมีคนใช้ไม่มากก็ตาม และกินเวลาที่จะไปหาโอกาสใหม่ๆ

ระหว่างนั้นก็ได้โอกาสกลับมานั่งคุยกับทีมว่าอะไรที่เราอยากทำจริงๆ อะไร ก็เลยเลือก Product ด้าน Open Financial Data เพราะเชื่อว่าจะพาเราไปถึงเป้าหมายที่วางไว้ได้

🚧 #understand_first_not_build_first
รอบนี้มาเริ่มต้นใหม่ ก็พยายามเปลี่ยนวิธีการทำงาน จากที่ได้เรียนรู้ใน Hackathon คือหลายๆ ครั้งมีแค่ mockup และ slide ก็ขายของได้ ทำไมเราต้องรอให้เราทำ product เสร็จก่อนถึงจะขายละ ถ้าเกิดมันขายไม่ได้ละ ที่ทำมาก็เสียเปล่าสิ

ก่อนหน้านี้ด้วยความเป็น developer พอคิดอะไรได้ ก็อยากสร้างไปหมด โดยไม่รู้ว่า 1) ปัญหาของกลุ่มลูกค้ามีอยู่จริงมั้ย รุนแรงแค่ไหน 2) solution ที่เรามีมันแก้ปัญหาที่เค้ามีจริงมั้ย 3) ลูกค้าพร้อมจะจ่ายให้กับ solutionที่เรามีรึเปล่า

ซึ่งพอเริ่มต้นจากการทำความเข้าใจลูกค้า ก็ทำให้เรา ออกแบบ product ได้ถูกทางขึ้นมากๆ และมีความมั่นใจขึ้น

❤️ #ได้กลับมาเรียนรู้ตัวเองมากขึ้นอีก
หลังจากนั้นก็ได้มีโอกาสเขียน reflection บ่อยขึ้น เข้า workshop นพลักษณ์ แล้วก็การได้พูดคุยกับคนหลายๆ คน ทำให้เริ่มเข้าใจตัวเองมากขึ้นอีก โดยเฉพาะในเรื่องที่เหมือนเราค่อนข้างแคร์ในภาพ และมุ่งมั่นใจเป้าหมายมากๆ จนบางทีไม่ได้มองโลกตามความเป็นจริง แต่ไปมองเป็นสิ่งที่อยากให้เป็นมากกว่า ต้องขอบคุณคนที่ตั้งคำถามให้เราได้คิดเสมอด้วยนะ :)

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

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

ตอนนี้ไปขอดู ระบบซอฟต์แวร์เขา จะถามว่าระบบคุณนี่ PASS ไหม คือ เขาต้องอธิบายได้ว่า. Performance Availability Security Scalability ของระบบเขามีที่มาอย่างไรในการออกแบบ

บางคนใช้ container อย่างหวือหวา แต่ database ไม่ scale บางทีไม่ได้คิดถึง สมรรถนะของ disk and io subsystem บริหารผู้ใช้ไม่มี identity management ไม่ได้ลด attack surface ลง ไม่ได้ออกแบบให้ระบบ scale out ได้แต่ scale up แบบโบราณ บางที่ไม่ได้เห็นการแบ่งโมดูล การเชื่อมโยง flow และข้อมูล สารพัด ไม่ง่ายนะครับ พวกนี้ทำทีหลังยากมากมาก เช่นถ้าไม่มี role base control ต่อไปการจัดระดับการ access ของข้อมูลอาจจะทำยากหรือไม่ได้เลย
เวลาขอดูงานจะเริ่มที่ความคิดในเชิงสถาปัตยกรรมระบบเขาก่อน ถ้าเขาวางดีแสดงว่าทำเป็น ส่วนอื่นมักจะพอไปได้

>>211 สมมติว่า ทำคนเดียว จะขึ้นทั้งหมดที่ว่ามามั้ย

𝐏𝐬𝟏 หลายๆอาชีพ มีมามีไป มีหายไป มีเกิดใหม่ ผมอยากให้เน้นความรู้พื้นฐานเอาไว้ให้แน่น เพราะจะทำให้เราเขยิบสาขา หรือเข้าสาขาใหม่ได้ง่าย ไม่โดนเท วิชาเหล่านี้คือหัวใจหลักที่ช่วยผมในทุกสายงานที่เข้าไป Engineer Mathematic, Algorithm​s and data structure, Database Systems, Statistic, Network, Data Communications, Signal Processing and Communication Systems
จะเห็นว่าวิชาเหล่านี้ ไม่มีคำว่า DS หรือDE เลย แต่พื้นฐานเหล่านี้ช่วยให้อ่านเพิ่มเติมได้ง่าย ทำให้ก้าวไปด้านไหนก็ไม่ยากเกินไป

ในขณะที่กำลังทำ personal side-project ก็เจอ quote นี้ .... มันโคตรจริงยิ่งกว่าจริง ... golden มาก ... ต้องเอามาลงไว้ตรงนี้ด้วย

“Businesses frequently prioritize new feature releases over fixing technical debt. They choose to work on revenue-generating work instead of revenue-protection work. This rarely works out as the business hopes, particularly as problems discovered during the final stages of uncompleted projects drag engineers away from the newer projects.”

― Dominica Degrandis

คำถามที่ผมเจอบ่อยที่สุดเวลาไปพูดเรื่อง quantum computation คือ เมื่อไรมันจะใช้งานได้จริง คำคอบคือ Now ครับ แต่ว่าจะใช้ได้เฉพาะกับงานบางประเภทเท่านั้น ยกตัวอย่างเช่น เรารู้กันดีว่าการทาสีแผนที่โดยใช้ไม่เกิน 4 สีเป็นปัญหาที่ยากมาก ใช้เวลานานในการคำนวณหากเราใช้คอมพิวเตอร์แบบปัจจุบัน (classical computer) แต่ถ้าใช้ quantum computer จะเร็วขึ้นกว่าเดิมมาก (แม้ว่ายังเป็น exponential อยู่แต่เร็วขึ้นประมาณ quadratic เท่า)
ในวิดีโอนี้ ลูกศิษย์ผม Wen Wen ใช้ quantum computer แบบที่เรียกว่า quantum annealer ของบริษัท D-wave ที่สหรัฐในแก้ปัญหาการทาสีแผนที่โดยใช้ไม่เกิน 4 สี ผลออกมาใช้ได้เลยทีเดียวครับ
ถามว่า D-wave ราคาเครื่องละเท่าไร ทำไมเราไม่ซื้อมาใช้เลยล่ะ ราคาประมาณ 100 ล้านเหรียญสหรัฐหรือประมาณ 3000 ล้านบาทครับ เอาปัญญาที่ไหนมาซื้อ แถมเราไม่ควรจะซื้อเทคโนโลยีของชาวบ้านด้วย เพราะเราจะไม่เรียนรู้อะไรเลย ซื้อใช้อย่างเดียว
ศูนย์เทคโนโลยีควอนตัมของ มช เรา เลยตัดสินใจว่าจะสร้าง quantum annealer ขึ้นมาเอง ราคาน่าจะถูกกว่าเยอะครับ ถ้าสำเร็จ เราจะได้เทคโนโลยีของเราเอง และทำให้ชาติไทยยืนเคียงบ่าเคียงไหล่กับต่างประเทศได้ ไม่เป็นเพียงผู้บริโภคเทคโนโลยีอีกต่อไปครับ
ปล. Wen Wen เป็นนักศึกษาวิศวะไฟฟ้า อินเตอร์เนชั่นแนลโปรแกรมปีสุดท้าย ของมหาวิทยาลัยขอนแก่น แต่มาฝึกงานที่ศูนย์ควอนตัม มช

ผมเห็นว่า "การขาดแคลนโปรแกรมเมอร์" หรือ "การที่เราต้องการโปรแกรมเมอร์จำนวนมาก" นั้น เป็น Quality Problem มากกว่า ​Quantity Problem ....
พูดอีกอย่างคือ เราไม่ต้องการโปรแกรมเมอร์มากแบบที่เราคิดหรอก .... แต่เราต้องการโปรแกรมเมอร์ที่เก่งกว่านี้ .... ซึ่งมันอาจจะทำให้จริงๆ แล้วเราต้องการโปรแกรมเมอร์จำนวนน้อยลงก็ได้
ทำไมอ่ะ?
คือ โปรแกรมเมอร์ห่วยๆ 1 คน .... สามารถเขียนโค้ดขยะที่ทำงานได้นะ แต่ต้องใช้โปรแกรมเมอร์อีก 2-3 คน (ที่อาจจะต้องเก่งกว่าเขาด้วย) ในการ maintain มันในระยะยาว และไม่มีเวลาไปแก้ไขไปรื้อไปปรับโครงสร้างอะไรกับตรงนี้ .... และถ้ายิ่งโปรแกรมเมอร์ห่วยๆ คนนี้ทำงานใหม่ไปเยอะเท่าไหร่ เรายิ่งต้องการคนมา maintain งานเขามากเท่านั้น ... ดังนั้น โปรแกรมเมอร์ห่วยๆ 1 คน ทำงาน 10 ปี ปีละ 1 งาน ... นี่อาจจะก่อให้เกิดความต้องการโปรแกรมเมอร์ที่เก่งกว่านั้นจำนวน 20-30 คนเลยทีเดียว ....
ถ้าเรามีโปรแกรมเมอร์ห่วยๆ มากเท่าไหร่ เรายิ่งต้องการโปรแกรมเมอร์มากขึ้นเท่านั้น
========================
ข้อความด้านบนนี้ Paraphase จากบทสัมภาษณ์ David Parnas (ที่ผมเห็นด้วยอย่างมากในประเด็นนี้) โดยการใส่ความเห็นส่วนตัวผมเพิ่มเติมลงไป ส่วนบทสัมภาษณ์ต้นฉบับคือ
Q: What is the most often-overlooked risk in software engineering?
A: Incompetent programmers.
There are estimates that the number of programmers needed in the U.S. exceeds 200,000. This is entirely misleading. It is not a quantity problem; we have a quality problem. One bad programmer can easily create two new jobs a year. Hiring more bad programmers will just increase our perceived need for them. If we had more good programmers, and could easily identify them, we would need fewer, not more.

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

"ถ้าเขาไม่รับคุณ"
"ถ้าคุณไม่ดีพอที่เขาจะรับ"

เงินเดือนแค่ไหนคุณก็ไม่ได้ จบ

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

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

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

และบ่อยครั้งถ้าคนนั้นเก่งพอที่จะได้เงินเดือนแสน ก็จะทำงานได้มากกว่าคนเงินเดือนหมื่นกว่านับสิบคนด้วยซ้ำ (จริงๆ ปกติเลยล่ะ) แถมปัญหาน้อยกว่ามาก ทะเลาะก็ทะเลาะคนเดียว เถียงก็เถียงคนเดียว สอนก็สอนคนเดียว ความยุ่งยากเรื่องประกันสังคมหรือเรื่องอื่นๆ ก็จัดการให้คนเดียว แทนที่จะเป็นสิบคน

"คนเก่งพอที่จะให้เงินเดือนระดับนั้นได้ มันมีน้อย เขาถึงตั้งระดับนั้นหรือสูงกว่านั้น เพื่อให้ได้คนๆ นั้นมา"

หลายคนที่ผมรู้จัก นี่ถ้าเรียก 60-150k ผมรู้สึกว่า "สมเหตุผล"

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

ในขณะเดียวกัน .... อีกหลายคนที่ผมรู้จัก จะเรียก 15k หรือแม้แต่น้อยกว่า 10k .. ต่อให้ 7k เลยก็ได้นะ .. ผมยังรู้สึกว่า "โคตรแพง" และ "ไม่สมเหตุผลเอาซะเลย" ... ที่ร้ายกว่านั้น บางคน "ยังควรจ่ายค่าเล่าเรียนการทำงานในชีวิตจริงด้วยซ้ำ"

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

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

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

สิ่งเดียวที่อัตโนมัติ คือ "ตกงาน"

เมื่อปี 62 ผมได้มีโอกาสอ่านข้อความนึง จากกระทู้ที่โพสถามเรื่อง

"เงินเดือน กับ ความสามารถ และ ความรับผิดชอบ"
แล้วก็มาเจอคอมเม้นนึงซึ่งผมคิดว่าตอบได้ครบแทบจะทั้งหมด

ปี 63 ก็เอามารีโพส
ปีนี้ (64) ก็เจอเรื่องเดิมอีกแล้ว

จึงอยากนำมาแบ่งปันกันครับ

----------------------------

อันนี้ผมเคยบอกแล้วว่า เงินเดือน ไม่เกี่ยวกับ skill เลยซะทีเดียว มันมีปัจจัยหลายอย่าง

หลักๆคือ มันคือความพอใจของคนจ่าย ที่เค้าได้ผลประโยชน์ตามที่เค้าต้องการครับ

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

กลับกันคนที่เขียนโปรแกรมเก่งระดับหนึ่ง อาจจะได้เงินเดือนมากกว่าคนแรกสองเท่า เพราะเค้าทำงานในจุดที่ spotlight สาดแสง เลยทำให้มีความสำคัญ

คนที่สาม อาจจะเขียนโปรแกรมได้น้อยกว่าสองคนแรก แต่เค้าทำงานในบริษัทที่รายได้มากกว่าสองบริษัทแรก 50 เท่า เลยได้เงินเดือนมากกว่าคนแรก 10 เท่า

ทั้งหมดจึงขึ้นอยู่กับปัจจัยต่างๆ ซึ่งส่วนตัวผมเรียงลำดับความสำคัญดังนี้

- สถานะทางเศรษฐกิจของบริษัท
- ความสามารถในการแก้ปัญหาทางธุรกิจ(ไม่ใช่แค่แก้ปัญหาในการเขียนโปรแกรม)
- ความจำเป็นของงานต่อธุรกิจ
- มาตรฐานทางเงินเดือนของประเทศ
- ความเก่งในการ code ของคนคนนั้น

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

อย่าลืมว่าทุกบริษัทต้องการผลกำไร ไม่ใช่ product ที่โคตรเจ๋ง 100% code coverage แต่ไม่มีผลกำไรเลย

ผู้เขียน
Mahasak Pijittum

--------------------------

ที่จริงน่าเอาไปเรียบเรียงเขียน Blog มาก แต่ยังขี้เกียจอยู่ เอาไว้หายขี้เกียจค่อยว่ากันใหม่

และสุดท้ายนี้ "อย่าลืมว่าทุกบริษัทต้องการผลกำไร ไม่ใช่ product ที่โคตรเจ๋ง 100% code coverage แต่ไม่มีผลกำไรเลย"

อีกหนึ่งวันจะทำงานที่ใหม่นี้ครบปีแล้ว (ซึ่งจนถึงตอนนี้ก็ยังไม่เคยเข้าออฟฟิศเลยแม้แต่ครั้งเดียว) แต่ถึงเวลาจะผ่านไปแค่ปีเดียว ประสบการณ์นี่เยอะกว่าทำงานอื่น ๆ ในชีวิต 5 ปีซะอีก เรียกว่าแฮปปี้มากที่ได้มีโอกาสทำงานกับบริษัทที่ Professional ระดับนี้ ได้เรียนรู้อะไรเยอะเลย
.
เลยขอใช้โอกาสนี้มาจดบันทึกชีวิตการเป็นพนักงานง่อย ๆ ในบริษัทยักษ์ใหญ่สักหน่อยนึงว่าได้เรียนรู้อะไรมาบ้าง =)
.
1) เวลาทำงานไม่ใช่ Metric ที่เหมาะสมในการวัดผลงาน การวัดประสิทธิภาพผลงานด้วยตัวงานนั้นส่งผลดีต่อทุกสิ่งกว่ามาก
.
2) เพศ อายุ เชื้อชาติ หน้าตา สัดส่วน ไม่เคยส่งผลต่อความเก่งของใครเลย มาอยู่นี่ไม่เคยมองว่าโปรแกรมเมอร์หญิงไม่เก่ง ไม่เคยมองว่าอายุน้อยจะไม่เก่ง นี่มีกฎห้ามถามอายุด้วยซ้ำไปเพื่อไม่ให้เกิด Bias
.
3) จงเชื่อว่าทุกคนมีจุดประสงค์ที่ดีเสมอแล้วจะดีเอง ต่อให้การกระทำนั้นทำให้เรารู้สึกไม่ชอบ ก็จงมองให้มันเป็นการกระทำที่มาจากจุดประสงค์ที่ดี
.
4) Blameless เป็นวัฒนธรรมที่สำคัญมาก การไม่หาตัวคนผิด การไม่กล่าวโทษตัวตนแต่ใช้วิธีอุดปัญหาที่ระบบ
.
5) การดราม่าเป็นเรื่องที่ไร้สาระและไม่มืออาชีพที่สุดแล้ว ตั้งแต่ทำงานที่นี่มาไม่เคยเจอดราม่าในที่ทำงานเลยแม้แต่ครั้งเดียว ทุกคนให้เกียรติกันคุยกันด้วยเหตุผล และนั่นทำให้งานเดินอย่างมีประสิทธิภาพมาก
.
6) มีอะไรก็จงคุยกัน ไม่พอใจก็พูด ไม่เห็นด้วยก็พูด งานคืองาน ไม่คุยกันแล้วงานมันจะสำเร็จได้ยังไง
.
7) วัฒนธรรมการให้และการรับ Constructive Feedback ก็เป็นอีกอย่างในการทำให้ทุกคนเก่งขึ้นไปพร้อม ๆ กับสังคมการทำงานที่ดีขึ้น และ Constructive Feedback ก็ไม่ใช่การด่าแหลกแล้วอ้างว่าติเพื่อก่อ มันเป็นการกระทำที่ราคาถูกและไร้ค่า
.
8) คนเก่งจัด ๆ ไม่ได้แปลว่าจะเป็นสุดยอด Asset ของบริษัท สกิลทำงานเป็นทีมต่างหากที่สำคัญกว่ามาก
.
9) สกิลการสื่อสารเป็นสิ่งที่ "ต้องมี" ในการทำงานอย่างมืออาชีพ ไม่ใช่สิ่งที่มีก็ดี แต่มันต้องมี
.
10) เงินเดือนสูงสำคัญ(มาก)นะต่อการทำให้คนตั้งใจทำงานและอยากเก่งขึ้น ไม่ใช่เพราะกลัวตกงาน แต่มันทำให้โฟกัสงานได้อย่างเต็มที่ต่างหาก
.
11) Manager ไม่ได้ทำตัวเป็นหัวหน้าและอยู่เหนือกว่า Engineer แต่เป็นคนที่ทำอีกหน้าที่นึงเท่านั้น สุดท้ายทุกคนคือเพื่อนร่วมงานที่มีปลายทางเดียวกันคือการทำงานให้สำเร็จ การให้ Feedback ไปมาเป็นเรื่องปกติมาก
.
12) การทำงานหนักมาก ๆ ไม่ใช่สิ่งที่บริษัทใหญ่ของเมกันต้องการ แต่เค้าต้องการให้เราพักผ่อนและมีชีวิตของตัวเองด้วย "การพักผ่อนเป็นส่วนนึงของการทำงาน"
.
13) Fundamental คือทุกสิ่งสำหรับงาน Engineer ฐานแน่นฝึกได้ทุกอย่าง แต่ฐานอ่อนก็คือไปต่อยากมาก ความต่างของคนที่เก่งขึ้นไม่หยุดกับคนที่วนอยู่กับที่อยู่ที่ตรงนี้เลย (เห็นคนไทยเถียงกันว่าทำไมต้องรู้ว่า Quick Sort ทำงานยังไงไปทำไมถ้าโหลดมาใช้ก็จบแล้วก็ช่างปวดใจ)
.
14) ความสามารถในการเรียงลำดับความสำคัญ (P0-P3) เป็นอีกสกิลที่สำคัญสำหรับคนทำงานในทุกระดับหน้าที่
.
15) งานโปรดักส์มันไม่มีคำว่าเสร็จสมบูรณ์ (เพราะมัน Subjective) มันมีแค่ Ready to Launch หรือยัง ต้องรู้จักวางแผนว่าอะไรเป็นงานที่ Blocked ส่วนไหนเป็น Non-Blocked จะได้วางแผนการ Deliver ให้ตรงตาม Deadline ให้ถูก
.
16) จงให้เครดิตทุกคนกับทุกสิ่งที่เค้าทำ ถึงจะเป็นเรื่องเล็ก ๆ น้อย ๆ แต่ก็ช่วยทำให้บรรยากาศการทำงานดีมาก ๆ การขโมยเครดิตถือเป็นสิ่งที่ร้ายแรงมาก ห้ามทำเป็นอันขาด
.
17) การประชุมให้มีประสิทธิภาพต้องอาศัยการจัดการที่ดี การประชุมที่ดีจะช่วยลดเวลาทำงาน การประชุมที่ไม่ดีจะเป็นการเสียเวลาทำงาน จะประชุมต้องรู้จักวางแผนและควบคุมให้ดี
.
18) การประชุมที่ดีต้องมีเวลาล็อคไว้ชัดเจนและห้ามเกินเวลา
.
19) คนที่นี่ขยันเก่งขึ้นตลอดเวลามากทั้ง ๆ ที่งานเยอะมากอยู่แล้วก็ยังหาเวลาฝึกตัวเองเพิ่มได้อีก สุดท้ายคือทุกคนมีความสามารถในการบริหารเวลา ถือเป็นอีกสกิลที่ทุกคนควรมี
.
20) สำหรับสายงาน Software Engineer หลังจากลาออกจากที่นึงก็แทบจะได้งานใหม่ในอีกที่นึงทันที
.
21) การถูกรายล้อมด้วยคนเก่งจะช่วยให้เราเก่งขึ้นเองได้จริง ๆ
.
ไม่รู้ว่าโชคดีหรือโชคร้ายที่เริ่มงานปุ๊บก็ WFH ปั๊บ แต่ต้องบอกเลยว่าเพราะ WFH นี่แหละเลยได้เรียนรู้อะไรเยอะกว่าปกติมาก (โดยเฉพาะวิธีการทำงานและการจัดการเวลาของตัวเอง) ไม่รู้จะได้เข้าออฟฟิศเมื่อไหร่ ตลอดปีที่ผ่านมาเคยเจอเพื่อนร่วมงานตัวเป็น ๆ แค่ 3 ครั้งเอง แต่คิดว่าถ้าได้เข้าออฟฟิศคงได้เรียนรู้อะไรมากกว่านี้อีก
.
รออย่างใจจดใจจ่อ ไว้เจอกันน้าออฟฟิศคุงงง =)

มันลำบาก บ้าเนราอยากได้คนเก่งแต่ไม่มีงานดีๆให้คนเก่งมันทำ

https://discord.gg/69z5u4Z5

หลายคนที่เขียนบทความ หรือพูดทำนองว่า เขียนโปรแกรมไม่ยาก เขียนไม่กี่บรรทัด ง่ายๆ ก็ทำเงินได้สารพัดแล้ว ว่าไม่จะเป็นตั้งบริษัทมูลค่าหลายล้าน ไปถึงได้งานประจำเงินเดือนหลายหมื่น ....
พวกนี้ไปดูดีๆๅ นี่ หลายคน ขายคอร์สเขียนโปรแกรม คอร์สเขียนโค้ด .... เอาเงินหรือ “ความรวย” มาล่อให้คนไปเรียน
พูดถึงคนที่หลงไปเรียนกับพวกนี้ ... แล้วก็นึกถึงน้องคนหนึ่งที่เคยมาสมัครทำงานกับผม ...
เคยมีน้องคนหนึ่ง ไปเรียนกับพวกนี้ .... มาสมัครงาน ขอเงินเดือน 70,000 ... ตามคำโฆษณาเชิญชวน ....
น้องเล่าว่า น้องถูกชมจากคนสอนมากมาย ว่าเก่งมาก
ตามธรรมเนียมของการสมัครงาน ก็ให้ลองเขียนโปรแกรมเล็กๆ ดูขำๆ .... น้องก็เขียน Java ตามที่เรียนมาจากที่นั่น .... แต่น้องเขียนทุก Method เป็น Static หมดเลย (น้องเขียนแบบอื่นไม่เป็นเลย) ...
เท่าที่ผมดูจากเอกสารที่น้องเรียน ... คือที่เขาสอนมา ก็สอนแบบ C แล้วเขียนคลาสครอบ Procedures ทั้งหลาย .... มันก็เลยต้องเป็น Static ไม่งั้นใช้ไม่ได้ (อันนี้ผมดูเองจากเอกสาร น้องไม่ได้อธิบายแบบนี้)
ไม่ต้องพูดถึง algorithm หรือพวก abstraction design ต่างๆ นะ เอาแค่เรื่อง technical ของการใช้ภาษาโปรแกรมแบบพื้นฐานล้วนๆ ก็ไม่ผ่านแล้ว
น้องคิดว่า เป็นงานไม่ยาก วันๆ นั่งเปิดนั่งลอก Stackoverflow ให้มันทำงานได้ก็พอแล้ว เขียนยังไงก็ได้ ความเข้าใจอะไรไม่ต้องมีมาก นอกจากให้มันทำงานได้พอ .... และก็ได้เงินเดือนเยอะๆ

>>220 มีเยอะแยะ แต่ส่วนมากไอ้ที่เก่ง เก่งแต่ปากน่ะ เขียนจริงไบ้แดก

บางที ก็จะเจอ CTO ที่รู้จักเทคโนโลยีเดียวในโลกนี้ นั่นก็คือ SAP
เจอ CIO ที่ไม่รู้ว่า Big Data คืออะไร และต้องทำอะไรบ้าง
เจอ Data Team Lead ที่แยกไม่ออกระหว่างงาน DE กับ DS
และเจอ CEO ที่ปล่อยให้แต่ละโครงการกระจัดกระจาย จนสุดท้ายเหมือนทำโครงการทิ้งไปเฉยๆ เลย

- ฝั่ง backend ใช้ go ethereum กับ truffle abigen
- ฝั่ง frontend ใช้ Vue หรือ React กับ web3.js หรือ ether.js
- ถ้าจะใช้ Typescript แบบผมก็ใช้ typechain ในการ generate type
- ผมใช้วิธีสร้าง pattern ในการ develop เองเนื่องจากอยาก develop ทั้งฝั่ง golang และ frontend ไปพร้อมๆกัน ให้เป็น pattern เดียวกัน เลยไม่ได้ใช้ Hardhat แต่เห็นหลายๆคนใช้ก็น่าจะดี แต่ผมไม่มีความเห็น
- ใช้ Ganache develop local และ run test กับ local
- ใช้ jest run test ฝั่ง frontend
- ใช้ testify run test ฝั่ง backend
- ทำความเข้าใจเรื่อง wei และ eth และเรื่องจุดทศนิยมต่างๆให้ดี mathematics บน blockchain เราทำกันบน integer ขนาด 18 digits ไม่ได้ทำกับ floating point
- ทุกๆ concept ที่ทำใน solidity ให้เขียน test ทั้งฝั่ง backend และ frontend ทุกๆ concept อย่าคิดว่าไม่เทสแล้วจะรอด อันนี้ Defi นะ พลาดก็หมดตัวได้เลย
- ถ้ายังไม่เคยทำเลย ให้ทำจนกระทั่งสามารถ deploy ERC20 โดยใช้ contract จาก OpenZeppelin ให้ได้ซักตัว และทดลอง connect จาก backend หรือ frontend ก่อนก็ได้ จะเริ่มเห็นทางไป
- พอ deploy contract แรกได้แล้ว ก็มาไล่ test concept ไปทีละ concept เรียงตามลำดับข้อ 1-8 ในรูป
- หลังจากได้ concept ของ solidity แล้ว ก็มาไล่ test defi building block ตามข้อ 9-16 ในรูป
- หลังจากได้ concept ของ defi building block แล้ว ก็เริ่มคล่องแล้ว ก็จะลองสร้าง project ซักตัว หรือจะลองเขียน contract เชื่อมต่อ Dex, Lending บน chain ซัก chain (แนะนำเริ่มกับ BSC)
- การทดสอบเชื่อมต่อ กับ protocol ต่างๆให้ลอง ทำตาม ข้อ 17-20 ตามในรูปก็ได้
- หลังจากนั้นให้เทียบ code ตัวเองกับ code ของ Protocol ที่ดังๆแล้วจะได้รู้อะไรเพิ่ม แล้วก็สามารถ research เป็นหัวข้อๆได้แล้ว
- ถ้ามาถึงจุดนี้คุณจะกล้าที่จะท่องยุทธภพแล้ว จะไป fork protocol มา improve หรือจะเขียนใหม่ขึ้นมาในสิ่งที่ไม่เคยมีก็ลุยเลยครับ
- ถามว่าจะมี course แบบ step by step สไตล์ผมไหมก็คงมี แต่ตอนนี้ขอเคลียล์งานก่อน ปลายปีงานเข้าเต็มเลย

การตัดสินใจที่ดีที่สุดในปี 2021:
1) ลาออกจาก Facebook โดยยังทำงานอยู่ไม่ครบปี: ทิ้งหุ้นมูลค่า 2 ล้านกว่าบาทที่นอนอยู่เฉยๆอีกเดือนเดียวเป๊ะๆก็จะได้ แถมยังต้องจ่ายเงิน signon คืนอีก 3 แสนกว่าบาท
ลาออกจาก Facebook นี่น่าจะเป็นการตัดสินใจที่แทบจะดีที่สุดในรอบ 10 ปีของชีวิต สุดท้ายบางทีเงินที่ไหร่ก็ไม่คุ้มสุขภาพจิต ยิ่งตอนนี้ได้คุยกับคนที่ทั้งทำงานอยู่ Facebook ปัจจุบัน และคนที่ลาออกมาแล้ว ทั้งคนไทย และคนที่เคยอยู่บริษัทเดิมหลายคน แทบจะพบว่าคนที่อยู่ Facebook แล้วมีความสุข แทบจะมีแค่คนที่แบบเข้าตั้งแต่จบใหม่แล้วเข้าใจว่าโลกการทำงานใน Tech Industry มันเป็นแบบนั้นเท่านั้น เกือบทุกคนที่เข้าไปใหม่จากที่อื่นที่เข้าไปเป็น IC (คนที่ไม่ใช่ manager) ยังแทบไม่เจอใครที่แฮปปี้กับ Facebook เลย
มีหลายคนพูดกระทั่งว่า “ต่อให้อยู่ได้โปรโมตขึ้นเงินเดือน ก็ไม่ได้ทำให้ชีวิตมีความสุขขึ้น” “รู้สึกว่าย้ายไปทีมอื่นก็คงไม่ช่วยอะไร”
ถ้าไม่ได้พึ่งจบใหม่ ขอแนะนำ อย่าไปทำงาน Facebook! (แต่ก็ควรสัมภาษณ์นะ TC ค่อนข้างสูงเกือบที่สุดในตลาด ถ้าได้ก็เอา Offer ไปต่อบริษัทอื่นพอ แต่อย่าไป 55)
ส่วนใครอยู่แล้วไม่ happy มาขอคำแนะนำได้ 555
2) ลาออกมาหางานเป็นอะไรที่คุ้มค่าอยู่:
ด้วยความที่ตลาด Tech Industry ในอเมริกาช่วงนี้มันฮ็อดมาก (โดยเฉพาะสำหรับ Software Engineer) การลาออกแล้วตั้งใจหา offer หลายๆที่ไปต่อรองราคาเป็นอะไรที่เผลอๆจะได้เงินเท่ากับนั่งทำงานไปอีกหลายๆเดือน ที่สัมภาษณ์ไป 50 บริษัทหลายๆแบบ (funding stage + industry) นี่ก็ทำให้ได้เรียนรู้อะไรเยอะอยู่ว่าบริษัทแบบไหน culture เป็นยังไง จ่ายได้แค่ไหน แล้วเราอยากไปไหน เอาอันที่ได้เงินเยอะๆแต่ไม่อยากไปมาปั่นๆ ค่าตัว
ส่วนตัวรู้สึกว่าตอนที่ลาออกมา 2-3 เดือน ต่อราคาไป ต่อราคามา ปั่นๆราคาแบบฉลาดๆก็ได้เงินคืนเท่ากับถ้าใช้เวลาตอนนั้นนั่งทำงานแล้ว
3) สุขภาพจิตเป็นเรื่องสำคัญ:
การทำงานอยู่ที่ๆ work culture แย่ๆนานๆส่งผลต่อชีวิตเยอะอยู่ ยิ่งอยู่ไปก็ยิ่งความมั่นใจตกต่ำ เห็นตัวอย่างจากคนอื่นด้วยเหมือนกัน ที่แบบดูเปลี่ยนไปเยอะมาก เพราะ toxic environment เพราะฉะนั้นใครอยู่ที่ๆแย่ๆก็ลาออกเถอะ เงินบางทีมันก็หาใหม่ได้ ถ้าเรามีความมั่นใจ มีสุขภาพจิตที่ดี
==
Area of Improvement:
1) รู้สึกปีนี้เป็นปีจัดการความสัมพันธ์กับคนรอบตัวได้ไม่ค่อยดีเท่าไหร่​
2) รู้สึกเหมือนได้เจอคนทั้งตัวเป็นๆและ virtually น้อยกว่าที่อยากให้เป็น (เพราะฉะนั้นใครอยากคุยอะไรก็ตามทักมาได้เลย 55)
3) สุขภาพ บลาๆ (แต่ใครทักมาขายของหรือเนียนขายของ ขออนุญาต unfriend 55)

ต่อจากโพสที่แล้ว โพสนี้จะพูดถึงว่า Culture ของ Facebook แย่ยังไงถึงทำให้ตัดสินใจลาออก แต่ในทางตรงข้ามทำไมก็ยังเชื่อว่า Facebook ก็ยังจะสามารถจ้าง Engineer เก่งๆได้

หมายเหตุ: บางอันอาจจะเว่อร์ไปหน่อย และไม่จริงในหลายๆทีม แต่อันนี้รวบรวมจากที่ประสบพบเองและที่ฟังมา

สิ่งที่ไม่ชอบ:
1) การตัดสินว่าใครจะได้เลื่อนขั้น ใครจะโดนไล่ออก แทบจะวัดด้วยอย่างเดียวคือ impact
- ซึ่ง impact เนื่องจากมันเป็น OKR ก็คือต้องวัดได้ เพราะฉะนั้นคุณจะแบบไม่ช่วยใครอะไรทั้งสิ้นก็ได้ เขียน code ห่วยยังไงก็ได้ hacky ยังไงก็ได้ (ตราบใดที่ยังมีคนกด code review ผ่านให้) แต่ถ้าคุณทำสิ่งที่วัดได้นั้นให้มันดี improve metrics ได้ ด้วยวิธีใดๆก็ตาม คุณก็จะได้เลื่อนขั้น แต่ในทางตรงข้าม ถ้าคุณเขียน code ได้ดีแต่ไม่มี metrics รองรับ คุณก็จะไม่ได้ promote และอาจจะโดน PIP + ไล่ออกในไม่ช้า
- ได้ข่าวว่าบางคน manager บอกมาเลยว่า "ถ้าทีมอื่นให้ช่วยทำอะไร อย่าไปช่วยเค้า การช่วยทีมอื่นจะไม่ช่วยให้คุณได้เลื่อนขั้น"

2) ไม่มี ownership code ที่ชัดเจน​
- ในหลายๆบริษัทเช่น Quora ทุกอย่างจะมี DRI หรือพูดง่ายๆคือเจ้าของ Code ที่คอยดูแล แต่ที่ Facebook แทบทุกอย่างอาจจะมีทีมที่ดูแล แต่ทีมก็อาจจะใหญ่มาก หรือหลายๆส่วนก็คือไม่มีเจ้าของเลย การที่มีเจ้าของร่วมเยอะๆและไม่มีคนต้องรับผิดชอบ ทำให้ทุกคนไม่มีใครแคร์ว่าของมันจะดีมั้ย ยิ่งคุณภาพของ code เป็นสิ่งที่วัดไม่ได้ง่ายๆ ยิ่งไม่มีคนสนใจ เพราะสนใจไปก็ไม่มี "impact" แม้ว่า Facebook แกนหนึ่งในการพิจารณาก็คือ engineering excellece แต่เอาเข้าจริง อะไรที่วัดไม่ได้ คนก็จะไม่สนใจ เพราะมันไม่มีผลอะไรกับชีวิต

3) ความคาดหวังว่า Senior Engineer จะต้อง lead project ทั้งในทาง technical และ non technical
- สิ่งที่สำคัญที่จะทำให้ได้เลื่อนขั้นโดยเฉพาะจาก Senior -> Staff++ ที่ Facebook คือคุณจะต้อง lead project ขนาดใหญ่ขึ้น scope กว้างขึ้น แต่ถ้าของมันก็มีอยู่เท่าเดิมจะเกิดอะไรขึ้น? สิ่งที่เกิดขึ้นก็คือทุกคน ตั้งตัวเองเป็นหัวหน้า คอยสั่ง คอยกดดันให้คนอื่นทำทุกสิ่งที่ตัวเองสัญญาไว้ใน OKR เพื่อที่ตัวเองจะได้ promote ไปเรื่อยๆ กลายเป็นว่าทุกคนอยากสั่งคนอื่น แต่ไม่มีใครอยากทำอะไร
- "เพราะการทำอะไรหนะ มันเป็นงาน E3-E4 แต่การสั่งชาวบ้านหนะมันเป็นงานของ E5+"

4) manager ไม่มีหน้าที่กันเราจากทีมอื่น
- ในที่อื่นๆที่เคยทำมาปกติถ้ามีคนมาสั่งเราในงานที่ไม่เกี่ยวข้อง manager มักจะช่วยปกป้องเรา หรือไปเคลียกับคนอื่นให้ แต่ที่ Facebook ที่พบมาคือ manager ไม่มีความเข้าใจด้าน technical และไม่มีความคาดหวังที่จะต้องเข้าใจด้วยซ้ำ (เป็น people management ล้วนๆ) เพราะฉะนั้นเค้าก็จะแบบเหมือนเป็นที่ปรึกษาชีวิตแบบได้แต่บอกแบบ "สู้ๆนะ" แต่ช่วยอะไรแทบไม่ได้ พอรวมกับข้อ (3) ก็ยิ่งแย่ไปกันใหญ่

5) code quality นรกมาก
- อาจจะไม่น่าเชื่อ แต่ส่วนตัวเชื่อว่าบริษัทอื่นๆแม้แต่บริษัทเล็กๆในไทยก็น่าจะ code quality ดีกว่าใน Facebook ซึ่งแย่เพราะไม่มีใครแคร์ ถ้าเปิด code Facebook ดูจะเห็นความก็อปแปะ ทุกอย่างเละแทะมาก
- "แต่จะสนใจไปทำไมหละ ตราบใดที่ยังมี impact เราก็ได้ promote ยิ่ง code ไม่มี ownership ด้วยก็ไม่ใช่หน้าที่เราในการไปทำให้มันดีขึ้น"

6) สิ่งที่เรียนรู้ไม่สามารถนำไปใช้ในงานต่อไปได้
- ข้อนี้จริงๆอาจจะเป็นบริษัทใหญ่ๆแทบทั้งหมด คือ tool/abstraction ต่างๆ ของ Facebook คือมีของตัวเองหมด เพราะฉะนั้นถ้าย้ายงานก็เหมือนที่เรียนรู้ไปแบบศูนย์เปล่า คือคนอาจจะบอกว่า concept ต่างๆมันก็เอาไปใช้ในงานต่อๆไปได้ แต่คือมันก็คงได้สักแบบ 20% อะไรงี้มั้ง ซึ่งแบบการเรียนรู้อะไรก็รู้สึกเสียเวลาเปล่ามากๆ

===

แล้วทำไมยังเชื่อว่า Facebook ก็ยังจะสามารถจ้าง Engineer เก่งๆได้
1) รวย
- ข้อนี้จริงๆสำคัญแทบจะที่สุดในโลกทุนนิยม Facebook จ่ายได้ไม่อั้น จ้างคนเก่งๆได้ไม่จำกัดมาทำงานโง่ขนาดไหนก็ได้ อยากได้อะไรก็เปย์ๆๆ แล้ว benefit perk อื่นๆก็สู้กับทุกคนได้หมดจริงๆ ไม่ใช่แค่เงินเดือน แต่ประกันสุขภาพ ออฟฟิศและอื่นๆ ก็สู้ได้จริงๆ

2) ชื่อเสียง
- เอาจริงๆใน FAANG Facebook ก็น่าจะเป็นอันที่ชื่อเสียงด้าน engineer ดูดีเป็นอันดับต้นๆ การมีชื่อ Facebook แปะก็มีคนสนใจมากมาย ไปทำอะไรต่อในอนาคตก็ง่ายจริงๆ

3) culture fit
- สิ่งที่เป็นข้อเสียที่ว่ามาทั้งหมด ความวุ่นวายแบบนี้ก็คงมีคนชอบแหละ ยิ่งคนที่อยู่ใน Facebook มาตั้งแต่จบใหม่ก็อาจจะไม่รู้สึกว่าที่ว่ามาเป็นปัญหาอะไรด้วยซ้ำ เผลอๆถือว่าเป็น feature ของบริษัท เพราะถ้าแบบ exploit ตรงนี้ได้ก็เจริญก้าวหน้ารัวๆได้เลย E6-E7 ไม่ไกลเกินเอื้อม แต่ส่วนตัวอยู่แบบนี้ไม่ได้จริงๆ

Kittidaze Panklang ถ้าให้ตอบตรง ๆ ก็คงตอบว่าใช่ครับ

โลก Technology มันจะมี Stage ของม้น ถามว่าเทคจะมามั้ย มาสิ เพราะมันมีคนทำ (เฟส Early Adopter) และถ้ามีเจ้าภาพ มันก็คงถูกผลักไปเฟส Minor และ Major เพื่อพิสูจน์ตัวมัน ซึ่งนี่แหละที่ท้าทายเพราะเทคส่วนใหญ่ตายตั้งแต่ Minor ด้วยสาเหตุเดียวกัน "มันใช้ยาก"

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

ถัดจากความง่ายก็มี "ความไม่กลัว" อีก คือถ้าการเก็บ Seed ไม่เป็นสามารถสร้างความเสียหายที่คนส่วนใหญ่ยอมรับได้ยาก คนก็จะกลัวไม่กล้าใช้ ซึ่งตรงนี้จะทำให้ไม่สามารถทลายอีกกำแพงเรื่อง "ความไม่แพงในการใช้งาน" ได้

เหตุผลเดียวกันนี้ก็จะตอบได้ว่าทำไมคนถึงเลือกใช้ Binance มากกว่าสร้างกระเป๋ามาใช้เองหลายเท่า ง่าย ไม่แพง ไม่น่ากลัว

สั้น ๆ คือเทคโนโลยีมันไปต่ออยู่แล้วครับ ปัญหาคือ Adoption ที่จนถึงตอนนี้โลก Blockchain ก็ยังทำได้ไม่ดี

มีหลายคนถามว่า จะเปิดสอน Maths สำหรับเด็กประถมมัธยมบ้างไหม อยากส่งลูกมาเรียนด้วย (โดยที่คุณพ่อคุณแม่ที่ถามส่วนมาก ยังไม่เคยเรียนกับผมมาก่อนนะ)
คำตอบง่ายๆ คือ "ไม่" ครับ
คำตอบยาวกว่านั้นคือ "ไม่ครับ นอกเสียจากว่าคุณพ่อคุณแม่เข้าใจดีแล้วว่าลูกจะได้เรียนอะไร และไม่ควรคาดหวังอะไรที่ไม่ควรคาดหวัง โดยเฉพาะเรื่องที่เกี่ยวกับการคำนวนหรือผลสอบ .... ถ้าจะให้ดีคุณพ่อคุณแม่อาจจะเคยมาเรียน Maths กับผมก่อนสักคลาส หรือฟังผมพูดทัศนคติต่อ Maths เสียก่อน"
พูดอีกอย่างคือ อย่าหวังว่าผมจะสอนทำโจทย์ อย่าคาดหวังว่าผมจะสอนให้คิดคำนวนได้เร็วขึ้น หรือมีสารพัดทริกสำหรับสารพัดสถานการณ์ .... ซึ่งนั่นเท่ากับการเรียน algorithm สำหรับ specific problem ต่างๆ รวมถึง optimization ของ algorithm เหล่านั้น ในกรณีที่ตัวเลขหรือองค์ประกอบบางอย่างของโจทย์มีค่าจำเพาะเจาะจง ... ให้สามารถคำนวนได้เร็วขึ้น ใช้หน่วยความจำน้อยลง (หน่วยความจำในสมอง หน่วยความจำในกระดาษทด)
ตรงกันข้ามเลย ทัศนคติส่วนตัวผมคือ ยิ่งเราไปสนใจ "specific algorithm" และ "calculation optimization" เท่าไหร่ เรายิ่งห่างไกลจากคณิตศาสตร์เท่านั้น
มาเรียนกับผม นี่อาจจะทำโจทย์ข้อสอบทั่วไปช้าลงนะ อาจจะไม่ได้คำนวนอะไรเลยนะ บอกไว้ก่อน
เพราะสิ่งที่จะได้ คือ การกลับมามองคณิตศาสตร์ในฐานะภาษาในการสื่อสาร มากกว่าเครื่องมือในการคำนวน .... เพียงแค่ตัวภาษานี้บังเอิญมันเอาไปใช้คำนวนได้เท่านั้นแหละ .... ไม่ต่างอะไรเลยกับเรียนดนตรี ทฤษฎีดนตรี ที่สื่อสารด้วยตัวโน๊ต ที่บังเอิญมันเอาไปเล่นได้ ....
ถ้าเทียบกับการเรียนดนตรี สิ่งที่จะได้เรียนคือทฤษฎีดนตรี การสื่อสารด้วยเสียง การสื่อสารด้วยโทน การใช้เสียงและโทนต่างๆ ในการสื่อสารความหมายต่างๆ .... มากกว่าการฝึกเป็นนักดนตรี ที่เน้นเล่นดนตรีให้ได้ถูกต้องและแม่นยำ
แน่นอนว่ามันหนีการคำนวนไม่พ้นหรอก แต่เราสอนเรื่องพวกนี้กันเยอะแล้วจนผมไม่น่าจะต้องไปสอนอะไรซ้ำ .... แต่ผมสามารถทำให้เห็นได้ว่า การที่เราเข้าใจคณิตศาสตร์ในฐานะภาษาดีขึ้น มันทำให้เราค้นพบวิธีการแก้ปัญหาต่างๆ ผ่าน abstraction ได้ดีขึ้นอย่างไร ..... การหา algorithm ทั้ง general และ specific .... การ transform ปัญหาจากรูปหนึ่งไปเป็นอีกรูปหนึ่งที่แก้ง่ายกว่า การหา strategy ในการแก้ปัญหา ฯลฯ
ไม่ใช่แค่ปัญหาที่ต้องคำนวนตัวเลขนะ แต่เป็นปัญหาอะไรก็ได้ ที่เราสามารถ abstract มันออกมาได้
ซึ่งแน่นอนว่า ทั้งหมดนี้ อาจจะเป็นเรื่องที่ไร้ประโยชน์สำหรับคนส่วนมากที่อาจจะสนใจการสอบ การแข่งขัน การถูกตัดสินว่า "เก่งเลข" จากการคิดเร็วคำนวนเร็ว จำสูตรได้ใช้สูตรเป็น ฯลฯ .....
บางคนเคยถามผมว่า "ถึงเรารู้แบบอาจารย์ แต่ลูกเราก็ต้องถูกวัดผลแบบนั้นอยู่ดี"
คือผมจะเรียนว่า ถ้าจะสนใจแค่การวัดผลเฉพาะการสอบครั้งต่อไป มากกว่าการนำไปใช้ตลอดชีวิต (โดยเฉพาะบริบทปัจจุบัน ที่หลายต่อหลายคนเข้าถึง "คอมพิวเตอร์" และ "การโปรแกรมคอมพิวเตอร์" ได้ไม่ยากเท่าไหร่แล้ว) ก็ "อย่าเพิ่งมาเรียนกับผมเลยครับ"
พูดอีกอย่าง คือ ถ้าอยากให้ลูกชนะในการแข่งคูณเลข อย่าส่งมาเรียนกับผมเด็ดขาด ... แต่ถ้าอยากให้ลูกมองการคูณเลขเปลี่ยนไป อาจจะมองข้ามไป หรือไม่เคยมองแบบนั้นมาก่อน หรือลืมไปแล้ว เพราะถูกสอนให้สนใจแต่ผลคูณ (ซึ่งจะให้ดีคุณพ่อคุณแม่อาจจะต้องเข้าใจเช่นนั้นก่อน) ก็ค่อยคุยกัน
Irony ของเรื่องนี้ทั้งหมดคือ ..... บางที เราสนใจ "การนำไปใช้" มากไป จนการสอนทุกอย่างมันเต็มไปด้วย application specific algorithm, calculation specific algorithm .... พอชีวิตเรามันไม่ได้เจอ "specific" เหล่านั้น แล้วมันก็เลยกลายเป็นใช้ไม่ได้น่ะแหละครับ ...
ถ้าเราสนใจความหมายของมันจากพื้นฐาน บางทีเราจะเห็น Application ต่างๆ รอบตัวไปเองครับ

เปล่าเลยครับ มันไม่เกี่ยวหรอกว่าผมนิยมอะไร

แต่มันถึงจุดที่ มันคือสิ่งที่ควรจะต้องใช้แต่กลับไม่มีให้ใช้ ต่างหาก

Benchmark ในหลายๆการทดลอง มันก็คือ Field ที่ ผมไม่ได้ใช้ในเวลานี้(และคงไม่ต้องใช้)
และอีกหลายๆการทดลองที่ Benchmark มันแพ้รูดมหาราช ดันอยู่ใน Field ที่ผมกำลังอยากจะใช้

ซึ่งผมคงไม่ต้องมาทนฝืนใช้ ถ้าหากไม่ใช่เพราะอยู่ใน Platform ที่มันบังคับ

บอกอีกทีว่าผมกำลังใช้ GAE ซึ่งถ้าไม่ใช่ Java ก็ต้อง Python

และจากกระทู้นี้ก็ทำให้ผมตัดสินใจได้ว่า ถ้าใช้ GAE ต่อไป ควรจะไปตายเอาดาบหน้ากับ Python ดีกว่า
ไม่น่าเลือกเสี่ยงกับ Java แค่เพราะเห็นว่าเคยใช้มาบ้างเลย

Java มันก็รู้ทั้งรู้ ว่าตัวเองพยายามจะให้ทุกคนใช้ตัวเองในทุกๆที่
ทั้งมือถือทั้งอะไรที่ Spec ต่ำต้อย หรืองานหนักๆอย่าง Graphic หรือคำนวนวิทยาศาสตร์
แต่กลับพยายามตัดฟีเจอร์ที่มีผลกับ Performance ออกหมด แล้วมาบอกให้โปรแกรมเมอร์ทนเอา

ตั้งแต่สมัยที่ผมไม่คิดจะอวย C# ผมก็ยังคิดว่า Java กากส์
และตอนนี้ยิ่งมั่นใจ ว่าใครที่พูดว่า Java เร็วส์ คนนั้นกำลังหลอกลวงคนฟัง

ตั้งกระทู้นี้มาผมก็ตั้งใจจริงๆนะ ว่ามีใครจะบอกว่า Java มันมีวิธี Optimize กันบ้างหรือไม่

เอาจริงๆผมก็เห็นพวกเว็บต่างประเทศ เขาก็มีแนะนำให้ใช้ BitBuffer (ที่มาถามเพราะเผื่อใครจะมีเทคนิคอะไรดีกว่านั้น)
ซึ่งจริงๆมันก็คือทำ Array ของ struct แบบปลอมๆ แต่ประสิทธิภาพก็ยังต่ำกว่านิดหน่อย แถมความง่ายในการใช้งานต่างกันหลายขุม

คนที่เผยแพร่วิธีนี้บอกว่า ต้องออปติไมซ์โปรแกรมใน Server เพราะ Java แดกทรัพยากรมากเกินไป
พอเอาวิธีนี้มาใช้ ก็ดีขึ้นมาหลายเท่า

สรุปคือ Java มันตัดฟีเจอร์ดีๆออก "เพราะอยากให้คนใช้งานได้ง่าย"
แต่พอถึงขั้นที่ยังไงๆ ก็ต้องใช้ กลายเปนคนใช้ต้องเล่นท่ายาก แถมก็ไม่ได้เรื่องเท่าภาษาอื่นเขา

Java ควรจะละอายแก่ใจบ้างนะครับ ว่าเกิดมาก่อนกี่ปีแล้ว
เอามาอวดว่า ตั้งหลาย Benchmark ที่สูสีกับ C# น่าภูมิใจตรงไหนเนี่ย

สรุปก็แค่ขี้เกียจแก้ JVM ให้มันรองรับ struct
ดีแต่กินบุญเก่า แล้วก็อ้างข้างๆคูๆไปเรื่อย งานไม่ต้องมี Performance บ้างล่ะ (มือถือล่ะ?) รักษา OOP บ้างล่ะ (สุดท้ายก็ต้องมี Primitive อยู่ดี ก่อนหน้านี้ก็จำใจต้องเพิ่ม long เข้าในระบบ)

แล้วก็มาช่วยกันออกรับแทน ไม่แย่ขนาดนั้นหรอก ไม่ต้องใช้หรอก

สาวกยังไงก็เปนสาวกจริงๆ

ขอพูดอย่างสุดท้ายว่า

ผมเห็น Java มันก็พัฒนาอะไรๆ ตามคำเรียกร้องของคนใช้ OpenJDK มี Mailing List

แต่ในเมื่อมีแต่ผู้ใช้สาวกแบบนี้ SUN พูดว่าไม่ต้องใช้ struct ก็ชาบูว่า ดีแล้วๆ ไม่ต้องใช้ๆ

แล้วก็มาปลอบกันเอง "Performance ไม่ดี? ไม่ต้องห่วงๆ Java ไม่ห่วง Performance เขียนไปตามแนวคิดเขาก็พอ"

ชาติหน้าก็คงไม่มีให้ใช้ Performance ห่วยยังไงก็ได้ เพราะมันคือ Java

ขอบคุณครับ ที่ทำให้ผมได้ซาบซึ้งกับคำว่าสาวกอีกครั้งหนึ่ง

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

ไม่เคยเห็นมีใครเคยบอกเลยวะว่าหางานใน ตปท แม่งยากชิบหาย ทั้งเรื่อง visa ภาษา และก็ leetcode

ทุกวันนี้ยื่นหางานไม่ตกเพราะ leetcode ก็ตกเพราะ ปห visa

ตอนกุอยู่ไทย ยื่นสมัครงาน แทบไม่เคยเจอ leetcode เจอก็เจอแบบง่าย นี่กุมาอยู่นี่ บ startup no name แม่งยังต้องทำ leetcode เลยไอ่ห่า

กุนับถือพวก grind leetcode จนเซียนจริงๆ

หลายๆ ท่านที่ผมเคารพนิยามคำว่าปัญหาไว้ตรงกัน
ปัญหาคือช่องว่างระหว่างสภาวะที่เป็นอยู่กับสภาวะที่อยากให้เป็น
ปัญหาจึงประกอบไปด้วย will หรือความปรารถนาอยู่เสมอ
หากไม่มีความปรารถนาอะไรเลย ก็ไม่มีปัญหา
ถ้าไม่มีความปรารถนาที่จะมีชีวิตอยู่ เป็นมะเร็ง ติดโควิด ก็ไม่ใช่ปัญหา
ถ้าไม่มีความปรารถนาจะเห็นโลกดีงาม ไวรัสซอมบี้กระจายทั้งโลกก็ไม่เป็นปัญหา
การแก้ปัญหาโดยไม่เข้าใจถึง will ที่อยู่ภายใต้ แปลว่าคุณไม่เข้าใจส่วนที่สำคัญที่สุดครึ่งนึงของปัญหาด้วยซ้ำ
เวลาที่เราเห็นว่าคนมันแก้ปัญหาแบบขอไปที มักจะเกิดจากการแก้ปัญหาอย่างไม่สนใจแรงขับแรงปรารถนาที่ตั้งตนให้เกิดปัญหามาแต่แรก
เช่น ปัญหาคือไม่มีเทสก็เขียนเทสอะไรซักอย่างมามั่วๆ อ่ะ มีแล้ว จบ
มันไม่ได้ตอบ will ที่ต้องการให้ซอฟต์แวร์เสถียร ต้องการจะเห็นผู้ใช้งานมีความสุข
การเข้าใจพลังของ will เป็นสิ่งสำคัญมาก
ในฐานะผู้นำ หากคุณเอาแต่ปัญหาไปให้คนอื่นแต่ไม่สามารถสื่อสาร will ออกไปได้ คุณก็จะเจอแต่คนที่แก้ปัญหาแบบขอไปที มันถึงได้มีคำพูดว่า ผู้นำบางคนมีพลัง มีวิชั่น คนทำงานด้วยง่าย
ในฐานะคนทำงาน คุณไม่เข้าใจ will เบื้องหลังของคนอื่น คุณทำงานแค่ไหน ก็อาจจะโดนมองว่านี่มันขอไปที ตรงข้าม ถ้าคุณมี will ที่มากพอและส่งให้คนอื่นได้ ทีมอาจจะฟังคุณโดยที่ไม่ต้องมี official authority ด้วยซ้ำ
ความปรารถนา ความหวัง เป็นสิ่งสำคัญมากในการขับเคลื่อนไปข้างหน้า
แต่กลับกัน หากไม่มีเลย ก็ไม่มีปัญหา ไม่ต้องขับเคลื่อนอะไรสบาย
อยากใช้ชีวิตแบบก้าวไปข้างหน้าหรืออยู่กับที่สบายๆ ล่ะฮะ
และสุดท้าย การมี will มี hope เป็นเรื่องที่ต้องฝึกนะ คนเราถูกฝึกให้หมดหวังได้ ก็ถูกฝึกให้มีความหวังได้เช่นกัน ผมเชื่อแบบนั้น เริ่มจากสำรวจตัวเองบ่อยๆ ครับว่าเราหวังอะไร แล้วอยู่กับมัน อย่าตีตัวเองเร็วไปว่าฝันเฟื่องไร้สาระ

>>231 บ ไทยมันห่วยไง รับตามใจฉัน 555

>>231 บ ข้ามชาติในไทยหลายที่ก็ทำ leetcode อยู่นะ
แต่ส่วนมากที่โดนให้ทำมัน พวกเงินเดือนเกือบๆ แสน ขึ้นไปไง บางที leetcode ผ่านแล้ว เสือกให้สอบเขียน essay ต่ออีกรอบ

>>234 มีหลายที่ที่ไหนในไทยบ้าง นึกออกที่เดียว

ไอ้ที่บอกว่ามี ai ตามตรวจเทรดคริปโตได้นี่จริงหรือโม้วะ

>>236 ถ้ามึงเคยทำธุรกรรมกับ wallet ที่แม่ง KYC ไว้ ก็ตามได้

>>236 ไม่ได้ใช้ ai ตรวจหรอก ใช้ excel ตรวจ ส่วนไอ้ที่ส่งยอดน่าสงสัยมาให้ก็ ธนาคารเนี่ยแหละ

>>235 มีเยอะเยะไล่ไปตั้งกะสีลมยันทองหล่อได้เลยว่ะ บริษัทฝรั่งเศสดูแลฐานข้อมูลกิจการค้าปลีกก็ทำ หรือบริษัทสิงคโปร์ทำ Marketplace ก็ทำ บริษัทลูกรถไฟฟ้ายังทำเลย

>>239 ขอเป็นชื่อได้ไหม

เมื่อวานสอน programming เบื้องต้น ให้กับ non-tech staffsในทีม โดยใช้ sequence ที่ผมชอบ (และใช้ Python, REPL)
1. value (เอาแค่ integer และ boolean) และ basic operation/computation on values (พวก +, -, *, / รวมถึง boolean operation พวก >, <, ==)
2. variables
3. function (สร้างฟังก์ชั่นใหม่ ใช้ฟังก์ชั่นใหม่เอง)
4. if-else
แล้วก็หมดเวลาทำงาน (สอนตั้งแต่ประมาณ 14:30 - 18:30)
=========================
หลายคนอาจจะคิดว่า "แปลก" ที่เอา function มาก่อนพวก logical/flow control แบบ if-else, loop .... แต่ผมมีเหตุผลหลายอย่างว่าทำไมผมชอบ sequence นี้
0. ส่วนหนึ่งอาจจะมาจากการที่พื้นฐานส่วนตัว ผม preferred functional programming มากกว่า imperative ..... และ SICP (หนังสือในตำนวนเล่มหนึ่ง) รวมถึงอาจารย์ Abelson (คนเขียน) มีอิทธิพลกับผมเยอะมากอยู่
1. values -> computations -> variables -> functions
ผมคิดว่าอันนี้มันเป็น consequential flow ที่เป็นเหตุเป็นผลและเป็นธรรมชาติที่สุดแล้ว โดยเฉพาะถ้าคิดจากมุมของ functional programming (ซึ่งเป็น preferred paradigm ในปัจจุบัน) ....
เราทำงานกับ value ... พื้นฐานของโปรแกรมมันมีแค่นี้แหละ
ถ้าเรารู้ value ตรงๆ มันก็จบ จะทำอะไรก็ทำไป ... แต่หลายครั้งเรามักจะยังไม่รู้ว่ามันเป็นอะไร แต่เรารู้แล้วว่าจะทำอะไรกับมัน ... หรือว่าเรารู้แล้ว แต่เราต้องการจะ refer ถึงมันใน scope ที่กว้างขึ้น (ใช้ซ้ำนั่นเอง)
เช่น x = 10, y = 10 แล้วจากนั้นเราก็เขียน x + y กด enter ก็จะได้ 20 .... ไปเขียนอะไรเล่นอีก 2-3 บรรทัด จากนั้นเขียน x = 30 กด enter ... แล้วก็กดลูกศรขึ้นไป 2-3 ครั้ง ... เจอ x + y กด enter ใหม่ ก็จะได้ 40 ... เป็นต้น
จากนั้นทำยังไงให้ไม่ต้องกดลูกศรขึ้นแบบนี้ไปเรื่อยๆ เพราะสิ่งที่เราอยากใช้จริงๆ ก็คือ x + y ที่เราเคยเขียนไว้แล้ว ... ก็เขียน function ซะ
มัน natural มาก .... รู้ value -> อ้างอิง value นั้นๆ เพื่อใช้ซ้ำ (value -> variables) ... รู้ computation routine -> อ้างอิง routine นั้นๆ เพื่อใช้ซ้ำ (code -> functions)
2. การเริ่มต้นที่ if-else, loop ก่อน function อาจจะเป็น preferred sequence ในอดีตเมื่อหลายปีมาแล้ว แต่ทำให้เกิดผลเชิงลบในภาพใหญ่ โดยเฉพาะในปัจจุบัน ..
เพราะมันทำให้เราลงไปคลุกอยู่กับ low-level logical flow เร็วเกินไป .... คำนวนอะไรที่ซับซ้อนขึ้นได้เร็วเกินไป ... โดยยัดทุกอย่างลงไป "main" (หรือเทียบเท่าในระดับที่เรากำลังเขียนโค้ดอยู่) ก่อนที่จะได้จัดลำดับความคิด ว่านี่เรากำลังทำอะไรอยู่
มันฝึกนิสัยให้เราข้าม layer of abstraction โดยไม่รู้ตัว มันทำให้เราไม่แยกปัญหาออกเป็นปัญหาย่อย มันทำให้เราไม่คิดว่านี่เรากำลังทำอะไรอยู่และทำไปเพื่ออะไร (และไปโฟกัสแต่ว่าจะทำมันยังไง)
fast forward มาตอนที่หลายคนเป็น professional programmer .... ก็ไม่ต้องสงสัยหรอกว่านิสัยการ "ลัดไปที่ low-level logic" ก่อน และ "ยัดโค้ดลง controller" อะไรพวกนี้ มันมาจากไหน ... มันจาก early days ในการเขียนโปรแกรมของเราน่ะแหละ
ในตอนที่ฝึก เราก็สร้างฟังก์ชั่น sum2(x, y) ง่ายๆ น่ะแหละ แล้วต่อไปฟังก์ชั่น average2(x, y) .... ที่แน่นอนว่า มันก็คือ (x+y)/2 น่ะแหละ
แต่เอ๊ะ เดี๋ยวก่อน เราจะทำอะไรนะ .... อ่อ มันคือ เอาผลรวม มาหารด้วยจำนวนที่เอามารวมกัน .... เอ๊ะ ผลรวม เรามีแล้วนี่ ก็จะเขียน sum2(x, y)/2 แทน
ย้ำหน่อย​ ..... ผมยังไม่สนใจความเร็ว หรือเรื่อง optimization ณ จุดนี้ แต่สนใจเรื่องการสื่อสารสิ่งที่ต้องการทำ ลำดับความคิด และความถูกต้องของสิ่งเหล่านั้นมากกว่า (ดังนั้นไม่ต้องบอกว่า (x+y)/2 เร็วกว่า sum2(x, y)/2 นะ)
sum2 เป็นฟังก์ชั่นที่ไม่ยาก ต่อให้ไม่ใช้ และใช้ x+y ตรงๆ ในโค้ด ทุกคนก็คงจะอ่านออกไม่ยาก .... แต่ถ้ามันเป็นอะไรที่ยากกว่านี้ซับซ้อนกว่านี้และไม่ตรงไปตรงมาแบบนี้ล่ะ?

3. แล้วมันไล่ไปหา unit testing ได้ง่ายด้วยนะ .... แบบนี้เราก็จะมี test case สำหรับ sum2 และ average2 น่ะแหละ แต่เพราะว่า average2 มันใช้ sum2 เพราะฉะนั้นถ้า sum2 มันถูก (และถูกทดสอบ) และเราเอามันไปใช้อย่างถูกต้องใน average2 ..... มันก็จะถูกไปเอง ... ถ้า sum2 มันผิด เราก็จะแก้ที่เดียว แล้ว average2 มันก็ถูกไปเอง
4. สอน if-else หลังจาก function นี่ทำให้สอนโดยใช้ function ได้ .... ว่ามันเป็น function ที่รับ boolean และ function อีก 2 ตัว .... ถ้า boolean เป็นจริง มันจะเรียก function แรกทำงาน ถ้าเป็นเท็จ มันจะเรียก function สองทำงาน ..... มัน lead ไปหา function returns function ในอนาคตง่ายๆ เลย (เจอ lambda เจออะไรพวกนี้ เจอ higher-order function จะงงน้อยลง .... เพราะเราคุ้นเคยกับมันอยู่แล้ว)
5. แถมหน่อย .... ในภาษา industrial strength เก่าๆ ที่ไม่มี type inference ... การเขียนฟังก์ชั่นมันยากกว่าการสอน if-else, loop เยอะ เพราะ syntax มัน bloat และต้องรู้อะไรเยอะเกินไป ... อันนั้นเข้าใจได้ ... แต่ปัจจุบันนี้มันแทบไม่ต้องรู้อะไรเลยมากกว่าเรื่องตัวแปรเลย syntax มันง่ายซะจนกลายเป็นว่า if-else, loop นี่ยากกว่าซะอีก 😛
=========================
จบวัน ที่ให้เขียน max2(a, b) และให้เขียน max4(a, b, c, d) .... เป็นแบบทดสอบประจำวัน
ทุกคนที่เรียน เขียน max4 แบบสวยๆ บรรทัดเดียวได้เลย ... ใช้ max2(max2(a, b), max2(c, d)) น่ะแหละ (ก็ใบ้ไปนิดอ่ะนะ ว่าคิดแบบการแข่งกีฬา จากรอบรองไปรองชิง)
เนี่ย ถ้าเราเขียน max2 ถูก (และทดสอบแล้วว่าถูก) .... แล้วเราเอามาประกอบเป็น max4 ถูก ..... max4 จะถูกโดยปริยาย ไม่ต้องมี low-level logic อะไรที่ให้มันผิดซ้ำผิดซ้อนเลย และเป็นการฝึกแตกปัญหาใหญ่ที่ยาก เป็นปัญหาย่อยที่ง่าย และเราเคยแก้ได้แล้ว อีกด้วย
นี่เป็นผลจากการให้ใช้ฟังก์ชั่นเร็ว คนจะใช้ฟังก์ชั่นและคิดใน functional terms ไม่ใช่ไป fidgeting กับสารพัด if-else ที่จะทำให้ max4 ซับซ้อน ....
ครึ่งวัน กับคนไม่เคยเขียนโค้ดเลย ได้งี้ก็แจ่มแล้ว 🙂 .... เดี๋ยวต่ออังคารหน้า ยังไม่บอกว่าอะไร (แต่ไม่ใช่ loop แน่ๆ 555)
ใครอยากให้ไปช่วยสอน non-tech staffs บ้างครับ 😃

เปิดความลับ ทำอย่างไรให้เป็นบริษัท Tech ที่ลด Turn Over Rate จาก 30% เหลือ 2% ได้ ในเวลาไม่ถึง 1 ปี
เป็นที่ทราบกันดีว่า บริษัทเทค หรือบริษัทด้าน IT มักจะมีปัญหาเรื่องพนักงาน ทั้งการหาคน และการรักษาคน ซึ่งในตลาดแรงงานทุกวันนี้ ดุเดือนกันมาก ทั้งการแย่งตัว และการให้เงินเดือนที่เฟ้อเกินความเป็นจริง
Coraline ก็เป็นอีกหนึ่งบริษัท ที่(เคย)ประสบปัญหาดังกล่าว โดยที่เราไม่ใช่แค่รับคนมาทำงาน แต่เราต้อง Train พนักงานใหม่ เนื่องจาก Service ของเรา ไม่เหมือนของที่อื่น ทุกๆ ตำแหน่งจะต้องได้รับการ Train ทั้งสิ้น เช่น Data Scientist ก็ต้องเรียนรู้การแบ่งส่วน Dev กับ Production และการรับถ่ายทอด Requirement จากทีม Business Analyst, Project Mananger เอง ก็ต้องเข้าใจ Scope ของ Big Data ให้ครบ ก่อนที่จะปล่อยไป Run งานเองได้ และต้องรู้จักการใช้เครื่องมือที่เป็น Online ทั้งหมด เราจะไม่ Track งานใน Excel แน่นอน และเราจะ Online Dashboard เพื่อ Monitor งานกับลูกค้า PM เองก็ต้องเข้าใจ step การทำงาน, Business Development ของเรา ต้องอ่าน TOR เป็น เขียน SOW ได้ และต้องออกแบบ Solution ให้ลูกค้าได้ระดับหนึ่ง ที่สำคัญ ต้องสามารถสื่อสารกับทีมหลังบ้านได้ชัดเจนในเวลาอันจำกัด เป็นต้น
การบริหารคน จึงเป็นหัวใจของเรา และเราให้ความสำคัญมาก โดยเรามีแนวทางดังนี้
1. เลือกคน ที่มีทัศนคติตรงกัน เคมีตรงกัน และเข้าใจตรงกัน
เราต้องการคนที่ชัดเจนระดับหนึ่ง เช่น รู้ว่าอยากทำตำแหน่งอะไรเพราะอะไร ซึ่งเราพบว่า หลายคนสมัครงานมาโดยที่ยังไม่รู้ด้วยซ้ำว่าแต่ละตำแหน่งทำอะไร และตัวเองสามารถทำตำแหน่งอะไรได้ อันนี้เป็นสิ่งแรกเลยที่จะทำให้รู้ว่าคนนั้นพร้อมทำงานหรือไม่ ต่อมาก็จะดูว่าถ้าเขาพบเจอปัญหาบางอย่างที่จะเจอแน่ๆ ในตำแหน่งนั้นๆ เขาจะแก้ปัญหาอย่างเรา เรามีทั้งการสัมภาษณ์ และการบ้านให้ทำก่อน แม้ขั้นตอนของเราจะเยอะหน่อย แต่มันเป็นการคัดเลือกผู้ร่วมทีมที่คุ้มค่ามากๆ ซึ่งตัวพนักงานเอง เอาก็จะได้ทำงานตามความคาดหวังของตัวเอง Win-Win กันทั้งคู่
2. Reskill / Upskill ตลอดเวลา
มีพนักงานบางคน ที่พอทำงานไปเรื่อยๆ แล้วพบว่า เขาอาจจะถนัดบางอย่างที่พึ่งจะมาค้นพบ ทีม HR และ Manangement Team ของเรา พร้อมมากที่จะให้คำแนะนำ พนักงานเองก็สามารถขอความเห็นจาก Supervisor ใน Career path ของตัวเองได้ ที่ผ่านมา มีพนักงานบางคนที่เราเสนอว่า สามารถเปลี่ยน Role ได้นะ เพราะอาจจะเหมาะกว่า และสุดท้ายเขาก็ Happy มาก กับ Role ใหม่ ถือเป้นการ Reskill ให้เขา โดยที่เขาเองก็อาจจะนึกไม่ถึง
การ Upskill เกิดขึ้นทุกวัน ทุกนาที เพราะเราทำสิ่งใหม่ๆ ทุกวัน มีการสรุป Lesson learned กันบ่อยครั้ง และถ้าพบว่ามีคอร์สอบรม หรือมีหัวข้อไหนน่าสนใจ เราก็พร้อมจะสนับสนุนให้พนักงานได้ Upskill ซึ่งทุกคนจะมีแผนในการ Upskill ตัวเอง และจะต้อง Update ให้ทราบในทุกๆ ไตรมาส
3. เราทำงานกันแบบ Sport Team
ตั้งแต่วันแรกที่เริ่มทำงาน ในการ Orientation เราจะมีขี้แจงให้ทราบว่าแต่ละตำแหน่งทำอะไร และเกี่ยวข้องกับใคร ซึ่งในการทำโครงการแต่ละโครงการ ทุกตำแหน่งจะมีส่วนร่วม และเป็นฟันเฟืองให้กันและกัน บางคนอาจจะได้อยู่โครงการเดียวในเวลาเดียว บางคนได้อยู่หลายโครงการ ขึ้นอยู่กับจังหวะ โดยเราจะมีเครื่องมือที่ Monitor Slot เวลาของแต่ละทีม แต่ละคน เพื่อกระจายงานให้เหมาะสม เราเชื่อว่าการที่ทุกคนได้ลงมือทำงาน อาจจะเจออุปสรรค แต่ผลงานของเขา จะเป็นสิ่งที่สะท้อนความสามารถของเขาที่ดีที่สุด ซึ่งผลงานเดี่ยว คงไม่เกิดขึ้น อาจจะมี Hero อาจจะมีคนที่เด่นขึ้นมา แต่สุดท้าย ตัองยอมรับว่า ทุกโครงการต้องทำกันเป็นทีม และจะไม่มีใครเด่นคนเดียวแน่ๆ ทุกคนต้องช่วยกันให้เต็มที่

4. Benefit ที่เหมาะสมที่สุด
แป้งกล้าพูดได้เต็มปากเลยว่า Rate ที่เราให้พนักงาน ไม่ว่าจะ Level ไหนก็ตาม สูงกว่าค่าเฉลี่ยของตลาดแรงงานแน่นอน นอกจากนี้ เรามีการประเมินทุก 6 เดือน หมายความว่า ถ้าผลงานคุณดีอย่างสม่ำเสมอ ใน 6 เดือน คุณก็อาจจะได้รับการโปรโมทได้ ซึ่งเราไม่ได้มีเพดานในการขึ้นเงินเดือน กล่าวคือ ไม่ต้องรอขึ้นปีละ 5% เหมือนที่อื่น ถ้าคุณได้โปรโมทให้ได้รับมอบหมายใน Role ที่สูงขึ้น ก็อาจจะสามารถขึ้นได้เกิน 50% ก็เป็นได้
นอกจาก Benefit เรื่องเงินแล้ว ที่ผ่านมา เรามีการพิจารณาให้หุ้นกับพนักงานอีกด้วย เพราะเราไม่ได้มองว่า พนักงานเป็นแค่พนักงาน แต่เรามองว่าเขาคือหนึ่งในความสำเร็จของบริษัท เพราะฉะนั้น ถ้าเขาพิสูจน์ให้เห็นว่า เขาทำงานเหมือนว่าที่นี้เป็นหัวใจของเขา เราก็พร้อมที่จะให้เขามาเป็น partner ของเรา
5. สร้างคน แต่ไม่รั้งคน
เรารู้ดีว่า ตลาดแรงงานนั้นดุเดือด และเข้าใจดีว่า ทุกคนมีสิทธิเลือก ดังนั้นเราจะไม่หมกเม็ดในการสร้างคน เราพร้อมสนับสนุนให้ทุกคนเติบโต โดยที่คุณอาจจะเลือกไปโตที่อื่นก็แล้วแต่คุณ แต่เราจะพร้อมเสมอสำหรับการ Recruit คนใหม่ๆ โดยเรามีการวาง Process ในการทำ Knowledge Sharing เพื่อให้องค์ความรู้ยังคงอยู่ และการดำเนินโครงการสะดุดน้อยที่สุด
6. มีระยะห่าง แต่ใกล้ชิด
เราเคยทำงานแบบพี่น้อง ครอบครัวมาก่อน แต่มันไม่ Work เพราะตอนนั้น พี่ดูแลน้อง จนสุดท้ายน้องไม่โต เราจึงเปลี่ยนมาเป็น Sport Team ที่ผิดคือผิด พลาดคือพลาด ดุคือดุ ไม่ผ่านคือไม่ผ่าน ถ้าต้องทำใหม่ก็คือต้องทำใหม่ งานของใครก็ของคนนั้น ไม่ใช่ให้หัวหน้าต้องลงไปช่วย ทุกคนต้องเก่ง ต้องโต ไม่งั้นคุณก็จะถูกรั้งท้าย ทำให้การเป็นหัวหน้า กับลูกน้อง มีระยะห่างมากขึ้น เพราะน้องก็ต้องทำงานที่มอบหมายให้ได้ด้วยตัวเอง แต่เราใกล้ชิดกันมากขึ้น ตรงที่ถ้าติดปัญหา ทั้งเรื่องส่วนตัว และเรื่องงาน จะสามารถขอเวลาหัวหน้าได้เสมอ
7. งานต้องท้าทาย
งานที่ Coraline แทบจะไม่ซ้ำกันเลย มันทำให้เราได้เรียนรู้อะไรใหม่ๆ ในโครงการใหม่ๆ ตลอด บางครั้งแป้งตัดสินใจปฏิเสธบางโครงการ เพราะแป้งคิดว่าโครงการนี้อาจจะไม่เหมาะกับเรา และก็มีบางครั้งที่ตัดสินใจรับโครงการใหญ่ที่มีความเสี่ยง แต่ก็พร้อมที่จะเสี่ยง เพราะมันจะได้ทำให้ทีมงานได้พิสูจน์ความสามารถ
Data Engineer ที่ Coraline จะต้องได้ใช้ Cloud ได้ทั้ง 3 เจ้า และสามารถ Dev แบบ On-prem ได้ด้วย
Data Scientist ที่ Coraline จะต้องสร้าง Model ได้ ทั้ง Machine Learning, Optimization, Probability Model, Statistical Model และ Logic แบบต่างๆ
Full-Stack Dev ที่ Coraline ต้องสามารถพัฒนา Application ที่ Flexible พร้อมสำหรับการต่อยอดในอนาคต
Data Analyst ที่ Coraline จะได้ใช้ทักษะด้านการวิเคราะห์ในหลายๆ อุตสาหกรรม
8. CEO ต้องเสียสละ
ความลับของแป้ง คือ แป้งได้เงินเดือนน้อยกว่าพนักงาน แป้งเคยสละเงินเดือนตัวเองถึง 6 เดือน และแป้งไม่ได้รับโบนัสตราบใดก็ตามที่บริษัทยังไม่ได้ตามเป้า แต่แป้งไม่เคยงกกับน้องๆ ไม่ว่าจะเป็นโบนัสของน้อง เงินอั่งเปา จับฉลากปีใหม่ งานเลี้ยง ของขวัญ หรืออะไรก็ตามที่น้องๆ ควรจะได้ แป้งก็จัดเต็มเสมอ ซึ่งเป็นเงินส่วนตัวของแป้งทั้งสิ้น แม้มันอาจจะเป็นเรื่องเล็กๆ น้อยๆ ที่น้องมองไม่เห็น แต่อย่างน้อย แป้งก็พิสูจน์ให้ทั้งนักลงทุน และพนักงานเห็น ว่าแป้งไม่เอาเปรียบใครแน่ๆ
สุดท้ายนี้ แป้งเชื่อว่า ทีมงานของแป้ง (อาจจะไม่ทั้งหมด แต่คิดว่าส่วนใหญ่เป็นเช่นนั้น) เขาทำงานด้วยความสนุก และท้าทาย พร้อมกับได้ Benefit ที่เหมาะสม นั้นแหละ สำคัญที่สุดสำหรับเขาแล้ว
บริษัทอยากได้คนจริงทำงานฉันใด คนจริงก็ย่อมอยากจะอยู่บริษัทที่ทำจริงฉันนั้น
ทั้งนี้ แป้งคนเดียว คงไม่สามารถทำให้ทุกอย่างมี Progress ได้ขนาดนี้ ก็ต้องขอบคุณ Partner ของแป้งทุกคน ขอบคุณ Team Lead และหลายๆ คนที่แป้งเพียงแต่ให้ Direction แล้วไป Execute ให้เกิดขึ้น
แม้อะไรๆ จะไม่ปรู๊ดปร๊าด แต่เราก็เติบโตของเราไปเรื่อยๆ นะคะ
ขอบคุณที่อ่านมาถึงบรรทัดนี้ค่ะ
แป้ง
CEO
Coraline

ผมเปิดบริษัทเอง ผมสามารถมีเงินเดือนน้อยกว่าลูกน้องได้โดยไม่ต้องคิดมากเลย สุดท้ายแล้วเงินบริษัทก็เงินผมเองแหละที่ได้มา และมีมากพอที่จะมาจ่ายลูกน้อง 😎
เรื่องแบบนี้ผมมองว่าเราไม่เคยเอามาซื้อใจคนครับ ธุรกิจก็คือธุรกิจครับ ถ้าเอามาปนกับบรรทัดฐานทางสังคมเมื่อไหร่ เราจะไม่สามารถกลับมาคุยฉันมิตรกันได้อีกเลย

>>244 มันจ่ายเท่าไหร่วะ ต้องใช้ cloud เป็นทั้งสามเจ้าเนี่ย

>>246 senior 60-200k

>>247 range กว้างเกิน ให้มาแบบนี้ตีว่า 60k ละกัน น้อยไป

https://hifumin.app Techstack
หมดนี่เสียเดือนละ 2 บาท ด้วยพลังแห่ง Serverless
(Average Request: 350k / month)
Hifumin เป็น Opensource Hentai Platform สร้างขึ้นเพราะรำคาญโฆษณาของ nHentai + รู้สึกหงุดหงิดที่บางทีก็ช้าไปหน่อย เลยเขียนใหม่เองหมด แบบ optimized มาโคตรดี ไม่มีโฆษณา และเป็น Opensource โดยสมบูรณ์ มีแผนจะ integrate กับ H Platform อื่นอยู่ แน่นอนทั้งหมดนี่เขียนเองคนเดียว
Note: Stack ทั้งหมดนี่เลือกจากราคาถูกสุดเป็นหลัก ถ้าจะเน้นประสิทธิภาพ จะเป็นอีกแบบนึง
Service ตระกูล Hifumin ทุกตัวเป็น micro-service ที่ deploy เป็น Serverless บน Google Cloud Run คิดค่าใช้จ่ายตาม CPU Allocation Time แต่ด้วยการจูน performance มาดี เลยเสียเงินตรงนี้น้อยมาก ข้อเสียคือมี coldstart อยู่บ้างถ้าไม่มี request ซักพัก
Service หลักๆ จะแบ่งเป็น
- Frontend (Hifumi): hifumin.app
- หน้าบ้านรับ User เป็น PWA, Cache ด้วย Service Worker
- Hentai-related API (Akashic): api.hifumin.app
- Public GraphQL API (สำหรับทุกคน ไม่มี CORs) สำหรับใช้ดึงข้อมูลมาจาก nHentai API แล้ว จัดการ format และ cache เองให้พร้อมมี mirror server ที่ update เองทุกๆ 3 ชั่วโมง
- User-related API (Galahad): user.hifumin.app
- API สำหรับใช้เก็บข้อมูล user หรืออะไรที่เกี่ยวข้องกับ User
- Source / Translation API: rosmontis.hifumin.app

- Reverse Proxy สำหรับหา hentai จากภาพ หรือหา ภาษาอื่นจากภาพ (Experimental: ตอนนี้กำลังทำการแปลอยู่)
Frontend (Hifumi)
- https://github.com/saltyaom/hifumin/tree/bismarck
Main ตอนนี้ยังเป็น Nextjs อยู่แต่กำลังเขียนใหม่เป็น Svelte บน branch Bismarck
Hifumi เป็น PWA ที่ optimize มาค่อนข้างดี Average bundle size ประมาณ 40K ต่อหน้า แต่ ส่วนใหญ่ถูก cache เอาไว้ด้วย Workbox บน runtime หมดแล้ว ทำให้เวลาโหลดหน้าใหม่ ทุกอย่างจะถูก Cache ไว้หมด ยกเว้น API, ถ้าเป็น local assets จะเป็น CacheFirst แล้วที่เหลือ key หลักๆ จะเป็น StaleWhileRevalidate ที่จะ invalidate cache ให้เอง เลยไม่มีปัญหาเรื่อง cache invalidation
เอาจริง เขียนใหม่มา 4-5 รอบได้แล้ว 555555~
วิวัฒนาการมาจาก React > Nextjs (Stylus) > Nextjs (Tailwind) แล้วสุดท้ายมาปักหลักลงที่ Svelte Kit เพราะ performance ดีมาก
Public API จะเป็น GraphQL หมด แล้ว Internal API (เช่น User) จะเป็น REST API เพราะ overhead น้อยกว่า (มาก) แต่แลกมาด้วยความ Flexible ที่น้อยลง
GraphQL Driver เป็นตัวที่เขียนเองคือ @saltyaom/gql กับ gq เพราะว่า driver ส่วนใหญ่จะจัดการเรื่อง AST Tree ของ GraphQL ก่อนส่ง request เลยทำให้ขนาดใหญ่ แต่เราต้องการแค่ส่ง Request ได้ก็พอ (eg. fetch syntax sugar สำหรับ GraphQL ที่เขียน plugin เพิ่มได้) เลยทำให้ขนาดเหลือไม่เกิน 1KB

หน้า dynamic ใช้หลักการเดียวกับ Nextjs คือใช้ Incremental Static Regeneration แล้วใช้ StaleWhileRevalidate ในการ invalidate cache ทำให้ไม่ต้อง build hentai ทีเดียว 39x,xxx หน้า แล้วฝั่ง SSR ค่อย cache API request
Hentai-related API (Akashic)
- https://github.com/saltyaom/akashic
หลักๆ คือ เป็น Reverse Proxy สำหรับ nHentai API อีกทีนึง แต่ตัว API ของ nHentai คือ CORs, ไม่ช้าไม่เร็ว, Format ไม่สวย, ล่มบ่อย และโดน Rate Limit เลยทำให้ต้องหาทาง Workaround เองจนสุดท้ายต้องมาเขียน Reverse Proxy เอง
เขียนด้วย Rust (Actix Web) ที่ต้องการรีด performance ของ GraphQL ด้วยความที่ overhead เยอะกว่า REST มาก + เพื่อลดค่าใช้จ่ายของ Cloud Run CPU Allocation เลยเลือกใช้ Rust
ที่คือ API มีปัญหาเรื่อง Rate Limit เลยทำให้เรียก API ติดกันไม่ได้ แต่มีทางออกคือ การทำ Reverse Caching
ทีนี้ถ้าเลื่อนลงไปจะเห็นว่าเรา List Github ในกลุ่ม Database ซึ่งไม่ได้ต้องใจจะเกรียนแต่เราใช้ Github เป็น Database จริงๆ เพราะ
1. Free ถ้าใช้ Database หรือ Storage จะเสียเงิน
2. เราเสก cronjob ด้วย Github Action ให้ dumb nHentai API และ Comments ทั้งหมดมาเก็บเป็น json file แล้วเก็บไว้ใน repo นึง ซึ่งจะทำงานทุกๆ 3 ชั่วโมง
- https://github.com/saltyaom.../hifumin-mirror/tree/generated
ด้วยความที่มันเป็น Public Data เลยไม่มีปัญหาอะไร
ตัว Akashic จะดึง API มาจาก Mirror Server ก่อนแล้วค่อย Fallback ไปที่ API ของ nHentai อีกที จากนั้นจะจัดการ format เป็น แบบที่อ่านง่ายกว่า แล้วค่อยส่งค่าคืนเป็น GraphQL อีกทีนึง ส่วนระหว่าง request ใช้ Apollo ในการ Monitor Request, GraphCDN ในการ cache query และ Cloudflare ในการ Cache Request ที่ซ้ำกัน ด้วยความที่จูนมาดี Allocation Time เลยน้อยมาก
User-Related API (Galahad)
- https://github.com/saltyaom/galahad
เป็น API Server ที่จัดการข้อมูลฝั่ง user (authen, cloud save, etc.) ที่เขียนด้วย Node เพราะหลักๆ ไม่ได้มีอะไรมากนอกจาก CRUD ตรงๆ + Node ถนัดเรื่อง Non-Blocking IO และมี ORM และ DB Driver ให้ใช้เยอะมาก แต่เพราะติด cost เลยใช้อะไรได้ไม่เยอะ
หลักๆ คือใช้ Planetscale ต่อด้วย Prisma และ Redis ต่อด้วย ioredis
ใช้ Planetscale เพราะเป็น Serverless Database ที่ไม่ต้อง Host เอง แถมได้ใช้ฟรี 1 พันล้าน Read, 10 ล้าน Write, 10GB Storage ฟรี ถ้าเกินก็จ่ายไม่กี่ $ ข้อเสียที่ไม่เป็นข้อเสียคือเป็น MySQL (ส่วนตัวนิยม Postgres กว่า) เอาไว้เก็บข้อมูลทั่วๆ ไปได้เลย
ส่วน Redis สำหรับเก็บ Session โดยเฉพาะเพราะเป็น In-Memory Database อย่างที่ทุกคนรู้, Redis มี Cloud ให้ใช้ได้ผ่าน Redis Lab ฟรี 30MB อาจฟังดูเหมือนน้อย แต่ต้องอย่าลืมว่าเราเอาไว้เก็บ active session อย่างเดียว ซึ่ง session ที่เราสร้างมามี format เป็น nanoID (21 Character) ซึ่งถ้าจะใช้ให้ถึง 30MB คร่าวๆ ก็คือต้องมี active session ประมาณ 9 แสนขึ้นไป ถ้าเกินก็จะเสีย $7 ต่อเดือนแล้ว storage จะขึ้นเป็น 100MB แต่ถ้าถึงตอนนั้นจริงๆ คนใช้ก็คงเกิน 3 ล้าน active session แล้ว ก็คงย้ายลง Raspberry PI 4B RAM 8GB ที่มีอยู่แล้วเป็น dedicated server ได้ ก็จะเก็บ active session เกิน 100ล้าน active session ได้สบายๆ
ส่วนตัวชอบ Prisma มาก เป็น ORM ที่ชอบที่สุดละ Generate Code + Type มาให้ใช้ได้เลย เบื้องหลังมี Query Engine ที่เขียนด้วย Rust embed มาให้ด้วย + มี Admin Tools ที่ชื่อ Prisma Studio มาเป็น GUI ให้จัดการ Database ได้แบบง่ายๆ ด้วย
จริงๆ ตอนแรกชั่งใจระหว่าง CockroachDB กับ PlanetScale แต่เลือก PlanetScale เพราะ ตามความเข้าใจ เป็น MySQL ที่ fork มาก่อนเองแล้วเอา

มา run บน Vitess ซึ่ง Scale MySQL ได้ Vertical Scaling แบบน่ากลัวมาก คือ Scale Cluster หลักแสนเครื่องพร้อมกันได้ + มี feature branching คือเหมือน Github Branch เลยแต่เป็น Database ทำให้ไม่ต้องกังวลเรื่อง Migration ว่าจะมี Type Conflict หรือต้องจำลอง Database เอง
Source / Translation API (Rosmontis)
https://rosmontis.hifumin.app
เป็น API Server สำหรับการทำ Reverse Image Search และใช้ Image Processing ในการอ่านคำและระบุตำแหน่งจากรูปภาพ และแปลด้วย ตัว API ตอนนี้เขียนด้วย Node และ ใช้ Web Assembly ฝั่งหลังบ้าน (ตอนนี้มีใช้ Neon สำหรับ Rust Binding อยู่)
อันนี้ยังเป็น internal อยู่ เพราะมี Technical Dept เรื่อง secret ทำให้ยัง public ไม่ได้ + ไม่รู้จะได้ใช้จริงไหม + ถ้าจะใช้จริงจะมี fixed cost อย่างน้อย $6 ต่อเดือนสำหรับ SourceNao API, Google Cloud Storage สำหรับเก็บ ephemral storage
ตอนนี้ public version เป็นแค่ Reverse Image Search อย่างเดียวซึ่งทดลองใช้เพราะต้องการคำนวนค่าใช้จ่ายของ Cloud Storage หลายๆ ตัว
Tooling อื่นๆ
- Astro มี internal project ที่ใช้อยู่
- Vite ฝั่ง SvelteKit, Vitest สำหรับ Test
- SWC ใช้ bundle Node หลังบ้าน, Jest สำหรับ Test
- Lagrange (Internal ตอนนี้เป็น Rust + SvelteKit) แทน Postman
- WRK สำหรับ Loadtest
- GraphCDN สำหรับ cache GraphQL Request
- Pulumi สำหรับ Google Cloud automation
- Wrangler deploy ขึ้น Cloudflare Worker ด้วย Github Workflow สำหรับ Performance-Critical Function
- Hifumi ตอนนี้ใช้ Cloud Run แต่กำลังวัด performance และ Coldstart ระหว่าง Cloud Run, Netlify, และ Cloudflare Pages อยู่ แต่ดูทรงคงได้ย้าย
- Google Cloud Build สำหรับ CI/CD Cloud Run ที่โยนขึ้น Github
- Fusejs สำหรับ Web Client-side search
- และก็เราเป็นที่แรกที่มี nHentai อยู่ใน List ขึ้นเป็นหนึ่งใน Techstack 😎
ที่เห็นทั้งหมดนี่เป็น Opensource ทั้งหมดที่เขียนทั้งหมดเองคนเดียวตอนว่าง
เอาจริงๆ ถ้าไม่จำกัดเรื่องเงินจะได้เห็น Techstack คนละแบบกันเลย อาจจะได้เห็น ScyllaDB internal ZeroMQ, Kong + Consul บน k8s กระจายทั่ว AWS, GCP
แต่จุดประสงค์หลักๆ คือต้องการลดค่าใช้จ่ายทุกอย่างให้ใกล้เคียง 0 มากที่สุดเลยได้มาเป็น Stack ที่เห็น หรือก็คือที่เห็น Technical ทั้งหมดนี่เกิดมาจาก "การอยากอ่าน Hentai ที่ไม่มีโฆษณานั่นแหละ"

>>249-252 โม่งคนเดียวกับที่มาถามเรื่อง regex parse ชื่อการ์ตูน H รึเปล่าเนี่ย
ยังไม่ได้ลอง แต่เราขอให้ท่านมีความสุขความเจริญ

python อนาคตยังไปได้สวยไหม

เรื่องสตรีมมิ่งล่มนี่ ต้องบอกว่ามีบริษัทมิตรสหายท่านหนึ่งที่เคยเจอโหลดระดับครั้งยิ่งใหญ่ของไทยแล้วไม่เคยล่มเลย

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

>>255 เพิ่ม node ไปเรื่อยๆก็ไม่ล่มแล้ว ยากตรงไหน

ทำไม Startup ถึงล้มกันเยอะ ทั้งๆ ที่มีระดมทุนไปตั้งเยอะ ก็ยังไม่รอด

ความเห็นส่วนตัวค่ะ อาจจะเป็นเพราะว่า ได้เงินมาเยอะ ก็เลยขาดการระวังในการใช้เงิน ก็เป็นได้นะคะ

สำหรับ Coraline เราไม่ได้เปิดระดมทุนค่ะ ตั้งแต่สร้างองค์กรขึ้นมา แนวคิดของแป้ง คือ แป้งสร้างองค์กร เพื่อหาลูกค้า ไม่ใช่หา Funding เพราะแป้งต้องการให้บริษัทอยู่ได้ด้วยผลงาน ไม่ใช่ด้วยการระดมทุน (หรือ Money Game)

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

เมื่อเป็นเช่นนั้น การบริหาร Cash Flow จึงสำคัญมาก เพราะเราไม่ได้มีเงินถุง เงินถังที่จะ Burn ได้อย่างฟุ่มเฟือย

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

นั้นเป็นเหตุผลที่ว่า ทำไมเราถึงเติบโตได้อย่างต่อเนื่อง เพราะเราค่อนข้าง "ผิดให้น้อย"

แป้งไม่ได้ต้องการเป็น Unicorn เพราะไม่รู้สึกว่าจะต้องขอระดมทุนเยอะๆ ถ้าเราอยู่ได้ด้วยตัวเอง ก็ไม่รู้จะระดมทุนทำไม

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

มีนักลงทุนติดต่อเข้ามาเยอะ ว่าจะเปิดให้ระดมทุนมั้ย??? อาจจะเปิดค่ะ ตอนนี้ยังตอบไม่ได้ ซึ่งการจะเปิดระดมทุนของแป้ง คือ กรณีที่ต้องการเปิดตลาดใน Product ที่เราพร้อมจะเปิดตัว และต้องการ Support ในการเปิดตลาดเท่านั้น แต่ถ้าอะไรยังไม่ชัดเจน แป้งจะไม่ระดมทุนมาเพื่อเสี่ยงแน่นอน เพราะแป้งให้ความสำคัญกับทุกบาทของนักลงทุนมาก ๆ

ลงทุนกับแป้ง คุณจะต้องได้คืน ถ้าบริษัทคืนไม่ได้ แป้งก็จะหามาคืนให้ได้ด้วยตัวแป้งเอง

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

แต่แน่นอนว่า ทุกอย่างมีรากฐานมาจาก Data และต่อยอดจากประสบการณ์เดิม

Direction ของแป้ง คือ ปรับตัวให้เร็ว เพราะเราจะต้องเป็น No.1 ให้ได้ ไม่วันใด ก็วันหนึ่งค่ะ

>>257 แป้งไหนวะ? ไม่ใช่มาดามแป้งใช่ไหม? เพราะรายนั้นคือเจ้าแม่สายการเงิน ประกันภัยอยู่ละ รวยจนมาเป็นนายทุนsharktank ได้

>>258 เจ้าของบริษัท Coraline

Job Hopper แตกต่างจากคนที่กำลังเดินทางค้นหาตัวเอง ไม่ว่าจะเป็นหาที่ หางาน หาสังคม หาสิ่งที่หายไป หาสิ่งที่เติมเต็ม หาความรู้ หา mentor หา ฯลฯ ….

หลายคนเปลี่ยนงานเพื่อหาสิ่งเหล่านั้น …. บางทีก็รายได้สูงขึ้น บางทีก็ลดลง …

บางคนก็ไม่ได้หา แต่หนี …. หนีงานเฮงซวย หนีคนห่วยๆ หนีลูกค้า หนีรัก (เพราะดันไปแอบชอบเพื่อนร่วมงานที่มีแฟน) หนีอดีตรัก (เลิกกับคนที่ทำงานด้วยกัน) หนีการถูกจีบ หนีงานที่ไม่ตรงกับที่คิด (เป็นโปรแกรมเมอร์ แต่วันๆ ลงแต่ Windows, เปลี่ยนแต่หมึกเครื่องพิมพ์, ทำแต่งานเอกสาร) ฯลฯ …. ก็ได้เช่นกัน

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

คนเหล่านี้ งานใหม่ คือ ชีวิตใหม่ ความหวังใหม่ …. รายได้มันก็เรื่องนึง ถ้ามันมากขึ้นก็เป็นผลพลอยได้ …

แต่คนที่เป็น Job Hopper จริงๆ ที่สนใจแค่เปลี่ยนงานขยับฐานเงินเดือน โดยไม่สนใจอะไรอย่างอื่นเลย มันก็มีเช่นเดียวกัน ….

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

ผมอยากรับคนที่เปลี่ยนงานเพื่อค้นหาอะไรสักอย่าง เพราะมันเป็น challenge สำหรับผมเช่นเดียวกันว่าจะมีของที่เขาตามหาหรือไม่

แต่ผมไม่อยากรับพวก Hopper ที่แท้ทรู (ซึ่งเขาก็คงไม่สนใจทำงานกับผมเช่นกัน)

[ป.ล. แต่ทั้งนี้ ผมบอกไม่ได้ “ด้วยความมั่นใจสูงๆ” ว่าใครเป็น Hopper จากการ interview หรือ CV นะ … อย่างมากก็พอมี vibe มาให้สัมผัส]

[ป.ล.2 ทั้งนี้ ผมไม่มีปัญหาอะไรกับใครที่เป็น Hopper ที่แท้ทรูนะ มันก็เป็นชีวิตเค้า วิถีเค้า แค่ไม่ตรงกับ profile ที่ผมสนใจ แค่นั้นแหละ]

เรื่อง Job Hopper ผมว่าจริงๆ มันออกแนวเป็นเทรนด์ตามสมดุลตลาดในวงกว้างไปแล้วแหละ เพราะตอนนี้งานที่ต้องการคนบางประเภทโดยเฉพาะ IT มันเยอะเกินแรงงานที่ทำงานได้จริงอยู่ในตลาดไปมากจริงๆ ดังนั้นก็ไม่แปลกที่คนเขาจะมีทางเลือกย้ายงานไปหาที่ๆ เหมาะกับตัวเองทั้งในเชิงเนื้องาน สังคม และรายรับได้ เป็นการเปลี่ยนแปลงของตลาดในภาพรวมเลยแหละ ที่อื่นเกิดไหมไม่รู้แต่ที่ไทยนี่ก็เป็นมาได้ 3-4 ปีแล้วนะ และเทรนด์นี้ก็คงไม่หยุดเร็วๆ นี้ด้วย

ความเสี่ยงที่ภาคธุรกิจน่าจะต้องคิดสำหรับประเด็นนี้ ก็คงจะเป็นเรื่องว่า จริงๆ แล้ว Job Hopper จะกลายเป็นมาตรฐานใหม่ของตลาดหรือเปล่า หรือฟองสบู่เศรษฐกิจและแรงงานมันจะแตกแล้วกลับไปสู่สภาพในอดีตที่ตำแหน่งงานที่ต้องการคนมันลดลงไปจนคนไม่ได้มีทางเลือกในงานมากนัก และคนอยากทำงานเดิมเติบโตต่อไปในบริษัทเดิมๆ

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

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

ถ้ากลับมาพูดถึงธุรกิจ IT ไทย ผมว่าประเด็นนี้เป็นประเด็นที่กดดันกันไม่น้อยเลยนะ บ. IT ไทยหลายแห่งที่ผมรู้จักก็พูดกันตรงๆ เหมือนกันว่าจ้างคนเงินเดือนสูงระดับนี้กันเริ่มไม่ไหวแล้วก็ต้องปล่อยไปแล้วลดขนาดธุรกิจลงแทน บางบ.ปรับสไตล์เลยว่าจะจ้างพนักงานบางคนมาทำงานไม่เกิน 1 ปีเท่านั้นโดยไม่ได้ให้งานที่มีคุณค่าหรือความรับผิดชอบมากนักไปทำ หรือบางที่ถึงขั้นไป Outsource งานให้ต่างประเทศแทนก็เริ่มจะคุ้มกว่าจ้างงานในไทยแล้วก็มี เก็บเฉพาะ Core Team สำคัญๆ เอาไว้ในไทยด้วยฐานเงินเดือนสูงที่มี Career Path ระยะยาว แต่ก็ยังมีบ.อีกหลายแห่งเหมือนกันที่บอกว่าเงินเดือนเท่าไหร่จะเรียกก็เรียกมา ทำงานได้ผลลัพธ์เกินเงินเดือนตัวเองได้ก็พอ หรือบางบ.ก็ใช้วิธีจ้างคนแบบ Part Time เน้นผลลัพธ์แบบมี Commitment และ Deadline แทนไปเลย จะทำงานประจำที่ไหนอยู่ก่อนก็ไม่สนใจ เรื่องของเขา ก็มีเหมือนกัน วิธีรับมือมันแตกต่างหลากหลายไปตามประเภทธุรกิจจริงๆ บางวิธีอาจทำให้ธุรกิจดีขึ้น บางวิธีก็อาจทำให้ธุรกิจแย่ลงในบางมุม ก็ต้องปรับกันไปครับ

ผ่านร้อนผ่านหนาวในวงการมา ตอนนี้สัมผัสได้ว่าหลายๆที่(product company ของต่างประเทศ) กำลังทิ้งการทำงานแบบ Sprint-Based แล้ว
---
ฝากไว้ๆ
* https://blog.pragmaticengineer.com/project-management-at-big-tech/
* https://medium.com/adventures-in-consumer-technology/why-we-transitioned-from-sprints-to-basecamps-shape-up-f416114224e7

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

ส่วนตัว ต้องขอบคุณอาจารย์หลายท่านมากๆ ที่ม. เกษตร ที่ไม่ได้สอนแค่หลักวิชา แต่สอนให้มองลึกไปกว่านั้นหลายเท่า บางคนสอนการใช้ชีวิต การ give credits when it's due การเปิดโลกให้กว้างกว่าแค่การเรียนในมหาวิทยาลัย

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

ของวิศวะคอม ถ้านึกเร็วๆ สิ่งที่ได้คือ

🟢 การมองทุกอย่างเป็นระบบ

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

🟢 การมองว่าสิ่งใหญ่ๆ นั้นเริ่มมาจากชิ้นส่วนเล็กๆ ที่ประกอบกันอย่างมีประสิทธิภาพ

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

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

สอง การที่ส่วนเล็กๆ เสียหาย มันไม่ได้เสียแค่ส่วนเล็กๆ แต่ถ้าส่วนเล็กๆ นั้นเป็นส่วนสำคัญ มันสามารถพาลให้เสียหายกันทั้งระบบได้

🟢 มีความสวยงามในทุกสิ่ง มีสไตล์ในทุกอย่าง

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

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

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

🟢 มองปัญหาด้วยจิตใจที่มีความสนุก

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

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

สวัสดีพี่โม่ง น้องเพิ่งจบใหม่ ทำงานได้ 6 เดือน มีเรื่องอยากปรึกษา คือว่างานที่ทำอยู่เนี่ยคือ title คือ ML+Backend แต่ที่ทำอยู่มันเทไปทาง Backend ซะ 90 เลย เลยคิดว่าถ้าทำนานๆไป skill ML จะไม่อัพเลยอยากเปลี่ยนงาน ทีนี้ถ้าเพิ่งทำงานได้ไม่ถึงปีแถมจบใหม่อีก แบบนี้ประวัติจะไม่ดีไหมพี่โม่ง รึควรทำต่อไปซักปีนึงก่อนดี

>>265 ย้ายไปเหอะ ปีแรกไม่ค่อยมีใครสนใจเท่าไหร่ ถ้าเขาถามก็บอกเหตุผลไป มันจะเริ่มดูไม่ก็ต่อเมื่อมัน 6 เดือน 3-4 รอบเนี่ย
ตอนกุย้ายงานครั้งแรก ก็ 6 เดือน โดนถามก็ค่อยทำไมถึงย้าย กุก็บอกไปตรงๆ ว่าไม่ชอบที่เก่าเท่าไหร่เลยย้ายออกมา เขาก็ไม่ได้ซักอะไรมากกว่านั้น

เมื่อวาน มีคนหนึ่ง ทำให้รู้สึกว่า คลาสที่จัดมาทั้งหมด ไม่มีค่า ไม่มีความหมาย “ถ้าเราไม่แก้ปัญหาเชิงโครงสร้างของระบบการศึกษา”

“เรา” ที่ว่านี่ใครก็ไม่รู้ด้วยนะ

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

พวกนี้ก็ไม่มีประโยชน์อีกเช่นกัน …. เรียกว่าถ้าการแก้ปัญหาเฉพาะหน้า มันเป็นเฉพาะหน้าจริงๆ (เช่น อัด RAM) ก็อย่าไปทำมันเลย ปล่อยมันล่มไป …. etc

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

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

วันนี้ก็ยังรู้สึกแย่ๆ อยู่ …. สงสัยที่ทำมานี่มันไร้ประโยชน์จริงๆ …. มีความรู้สึกโผล่มาแว๊บๆ ว่าปีหน้าอาจจะพิจารณางดจัดคลาส …. (อารมณ์ depress ชั่ววูปแหละครับ น่าจะ นะ …)

แต่ Block ไปล่ะ

โพสท์นี้จะลบตัวเองนะ อีกสักแป๊บ

บักลิ่วจะโชว์ความร่าน สุดท้ายโดนถอนหงอก ในบล็อกที่ตัวเองสร้างขึ้น 555

>>268 กุเข้าใจที่แกจะสื่อนะ แกมองในมุมธุรกิจมันไม่คุ้มก็ถูกแหละ
แต่เผอิญคนอื่นในบล็อกเค้ามองในแง่ของมนุษยธรรมไง

>>269 สลับกันแล้วโยม

ครบปีแล้ว ผมขอเอาของขวัญปีใหม่จากปีที่แล้วมารีโพสต์อีกรอบครับ

ผมเองก็อ่านโพสต์นี้ซ้ำบ่อย ไม่ว่าจะผ่านไปกี่ปี คำถามสามข้อนี้ช่วยให้ผมจัดลำดับความสำคัญในชีวิตได้ดีขึ้น

----
.
ผมสังเกตเห็นว่าโปรแกรมเมอร์มักจะมี New year resolution กัน เนื่องจากผมไม่ค่อยชอบทำอะไรที่คนส่วนใหญ่ทำ ผมขอเสนอ New year questions สักสามข้อ ให้ลองถามตัวเองกัน
.
---
.
1. ถ้าวันนี้บริษัทไล่เราออกจากงาน (หรือบริษัทของเราเจ๊ง) คิดว่าจะใช้เวลาหางานใหม่ได้เร็วแค่ไหน จะได้เงินเดือนเท่าไร
.
ผมเคยสัมภาษณ์โปรแกรมเมอร์คนหนึ่ง (ที่ตปท. ไม่ใช่ที่ไทยนะครับ) ซึ่งทำงานอยู่ในบริษัทน้ำมันยักษ์ใหญ่ แต่ถูกให้ออก เนื่องจากตอนนั้นราคาน้ำมันตกเยอะมาก จนบริษัทต้องลดขนาดองค์กร
.
จากการสัมภาษณ์ ผมชอบทัศนคติ และความฉลาดของเขามาก
.
แต่ตัดสินใจไม่รับ
สาเหตุเพราะเค้ามีอายุงานเกิน 10 ปี แต่ทำงานที่เดียว แผนกเดียวกัน มาตลอดตั้งแต่ฝึกงาน ความรู้ด้านการเขียนโปรแกรมของเขาอยู่กับระบบเก่า ภาษาเก่า เทคนิคเก่า และอยู่เฉพาะธุรกิจของ Oil and Gas ถึงผมมั่นใจว่าเค้าเรียนรู้อะไรใหม่ๆได้ แต่การจะจ้างเค้าในฐานะ Senior ด้วยเงินเดือนที่เหมาะสมกับที่เก่า แต่ความรู้น้อยกว่า Medior ที่ทำงานมาไม่ถึง 5 ปี ผมคงต้องขอเก็บตำแหน่งนี้ให้กับผู้สมัครคนอื่น
.
สัมภาษณ์งานเสร็จ ผมก็ต้องเตือนตัวเองด้วยว่า
.
โปรแกรมเมอร์เป็นสาขาที่แตกต่างจากวิชาชีพอื่นมาก ความรู้(ส่วนใหญ่)ของเราหมดอายุเร็ว ส่วนประสบการณ์ก็ไม่ได้ Stack โดยตรงเหมือนอาชีพฝั่งวิศวกรบางสาขา อายุงานมาก ไม่ได้แปลว่าคุณได้เปรียบ
.
ลองถามคำถามนี้กับตัวเองดูครับ ถ้าหางานไม่ได้เร็วพอ หรือเงินเดือนไม่ได้ตามต้องการ ลองถามต่อด้วยว่าเพราะอะไร เราจะทำอะไรเพื่อทำให้หางานได้เร็วขึ้นแค่ไหน
.
----
2. ในงานปัจจุบันเรา เราสร้างมูลค่า(ตีเป็นตัวเงิน)ให้กับบริษัทได้เท่ากับ 3 เท่าของเงินเดือนที่เราได้รับรึเปล่า?
.
บริษัทคือธุรกิจครับ สุดท้ายวัดกันที่ผลประกอบการณ์ ถึงทุกวันนี้ตลาดโปรแกรมเมอร์จะแดงเดือด เงินเดือนพุ่งขึ้นสูงมาก แต่ก็ไม่ได้หมายความว่าจะเป็นเช่นนี้ตลอดไป
เมื่อไรก็ตามที่ธุรกิจอยู่ในขาลง สำหรับบริษัทไอที การลดรายจ่ายหลัก ยังไงก็ต้องเป็นการเอาคนออก สำหรับบริษัทที่ไม่ใช่ไอที แผนกที่ไม่ได้เป็นแผนกหลักของธุรกิจ ก็จะโดนหนักหน่อย
.
บางคนคิดว่าเรื่องแบบนี้ไม่เกิดขึ้นหรอก ก็เป็นไปได้นะครับ แต่เราเดาอนาคตกันไม่แม่นอย่างที่เราคิดหรอก ผมอยากจะชี้ให้เห็นว่าตอน Dot Com Bubble คนก็คิดกันแบบนี้
.
ถ้าคำตอบของคำถามนี้คือไม่ ลองถามตัวเองดูว่าจะทำอย่างไรให้สร้างมูลค่าได้มากกว่านั้น ตั้ง Career (และรายได้) ของเราบนความไม่ประมาทนะครับ
.
----
.
3. สุขภาพของปีนี้ เทียบกับเมื่อ 3 ปีที่แล้ว ดีขึ้นหรือแย่ลงอย่างไร ทำอย่างไรได้บ้างให้ปีนี้ดีขึ้น
.
ผมมีเพื่อนเป็นหมอฟัน รายได้ดี แต่แค่ 30 ต้นๆก็เริ่มมีปัญหาเรื่องข้อมือกันแล้ว โปรแกรมเมอร์นี่ไม่ต้องพูด นอกจากข้อมือแล้ว คอ หลัง และหมอนรองกระดูกเริ่มไปพร้อมๆกัน
.
มองอีกมุม เราเป็น"กรรมกรห้องแอร์" ใช้แรงงานไม่หนัก แต่ใช้ซ้ำๆตรงบางบริเวณ ทำให้มีโอกาสบาดเจ็บจากพวก RSI (Repetitive Stress Injury)สูง ส่วนใหญ่จะรู้ตัวกันเมื่อเจ็บมากแล้ว
.
แต่ก่อนผมไม่ค่อยสนใจสุขภาพ อาจเป็นเพราะว่าอายุยังน้อย แต่พอเลย 30 มา มันชัดขึ้นเลยว่าร่างกายเราไม่เหมือนแต่ก่อน ใครที่ยังไม่เป็นไร ดูแลสุขภาพตัวเองให้ดี ลองถามรุ่นพี่ที่เป็นดู ว่ามันทรมานแค่ไหน
..
คำถามนี้สำคัญกว่าสองข้อข้างบนอีก ถ้าสุขภาพพัง ไม่ต้องคิดถึงเรื่องงาน เรื่องเงิน เรื่องแฟน เรื่องครอบครัวหรอกครับ ทุกอย่างพังกันหมดเป็นโดมิโนเลย
ส่วนใครที่ New year resolution เป็นเรื่องออกกำลังกายมาหลายปีแล้ว แต่ไม่ได้ทำสักที ไม่ต้องรอปีใหม่ครับ ถ้าวันนี้คุณไม่ไปออกกำลัง วันถัดๆไป คุณก็ใช้ข้ออ้างเดิมมาไม่ออกน่ะแหละ
.
------
.
สวัสดีปีใหม่ครับ ไม่ว่าโลกจะหมุนครบรอบหนึ่งปีวันนี้หรือเปล่า ผมแนะนำให้ทุกคนอยู่กับตัวเอง อยู่กับปัจจุบัน
.
เพราะเราใช้ชีวิตอยู่ใน"วันนี้"ทุกวัน เราไม่สามารถใช้ชีวิตในวันพรุ่งนี้หรือเมื่อวานซืน

-----

https://www.youtube.com/@JoshuaFluke1/videos

ช่องนี้โคตร Based

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

วันนี้เป็นวันแรกของวิชา 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เติมเงินให้เก่งใช้โปรแกรมไรสร้าง

ดราม่า Go กับ Rust ตอนนี้แหละ ไอ้เรื่องที่ทะเลาะกันนี่แหละ ที่ทำให้อยากสอน Humanistic Architecture

คือเจอคนเถียงกันแบบนี้มาตั้งแต่ก่อนหน้านี้แล้วก็เจอมาเรื่อยๆ ตลอด 10 กว่าปีที่ทำงาน

โอเค ผมจะสรุปให้ฟังนิดนึง

คือ Go เนี่ย มันตั้งใจจะออกแบบมาให้แบบคนจบใหม่ทำงานได้เลยอยู่แล้ว มันออกแบบโดยคิดถึง Developer Productivity สำหรับ Audience คือ จบมหาลัยมาปุ๊ป ไม่เคยอยู่ใน Industry นานเท่าไหร่ แล้วต้องทำงานให้ Google คำถามคือจะออกแบบภาษายังไงให้มันไม่เยอะเกินจนเขาทำงานได้ ทำงานดี โดยไม่ต้องมาผ่าน Learning curve เยอะ แต่ก็ยังมี Performance, Stability และอื่นๆ ในระดับที่ผ่านมาตรฐานของ Google

ส่วน Rust เนี่ยผมสรุปแบบย่อมากๆ ละกัน มันออกแบบมาให้ทำงานได้ Performance เท่ากับ C, C++ โดยที่ได้ Type Safety ที่มากกว่า

โอเค คุณอาจจะบอกได้แหละว่าถ้างานที่ต้องการ Performance ใช้ Rust ดีกว่า หรือต้องการ Type Safety สูงๆ Rust ก็ดีกว่า Go อีก ใช่ ไม่เถียง เพราะนั่นเป็นสิ่งที่มันทั้งทำได้ และมันออกแบบมาให้ทำแบบนั้น

แต่ลองคิดดูนะ ในบริบทของที่ Go ถูกออกแบบมา อย่างใน Google เงี้ย เขาใช้ Rust ทั้งบริษัท ก็ไม่ตอบโจทย์อีกนั่นแหละ จะให้เด็กจบใหม่มาเรียน Rust เขาก็คิดแล้วว่าในเชิง Business มันไม่คุ้มอ่ะ ในบริบทนี้ Rust ก็ถือว่ากากชิบหายได้เหมือนกันนะ

ประเด็นคือการตัดสินว่าอะไรห่วยไม่ห่วยเนี่ย มันทำผ่าน Value system บางอย่าง

ซึ่งคุณอาจจะบอกได้ว่าคุณไม่แคร์ คุณจะใช้แต่ Senior ใช้แต่คนมีประสบการณ์ แล้วยอมเสียเวลาให้เรียนได้ ดังนั้น Go ไปไกลๆ ชิ่วๆ กากมากในบริบทคุณ โอเค เมคเซนส์เว้ย

และกลับกัน บางคนก็อาจจะบอกว่า ผมไม่เห็นจะแคร์ในสิ่งที่ Rust ออกแบบมาเลย จะเอา Performance แบบนั้นไปทำเชี่ยอะไร เรามีแรมตั้งเยอะ CPU ตั้งเยอะ ก็ได้อีก

แต่มันมีความแตกต่างกันระหว่าง "เทคโนโลยีแม่งห่วย" กับ "สิ่งที่เทคโนโลยีตัวนั้นให้คุณค่า ผมไม่แคร์"

และทั้งคอร์สผมสอนเรื่องการออกแบบโดยเข้าใจกระบวนการให้คุณค่าของมนุษย์ เพราะ คุณไม่มีทางเลือกใช้เทคโนโลยีที่ "เหมาะสม" ได้ ถ้าคุณยังไม่เข้าใจว่า สิ่งที่คุณมองว่าห่วย มันห่วยจริงๆ ห่วยใน Value system ที่มันออกแบบมาเลย หรือมันห่วยเพราะแค่คุณไม่แคร์สิ่งที่มันให้ค่า

และถ้าคุณมองไม่เห็นว่ามันมีระบบคุณค่าของมนุษย์ที่มากกว่าที่คุณแคร์ เวลาคุณไปออกแบบระบบให้ธุรกิจหรือลูกค้าบางคนที่ Context ของมัน สิ่งที่คุณไม่ค่อยแคร์เสือกเป็นสิ่งสำคัญ คุณก็จะออกแบบผิดเพี้ยนไปหมดไง

ผมยกตัวอย่างง่ายๆ เลย ถ้าบริบทธุรกิจแม่งพึ่ง Raise fund มาแล้วเขากัน Cloud budget ให้เป็นล้านแล้ว ขอแค่รีบ dominate market ในเวลานี้ให้ได้ก่อน คุณจะมาบอกว่าโอ้ยเราต้องเขียนด้วย Low-level language ที่กว่าจะหาคนเพิ่มได้ กว่าจะเรียนรู้ มันจะไปทันกินอะไร ซึ่งถ้าคุณติดหล่มว่า "โค้ดที่ดีต้องใช้ Resource คุ้ม อะไรใช้เยอะคือกาก" คุณก็จะมองไม่ออกว่างานออกแบบคุณมันไม่สอดคล้อง

หรือตรงข้าม ธุรกิจสเกลใหญ่แล้ว ต้องประหยัดงบ จะออกแบบโดยเอา Dev productivity ตั้ง ก็ป่วยอีกแบบ

นั่นแหละถ้าสรุปสั้นๆ คือโปรแกรมเมอร์จำนวนมากเกินไป ที่มองว่า "สิ่งที่กูไม่แคร์คือสิ่งที่กาก" ซึ่งไม่ใช่ ไม่แคร์ กับห่วย ไม่เหมือนกันเว้ย

ความห่วยของจริงเนี่ยคือห่วยใน Value system ของมันเลย คือแบบออกแบบมาโดยตั้งใจให้เร็ว แต่ช้าชิบหายเงี้ย อันนี้อ่ะคือห่วย แต่ถ้าแบบอย่าง Rails ที่เขาตั้งใจทำมาเพื่อ Dev productivity มันช้ากว่าภาษาอื่นๆ เยอะมั้ย ใช่ ใช้ Resource เยอะกว่ามั้ย ใช่ แต่มันห่วยมั้ย ผมตอบว่าไม่ใช่

แยกให้ออกว่า เทคโนโลยีที่ไม่เวิร์ค กับเทคโนโลยีที่ความเวิร์คของมันฉันไม่แคร์ สองอันนี้ต่างกันมาก แล้วถ้าคุณจะออกแบบระบบให้ธุรกิจหลากหลาย คุณต้องเข้าใจความแตกต่างครับ

และนี่แหละทำไมผมคิดว่าคลาส Humanistic Architecture สำคัญกับคนที่เริ่มเขียนโปรแกรมเก่ง มีประสบการณ์หลายปี

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

ปล.​ ส่วนตัวผมไม่ชอบ Go, Rails แต่ผมคิดว่ามันออกแบบมาค่อนข้างดี เพราะผมเข้าใจว่าสิ่งที่มันออกแบบมารองรับ ผมไม่ค่อยแคร์หรือแม้แต่แคร์ในเงาขั้วตรงข้ามมากกว่า

ปล. 2 ผมคิดว่าเราดราม่าหรือเถียงกันได้นะ ดีด้วย ดราม่ากันหนักๆ แต่แค่ถ้าเราไม่เอา value system มากาง แล้วบอกแค่ว่า “ไอ้นี่ห่วย” เฉยๆ อ่ะ มันไม่เกิดประโยชน์อะไรไง แต่ถ้าดราม่ากันว่าแบบ เอ้ย ดีเพราะเร็ว ดีเพราะเขียนง่าย เห็นนิยามของ “ดี” ไอ้แบบนี้อ่ะดราม่าแล้วมีสาระหน่อย แต่โผล่มาแบบ “อันนี้กาก” เลยนี่ไม่ใช่

ควันหลังหน่อยจากโพสต์ที่แล้ว ผมเห็นบางคนตอบประมาณนึง
"เขียนภาษาอะไรก็ได้ที่ได้เงินเดือนเยอะที่สุด" ก็เป็น Value system แบบนึง ที่ก็เหมือนเดิม ไม่ได้เป็นคุณค่าสากลเหมือนกัน
"เขียนอะไรก็ได้ที่ลูกค้าจ้าง" ก็เป็น Value system อีกแบบ และก็แน่นอน มันไม่ได้เป็นคุณค่าสากลเท่าที่คนพูดคิดไว้อีกนั่นแหละ
และแน่นอนในมุมของบางคนที่มาตอบมันจะเหมือนเป็นอะไรที่ "ก็แหง๋อยู่แล้ว บ้าเหรอ สนใจอย่างอื่นมากกว่าเงินเดือนหรือมีลูกค้าจ้างได้เหรอวะ"
คำตอบคือได้เสมอแหละครับ และมันก็จะมีอะไรแบบนี้เสมอที่แตกต่างกันในมนุษย์แต่ละคน
เรื่องที่มันน่าช็อคจริงๆ บนโลกนี้ คือ Value priority แต่ละคนไม่เหมือนกัน และมันสามารถไม่เหมือนกันได้ในระดับที่ลึกมากๆ มากกว่าที่หลายคนประเมิน
ไม่งั้นสมัยก่อนญี่ปุ่นจะมีซามูไรยอมคว้านท้องทั้งๆ ที่มีชีวิตที่ดีมีครอบครัวอบอุ่นมีลูกมีเมียบ้านมั่นคงได้เหรอ
------------
ในคลาส Humanistic Architecture. ที่ผมรัน มันจะได้เห็นแม้แต่ Case study ที่ว่าบางทีเราต้อง Tech ไปตอบโจทย์ว่าลูกค้าที่เป็น Key Stakeholder จำเป็นจะต้องใช้ Tech stack ใหม่เพื่อพิสูจน์ตัวเองว่าจะสามารถ Modernize องค์กรได้ เพราะเขาเป็น CTO ใหม่พึ่งเริ่มงาน มีความคาดหวังจะเปลี่ยนภาพลักษณ์ขององค์กรเพื่อดึงดูด Modern talent
แล้วคุณจะมาแบบจบที่ Cobol เงี้ย แล้วเขาจะเอาหน้าตัวเองไปอยู่ไหน
ซึ่งตรงนี้ถ้าเราเห็นเราเข้าใจและยอมรับ Value system ของเขา มันก็จะเป็น Constraint ในการออกแบบไปอีกตัว
แต่มันไม่ใช่การที่เราจะต้องยอมไปหมดทุกอย่างนะ แค่การเข้าใจมันสร้างทางเลือก
สมมติเทรนด์ Microservice มันมา เขาอยากทำ แล้วเราเห็นว่าไม่เวิร์ค ต้องหยุด แต่เราเข้าใจ Value ของเขา เราสร้างคอนเซปต์ของ Modular Monlith แล้วทำภาพลักษณ์มัน Cool และดู Modern ก็ได้ แล้วก็บอก นี่ผมพาคุณล้ำหน้าเกิดตลาดปัจจุบันไปอีกก้าวเลยด้วยซ้ำ
มันก็ตอบ Value ของเขาได้โดยเราไม่จำเป็นต้องทำอะไรที่จะสร้างความชิบหายในประเด็นอื่นๆ อย่าง Maintainability เงี้ย
แต่จะออกแบบอะไรยังงี้ได้ เริ่มจากการเข้าใจ Value system อื่นได้ครับ
แล้วยังงี้คือเราต้องออกแบบตามใจคนอื่นตลอดเวลาเหรอ? ก็ไม่ใช่ครับ
คือถ้าเข้าใจแล้วแต่ไม่อยากยอมรับ ไม่อยากทำงานให้ ก็ปกติ เกิดขึ้นได้แหละ อย่างที่ผมบอก เราสามารถเข้าใจประเด็นของ Go ได้โดยไม่ต้องชอบมัน
และการเข้าใจ มันทำให้เราเฉียบคมขึ้นด้วยซ้ำ สมมติเราขยาดไม่อยากทำ Go เลย เราเข้าใจว่า Value system มันอยู่ตรงไหน เราก็จะรู้เลยว่าองค์กรแบบไหนมีแนวโน้มจะ Adopt ภาษานี้ จะขยาดจะหนี ก็วางแผนหนีทันอีกตะหาก
การเข้าใจทำให้เรามีทางเลือกมากขึ้น จะเลือกทางไหนก็อีกเรื่องนึง จะเข้าใจแต่เกลียดขี้หน้าก็ยังได้ครับ
Awareness มาก่อน Option เสมอ ยิ่งเข้าใจมาก ยิ่งมีทางเลือกมาก
ซึ่งการเข้าใจ Value system ที่แตกต่าง เป็นบทเรียนที่ต้องใช้สติมาก แล้วเป็นบทเรียนที่ฝึกตลอดชีวิต
ผมเองก็ยังเผลอหลุดไปไม่กี่สัปดาห์ที่แล้วเลย
ปล.​แต่ Case Study เนี่ย ถ้าคุณไม่ได้ลองทำเอง มันยากที่จะเข้าใจว่ามันกระแทกกระทั้นโลกภายในขนาดไหนกับการที่ต้องละวาง Value ตัวเองลงไป ใครเรียนรุ่นที่เริ่มมี Workshop แล้วน่าจะเจอโมเมนท์กระแทกใจกันหลายคน
คือเรื่องนี้ มองแบบผ่านๆ มองแบบคนนอก มันง่ายแหละ แต่พอมาเจอเอง มันไม่ใช่เรื่องง่ายเลย
ซึ่งตรงนั้นแหละที่คลาสผมพยายาม Faciliate ให้เกิด และทำให้ผมจัด Online ไม่ได้ ผมสร้างความกระแทกขนาดนั้นบนฐานที่ทั้งคลาสยังเป็นพื้นที่ปลอดภัยอยู่ ในโลก Zoom ไม่เป็นครับ

"Congratulations to the Go programming language on receiving the "WORST PROGRAMMING LANGUAGE OF THE YEAR AWARD" consistently for more than a decade!"

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

"No one talks about Go more than Rust devs 😭
How about you Go get a job?"

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