Fanboi Channel

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

Last posted

Total of 176 posts

104 Nameless Fanboi Posted ID:P0IDNoGSn2

ปัญหาด้านเทคโนโลยีใหญ่และสะสมมานมนานในองค์กร หาคนมาทำงานว่ายากแล้ว สิ่งที่ยากกว่าและส่วนใหญ่ไม่ให้ความสำคัญมากพอก็คือกระบวนการจัดการองค์ความรู้ ความรู้ส่วนใหญ่เก็บไว้ที่ตัวบุคคล เมื่อคนเก่งเหล่านั้นออกไป คนใหม่มาก็ใช่ว่ามาถึงแล้วจะทำงานได้เลย ไม่มีคนสอนงานเก่า งมเองกว่าจะได้เท่าคนเดิมส่วนใหญ่ก็เจ็บและเจอปัญหาจนออกไปก่อน ทำให้การทำงานและธุรกิจสะดุด ไม่เกิดการพัฒนาอย่างต่อเนื่อง ต้องทำใหม่ตลอด
แนวทางที่องค์กรที่บริหารจัดการเรื่องนี้สำเร็จก็มี
1. หาพาร์ทเนอร์มาดูแลแทน ก็มาความเสี่ยง ช่วงแรกก็ต้องเรียนรู้ ว่าเวิร์คหรือไม่ ระยะยาวความรู้จะไปอยู่กับพาร์ตเนอร์หมด
2. ต่างประเทศ เอกชน จะลงทุนสนับสนุนมหาวิทยาลัย สถาบันวิจัย เป็นคนเก็บและพัฒนาองค์ความรู้ เอกชนจะเก็บแค่ส่วนต่างเฉพาะที่เป็นความลับไม่ต้องการเผยแพร่
3. เปิด opensource ให้ชุมชน ช่วยดูแล
4. เปิดหน่วยงานสถาบันเพื่อดูแลเรื่องนี้เอง

105 Nameless Fanboi Posted ID:eAF1.y2tQe

วันนี้แปลกๆ มานั่งคิดย้อนเวลาไปว่าชีวิตเรามาอยู่ตรงจุดนี้ได้ยังไง ก็เลยมานั่งเขียนลงโน้ตเอาไว้ เขียนไปเขียนมา ขอเอามาแปะเลยละกันเพราะคิดว่าน่าจะมีประโยชน์สำหรับเพื่อนๆเช่นกัน
.
.
.
ผมเชื่ออย่างยิ่งว่าชีวิตเราทุกคน(และผม)ได้ดีเพราะมีคนสนับสนุนเสมอ
.
ตั้งแต่ช่วงเติบโตจนก่อนถึงวัยทำงาน พ่อแม่และพี่ชายพี่สาวผมทุกคนมอบทรัพยากรให้ผมศึกษาและลองเล่นในเรื่องต่างๆมาโดยตลอด ไม่ว่าจะเป็นเครื่องเกม คอมพิวเตอร์ อุปกรณ์อิเล็คทรอนิคส์ต่างๆ เรียกว่าอยากได้อะไรมาลอง 90% ผมจะได้โดยที่ตัวเองไม่ต้องเสียเงินเองเลย ผมถือว่าเป็นช่วงเวลาที่สำคัญมากๆเพราะมันทำให้ผมพร้อมในด้านทักษะกว่าคนอื่นในช่วงอายุที่ใกล้ๆกัน
.
พอเข้ามหาลัย ตอนเรียนรามฯ ผมก็ได้เพื่อนในซุ้มรามฯช่วยสนับสนุนโดยการพาไปให้รู้จักกับ “พี่ป้อม” เจ้าของร้านสติ๊กเกอร์ที่ใหญ่ที่สุดในซีคอนสแควร์สมัยนั้น ร้านใหญ่ มีคอมให้เล่นหลายเครื่อง มีกล้อง Digital Camera ของ Sony อย่าง Mavica ให้เล่น สมัยโน้นต้องบอกเลยว่าเท่ห์มากๆ
.
หลังจากได้รู้จักกับพี่ป้อม แกก็สนับสนุนผมด้วยการจ้างให้ทำงานที่ร้าน ไม่ว่าจะถ่ายรูป รีทัชภาพลูกค้าก่อนพิมพ์ออกมา เรียกว่าซองเงินเดือนซองแรกผมได้มาจากที่นี่ล่ะ ยังคงจำความรู้สึกแรกได้เลย โคตรดีใจที่เราสามารถทำงานแลกเงินได้แล้ว แถมพี่ป้อมยังได้หางานเขียนโปรแกรมบริหารสมาชิกโบสถ์คริสต์มาให้อีกงาน รวมไปถึงจ้างไปติดตั้งระบบร้านเน็ทให้หลายๆร้าน คือได้เล่นอะไรเยอะมากๆ
.
หลังจากนั้นก็มี “พี่ไก่” สนับสนุนผมต่อ เราเจอกันทาง Pantip และพี่ไก่ก็ได้มอบโอกาสให้ผมแบบยิ่งใหญ่มากโดยนัดผม นศ.รามฯกระจอกๆคนนึงให้ไปทานข้าวด้วยกันกับพี่ธานี (เจ้าของบริษัท PE&E) และทำการแนะนำผมให้กับพี่ธานีจนพี่ธานีว่างจ้างให้ผมไปทำงานด้วยเงินเดือนที่ดีมากๆสำหรับนศ.ที่ยังเรียนอยู่อย่างผม (เรียนแบบไม่เรียน 5555)
.
พอทำงาน PE&E ไปสักพัก ผมก็ได้ไปเรียนเขียนโปรแกรมที่ CTT แล้วก็ได้รับการสนับสนุนจาก “พี่โช” โชคชัย จันทร์เชย และ “คุณมิ้งก์” ต่อ โดยให้ไปลองฝึกเป็นเทรนเนอร์สอนเขียนโปรแกรมดู แถมยังได้รับการชวนให้ไปเปิดบริษัท Software House ด้วยกันต่ออีกทอด ต้องบอกเลยว่าช่วงนี้เป็นช่วงที่เปลี่ยนชีวิตผมไปมากที่สุดอีกช่วง ได้เรียนรู้อะไรเยอะมากๆในการทำธุรกิจ
.
ในระหว่างที่ทำ Software House ผมก็ยังคงได้รับการสนับสนุนจากผู้ใหญ่ทางฝั่งลูกค้าเสมอ ไม่ว่าจะเป็น ผอ.จากภาครัฐต่างๆ นายตำรวจนายทหารต่างๆ หรือแม้แต่ผู้บริหารระดับสูงในบริษัทเอกชนใหญ่ๆ ผมยังคงจำชื่อคนที่สนับสนุนผมได้อย่างดีจนวันนี้ ไม่ว่าจะเป็น “พี่เมฆ” “ดร.อธิป” “เอ” จากทรูที่เวลามีงานมีปัญหาก็ไม่เคยทิ้งกัน ฯลฯ
.
พอจบเส้นทาง Software House ผมก็ยังไม่วายได้รับการสนับสนุนต่อจากเมนทอร์ทางด้าน IM ของผมอย่าง “Patric Chan”...
.
อยากจะขอขอบคุณทุกคนอย่างสุดซึ้ง ผมคงไม่มีวันนี้ถ้าไม่มีทุกคนคอยสนับสนุน ผมจะทำชีวิตต่อไปให้ดีที่สุดไม่ให้ผิดหวังที่ได้รับการสนับสนุน และผมก็จะสนับสนุนหลายๆชีวิตให้ดีขึ้นด้วยเช่นกันครับ
.
ด้วยรักและเคารพเสมอ
ก๊วง
.
ปล. ความเชื่อเดียวที่ผมคิดว่าอาจจะเป็นกุญแจสำคัญที่ทำให้มีคนสนับสนุนผมอย่างต่อเนื่องคือ: “ความจริงใจ” ที่ผมมีให้เค้า
.
ถ้าวันนี้เราน้อยใจว่าไม่มีคนสนับสนุน ลองมอบความจริงใจให้กับคนที่เราติดต่อด้วยดูครับ ผมเชื่อว่าคนเราสัมผัสเรื่องพวกนี้ได้ :)

107 Nameless Fanboi Posted ID:xc+QiaN7dT

เมื่อวานได้คุยกับเพื่อนสนิทที่เป็นระดับเทพด้านไอที เรามีความเห็นตรงกันว่า สิ่งนึงทีน่ากลัวของวงการไอทีในปัจจุบันคือความไม่รู้จริง และความเห่อกระแสตามแฟชั่น ทำให้หลายคนมองบางเทคโนโลยีเป็นคำตอบในทุกเรื่อง ไม่ว่าจะเป็น Big Data, AI, Blockchain แล้วพวกแก่ๆอย่างเราที่ยืนอยู่บนความคิดพื้นฐาน ถ้าไปขัดแย้ง ก็เหมือนกับเป็นเต่าที่ตกยุค ตามไม่ทัน ขวางโลก เลยอยากจะฝากแนวความคิดไว้กับคนุร่นใหม่ที่จะโตไปเป็นคนชี้นำสังคมว่า

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

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

ปล.ที่คุยกันเมื่อวาน มีการพูดถึง NP-Complete กับ Non-Deterministic ด้วยนะ

108 Nameless Fanboi Posted ID:xPFg1+6tlM

วันพฤหัสคุยกับ Passapong Champillon Thaithatgoon กับ Keattiwut Joe Kosittaruk อยู่ว่า Functional programming อาจจะไม่เหมาะกับทุกงาน วันนี้จับ Physics engine นี่น่าจะอันนึงที่อาจจะทำ FP แล้วไม่ธรรมชาติ

เขียน Object ให้เป็น Ball.addKineticEnergy(right, 100) แล้วซ่อน State x,y ปัจจุบันไว้ใน Object เป็นโมเดลที่เหมาะกับเกมมากกว่าพยายามเปิดเผย x,y นะ

ถ้าเป็น FP จริงๆ มัน Equivalent อยู่แล้ว จะทำเป็น nextContext = context |> addKineticEnergy(ball, right, 100) |> nextFrame() เพื่อเก็บ context ก็ได้ แต่ก็ไม่รู้ว่า Natural ขนาดไหน ลองอ่านคู่มือ Physics engine ใช้ Object-oriented Model หมดเลย ขนาดใน Javascript นะ

แต่ที่มั่นใจคือเขียนเกมกับใช้ Physics engine การให้เข้าถึง X,Y ที่เป็น State ได้ง่ายๆ มันไม่ใช่ มันควรจะเข้าถึงผ่าน Mutation ที่เป็นธรรมชาติในโลกจริง อย่าง Gravity, Force, KineticEnergy พอมัน Emphasize state mutation มากกว่าตัว State แล้วผมว่าโมเดลด้วย Object + Message parsing มันจะเน้นย้ำในสิ่งที่ควรเน้นย้ำให้เห็นชัดเจน และทำให้ส่วนที่ไม่ควรจะถูกเน้นย้ำเข้าถึงยากขึ้น

ซึ่งนั่นแหละคือการ "ออกแบบโค้ด"

110 Nameless Fanboi Posted ID:B/E.iltyNe

ครั้งสุดท้ายที่ผมจะโพสท์เกี่ยวกับดราม่า "Coding" นะครับ

ผมไม่ขอพูดอะไรมาก นอกจากแปะหนังสือ "Coding as a Playground" ที่เขียนโดย Professor ด้าน Child Study & Human Development และยังเป็น Adjunct Professor ทาง Computer Science จาก Tufts University (มหาวิทยาลัยระดับโลก ถาม Sanpawat Kantabutra ได้)

ผมตัดมาบางหน้า ที่บอกว่า Coding มันเป็นการเรียนและฝึกอะไร และมันไม่ใช่ว่าเรียนไปเพื่อไปประกอบอาชีพเขียนโปรแกรมคอมพิวเตอร์แต่อย่างใด ..... มันเป็นการเรียน Way of Thinking มากกว่าเรียนรู้ Tools และการใช้ Tools (การเขียนโปรแกรมคอมพิวเตอร์เพื่อสั่งงานคอมพิวเตอร์ ด้วยภาษาโปรแกรม เป็นการเรียนรู้ Tools และใช้ Tools)

