- นักพัฒนาคนหนึ่งที่ หยุดเขียนและหยุดกิจกรรมออนไลน์ไปหลายเดือนเพราะความกลัว ตัดสินใจ หยุดเซ็นเซอร์ตัวเอง และสารภาพถึงข้อบกพร่องทั้งด้านเทคนิคและด้านชีวิตส่วนตัวที่ก่อนหน้านี้ไม่กล้ายอมรับ
- ยอมรับว่าตัวเองไม่เข้าใจแนวคิด polymorphism มานานกว่าสิบปี, ลืมทักษะ SQL ไปแล้ว, และโค้ดส่วนใหญ่ที่ปล่อยขึ้นระบบนั้น ถูก deploy โดยไม่มี automated tests
- พยายามปรับตัวตามการเปลี่ยนแปลง tech stack ของบริษัทจน เลิกเรียน C# และ Blazor, ยัง รัก Ruby อยู่เสมอแต่ไม่ได้ใช้ในอาชีพ, และรู้สึกกดดันทางจิตใจเมื่อผู้จัดการและเพื่อนร่วมงานอ่านบล็อกของตน
- เล่าถึง ประสบการณ์ถูก cyberbullying หลังส่ง PR ที่เขียนด้วย AI รวมถึงความรู้สึกตรงไปตรงมาเกี่ยวกับ remote work และความเห็นว่า ไม่จำเป็นต้องมี development process แบบออกแบบเฉพาะภายในองค์กร
- ปิดท้ายด้วยความตั้งใจว่าจะวางความกลัวลง และเดินหน้าต่อด้วย การเรียนรู้อย่างต่อเนื่องและการเขียนอย่างเปิดเผย โดยไม่เซ็นเซอร์ตัวเองอีก
จุดเริ่มต้น: อะไรทำให้ตัดสินใจหยุดความกลัวและการเซ็นเซอร์ตัวเอง
- หลังเดือนเมษายน มีช่วงเวลาที่ กลัวมากจนโพสต์อะไรไม่ได้เลย และตัดขาดจากทั้งโซเชียลมีเดีย news aggregator และฟอรัมทั้งหมด
- เมื่อรู้สึกว่าปล่อยให้สภาพนี้ยืดเยื้อต่อไปไม่ได้ จึง ตัดสินใจกลับมาเขียนอีกครั้งโดยก้าวข้ามความกลัว
- ที่ผ่านมาซ่อนความอ่อนด้านพื้นฐานไว้อย่างแน่นหนาเพราะไม่อยากให้ใครเห็น แต่สุดท้ายก็เริ่มมองเห็นว่า นักพัฒนาจำนวนมากก็ทำงานอยู่ท่ามกลางช่องโหว่ทางความรู้แบบคล้ายกัน
- วิธีเรียนรู้ที่ผ่านมาเหมือน slime mold ที่เติบโตเฉพาะบริเวณที่ใช้งาน ส่วนความรู้ที่ไม่ได้ใช้ก็แห้งตายไปแบบนั้น
- ช่วงหลังเริ่มกลับมาเติมพื้นฐานอีกครั้ง และเมื่อเรียบเรียงสิ่งที่เรียนรู้ผ่านการเขียนและการพูด ก็เริ่มเกิดความรู้สึกว่า การยอมรับเบา ๆ ว่า “ไม่รู้” เป็นเรื่องที่ทำได้
- เมื่อได้สัมผัสด้วยตัวเองว่าพื้นฐานสามารถเรียนใหม่ได้ ก็เริ่มมั่นใจว่า ไม่มีคำว่าสายเกินไป
ช่วงเวลาที่ไม่เข้าใจ polymorphism มานานกว่าสิบปี
- คิดมาตลอดว่าตัวเองเขียนโค้ดเชิงวัตถุตั้งแต่ปี 2012 แต่เพิ่งยอมรับกับตัวเองว่า แม้กระทั่งเมื่อราว 1 ปีก่อนก็ยังไม่ได้เข้าใจ polymorphism อย่างแท้จริง
- ต้องเผชิญกับความจริงว่าโค้ดที่เขียนมาจนถึงตอนนี้ แทนที่จะเป็น object-oriented กลับ ใกล้เคียงกับ structured programming มากกว่า
- ไม่เคยคิดมาก่อนว่าจะ แทนที่เงื่อนไข
if ด้วย class เพื่อเปลี่ยนแนวทางการออกแบบ ได้
- เพิ่งมาเข้าใจแนวคิดนี้ช้าไปมากหลังอ่านงานเขียนของ Sandi Metz และเอกสารของ Martin Fowler และยิ่งชัดเจนว่าที่ผ่านมาพลาดอะไรไปมากมาย
-
เหตุผลที่เปิดเผยเรื่องนี้ได้ยาก
- ในการสัมภาษณ์งานตนเองเคยเป็น คนที่มีหน้าที่ประเมินความเข้าใจเรื่อง object-oriented concepts แต่กลับไม่รู้จัก polymorphism จริง ๆ ทำให้ยากจะเปิดเผย
- มันเผยให้เห็นตรง ๆ ว่าช่วงต้นอาชีพ เอนเอียงไปทางการเรียนรู้เครื่องมือมากกว่าหลักการ และก็ยากที่จะเผชิญกับความจริงว่าด้วยพื้นฐานที่ไม่ได้เรียน CS โดยตรง จึงพลาดเรื่องพื้นฐานไปมาก
ประสบการณ์ที่ลืม SQL ไปแล้ว
- ในอดีตเคยมีช่วงที่ตามทำแบบฝึกหัดจากหนังสือ SQL และ เขียน JOIN กับ subquery ได้อย่างคล่องแคล่ว อย่างแน่นอน
- แต่เมื่อทำงานสาย frontend เป็นหลักต่อเนื่องและไม่มีโอกาสใช้ SQL เลย วันหนึ่งก็พบว่า ทักษะทั้งก้อนหายไปจากหัวโดยสมบูรณ์
- ยังพอนึก query พื้นฐานออก แต่ ถ้าต้องอธิบายความต่างระหว่าง left join กับ outer join ก็ต้องกลับไปเปิดเอกสารใหม่
-
เหตุผลที่ยอมรับเรื่องนี้ได้ยาก
- ตอนยังหนุ่มเคยเชื่อว่าแม้เวลาจะผ่านไปหลายปี ความรู้และทักษะก็ยัง ฟื้นคืนได้จากเพียงคำใบ้เล็กน้อย
- ตอนนี้ได้สัมผัสความจริงว่าความสามารถนั้นไม่ได้คงอยู่เหมือนเดิม และยิ่งกระทบใจที่ เทคโนโลยีแรกที่หายไปจากความทรงจำทั้งก้อนคือ SQL
- การเขียนต่อสาธารณะเรื่องความแก่ขึ้นและการเปลี่ยนแปลงของความทรงจำก็ไม่ใช่เรื่องง่าย
ความจริงที่พัฒนามาโดยไม่มี automated tests
- ยอมรับกับตัวเองว่า โค้ดที่ deploy ไปแล้วมากกว่า 95% ทำงานอยู่โดยไม่มี automated tests
- ช่วงต้นอาชีพไม่เคยได้รู้จักแนวคิดเรื่อง testing และในยุค Ember ก็ใช้งานเครื่องมือทดสอบได้ไม่สะดวกนัก
- ช่วงหลังต้องทำงานกับ legacy code บ่อย จึง ไม่มีเวลามากพอสำหรับงานเตรียมโค้ดให้พร้อมต่อการทดสอบ
- มีเพียง subsystem ใหม่ที่สร้างขึ้นเท่านั้นที่พอจะใส่การทดสอบเข้าไปได้
-
เหตุผลที่เปิดเผยเรื่องนี้ได้ยาก
- รู้สึกว่านี่คือ ข้อเท็จจริงที่ร้ายแรงที่สุดต่ออาชีพการงาน ในบรรดาคำสารภาพทั้งหมด
- ตามมาตรฐานของ Uncle Bob โค้ดที่รันใน production โดยไม่มี tests อาจถูกมองว่าเป็น ท่าทีที่ไม่ถึงขั้นจริยธรรม และการเผชิญกับช่องว่างระหว่างมาตรฐานนั้นกับความจริงของตนเองเป็นเรื่องน่ากลัว
- กลัวว่าหากเรื่องนี้ถูกเปิดเผย จะนำไปสู่ การตัดสินเชิงลบในกระบวนการสมัครงาน จนเลื่อนการบันทึกเส้นทางการเรียนรู้ของตนออกไปเรื่อย ๆ
เหตุผลที่เรียน Blazor ต่อไม่สำเร็จ
- เมื่อบริษัทตัดสินใจย้ายจาก Angular ไป Blazor ตนเป็นคนเดียวในทีมที่ไม่มีประสบการณ์ C# จึง รีบเริ่มเรียนเพื่อไล่ให้ทัน
- แต่ไม่กี่เดือนต่อมาบริษัทก็ยกเลิกการตัดสินใจนั้น ทำให้ แรงจูงใจในการเรียนหายไปทั้งก้อน และสุดท้ายก็อ่านหนังสือไม่จบ
- เดิมที C# หรือ .NET ก็ไม่ใช่ภาษาที่อยากใช้ใน side project อยู่แล้ว และเรื่องนี้ก็สะท้อนชัดว่าที่เรียนไปนั้นเรียน เพื่อการทำงานเท่านั้น
-
เหตุผลที่เขียนเรื่องนี้ได้ยาก
- ในบทความก่อนหน้าเคย สัญญาไว้ด้วยตัวเองว่าจะเขียนภาคต่อ และเมื่อทำตามสัญญาไม่ได้ การไปเขียนเรื่องอื่นก็ยิ่งรู้สึกอึดอัดขึ้นเรื่อย ๆ
- เพราะบทความเกี่ยวกับ Blazor มียอดเข้าชมสูง จึง กลัวว่าการยอมรับว่าเปลี่ยนทิศทางแล้วจะดูเหมือนความพ่ายแพ้
ความรู้สึกที่อยากใช้ Ruby มากกว่านี้
- Ruby ยังคงเป็นภาษาที่สบายมือและสนุกที่สุด และเป็นภาษาที่มักหยิบมาใช้อย่างเป็นธรรมชาติใน ตัวอย่างโค้ด, โอเพนซอร์ส, kata และ hackathon
- แต่ตั้งแต่ปี 2013 เป็นต้นมา ไม่เคยได้รับเงินเดือนจากการเขียน Ruby แม้แต่ครั้งเดียว และในงานประจำกลับใช้ภาษาอย่าง TypeScript แทน
- เพราะชอบเพื่อนร่วมงานที่ได้ร่วมงานด้วยในหลายบริษัทมาก จึงต้อง ยอมประนีประนอมเรื่องภาษาเพื่อเลือกคนที่อยากทำงานด้วย ต่อไป
- อยากใช้เวลาหลังเลิกงานและวันหยุดกับ Ruby แต่เพราะภาระและเป้าหมายการเรียนรู้อื่น ๆ เบียดเข้ามา จึงยังต้องอยู่กับ ความจริงที่แทบไม่มีเวลาให้ Ruby อย่างเพียงพอ
-
เหตุผลที่เปิดเผยเรื่องนี้ได้ยาก
- ผู้จัดการและ CTO อ่านบล็อกนี้อยู่ จึงกลัวว่าการพูดว่าอยากใช้ Ruby มากกว่านี้จะ ถูกตีความว่าเป็นสัญญาณว่าจะลาออก
- อีกด้านหนึ่งก็ไม่อยากถูกมองว่าเป็นคนที่พยายามยัดเยียดภาษาที่ไม่คุ้นเคยให้บริษัท
ประสบการณ์ถูก cyberbullying ที่ยังเจ็บแม้เป็นผู้ใหญ่แล้ว
- เมื่อตนส่ง patch เล็ก ๆ ที่สร้างด้วย LLM ให้กับโปรเจกต์โอเพนซอร์ส และแชร์ประสบการณ์นั้นในฟอรัมออนไลน์
ก็ต้องเผชิญกับการโจมตีส่วนบุคคลอย่างรุนแรง เช่น ไร้ความสามารถ, น่าขยะแขยง, เป็นภัยคุกคาม
- การโจมตีไม่ได้หยุดอยู่แค่ในเว็บไซต์ แต่ลุกลามไปถึง เว็บไซต์อื่น, อีเมล, SMS และโทรศัพท์ จนรู้สึกโดยตรงว่าไม่ปลอดภัย
- ได้ขอให้ผู้ดูแลฟอรัมลบชื่อจริงออก แต่กลับกลายเป็นว่า มี PII เพิ่มขึ้นในโปรไฟล์เสียอีก
และยังต้องเจอกับสถานการณ์ที่มี ข้อความเท็จว่าตนแต่งเรื่องการติดต่อจากภายนอกขึ้นมา ถูกปักไว้ถาวร
- สุดท้ายจึงไม่มีทางเลือกนอกจากปิดการใช้งานบัญชีและออกจากเว็บไซต์
-
เหตุผลที่เขียนเรื่องนี้ได้ยาก
- การคุกคามที่ยืดเยื้อหลายวันคือ ประสบการณ์ออนไลน์ที่เป็นพิษที่สุดเท่าที่เคยเจอ และผลกระทบยังคงอยู่จนถึงตอนนี้
- ยังมี ความกลัวว่าถ้าเล่าเรื่องนี้ออกสาธารณะ ผู้ก่อเหตุก็อาจกลับมาตามรังควานอีก
- ยิ่งพูดยากขึ้นไปอีกเมื่อคิดว่าข้อมูลเท็จที่ยังค้างอยู่ในโปรไฟล์นั้น อาจส่งผลเสียต่อการจ้างงาน
มุมมองว่า SaaS team ไม่จำเป็นต้องมี ‘process พิเศษ’
- ในอุตสาหกรรมซอฟต์แวร์มี process ที่ถูกขัดเกลามาแล้วหลายทศวรรษ
และแนวทางอย่าง Agile, Lean, Kanban, XP ก็ล้วนเป็น โครงสร้างที่ผ่านการพิสูจน์มาแล้ว
- จึงค่อย ๆ เชื่อโดยธรรมชาติว่า ความสามารถที่มีจำกัดของบริษัทควรถูกใช้ไปกับการพัฒนาผลิตภัณฑ์ มากกว่าการประดิษฐ์ process ใหม่
-
เหตุผลที่พูดเรื่องนี้ได้ยาก
- เวลาจะเขียนอะไร มักมีนิสัย เขียนจากหัวข้อที่ตัวเองรู้จักดีจริง ๆ และในกรณีนี้จุดเริ่มต้นก็มาจาก custom software development process ที่เพื่อนร่วมงานในบริษัทเดียวกันเสนอ
- จึงรู้สึกว่ามีความเสี่ยงที่มันจะดูเหมือนบทความที่วิจารณ์เพื่อนร่วมงานหรือไอเดียนั้นต่อสาธารณะโดยตรง
- ชื่นชมคนอย่าง Kent Beck และ Martin Fowler ที่ อธิบายวิธีทำงานร่วมกันที่ดีกว่าได้ โดยไม่พุ่งเป้าโจมตีเพื่อนร่วมงานที่ทำพลาดตรง ๆ
- แต่ตนรู้สึกว่ายังไม่มี sense of balance แบบนั้นดีพอ จึงลังเลที่จะเขียน
วิธีที่ remote work ขัดขวางการทำงานร่วมกันจริง ๆ
- แม้ remote work จะช่วยแก้ปัญหาได้หลายอย่าง แต่ก็ยังสลัดความรู้สึกไม่ได้ว่า การพัฒนาซอฟต์แวร์เองทำได้ดีกว่าเมื่อทุกคนอยู่ร่วมกันในพื้นที่เดียวกัน
- การคุยผ่านวิดีโอคือ การสื่อสารแบบ bandwidth ต่ำและรับรู้อารมณ์ได้ต่ำ ทำให้สูญเสียการรับรู้บริบทโดยรอบและยากขึ้นที่จะจับสัญญาณว่าทีมเมตกำลังลำบาก
- การขอความช่วยเหลือก็รู้สึกเป็นภาระมากขึ้น และการคิดเชิงพื้นที่ด้วยไวท์บอร์ดหรือ sticky notes ก็ แตกสลายได้ง่ายเมื่อย้ายไปอยู่ในเครื่องมือออนไลน์
- ความขัดแย้งยิ่งรุนแรงเร็วขึ้น เพราะคนบนหน้าจอมอนิเตอร์ ถูกมองเป็นศัตรูได้ง่ายกว่า
-
เหตุผลที่เขียนเรื่องนี้ได้ยาก
- หลังโควิด บริษัทกลายเป็นองค์กร remote เต็มตัว และด้วยสิ่งนั้นจึงสามารถสร้างชีวิตที่มี ที่ดิน 27 เอเคอร์และแม้กระทั่งวัวนมสำหรับครอบครัว ได้
- เพราะตอนนี้มีโครงสร้างชีวิตที่ย้ายกลับเข้าเมืองได้ยาก การพูดว่าตนไม่ได้ชอบ remote work จึงให้ความรู้สึกเหมือนจะ สร้างภาพลบต่อทั้งงานปัจจุบันและทุกงาน remote ที่อาจสมัครในอนาคต
แผนหลังจากนี้
- รู้สึกว่าบทความนี้คือ ก้าวแรกอีกครั้งของการก้าวข้ามความกลัว และจากนี้ไปก็วางแผนว่าจะเรียนรู้พื้นฐานต่อไป พร้อมเขียนทุกสิ่งที่ได้เรียนรู้ออกมาอย่างไม่ปิดบัง
- ปิดท้ายด้วยการบอกช่องทาง Mastodon, RSS และ mailing list สำหรับคนที่มีประสบการณ์คล้ายกัน คนที่อยากช่วยเหลือ หรือคนที่อยากติดตามบทความต่อไป
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ฉันเองก็ชอบทำงานที่ออฟฟิศ แต่ไม่ได้หมายความว่าฉันสนับสนุน RTO (การกลับเข้าออฟฟิศ) นั่นเป็นแค่ลักษณะนิสัยของฉัน
ดูเหมือนว่า ความไม่มั่นคงและอาการ impostor syndrome ในอุตสาหกรรมนี้จะทำให้ผู้คนก้าวร้าวกันมากขึ้น ถ้าทุกคนซื่อตรงกันมากกว่านี้ก็น่าจะสบายใจกว่านี้
และถ้าจะสารภาพกันตามตรง ฉันไม่เคยเขียนอะไรด้วย Lisp หรือ Haskell ที่ซับซ้อนกว่า Fibonacci เลย สมองฉันไม่ค่อยทำงานในแนวนั้น
แต่ต้นฉบับกลับเล่าประสบการณ์ของตัวเองราวกับเป็น ความจริงเชิงวัตถุที่ใช้ได้ทั่วไป โดยเฉพาะการใช้สรรพนามบุรุษที่สองที่ให้ความรู้สึกหยิ่งยโส
วิธีการพูด สำคัญพอ ๆ กับเนื้อหา ยิ่งเป็นเรื่องอ่อนไหวอย่างการทำงานระยะไกลก็ยิ่งต้องระวังการใช้ถ้อยคำ
ฉันเองก็เคยต้องทำงานระยะไกลเพราะปัญหาสุขภาพของคนในครอบครัว เลยโกรธเพราะน้ำเสียงของบทความดูเบาหวิวเกินไป
สุดท้ายแล้ว ก่อนจะบอกว่าคนอื่นไวเกินไป ก็ควรย้อนมองก่อนว่าคำพูดของตัวเองส่งผลอย่างไร
เราแก้ปัญหากันผ่านแชตทีมแทนการคุยกันตามทางเดิน และทุกคนก็ช่วยกันอย่างแข็งขัน
ตอนนี้กลับรู้สึกเหมือนเราใช้เครื่องมือกันได้แย่ลงกว่าเดิม
พอพื้นที่ที่พูดแบบไม่เปิดเผยตัวตนน้อยลง ก็เกิด วัฒนธรรมที่พูดอย่างอิสระได้ยากขึ้น
ตอนนั้นถ้าทางนี้ไม่เวิร์กก็แค่เดินไปคุยกับคนข้าง ๆ แต่ตอนนี้ถ้าไม่เวิร์กก็คือจบ
เพราะอย่างนั้นผู้คนเลยโทษความโดดเดี่ยวว่าเป็นความผิดของการทำงานระยะไกล
ตอนนี้มีคนที่ถูกขัดเกลาทางสังคมมากกว่าเดิม จึงอ่อนแอกับการสื่อสารแบบอะซิงก์
เพราะความหนาแน่นของการอ่าน สัญญาณที่ไม่ใช่คำพูด ต่ำกว่า เลยทำให้เบาะแสทางสังคมหายไปมาก
นักพัฒนาหลายคนกำลังเดินตาม เส้นทางอาชีพมากกว่าความสนใจ
ฉันเรียน SQL ใหม่ตั้งสามรอบ เทคโนโลยีเปลี่ยนตลอดเลย จำทุกอย่างไม่ได้
สิ่งสำคัญไม่ใช่ไวยากรณ์ แต่คือ ความสามารถในการแก้ปัญหาและการทำงานร่วมกัน
ฉันคิดว่า AI มาแทนสิ่งนี้ได้ยาก
มันมี ผลของการแพร่กระจายของสมาธิ พื้นที่ทำงานร่วมกันช่วยเพิ่มประสิทธิภาพได้
ประตูคือเครื่องมือที่ดีที่สุดในการควบคุมทั้งการทำงานร่วมกันและการจดจ่อ
มันเป็นสัญญาณที่ชัดเจนกว่าสถานะ ‘away’ แบบออนไลน์มาก
การ บังคับเรียกคนอื่นเข้าออฟฟิศ เพื่อให้ใครบางคนมีสมาธิ ถือว่าไร้มนุษยธรรม
ไม่ใช่ว่าการทำงานระยะไกลไม่ดี แต่อาจเป็นเพราะผู้เขียนเคยทำงานใน บริษัทที่มีระบบสนับสนุนแย่ ก็ได้
ฉันเองก็พูดว่า “ไม่รู้” บ่อย ๆ และคิดว่านี่เป็นลักษณะของคนที่มี EQ สูง
ตอน live coding ด้วย Kotlin ฉันดันนึก ไวยากรณ์ของ switch ไม่ออกจนเสียอาการ
มันทำให้ตระหนักว่าแม้แต่ภาษาที่ใช้ทุกวันก็ลืมได้ในพริบตา
ตัวแนวคิดอยู่ได้นาน แต่ไวยากรณ์รายละเอียดหายไปเร็วมาก
แต่เอาเข้าจริง บรรยากาศตอนนี้กลับทำให้แม้แต่การพูดถึงความกังวลนั้นก็ยังยาก
ฉันเองก็สนุกกับการเขียนโค้ดด้วย Claude แต่ก็กลัวไปพร้อมกัน
ถ้าเราเป็น คนรุ่นที่เข้าใจแก่นของการเปลี่ยนแปลงที่กำลังมาได้ดีที่สุด เราก็ควรคุยเรื่องนี้กัน
ปัญหาคือ มันอาจเป็นแค่ การเพิ่มผลิตภาพให้คนที่ไม่มีทักษะ เท่านั้น
แต่ถ้าบริษัทเริ่มใช้ AI เป็นผู้จัดการ บทบาทของนักพัฒนาที่เป็นมนุษย์ก็จะยิ่งหดแคบลง
เราควรเริ่มเตรียมตัวเปลี่ยนไปทำบทบาทอย่าง ที่ปรึกษาด้านประสิทธิภาพ AI ตั้งแต่ตอนนี้