Last posted
Total of 361 posts
bb github รู้สึกว่าแพงไป บางทีต้อง add คนอื่นที่ไม่ได้อยู่ในทีมเข้ามาด้วย แล้วซื้อเป็นรายปีมันต้อง add seat ทั้งปี
จริง ๆ ถ้า github มีระบบ guest แบบไม่เสียตังจะดีกว่านี้
ตอนนี้มีใช้หลาย service ที่ pay per user มันแพงมาก ๆ เลย รับงานมาแทบจะไม่กำไรเพราะไอพวกนี้แหละ
สำหรับท่านใดที่กำลังให้ความสนใจ 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
.
🔥🔥🔥
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 ที่เก่ง ต้องมีความสามารถในการจัดการบริหารความเปลี่ยนแปลงและปรับปรุงระบบที่มีอยู่แล้ว ซึ่งเรื่องนี้ยากกว่าการออกแบบระบบใหม่เยอะ
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 ให้กับพวกเขา ....
การมีของเล่นแบบนี้ มันสะท้อนชัดเจนหลายอย่างเลยนะ
ความเห็นและความหงุดหงิดส่วนตัว
เห็นคนวิเคราะห์ 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 พลาดตรงนี้ อันนั้นมันง่ายไปเยอะเลย
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.
โค้ดสตาร์
เย็ดโค้ดสตาร์
อมควยโค้ดสตาร์
ระเบิดอัลเลาะห์กับโค้ดสตาร์
เว็บที่ให้เราเขียนโค้ดออนไลน์แต่ละที่มีข้อดีข้อเสียแตกต่างกันครับ ก่อนหน้านี้ผมชอบเขียนบน LeetCode เพราะเขียนโจทย์ได้ดีกว่าที่อื่น อ่านเข้าใจง่าย แต่ช่วงนี้หันมาเล่น Clash Of Code แทนครับ เพราะเน้นให้เราคิดเร็ว พิมพ์เร็ว ไม่ยอมแพ้อะไรง่ายๆ
ช่วงนี้ Clash Of Code มีคนจากเมืองไทยติดอันดับ Top 10 ด้วยครับ ตามมาเชียร์และมาฝึกเขียนโค้ดกันได้ที่นี่ครับ
แคลชพ่อมึงตายแห่งควยโค้ดสตาร์
เน็ตเหี้ยและล่มจมเพราะโค้ดสตาร์
ศาสนาแรกของโลกก็คือศาสนาโค้ดสตาร์
เห็นคนแชร์เรื่องสัมภาษณ์งานในสมาคมอะไรซักอย่าง ทำให้อยากเขียนสิ่งนี้ขึ้นมาเลย
ชีวิตนี้ ผมสัมภาษณ์งานไม่ผ่านเยอะมากเลยนะ น่าจะเยอะกว่าที่หลายคนคิดไว้
แต่สุดท้าย เวลามันใช่ มันใช่ของมันเอง
ตอนที่ผมเข้า Taskworld ใหม่ๆ ใช้ Git เป็นงูๆ ปลาๆ มาก Javascript build รวมกันยังไงก็ไม่รู้ คนอื่นเขา Grunt เขา Webpack ของเราที่ทำมาตลอดยังแค่ใช้ script มารวมๆ กันอยู่เลย เขียน React ก็ไม่เคย ตอนนั้นได้งานทำ SPA มาคือเขียน Framework SPA เล็กๆ เอง เพราะไม่รู้จัก React
ที่อื่นจะไม่รับก็ไม่แปลก จะบอกว่าไม่เชี่ยวชาญพอก็เถียงไม่ได้แหละ
แล้วสุดท้าย ก็น่าประหลาดใจที่มันเป็นที่ๆ เหมาะกับตัวเองในช่วงชีวิตตอนนั้นมากๆ มันมีเคมีที่เข้ากัน และทั้งผมทั้งบริษัทก็ได้เติบโตจากกันและกันมากมายมหาศาล
=============================
ถ้าเรามองจากมุมของคนที่ออกแบบสัมภาษณ์ ไม่แปลกเลยที่จะหาวิธีการพัฒนาให้มันแฟร์ขึ้น แม่นยำขึ้น ดีขึ้น
แต่ถ้าเราเป็นคนสัมภาษณ์ ก็อยากจะให้มองมันอย่างเข้าใจ
บางปัจจัยอย่างเราอาจจะท้องเสียวันนั้นพอดี คนสัมภาษณ์อาจจะรีบร้อนวันนั้นพอดี หรือแม้แต่บริษัทมีปัจจัยอะไรซักอย่างให้อยู่ดีๆ ต้องรัดเข็มขัด ตัด Headcount ที่จะรับเพิ่ม ทั้งๆ ที่กำลังจะรับอยู่แล้ว ก็เกิดได้
บางทีมันไม่มีใครผิดใครถูกหรอก หรือเปล่าประโยชน์ที่จะไปหา
มันก็แค่ไม่ใช่เวลาไม่ใช่โอกาส ก็แค่นั้น
=============================
ผมเชื่ออย่างหนึ่งว่า กฎแรงดึงดูดมีจริงนะ
ผมเป็นคนที่ออกความเห็นเยอะ เขียนอะไรเยอะ
คนชอบก็มี คนไม่ชอบก็มี พูดมากขนาดนี้ คนหมั่นไส้ก็คงมีเยอะแน่ๆ
บางคนมาเห็นความเห็นแล้วจะตัดโอกาสของเราไม่อยากร่วมงานกับเรา ไม่อยากให้โอกาส คิดว่าแบบแนวคิดของเราไร้สาระ ตัดโอกาสทิ้ง เกิดขึ้นได้มั้ย ก็คิดว่าเกิดขึ้นได้
แต่ชีวิตมันกินทุกโอกาสไม่ได้
และการที่เราเลือกที่จะเป็นตัวเอง แสดงความเป็นตัวตน ก็จะนำพาโอกาสที่ใช่เข้ามาหา และผลักโอกาสที่ไม่ใช่ออกไป
ผมเชื่อว่า โอกาสที่ใช่ จะยอมรับความเป็นตัวเรา และทำให้เราดึง Best version ของตัวเองออกมาได้ โอกาสที่ใช่ จะรู้สึกอุ่นใจกับตัวตนของเรา
โอกาสที่ไม่ใช่ จะไม่ยอมรับความเป็นตัวเรา จะรู้สึกว่าตัวตนของเราไม่เหมาะกับเขา จะอึดอัดกับความเป็นตัวตนของเรา
มันเป็นธรรมดาของโลกนี้ ไม่ได้มีใครผิดใครถูก มันแค่เข้ากันไม่ได้
สัมภาษณ์งานก็เหมือนกัน ถ้ามันไม่เหมาะ เวลามันไม่ใช่ โอกาสไม่ใช่ มันก็ไม่ได้ ก็แค่นั้นแหละ
=============================
อยากให้กำลังใจน้องๆ หรือเพื่อนๆ พี่ๆ ที่อาจจะกำลังย้ายงาน
วันนี้เราสัมภาษณ์ไม่ผ่าน เราอาจจะคิดว่า มันต้องมีใครผิด ไม่ฉันผิด ก็อีกคนผิด ไม่ฉันแย่ ก็บริษัทแย่ พยายามอธิบายด้วยแนวคิดผิดถูก
ความผิดหวังเป็นเรื่องธรรมดา ผมผ่านมาเยอะนะ
แต่จริงๆ โลกมันซับซ้อนกว่านั้น เป็นสีเทามากกว่านั้น
อยากให้เชื่อมั่นว่าสุดท้ายโลกจะหาสิ่งที่ใช่เข้ามาหาเรา ผลักสิ่งที่ไม่ใช่ออกไปจากเรา
กฎแรงดึงดูดมีจริงเสมอ ผมเชื่อ และก็ผ่านมาแล้ว
ย้อนกลับไปคิดก็ขอบคุณโลกนี้ที่สุดท้ายพาโอกาสที่ใช่เข้ามาในชีวิต ผลักโอกาสที่ไม่ใช่ออกไป มันอาจจะเป็นโอกาสที่ใช่ของคนอื่น เป็นโอกาสที่ดีในสายตาคนอื่น แต่ไม่ใช่ของเรา
แต่กฎแรงดึงดูดจะทำงานได้ดี เราต้องมั่นคง ต้องมี Integrity คอยพัฒนาตัวเองในแนวทางที่ตัวเองเป็นอยู่สม่ำเสมอ จนความเป็นตัวตนชัดเจนขึ้น
ถ้าเราไม่มี Integrity ไม่มีความชัดเจน หลอกลวงไปเรื่อย ทำตัวเฉไฉไปมาต่อโลกนี้ โลกจะเลือกให้เราไม่ถูก กฎแรงดึงดูดก็จะงง ไม่รู้ว่าจะดึงอะไรเข้ามา โลกก็จะดึงดูดสิ่งต่างๆ เข้ามาในชีวิต อย่างมั่วซั่วสะเปะสะปะไปหมด ให้เราเสียเวลาปวดหัว
ความไม่ชัดเจนนั้นอาจจะเกิดจากความไม่มั่นใจในตัวเอง หรืออาจจะเกิดจากเจตนาที่หลอกลวง ผมมิอาจตัดสินว่ามาจากเจตนาใด
แต่ผมเชื่อว่า โลกนี้จะงง สรรหาพื้นที่ให้คุณไม่ถูก กฎแรงดึงดูดจะสับสน ดึงดูดสิ่งต่างๆ เข้ามาอย่างมั่วซั่วเละเทะ ถ้าคุณไม่มีความชัดเจน
ชีวิตช่วงไหนที่ผมสับสนกับตัวเองมากๆ โอกาสต่างๆ ที่เข้ามาก็จะสับสนมาก พอๆ กับความสับสนภายในจิตใจ
ผมถึงเชื่อในกฎแรงดึงดูด
และก็อยากเตือนด้วย
ถึงแม้จะเชียร์ว่า ให้เป็นตัวตนของตัวเอง แต่ก็อย่าให้ความเป็นตัวเรามันไม่ได้ไปบดบังคนอื่น Abuse คนอื่น
ว่าการทำให้ตัวเองเด่นโดยกดคนอื่นให้ด้อย โยนความผิดให้สิ่งรอบข้าง โดยอ้างว่านี่คือความเป็นตัวตน ฉันไม่แคร์ วางตัวเหนือกว่า มันไม่น่ารักนะ
มันผลักโอกาสต่างๆ ออกไปนะ มันจะดึงดูดคนที่คิดว่า "การกดคนอื่นเพื่อให้ตัวเองเด่นเป็นธรรมดาโลก" เข้ามาในชีวิตนะ
แสดงความเป็นตัวตนในกาลเทศะและเวลาที่เหมาะสม ไม่กดคนอื่นลงเพียงเพื่ออยากขับเน้นตัวเองให้เด่นขึ้น
ทั้งให้กำลังใจและก็เตือนสตินะ
ก็หีแม่มึงมันสวิงกิ้งแบบโค้ดสตาร์
การที่เว็บบอร์ดนี้มันร้างเพราะSIRNมันโดนลักพาตัวโดยโค้ดสตาร์
โค้ดสตาร์แม่งแย่งข้าวกูแดก
โค้ดสตาร์มันชาติเหี้ยทำให้กูปวดหัว
ฝุ่นPM 2.5 เกิดขึ้นมาได้ก็เพราะว่าโค้ดสตาร์
โค้ดสตาร์ทำให้กูต้องมานอนตอนนี้
รถติดก็เพราะโค้ดสตาร์มอมเมาคนมาเรียน
รู้ไหมว่าขนาดพระเยซูยังนับถือศาสนาโค้ดสตาร์เลย
พระแม่อุมาหน้าหีไปเรียนกับโค้ดสตาร์แล้วมาปิดถนนสีลม
โค้ดสตาร์ทำให้ประชาชนคนไทยยากจน
ทำไมมีการปิดถนนที่อนุเสาวรีย์ตอนเช้า กับสีลมตอนเย็น ๆ เมื่อวันก่อน พอรู้บ้างไหม
เรื่องขำๆของเซเลปท่านนึง
เท่าที่จำได้
โตนเตะรอบแรกเพราะสั่งลบกลุ่ม แต่เฟสบุ๊ค รออนุมัติ 14 วัน ก็เลยยังมีกลุ่มนี้อยู่ทุกวันนี้
แล้วก็สถาปนาตัวเองเป็นสตีฟจ๊อปเมืองไทย
รอบสอง บอกว่าจะไม่ยุ่งกะกลุ่ม level 1 แต่เข้ามายังไงไม่รู้ ก็มีดราม่าตามคาด แล้วรอบนี้ ออกเอง แอตมิน แคบไว้ แต่บอกชาวโลกว่า แอตมินเตะออก
รอบสาม โพสต์เรื่องเดิมทุกวัน เพราะปั่นยอดยูทูป เศรษฐกิจคงแย่จริงๆ คนที่บอกกลุ่มนี้ห่วยจะไม่มายุ่ง ก็เข้ามาโพสต์ประจำ เราก็แค่บอกให้เพลาๆ อาทิตย์ละครั้งพอ ก็ไม่ฟัง แอดท่านนึงก็เตะออกเลย
แอดเขาก็อยู่เฉยๆตลอด ไม่เคยไปรังควานอะไร มีแต่ท่านที่เข้ามาเอง ทั้งที่บอกจะไม่ยุ่ง แล้วบอกกลุ่มมันแย่ ก็ตลกดี แล้วมาบอกคนนั้นคนนี้ต้องทำตัวแบบนั้นแบบนี้ ตัวเองพูดไรไว้ยังไม่เห็นทำอย่างที่พูดเลย จะเชื่อทำไมเนี่ย
มีน้องที่ทำงานด้วยบอกเคยไปเรียน PHP yii ด้วย แล้วเหมือนติด config ก็เลยไปช่วยดู กลับโดนตวาดใส่ “เก่งแล้ว มาเรียนทำไม” อีหยังวะ ยังงี้ก็ได้เหรอ
แยกย้ายทำงานๆ
วันนี้นั่งอ่านว่าผิดหวังจาก 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
*แปลว่า ผอมเพรียว
ตระหนักไว้เสมอว่ามีคำว่า "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 คือจะต้องสามารถนิยามคำว่า "ความคุ้มค่า" ของงานที่ตัวเองทำให้ได้
.
และการจะทำสิ่งนี้ได้นั้น เราจะต้อง "ประเมินมูลค่าของสิ่งที่ทำและสิ่งที่ตัดสินใจไม่ทำให้ได้"
.
การเขียนโปรแกรมดีเลิศ 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 ฝึกไว้ อย่าเอาแต่เขียนโปรแกรมไปวัน ๆ แต่เมื่อได้โจทย์อะไรมา เราจะต้องสามารถวิเคราะห์สถานการณ์ วางแผนไว้หลาย ๆ แบบ ประเมินมูลค่าของแต่ละแบบแล้วเลือกแผนที่ "คุ้มค่า" ที่สุด
.
เพราะมันไม่มีหรอกคำตอบที่ดีที่สุดสำหรับทุกสถานการณ์ มันมีแค่ "ทางที่เหมาะสมที่สุด" เท่านั้นแหละ
.
เหมือนที่เธอกับเราเหมาะสมกันไง 😳😳😳
พี่โดมพูดเรื่องนึงได้น่าคิด
"เป็นคนที่สามารถทำสิ่งที่ทุกคนรู้ๆ นี่แหละแต่ทำได้ดี" ผมว่านี่คือเรื่องที่สำคัญมากๆ ตลอดหลายปีมานี่ เวลาอยู่ในวง Startup เราจะเจอสิ่งที่เป็นเรื่องใหม่ๆ ตลอดเวลา แต่เรามักจะพบว่าเบอร์ต้นๆ ที่ประสพความสำเร็จ ดันทำเรื่องเดิมๆ นั่นแหละ อิหยังวะ
Line ก็มาหลัง MSN หลัง Pirch หลัง ICQ
Gmail มาหลัง Hotmail
Booking Agoda พวกนี้ก็มีมานานแล้ว
Kapook มาหลัง Yahoo
ทำเรื่องเดียวกัน คนทำคนละคน มันก็ไม่ใช่ว่าจะออกมาประสพความสำเร็จเหมือนกัน งานนี้ถ้าพี่บี๋ทำได้ ขึ้นแท่นผู้ชนะสิบทิศเลย
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?
อันนี้ผมเคยบอกแล้วว่า เงินเดือน ไม่เกี่ยวกับ skill เลยซะทีเดียว มันมีปัจจัยหลายอย่าง
หลักๆคือ มันคือความพอใจของคนจ่าย ที่เค้าได้ผลประโยชน์ตามที่เค้าต้องการครับ
คนเก่งมากๆ เขียนได้วันนึงหลายอย่าง แต่อาจจะได้เงินเดือนน้อย ไม่ใช่เพราะเค้าไม่เก่ง แต่เค้าอาจจะอยู่ในจุดที่บริษัทไม่ได้ให้ความสำคัญ
กลับกันคนที่เขียนโปรแกรมเก่งระดับหนึ่ง อาจจะได้เงินเดือนมากกว่าคนแรกสองเท่า เพราะเค้าทำงานในจุดที่ spotlight สาดแสง เลยทำให้มีความสำคัญ
คนที่สาม อาจจะเขียนโปรแกรมได้น้อยกว่าสองคนแรก แต่เค้าทำงานในบริษัทที่รายได้มากกว่าสองบริษัทแรก 50 เท่า เลยได้เงินเดือนมากกว่าคนแรก 10 เท่า
ทั้งหมดจึงขึ้นอยู่กับปัจจัยต่างๆ ซึ่งส่วนตัวผมเรียงลำดับความสำคัญดังนี้
- สถานะทางเศรษฐกิจของบริษัท
- ความสามารถในการแก้ปัญหาทางธุรกิจ(ไม่ใช่แค่แก้ปัญหาในการเขียนโปรแกรม)
- ความจำเป็นของงานต่อธุรกิจ
- มาตรฐานทางเงินเดือนของประเทศ
- ความเก่งในการ code ของคนคนนั้น
จะเห็นว่าในมุมมองส่วนตัวผม สิ่งที่สำคัญคือ คุณทำงานให้ใคร และคุณมีคุณค่าทางธุรกิจให้เขาไหม มากกว่าความสามารถในการเขียนโปรแกรมเพียวๆ
อย่าลืมว่าทุกบริษัทต้องการผลกำไร ไม่ใช่ product ที่โคตรเจ๋ง 100% code coverage แต่ไม่มีผลกำไรเลย
ถามเหตุการณ์สมมติกับเพื่อนโม่งหน่อยครับ
สมมติมี Startup ด้านการเงินสัญชาติยุโรปมาตั้งบริษัทในไทยแห่งหนึ่งเพื่อ develop software ให้บริษัทแม่แล้วไม่จ่ายเงินเดือนพนักงานมา 2 เดือน รวมถึงค้างค่าใช้จ่ายต่าง ๆ เช่น ประกันสังคม (ไม่ได้ส่งมาหลายเดือน), AWS, Jira, Bitbucket, ค่าเช่าออฟฟิศ ฯลฯ เพราะอ้างว่าเงินทุนก้อนใหญ่มากกำลังจะเข้ามา (ซึ่งไม่น่าจะจริง) แต่ติดปัญหาเรื่องการเดินเอกสาร และให้พนักงานทำงานฟรีมา 2 เดือนจนขึ้นเดือนนี้ถึงให้หยุดอยู่บ้านไปก่อน และในระหว่างนี้พนักงานหลายคนก็เดือดร้อนเรื่องเงินเพราะมีภาระต้องผ่อนหนี้ค่าบ้าน/คอนโด/รถ หรือส่งลูกเรียนแบบนี้
เพื่อนโม่งจะตัดสินใจยังไงครับ ลาออกและเงินเดือนที่ค้างอยู่จะเป็นไงก็ช่างมัน? เชื่อมั่นในบริษัทและทนรอเงิน? จะฟ้องกรมแรงงานมั้ย? หรือจะทำอะไรบ้างครับ?
ย้ำว่านี่เป็นเหตุการณ์สมมตินะครับ
ไปอ่านบล็อกนึงใน 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 ที่ผมเขียนหรือให้คำปรึกษาสิ จบเลย" แค่นี้ทุกคนก็พร้อมจะจ่ายเงินให้แล้วไม่คิดอะไรต่อแล้วอ่ะ ดี ไม่ต้องผ่านขั้นตอนค้นหา เป็นโมเดลธุรกิจที่ดีมากเลย
แต่มันเป็นคำตอบจริงมั้ยนะ ก็ขอให้โชคดีกับขั้นตอนการ "ค้นหาคำตอบ" ที่ปลอมตัวใส่เสื้อผ้าว่านี่คือการ "มีคำตอบให้ แค่ทำตาม" ละกัน
ปล. ผมก็ทำที่ปรึกษามานะ แต่ผมบอกว่าที่ผมเสนอให้ก็คือการทดลอง แต่ผมมีเหตุผลว่าทำไมเลือกทดลองแบบนี้ คาดหวังอะไร ถ้าอยากลองท่าที่ผมคิดมาให้จากประสบการณ์ที่เคยทดลองมาหลายแบบ ก็ทดลองไปด้วยกัน ไม่เคยบอกเลยซักครั้งว่ารู้คำตอบดี
ผมเห็นด้วยที่ว่า 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 ชั่วโมง
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 ไว้ใช้สักอัน.. ลองพิจารณาดูให้ถี่ถ้วนก่อนนะครับว่า.. ไหวหรอ? 😅
ปล. ให้คำปรึกษาด้านเว็บสำหรับเจ้าของเว็บฟรี แต่ไม่รับทำนะครับ..ไม่มีเวลาทำจริง ๆ.. ทิ้งคำถามไว้หน้าไมค์หลังไมค์ตามสะดวกเลยครับ
คอมติดไวรัส .zobm ทำไงถึงกู้ไฟล์ได้คับ
หนึ่งใน "หนังสือที่ผมอยากให้โปรแกรมเมอร์ทุกคนอ่าน" ....
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 จากหนังสือเล่มนี้ให้อ่านครับ เป็นตัวอย่าง ว่าทำไมมันน่าอ่าน
หนังสืออีกเล่ม ที่อยากให้โปรแกรมทุกคนอ่าน ..... ด้วยเหตุผลเดียวกับเล่มเมื่อวาน คือ 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
ผมคิดว่าเวลาเราจะใช้อะไรควรดูให้รอบด้านครับ ความเร็วเป็นแค่มิติหนึ่งที่ใช้ประกอบการตัดสินใจ ร่วมกับว่า
1. ใช้ง่ายไหม
2. เครื่องมือที่ใช้ถนัดไหม
3. Library ที่ต้องใช้มีครบไหม
4. เขียนไปแล้วเพื่อนอ่านออกไหม (4.1 เขียนไปแล้วตัวเองกลับมาอ่านออกไหม)
5. เทสง่ายไหม -- ถ้าสนใจจะเทส
6. ดีพลอยง่ายไหม
ยกตัวอย่าง คือ ผมไม่ชอบ syntax ภาษา go เอาซะมากๆ เลย แต่ถ้าต้องเขียน command line tool ผมก็เลือกใช้ go เพราะมันเป็น binary ไฟล์เดียว คอมไพล์เสร็จโยนไปใช้ได้เลย ไม่ว่าภาษาไหนจะมีรันไทม์ลงง่ายแค่ไหนก็สู้ go 1 binary ไม่ได้ กรณีนี้ไม่ได้ขึ้นกับว่าภาษานี้เร็วแค่ไหนเลย เพราะไม่สำคัญ
ทั้งนี้ พึงระลึกถึงคำสอนปราชญ์โบราณ ท่านกล่าวไว้ว่า Only a sith deals in absolute ครับ
ลองใช้กลยุทธ์ ทรัมป์ ก็จะได้เห็น Dark Side ของคนมากขึ้น
ได้ข้อมูลมาเยอะแยะ ดีเลย จะได้เห็นว่าจริงๆแล้วเค้าคิดยังงัยกับเรา
คนที่เห็นประโยชน์เราตอนเราดีก็มีเต็มไปหมด
ตอนเราร้ายก็ด่าเราลับหลัง
ความโกหกตอแหลมันโผล่ออกมาชัดเจน
สิ่งที่อยากได้จาก Community คือความจริงใจเป็นอันดับแรก
มันเป็นวิธีการกรองคนที่ได้ผลดีอย่างที่ตั้งใจไว้
คนที่เขาทำงานด้านมืดนี่ รู้จักจริงๆหลายคน ธรรมมะธรรมโมมาก ดูแลผู้หญิงดีมาก ไม่งั้นผู้หญิงก็ไม่มาทำงานด้วยหรอก
เพราะสังคมบีบคั้นทำงานแล้วโดนกดขี่ เก็บเงินไม่ได้ โดนขูดรีดจากผู้มีอิทธิพล แต่ละคนก็มีทางเลือกต่างกัน ไม่ต้องรีบตัดสินก็ได้ถ้ายังไม่รู้จักกันดีพอ
คนที่ทำด้านสว่างก็ทำเรื่อง Dark ๆ เยอะ ก็เห็นมาเยอะแต่ทำไรไม่ได้ พอยกเรื่อง dark ที่ตัวเองเคยทำขึ้นให้เห็น ก็แสดงตัวเป็นคนดีขึ้นมารับไม่ได้ก็แปลกดี ตัวตนจริงๆตัวเองยังยอมรับไม่ได้เลย
ริเริ่มทำไรใหม่ๆก็ไม่มีคนเข้าใจอยู่ละ ไม่จำเป็นต้องอธิบายมาก เพราะไม่ได้อยากอธิบาย อยากทำให้สำเร็จมากกว่า ยังงัยก็ทำอยู่ละ
ก็ไม่อยากจะโอ้อวดว่าตัวเองทำมาไม่น้อยกว่าใคร เห็นปัญหามากมายที่มันไปต่อไม่ได้ด้วยวิธีการเดิม ก็พิสูจน์กันละกัน เอาตัวเองให้รอดก่อน
ถ้าคิดว่าสิ่งที่ทำมาในอดีตมันคือความดี มันก็เป็นอดีต ที่ไม่ได้มีใครสนใจ ป่วยมายังไม่มีใครเหลียวแหล ทุกอย่างมันก็เป็นแค่อดีต
ผมเจ็บแทนคนใน Community มาเยอะกว่าที่หลายคนรู้ ไม่แฉก็ดีแล้วครับ แต่ละคนแสบๆทั้งนั้น
ก็อยากจะ Filter ให้เหลือน้อยๆ เหลือแต่คนที่ลำบากไปด้วยกันลุยไปด้วย
Set to Zero ถ้าไม่ทิ้งบางอย่าง เราก็ยากจะก้าวผ่าน ใครจะดราม่าก็ดราม่าไปนะครับ มีไรทำเยอะ
เอาเวลาไปทำงานสร้าง Value ให้ Community ที่คุณคิดว่าดี ดีกว่าครับ
ทำไมฝั่ง business เขาชอบมาคุยกับผมมากกว่าคุยกับ Dev และ Community ก็ลองคิดเองว่ามันยังมีปัญหาอะไรอยู่ ทำไมอีกหลายๆที่เขาไม่อยากสนับสนุน
อย่ามาเสียเวลากะผม อีกไม่กี่ปีเราก็ตายจากกันละ แมนๆก็มาคุยกันได้ ไม่ต้องโพสต์หรือนินทาลับหลัง ขี้เกียจตามไปอ่าน
ขอบคุณเพื่อนพี่ๆน้องๆที่ทักเข้ามาถามไถ่ ด้วยความเป็นห่วง กลัวสิ่งที่ทำจะเสียชื่อเสียง กังวลแทนผมซะเยอะกว่าเจ้าตัวอีก ถ้าไม่มีหนี้ผมก็ทิ้งได้หมดแหละ ตอนโดนมีดโดนปืนจ่อหัวยังน่ากลัวกว่าเยอะ เรื่องความเห็นไม่ตรงกันมันสิวมากสำหรับผม เรื่องที่ทำมันไม่ได้คิดเองเออเอง มันผ่านการคิดจากผู้หลักผู้ใหญ่ที่สนับสนุน พร้อมรับผล มันคืองานของผมกับทีม ไม่ตัองโยงไปกับ กลุ่มใด vision ใด ไม่ได้เกี่ยวกันเลย ผู้หลักผู้ใหญ่บอกมาว่าถ้าร่วมกันทำงานสำเร็จ รอบหน้าจะพาไปเขียนโค้ดบนเรือยอร์ช #DEAN
เห็นพี่ที่เคารพท่านหนึ่งพูดเรื่องเข้าใจ พื้นฐาน OOP ผิดกันเยอะ
ทั้งหมดโพสต์นี้เป็นความเห็นส่วนตัวของผมนะ แต่ก็เป็นวิธีที่ผมใช้มอง OOP แล้วยังคง Sanity ไว้ได้
- OOP ตัวตั้งต้นของ Alan Kay พูดถึงเรื่อง State encapsulation ซึ่งผมเข้าใจว่าเขาต้องการแบ่งปัญหาออกเป็นปัญหาย่อยๆ และจัดระเบียบและแบ่งสันปันส่วนว่าระบบตรงไหนเข้าถึง State ตรงไหนได้บ้าง ซึ่งเขาไม่ได้สนใจเรื่อง Code reuse เลย ไม่มี Polymorphism ด้วย ไม่ต้องพูดถึง Inheritance เลย
- ยุคหนึ่ง การทำ Dynamic link เพื่ออัพเดทโค้ดผ่านการวาง DLL หนึ่งไฟล์ หรือ Class 1 ไฟล์เป็นอะไรที่โอ้โหเจ๋งมาก ผมคิดว่ามันเกิดในยุคที่คนยังส่งมอบซอฟต์แวร์ผ่าน Floppy disk จำนวนมากอยู่ แล้วคอนยเซปต์ Dynamic link ที่สามารถสับเปลี่ยน Class ได้ตลอด ไม่ต้องส่ง Floppy disk 40 แผ่นผ่าน EMS เพื่ออัพเดทซอฟต์แวร์หนึ่งชิ้นแล้ว โคตรเจ๋งเลย!!! ในยุคนั้นสิ่งนี้เป็นเรื่องสำคัญ ส่วนสมัยนี้เหรอ ทำ Patch ทั้ง App ผ่าน Internet ง่ายกว่าเยอะ ซึ่งบนข้อจำกัดนี้ ไม่แปลกใจที่ Inheritance เป็นคอนเซปต์ที่มีพลังมาก ผมจำได้ว่าผมอ่าน Polymorph ครั้งแรกช่วงที่ยังใช้ Floppy disk กันอยู่ เดาว่าคอนเซปต์มันเกิดช่วงนี้
- ส่วน Code reuse ผมว่ามันมาเกิดในช่วงอีกช่วงหนึ่ง แต่ยังไม่แน่ใจว่าตอนไหน ผมจำได้ว่ามีช่วงหนึ่งมันป็อปมากเรื่อง Code reuse via OOP เนี่ย จนบอกว่าทำ OOP เพื่อจะได้ทำ Code reuse ได้ ซึ่งก็ตลกดีตรงที่เท่าที่ผมอ่านเจอ เจ้าตัวคนคิดคนแรก ไม่ได้สนใจอะไรตรงนี้ขนาดนั้นนะ
- เวลาเราเข้าใจ OOP ถ้าเราเข้าใจว่าเรื่อง Separation of concern, State encapsulation มันเกิดคนละยุคกับช่วงที่เขาโปรโมตเรื่อง Code reuse, Inheritance, Polymorph เราจะเก็ตว่าทำไมพอพยายามใช้งานจริง บางทีคอนเซปต์มันขัดกันเองแปลกๆ บางทีพอพยายามจะ Encapsulate แล้ว Reuse ยากจังวุ้ย แล้วตรงข้าม พอพยายามจะ Reuse ให้ได้เยอะๆ ทำไมโดเมนบางทีมันผสมกันไปหมดเลยวุ้ย พอเรารู้แบบนี้ เราไม่ต้องไปหาทาง Justify ครับ แค่เข้าใจว่ามันเกิดคนละยุค Practice ที่เกิดมันเลยอาจจะไม่เป็นเนื้อเดียวกันหมด (แต่เราเรียนบนหัวข้อเดียวกันคือ Object-oriented programming ทำให้หลายคนเข้าใจว่าทุกอย่างเป็นเนื้อเดียว Well-thought มาทั้งหมดแล้วถูกออกแบบมาดีแล้วแค่ทำตามพอ ซึ่งผมว่าไม่ใช่) ตรงนี้มันเป็นช่องว่างที่เราต้องใส่ไอเดียของตัวเองเข้าไป
ที่ผมแซวเรื่อง Original OOP เยอะเพราะอยากให้เห็นว่า Object-oriented มันมีหลายมุมที่เกิดในหลายยุคนะ
พอเรารู้ว่ามันมีหลายยุคแล้วได้ประโยชน์ยังไง? ตัวผมเองใช้แบบนี้
- ผมมองว่าจังหวะที่เราเริ่มสเกลทีมแล้วแบ่ง Cross-functional การมองไปมองที่ Original OOP ที่เน้นเรื่อง Domain encapsulation เป็นอะไรเหมาะสมกับโจทย์กว่า
- Code reuse strategy อาจจะประยุกต์เอาคอนเซปต์ของ Functional programming เข้ามาใช้ได้ครับ ซึ่งผมสนใจการผสมผสานตรงนี้ เพราะผมไม่ชอบ Inheritance by default เวลาคิดอะไรไม่ออก ส่วน Reuse by composition ผมว่า Function composition มัน Concise และมี Expressive power มากกว่า Object composition ครับ
วันนี้เพิ่งไปทำความรู้จักกับ Redis มาเลยจะมาแนะนำให้ฟัง https://redis.io/ (บทเรียนแบบสนุกลองไปหน้านี้ http://try.redis.io/ ครึ่ง ชม. ก็จบแล้วครับ)
มันคือ service ที่รันบนคอมแล้วเหมือนเรามีตัวแปร Dictionary, HashSet, ... มหัศจรรย์ให้ใช้ที่สามารถรุมใช้จากหลายๆ client ผ่านเน็ตได้อย่างสวยงาม ซึ่งถึงตัวแปรที่ว่าจะอยู่บน memory ไม่ได้เซฟแต่ก็มีฟังก์ชั่น replay คำสั่งให้ถึงเครื่องพังพอเปิดมาใหม่ก็มีตัวแปรสภาพเดิมได้แบบนั้นก็มีครับ เลยเอามาใช้เป็น database กันก็ดูไม่เลวไม่แคร์ความ RAM กันเลย
ความ in memory ไม่ต้องเซฟทำให้ความเร็วสูงพอที่จะใช้ algorithm ที่ไม่ค่อย scalable ใน DB ปกติได้ เช่นการ count หรือ sort (ไม่ใช่ indexing) อัตโนมัติทุกครั้งที่เพิ่มข้อมูลใหม่เข้าไป ใครเคยใช้ Firebase Cloud Firestore / RDB จะรู้สึกว่ามันน่าจะทำ scoreboard ลำบากไม่ก็เปลืองเงินมาก ส่วนมากปัญหาจะอยู่แถวๆที่ว่าอยากรู้ว่าเรา rank เท่าไหร่หลังจากเพิ่งอัพเดทคะแนนไป ซึ่ง count ก็เปลือง ถ้าจะเซฟเลขเก็บไว้เดี๋ยวมีคนแซงก็เลขเลื่อนกันหมดอีก ถ้า Firestore อัพเดทเสียเงินเป็นหน่วย document แล้วน่าจะเจ็บหนักครับ ต้องดีไซน์แผนดีๆเพื่อให้เสียเงินน้อยลงแล้วทีนี้ structure ก็จะดูไม่สวยงามอีก (เช่นต้องมี document เดียวที่มี bake คะแนน top 100 กองอยู่ด้วยกัน แล้วปัญหาอื่นอาจจะตามมา เช่นต้องคอย sync ข้อมูลหน้า avatar ที่ฝังอยู่ในนั้น ฯลฯ)
แต่คงจะง่ายกว่าถ้าแค่ใช้ Redis มาช่วย (หรืออยากใช้แต่ Redis ไปเลยก็อาจจะได้ แต่ด้วยกันน่าจะประหยัดเงินสุด) ใน Redis นี้มีตัวแปรประเภท sorted set ที่เหมือนเกิดมาเพื่อทำตารางคะแนนเลยครับดังนั้นเราแค่ใส่ๆข้อมูลเข้าไปรัวๆแล้วถามเวลาอยากรู้ก็รู้อันดับได้เลย
อยากศึกษาว่าทำไม leaderboard ถึงเป็นปัญหายาก https://redislabs.com/redis-enterpr…/use-cases/leaderboards/
ถ้าอยากลองเล่นสามารถลอง Tier ฟรีของ Redis Labs ที่สปอนเซอร์คนทำ Redis อยู่ได้ สามารถเปิดคอมกับ AWS/GCP/Azure ได้สามที่ เปิดมาแล้วมี RAM ให้ 30MB ซึ่งดูเหมือนน้อยแต่สมมติถ้า record นึง 32 bytes (~ GUID + float) ก็เก็บได้ตั้งประมาณ 900,000 คะแนนแน่ะ ถ้า trim ไว้ให้ rank แค่ top 10000 อะไรงี้ก็คิดว่าเหลือเฟือได้หลายบอร์ดเลยครับ
ของฟรีไม่มี data persistence ให้ ถ้าคอมรีสตาร์ทแล้วของใน RAM จะหายหมดไม่มี replay แล้วก็ connection ได้ถึง 30
แต่ถ้าไม่ใช้เป็น DB แล้วใช้เป็นตัวแปรจริงๆก็น่าจะพอไหวครับ เช่น ใช้ Cloud Firestore ในการเก็บคะแนนของแต่ละคนเป็นส่วนตัวอันนี้แบบกลัวหาย แล้ว export ไป Redis ที่ไม่กลัวหายเพื่อให้เป็นคอมที่เปิดไว้ ranking หรืออื่นๆที่ต้องยุ่งกับผู้เล่นอื่นแบบ active หน่อยโดยเฉพาะ
คิดๆไว้ว่าอาจจะสร้าง record ไว้ใน Redis ประมาณว่า "exported" เวลาอพยพไปแล้ว + trim เสร็จแล้ว ทีนี้ถ้าคอมพัง ฝั่ง Firebase ก็จะได้ถาม Redis เจอว่าไม่มี record นั้นแล้วดังนั้นอพยพอีกรอบ ถ้าอพยพเสร็จแล้วทีนี้ทุกครั้งที่มีคะแนนใหม่ก็แค่แถมไปใส่ฝั่ง Redis ด้วยจะได้ถาม rank กลับมาได้
เท่าที่ดูคร่าวๆนอกจาก Sorted Set แล้วมีฟีเจอร์เท่นึงที่ชอบคือสามารถสร้าง record ที่นับเวลาถอยหลังแล้วหายไปเองเมื่อถึงเวลาได้ครับ (EXPIRE) ดูน่าจะเอาไปเล่นได้หลากหลายดี (เช่น ทำ ranking ที่จัดอันดับทุก ชม. แทนเพื่อให้ไม่ต้อง connect ไป Redis ทันทีที่ใครซักคนทำคะแนนได้ ทำ timed challenge ในเกม ฯลฯ)
"Don't underestimate the power of survival of the fittest. And don't ever make the mistake that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle. That's giving your intelligence much too much credit."
Linus Torvalds
GildedRose Kata นี่เป็นแบบฝึกหัดที่ดีมากเลยนะ
คือ Engineer จำนวนมากพยายามแก้ไขปัญหา Technical Debt ด้วยการที่บอกว่า "อย่าสร้างสิ เขียนให้ดีสิ" แต่ในโลกความเป็นจริงแล้วเรามีโค้ดที่เละยังงี้เต็มไปหมด บางทีเราก็สร้างเองเพราะงานเร่ง มันเป็นอะไรที่หลีกเลี่ยงไม่ได้เลย
คำถามคือเราจะทำยังไง เวลาเจอโค้ดยังงี้
ถ้าใครบอกว่าจะ Refactor นี่ก็เป็นโจทย์ที่ดีที่จะได้ฝึก
หรือแม้แต่ถ้าใครบอกว่าเจอ Tech debt เยอะๆ ฉันจะไม่แตะแล้ว จะ Rewrite แม่งอย่างเดียว คุณก็ลอง Rewrite GildedRose ขึ้นมาดู ก็เป็นแบบฝึกหัดที่ดีอีก
คุณจะได้เข้าใจว่าการ Rewrite ในทางปฏิบัติ ที่ Requirement ส่วนมากจะไม่ครบ มันต่างกับในอุดมคติเยอะ เอาแค่ Rewrite ระบบเล็กๆ อย่าง GildedRose นี่แหละให้รอดก่อน ค่อยไปลองขอ Rewrite ระบบใหญ่ๆ
(ผมต้องเน้นเสมอว่างาน Rewrite != งาน Green field ระดับความยากมันต่างกันแบบคนละเลเวลกันเลย Engineer หลายคนคิดว่าเวลาที่ได้ใบอนุญาตให้ Rewrite ระบบที่เละๆ ใหม่จากศูนย์ มันจะให้อารมณ์สวยงามเหมือนทำ Greenfield Project ซึ่ง ขอบอกเลยว่าโคตรจะไม่ใช่)
ผมคิดว่าการจัดการกับ Legacy code เป็นสกิลที่สำคัญมาก คือผมมองว่ามันมีเส้นแบ่งที่ใหญ่มากระหว่างคนที่เขียนโค้ดสวย กับเปลี่ยนโค้ดไม่สวยเป็นโค้ดสวยได้ (ไม่ว่าจะด้วยวิธีใดๆ) คือถ้าสมมติแบ่งเป็น 10 Grade ผมว่าคนที่ทำได้กับไม่ได้ฝีมือต่างกันอย่างน้อย 2 Level แน่ๆ
และ GildedRose เป็นแบบฝึกหัดที่คุณจะได้ลองจัดการกับ Legacy Code ของจริง ไม่ว่าคุณจะเลือกจัดการมันยังไง ค่อยๆ แก้ หรือเขียนโครงใหม่จากศูนย์ก็ตาม
Repo นี้มีให้เกือบทุกภาษาให้เล่น ใครสนใจลองเล่นดูได้ครับ
ใน Javascript, Typescript ผมชอบที่จะเขียน OOP ด้วย Higher-order function มากกว่า Class keyword
ผมพบว่าถ้าคุณรู้จักและใช้ Higher-order function (HOF) ตัวเดียว มันสามารถทำได้หมดเลยทั้ง Inheritance, Decorator, Annotation, Implements, Private, Public และอีกหลายๆ Keyword ที่ในหลายๆ ภาษา OOP คุณต้องเรียนทีละตัวว่าแต่ละตัวคืออะไร Inherit คืออะไร ทำงานยังไง Decorator คืออะไร ทำงานยังไง
ถ้าใช้ HOF คุณเรียนแค่ว่ามันคืออะไรตัวเดียวพอ แล้วแต่ละสิ่งข้างบน มันทำงาน Conceptually เหมือนกันหมด ส่วนในรายละเอียด อ่านโค้ดเองได้เลย ขอแค่เข้าใจ HOF
หรือแม้แต่สิ่งที่หลายๆ ภาษา OOP ไม่มีอย่าง Multiple Inheritance คุณก็ทำด้วย HOF ได้และสามารถบอกได้หมดว่าแต่ละ Conflict แก้ไขยังไง
เราเขียนโปรแกรมแบบ OOP Paradigm โดยไม่ต้องมีคำว่า "Class" ได้นะ เผื่อไม่รู้
แล้วส่วนตัว ผมคิดว่าโค้ด HOF สวยเพราะมี Language construct เดียวแต่ทำได้ทุกอย่างอย่าง Concise โค้ดก็ไม่ได้บวมด้วย และไม่ต้องจำอะไรเยอะแยะว่าไอ้นั่นคืออะไรไอ้นี่คืออะไรมากมาย ซึ่งอันนี้มักจะเป็นความเห็นที่ต่างกับหลายคนที่บอกว่าโค้ดที่ทำ HOF อ่านไม่รู้เรื่อง อ่านยาก พอมีคำว่า Class สวยกว่า
ปล. จริงๆ ผมเข้าใจได้นะว่าทำไมคำว่า Class สวยกว่าในแง่นึง และผมก็เลือกใช้กับหลายๆ ทีมที่เขา Familiar กับสิ่งนี้ไปแล้วเหมือนกัน มันก็ง่ายที่จะอ่านมากกว่ามาเรียนรู้ใหม่ล่ะ แต่ไม่อยากให้ปิดใจกับ HOF แล้วลองดูกัน
อยากตั้งคำถามให้วงการไอทีไทยอีกที นี่เป็นรอบที่เท่าไหร่ก็ไม่รู้แล้ว ทำไม Programmer ต้องโปรโมทไปเป็น SA แล้วไปเป็น PM/Mgr ทำไมเราไม่เห็น Growing Path ที่สนับสนุน Individual Contributors ในไทยนะ
ผมเห็น engineer อายุรุ่นราวคราวเดียวกัน (+/- 5 ปี) พอถึงอายุ 35 จะต้องเริ่มคิดว่าแล้วกูจะทำอะไรต่อดี เพราะอายุ 35 แล้วเนี่ยบริษัทไทยไม่ค่อยมี Path ให้ คุณต้องเลือกไป Management สักทาง ในขณะที่ใน ตปท เค้ามีโอกาสให้ Engineer โตจนเก๋าๆ อายุ 50 ปีเยอะแยะเลย
พอเราต้องแข่งกับระดับโลก เราก็ถามอยู่นั่นแหละ คนเก่งเราเยอะแยะ แล้วทำไมเราสู้เค้าไม่ได้ ก็เพราะคนเก่งเราเปลี่ยนจากเรื่องที่เค้าเก่งมาทำเรื่องที่เค้าเก่งน้อยกว่ากันหมด เพราะระบบและสังคมมันบังคับไง ด้วยความที่ไทยเราเป็นสังคมอำนาจนิยม ใครอายุ 3x ไม่ได้เป็น manager เราก็จะมองว่าเค้าไม่ประสบความสำเร็จแล้วล่ะ เราไม่ได้ให้คุณค่ากับ individual contributor มากพอ สุดท้ายถ้าเค้าไม่ยอมแพ้ให้กับระบบ เค้าก็จะพาตัวเองออกจากระบบไปเลย
อยากแข่งกับโลกต้องทำไง ดูจีนครับ เค้าให้ value กับ IC มาก มากพอๆกับ management แหละ #ช่วยตัวเองกันไปก่อนนะครับ
#มิตรสหายนักพัฒนาซอฟต์แวร์ท่านหนึ่ง
แอปเกมสนุกๆ เล่นได้ง่ายๆ ทำกำไรมากมายได้ตลอด 24 ชั่วโมงพิเศษสมัครใหม่วันนี้รับโบนัสทันที 50%
หากสนใจการทำเงินที่มีแต่ความสนุกสนานกดเลย!
https://www.ballinw.com/ดาวน์โหลด-live22/
ขอจดอัพเดทความรู้ Technical ที่เก็บได้เด็ดๆช่วงนี้หน่อย
1. การวาง Structure Code แบบ "Functional Core, Imperative Shell"
ไปเรียน Testable Web API กับพี่คริส (Taskworld, Omise) มา สะดุดกับ Concept นี้มากๆ เพราะส่วนตัวชอบความ Resilience ของ OO ในส่วนของ IO ต่างๆ แต่พอมาเป็น Business Logic เราใช้ต่อ บางทีมันรู้สึกขัดความรู้สึก ไม่ว่าจะ Test ยากเอย เขียนเสร็จชื่อ Object ไม่ค่อย Make Sense เอย มีความขี่ช้างจับตักแตนอยู่ พอมาฟังพี่คริส Demythify เรื่องนี้ Concept มันดู Eureka จริงๆ
2. ด้วยเหตุข้อ 1 Typescript มันดูหล๊อหล่อขึ้นมาทันที ด้วยความที่มันลดความบ้านป่าเมืองเถื่อนของ Javascript ในจุดที่เราต้องการได้
3. ขึ้น Project ใหม่ ยุคนี้ หาข้ออ้างไม่ทำ CI/CD ยากละน้า นั่งลองเล่น Cloudbuild ต่อเข้า Github แล้ว Deploy ลง App/Kubenetes Engine กดๆแปปเดียวเสร็จ เข้าใจง่าย Integration Test ก็ทำไว้ใน Cloudbuild ได้หมด และ Infra as a code มันชีวิตง่ายขึ้นจริงระบุ Instance เอาขึ้น เอาลง Scale ไป Size เท่าไร ชีวิต Dev Happy
4. เช่นเดียวกันทำ Web / App ให้ Scalable ก็มาในยุคที่ Cost ถูกลงมาก (ทั้ง Cost Infra / Operation) เครื่องไม้เครื่องมือพวก Queue, Message พวกนี้ Cloud Provider มีให้ใช้ง่ายๆทุกเจ้าแล้ว
5. Concept ของพวก Distribution System อย่าง At least/Exactly Once semantic,Idempotent, Redundancy หรือกระทั่งการทำ Event Storming อันนี้น่าศึกษาไว้ Even กับ Role อย่าง Product Owner / Manager ก็ตาม
ตอบในฐานะ SA นะครับ เรื่อง Set สำคัญกับการออกแบบระบบมาก เพราะปัจจุบันการเขียน Software จะให้ความสำคัญกับ Bussiness Rule มากกว่าการ Modeling ถ้าคุณอยากเขียนซอฟแวร์ในระดับลึกมันไม่ใช่การใช้ Api ชาวบ้านอีกต่อไป มันคือการสร้าง Architect ครับ
.
Set มีบทบาทยังไง การที่จะเขียนโปรแกรมให้ตอบโจทย์ Bussiness เราจะต้องมี Context กับ Operation ให้เหมาะสม ดังนั้นการเขียนโปรแกรมที่ Generic มาก ๆ ที่ชอบทำกันเนี่ย มันไม่ใช่ผลดีกับระบบ เราต้องแบ่ง Context ของระบบให้แก้ปัญหา Bussiness ให้ได้
.
แล้วอะไรจะใช้คำนวณว่าเราออกแบบ Class ได้ตรงความต้องการของระบบไหม คำตอบคือ Set ครับ
.
เช่น
A { x | ILoginService }
หมายความว่า เราสนใจ Elements ของ ILoginService
.
ทีนี้เรา Specific ได้แล้วว่าอะไรคือ Service ที่กำลังพัฒนา ต่อมาที่เราต้องเช็คคือสิ่งที่อยู่ใน Set มีความสำพันธ์กันอย่างไร
.
สมมติ A { LineLogin, FacebookLogin }
สมมติมี Service อยู่สองตัว ทีนี้เราหาความสำพันธ์ของมัน
.
ถ้ามันเป็น Isolation เคสเพราะนี้เป็น A+B ก็คือ
ต่อมาเราก็สนใจที่ตัว Elements ของ set ค่อยๆ ไล่ไปทีละตัว
.
การออกแบบ Class เราต้องนึกถึง 1. Relationship, 2. Multiplication, 3. Communication
.
ทีนี้เราสนใจลึกลงไปอีก step
เช่นผมสนใจ A { x | FacebookLogin }
.
ทีนี้ Set ของเราจะเป็น Aggregation ของ FacebookLogin
.
ดังนี้ FacebookLogin { TokenValidator, SendValidRequestEvents } ( ของจริงเยอะกว่านี้ นี่แค่ยกตัวอย่างมา 2 อัน )
.
ทีนี้ความสัมพันธ์มันเป็น AB คือ Existence Dependency ถ้าตัวไหนพังก็พังทั้ง Service
.
Event ของสองตัวนี้เป็นแบบ Sequence คือต่อกัน
คือ Validate input แล้วค่อยส่งไป Server
ทีนี้เราก็มาวิเคราะห์ว่าจะใช้ Pattern ไหนในที่นี้ใช้ Middleware Pattern เพราะ Flow input เป็นแบบ Sequence
.
เราก็ไล่ออกแบบไปเรื่อยๆ ตามนี้ ซึ่งความยากคือ Entity ของระบบมันมี Invariant ต่างกัน Aggregate ต่างกัน Concurrency ก็ต่างกันอีก
.
ในโลก Software คือความยากมันไม่ใช่แค่คณิตศาสตร์ มันคือ Concept มหาศาล หลากหลาย Principal แต่ที่ผมจะบอกคือเรื่อง Set เนี่ยมันทำให้เรามองเห็น Domain ที่กำลังจัดการอยู่ให้ชัดขึ้น ทีนี้เราจะมอง Dependency ออก มอง Communication ออก ที่เหลือก็ไปว่ากันที่ Pattern กับ Persistence
.
ถ้าคุณแยก Domain ไม่ออก อย่าพูดถึง Design Pattern เลย ปนกันมั่วแน่นอน
ไอ้สูตร Set ที่คุณเรียนกันตอนม. ปลายนี่แหล่ะ เคสที่มันได้ใช้
.
Cohesion กับ Coupling ก็ Set
ถ้าระบุ Set ไม่ได้ Object มันก็คุยมั่วไปหมด หา Boundary ไม่เจอ
.
จริงๆ ยังมีมากกว่านี้อีก ผมยกตัวอย่างแค่ Service เดียวเอง เผื่อพอเป็นไอเดียว่าคณิตศาสตร์มันไม่ใช่แค่ผูกกับการแก้สมการอย่างเดียวมันมีมุมมองอื่น ๆ ด้วย
.
Code ที่แก้สมการในระบบมันคือ Behavior ของ Class กับของ Service ที่เราสนใจแค่นั้นเอง ว่าจะแก้ยังไง ไม่ใช่แค่หน้าที่ของ Dev แต่หมายถึงการสื่อสารระหว่าง Dev กับ Domain Expert ในด้านนั้น ๆ เพื่อร่วมกันแก้ปัญหา
.
สุดท้ายกับคำถามที่ว่า “เป็นโปรแกรมเมอร์ใช้คณิตศาสตร์กี่ %”
1. Empirical Expression
2. Numerical Expression
นี่แหล่ะสองสิ่งที่คุณจะใช้
ปริญญาโทด้านคอมพิวเตอร์มันจำเป็นมากป่าววะ หรือไปหางานทำดี
ปรึกษาหน่อยค่ะ
หนึ่งในเรื่องสำคัญที่หลายต่อหลายคนมองข้าม ก็คือ "พิมพ์ดีด"
ต้องฝึกให้คล่องนะ อย่างน้อยๆ นี่ 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 โดยตรงแล้ว
ส่วนตัวเราคิดว่าอีก 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ๆ
สองสัปดาห์ที่ผ่านมาประชุมเยอะขึ้นมากๆ แต่รู้สึกว่าได้ทำงานเป็นชิ้นเป็นอันจากการประชุม ไม่ได้รู้สึกว่ามัวแต่ประชุมไม่ได้งาน
ทำให้เข้าใจอย่างนึง เวลาประชุมแล้วไม่มีประสิทธิภาพมันไม่ได้เกิดจาก 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
พวก great dying ส่วนมากมันจพมาแบบสุ่ม
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 ของข้อมูลอาจจะทำยากหรือไม่ได้เลย
เวลาขอดูงานจะเริ่มที่ความคิดในเชิงสถาปัตยกรรมระบบเขาก่อน ถ้าเขาวางดีแสดงว่าทำเป็น ส่วนอื่นมักจะพอไปได้
𝐏𝐬𝟏 หลายๆอาชีพ มีมามีไป มีหายไป มีเกิดใหม่ ผมอยากให้เน้นความรู้พื้นฐานเอาไว้ให้แน่น เพราะจะทำให้เราเขยิบสาขา หรือเข้าสาขาใหม่ได้ง่าย ไม่โดนเท วิชาเหล่านี้คือหัวใจหลักที่ช่วยผมในทุกสายงานที่เข้าไป Engineer Mathematic, Algorithms 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 ครั้งเอง แต่คิดว่าถ้าได้เข้าออฟฟิศคงได้เรียนรู้อะไรมากกว่านี้อีก
.
รออย่างใจจดใจจ่อ ไว้เจอกันน้าออฟฟิศคุงงง =)
มันลำบาก บ้าเนราอยากได้คนเก่งแต่ไม่มีงานดีๆให้คนเก่งมันทำ
หลายคนที่เขียนบทความ หรือพูดทำนองว่า เขียนโปรแกรมไม่ยาก เขียนไม่กี่บรรทัด ง่ายๆ ก็ทำเงินได้สารพัดแล้ว ว่าไม่จะเป็นตั้งบริษัทมูลค่าหลายล้าน ไปถึงได้งานประจำเงินเดือนหลายหมื่น ....
พวกนี้ไปดูดีๆๅ นี่ หลายคน ขายคอร์สเขียนโปรแกรม คอร์สเขียนโค้ด .... เอาเงินหรือ “ความรวย” มาล่อให้คนไปเรียน
พูดถึงคนที่หลงไปเรียนกับพวกนี้ ... แล้วก็นึกถึงน้องคนหนึ่งที่เคยมาสมัครทำงานกับผม ...
เคยมีน้องคนหนึ่ง ไปเรียนกับพวกนี้ .... มาสมัครงาน ขอเงินเดือน 70,000 ... ตามคำโฆษณาเชิญชวน ....
น้องเล่าว่า น้องถูกชมจากคนสอนมากมาย ว่าเก่งมาก
ตามธรรมเนียมของการสมัครงาน ก็ให้ลองเขียนโปรแกรมเล็กๆ ดูขำๆ .... น้องก็เขียน Java ตามที่เรียนมาจากที่นั่น .... แต่น้องเขียนทุก Method เป็น Static หมดเลย (น้องเขียนแบบอื่นไม่เป็นเลย) ...
เท่าที่ผมดูจากเอกสารที่น้องเรียน ... คือที่เขาสอนมา ก็สอนแบบ C แล้วเขียนคลาสครอบ Procedures ทั้งหลาย .... มันก็เลยต้องเป็น Static ไม่งั้นใช้ไม่ได้ (อันนี้ผมดูเองจากเอกสาร น้องไม่ได้อธิบายแบบนี้)
ไม่ต้องพูดถึง algorithm หรือพวก abstraction design ต่างๆ นะ เอาแค่เรื่อง technical ของการใช้ภาษาโปรแกรมแบบพื้นฐานล้วนๆ ก็ไม่ผ่านแล้ว
น้องคิดว่า เป็นงานไม่ยาก วันๆ นั่งเปิดนั่งลอก Stackoverflow ให้มันทำงานได้ก็พอแล้ว เขียนยังไงก็ได้ ความเข้าใจอะไรไม่ต้องมีมาก นอกจากให้มันทำงานได้พอ .... และก็ได้เงินเดือนเยอะๆ
บางที ก็จะเจอ 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 เป็นเรื่องที่ต้องฝึกนะ คนเราถูกฝึกให้หมดหวังได้ ก็ถูกฝึกให้มีความหวังได้เช่นกัน ผมเชื่อแบบนั้น เริ่มจากสำรวจตัวเองบ่อยๆ ครับว่าเราหวังอะไร แล้วอยู่กับมัน อย่าตีตัวเองเร็วไปว่าฝันเฟื่องไร้สาระ
ไอ้ที่บอกว่ามี ai ตามตรวจเทรดคริปโตได้นี่จริงหรือโม้วะ
เมื่อวานสอน 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
ผมเปิดบริษัทเอง ผมสามารถมีเงินเดือนน้อยกว่าลูกน้องได้โดยไม่ต้องคิดมากเลย สุดท้ายแล้วเงินบริษัทก็เงินผมเองแหละที่ได้มา และมีมากพอที่จะมาจ่ายลูกน้อง 😎
เรื่องแบบนี้ผมมองว่าเราไม่เคยเอามาซื้อใจคนครับ ธุรกิจก็คือธุรกิจครับ ถ้าเอามาปนกับบรรทัดฐานทางสังคมเมื่อไหร่ เราจะไม่สามารถกลับมาคุยฉันมิตรกันได้อีกเลย
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 ที่ไม่มีโฆษณานั่นแหละ"
python อนาคตยังไปได้สวยไหม
เรื่องสตรีมมิ่งล่มนี่ ต้องบอกว่ามีบริษัทมิตรสหายท่านหนึ่งที่เคยเจอโหลดระดับครั้งยิ่งใหญ่ของไทยแล้วไม่เคยล่มเลย
ในวงการ media รู้จักกันดีอยู่แล้วเพราะรับทำงานให้หลายเจ้า แต่เราเก็บชื่อไว้เป็นบริษัทลับจะได้ดูเท่ๆ เหมือนพวกร้านลับ คาเฟ่ลับบ้าง
ทำไม Startup ถึงล้มกันเยอะ ทั้งๆ ที่มีระดมทุนไปตั้งเยอะ ก็ยังไม่รอด
ความเห็นส่วนตัวค่ะ อาจจะเป็นเพราะว่า ได้เงินมาเยอะ ก็เลยขาดการระวังในการใช้เงิน ก็เป็นได้นะคะ
สำหรับ Coraline เราไม่ได้เปิดระดมทุนค่ะ ตั้งแต่สร้างองค์กรขึ้นมา แนวคิดของแป้ง คือ แป้งสร้างองค์กร เพื่อหาลูกค้า ไม่ใช่หา Funding เพราะแป้งต้องการให้บริษัทอยู่ได้ด้วยผลงาน ไม่ใช่ด้วยการระดมทุน (หรือ Money Game)
ถามว่า มีนักลงทุนมาลงทุนมั้ย >>> มีค่ะ แต่เป็นการพูดคุยที่ลงตัว และมีหลายครั้งที่มีองค์กรต่าง ๆ ติดต่อมาพูดคุย แต่ไม่ลงตัว จะเงินก้อนโตแค่ไหน แต่มุมมองที่มีต่อการเติบโตไม่เหมือนกัน ก็ไม่สามารถรับเงินทุนมาได้จริง ๆ
เมื่อเป็นเช่นนั้น การบริหาร Cash Flow จึงสำคัญมาก เพราะเราไม่ได้มีเงินถุง เงินถังที่จะ Burn ได้อย่างฟุ่มเฟือย
เราทั้งรัดเข็มขัด ตัดสิ่งที่ไม่จำเป็นออก และพยายามหาลูกค้า เพื่อให้บริษัทอยู่รอด มาตั้งแต่ตอนต้น
นั้นเป็นเหตุผลที่ว่า ทำไมเราถึงเติบโตได้อย่างต่อเนื่อง เพราะเราค่อนข้าง "ผิดให้น้อย"
แป้งไม่ได้ต้องการเป็น Unicorn เพราะไม่รู้สึกว่าจะต้องขอระดมทุนเยอะๆ ถ้าเราอยู่ได้ด้วยตัวเอง ก็ไม่รู้จะระดมทุนทำไม
แต่แป้งต้องการเติบโต และจะต้องโตไปเรื่อย ๆ มีการขยาย Scope งานที่รับได้ บริการใหม่ ๆ ทุกปี จนพูดได้ว่าเราเป็นบริษัทเทคโนโลยีที่ตอบโจทย์ได้ครบจริง ๆ
มีนักลงทุนติดต่อเข้ามาเยอะ ว่าจะเปิดให้ระดมทุนมั้ย??? อาจจะเปิดค่ะ ตอนนี้ยังตอบไม่ได้ ซึ่งการจะเปิดระดมทุนของแป้ง คือ กรณีที่ต้องการเปิดตลาดใน Product ที่เราพร้อมจะเปิดตัว และต้องการ Support ในการเปิดตลาดเท่านั้น แต่ถ้าอะไรยังไม่ชัดเจน แป้งจะไม่ระดมทุนมาเพื่อเสี่ยงแน่นอน เพราะแป้งให้ความสำคัญกับทุกบาทของนักลงทุนมาก ๆ
ลงทุนกับแป้ง คุณจะต้องได้คืน ถ้าบริษัทคืนไม่ได้ แป้งก็จะหามาคืนให้ได้ด้วยตัวแป้งเอง
ในแต่ละปี Coraline มีการเปลี่ยนแปลงใหม่ๆ ทั้ง Culture ใหม่ ที่เปลี่ยนแปลงตลอด ทั้งบริการใหม่ๆ ทั้งองค์ความรู้ และแนวทางใหม่ ๆ บางครั้งปีนี้คุยกันอาจจะยังไม่ใช่ ปีต่อไปมาคุยใหม่ อาจจะใช่ก็ได้ ทั้งในมุมการลงทุน การเป็นลูกค้า และการสมัครงาน
แต่แน่นอนว่า ทุกอย่างมีรากฐานมาจาก Data และต่อยอดจากประสบการณ์เดิม
Direction ของแป้ง คือ ปรับตัวให้เร็ว เพราะเราจะต้องเป็น No.1 ให้ได้ ไม่วันใด ก็วันหนึ่งค่ะ
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 จะไม่อัพเลยอยากเปลี่ยนงาน ทีนี้ถ้าเพิ่งทำงานได้ไม่ถึงปีแถมจบใหม่อีก แบบนี้ประวัติจะไม่ดีไหมพี่โม่ง รึควรทำต่อไปซักปีนึงก่อนดี
เมื่อวาน มีคนหนึ่ง ทำให้รู้สึกว่า คลาสที่จัดมาทั้งหมด ไม่มีค่า ไม่มีความหมาย “ถ้าเราไม่แก้ปัญหาเชิงโครงสร้างของระบบการศึกษา”
“เรา” ที่ว่านี่ใครก็ไม่รู้ด้วยนะ
นั่นคือหนึ่งในสองตัวอย่างที่พูดในโพสท์ อีกเรื่องก็คือการดูแลระบบ ที่มันต้องแก้ปัญหาเฉพาะหน้า เวลามันจะล่ม และแก้ปัญหาระยะยาวด้วยการค่อยๆ ปรับโครงสร้างที่มันไม่เหมาะกับการใช้งาน (อันเกิดจากหลายสาเหตุ)
พวกนี้ก็ไม่มีประโยชน์อีกเช่นกัน …. เรียกว่าถ้าการแก้ปัญหาเฉพาะหน้า มันเป็นเฉพาะหน้าจริงๆ (เช่น อัด RAM) ก็อย่าไปทำมันเลย ปล่อยมันล่มไป …. etc
พอบอกว่าใครทำอะไรได้ก็ทำไป ถ้ามันไม่ทำให้อะไรแย่ลงกว่าเดิม ก็โดนสวนกลับมาอีก ว่ามันไม่ง่ายขนาดนั้น มัน ฯลฯ
คือเขาคิดว่าผมพูดเรื่องโตโน่ แต่พูดอ้อมๆ ด้วยการยกตัวอย่างตัวเอง พอผมบอกไปว่าไม่ใช่ ก็โดนสวนกลับ ว่า “ประเด็นที่เขาพูดก็ยังถูกต้อง ไม่เกี่ยวกับเรื่องนั้น”
วันนี้ก็ยังรู้สึกแย่ๆ อยู่ …. สงสัยที่ทำมานี่มันไร้ประโยชน์จริงๆ …. มีความรู้สึกโผล่มาแว๊บๆ ว่าปีหน้าอาจจะพิจารณางดจัดคลาส …. (อารมณ์ depress ชั่ววูปแหละครับ น่าจะ นะ …)
แต่ Block ไปล่ะ
โพสท์นี้จะลบตัวเองนะ อีกสักแป๊บ
บักลิ่วจะโชว์ความร่าน สุดท้ายโดนถอนหงอก ในบล็อกที่ตัวเองสร้างขึ้น 555
ครบปีแล้ว ผมขอเอาของขวัญปีใหม่จากปีที่แล้วมารีโพสต์อีกรอบครับ
ผมเองก็อ่านโพสต์นี้ซ้ำบ่อย ไม่ว่าจะผ่านไปกี่ปี คำถามสามข้อนี้ช่วยให้ผมจัดลำดับความสำคัญในชีวิตได้ดีขึ้น
----
.
ผมสังเกตเห็นว่าโปรแกรมเมอร์มักจะมี 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 บริษัทกันเล้ยเว้ยยยยย…โอ้ววว… ทำไมเดียวนี้ มันกล้ารับซ้อนกันขนาดนี้เลยเหรอ…
ลองไปเช็กทีมงานของคุณให้ดีนะครับ …
ไม่เคยอ่านหนังสือเล่มนี้แบบจริง ๆ จัง ๆ มาก่อนหน้านี้ แต่เทอมนี้ ต้องใช้เล่มนี้สอนคนในอุตสาหกรรม เลยต้องอ่านแบบจริงจังทุกหน้า ทุกบรรทัด บอกได้เลยครับว่า #อ่านแล้ววางไม่ลง เพราะเขียนได้ดีมาก สอนกระบวนการคิดได้เป็นอย่างดี รู้เลยว่าผู้แต่งใช้ประสบการณ์จากการทำวิจัยมาสอนกระบวนการคิดวิเคราะห์แก้ปัญหา โยงให้เห็นความสำคัญและประโยชน์ของการพิสูจน์ทางคณิตศาสตร์ทุกขั้นตอน ไม่เหมือนตำราคณิตศาสตร์ทั่วไป ในความคิดของผม เล่มนี้จึงเหมาะกับคนที่ทำงานแก้ปัญหาจริงในอุตสาหกรรม และเหมาะกับคนที่สนใจจะทำงานวิจัยในระดับสูงขึ้นไปครับ
ที่สำคัญ ไม่ต้องเสียเงินซื้อแม้แต่บาทเดียว
“การเรียนด้านปัญญาประดิษฐ์หรือ 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 ช่วยงาน และความละเอียดรอบคอบในการตรวจสอบ ตรวจงาน ในทุกรายละเอียด .... มากกว่าวันนี้เสียอีก ......
ฐานะคนจ้าง ตั้งแต่เปิด บ มาคนที่เรียน 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
320 คลิกแล้วติดไวรัส
>>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ด้วย กูรู้กฏหมายละกูเจ๋งแน่นอน
ขออภัยที่ใช้กูมึง 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 เหมือนกัน
น้องๆว้าวกัน เลยให้วิชาน้องๆเข้าใจธรรมชาติของฐานข้อมูลไปว่ามันเก่งทำงานแบบไหนถึงจะเร็ว ได้วิชาติดตัวกันไป
ให้โจทย์ต่อ
ออกแบบฐานข้อมูลสำหรับโอนเงินข้ามธนาคารมีคิดค่าธรรมเนียม
นั่งถกกันใหญ่
วันนี้ก็เป็นอีก 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
กุเห็นคนขายคอร์ส ราคา 4-5000
เนื้อหาแม่งหาได้ตาม youtube ตามเน็ตเยอะแยะ
คอร์สพวกนี้มันเหมาะกับคนที่ไม่มีพื้นฐานเหรอวะ
ตอนเด็กๆเคยเรียนคอร์สกราฟฟิกกับนักวาดมีชื่อท่านนึง เค้าก็บอกว่าเป็นอาจารย์ของนักวาดดังหลายคนในไทย เราก็ลงเรียนเผื่อหวังได้ฝีมือ ออกตังค์ค่าเมาส์ปากกาตัวแพงวาคอมให้เค้า เค้าบอกจำเป็นต้องซื้อให้เค้าด้วย เสียชั่วโมงนึงหลายพัน เราก็ยอม สุดท้ายได้แค่เบสิคนิดๆหน่อยๆ แถมตอนนั้นทางโรงเรียนมีงานกีฬาสี เค้าออกตัวขอรับงานออกแบบเสื้อให้ ได้เสื้อแบบก๊อปๆมาจากเน็ตแต่เรียกค่าออกแบบหลักหมื่น เสียใจมากตอนนั้นเรายังเด็กไง ไม่นานหลังจากนั้นมีดราม่าเรื่องเค้าขายงานโดจินที่หน้าปกก๊อปมาอีกที มีดราม่าลงไปทั่วเน็ต ทั้งเวบดราม่าจ่า หรือเวบพันทิป
พวกขายคอร์สมันก็อาศัยคนที่ไม่เข้าใจแบบนี้แหละหากิน
"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 ก็ได้”
ไม่ชอบเลยเวลามีคนบอกว่าภาษาโปรแกรมกับการเขียนโค้ดไม่สำคัญแล้วในยุคนี้ เราเคยตั้งคำถามกับความเชื่อของคนสร้างภาษากันบ้างมั้ย ทำไมต้องมีหลายภาษา
ลองนึกถึงคนที่มีเลนส์เดียวในการมองโลก คนที่ใช้ศิลปะมองทุกอย่าง ใช้คณิตศาสตร์มองทุกอย่าง ใช้การเมืองมองทุกอย่าง เวลาที่ 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
#มิตรสหายนักพัฒนาซอฟต์แวร์ท่านหนึ่ง
หลังจากไม่ได้ตาม 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 ความห่วยในการใช้งานของคุณอ่ะครับ
วันก่อนคุยกับเพื่อนคนหนึ่ง เรื่องธุรกิจแบบ 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 กลับมาในลักษณะ คนนั้นจะลำบากแบบนี้ คนนี้จะลำบากแบบนั้น โอ๊ย ตอนนี้ยิ่งมีอันนี้น้อยๆ อยู่ ตอนนี้ยิ่งทำแบบนั้นลำบากอยู่
ก็จะให้ทำยังไงนะครับ ......
ผมบอกแบบเดียวกันได้ไหมนะ ว่าถ้าคุณจะเอามากกว่านั้น ใครต้องลำบากอะไรเพิ่มขึ้นบ้าง หรืออะไรมันจะเกิดขึ้นบ้าง
ผมบอกแบบเดียวกันได้ไหมนะครับ ว่าถ้าเอาแบบนั้นแบบนี้ ผมจะลำบากอะไรยังไงบ้าง
ไม่ได้หรอกมั้งครับ
อยากแก้ปัญหาด้วยกันไหมนะ ..... หรืออยากจะบ่นกับทุกทางออกที่เป็นไปได้ .....
รู้สึกเหนื่อยๆ และรู้สึกแย่ๆ
โพสท์นี้จะลบตัวเองเร็วๆ นี้
Be Civil — "Be curious, not judgemental"
All contents are responsibility of its posters.