ผมเองก็รู้สึกคล้าย ๆ กันตอนเขียนโค้ดด้วย AI ครับ พอดูสาเหตุที่สรุปไว้แล้วก็คิดว่าน่าจะเป็นเพราะเวลาเราคนเขียนโค้ดนั้น แพตเทิร์น กฎการตั้งชื่อ การจัดการ edge case เงื่อนไข guard ต่าง ๆ ที่ปกติเรามีเป็นความรู้พื้นฐานอยู่แล้ว ไม่ได้ถูกส่งให้เป็นบริบทอย่างเพียงพอ
เพราะงั้นผมเลยทำไฟล์กฎที่รวบรวมเรื่องพวกนี้ไว้ไฟล์หนึ่ง แล้วเวลาจะเขียนโค้ดก็สั่งให้อ่านและปฏิบัติตามไฟล์นี้ทุกครั้ง แบบนี้พอปรับปรุงแค่ไฟล์กฎ ผลลัพธ์ที่ได้ก็ดีขึ้นมากเลยครับ

 

ผมหาข้อมูลเพราะกะว่าจะจัดระเบียบไว้ใน obsidian
ดูเหมือนว่าจะมีอยู่หลายแบบที่ใช้กันบ่อยครับ

https://gemini.google.com/share/e875e7e7c19f

 

ช่วงนี้ประโยคที่ว่า 'AI คืออนาคต' ซึ่งกำลังเป็นประเด็นร้อนที่สุด ยังคงผุดขึ้นมาในหัวอยู่เรื่อย ๆ..

 

กลัวว่าจะมีความเห็นประมาณว่า "ทำออกมาได้เยอะขนาดนั้น งั้นบั๊กมากขึ้น 1.7 เท่าก็เหมือนได้มาฟรีไม่ใช่เหรอ" ...

 

"คนบ้างาน", "วัฒนธรรมการทำงานหนักเกินไป"

 

คนที่เคยลุยอย่างบ้าคลั่งมาก่อนเท่านั้น จึงจะสามารถปรับความเร็ว ประสิทธิภาพ และคุณภาพให้เหมาะสมที่สุดได้

 

แต่มันก็เร็วใช่ไหมล่ะ? ทำให้นึกถึงมีมนี้เลย 555

 

นึกขึ้นได้ว่าในเอกสารของระบบจัดระเบียบที่ชื่อ Johnny Decimal ซึ่งเพิ่งได้อ่านไปเมื่อไม่นานนี้ก็มีบทความคล้ายกันอยู่ เลยนำมาฝากครับ ไม่ใช่เรื่องยิ่งใหญ่อะไร แต่เป็นบทความที่บอกว่า หากจะนำระบบจัดการความรู้มาใช้กับองค์กร (และกับตัวบุคคล) ก็จำเป็นต้องมีบทบาทแบบ "บรรณารักษ์" ที่มองภาพรวมทั้งหมดออกและลงมือจัดระเบียบด้วยตัวเอง
11.08 The Librarian • Johnny.Decimal

 

นี่คือบทความที่ผมเคยแชร์ไว้ในช่วงแรก ๆ ของ GeekNews

ผมขายหัวหอมบนอินเทอร์เน็ต 저는 인터넷에서 양파를 팝니다

ตอนนี้กลับมาอ่านก็ยังเป็นบทความที่น่าสนุกอยู่ครับ

 

เป็นบทความและคอมเมนต์ที่ยอดเยี่ยมมากเลยครับ

 

