Fanboi Channel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#my2cents

abcdefg

ccccccc

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

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

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

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

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

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

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

ดันมู้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>352 cringe

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

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

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

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

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

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

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

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