แม้ว่าปลายทางสุดแล้ว เด็กที่เรียน Coding จะสามารถเขียนโปรแกรมสั่งงานคอมพิวเตอร์ได้ก็ตาม นั่นไม่ใช่แก่นของการเรียน Coding .... (คือสุดท้าย ทุกคนคือ Computer Programmer แบบเดียวกับที่ทุกคนคือ Writer .... เราเขียนอะไรกันเยอะ สื่อสารด้วยการเขียนเยอะแยะ แต่ไม่ใช่เราทุกคนทำอาชีพนักเขียน)

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

Coding with Objects หรือใน Everyday Life ก็ทำได้ (ถึงตัวอย่างในหนังสือจะใช้ Robot แต่จริงๆ ก็ไม่จำเป็น ให้เด็กเล่นด้วยกันก็ได้ .... จริงๆ ผมเห็นว่าวิชา Coding น่าจะเป็นการเล่นเกมแบบ Rule-based ให้เหมาะกับวัยด้วยซ้ำ จากโดมิโน บันไดงู ไปหาพวก Board Game)

ดังนั้น คำว่า Coding มันไม่ได้มีความหมายแคบเฉพาะกับ Computer Programming ที่เราต้องเขียน (Programming Language) Code ... แต่มันมีความหมายกว้างกว่านั้นมาก

แน่นอนว่าเมื่อโตๆ ไป (ระดับมัธยม) ก็จะมีการนำ Digital Tools หรือแม้แต่ Computer Programming เพิ่มเข้ามาเอง .... เพราะนั่นเป็นการประยุกต์ใช้ Coding ไปกับคอมพิวเตอร์

ผมจะไม่พูดเรื่องนี้ล่ะครับ ใครจะเชื่ออะไรก็เชื่อไป คิดอะไรก็คิดไป

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

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

พูดอีกอย่างคือ ไม่ว่าใครจะเป็นรัฐบาลช่วงนี้ เรื่องนี้ก็จะถูกยัดใส่มือให้พูดช่วงๆ นี้ (+/- ไม่กี่ปี) อยู่ดีแหละครับ

111 Nameless Fanboi Posted ID:lPpfvs.p8d

Make sure you don’t hire engineers with “shiny object syndrome”.

What is that?

It’s when an engineer gets easily distracted by every cool new technology, framework, or library that comes out and wants to include that into what their working on just because it’s the “cool new thing” everyone is using.

A lot of Silicon Valley engineers have this problem.

It’s ok to play around with new tech, but you need to make sure it doesn’t distract you from business objectives.

Engineers should be using technology that is widespread, proven in production environments and has mature documentation. This will increase speed of development while reducing bugs and maintenance work.

It has happened over and over again in which a cool new library is introduced and then after a few months, it’s abandoned by the authors because it was just a “side project” and they don’t have time to “maintain it”. This screws you over and creates massive tech debt.

If your product is full of new and unproven tech, you are setting your business up for failure.

Either because you’re going to waste more time rewriting everything and/or when you hire more people, they have no experience with the new tech and will get frustrated.

112 Nameless Fanboi Posted ID:AhbCzfjIm1

coding ไม่ใช้คอม (อีกครั้ง และครั้งสุดท้าย)

โพสที่แล้วผมพูดเรื่อง coding ไม่ใช้คอม คนแชร์ไปเยอะ จนเริ่มรู้สึกชีวิตไม่สงบแล้ว จะเปลี่ยนเป็น Friend only ก็เกรงใจหลายท่านที่แชร์ไปแล้ว

ผมไม่ชอบดราม่า ผมไม่สนใจว่าใคร หรือพรรคไหนเป็นคนพูดประเด็นนี้ มันไม่ใช่สาระ ผมสนใจแค่ context ที่ debate กันอยู่ในสังคมเท่านั้น

ย้ำว่าโพสนี้ไม่ใช่โพสการเมือง และผมก็เลือกอนาคตใหม่ ดังนั้นพวกที่ด่าผมเป็น <ขนมหวานหลากสี> กรุณาเข้าใจเสียใหม่

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

โพสที่ผ่านมา แปลกดี

โปรแกรมเมอร์อาชีพส่วนใหญ่เห็นด้วยกับผม (p->q)
คนที่ด่าส่วนใหญ่ไม่ใช่โปรแกรมเมอร์อาชีพ (!q->!p)

(อันนี้ตรรกศาสตร์พื้นฐาน Transposition rule นะครับ ย้ำว่าผมใช้คำว่าส่วนใหญ่ ผมไม่ได้ stereotype มีโปรแกรมเมอร์อาชีพบางคนไม่เห็นด้วยกับผม และก็มีคนที่ไม่ใช่โปรแกรมเมอร์เห็นด้วยกับผมจำนวนมาก (!p->q) เขียนกันไว้ก่อนโดนด่าอีก เพราะผมไม่ชอบดราม่านะ)

สรุปประเด็นคำถามหลายๆ คนที่เห็นแย้งกับโพสของผม

**************************************
Q: บางคนบอกว่า coding ไม่เขียนโปรแกรมจะเรียก coding ได้ไง..?

