ต้องอ่านหนังสืออย่างน้อยหนึ่งเล่มถึงจะขึ้น Ride ได้
(ludic.mataroa.blog)- แม้ในที่ทำงานจะได้รับการยอมรับว่าเป็นวิศวกรระดับหัวแถว แต่เมื่อเทียบกับตัวจริงระดับสูง ความห่างอาจกว้างมาก และความต่างนั้นมักปรากฏจาก ปริมาณการเรียนรู้อย่างถูกวิธี
- ประสบการณ์ที่เลิกวาดรูปหลังมัธยม แสดงให้เห็นว่า หนังสือเพียงเล่มเดียวอย่าง Drawing On The Right Side Of The Brain กับการฝึกไม่กี่ชั่วโมง ก็ช่วยลดกำแพงได้ หากมี แหล่งเรียนรู้ที่เหมาะสม
- ในงานวิศวกรรมเอง ความต่างระหว่างคนที่อ่านเรื่องใดเรื่องหนึ่ง อย่างน้อยหนึ่งเล่ม กับคนที่แทบไม่เคยลองเลยนั้นใหญ่กว่ามาก และในหลายอาชีพ คนกลุ่มหลังกลับเป็นคนส่วนใหญ่
- ความเชี่ยวชาญแตกชั้นเป็นระดับ ๆ เหมือนกีฬาฟันดาบ ตั้งแต่ระดับท้องถิ่น ระดับประเทศ ไปจนถึงโอลิมปิก และคนที่อ่านหลายเล่มแล้วขุดลึกลงไป จะเข้าใกล้ การแข่งขันชิงงานระดับท็อป
- แค่อ่านหนังสืออย่างเดียวไม่พอ หากไม่มี เมตาสกิล ในการเลือกแหล่งเรียนรู้ที่ดีและคัดทิ้งส่วนที่แย่ ต่อให้ยึดติดกับ Scrum·Agile·เอกสารภาวะผู้นำ ก็ยากจะสร้างผลงานได้
จุดเริ่มต้นแบบ “อยู่ระดับบน แต่ก็ยังไม่พอ”
- ผู้เขียนได้รับการยอมรับมาอย่างต่อเนื่องว่าเป็น วิศวกรที่ดี ในสภาพแวดล้อมการทำงาน
- บอกว่าตัวเองศึกษามากกว่าวิศวกรรอบตัวโดยเฉลี่ยได้ถึงระดับหลายเท่าตัวเลขสองหลัก
- เคยได้รับข้อเสนอระดับ senior จากหนึ่งในบริษัทที่ถือว่าดีที่สุดแห่งหนึ่งในรัฐ
- คนประเภท “Serious People” อยากจ้างกลับอีก และจะโกรธกับ commit message ที่ขี้เกียจเขียน
- แต่เมื่อเทียบกับคนจำนวนมากที่ส่งอีเมลมาหา ผู้เขียนมองว่าตัวเอง ยังขาดอยู่ชัดเจน
- มีประสบการณ์ 3–4 ปี และพื้นฐานเดิมคือจิตวิทยา
- แทบไม่เคยเขียนเทสต์นอกจากในโปรเจกต์ส่วนตัว และนายจ้างที่เคยเจอก็ไม่มีทั้งเทสต์ที่ใช้งานได้หรือความตั้งใจจะนำเทสต์มาใช้
- โค้ดวิทยานิพนธ์ปริญญาโทเขียนโดยไม่มี version control และอธิบายว่ามหาวิทยาลัยชั้นนำในประเทศแห่งหนึ่งไม่ได้สอน version control
- ผู้เขียนคลี่ความย้อนแย้งนี้ผ่านตัวอย่างจากศิลปะ วิศวกรรม และกีฬา เพื่อเน้นช่องว่างระหว่าง “คนที่เรียนมาอย่างถูกต้องนิดหน่อย” กับ “คนที่แทบไม่เคยพยายามเลย”
พลังของ “หนังสือที่ใช่เพียงหนึ่งเล่ม” ในงานศิลปะ
- ตอนมัธยม ผู้เขียนเกลียดศิลปะที่สุด และหลังตัดสินว่าตัวเอง ไม่ได้เป็นคนสาย artsy ก็แทบไม่ได้วาดอะไรเลยเกือบ 10 ปี นอกจากลูกบาศก์แบบขีดเล่น
- ในปี 2022 ลองเรียนคอร์ส Drawabox แต่รู้สึกว่าน่าเบื่อมากและไม่เห็นความก้าวหน้า
- ต่อมาจึงเจอหนังสือ Drawing On The Right Side Of The Brain ของ Betty Edwards จากคำแนะนำบน Hacker News
- ชื่อหนังสือทำให้ผู้เขียนที่เลิกสายจิตวิทยาไปแล้วรู้สึกไม่สบายใจ แต่มีทั้งคำแนะนำและ ตัวอย่าง before/after
- ภาพ after ดูเหนือจริงเกินไปจนรู้สึกเหมือนโฆษณาหลอกลดน้ำหนัก
- แบบฝึกหัดแรกในหนังสือคือให้วาดมือตัวเองให้ดีที่สุด และผู้เขียนใช้เวลาวาด 30–45 นาที
- ตามมาตรฐานตอนนั้น มันคือภาพที่ดีที่สุดในชีวิต แต่ก็ยังมองว่ายังไม่ดีพอ
- หลังจากนั้นก็ทำแบบฝึกหัดประเภทตามเส้นของภาพกลับหัวด้วยสายตา และวาดเพิ่มอีกสองสามภาพ จนประหลาดใจกับผลลัพธ์
- เมื่อกลับมาวาดมืออีกครั้ง หลัง อ่านและฝึกเพียงราว 6 ชั่วโมง ผลก็ดีขึ้นอย่างชัดเจนจากเดิม
- ประสบการณ์นี้กลายเป็นตัวอย่างว่า ผู้เขียนเกือบพลาดความสุขจากศิลปะไปทั้งชีวิต แต่พอหยิบ หนังสือที่ใช่ ก็ข้ามกำแพงนั้นได้
“กำแพงหนังสือหนึ่งเล่ม” และการกระจายตัวของวิศวกร
- ผู้เขียนมองว่าวิศวกรแบ่งได้คร่าว ๆ เป็นสองกลุ่ม
- วิศวกรที่อ่านเรื่องใดเรื่องหนึ่ง อย่างน้อย 1 เล่ม มักดูมีความสามารถมาก
- ไม่จำเป็นต้องเป็นหนังสือตามตัวอักษรเสมอไป เพราะบล็อกเทคนิคหรือคอร์สสอนที่มีปริมาณมากพอก็อาจทำหน้าที่คล้ายกันได้ แม้ประสิทธิภาพจะต่างกัน
- อีกฝั่งคือวิศวกรที่แทบไม่เคยพยายามเลยตลอดอาชีพ และคนในอาชีพอื่น ๆ ซึ่งผู้เขียนมองว่านี่คือคนส่วนใหญ่
- วิศวกรมือเก๋า Seth Newman บรรยายมืออาชีพโดยเฉลี่ยว่าใกล้เคียงกับ “คนที่ละเมอเดินผ่านชีวิตการทำงาน”
- คือมีการเคลื่อนไหวอยู่ แต่ขาดการรับรู้มากพอจะหลีกเลี่ยงไม่ให้กลิ้งตกบันได
- ผู้เขียนมองว่าตัวเองใกล้เคียงกับคนที่อ่าน หนังสือดี ๆ แค่เล่มเดียว ในแทบทุกหัวข้อที่เกี่ยวกับงาน
- ผ่าน Pro Git จึงเข้าใจ data model ของ Git อย่างแน่นหนา แต่ไม่รู้ algorithm ที่อยู่ลึกลงไปกว่านั้น
- ถึงอย่างนั้นก็คิดว่าเพียงพอจะเหนือกว่าวิศวกรที่สุ่มหยิบมาคนหนึ่งได้สบาย
- เมื่อดูโปรเจกต์อย่าง Evennia ก็ยอมรับว่ามีคนที่อยู่ลึกกว่านั้นมาก
- จากการคุยกับคนผลงานสูงในหลายสาขา ผู้เขียนบอกว่ามักได้ยินปฏิกิริยาแบบเดียวกัน คือแทบทุกวงการมีคนจำนวนมากที่ยังไม่เคยลองอย่างจริงจังเลยด้วยซ้ำ
ความเชี่ยวชาญแตกชั้นไปได้ไม่สิ้นสุด
- บทสนทนากับ Seth พาไปสู่เรื่องว่า การเชี่ยวชาญลึก ไปได้ไกลแค่ไหน
- ตัวอย่างจากบาสเกตบอลคือวิดีโอของผู้เล่นที่เคยถูกมองว่าอยู่แถวล่างของ NBA แต่แม้จะเลิกเล่นไป 10 ปีและร่างกายไม่สมบูรณ์ ก็ยังถล่มผู้เล่นสมัครเล่นและกึ่งอาชีพระดับล่างได้สบายใน วิดีโอ
- ประสบการณ์ฟันดาบของผู้เขียนก็มีโครงสร้างแบบเดียวกัน
- ที่ Melbourne ผู้เขียนถูกมองว่าเป็น sabre fencer ที่ใช้ได้ และชนะมือสมัครเล่นส่วนใหญ่
- แต่กลับโดนผู้เล่นบางคนที่แข่งระดับชิงแชมป์รัฐกดขาด
- นักกีฬาคนหนึ่งที่เคยซ้อมด้วยกัน ภายหลังชนะ Australian Nationals แต่เมื่อเจอกับคนที่พยายามไปคัดโอลิมปิก กลับเก็บแต้มไม่ได้เลยแม้แต่แต้มเดียว
- ส่วน Yu Peng Kean จาก Malaysia แพ้แชมป์โอลิมปิกปี 2012 ในปีนั้นไป 15 ต่อ 1
- โครงสร้างแบบเป็นชั้น ๆ นี้ไม่ใช่เรื่องแปลกใหม่ ถ้านึกถึงกรณีอย่าง Magnus Carlsen ที่ถล่มนักหมากรุกซึ่งฝึกมาทั้งชีวิต แต่เมื่อได้เจอกับตัวจริง ความรู้สึกจะต่างออกไปมาก
- ผู้เขียนบอกว่าผู้เล่นระดับบนมักดูไกลกว่า เร็วกว่า และแม่นยำกว่านิดหนึ่งเสมอ ส่วนคู่ต่อสู้จะรู้สึกเหมือนเด็กตัวเล็ก ๆ วิ่งเข้าชนผู้ใหญ่
แรงจูงใจและ “คนที่เข้ามาอยู่ในวงการเทคผิดคน”
- ผู้เขียนยอมรับว่าตัวเองก็ใกล้เคียงกับภาวะ ละเมอเดิน ในบางด้าน เช่น เปียโน
- รู้สึกว่าตัวเองพรสวรรค์ไม่พอ แต่ในความจริงก็ไม่ได้ฝึกมากพอด้วย
- เพียงแต่ไม่ได้ทำเปียโนเป็นอาชีพ และไม่มีใครจ่ายเงินให้เขาในฐานะนักเปียโนมืออาชีพ
- ผู้เขียนมองว่าสังคมออกแบบผิด ที่ให้แรงจูงใจกับคนที่ไม่มีทั้งพรสวรรค์และความสนใจให้เข้ามาอยู่ในสายเทค
- คนจำนวนมากอาจตื่นตัวและจริงจังกว่าในกีฬา ศิลปะ คณิตศาสตร์ หรือด้านอื่น
- แต่เพราะบางสายมีเงินมหาศาล การบริหารองค์กรใหญ่ทำได้ยาก และมีแรงผลักให้เอาเงินบริษัทมาแปลงเป็นสถานะส่วนตัว จึงทำให้ทั้งโปรแกรมเมอร์แย่ ๆ และผู้นำแย่ ๆ ยังได้ค่าตอบแทนสูง
- ผู้เขียนวิจารณ์รุนแรงว่า PowerBI developer เป็นวิธีที่ทำให้ได้ค่าแรงสูงกว่าค่าเฉลี่ย ทั้งยังเอื้อให้ทำตัวเรื่อยเปื่อยวันละเกิน 6 ชั่วโมงได้ง่าย
- เขายกประสบการณ์งานแรกของ Christopher Hitchens มาประกอบ ว่าการที่ตัวเองทำบางงานได้แย่จนไม่อาจอยู่ต่อได้ กลับทำให้ต้องออกไปหาทางอื่น
หนังสือหนึ่งเล่มสร้างความได้เปรียบในการแข่งขัน
- ผู้เขียนโยงไปยังบทความ very little effort ของ Dan Luu ว่าบางครั้งการจะเป็นคนผลงานสูงอาจใช้แรงน้อยมาก
- คนผลงานสูงอาจหมายถึงคนที่ทำงานชัดเจนอย่างการตีลังกาหลังได้ หรืออาจหมายถึงคนที่ให้ผลลัพธ์สูงกว่าคนอื่นก็ได้
- หนังสือหนึ่งเล่มมักพาไปถึงระดับที่ “เพิ่มฟีเจอร์ใหม่ให้แอป React โดยไม่สร้าง technical debt” ได้
- ถ้าเลือกงานที่สังคมยอมจ่ายอย่างชาญฉลาด ผู้เขียนมองว่านั่นก็เพียงพอสำหรับเลี้ยงชีพอย่างมีจริยธรรม
- ถ้าอ่านหลายเล่ม ก็จะเข้าใกล้การแข่งแย่งงานเงินเดือนสูงสุด
- มันเป็นเขตที่สำคัญว่า คุณทำงานแบบเดียวกันได้ภายในหนึ่งวัน หรือหนึ่งสัปดาห์
- ถ้าคู่แข่งอ่าน N เล่ม คุณก็ต้องอ่าน N+1 เล่ม กลายเป็น การแข่งขันสะสมอาวุธ
- ผู้เขียนมองว่าเพราะ Deloitte และนักพัฒนาโดยเฉลี่ยไม่อ่านหนังสือเลย คนกลุ่มนี้จึงรับมือได้ง่าย
- หากเป็นพนักงานประจำที่ถูกผูกไว้กับองค์กร ก็อาจต้องทำงานร่วมกับคนแบบนี้จนรู้สึกหมดแรง
- แต่ถ้าเคลื่อนไหวแบบ mercenary มากขึ้น ก็อาจกดพวกเขาได้ทั้งในสัมภาษณ์งานและการประชุม
- ในการสัมภาษณ์สายเทคนิค ผู้เขียนเสนอว่าให้ถามผู้สมัครว่าชอบหนังสือเทคนิคเล่มไหน แล้วคุยต่อเฉพาะกับคนที่ตอบชื่อหนังสือที่ผู้สัมภาษณ์ตรวจสอบเนื้อหาได้ ก็อาจคัด dud candidate ส่วนใหญ่ออกได้
- แน่นอนว่าผู้สมัครที่อ่านหนังสือดีมากแต่ผู้สัมภาษณ์ไม่รู้จัก อาจกลายเป็น false negative
- แต่คาดว่า false positive จะมีน้อยมาก
คนที่พยายามแต่ไม่เกิดผล และทักษะในการคัดเลือกแหล่งเรียนรู้
- ยังมีกรณีที่ซับซ้อนกว่า คือคนที่ตั้งใจทำงานหนักจริง แต่กลับบริหารทีมไม่สำเร็จ
- พวกเขารบกวนวิศวกร ตื่นตระหนก ไม่เข้าใจการจ้างงาน ประเมินฝีมือตัวเองสูงเกินจริง แต่ก็พยายามอย่างจริงใจ
- พยายามทำ Scrum ให้ “ถูกต้อง” อยู่เรื่อย ๆ แต่สุดท้ายก็ดูเหมือนคนละเมอที่เดินลงไปกลางทะเลสาบ
- ผู้เขียนมองว่าสิ่งที่คนเหล่านี้ขาดคือ เมตาสกิล ว่าควรอ่านหนังสือเล่มไหน
- ความต่างระหว่าง Drawabox กับหนังสือของ Betty Edwards คือกรณีตัวอย่างที่ชัดเจน
- Drawabox ดูน่าเชื่อถือภายนอก แต่สำหรับเป้าหมายของผู้เขียน หนังสือของ Edwards ดีกว่ามาก
- ผู้เขียนมองว่า Drawabox กระโดดไปยังทักษะเชิงกล โดยตั้งสมมติฐานว่าผู้เรียนรู้เทคนิคหลักที่ Edwards เน้นอยู่แล้ว
- เพราะชิ้นส่วนสำคัญขาดหาย ต่อให้เรียนครบทั้งคอร์สก็อาจแทบไม่ก้าวหน้า
- ในวงการเทค ผู้เขียนมักเชื่อแหล่งเรียนรู้จาก คนที่เคยสร้างของน่าทึ่งด้วยตัวเอง มากกว่า
- ถ้ามีสัญญาณอย่างการดูแลโอเพนซอร์ส หรือความรู้ที่ปลอมเป็นสัญญาณได้ยาก ก็จะให้คะแนนสูง
- ส่วนความสำเร็จที่พร่ามัวกว่าอย่าง “อยู่บริษัทใหญ่” นั้นอาจได้มาจากโชคหรือการสร้างภาพ จึงให้คะแนนต่ำ
- เขามองว่าเรื่องโค้ดนั้นหลอกยากว่าจะคอมไพล์ผ่านหรือไม่
- ผู้เขียนยังเสนอเกณฑ์หลวม ๆ สำหรับประเมินแหล่งเรียนรู้
- ชื่อที่สะดุดตาเกินไปเป็นปัจจัยหักคะแนน
- หนังสือดีมักมีปกที่น่าเบื่อหรือดูเรียบหรู
- ถ้ามีคำว่า “leadership” อยู่ในชื่อ มักมีโอกาสสูงที่จะเป็นเรื่องเหลวไหล
- ยิ่งผู้เขียนอวดรางวัลมากเท่าไร ก็ยิ่งให้ความรู้สึกเหมือนกำลังโกหก
- สำนวนภาษาพูดเป็นจุดลบ แต่ถ้าหัวข้อมีความละเอียดอ่อน ก็ไม่ถึงกับเป็นข้อบกพร่องร้ายแรงเสมอไป
คำวิจารณ์ต่อ Agile, The Phoenix Project และการเรียนรู้ผ่าน LinkedIn
- ที่ทำงานเคยมี Agile consultant เข้ามา ฝ่ายบริหารชอบมาก แต่กลับให้วิศวกร “ให้คะแนน Agile training จาก 1 ถึง 5”
- ผู้เขียนมองว่าคำถามนี้เองก็ไม่มีความหมาย
- ถึงขั้นบอกว่าคนที่ชอบเซสชันแบบนั้น มีความสัมพันธ์เกือบ 100% กับคนที่อ่านหนังสือผิดเล่ม
- แม้แต่ในหนังสือเอง ก็ต้องทิ้งส่วนที่ไม่มีค่าให้เป็น
- The Phoenix Project มีไอเดียที่ดี แต่ผู้เขียนมองว่าเรื่องเล่าการเปลี่ยนผ่านองค์กรในนั้นทำให้มีตัวร้ายอยู่แค่คนเดียว ส่วนที่เหลือกลับเก่งและจริงจังกันหมด ซึ่งไม่ตรงกับความจริงขององค์กรใหญ่
- จึงควรเก็บไอเดียดี ๆ เอาไว้ แต่ต้องสังเกตให้ได้ว่าส่วนที่เหลือนั้นใกล้เคียงกับ “leadership fanfic”
- หากไม่มีความสามารถในการคัดเลือกเช่นนี้ การเรียนรู้และการพัฒนาตัวเองจะติดขัดอย่างมาก
- ผู้เขียนบอกว่าเมื่อผู้บริหารเปิดเผยรายการที่ตัวเองอ่าน ก็มักพอมองออกทันทีว่าคนนั้นมีโอกาสน้อยที่จะทำงานเก่ง
- และถ้าผู้นำบอกว่าเรียนรู้จาก LinkedIn ผู้เขียนก็จะรู้สึกต่อต้านอย่างแรง
สรุป: การเปิดหนังสือให้ผลดีมาก แต่ไม่จำเป็นต้องแนะนำคู่แข่ง
- ตอนแรกผู้เขียนตั้งใจจะเขียนบทความย้อนมองผลลัพธ์ที่ มากผิดปกติ ของการหยิบหนังสือขึ้นมาอ่านในยุค YouTube
- แต่ข้อสรุปจริงกลับออกมาในเชิงประชด ว่าไม่ว่ากรณีใดก็ไม่ควรแนะนำให้คนอื่นอ่านหนังสือ
- ถ้าคนอื่นยังคงไม่อ่านต่อไป มันก็กลายเป็นช่องทางหาเงินง่ายสำหรับคนที่อ่าน
- ท้ายบทความปิดด้วยมุกว่าโพสต์ถัดไปจะอัดแน่นไปด้วย anti-Git propaganda และลิงก์เกี่ยวกับ Scrum
2 ความคิดเห็น
ถึงจะอยากนำเทคโนโลยีมาใช้ อย่างน้อยก็ต้องรู้ก่อนว่ามันมีอยู่จริง ถึงจะได้ลองใช้ดูได้บ้าง เพราะฉะนั้นการรู้ไว้บ้างแม้เพียงผิวเผินจึงสำคัญ
ความคิดเห็นบน Hacker News
เขียนได้ดี แต่ดูเหมือนจะประเมิน ความรู้โดยนัยของวิศวกรที่ชำนาญ ซึ่งมือใหม่ไม่มี ต่ำเกินไป
บางครั้งมันดูเหมือนสามัญสำนึกธรรมดา แต่จริง ๆ แล้วไม่ใช่ และผลลัพธ์ก็มักนำไปสู่การขาดความเข้าอกเข้าใจได้ง่าย การใช้เวลากับเด็กหรือผู้สูงอายุ หรือช่วยญาติที่กำลังลำบากโดยยืนอยู่ฝ่ายเดียวกับเขา อาจช่วยสะสมความเข้าอกเข้าใจแบบนั้นได้ คล้ายกับการนึกถึงความแตกต่างระหว่างเจ้าของภาษาที่พูดได้อย่างเป็นธรรมชาติ กับคนที่กำลังลำบากกับการเรียนภาษา
พี่ผมลำบากกับสิ่งที่ผมเคยมองว่าเป็นเรื่องแน่นอน เช่น การย่อหน้าให้สอดคล้องกัน หรือการอ่านข้อความ error ของ compiler จริง ๆ แล้วเอาไปใช้ debug กว่าจะถึงระดับที่พี่ได้งานเป็นโปรแกรมเมอร์ใช้เวลาหลายปี และความจริงผมเองก็ใช้เวลาหลายปีเหมือนกัน เพียงแต่ผมลืมจุดเริ่มต้นของตัวเองไปเท่านั้น
วิศวกรที่เก่งที่สุดในบริษัทที่ปรึกษาแทบไม่อ่านหนังสือเลยเพราะเป็น ADHD รุนแรง แต่มีประสบการณ์ภาคปฏิบัติมหาศาล และอ่านเอกสารกับบทความบล็อกคุณภาพสูงมากพอ จนดูเหมือนจะทดแทนกันได้ในระดับหนึ่ง เคยมีคนที่เก่งมากคนหนึ่งบอกว่า “หนังสือไม่ได้ช่วยอะไรมากนัก” แต่ก็ไล่ชื่อหนังสือห้าเล่มที่อ่านในปีนั้นได้เป็นชุด ๆ ต่อให้ตัวหนังสือเองอาจไม่ได้มีประโยชน์กับเขามากนัก แต่ วินัย ที่ทำให้เขาเปิดอ่านหนังสือห้าเล่มนั้น ดูเหมือนจะเป็นสิ่งที่พาเขาขึ้นไปอยู่แถวหน้า
ความรู้สึกนั้นมาจาก การฝึกฝนอย่างตั้งใจ ในปริมาณมหาศาล
ประโยคที่ว่า “วิศวกรที่ไม่เคยลองอย่างจริงจังเลยตลอดอาชีพ” ตรงกับประสบการณ์ของผม 100%
ผมไม่ใช่นักพัฒนาอัจฉริยะ แต่คิดว่าตัวเองมีความสามารถพอจะทำทางแก้ที่โอเคให้กับปัญหาขนาดไม่ใหญ่มากที่ได้รับมอบหมาย และมีเซนส์ว่าแนวทางไหนถูกหรือผิด แม้ยังไม่มั่นใจด้วยซ้ำว่าจะผ่านการสัมภาษณ์ FAANG ได้ไหม เวลาทำงานผมจะอยู่ในโหมดระแวดระวังตลอด เหมือนถ้าเผลอละสายตาแป๊บเดียว gremlin จะคลานเข้ามา
เช่น แค่มอง PR ที่วิศวกร senior สองคนอนุมัติไปแล้ว 30 วินาที ก็เจอ ช่องโหว่ด้านความปลอดภัย ร้ายแรง หรือเห็น pattern การโหลดที่ดูโอเคกับ record ที่ทดสอบ 5 รายการ แต่ใน dataset จริงกลับยิง query ฐานข้อมูล 300 ครั้งต่อหน้า หรือเห็น code ที่ใช้เวลา CPU 75% ไปกับการประกอบ date object กลับขึ้นมาจาก timestamp ที่เดี๋ยวก็จะทิ้งทันที สุดท้ายมันดูเหมือนเป็นการขาดความอยากรู้ ความสนใจ และแพสชันโดยธรรมชาติต่อการเขียนโปรแกรม
สำหรับผม การเขียนโปรแกรมที่ดีใกล้เคียงกับ ความเป็นช่างฝีมือ หากต้อง deploy งานปะผุชั่วคราวเพราะความต้องการทางธุรกิจ จะเกิดความไม่สบายใจที่อธิบายเป็นคำพูดยาก และถ้าเป็นงานที่ผมสร้างเอง ต่อให้ไม่ได้ผูกพันกับตัวผลิตภัณฑ์มากนัก ผมก็อยากทำให้มันดี ผมได้ยินบ่อยว่า “ไม่รู้ว่าจะทำให้มันทำงานยังไง เลยทำแบบนี้ไป” แต่ความหมายจริง ๆ มักใกล้กับ “พอลองครั้งแรกแล้วติดอุปสรรคเล็ก ๆ ก็ไม่ได้ลองต่อ” มากกว่า ยิ่ง codebase แย่ลงเท่าไร การมี contribution ที่ภาคภูมิใจได้ก็ยิ่งยากขึ้นเท่านั้น
ผมสงสัยว่าผมแค่เคยทำงานกับบริษัทที่แย่เป็นพิเศษหรือเปล่า หรือทั้งอุตสาหกรรมมันเป็นระดับนี้จริง ๆ
เจ้าตัวไม่รู้หรอก แต่ rockstar ของทีมเราก็คือคนนั้นแหละ ดูจากตัวอย่างแล้ว เหมือนเพื่อนร่วมงานไม่ได้ใส่ใจงานของตัวเองมากนัก
ผมคือคนที่ทุกคนเรียกหาเมื่อเกิดเรื่อง เมื่อจำเป็นต้องจัดการความเห็นขัดแย้ง เมื่อต้องซ่อมสิ่งที่ดูเหมือนซ่อมไม่ได้ หรือเมื่อต้องหาคำตอบอะไรบางอย่าง ผมไม่เคยรู้สึกว่าตัวเองคู่ควร และคิดว่าถ้าไปอยู่ที่อย่าง Facebook คงอยู่ไม่รอดแม้แต่วันเดียว ผมไม่มีความสามารถในการปรับตัวให้เข้ากับทีมและทนโครงสร้างการเมืองในองค์กรได้ จึงชอบมุมมืด ๆ มากกว่า
ถ้าถามว่าทั้งอุตสาหกรรมเป็นระดับนี้หรือไม่ ความจริงแล้วมันแย่กว่านี้มาก จำนวนคนในอุตสาหกรรมมากกว่าที่เคยเป็นมา และแทบเป็นไปไม่ได้ที่จะหาคนที่รู้เรื่องจริง ๆ คุณต้องสร้าง รายชื่อคนที่เชื่อถือได้ ตลอด 5–10 ปี และรักษาความสัมพันธ์ไว้ อย่าปล่อยหลุดเด็ดขาด
เพราะซ่อนตัวในฝูงชนได้ยากกว่า และแน่นอนว่าบริษัททุกขนาดก็มีคนฉลาดและทุ่มเทอยู่ อย่ามัวดับไฟไปเรื่อย ๆ แต่ให้ไปหาคนที่มีหรือเคารพหลักการร่วมกัน แล้วน่าจะโอเค
ผมเห็นคนจำนวนมากเกินไปที่โยน code ใส่ issue โดยแทบไม่มีความสนใจ ความใส่ใจ หรือความอยากรู้ แล้วก็คิดว่าใช้ได้แล้ว ผู้จัดการเก่าของผมมองหาคนที่มี “ประกายไฟ” และจากการที่เขาจ้างผม ก็ดูเหมือนตอนนั้นผมเองก็มีเหมือนกัน
นักพัฒนาที่ไม่มีประกายไฟแบบนั้นก็ยังมีที่ไป และในทางกลับกัน ผมก็เคยเห็นองค์กรที่ลำบากเพราะพยายามรวบรวมแต่คนแบบนั้น แต่ก็มี ผู้จบ bootcamp จำนวนมากที่เข้ามาเพราะเงิน หรือเพราะคิดว่าเป็นอาชีพที่มั่นคง และบ่อยครั้งก็ไม่ได้มีความสนใจอื่นมากนัก
ถ้าในปี 2025 มีรายได้เพียงพอจนสามารถจ้างคนได้ในปี 2026 ลองส่งอีเมลมาที่บริษัทที่ปรึกษาดูได้
ส่วนที่สำคัญคือการอ่าน “หนังสือที่ถูกต้อง” ตอนมัธยมเคยลองอ่านหนังสือพัฒนาตัวเองอยู่สองสามเล่ม และแค่อ่านไม่กี่เล่มก็รู้ได้เลยว่า ส่วนใหญ่ใกล้เคียงกับ แฟนฟิก อย่างที่ผู้เขียนว่าไว้
ระหว่างอ่านจะคอยถามตัวเองอยู่เรื่อย ๆ ว่า “นี่มันเป็นเรื่องที่ชัดเจนอยู่แล้วไหม? เป็นสิ่งที่รู้อยู่แล้วหรือเปล่า?” มีตัวอย่างหรือเรื่องเล่าเยอะ และมักเห็นแพตเทิร์นที่พยายามขยายอุปมาหรือคำขวัญง่าย ๆ อย่าง “skin in the game” ให้กลายเป็นปรัชญาชีวิตทั้งชุด
กลุ่มที่สองจำข้อมูลได้ดีกว่ามาก มนุษย์เป็นสิ่งมีชีวิตที่ถูกดึงดูดด้วยเรื่องเล่า และการที่มหากาพย์ที่เก่าแก่ที่สุดเป็นเรื่องเล่าก็มีเหตุผลอยู่ หนังสือพัฒนาตัวเองทำตามสูตรนี้ก็เพราะมันได้ผล การอ่านบางสิ่ง การเข้าใจมัน การนำไปใช้ และการฝึกใช้จนชำนาญนั้นแตกต่างกันมาก
ผมมองว่าแก่นของหนังสือประเภทนี้คือการยอมรับไอเดีย รูทีน หรือกระบวนการบางอย่างอย่างเต็มที่ และสร้างความสามารถในการนำไปใช้ได้แทบจะเป็นสัญชาตญาณเมื่อสถานการณ์มาถึง หนังสือบางเล่มจริง ๆ แล้วเป็นแค่บทความบล็อกก็พอ และก็มีคำบรรยายยืดยาวแย่ ๆ ที่ใส่มาเพื่อเพิ่มจำนวนหน้า แต่เรื่องเล่าและ narrative จำนวนมากเป็นอุปกรณ์ที่ทำให้ผู้อ่านพบตัวเองในเรื่องใดเรื่องหนึ่ง และจดจำบทเรียนได้อย่างแรงกล้า จะไปโทษหนังสือเพียงเพราะตั้งชื่อได้เหมาะเจาะก็คงไม่ได้
ผมมักถูกถามว่าอ่าน Cal Newport ไหม แต่ทนอ่านได้ยาก เพราะเขาผสมข้อสังเกตที่ดีกับข้อสังเกตซ้ำซาก แล้วพึ่งพาตัวอย่างกับเรื่องเล่าเป็นหลัก มีบางจุดที่ตัวอย่างและเรื่องเล่าจำเป็น แต่แนวทางนั้นไม่ได้รู้สึกน่าเชื่อถือสำหรับผม น่าเสียดายที่ตอนเขียนนึกถึงสามข้อข้างหน้าไม่ออก และก็น่าขำที่ “Skin In The Game” เป็นหนังสือของ Taleb พอดี ไม่ได้หมายความว่าหนังสือเล่มนั้นแย่ แค่ตลกดีที่หนังสือของผู้เขียนซึ่งทำให้ผมมีภูมิคุ้มกันต่อแพตเทิร์นแบบนี้กลับถูกยกมาเป็นตัวอย่าง
โดยทั่วไปช่วงต้นจะมีไอเดียดี ๆ หนึ่งหรือสองอย่าง ที่เหลือคือการพูดซ้ำและเติมเนื้อหา ปัญหานี้พบได้บ่อยมากจนผมคิดว่าส่วนใหญ่ฟังแค่ วิดีโอสรุปบน YouTube ก็พอ อีกเทคนิคหนึ่งคือพยายามหา edition แรกเสมอ เพราะโดยมากจะสั้นกว่าและชัดเจนกว่า
พอกลับมาเริ่มอ่านหนังสืออีกครั้ง ช่วงเวลาที่คงความสนใจ และสมาธิเพิ่มขึ้นมาก และความอยาก doomscroll ก็ลดลงด้วย
หลายสิ่งที่ผู้คนมองว่าเป็นลักษณะคล้าย ADHD ในตัวเองก็ทับซ้อนกับความสามารถในการมีสมาธิที่ยังพัฒนาไม่มากพอ หรือถูกปล่อยปละโดยตั้งใจ ไม่ได้หมายความว่าทุกคนเป็นเช่นนั้น หากคุณวินิจฉัยตัวเองหรือได้รับการวินิจฉัยจากผู้เชี่ยวชาญว่าเป็น ADHD ก็ควรลองทบทวนว่าคุณได้ฝึกกล้ามเนื้อสมาธิเป็นประจำด้วยการทำงานที่ต้องใช้สมาธิหรือไม่ และได้ดึงตัวเองออกจากขยะอย่าง doomscroll หรือวิดีโอสั้นหรือเปล่า คุณกำลังหลีกเลี่ยงสิ่งยาก ๆ เหมือนเป็นทาสของความทุกข์ แล้วจมอยู่กับพฤติกรรมที่ยิ่งตอกย้ำปัญหาหรือไม่ สมาธิเป็น ความสามารถที่ถูกใช้จนหมดได้ สำหรับทุกคน
ออกจะพูดเกินจริงไปบ้าง และความจริงซับซ้อนกว่านั้น แต่ในฐานะหลักการทั่วไปก็เห็นด้วย แค่ใส่ใจงานที่ทำอย่างจริงใจก็สามารถนำหน้าคนที่มาทำงานเพื่อรับเงินเดือนอย่างเดียวได้ไกลมากแล้ว
เห็นด้วยอยู่มากกับแนวคิดที่ว่า “สังคมที่เริ่มชักจูงคนที่ไม่มีพรสวรรค์หรือความสนใจให้เข้าสู่วงการเทคโนโลยีนั้นมีบางอย่างผิดพลาดอย่างหนัก” แต่กรอบคิดนี้นำไปสู่ข้อสรุปที่น่าสนใจ
ข้อแรก กระบวนการจ้างงานด้านเทคโนโลยีโดยรวมอาจ ไม่มีประสิทธิภาพ ยิ่งกว่าที่คนในอุตสาหกรรมบ่นกันหลายระดับ แม้แต่ตอนหาคนมีแววระดับเริ่มต้น บริษัทก็อาจกำลังคัดกรองผิดสิ่งอยู่
ข้อสอง งานที่มี long tail แบบกีฬาอาชีพหรือศิลปะมีแรงจูงใจทางการเงินที่แย่มาก หากจะจัดการปัญหาที่ผู้เขียนมองเห็น ก็ต้องจัดการเรื่องนี้ไปพร้อมกันด้วย ซึ่งตัวมันเองเป็นโพรงกระต่ายที่ลึกมาก
ข้อสาม ถ้าสถานการณ์แย่ขนาดนั้น ทำไมบริษัทถึงไม่ฝึกพนักงานเองในที่ทำงาน
ข้อสี่ เราแทบไม่เคยถามว่าต้นทุนค่าเสียโอกาสนี้แพงกว่า รายได้พื้นฐาน หรือไม่ เพราะทุกวันนี้การตัดสินใจของภาคเอกชนกับภาครัฐมีแนวโน้มจะตั้งฉากกัน
ต่อให้พวกเขาผ่านหลักสูตรไปจนจบ ก็ไม่มีใครรู้ว่าหากพวกเขาได้งานพัฒนาซอฟต์แวร์จริง ๆ แล้วเส้นทางอาชีพจะเป็นอย่างไร
สถานที่ส่วนใหญ่มองพนักงานทุกคนเสมือนว่า “ผ่านการฝึกครบแล้ว” และแปลกตรงที่ปฏิบัติต่อการฝึกระหว่างทำงานเหมือนเป็นความเมตตาที่มอบให้พนักงาน เรื่องนี้น่าจะเชื่อมโยงกับวัฒนธรรมที่แรงงานสายเทคโนโลยีอยู่กับแต่ละบริษัทเป็นเวลาสั้น ๆ
การขึ้นค่าจ้างในสายเทคโนโลยีเป็นสัญญาณว่ามีโปรแกรมเมอร์ไม่เพียงพอ การเติบโตทางเศรษฐกิจส่วนใหญ่ของสหรัฐฯ ตอนนี้ตั้งอยู่บนฐานของ การเขียนโปรแกรมและเทคโนโลยี
สุดท้ายแล้วก็ดูเหมือนเรื่องแนว “Matlab filedriver ผู้ครอบงำ”
คือการหยิบอะไรก็ได้จากประสบการณ์ชีวิตของตัวเองมาใส่ เช่น อ่านหนังสือมากกว่าหนึ่งเล่ม เล่นกีตาร์ มีงานอดิเรกประหลาดสักอย่าง เป็นนักยิมนาสติกกึ่งอาชีพ แล้วสร้างกรอบเรื่องเล่าเพื่ออธิบาย rant ยาว ๆ ว่าตัวเองเก่งแค่ไหนหรือคนอื่นโง่แค่ไหน โดยแทบไม่ต้องใช้ความพยายาม
การอ่านเป็นเหมือนตัวเร่งและจุดเริ่มต้นมากกว่า ส่วนสิ่งที่ทำให้มันลงตัวจริง ๆ คือ การฝึกฝน และสิ่งสำคัญคือการรู้สึกสนใจมากพอจนไปค้นหาและลองทำหลายอย่างด้วยตัวเอง
https://ludic.mataroa.blog/blog/i-will-fucking-piledrive-you...
เห็นด้วยอย่างยิ่งกับสมมติฐานนี้ ทักษะของผมแบ่งได้เป็นสามประเภท: สิ่งที่คิดค้นขึ้นเองโดยตรงจากหลักการปฐมฐาน, สิ่งที่อ่านหนังสือหนึ่งเล่มแล้วทำได้, และสิ่งที่ทำไม่ได้
หนึ่งในสิ่งที่ผมทำไม่ได้คือ การหาหนังสือดี ๆ หนังสือมีอยู่ทุกที่ และส่วนใหญ่ก็เป็นขยะ แต่หนังสือที่มีคนแนะนำมาล้วนยอดเยี่ยมทั้งนั้น มีหนังสือดี ๆ เกี่ยวกับวิธีหาหนังสือดี ๆ ไหม?
https://www.gnooks.com/faves.php
Gnod ทั่วไป: gnod.com
https://www.literature-map.com/
ยังมีไซต์ที่รวบรวมรายชื่อหนังสือไว้ด้วย
https://www.goodreads.com/review/list/21394355-william-adams...
https://www.goodreads.com/review/list/21394355-william-adams...
ถ้าไม่มีคำแนะนำเข้ามาเองตามธรรมชาติ ก็หาได้จากหนังสือแนะนำและบรรณานุกรมของหนังสือที่เคยอ่านแล้วชอบ, หนังสือเล่มอื่นของผู้เขียนที่ชอบ, หรือหนังสือเล่มอื่นในซีรีส์ที่เคยอ่านไปเล่มหนึ่งแล้วถูกใจ
ถ้าใช้เครื่องมือที่ผสานโมเดลภาษาขนาดใหญ่กับข้อมูลเรียลไทม์อย่าง Gemini ผลลัพธ์จะดียิ่งขึ้น
เชื่อมโยงกับประโยคที่ว่า “เรียนรู้จากสิ่งที่คนอื่นใช้เวลาคิดและเตรียมมาอย่างยาวนาน แล้วผมพยายามทำความเข้าใจมันในเวลาที่สั้นกว่ามาก”
https://news.ycombinator.com/item?id=40147526
การอ่าน HN นับเป็นการพัฒนาตัวเองด้วยไหม? ผมนับไม่ถ้วนเลยว่าได้ทักษะหรือ “เบาะแส” ของไอเดียมากแค่ไหนจากการใช้เวลาในไซต์นี้
ถ้าไม่มีเรื่องราวต่าง ๆ ที่นี่ ผมคงไม่ได้ลาออกจากงานมาเป็น ผู้ก่อตั้งเดี่ยว แน่ ๆ ส่วนมันเป็นทางเลือกที่ดีไหม ยังเร็วเกินไปที่จะพูด
ผมได้รับความรู้มากมายแบบซึมซับที่คงไม่ได้จากวิธีอื่น เทคโนโลยีที่เคยใช้จริงมีเพียงส่วนน้อยมาก แต่ผมก็ได้รู้จักระบบนิเวศการเขียนโปรแกรมโดยรวมค่อนข้างดี มันช่วยให้รู้ว่า “โลกนี้มีอะไรอยู่บ้าง” และ “ควรค้นหาอะไร”
อย่างไรก็ตาม 95% ของความรู้แบบซึมซับนั้น น่าจะได้มาด้วยเวลาเลื่อนดูเพียง 10% เท่านั้น โดยรวมแล้ว HN ถือว่าใช้เวลาได้คุ้มค่า แต่ปกติผมก็ตั้งใจเสียเวลาอยู่ดี