บทความนี้ทำให้เห็นว่ามุมมองของแต่ละคนแตกต่างกันไปตามมุมที่ใช้มองนะครับ สำหรับผม เกณฑ์ที่ใช้แยกระหว่างวิศวกรระดับซีเนียร์กับระดับกลางคือเรื่องของขอบเขตงานเท่านั้น
การทำให้ Ambiguity กลายเป็นสิ่งที่ชัดเจนเป็นคุณสมบัติพื้นฐานของวิศวกร และผมคิดว่าตั้งแต่วิศวกรระดับกลางขึ้นไปก็ควรทำสิ่งนี้ได้จึงจะเหมาะกับตำแหน่งวิศวกร ดังนั้นสำหรับผม บทความนี้น่าจะใช้เป็นเกณฑ์แบ่งระหว่างวิศวกรระดับกลางกับวิศวกรมือใหม่ (associate) ได้ครับ

 

ความเป็นเลิศทางเทคนิคในสภาวะที่ยังนิยามปัญหาให้ชัดเจนไม่ได้
ก็เป็นได้แค่การ "แก้ปัญหาที่ผิดอย่างสง่างาม" เท่านั้น

ประโยคที่ขนลุกจริง ๆ

 

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

 

"ถ้าคุณไม่ได้ใช้ชีวิตตามที่คิด สุดท้ายคุณจะคิดไปตามที่ใช้ชีวิตอยู่"

 

Spotify คงเดือดน่าดูสินะ

 

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

 

ดีใจที่ได้เห็น Gödel, Escher, Bach เป็นหนังสือที่ยอดเยี่ยมเกี่ยวกับสติปัญญาของมนุษย์และการเรียกซ้ำ

 
1. ทักษะการตั้งคำถามและทุนทางสังคม (Social Capital)
  • ความไม่รู้เชิงกลยุทธ์: คำถามของซีเนียร์ไม่ได้เกิดจากความไม่รู้ แต่เป็นการกระทำที่ตั้งใจเพื่อขจัดความไม่แน่นอน การกล้าถามคำถามพื้นฐาน ("ตัวย่อนี้หมายถึงอะไร?") โดยไม่รู้สึกอายคือความสามารถหลัก
  • การใช้ทุนทางสังคม: ต่างจากจูเนียร์ ซีเนียร์มี 'ทุนทางสังคม (ความไว้วางใจ)' ที่สร้างไว้แล้ว จึงไม่ถูกมองว่าไร้ความสามารถแม้จะถาม "คำถามโง่ ๆ" บทบาทของซีเนียร์คือใช้สิ่งนี้เพื่อขจัดความคลุมเครือในการประชุม
  • การคำนึงถึงบริบททางการเมือง: สำหรับผู้จัดการที่หลีกเลี่ยงความชัดเจน คำถามตรงเกินไปอาจถูกมองเป็นการคุกคามได้ ดังนั้นจึงต้องใช้ศิลปะการวางตัวขั้นสูงในการเลือกคำถามที่ปลอดภัยทางการเมืองและยังช่วยให้โปรเจกต์เดินหน้าต่อได้
2. ความเป็นอิสระและการบริหารความเสี่ยง (Autonomy & Risk)
  • แก้ปัญหาได้แม้ไม่มีตาข่ายนิรภัย: ความสามารถของซีเนียร์วัดจากการฝ่าปัญหา (Plough through) และทำงานให้สำเร็จได้ด้วยตัวเอง แม้ไม่มีความช่วยเหลือจากภายนอกหรือคำสั่งที่ชัดเจน
  • ควบคุมความโกลาหล (Chaos): แทนที่จะเรียกร้องความชัดเจนแบบไม่มีเงื่อนไข ซีเนียร์จะตัดสินใจตามสถานการณ์ว่าจะ 'หยุด' หรือ 'เดินหน้า' ลดความสับสนด้วยการตั้งสมมติฐานที่เหมาะสมและลงมือส่งงาน (Ship) แทนการรอสเปกที่สมบูรณ์แบบ
  • การรับความเสี่ยงอย่างคำนวณแล้ว: ไม่ว่าจะเป็นการแก้โค้ดที่คอมไพล์ไม่ผ่านใน runtime หรือการทำรีแฟกเตอร์ครั้งใหญ่ ซีเนียร์สามารถตัดสินใจทางเทคนิคที่กล้าหาญแบบที่จูเนียร์ทำไม่ได้ และรับผิดชอบต่อผลลัพธ์ที่ตามมา