A: coding ไม่ได้ตีความว่าต้องเขียนโปรแกรมเป็นบรรทัดๆ ด้วยภาษาคอมพิวเตอร์ อย่างเดียว Lego Mindstorm ก็ coding ด้วย drap and drop, Scratch ของ MIT เป็นแพลตฟอร์มสอนเด็กให้เข้าใจ coding ด้วย GUI (ลองเข้าไปดูที่ https://scratch.mit.edu) ทั้งหมดคือการสอน coding โดยไม่ใช้ภาษาโปรแกรมทั้งนั้น และทั้งหมดนั้นสามารถทำอะไรที่คล้ายๆ กันได้โดยไม่ต้องใช้คอมพิวเตอร์ คอมพิวเตอร์เป็นเพียง "tool" ในการอำนวยความสะดวกเท่านั้น ซึ่งมันก็จะตามมาด้วย "ข้อเสีย" แบบที่ผมเคยได้พูดไปแล้ว)
ภาษาโปรแกรมเป็นแค่ 1 วิธีในการสร้างกระบวนการแก้ไขปัญหาอย่างเป็นระบบเท่านั้น

**************************************
Q:บางคนบอกว่า ถ้าอยากฝึกวิธีคิด วิธีแก้ปัญหา มีวิชา math และ logic แล้วนี่ จะเรียนซ้ำซ้อนทำไม..?

A: ถ้าจะพูดแบบนี้ทุกวิชาในโลกนี้เรียนเพื่อฝึกคิดและแก้ปัญหาทั้งนั้น ไม่ใช่เฉพาะ math หรือ logic
แต่เราไม่ได้เรียน coding เพื่อแก้ปัญหาแบบตรงๆ แต่เราเรียน coding เพื่ออธิบายปัญหาและวิธีแก้ "อย่างเป็นระบบ" (อันนี้เอามาจากคำตอบของคนในทีมผมเอง ขออนุญาตไม่ระบุนาม) ซึ่งวิชา math และ logic ไม่ได้เน้นเรื่องนี้

**************************************
Q: เรียน coding ด้วยกระดาษ โปรแกรมบั้กก็แก้ไม่ได้ รันโปรแกรมก็ไม่ได้ จะไปมีประโยชน์อะไร

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

**************************************
Q: ถ้างั้นก็อย่าใช้คำว่าวิชา coding ให้คนเข้าใจผิด จะใช้คำว่าวิชา computational thinking หรืออะไรก็ใช้ไป

A: ผมก็ยังยืนยันว่า ตำราฝรั่งทั้งจาก MIT, google จากมหาวิทยาลัยดังๆ หนังสือเด็กของฝรั่ง ส่วนใหญ่ก็ใช้คำว่า coding อย่าตีความ coding เป็นการเขียนภาษาคอมพิวเตอร์เพียงอย่างเดียว
และถ้าคุณเลือกใช้คำอื่น ต่อให้มันจะเป็นคำที่ตรงเป๊ะๆ อย่าง computational thinking หรืออะไรก็ตามแต่ ก็จะยิ่งยากที่จะทำให้สังคมเข้าใจมากยิ่งขึ้นไปอีก "ลองจินตนาการรมต พูดว่า เราต้องให้เด็กเรียนวิชา computational thinking" ในสภาดูสิครับ

**************************************
Q: เป้าหมายของการเรียน coding คืออะไร
A: สำหรับผม ผมไม่ได้คิดว่าเด็กที่เรียน coding จะต้องเขียนโปรแกรมคอมพิวเตอร์เป็น รันโปรแกรม python หรือ java ได้ ไม่จำเป็นเลย
ที่ผ่านมาเราให้เด็กเรียนวิชาอ่าน เขียน ไม่ได้เพื่อเรียนจบไปเป็นนักอ่านข่าวอาชีพ หรือนักเขียนอาชีพใช่ไหมครับ แต่เราให้เค้าเรียนเพื่อให้มี skill พื้นฐานในการสื่อสารปฏิสัมพันธ์
เช่นเดียวกันเราให้เด็กเรียน coding ไม่ได้เพื่อไปเป็นโปรแกรมเมอร์อาชีพ แต่เราให้เค้าเรียนเพื่อมี skill พื้นฐานในการคิดแก้ปัญหาอย่างเป็นระบบ

สุดท้ายนี้ ผมไม่ได้บังคับให้ทุกคนเห็นด้วย ความเห็นของผมเป็นแค่ความเห็นหนึ่งของโปรแกรมเมอร์ที่เขียนโปรแกรมมา 25 ปี (ผมเริ่มเขียนโปรแกรมตั้งแต่อยู่ม. 3) ผ่านอะไรมาในระดับนึงที่น่าจะพอให้ความเห็นกับสังคมได้

ทุกคนมีสิทธิ์เห็นต่าง แต่ไม่ใช่การเห็นต่างที่จะมาด่า หรือดูถูกความคิดของฝ่ายตรงข้าม แบบที่ผมเห็นมาในโพสที่แล้ว (บางคน)

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

ขอบคุณครับ

113 Nameless Fanboi Posted ID:AhbCzfjIm1

ประชาพิจารณ์ หลักสูตร ict ของ สสวท

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

ก่อนอื่น ต้องบอกว่า มีทีมงานร่างหลายหลาก ยืน ภู่วรวรรณ เป็นประธาน และมีอาจารย์มหาลัยหลากหลายแห่ง และ ครูผู้สอนจากทั่วประเทศ มาช่วยกันปล้ำจนเป็นรูปร่างได้

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

ทีนี้ปรับน้อยคือยังไง เราพยายามเปลี่ยนวิธีคิดว่า เราจะไม่เรียนคอมพิวเตอร์ แต่เราจะสอน "วิธีคิด"

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

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

ผมขอให้ keyword ของประถมต้นว่า "Unplugged" ซึ่งก็คือเรียน ict กับชีวิตจริงเป็นหลัก (แน่นอนว่า ถ้ามีเครื่องจะเสียบปลั๊กก็ไม่ได้ว่าอะไร)

ประถมปลายนี่ เด็กเริ่มใช้เน็ตเป็น เล่นไลน์ ค้นเน็ต ลอกการบ้านจาก วิกิ ส่งครูได้ การเข้าใจเครื่องมือที่มีไม่ว่า จะ I(nternet) หรือ C(omputer) หรือ T(elecomm) ก็จะเริ่มแถวๆนี้แหละ แต่เราจะให้เด็กคิดว่าอะไรควรหรือไม่ควร เนื้อหาบางอย่างได้สอดแทรกเข้าไปเช่น logical fallacy เพื่อให้เด็กสามารถมีตรรกะที่จะต่อต้านข่าวปลอม หรือ พฤติกรรมไม่เข้าท่าในเน็ต เด็กเราจะได้ไม่โดนแชร์ลูกโซ่ หรือ โดนหลอกบริจาคทั้งที่บ้านไม่จนได้

ผมให้ keyword ของประถมปลายว่า "Daily" ซึ่งหมายถึงการใช้ ict กับชีวิตประจำวัน ไม่ว่าในการเรียนวิชาต่างๆ การเขียนบล๊อกหรือส่งเมล์ควรเรียนในภาษาไทย การคำนวณด้วยคอมพิวเตอร์ควรอยู่ในคณิตศาสตร์วิทยาศาสตร์ การทำภาพกราฟิกควรอยู่ในวิชาศิลปะ

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

การเรียนใน ม.ต้น จึงเน้นระเบียบและเทคโนโลยีการเก็บข้อมูล ตั้งแต่แบบสอบถาม แบบสำรวจ จนกระทั่ง Internet of Things (IoT) แล้วแต่ว่าโรงเรียนไหนจะไหว ย้ำอีกที เราสอนวิธีคิดนะ ไม่ได้สอนการใช้เทคโนโลยี

ผมให้ keyword ของ ม.ต้นว่า "primary data"

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

ซึ่งผมให้ keyword ของ ม.ปลายว่า "secondary data"

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

แต่อุปสรรคที่สำคัญอย่างหนึ่งคือ การเปลี่ยน mind set จาก "ทำอะไรได้ แปลว่า คิดได้" มาเป็น "คิดได้ เดี๋ยวก็ทำได้เอง" ยังเป็นความท้าทายอย่างยิ่งครับ

114 Nameless Fanboi Posted ID:AhbCzfjIm1

ว่าจะไม่พูดเรื่อง Coding แล้วเชียว ... ขออีกสักโพสท์ละกัน

ผมว่าปัญหาหนึ่ง ก็คือเรามองมันใน Context แคบๆ แค่ Computer Programming น่ะครับ (อันนี้เป็นปัญหา โดยเฉพาะคนในวงการไอที -- พอเห็นอะไรที่เกี่ยวกับเรื่องนี้ก็ตีความไปทางที่ตัวเองทำ -- Coding with Computers, Coding Computer Programs, etc)

ลองคิดแบบนี้ครับ .....

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

ต้องลองคิดว่า

คนที่จะเป็น Designer, พยาบาล, พ่อครัว, คนอยากเรียนอักษรฯ, คนอยากเรียนเกษตรฯ, คนอยากเรียนอะไร ก็ควรเรียน Coding

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

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

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

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

ถ้ารอบๆ ตัว ทั่วๆ ไป .... การบอกทางให้มีประสิทธิภาพ (เวลาถามว่าอะไรไปยังไง) ก็ต้องอาศัย Coding ..... การแก้ปัญหาต่างๆ ก็ต้องใช้ Coding .... อะไรทำนองนี้

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

แน่นอนว่า Computer Programming เป็น Context หนึ่งของ Coding แต่ไม่ใช่ทั้งหมด

ถ้าเด็กๆ ได้เรียน Coding ใน General Context หรือ Daily Lives มาแล้ว การนำมาประยุกต์ใช้กับการเขียนโปรแกรมคอมพิวเตอร์ก็เป็นเรื่องที่ง่ายขึ้นมาก (Note: ปัญหาของเด็กเรียน CS/IT/CE บ้านเราเลยครับ ... รู้แต่ Syntax แต่ "Coding ไม่เป็น")

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

ผมขอแปะ link ไป product ตัวหนึ่งใน Amazon ละกันครับ ....

"Littlecodr - Kids Coding Game"

https://www.amazon.com/Littlecodr-46618-Kids-…/…/B0199Q3PEI/

อันนี้เป็น Card Game สำหรับเด็กอายุ 4 ขวบขึ้นไป เป็น Card คำสั่ง ที่เอามาต่อกันเป็น Instruction เล่นกับเพื่อนได้ (สมมติว่าเพื่อนเป็น Robot ก็ได้)

ประเด็นคือ .... ถ้าฝรั่งไม่ใช้คำนี้ กับการสอนอะไรแบบนี้ แล้วทำไม Product ตัวนี้มันชื่อนี้?

คนสาย IT ก็ลด​ Ego ตัวเองลงนิดๆ นะครับ ลองมองในภาพที่มันกว้างขึ้นบ้าง .... อย่าคิดว่ามันเป็นของพวกเราเท่านั้น ต้องทำแบบเราเท่านั้น หรือทุกอย่างปลายทางอยู่ที่เป็นแบบพวกเราเลยครับ

ป.ล. สำหรับคนที่อยากแชร์ มันน่าจะได้แค่ amazon link นะครับ เพราะว่าที่ผมเขียนนี่ ผมทำไว้แค่ friends only ครับ

115 Nameless Fanboi Posted ID:6dDocMKiFd

ปัจจัยหนึ่งที่ทำให้ปัญหา Developer หนักขึ้นคือหลายคนเข้าใจแต่การ Scale quantity ของทีมงานเพื่อแก้ปัญหางานเยอะ

Whatsapp - ทีม 30 คน ดูแล 900M Users
Gojek - ทีม 12 คน ดูแล 1 ล้านคนขับ (ไม่ใช่ Users ด้วยนะ ตัว Users เยอะกว่านั้นอีกแน่ๆ)

แล้วผมก็เห็นข่าวทีมงาน 100+ คนทำแอพพลิเคชั่นที่ผมคิดว่า 2-3 คนทำน่าจะได้ คนพัฒนาก็ตีซะใหญ่โตว่าแบบลงทุนเยอะเจ๋งมาก

ผมก็นั่งคิดในใจว่า โครงการนี้ คงใช้เวลา น่าจะใช้เวลา 7-9 เดือน นั่งวางโครงสร้างและ Process ให้ 100+ คนทำงานร่วมกันได้โดยไม่ตีกัน ตอนเขียนจริงอาจจะ 2 สัปดาห์

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

ธรรมชาติงานพัฒนาซอฟต์แวร์ พอคนมันเยอะเกินจุดที่มันเหมาะสม ยิ่งมีคนเยอะก็ยิ่งช้าลง

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

(ส่วนตัวผมเคยบอกเจ้านายหลายครั้งใน Career เลยนะว่า Allocate คนมาเพิ่มไม่ช่วย เอามาก็เหยียบเท้ากันตีกันเปล่าๆ โครงสร้างมันไมไ่ด้รองรับให้คน x คนทำงานด้วยกัน รื้อโครงสร้างให้รองรับก็ยิ่งเลทกว่าเดิม)

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

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

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

เราต้องการจำนวนโปรแกรมเมอร์เยอะขึ้นหรือเปล่านะในตลาด ต่อให้เยอะขึ้น ต้องการเยอะขึ้นเท่าไหร่กันแน่

116 Nameless Fanboi Posted ID:4Pc/Emg+vD

>>115 เข้าใจอะไรผิดปะวะ support ไม่ใช่ dev แล้ว gojek ก็มี dev มากกว่า 12 คนแน่ๆ มึงเอาเรื่องมาปนกันอะ

117 Nameless Fanboi Posted ID:6dDocMKiFd

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

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

ดังนั้นการอยู่รอดในอนาคตต้องพึ่งพากันทั้งสองฝั่ง
คนทั้งสองฝั่งเลยเอางานมาพักไว้ที่เราเยอะเพราะอย่างนี้นี่เอง เพราะเขาคุยกันไม่รู้เรื่อง

เปิดคอร์ส
- Programming for Non Tech
- Business for Tech
ดีมะ #ขายของ

118 Nameless Fanboi Posted ID:tAwwkuhc4G

อยากเย็ด แมรี่ สยามดรีม จังเลยครับ

https://imgur.com/Oa4i2CR
https://imgur.com/9q1xksb
https://imgur.com/zbiNqv1
https://imgur.com/3hJrTUj

119 Nameless Fanboi Posted ID:Ek/L2Q92Ro

วันนี้ได้ฟังเรื่องราวหลายๆ อย่างเหลือเกิน

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

พอคิดดีๆ ลูปมันก็ครบ ดีมานด์ซัพพลายก็สมดุล บริษัทไทยเองก็ได้ของดีขึ้น นักพัฒนาไทยเองก็มีความเป็นอยู่ที่ดีขึ้น มันก็ไม่วิกฤติอะไรหรอก สุดท้ายเงินก็หมุนกลับมานักพัฒนาไทยนี่แหละ และของที่ได้ก็กลับมาที่ไทยเหมือนกัน ทุกคนก็วินๆ กันหมด แค่มีเศษเงินหลือๆ กระฉอกออกไปที่เมืองนอกหน่อยบ้างก็คิดซะว่าเป็นค่าน้ำชงน้ำชาไป

เราจะไปเห็นเป็นปัญหาทำไมกันนะ

(สถานะนี้อาจทำลายตัวเองได้)

120 Nameless Fanboi Posted ID:i8pffGD7jH

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

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

แหม่ ..... ผมนี่แทบจะหลุดว่า

"You don't tell a computer scientist who is a mathematician that solving a problem takes time. Time complexity for solving any problem depends on 'how' you solve it.

Don't tell me you need time. Tell me your understanding of the problem and tell me your "solution" ("algorithm" - how would you solve it).

Time isn't a solution. Time is needed for executing a solution."

แหม่ .... จริงๆ เล้ย

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

แม้แต่เรื่องที่ต้องการความเข้าใจมากๆ อย่างคณิตศาสตร์และ Computer Science เรายังเรียนมาเป็นการใช้เครื่องมือแบบจ๋าๆ ได้เลย (สูตร คือ เครื่องมือ, Library คือเครื่องมือ, Programming Languages คือเครื่องมือ ฯลฯ)

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

When all you know is a hammer, everything suddenly looks like a nail.

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

หลายคนบอกว่าต้องใช้เวลา แล้วหวังว่าวันหนึ่งปัญหามันจะหายไป ...... หรือปัญหามันจะแก้ตัวมันเอง .....

แต่ส่วนมาก วิธีการแก้ปัญหาของบ้านเรา คือ "บังคับให้คนอยู่กับปัญหาจนชินไปเอง" ..... นั่นคือ Hammer ของเราครับ ... ตอกให้คนจมลงไปอยู่กับปัญหา

122 Nameless Fanboi Posted ID:eDHofW5cRm

เคยเห็นกระทู้ถามว่า "ทดสอบรับคนเข้างานด้วย Algorithm เวิร์คมั้ย" ในบอร์ดเมืองนอก

- มีคนแชร์ว่าเคยรับคนที่ไม่ได้อัลกอริธึมแล้วเวิร์ค รับคนที่ไม่ได้แล้วไม่เวิร์คขาดตรงไหน
- มีคนแชร์ว่าเคยรับคนที่ได้อัลกอริธึมแล้วไม่เวิร์ค แชร์ว่ามันทดสอบอะไรได้และที่มันทดสอบไม่ได้คืออะไร
- DHH คนสร้าง Rails ก็ออกมาบอกว่าเขาไม่ใช้แล้วใช้อะไรแทน
- มีคนจาก Top tech (F,M,A,G) ออกมาบอกว่าทำไมเขายังทำอยู่
- มีแม้แต่คนที่ทำ Opensource ระดับโลกที่เคยตกโจทย์อัลกอริธึมตอนไปสมัครงาน ออกมาบอกว่าเขาติดอะไร

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

ดีนะที่ไม่เคยตั้งคำถามนี้ออกไปให้ใครฟังนอกบริษัท เราคุยกันเรานั่งตั้งคำถามกันแล้วเราก็ปรับปรุงวิธีสัมภาษณ์กันเนียนๆ

สังคมข้างนอกเนี่ยมี Prejudge สูงมาก

123 Nameless Fanboi Posted ID:eDHofW5cRm

ว่าด้วยเรื่องการสอบสัมภาษณ์ด้วย Algorithms

- ปกติแล้วจะใช้ในกรณีบริษัทขนาดกลางหรือใหญ่ขึ้นไป บริษัทข้ามชาติหรือบริษัท Startup ที่ต้องการโปรแกรมเมอร์ที่ต้องแก้โจทย์ยาก ๆ หรือต้องทำ Optimization เยอะ ซึ่งมีผลต่อผลกำไรของบริษัทโดยตรง
- โจทย์มักจะคล้าย ๆ กับคอมพิวเตอร์โอลิมปิคหรือ ICM-ICPC ในระดับง่ายถึงปานกลาง ใช้เวลา 30 นาที - 3 ชั่วโมง
- อัตราส่วนในการแก้โจทย์ได้ประมาณ 10%-20% ซึ่งถ้าบริษัทมีคนมาสัมภาษณ์เยอะ ๆ ก็ค่อนข้างคุ้มที่จะได้คนเก่ง ๆ ไปสัมภาษณ์ทัศนคติต่อ
- ปกติแล้วจะมีเพียง 1-2 โจทย์ ง่ายกับปานกลาง หรือปานกลางอย่างเดียว
- บางครั้งโจทย์เหมือนจะเป็นโจทย์ Algorithm แต่จริง ๆ แล้วคุณต้องแก้ด้วยเซนส์ทางคณิตศาสตร์
- บางครั้งแกล้งใส่ Bug ไว้ในคำถามเพื่ออยากรู้ว่าจะแก้ปัญหายังไง บางคนหนีกลับบ้านก็มี บางคนก็เดินมาถาม บางคนก็ทำไปเลย
- เมื่อแก้โจทย์ได้แล้วจะมีการรีวิวโค้ดและสัมภาษณ์วิธีการแก้ปัญหา ดูสไตล์การเขียน ดูวิธีการตอบคำถาม ประสบการณ์และทัศนคติอื่น ๆ ซึ่งมักจะสำคัญกว่าวิธีในการแก้โจทย์
- การมีโจทย์จะทำให้วัดความรอบคอมของคนสอบ และสไตล์การทำงานได้คร่าว ๆ เช่น บางคนมั่นใจมาก ทำแปปเดียวเสร็จแล้วคิดว่าถูกก็ส่งเลย บางคนก็ใช้เวลาจนหมดเพื่อพิจารณาโดยละเอียด บางคนนั่งเขียนเทสให้ด้วย
- โจทย์แบบนี้มักจะใช้ในงานที่เงินเดือนค่อนข้างสูง
- ถามว่ามีประโยชน์ไหม ส่วนตัวคิดว่ามีประโยชน์มากสำหรับงานที่ต้องการคนแบบนี้จริง ๆ หรือใช้ในการคัดกรอง Outlier เก่ง ๆ ในกรณีที่มีคนสัมภาษณ์เยอะ แต่ในบางงานก็ไม่จำเป็น เช่น งาน Client Side (Front End) ก็ทดสอบด้วยการเขียนอย่างอื่นแทน แต่ก็อาจจะมีบางบริษัทที่ต้องการ Optimize ฝั่ง Front End
- การสอบสัมภาษณ์ไม่ใช่ทุกอย่าง บางครั้งบริษัทอาจเลือกจากสิ่งที่คุณเป็น เช่นบริษัทก็อาจจะมีโควต้าจำกัด ถ้าเลือกรับได้แค่ไม่กี่คน แต่มีตัวเลือกที่เก่งเท่ากันและทัศนคติเท่ากันหลาย ๆ คน บริษัทอาจรับคนที่บ้านใกล้กว่า กินเบียร์เก่งกว่า แต่งงานแล้ว(ปัญหาน้อยกว่า) โสด(เวลาว่างเยอะกว่า) เล่นดนตรีเก่ง อะไรแบบนี้ก็มีเหมือนกัน

126 Nameless Fanboi Posted ID:NgHSXg0rmj

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

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

ปล. Facebook, Google, Microsoft, Apple เวลาพูดถึงเรื่องนี้เขาก็ยอมรับนะว่าระบบให้ความสำคัญกับการที่ไม่พลาดท่ารับคนที่ไม่ถึงมาตรฐานมาก ทำให้หลายครั้งก็จะไปพลาดไม่ได้รับคนที่เกินมาตรฐานแต่ไม่เหมาะกับแบบทดสอบไปเสียได้ และก็ยอมรับว่าตอนนี้เป็นแบบนี้เพราะยังหาวิธีดีกว่านี้ไม่เจอ ก็แค่นั้น

127 Nameless Fanboi Posted ID:vqdWOUzumi

>>126 อ่านแล้วเก็ตอยู่นะ สมมติ ไปเอาคนกากๆทำงานไม่ได้มา นี่ก็อายอยู่นะ

128 Nameless Fanboi Posted ID:ArYYlu8/h0

ปกติ id ในโม่งมันมีวิธีอ่านเป็น ip address ไหม

129 Nameless Fanboi Posted ID:PT.PriE3.A

ส่วนตัว ผมไม่ mind เรื่องไม่เชี่ยวชาญ stack ปัจจุบันนะ ไม่ได้อยากได้คนที่ exact match จ๋าๆ ด้วย ผมมองว่าสายงานเราความรู้ตามกันทันแค่อ่าน แต่ความสามารถในการอ่านแล้วซึมซับได้

ผมแชร์อีกมุมละกันว่า ผมไม่เสียดายมากนักกับความเชี่ยวชาญใน stack ปัจจุบันที่ใช้อยู่

130 Nameless Fanboi Posted ID:fwekwgHuoR

bb github รู้สึกว่าแพงไป บางทีต้อง add คนอื่นที่ไม่ได้อยู่ในทีมเข้ามาด้วย แล้วซื้อเป็นรายปีมันต้อง add seat ทั้งปี
จริง ๆ ถ้า github มีระบบ guest แบบไม่เสียตังจะดีกว่านี้

ตอนนี้มีใช้หลาย service ที่ pay per user มันแพงมาก ๆ เลย รับงานมาแทบจะไม่กำไรเพราะไอพวกนี้แหละ

131 Nameless Fanboi Posted ID:/VJqDqGGDF

สำหรับท่านใดที่กำลังให้ความสนใจ Serverless แล้วเกิดข้อสงสัยว่าทำยังไงเราถึงจะสามารถ ย้ายระบบ Web ของเราไปเป็น Serverless ได้บ้าง
.
มีบทความแนะนำจาก freeCodeCamp ครับ แต่จะเป็นการ Migrate ไปที่ Serverless ของ AWS น่ะครับ
.
The Ultimate Guide to Migrating to Serverless
https://www.freecodecamp.org/news/migrating-your-app-to-the-cloud-using-serveless/
.
ขั้นตอน
1. ย้าย API เล็กๆที่ไม่ได้ต่อ DB ก่อน เช่น API การจัดการรูปภาพ, การส่งเมล์ ออกมาที่ AWS Lambda and API Gateway
2. ย้าย DB มาที่ Amazon DynamoDB หรือ Amazon RDS
3. ย้าย API ที่ต่อ DB ที่เหลือมาที่ AWS Lambda and API Gateway
4. ย้ายการเก็บ File มาที่ AWS - Amazon S3
5. ย้าย Static Web ไปวางที่ AWS - Amazon S3 และจัดการ Domain Name ผ่านทาง Amazon Route 53
.
สุดท้ายก็มีแนะนำ Course Free ให้ลองเรียนเพิ่มเติมครับ
https://courses.completecoding.io/p/build-a-serverless-api/
.
ปล. ถ้ายังไม่หนำใจ จัด Course Free นี้ต่อได้เลยครับ
https://serverless-stack.com/
เป็น Course สอนพัฒนา Full-Stack Apps ด้วย AWS Serverless และ React
มาทุกขั้นตอนเลยตั้งแต่สมัครใช้งาน AWS, จัดการ users, เขียน Web API, Web UI, Automation
.
Happy Coding
.
🔥🔥🔥

132 Nameless Fanboi Posted ID:jlQkcUfYCx

There are a lot of articles say "Every engineer must start thinking of x as a primary concern, not as an afterthought".

Honestly, I think this is not a healthy way to approach software engineering because

1. More than 80% of software engineers work with legacy code in daily-basis. So the lesson about how to make it right from the start will be valuable for only a few portions of software engineers and applicable to very few systems. We should talk more about migrating and change.

2. If I gather all these articles, there will be too many x that no one can even start a project. We should also consider the context of the system and prioritize all the x-es accordingly.

I believe that great software engineer should be proficient in managing change and evolving the system.

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

หลายๆ บทความ Tech โดยเฉพาะเวลาโปรโมต Practice ใหม่ๆ "เราต้องคิดถึง X ตั้งแต่เริ่มโปรเจ๊กต์ ไม่ใช่คิดทีหลัง ต้องออกแบบมาให้รองรับแต่แรก"

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

1. Developer เกิน 80% ทำงานกับ Legacy code ดังนั้นบทความที่เขียนว่าทำยังไงให้ถูกต้องตั้งแต่เริ่มวางระบบ มีประโยชน์และใช้ได้จริงกับคนแค่ไม่กี่คนและระบบไม่กี่ระบบเท่านั้น เราควรจะพูดถึงวิธี Evolve กับ Migrate ระบบให้รองรับ X ได้บ้าง ไม่ใช่บอกว่าคุณต้องคิดมาให้ดีแต่แรกครับอย่างเดียว

2. ถ้าเอาทุกบทความพวกนี้มารวมกัน X จะมีเยอะมากจนไม่น่าจะมีใครเริ่มงานได้เลย น่าจะใส่ใจกับบริบทแล้ว Prioritize X ต่างๆ ตามบริบท ไม่ใช่โยนโครมแล้วทุบดินว่าต้องทำอย่างเดียวโดยไม่สนใจบริบท

ผมเชื่อว่า Software engineer ที่เก่ง ต้องมีความสามารถในการจัดการบริหารความเปลี่ยนแปลงและปรับปรุงระบบที่มีอยู่แล้ว ซึ่งเรื่องนี้ยากกว่าการออกแบบระบบใหม่เยอะ

133 Nameless Fanboi Posted ID:JNJ0LoIyZW

IMHO,

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

การหาของเล่นใหม่ๆ มาลองเล่น ลองผิดลองถูก ลองให้รู้ การรู้จักสังเกต subtleties เล็กๆ น้อยๆ ที่สร้างความแตกต่างให้ของเล่นนั้นๆ ความรู้เชิงลึกที่ประกอบลงไปกับความแตกต่างเล็กๆ น้อยๆ เหล่านั้น ว่ามัน make differences อย่างไร และ tradeoff มันคืออะไร .... การมีความเห็น มี opinion ของตัวเองเกี่ยวกับของเล่นนั้นๆ รวมถึงการไปอ่านความเห็นคนอื่นใน forum ที่เกี่ยวข้อง (ขอ forum ที่ civilized หน่อยละกัน ที่เต็มไปด้วยพวก geek เพียงพอ และ respect ซึ่งกันและกันเพียงพอ)

ย้ำ: "ของเล่น และเล่นสนุกกับมันนะ" ไม่ใช่ "จำเป็นต้องใช้ด้วยความจำเป็น"

ถ้าเราจะเอาแค่รู้จักพวกนี้ "เพราะว่าต้องใช้ในงาน" เราจะรู้จักอะไรน้อยไปเสมอ และพัฒนาตัวเองยากเสมอ (ซึ่งจะทำให้ทีมและงานพัฒนาไม่ได้ไปด้วย)

ของเล่นผมก็รองเท้า หูฟัง กล้อง ... ส่วน forum ที่ผมอ่านประจำ เข้าไปคุยบ่อยๆ ก็ head-fi (หูฟัง) styleforum (รองเท้า) เป็นต้น (วันก่อนเพิ่งจะเปิดโลก ด้วยการนั่งตามอ่าน thread เกี่ยวกับรองเท้า Antonio Meccariello ..... ว่าโลกของ High-End จริงๆ นี่เค้าเล่นอะไรกัน ..... โหดมาก ละเอียดมาก ..... เพิ่งจะรู้ว่ามันสังเกตแบบนั้นได้ด้วย มันมีรายละเอียดแบบนี้ด้วย)

ไม่ใช่มีรองเท้าไว้ใส่ ยังไงก็ได้ หูฟังไว้ฟังเพลง ยังไงก็ได้ เอาแค่กระแสว่าดี คนอื่นใช้กัน ฯลฯ

ของเล่นในเชิงการเขียนโปรแกรมก็เช่นกัน

เราต้องหาของเล่นเหล่านี้ตลอดเวลา ไม่ว่าจะเป็น library, framework, programming languages, รวมถึง computation models ต่างๆ .....

คนเก่งๆ ที่ผมรู้จักแทบทุกคน จะหาพวกนี้เล่น ลอง ตลอดเวลา และรู้สึก wow กับอะไรที่มันเพิ่ม expression power ให้กับพวกเขา ....

การมีของเล่นแบบนี้ มันสะท้อนชัดเจนหลายอย่างเลยนะ

134 Nameless Fanboi Posted ID:wrQ7.ECC9d

ความเห็นและความหงุดหงิดส่วนตัว

เห็นคนวิเคราะห์ WeWork กันตอนล่มด้วยคำอธิบายง่ายๆ ว่า ขาดทุน เท่ากับ หลอกลวง ก็จะบอกว่า Startup ที่ Valuation สูง ไม่มีกำไรแล้วพอ IPO ก็พบว่าของจริงแกร่งจริงก็มีเยอะนะ

จะบอกว่าที่เราต้องไม่ลืมในวงการนี้คือ
- Startup 90% Failure rate นะ แต่ถ้าติดแล้วกำไรมักจะเกิน 10-100 เท่า ก่อนลงทุนก็รู้ข้อนี้ไว้ก่อนนะ จะได้ทั้งไม่โดนหลอกให้ลงทุน และไม่ตัดสินว่า Startup ล้มเหลวเท่ากับกาก
- ผมมองว่า Unit economics สำคัญมาก ตราบใดที่ต้นทุนในการหาลูกค้าและดูแลลูกค้ามันชัดเจนแล้วสเกลได้

ผมยกตัวอย่างง่ายๆ ดีกว่าว่าสมมติคุณไปเจอสูตร Online marketing อันนึงที่มันเวิร์คมากๆ ลงแล้วได้ลูกค้าแน่นอน แล้วสูตรที่ว่าบางทีมันอยู่ได้แป๊ปเดียวมันมี Timing window เช่น เจอ Keyword ทองคำ หรือ Segment ทองคำ ที่ลงถูกและผลตอบแทนดี ถ้าไม่รีบลงเงินใส่ ซักพักคนอื่นรู้ แข่งประมูล ราคาขึ้น ก็ไม่ทองคำอีกต่อไปละ

กลยุทธ์หนึ่งที่ทำได้คือลงเงินกับตรงนั้นจนกว่าจะไม่ได้ลูกค้าเพิ่มจนกว่าจะ Stagnate ลงไม่ได้ ซึ่งจังหวะนี้ยังไงก็ต้องระดมทุนมาลง

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

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

ซึ่งก็บอกได้เลยว่าแน่นอน จะลงทุนแล้วไม่ดูรายละเอียดเนี่ย ไม่ได้หรอกนายเอ๋ย เราก็แค่เซ็งๆ อยู่บ้างที่คนเก่งหลังเกมบอกว่า "เนี่ย ดูก็รู้แล้ว ง่ายๆ เลย ขาดทุนทุกปี ไปไม่มีทางรอดหรอก ดูง่ายๆ ก็รู้แล้ว" แล้วแบบออกตัวว่าเก่งกันใหญ่เป็นฉันฉันไม่โดนหลอกหรอกดูแค่นี้ก็รู้แล้ว แหม่ มันง่ายขนาดเลยเหรออออออออ มาซาโยชิ ซัน เจ้าของ Softbank นักลงทุนมือทอง นี่โดนหลอกง่ายมากขนาดนั้นเชียวนะเนี่ย

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

135 Nameless Fanboi Posted ID:LxYk920oAz

Agile is not a way to go fast. It is a way to know where you are going.

Agile is does not increase productivity. Agile increases manageability.

Agile does not guarantee you’ll get there on time. Agile destroys the hope that you might, when you won’t.

136 Nameless Fanboi Posted ID:dPEazNs4Pz

โค้ดสตาร์

137 Nameless Fanboi Posted ID:dPEazNs4Pz

เย็ดโค้ดสตาร์

138 Nameless Fanboi Posted ID:dPEazNs4Pz

อมควยโค้ดสตาร์

139 Nameless Fanboi Posted ID:dPEazNs4Pz

ระเบิดอัลเลาะห์กับโค้ดสตาร์

140 Nameless Fanboi Posted ID:/h95nb2ahk

เว็บที่ให้เราเขียนโค้ดออนไลน์แต่ละที่มีข้อดีข้อเสียแตกต่างกันครับ ก่อนหน้านี้ผมชอบเขียนบน LeetCode เพราะเขียนโจทย์ได้ดีกว่าที่อื่น อ่านเข้าใจง่าย แต่ช่วงนี้หันมาเล่น Clash Of Code แทนครับ เพราะเน้นให้เราคิดเร็ว พิมพ์เร็ว ไม่ยอมแพ้อะไรง่ายๆ

ช่วงนี้ Clash Of Code มีคนจากเมืองไทยติดอันดับ Top 10 ด้วยครับ ตามมาเชียร์และมาฝึกเขียนโค้ดกันได้ที่นี่ครับ

https://www.codingame.com/multiplayer/clashofcode

141 Nameless Fanboi Posted ID:g963aIIwH9

แคลชพ่อมึงตายแห่งควยโค้ดสตาร์

142 Nameless Fanboi Posted ID:g963aIIwH9

เน็ตเหี้ยและล่มจมเพราะโค้ดสตาร์

143 Nameless Fanboi Posted ID:g963aIIwH9

ศาสนาแรกของโลกก็คือศาสนาโค้ดสตาร์

144 Nameless Fanboi Posted ID:K5IFc0yFCJ

เห็นคนแชร์เรื่องสัมภาษณ์งานในสมาคมอะไรซักอย่าง ทำให้อยากเขียนสิ่งนี้ขึ้นมาเลย

ชีวิตนี้ ผมสัมภาษณ์งานไม่ผ่านเยอะมากเลยนะ น่าจะเยอะกว่าที่หลายคนคิดไว้

แต่สุดท้าย เวลามันใช่ มันใช่ของมันเอง

ตอนที่ผมเข้า Taskworld ใหม่ๆ ใช้ Git เป็นงูๆ ปลาๆ มาก Javascript build รวมกันยังไงก็ไม่รู้ คนอื่นเขา Grunt เขา Webpack ของเราที่ทำมาตลอดยังแค่ใช้ script มารวมๆ กันอยู่เลย เขียน React ก็ไม่เคย ตอนนั้นได้งานทำ SPA มาคือเขียน Framework SPA เล็กๆ เอง เพราะไม่รู้จัก React

ที่อื่นจะไม่รับก็ไม่แปลก จะบอกว่าไม่เชี่ยวชาญพอก็เถียงไม่ได้แหละ

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

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

ถ้าเรามองจากมุมของคนที่ออกแบบสัมภาษณ์ ไม่แปลกเลยที่จะหาวิธีการพัฒนาให้มันแฟร์ขึ้น แม่นยำขึ้น ดีขึ้น

แต่ถ้าเราเป็นคนสัมภาษณ์ ก็อยากจะให้มองมันอย่างเข้าใจ

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

บางทีมันไม่มีใครผิดใครถูกหรอก หรือเปล่าประโยชน์ที่จะไปหา

มันก็แค่ไม่ใช่เวลาไม่ใช่โอกาส ก็แค่นั้น

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

ผมเชื่ออย่างหนึ่งว่า กฎแรงดึงดูดมีจริงนะ

ผมเป็นคนที่ออกความเห็นเยอะ เขียนอะไรเยอะ

คนชอบก็มี คนไม่ชอบก็มี พูดมากขนาดนี้ คนหมั่นไส้ก็คงมีเยอะแน่ๆ

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

แต่ชีวิตมันกินทุกโอกาสไม่ได้

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

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

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

มันเป็นธรรมดาของโลกนี้ ไม่ได้มีใครผิดใครถูก มันแค่เข้ากันไม่ได้

สัมภาษณ์งานก็เหมือนกัน ถ้ามันไม่เหมาะ เวลามันไม่ใช่ โอกาสไม่ใช่ มันก็ไม่ได้ ก็แค่นั้นแหละ

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

อยากให้กำลังใจน้องๆ หรือเพื่อนๆ พี่ๆ ที่อาจจะกำลังย้ายงาน

วันนี้เราสัมภาษณ์ไม่ผ่าน เราอาจจะคิดว่า มันต้องมีใครผิด ไม่ฉันผิด ก็อีกคนผิด ไม่ฉันแย่ ก็บริษัทแย่ พยายามอธิบายด้วยแนวคิดผิดถูก

ความผิดหวังเป็นเรื่องธรรมดา ผมผ่านมาเยอะนะ

แต่จริงๆ โลกมันซับซ้อนกว่านั้น เป็นสีเทามากกว่านั้น

อยากให้เชื่อมั่นว่าสุดท้ายโลกจะหาสิ่งที่ใช่เข้ามาหาเรา ผลักสิ่งที่ไม่ใช่ออกไปจากเรา

กฎแรงดึงดูดมีจริงเสมอ ผมเชื่อ และก็ผ่านมาแล้ว

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

แต่กฎแรงดึงดูดจะทำงานได้ดี เราต้องมั่นคง ต้องมี Integrity คอยพัฒนาตัวเองในแนวทางที่ตัวเองเป็นอยู่สม่ำเสมอ จนความเป็นตัวตนชัดเจนขึ้น

ถ้าเราไม่มี Integrity ไม่มีความชัดเจน หลอกลวงไปเรื่อย ทำตัวเฉไฉไปมาต่อโลกนี้ โลกจะเลือกให้เราไม่ถูก กฎแรงดึงดูดก็จะงง ไม่รู้ว่าจะดึงอะไรเข้ามา โลกก็จะดึงดูดสิ่งต่างๆ เข้ามาในชีวิต อย่างมั่วซั่วสะเปะสะปะไปหมด ให้เราเสียเวลาปวดหัว

ความไม่ชัดเจนนั้นอาจจะเกิดจากความไม่มั่นใจในตัวเอง หรืออาจจะเกิดจากเจตนาที่หลอกลวง ผมมิอาจตัดสินว่ามาจากเจตนาใด

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

ชีวิตช่วงไหนที่ผมสับสนกับตัวเองมากๆ โอกาสต่างๆ ที่เข้ามาก็จะสับสนมาก พอๆ กับความสับสนภายในจิตใจ

ผมถึงเชื่อในกฎแรงดึงดูด

และก็อยากเตือนด้วย

ถึงแม้จะเชียร์ว่า ให้เป็นตัวตนของตัวเอง แต่ก็อย่าให้ความเป็นตัวเรามันไม่ได้ไปบดบังคนอื่น Abuse คนอื่น

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

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

แสดงความเป็นตัวตนในกาลเทศะและเวลาที่เหมาะสม ไม่กดคนอื่นลงเพียงเพื่ออยากขับเน้นตัวเองให้เด่นขึ้น

ทั้งให้กำลังใจและก็เตือนสตินะ

145 Nameless Fanboi Posted ID:hVKt8ve17r

ก็หีแม่มึงมันสวิงกิ้งแบบโค้ดสตาร์

146 Nameless Fanboi Posted ID:hVKt8ve17r

การที่เว็บบอร์ดนี้มันร้างเพราะSIRNมันโดนลักพาตัวโดยโค้ดสตาร์

147 Nameless Fanboi Posted ID:hVKt8ve17r

โค้ดสตาร์แม่งแย่งข้าวกูแดก

148 Nameless Fanboi Posted ID:hVKt8ve17r

โค้ดสตาร์มันชาติเหี้ยทำให้กูปวดหัว

149 Nameless Fanboi Posted ID:hVKt8ve17r

ฝุ่นPM 2.5 เกิดขึ้นมาได้ก็เพราะว่าโค้ดสตาร์

150 Nameless Fanboi Posted ID:l7gjDlZ9Af

โค้ดสตาร์ทำให้กูต้องมานอนตอนนี้

151 Nameless Fanboi Posted ID:.BrhVtl6PZ

>>150 มึงรอเล่นมุกนี้มานานมั้ยเนี่ย

152 Nameless Fanboi Posted ID:dgPoGmed5u

>>151 ไม่นานเพราะไอเหี้ยโค้ดสตาร์นี่แหละ

153 Nameless Fanboi Posted ID:l4YnjwzBB5

รถติดก็เพราะโค้ดสตาร์มอมเมาคนมาเรียน

154 Nameless Fanboi Posted ID:l4YnjwzBB5

รู้ไหมว่าขนาดพระเยซูยังนับถือศาสนาโค้ดสตาร์เลย

155 Nameless Fanboi Posted ID:l4YnjwzBB5

พระแม่อุมาหน้าหีไปเรียนกับโค้ดสตาร์แล้วมาปิดถนนสีลม

156 Nameless Fanboi Posted ID:Dd8heMKoaN

โค้ดสตาร์ทำให้ประชาชนคนไทยยากจน

157 Nameless Fanboi Posted ID:HtSfFE/JRk

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

158 Nameless Fanboi Posted ID:/DjWmyGu27

เรื่องขำๆของเซเลปท่านนึง

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

รอบสอง บอกว่าจะไม่ยุ่งกะกลุ่ม level 1 แต่เข้ามายังไงไม่รู้ ก็มีดราม่าตามคาด แล้วรอบนี้ ออกเอง แอตมิน แคบไว้ แต่บอกชาวโลกว่า แอตมินเตะออก

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

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

มีน้องที่ทำงานด้วยบอกเคยไปเรียน PHP yii ด้วย แล้วเหมือนติด config ก็เลยไปช่วยดู กลับโดนตวาดใส่ “เก่งแล้ว มาเรียนทำไม” อีหยังวะ ยังงี้ก็ได้เหรอ

แยกย้ายทำงานๆ

159 Nameless Fanboi Posted ID:fLJEn7Z5Db

>>157 เพราะอีพระอุมาหน้าหีมาเรียนโค้ดสตาร์เลยต้องปิดถนน

160 Nameless Fanboi Posted ID:I2P6cl4lEI

วันนี้นั่งอ่านว่าผิดหวังจาก Blazor แล้วจะไปลองเล่นอะไรดีสำหรับโฮมเพจเกม (คงไม่ interactive มาก แต่อย่างน้อยอยากทำเว็บที่ประกอบจาก component) ตอนแรกว่าจะลองศึกษา React Hooks แต่ใน documentation ก็ได้รู้จักกับ Svelte https://svelte.dev/

อันนี้มันเท่ตรงที่ UI Framework ปกติจะให้เราเป็นคนเขียนโปรแกรมตามกติกาแล้วเราจะพอดูออกว่า จังหวะนี้นั้นนี่เองที่ framework รู้ว่าเราอยากจะอัพเดทชิ้นส่วนไหน แต่ก็ไม่ได้รู้หมดเด๊ะๆขนาดนั้น ก็เลยต้องควบคู่กับการ diff DOM + อาจจะมีตัวช่วยอย่าง ID ประจำ element นิดหน่อยจะได้เปลี่ยน DOM ถูกที่ เช่นถ้า React ก็จะมีจังหวะตอน set state

แต่ Svelte ก้าวข้ามไปอีกขั้นคือเป็น compiler ซะเลย คือเว็บสุดท้ายที่ออกมาไม่มี framework ให้โหลดมาคู่กันด้วยซ้ำ เพราะโค้ดที่เราเขียนนั่นแหละกลายเป็น DOM manipulation ด้วยตัวเองไปแล้ว! (ประมาณว่าออกมาเหมือนเหมือนเราทนเขียน web app แล้วมาแก้ DOM ด้วยมือแบบไม่มีเครื่องมืออะไรเลย)

เขาก็เลยสร้าง syntax ภาษาใหม่ .svelte ขึ้นมาที่หลุดจากบ่วง JS ได้เลยไหนๆก็เป็น compiler แล้ว ทีนี้ก็ไม่ต้องมีพิธีที่รู้สึกได้ว่ากำลังครอบอยู่บน JS อีกต่อไป assignment เปล่าๆอย่าง foo = 50 อะไรงี้ compile กลายเป็น DOM change ซะงั้นได้ครับ ที่สำคัญไม่มีการ diff เกิดขึ้นด้วยซ้ำเพราะโค้ดสุดท้ายมันกำลังแก้หน้าเว็บสดๆจริงๆ เขาวิจารณ์ไว้ว่า Virtual DOM is pure overhead (https://svelte.dev/blog/virtual-dom-is-pure-overhead)

ตอนนี้ยังไม่ถึงไหนเท่าไหร่ แต่ syntax เขียนค่อนข้างสนุกดี ดูเหมือนโล่งๆไม่มีอะไรแต่ component ก็พร้อมใช้งานแล้ว ยากแค่ต้องมาทำความเข้าใจ bundler อย่าง Rollup / Webpack อีกหน่อยครับถ้าจะ extend (แต่อีกมุม มันก็คือความโปร่งใสดีว่าเว็บเราออกมาเป็นก้อนๆนี้ ไม่เหมือน Blazor ที่เป็น .dll วุ่นวายไปหมด)

*Angular ก็เป็น compiler เหมือนกัน ที่เขียนขึ้นมาสดๆยังใช้จริงไม่ได้ https://angular.io/guide/aot-compiler ไม่เหมือน React ที่เป็นสั่ง JS lib จริงๆ (แต่ก็ต้อง compile จาก JSX ก่อนอยู่ดี) แต่ทั้งคู่ไม่ได้ฉีกห่างออกจาก JS เว่อร์เหมือน Svelte

*แปลว่า ผอมเพรียว

161 Nameless Fanboi Posted ID:WZqtoxmmK9

ตระหนักไว้เสมอว่ามีคำว่า "Engineer" ในชื่อตำแหน่งของ "Software Engineer"
.
เป็นสิ่งนึงที่เรียนรู้มาจากอาจารย์ที่เคารพมากตอนป.ตรี อาจารย์ท่านถามว่า
.
"... รู้มั้ยทำไมงานพวกเราถึงถูกเรียกว่า Software Engineer ? ..."
.
"... ก็เพราะสิ่งที่เราต้องทำมันเป็นงาน *วิศวกรรม* ยังไงหละ ..."
.
สีหน้าสงสัยปนสนใจของเราทำให้ยังไม่ทันที่จะเอ่ยปากถาม อาจารย์ก็เดาออกทันทีว่าเราจะถามอะไร อาจารย์เลยตอบคำถามที่เรายังไม่ทันถามได้ทันที
.
"... วิศวกรซอฟต์แวร์หนะ เราไม่ได้แค่เขียนโปรแกรมให้ใช้งานได้นะ แต่หน้าที่ของเราคือต้องแก้ปัญหาทางคอมพิวเตอร์โดยคำนึงถึง *ความคุ้มค่าที่สุด* ให้ได้ด้วย ..."
.
ตั้งแต่นั้นเป็นต้นมา คำว่า "คุ้มค่าที่สุด" ก็ถูกฝังไว้ในหัวและกลายเป็นแกนกลางของการแก้ปัญหาใด ๆ ในทุกงานของเรา ความเข้าใจเพียงเบาบาง ณ ตอนนั้นก็ค่อย ๆ ถูกประสบการณ์หล่อหลอมให้เข้าใจมากขึ้นจนรู้แล้วว่ามันไม่ใช่แค่เรื่องของการพัฒนาซอฟต์แวร์ แต่กับทุกเรื่องในชีวิตเลย
.
อาจจะสงสัยว่าความคุ้มค่าที่สุดที่ว่าคืออะไร ? คำตอบคือ "เราต้องรู้ว่าจุดประสงค์ของงานนั้น ๆ คืออะไร สิ่งที่ได้กลับมามีมูลค่ามากน้อยแค่ไหน และเราต้องลงทุนลงแรงไปมากน้อยเพียงใดถึงจะคุ้มกับสิ่งที่ได้มา"
.
งานที่ทำแล้วใช้ครั้งเดียวทิ้ง ทำ Big-O แย่ ๆ โดยใช้เวลา 30 นาทีในการเขียนแล้วปล่อยให้มันรัน 1 ชั่วโมงเต็มก็ยังคุ้มค่ากว่าเขียนโปรแกรม 3 วันเต็มด้วย Big-O เทพ ๆ แต่รัน 1 นาทีเสร็จ ... แล้วก็โยนทิ้งไป
.
งานที่รันตลอดเวลา ลงทุนเขียนโปรแกรมเป็นเดือนให้ทำงานได้ ≤ O(log n) นี่แหละคือความเหมาะสมและคุ้มค่ากับสิ่งที่ได้มา
.
แต่ถ้างานมีเวลากระชั้น การนั่งทำ Big-O เทพ ๆ แล้วส่งงานไม่ทันก็อาจจะส่งผลเสียต่อธุรกิจ ก็ต้องสามารถบาลานซ์ได้ว่าจะต้องทำด้วย Big-O เท่าไหร่เพื่อให้ประสิทธิภาพยอมรับได้และส่งงานทัน แล้วค่อยมา Optimize ให้ดีขึ้นทีหลัง
.
Code Quality เทพเนียนกิ๊กแต่ Deliver งานตามกำหนดไม่ได้ รันโปรดักชั่นไม่สำเร็จ สเกลไม่รอด ธุรกิจพังไม่เป็นท่า บริษัทเจ๊ง ถ้าเทียบกับ Code Quality พอดี ๆ เขียนเทสต์ในส่วนที่จำเป็น ส่งงานทัน บริษัทกำไรเพิ่มแล้วค่อยมาปรับ Code Quality ให้สมบูรณ์ทีหลัง
.
งาน Software Engineer กับธุรกิจจึงเป็นเรื่องเกี่ยวข้องกัน หน้าที่นึงของ Software Engineer คือจะต้องสามารถนิยามคำว่า "ความคุ้มค่า" ของงานที่ตัวเองทำให้ได้
.
และการจะทำสิ่งนี้ได้นั้น เราจะต้อง "ประเมินมูลค่าของสิ่งที่ทำและสิ่งที่ตัดสินใจไม่ทำให้ได้"
.

162 Nameless Fanboi Posted ID:WZqtoxmmK9

การเขียนโปรแกรมดีเลิศ Code Quality ดี โค้ดดูแลง่าย - มีมูลค่าบวก
.
การเขียนโปรแกรมดีเกินไปจนสิ่งที่รับกลับมามีค่าน้อยกว่าแรงที่ลงลงไป (Overengineer) - มีมูลค่าลบ
.
การเขียนโปรแกรมแย่ แก้ทุกอย่างแบบ Quick & Dirty จนโค้ดดูแลไม่ได้ในระยะยาว (Technical Debt) - มีมูลค่าลบ
.
การเขียนโปรแกรมด้วยภาษาที่หาคนร่วมทีมได้ง่าย - มีมูลค่าบวก
.
การเขียนโปรแกรมด้วยภาษาที่ต้องควานหาคนทั้งปฐพีถึงจะเจอคนทำเป็นสักคน - มีมูลค่าลบ
.
การส่งงานทัน - มีมูลค่าบวก
.
การส่งงานไม่ทัน - มีมูลค่าลบ
.
การจะทำงานสักงานนึงก็ต้องเอาค่าด้านบนพวกนี้มาบวกกัน ดิฟนิดหน่อย อินทิเกรดนิดนึง (เพราะมันมีเรื่องเวลามาเกี่ยวข้อง ความคุ้มค่าระยะสั้น ความคุ้มค่าระยะยาว ล้วนมีผลต่อการตัดสินใจ) แล้วถึงตัดสินใจกันว่าจะเดินไปทางไหน
.
จะเห็นว่างานของ Software Engineer ไม่ใช่แค่เขียนโปรแกรมให้จบ ๆ ไป ไม่ใช่การเขียนให้ Code Quality ดีเลิศที่สุดในปฐพี ไม่ใช่การเขียนโค้ดที่ประสิทธิภาพล้ำจนเอาคนไปแข่ง ACM ได้ แต่เป็นการ "หาจุดคุ้มค่าที่สุดแล้วทำอย่างเหมาะสม" ต่างหาก
.
บ่อยครั้งมากที่มีคนถกเถียงกันเรื่อง Code Quality เอย เรื่องประสิทธิภาพการทำงานของโค้ดเอย เรื่องการเขียน Test เอย แล้วผลก็คือเสียงแตก จะบอกว่าไม่มีทางหรอกที่แต่ละคนจะให้คำตอบเหมือนกัน เพราะเรายังไม่ได้นิยามคำว่า "คุ้มค่า" ร่วมกันเลยนี่
.
เมื่อความคุ้มค่าไม่เหมือนกัน แล้วจะคาดหวังให้การตัดสินใจของแต่ละคนเหมือนกันได้ยังไงอ่ะ ?
.
ไม่ต้องไปถึงขั้นคนไม่รู้จักกันมาคุยกันใน Facebook Group หรอก แค่ในบริษัทตัวเอง ฝ่าย Business กับฝ่ายเขียนโปรแกรมก็ไม่สามารถคุยกันรู้เรื่องได้แล้วถ้าไม่สามารถคุยด้วยจุดมุ่งหมายเดียวกันได้
.
แล้วอะไรคือจุดมุ่งหมายร่วมกันของบริษัทหละ ?
.
"ธุรกิจก็คือธุรกิจ" ไม่ว่าจะทำอะไร ยังไงก็ต้อง Business-Driven อยู่แล้ว ถ้าไม่มีกำไรบริษัทแล้วจะไปต่อยังไง ถ้าสิ่งที่ทำกลับทำให้บริษัทขาดทุนแล้วจะเปิดบริษัทต่อไปทำไม หน้าที่ของ Software Engineer คือต้องประเมินมูลค่าออกมาเป็นตัวเลขและความคุ้มค่าให้ได้ เพื่อเอาสิ่งเหล่านี้ไปคุยกับฝ่าย Business หาจุดคุ้มค่าร่วมกันแล้วมุ่งหน้าสู่ทางนั้นเต็มอัตรา
.
ถ้ายังทำไม่ได้ นั่นแปลว่าคุณยังทำให้คนอื่นมองเห็นมูลค่าของงานที่คุณทำไม่ได้นั่นเอง
.
เป็นสกิลนึงที่อยากให้คนสาย Software Engineer ฝึกไว้ อย่าเอาแต่เขียนโปรแกรมไปวัน ๆ แต่เมื่อได้โจทย์อะไรมา เราจะต้องสามารถวิเคราะห์สถานการณ์ วางแผนไว้หลาย ๆ แบบ ประเมินมูลค่าของแต่ละแบบแล้วเลือกแผนที่ "คุ้มค่า" ที่สุด
.
เพราะมันไม่มีหรอกคำตอบที่ดีที่สุดสำหรับทุกสถานการณ์ มันมีแค่ "ทางที่เหมาะสมที่สุด" เท่านั้นแหละ
.
เหมือนที่เธอกับเราเหมาะสมกันไง 😳😳😳

163 Nameless Fanboi Posted ID:WZqtoxmmK9

พี่โดมพูดเรื่องนึงได้น่าคิด

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

Line ก็มาหลัง MSN หลัง Pirch หลัง ICQ
Gmail มาหลัง Hotmail
Booking Agoda พวกนี้ก็มีมานานแล้ว
Kapook มาหลัง Yahoo

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

164 Nameless Fanboi Posted ID:Xwx2VBLIQm

At my (now former) company, we use a metric called SHOT to track the performance within a portfolio. It's some in-house calculation no one else uses, but it's been around for like 20 years even though no one remembers what the acronym is supposed to mean. My task was to average it over a time period, with various user-defined smoothing parameters... to accumulate it, in essence.

So, I don't like long variable names like "accumulated_shot_metric" or "sum_of_SHOT_so_far" for what is ultimately just the cumulated SHOT value. So I gave it the short name, "cumShot", not thinking twice about it, and checked it into the code. Seeing that it passed all tests, I went home and forgot about it.

Two months later, today, my boss called me into a meeting with HR. I had no idea what was going on, but apparently, the "cumShot" variable had become a running joke behind my back. Someone had given a printout to the CEO, who became angry over my "unprofessional humor" and fired me. I didn't even know what anyone was talking about until I saw the printout. I use abbreviated variable names all the time, and I'm not a native speaker of English so I don't always know what slang is offensive.

I live in California. Do I have any legal recourse? Also, how should I explain this in future job interviews?

165 Nameless Fanboi Posted ID:.ioNbtqt3s

อันนี้ผมเคยบอกแล้วว่า เงินเดือน ไม่เกี่ยวกับ skill เลยซะทีเดียว มันมีปัจจัยหลายอย่าง
หลักๆคือ มันคือความพอใจของคนจ่าย ที่เค้าได้ผลประโยชน์ตามที่เค้าต้องการครับ
คนเก่งมากๆ เขียนได้วันนึงหลายอย่าง แต่อาจจะได้เงินเดือนน้อย ไม่ใช่เพราะเค้าไม่เก่ง แต่เค้าอาจจะอยู่ในจุดที่บริษัทไม่ได้ให้ความสำคัญ
กลับกันคนที่เขียนโปรแกรมเก่งระดับหนึ่ง อาจจะได้เงินเดือนมากกว่าคนแรกสองเท่า เพราะเค้าทำงานในจุดที่ spotlight สาดแสง เลยทำให้มีความสำคัญ
คนที่สาม อาจจะเขียนโปรแกรมได้น้อยกว่าสองคนแรก แต่เค้าทำงานในบริษัทที่รายได้มากกว่าสองบริษัทแรก 50 เท่า เลยได้เงินเดือนมากกว่าคนแรก 10 เท่า
ทั้งหมดจึงขึ้นอยู่กับปัจจัยต่างๆ ซึ่งส่วนตัวผมเรียงลำดับความสำคัญดังนี้
- สถานะทางเศรษฐกิจของบริษัท
- ความสามารถในการแก้ปัญหาทางธุรกิจ(ไม่ใช่แค่แก้ปัญหาในการเขียนโปรแกรม)
- ความจำเป็นของงานต่อธุรกิจ
- มาตรฐานทางเงินเดือนของประเทศ
- ความเก่งในการ code ของคนคนนั้น
จะเห็นว่าในมุมมองส่วนตัวผม สิ่งที่สำคัญคือ คุณทำงานให้ใคร และคุณมีคุณค่าทางธุรกิจให้เขาไหม มากกว่าความสามารถในการเขียนโปรแกรมเพียวๆ
อย่าลืมว่าทุกบริษัทต้องการผลกำไร ไม่ใช่ product ที่โคตรเจ๋ง 100% code coverage แต่ไม่มีผลกำไรเลย

166 Nameless Fanboi Posted ID:9d3UIqdxmc

ถามเหตุการณ์สมมติกับเพื่อนโม่งหน่อยครับ

สมมติมี Startup ด้านการเงินสัญชาติยุโรปมาตั้งบริษัทในไทยแห่งหนึ่งเพื่อ develop software ให้บริษัทแม่แล้วไม่จ่ายเงินเดือนพนักงานมา 2 เดือน รวมถึงค้างค่าใช้จ่ายต่าง ๆ เช่น ประกันสังคม (ไม่ได้ส่งมาหลายเดือน), AWS, Jira, Bitbucket, ค่าเช่าออฟฟิศ ฯลฯ เพราะอ้างว่าเงินทุนก้อนใหญ่มากกำลังจะเข้ามา (ซึ่งไม่น่าจะจริง) แต่ติดปัญหาเรื่องการเดินเอกสาร และให้พนักงานทำงานฟรีมา 2 เดือนจนขึ้นเดือนนี้ถึงให้หยุดอยู่บ้านไปก่อน และในระหว่างนี้พนักงานหลายคนก็เดือดร้อนเรื่องเงินเพราะมีภาระต้องผ่อนหนี้ค่าบ้าน/คอนโด/รถ หรือส่งลูกเรียนแบบนี้

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

ย้ำว่านี่เป็นเหตุการณ์สมมตินะครับ

167 Nameless Fanboi Posted ID:uq2L9xGw2Y

ไปอ่านบล็อกนึงใน Reddit ที่ Github บอกว่าเขาไม่ใช้ Foreign key constraint เพราะอะไร

มีคนอ่านบอกว่า ปัญหานี้มันเฉพาะตัวของ Github ไม่ใช่ปัญหาที่คนทั่วไปเจอ

ผมตอบว่า No one tasked to solve generic problem, ever. แล้วผมก็แชร์บล็อกนี้เลยใน Tech Articles Group

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

ผมอยากชวนคิดว่า เราอยากจะหา Generic solution หรือมักจะเรียกอีกชื่อหนึ่งว่า "Best practice" ที่ใช้ได้ในกรณีทั่วไปเพื่ออะไร

ถ้าระบบหรือที่ไหนเจอ Generic problem เขาก็ไปอ่าน Generic solution แล้วก็ทำตามนั้นก็จบ จะจ้างเรามาทำงานทำไม คนเขียนวิธีอย่างละเอียดในการแก้ไข Generic problem มีเยอะแยะไปหมด

ทุกคนทุกระบบ เจอ Specific problem ที่จำเป็นต้องใช้ Specific solution ในการแก้ไขทั้งนั้น ดังนั้น ในแง่นี้ การที่เรารู้จัก Generic solution หรือ AKA. Best practices ไม่ได้การันตีเลยว่ามันจะแก้ไขปัญหาของเราได้ ต้องบอกว่าส่วนมากจะไม่ได้ด้วยซ้ำไป

อ้าว แล้วถ้างั้นเราควรจะทิ้ง Best practice ไปมั้ย ไม่สนใจเลยเหรอ? เราจะเรียน Best practices ไปทำไม

เพราะเวลาพัฒนาระบบเนี่ย มันไม่มีใครรู้ว่า Solution คืออะไรไงล่ะ ถ้ามีคนรู้จริงๆ แล้วเนี่ย งานมันไม่มาถึงเราหรอก

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

ทีนี้ประโยชน์ของ Best practices มันก็คือตรงนี้ คือคุณลอง Apply best practices ไปในตอนที่ยังหา Solution ที่เป๊ะๆ ไม่เจอ โอกาสที่มันจะใกล้เคียงกับ Solution มีเยอะกว่า Apply อะไรก็ไม่รู้มั่วซั่วเยอะ ดังนั้น เวลาไม่รู้อะไร ผมก็แนะนำ Best practices ก่อนเสมอ เป็น Bet ที่ดีกว่าลองมั่วซั่วแน่ๆ คุณควรจะรู้แล้วใช้มันเป็นฐานตั้งต้นเสมอ

แต่คุณจะไปสรุปว่ามันเป็นคำตอบถาวรของระบบไม่ได้ คุณยังต้องสังเกตและ Iterate ต่อจากตรงนั้นไปด้วย แล้วถ้าจะปรับเปลี่ยน ก็ต้องเปรียบเทียบว่าทางออกที่ไม่ได้ตรงกับ Best practice นั้นในบริบทของเรามันดีกว่าหรือแย่กว่า ก็ต้องค้นหากันต่อไปเรื่อยๆ ตราบที่ระบบยัง Evolve อยู่ยังต้องดูแลกันอยู่

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

จุดที่ยากที่สุดคืออะไร คือเราต้องเผชิญหน้ากับความจริงว่า ไม่มีใครรู้คำตอบของระบบเราทั้งนั้น ถ้ามีคนรู้ ทุกวันนี้มันจะมีปัญหาเหรอ?

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

ทุกวันนี้ ทุกคนอยากให้มีคนรู้คำตอบ แต่ไม่มีใครอยากผ่านขั้นตอนในการ "ค้นหาคำตอบ" ตัว Business อยากให้มีคนรู้คำตอบ Investor คาดหวังว่าจะมีคนรู้คำตอบ Junior คาดหวังว่าจะมีคนรู้คำตอบ Senior คาดหวังว่าคนอื่นจะรู้คำตอบ แต่ไม่มีใครอยากผ่านขั้นตอนการค้นหาคำตอบ

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

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

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

168 Nameless Fanboi Posted ID:uq2L9xGw2Y

>>166 ฟ้องกรมแรงงานก่อนได้เปรียบ

169 Nameless Fanboi Posted ID:3jb8hqnwz8

ผมเห็นด้วยที่ว่า Agile ไม่ได้แปลว่า เร็ว (ใน Absolute Term/Sense) ... ทุกอย่างมันขึ้นกับ Frame of Reference ว่าเราเอาอะไรไปเทียบกับมัน และมันเหมาะสมหรือไม่ มัน Overkill เกินไปหรือเปล่า ในทุกเรื่อง

ผมเห็นว่าทุกกระบวนการ มันมี Scale ที่เหมาะกับมันเอง สิ่งที่จะทำให้มันยากลำบากและช้าลง ไม่ใช่ที่ตัวกระบวนการ แต่เป็นการไม่เหมาะสมกันระหว่าง Process และ Scale ต่างหาก

นี่ยังไม่รวมถึงลักษณะงาน และเป้าหมายนะ ... เช่น ถ้าเป็นงานแบบ "ใช้แล้วทิ้ง" ใน Scale ที่เล็กพอที่จะ Cowboy-Developer ได้ตรงๆ แบบดุ่มๆ ไปเลย เดี๋ยวก็เสร็จ และการันตีได้ว่าไม่ต้องดูแลต่อ (ไม่ว่าจะโดยใครก็ตาม) การทำ Agile ก็ Overkill ไม่ต่างอะไรกับการใช้ Process อื่น ...

แต่กับอีกหลายงานมันก็ไม่ใช่แบบนั้น

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

ประเด็นมันไม่ใช่ Agile เร็วหรือไม่เร็ว เพราะตัวมันเองไม่ใช่ความเร็ว เพียงแต่ว่าเมื่อนำมันไปใช้กับ "งานบาง Scale" แล้วมัน "เร็วกว่า Waterfall-based ในระยะสั้นและระยะกลาง" และ "เร็วกว่า Cowboy-Develop ในระยะกลางและระยะยาว"

ซึ่งพอเรา "เคยชิน​" กับ Frame of Reference บางอย่าง (พูดอีกอย่าง คือเรามี Implicit Frame of Reference) เราอาจจะรู้สึกว่ามัน "เร็วขึ้น"​ เสมอ แต่ถ้าเราเคยชินกับอีก Frame หนึ่ง เราอาจจะรู้สึกว่ามัน "ช้าลง" เสมอ เช่นกัน

การนำ Process ไปใช้ ถ้าเรารู้สึกว่ามันเร็วขึ้น แปลว่า Scale ของงานที่เราทำ และ Process มันมี matching ที่ดีกว่า แต่ในขณะเดียวกันถ้ามันช้าลง แปลว่า matching มันไม่ดี

ประเด็นสำคัญคือ ... ทีมงานหลายทีม ใช้ Process ผิด Scale .... ส่วนหนึ่งก็เพราะว่าตอนเรียน เรียน Process for Enterprise มา .. แต่ตอนทำโปรเจ็คจบ หรืองาน Freelance แรกๆ ดันทำแบบ Cowboy ....

ต้องยอมรับกันนะ ว่างานบ้านเราที่ต้องใช้ Scale ระดับ Enterprise มันไม่ได้มีเยอะขนาดนั้น แต่งานส่วนมากมันเกิด Scale ของ Cowboy Coding ไปเยอะอยู่

Agile จึงเป็นทางออกที่ดี และผมเห็นว่ามันเป็น Bootstrapping Platform ที่ดี สำหรับการ Rescale Enterprise ให้เป็น Smaller Units ในการทำงานต่างๆ

แต่ที่แน่ๆ คือ เราต้องแยกแยะให้ออกระหว่างตัวปรัชญา (Philosophy) ของแต่ละอย่าง กับ "Implementation" ของมันทั้งหลาย ไม่ว่าจะเป็นการ Implement แบบไหนก็ตาม

หลายอย่าง Philosophy ดีมาก เช่นพวก CMMi แต่ตัวปรัชญามันเอาไปทำอะไรไม่ได้ มันก็ต้องมี Implementation ... ซึ่งแน่นอนว่า Implementation ทุกตัวมันจะเหมาะกับบางรูปแบบ (เช่น บางตัวเน้นการใช้เอกสาร) ... แต่ถ้าเราถอดเปลือกของ Implementation กลับไปมองที่ประเด็นของปรัชญาของมัน เราอาจจะสร้าง Process ใหม่ๆ ได้โดยไม่อิงกับ Implementation บางแบบที่ไม่เหมาะสม ได้ทั้งนั้น

ก็เช่นเดียวกันกับ Agile .... ณ วันที่ผมลงชื่อใน Manifesto เมื่อประมาณ 15 ปีก่อน ....​ ณ วันนั้นมันยังไม่มี Agile Methodology หรือ Agile Process มากมายดังเช่นทุกวันนี้ ยังไม่มี Scrum ไม่มี Kanban ไม่มีอะไรทั้งนั้น ... พวกนี้เกิดจากการเอาปรัชญาไปใช้สร้าง Process ของตัวเอง จนมันเวิร์กขึ้นมา และทำจนเชี่ยวชาญ จนมันเร็ว

บางที กลับไปหาปรัชญามันซะบ้าง แล้วก็คิดบ้าง ว่ามันไม่มี one size fit all ... และทุกอย่างมันไม่มี absolute term

ผมจะลบโพสท์นี้ในอีก 1 ชั่วโมง

170 Nameless Fanboi Posted ID:e+6VmtQKo9

>>169 ในนี้มันลบไม่ได้ไอสัส

171 Nameless Fanboi Posted ID:STBXBlb+JA

>>166 หางานใหม่เหอะ เป็นกุเดือนเดียวก็ไม่อยู่แล้ว ดูทรง เจ้าของลอยแพ แน่นอน อยากได้ไปฟ้องเอา

172 Nameless Fanboi Posted ID:hBLAW2aEjn

Gartner ทำนายเอาไว้ในปี 2017 ว่าภายในปี 2019 จะมีแบรนด์ราว 20% ถอดใจกับ mobile app ของตัวเอง

ไม่รู้ว่าตอนนี้ตัวเลขมันไปถึงไหนแล้ว แต่ส่วนตัวคิดว่าการทำ mobile app มันจะถูกลดความนิยมในอีกไม่นาน และถูกแทนที่ด้วย web technology มาตรฐานใหม่ ๆ ที่สามารถทำงานได้ในทุก ๆ อุปกรณ์มากกว่า

มีงานวิจัยจาก Forrester ที่ให้บทสรุปออกมาแม้ว่าคนส่วนใหญ่จะใช้เวลาในแต่ละวันเกือบ 85% หมดไปกับมือถือ แต่ก็มีแค่ราว ๆ 5 apps เท่านั้นแหละที่ถูกเรียกใช้งานถี่ที่สุด

ผมมานั่งนับดูของตัวเอง.. เออ จริง ๆ ก็ใช้หลัก ๆ แค่นี้แหละ facebook, line, gmail, youtube และที่ขาดไม่ได้คือ chrome

คุณมีกี่ app ในมือถือของคุณ?
คุณใช้วันละกี่ app?
app ละกี่ครั้งต่อวัน?

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

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

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

ถ้าธุรกิจของคุณกำลังสนใจอยากจะทำ mobile app ไว้ใช้สักอัน.. ลองพิจารณาดูให้ถี่ถ้วนก่อนนะครับว่า.. ไหวหรอ? 😅

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

REF:
- https://www.gartner.com/en/marketing/insights/articles/gartner-predicts-2017-marketers-expect-the-unexpected

- https://techcrunch.com/2015/06/22/consumers-spend-85-of-time-on-smartphones-in-apps-but-only-5-apps-see-heavy-use/

173 Nameless Fanboi Posted ID:WYMdlczbsy

คอมติดไวรัส .zobm ทำไงถึงกู้ไฟล์ได้คับ

174 Nameless Fanboi Posted ID:wZhk2CE1aB

หนึ่งใน "หนังสือที่ผมอยากให้โปรแกรมเมอร์ทุกคนอ่าน" ....

The Elements of Programming Style โดย Brian Kernighan และ P.J. Plauger

หนังสือตั้งแต่ปี 1974 (2nd edition ปี 1978) ที่ยังคงคลาสสิคและ "core content", "messages", "philosophy", "wisdom" มันยังคง relevant ในปัจจุบัน

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

ไม่ว่าจะเป็นเรื่องพวก test-driven, unit-testing, readable code, clean & clear code, SOLID, etc ..... โดยเ​ฉพาะอย่างยิ่งเรื่องอย่าบ้ากับเรื่อง performance มากนักในกรณีทั่วไป ..... (ถ้าต้องบ้าขนาดนั้น ส่วนมากต้องมาดู algorithm ของตัวเองใหม่แล้วล่ะ -- ซึ่งในเล่มนี้เขียนว่า "Don't diddle code to make it faster. Find better algorithm") .... หรือต้อง measure/profile ก่อน optimize ... อย่าเชื่อความคิดตัวเองเรื่อง performance มากกว่าตัวเลขจริง​ (และ algorithm complexity) ฯลฯ

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

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

พูดง่ายๆ คือมันเป็น Timeless Wisdom

ผมแปะ snapshot จากหนังสือเล่มนี้ให้อ่านครับ เป็นตัวอย่าง ว่าทำไมมันน่าอ่าน

175 Nameless Fanboi Posted ID:Vop6Qp206C

>>172 แอพ พวกที่รอดต้องแบบที่รวดเร็ว ไม่เหมาะกับใช้บนบราวเซอร์ ใช้บนเว็บยิ่งไม่สะดวก แป๊บๆคือเข้าใช้งานได้เลย หรือไม่ก็ต้องออกแนวที่เชื่อมต่อกับอุปกรณ์บนมือถือ , IoT ต่างๆ

176 Nameless Fanboi Posted ID:S1YqZW4nc+

หนังสืออีกเล่ม ที่อยากให้โปรแกรมทุกคนอ่าน ..... ด้วยเหตุผลเดียวกับเล่มเมื่อวาน คือ Timeless Wisdom .....

"The Art of UNIX Programming" ..... โดย Eric S. Raymond (ESR)

ชื่อหนังสืออาจจะทำให้คนคิดว่าเป็นการสอนเขียนโปรแกรมบน UNIX หรือหัดใช้ UNIX API (System Calls) อะไรพวกนี้ .... แต่จริงๆ มันคนละเรื่องเลย .... Very far from that ด้วยซ้ำ

มันคือปรัชญาและ Wisdom เบื้องหลังการสร้าง UNIX (และโปรแกรมใน UNIX Ecosystem) ที่ผมถือว่าเป็น very-well-designed และ stood the test of time มากๆ .... จนกระทั่งปัจจุบัน

ทุกอย่างในนี้ยังคง relevant ..... ทุกวันนี้เราก็ยังคงต้องสอนเรื่องแบบนี้กันอยู่

ลองอ่านตัวอย่างบางหน้าดูได้ครับ

ป.ล. ... ผมอยากจะจัดคลาส based on เล่มนี้ และ The Elements of Programming Style มากๆ เลยนะ :D