Fanboi Channel

"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