3. เงินเฟ้อตำแหน่งงานและความขัดแย้งเชิงโครงสร้างของการจ้างงาน
  • เงินเฟ้อตำแหน่งงาน (Title Inflation): มีแนวปฏิบัติแพร่หลายในการเลื่อนจูเนียร์ที่ยังไม่พร้อมขึ้นเป็นซีเนียร์เพื่อให้บรรลุตัวชี้วัดผลงาน ส่งผลให้เกิดช่องว่างระหว่างตำแหน่งกับความสามารถจริง
  • ข้อจำกัดของวิธีการจ้างงาน: บริษัทต่าง ๆ มุ่งคัดคนจากความสามารถในการแก้โจทย์อัลกอริทึม (LeetCode) แทนที่จะดูความสามารถในการทำให้ความต้องการที่คลุมเครือกลายเป็นสิ่งที่จับต้องได้ ผลคือมี "ซีเนียร์ที่ทำอะไรไม่ได้เลยถ้าไม่มีสเปก" ถูกผลิตออกมาจำนวนมาก
  • การทำหน้าที่แทน PM: เกิดปรากฏการณ์ที่ซีเนียร์เอนจิเนียร์ต้องเสียเวลาไปกับการทำให้แผนงานที่ยังไม่สุกงอม (Half-baked spec) ซึ่ง PM ที่ขี้เกียจโยนมา กลายเป็นรูปธรรม แม้จะนับเป็นความสามารถของวิศวกรด้วย แต่ก็เป็นหลักฐานของความไม่มีประสิทธิภาพเชิงองค์กรเช่นกัน
4. อายุงาน (Tenure) อย่างเดียว vs การฝึกฝนอย่างมีเจตนา
  • ความต่างเชิงคุณภาพของประสบการณ์: "การเติบโต 10 ปี" กับ "เอาประสบการณ์ 1 ปีมาทำซ้ำ 10 ครั้ง" ต้องถูกแยกออกจากกันอย่างชัดเจน ซีเนียร์ที่แท้จริงเกิดจากการฝึกฝนและการท้าทายตัวเองอย่างมีเจตนา โดยก้าวออกจากพื้นที่ที่คุ้นเคย
  • If vs What-if: จูเนียร์มุ่งจัดการกับเงื่อนไขที่ได้รับ (If) แต่ซีเนียร์จะตั้งสมมติฐานและเตรียมรับมือกับกรณีที่เงื่อนไขเปลี่ยนไป (What-if)
  • นิยามของแต่ละช่วงการเติบโต: มาตรฐานที่พบได้ทั่วไปในอุตสาหกรรมแบ่งเป็น 'ช่วงที่ต้องมีคนชี้แนะ (Junior)' → 'ช่วงที่ทำงานได้อย่างอิสระ (Regular)' → 'ช่วงที่ชี้แนะผู้อื่นได้ (Senior)'
5. มุมมองแบบกังขาต่อตำแหน่งซีเนียร์
  • เป็นเพียงระดับเงินเดือน (Pay Grade): มีมุมมองเชิงประชดว่าคำว่าซีเนียร์ไม่ใช่ตัวชี้วัดความสามารถ แต่เป็นเพียงการจัดประเภททางธุรการที่ HR สร้างขึ้นเพื่อกำหนดเงินเดือน
  • ช่องว่างระหว่างบริษัท: มีความแตกต่างอย่างมากทั้งด้านความสามารถและค่าตอบแทนระหว่างซีเนียร์ของบริษัทบิ๊กเทค (ที่แก้ปัญหาซึ่งมีความคลุมเครือสูงและขอบเขตกว้าง) กับซีเนียร์ของบริษัททั่วไป (ที่อาจเป็นเพียงพนักงานอายุงานยาวนาน)