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

เป็นเรื่องของบริษัทที่ใหญ่กว่า Toss~

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

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

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

ความเห็นใน Hacker News น่ากลัวจัง... "สิบล้านรายการ? ล้อเล่นหรือเปล่า?"

แม้จะบอกว่าไม่ใช่เช็กลิสต์ แต่คงต้องเอามาเป็นเช็กลิสต์ของผมเองแล้วล่ะ

เป็นการทดลองที่น่าสนใจมาก

ช่วงนี้ผมก็สงสัยอยู่เหมือนกันว่าทำไม Gemini ถึงมีความเร็ว time to first token ที่ทิ้งห่างแบบเห็นได้ชัด ที่แท้ก็มีเหตุผลแบบนี้นี่เอง...

เห็นด้วยอย่างมากว่าควรอ่านเอกสารอย่างเป็นทางการให้แน่ใจ

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

แม้จะไม่ใช่ทั้งหมด แต่ส่วนใหญ่ก็เป็นประเด็นที่ชวนให้เห็นด้วยนะครับ

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

Hyperlight - ตัวจัดการเครื่องเสมือนน้ำหนักเบา (VMM) | GeekNews

Hyperlight WASM: รวดเร็ว ปลอดภัย และไม่ต้องพึ่งพา OS | GeekNews

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

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

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

สุขสันต์วันเกิดนะ เชื่อฟังคุณลุงแล้วก็ขอให้สุขภาพแข็งแรงไปนานๆ

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

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

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