เรื่องเล่าจากการพัฒนาซอฟต์แวร์ตลอด 25 ปี

 (susam.net)
17 คะแนน โดย GN⁺ 2026-02-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ย้อนมอง เส้นทางการเขียนโปรแกรมตลอด 25 ปี ที่เริ่มมาตั้งแต่สมัยมหาวิทยาลัย โดยเน้นไปที่ผู้คน ความสัมพันธ์ และประสบการณ์ มากกว่าตัวเทคโนโลยีเอง
  • 10 นาทีของการดูซอร์ส HTML ที่บังเอิญได้เรียนรู้ในห้องคอมพิวเตอร์ของมหาวิทยาลัย กลายเป็นจุดเริ่มต้นของการสร้างและดูแลเว็บไซต์ส่วนตัวมาอย่างยาวนาน
  • การทดลองเล็ก ๆ ที่กระโดดไปยังรีเซ็ตเวกเตอร์ของโปรเซสเซอร์ 8086 เพื่อรีบูตระบบ ได้สลักแนวทางการเรียนรู้แบบ เริ่มจากความอยากรู้อยากเห็น ไว้ให้เพื่อนคนหนึ่ง
  • ทั้ง การดีบักโค้ดสปาเกตตี, ความล้มเหลวจริงของแอนิเมชันบนเซ็ตท็อปบ็อกซ์, และ ผลงานระดับสูงในการแข่งขัน CTF ล้วนสะท้อนการลองผิดลองถูกและการเติบโตที่เกิดขึ้นซ้ำ ๆ
  • เมื่อเวลาผ่านไป จึงรับรู้ถึงการเปลี่ยนแปลงที่ความสามารถในการแก้ปัญหาไม่ได้ถูกมองว่าเป็นพรสวรรค์ แต่เป็น ผลลัพธ์ของประสบการณ์ และสรุปได้ว่า สิ่งที่หลงเหลือในท้ายที่สุดคือ ความเป็นมืออาชีพ จริยธรรม และท่าทีที่มีต่อผู้คน

จุดเริ่มต้นของเว็บ: การดูซอร์ส(Viewing the Source)

  • ทันทีหลังเข้าเรียนมหาวิทยาลัยในปี 2001 ระหว่างนั่งท่องเว็บในห้องคอมพิวเตอร์ช่วงเย็น ก็ได้พิมพ์ susam.com ลงในแถบที่อยู่และพบกับเว็บเป็นครั้งแรก
  • รุ่นพี่ที่นั่งดูอยู่ข้าง ๆ เปิดเมนู View > Source ของ Internet Explorer แล้วอธิบายว่าเว็บไซต์คือข้อความที่เขียนด้วย HTML
  • เขาเปิด Notepad แล้วพิมพ์ HTML ง่าย ๆ อย่าง <BODY><FONT COLOR="RED">HELLO</FONT></BODY> ให้ดู พร้อมสาธิตว่ามันแสดงผลในเบราว์เซอร์อย่างไร
    • ในตอนนั้นแท็ก FONT ยังถูกใช้อย่างแพร่หลาย และการเขียนแท็ก HTML เป็น ตัวพิมพ์ใหญ่ ก็เป็นธรรมเนียมทั่วไป
  • เขาแนะนำสั้น ๆ ว่าเว็บทำงานอย่างไร พร้อมโชว์การเปลี่ยนขนาดและสีตัวอักษร การจัดกึ่งกลาง และการเปลี่ยนสีพื้นหลัง
  • แม้จะเป็นคำอธิบายเพียงราว 10 นาที แต่ก็ทำให้เวิลด์ไวด์เว็บดูน่าพิศวงน้อยลง และน่าสนใจขึ้นมากในทันที
  • เมื่ออธิบายเสร็จ รุ่นพี่คนนั้นก็ ไม่ได้คืนที่นั่งให้ แต่ใช้เว็บต่อทันที ส่วนผมต้องกลับหอพักเพราะที่นั่งมีไม่พอ
  • โดเมน susam.com ถูกธุรกิจเกี่ยวกับอาหารตุรกีใช้ไปแล้วจึงจดทะเบียนไม่ได้ และต่อมาจึงเลือกใช้ โดเมน .net
  • การพบกันสั้น ๆ ครั้งนั้น กลายเป็นจุดเริ่มต้นของการเดินทางอันยาวนานในการสร้างและดูแลเว็บไซต์ส่วนตัวหลังจากนั้น

รีเซ็ตเวกเตอร์(The Reset Vector)

  • เป็นเรื่องสมัยเรียนมหาวิทยาลัย ตอนกำลังเขียนโปรแกรมควบคุมลิฟต์ด้วยภาษาแอสเซมบลีบนเครื่อง MS-DOS ที่ใช้ Intel 8086 ในห้องคอมพิวเตอร์
  • จู่ ๆ ก็นึกถึงสิ่งที่เรียนในชั้นว่าพอ 8086 ถูกรีเซ็ต ค่า CS:IP จะถูกตั้งเป็น FFFF:0000
  • จึงสงสัยว่าถ้าลองกระโดดไปยังแอดเดรสนั้นใน DEBUG.EXE จะเกิดอะไรขึ้น เลยทดลองด้วยตัวเอง
    • ทันทีที่รันคำสั่ง C:\>DEBUG -G =FFFF:0000 ระบบก็รีบูตทันที
  • เพื่อนที่ได้ที่หนึ่งของภาคเรียนทุกเทอมซึ่งนั่งดูอยู่ด้วย ตกใจมากและถามว่าคิดแบบนั้นได้อย่างไร
  • หนึ่งสัปดาห์ต่อมา เขามาหาที่หอพักและยอมรับว่า แม้จะได้คะแนนอันดับหนึ่งมาตลอด แต่ตัวเองไม่มี ความอยากรู้อยากเห็นที่จะนึกถึงข้อเท็จจริงเล็ก ๆ แล้วลงมือทดลองเอง แบบนี้
  • เขาประกาศว่าจะเลิกตั้งเป้าเป็นที่หนึ่ง และจะหันไปเรียนแบบ สำรวจ ทดลอง และสนุกกับสิ่งที่เรียนรู้ แทน
  • หลังจากนั้นเขายังคงทำคะแนนได้ดีอยู่เสมอ แต่ก็ไม่เคยได้ที่หนึ่งอีกเลย
  • การทดลองครั้งเดียวที่กระโดดไปยังจุดเริ่มต้นการรีเซ็ตของโปรเซสเซอร์ กลายเป็น จุดเปลี่ยนที่ทำให้ทัศนคติการเรียนรู้ของใครบางคนเปลี่ยนจากการแข่งขันไปสู่การสำรวจ

การโจมตีแบบคนกลางและงานวิศวกรรมแรก(Man in the Middle)

  • หลังเรียนจบมหาวิทยาลัย ได้เข้าทำงานที่แรกในทีมสนับสนุนด้านเทคนิคของผลิตภัณฑ์ e-banking และรับหน้าที่รันตัวติดตั้งเพื่อแจกจ่ายคอมโพเนนต์บางตัว
  • ตัวติดตั้งที่เขียนด้วย Python มักล้มเหลวบ่อย เพราะตั้งสมมติฐานต่อสภาพแวดล้อมปลายทางไว้อ่อนแอ ในสัปดาห์แรกจึงปรับให้ตัวติดตั้งเสถียรขึ้นและเขียน คู่มือผู้ใช้แบบทีละขั้นตอน
    • คู่มือผู้ใช้กลับได้รับเสียงตอบรับดีกว่าการปรับปรุงโค้ดเสียอีก
  • เมื่อเริ่มรู้สึกถึงข้อจำกัดของงานซัพพอร์ตที่ซ้ำ ๆ ก็ต้องการไปทำงานพัฒนาที่จริงจังกว่านี้ จึงขอย้ายทีมหลายครั้ง
  • ในที่สุดก็ได้รับการแนะนำให้ไปสัมภาษณ์กับ ทีม Archie ในอีกเมืองหนึ่ง
  • ทีม Archie รับผิดชอบ เว็บเฟรมเวิร์กและคอมโพเนนต์สถาปัตยกรรมหลัก ที่รองรับผลิตภัณฑ์ e-banking ทั้งระบบ
    • มีการพัฒนา API routing, การยืนยันตัวตนและการกำหนดสิทธิ์, การจัดการคุกกี้ ฯลฯ ขึ้นเองด้วย Java Servlet และ JSP
    • เป็นโครงสร้างที่สร้างขึ้นก่อนการมาถึงของโอเพนซอร์สเฟรมเวิร์กอย่าง Spring หรือ Django
    • เนื่องจากใช้ในสภาพแวดล้อมของธนาคาร จึงต้องผ่าน การทดสอบความปลอดภัยอย่างเข้มงวดและการตรวจสอบตามรอบ
  • ในการสัมภาษณ์ทางโทรศัพท์ปี 2006 ตอบคำถามด้านความปลอดภัยอย่าง SQL injection และการรับมือ XSS ได้ แต่ยอมรับตามตรงว่าเพิ่งเคยได้ยินคำว่า MITM(การโจมตีแบบคนกลาง) เป็นครั้งแรก
  • ผู้สัมภาษณ์อธิบายว่า “จงศึกษา PKI และ MITM ให้ละเอียด เรากำลังจะเพิ่มฟีเจอร์ลายเซ็นดิจิทัลในผลิตภัณฑ์ธนาคารสำหรับองค์กร”
  • หลังจากนั้นใช้เวลาหลายสัปดาห์อ่านเอกสาร RFC รวมถึงศึกษา โครงสร้างพื้นฐานกุญแจสาธารณะ(PKI) และมาตรฐานการเข้ารหัสแบบกุญแจสาธารณะอย่างเข้มข้น
    • ตอนแรกมันยากและกดดันมาก แต่เมื่อเวลาผ่านไปก็เริ่มเข้าใจว่าเป็นระบบที่มีเหตุผลและประณีตมาก
  • หลังย้ายไปเมืองใหม่ได้ราวหนึ่งเดือน ก็พัฒนาฟีเจอร์ลายเซ็นดิจิทัลเสร็จโดยใช้ไลบรารีโอเพนซอร์ส Bouncy Castle
  • หลังจากนั้นยังได้พัฒนาส่วนสำคัญอีกหลายจุดของผลิตภัณฑ์ และสะสมประสบการณ์ที่โค้ดของตัวเองได้เข้าไปอยู่ในระบบขนาดใหญ่ที่มีธนาคารหลายร้อยแห่งและผู้ใช้หลายล้านคนใช้งาน
  • ผู้จัดการเป็น เมนเทอร์ ที่ยอดเยี่ยม และการสนับสนุนจากเขาก็กลายเป็นรากฐานของความมั่นใจมาอีกยาวนาน
    • แม้เวลาจะผ่านไปราว 20 ปี ผลิตภัณฑ์นั้นก็ยังทำงานอยู่ และบางครั้งเมื่อเปิดเครื่องมือนักพัฒนาในเบราว์เซอร์ในฐานะลูกค้า ก็ยังพบร่องรอยโค้ดที่เคยเขียนไว้ในตอนนั้น

โค้ดสปาเกตตี(Spaghetti Code)

  • ราวปี 2007~2008 ได้เข้าร่วมงานพิสูจน์แนวคิด(PoC) สำหรับพัฒนาวิดเจ็ตบน OpenTV set-top box
  • ระหว่างเขียนโค้ดในสภาพแวดล้อมภาษา C ที่ถูกลดทอนอย่างมาก ก็พบปัญหาว่าวิดเจ็ตล่มเป็นบางครั้ง
  • เนื่องจากตรรกะที่พันกันซับซ้อนและการใช้ pointer อย่างไร้ระเบียบ โค้ดจึงกลายเป็น โค้ดสปาเกตตี ที่แม้แต่ตัวเองก็ยังเข้าใจได้ยาก
  • จึงส่งโค้ดในรูปแบบ tarball ให้กับหัวหน้าทีมและสถาปนิกของทีมสี่คน
  • ปัญหาที่แก้ไม่ตกอยู่หลายชั่วโมง สถาปนิกกลับชี้ได้อย่างแม่นยำว่าเป็นบั๊ก pointer ในไฟล์หนึ่ง ภายในเวลาเพียง 5 นาที หลังได้รับโค้ด
    • พอแก้บรรทัดนั้นเพียงบรรทัดเดียว อาการล่มก็หายไปทันที
  • ประสบการณ์นี้ทำให้ตระหนักว่า แม้เคยคิดว่าตัวเองเก่งพอสมควร แต่ หนทางสู่การเป็นนักพัฒนาซอฟต์แวร์ที่ดีนั้นยังอีกไกล
  • หลังจากเติบโตต่อมาอีกหลายปี ทุกวันนี้ก็มีความสามารถในการรับมือกับความซับซ้อนของซอฟต์แวร์มากกว่าสมัยนั้นอย่างเทียบกันไม่ได้

วิดเจ็ตโทรทัศน์แบบแอนิเมชัน(Animated Television Widgets)

  • ในอีกโปรเจ็กต์หนึ่งช่วงเวลาเดียวกัน ได้รับหน้าที่พัฒนาวิดเจ็ตสำหรับแพลตฟอร์ม set-top box ที่ใช้ Java ME(Micro Edition)
  • โปรเจ็กต์ดำเนินไปในโครงสร้างที่มีผู้ร่วมมือสามฝ่าย
    • บริษัทของเรา: ทำหน้าที่เป็น ผู้ขายซอฟต์แวร์
    • บริษัทโทรคมนาคมรายใหญ่: ถือแบรนด์ของ บริการโทรทัศน์ DTH
    • ผู้ผลิต set-top box: จัดหาฮาร์ดแวร์และแพลตฟอร์ม
  • ฝั่งบริษัทโทรคมนาคมสอบถามว่าสามารถใส่ เอฟเฟกต์แอนิเมชัน แบบเลื่อนเข้า-เลื่อนออกให้วิดเจ็ตได้หรือไม่
  • ในการประชุมกับพาร์ตเนอร์ ผู้ผลิต set-top box ยืนยันหนักแน่นว่า set-top box รุ่นนั้นไม่รองรับแอนิเมชัน และ เป็นไปไม่ได้
  • ผมมองว่าถ้าวาดวิดเจ็ตได้ ก็ย่อมทำแอนิเมชันได้ด้วยการขยับตำแหน่งทีละนิดแล้ววาดซ้ำไปเรื่อย ๆ
    • ด้วยหลักการนี้จึงสร้าง เดโมที่ทำงานได้บนอีมูเลเตอร์
  • พอแชร์เดโมในที่ประชุมครั้งถัดไป ฝั่งผู้ผลิต set-top box ก็แสดงปฏิกิริยารุนแรงและขอให้ หยุดงานทันที
    • เพราะมันขัดกับจุดยืนที่พวกเขาเคยประกาศอย่างเป็นทางการว่าเป็นไปไม่ได้
  • ตัวแทนจากบริษัทโทรคมนาคมจึงเข้ามาแทรกว่า “ในเมื่อพวกเขาทำฟีเจอร์ที่คุณบอกว่าเป็นไปไม่ได้ให้เห็นอยู่ตรงหน้า
    จะเป็นไปได้อย่างไรที่ในฐานะผู้ผลิต คุณกลับไม่รู้สมรรถนะของผลิตภัณฑ์ตัวเอง” พร้อมตำหนิอย่างหนัก
  • แต่เมื่อทดสอบบนฮาร์ดแวร์จริง กลับพบว่าแอนิเมชันที่ลื่นไหลบนอีมูเลเตอร์ แสดงผลบนหน้าจอทีวีด้วย อาการกระตุกอย่างชัดเจน
  • ตลอดหลายสัปดาห์ได้ลองทั้งปรับเฟรมเรต เปลี่ยนวิธีบัฟเฟอร์ และปรับปรุงลูปการเรนเดอร์
    • จนเห็นชัดถึงข้อจำกัดที่ สมรรถนะของฮาร์ดแวร์ฝังตัว ไม่สามารถรองรับทั้งการคำนวณและการเรนเดอร์ได้
  • สุดท้ายบริษัทโทรคมนาคมตัดสินว่า “ถ้าแอนิเมชันออกมาไม่ดี ก็ไม่มีเสียยังดีกว่า” และ ยกเลิกฟีเจอร์นี้ไปทั้งชุด
  • ผลลัพธ์สุดท้ายจึงยืนยันว่า การประเมินของผู้ผลิต set-top box นั้นถูกต้องในเชิงความเป็นจริง

พรอันดีงาม(Good Blessings)

  • ในปี 2009 หลังทำงานที่ RSA Security ได้ราวหนึ่งปี ก็เริ่มมองหางานที่ท้าทายทางปัญญามากขึ้นและเน้นคณิตศาสตร์กับอัลกอริทึม
  • Dr. Burt Kaliski หัวหน้านักวิทยาศาสตร์ของ RSA Laboratories เสนอนัดคุยด้วยตัวเองเพื่อให้คำแนะนำเรื่องทิศทางอาชีพ
  • จากคำแนะนำนั้น จึงได้เข้าร่วมทีมใหม่และทำงานอยู่ที่นั่นต่อมา 6 ปี
    • การสร้าง parser generator, การกำหนดและพัฒนาภาษารูปแบบ
    • การพัฒนาเอนจินทำดัชนีและคิวรีสำหรับฐานข้อมูลระดับเพตะไบต์
    • ได้เรียนรู้สิ่งใหม่เกือบทุกวัน และเป็นช่วงเวลาที่สนุกที่สุดในอาชีพ
  • หลายปีต่อมา เมื่อได้ตระหนักว่าการพูดคุยสั้น ๆ ครั้งนั้นเปลี่ยนเส้นทางอาชีพของตัวเองไป จึงส่งอีเมลขอบคุณไปหาเขา
  • ในอีเมลตอบกลับของ Dr. Kaliski มีประโยคดังนี้
    • เป้าหมายของเขาคือการส่งต่อกำลังใจให้คนที่กำลังเติบโต เช่นเดียวกับที่คนอื่นเคยลงทุนกับอาชีพของเขา
    • การส่งต่อพรอันดีงามจากคนรุ่นหนึ่งไปสู่อีกรุ่นหนึ่ง

ตารางคะแนน CTF(The CTF Scoreboard)

  • ในปี 2019 ตอนนั้นไม่ได้เป็นวิศวกรหน้าใหม่วัยยี่สิบต้น ๆ อีกต่อไป แต่เป็น staff engineer ระดับกลางอาชีพ ที่พัฒนาระบบเครือข่ายและฐานข้อมูลระดับล่างด้วย C/C++ มาหลายปีแล้ว
  • เส้นทางอาชีพกำลังเปลี่ยนเข้าสู่ช่วงใหม่ที่ต้องนำการพัฒนา ไมโครเซอร์วิสด้วย Go และ Python
    • การเปลี่ยนผ่านค่อนข้างเป็นธรรมชาติ เพราะก่อนหน้านั้นก็ใช้ Python และ Go มาตลอดผ่านโปรเจ็กต์ส่วนตัว
  • เนื่องในเดือนรณรงค์ความตระหนักด้านไซเบอร์ซีเคียวริตีของเดือนตุลาคม บริษัทจึงจัดการแข่งขัน CTF(Capture the Flag) ภายใน
    • ประกอบด้วยปริศนาทางเทคนิคหลากหลายแบบ เช่น SQL injection, การเข้ารหัสที่อ่อนแอ, binary reversing, การโจมตีแบบ stack overflow exploit เป็นต้น
  • แม้จะรู้สึกกดดันกับการแก้โจทย์ภายใต้การแข่งขันและเวลาจำกัด ก็ยังตัดสินใจเข้าร่วม และภายในราว 8 ชั่วโมงก็ แก้โจทย์ได้ประมาณ 90% จนขึ้นอันดับ 1
  • ระหว่างการแข่งขัน เพื่อนร่วมงานมักแวะมาดูความคืบหน้าและแสดงความประหลาดใจ ทำให้กลายเป็นหัวข้อพูดถึงในออฟฟิศ
  • บังเอิญได้ยินวิศวกรรุ่นน้องสองคนที่เคารพคุยกันถึงผลงานนี้
    • เมื่อคนหนึ่งชื่นชมผลงานอย่างมาก อีกคนตอบว่า “ก็แน่อยู่แล้ว เขาเขียน C มามากกว่าสิบปีนี่นา”
  • ตอนยังหนุ่ม ความสามารถในการแก้ปัญหาแบบนี้มักถูกมองว่าเป็น “ความฉลาด” แต่ตอนนี้กลับรู้สึกได้ถึงความเปลี่ยนแปลงที่มันถูกตีความอย่างเป็นธรรมชาติว่าเป็น ผลของประสบการณ์
  • แม้ความสำเร็จทางเทคนิคจะถูกมองว่าเกิดจากประสบการณ์ แต่จากนี้ไปก็อยากทิ้งความประทับใจที่ดีผ่าน ความเป็นมืออาชีพ จริยธรรม และท่าทีที่มีต่อเพื่อนร่วมงาน

มองย้อนกลับทั้งหมด

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-02-09
ความเห็นจาก Hacker News

  • เมื่อก่อนมีความไว้วางใจว่าถ้ามอบงานให้คนอื่นแล้ว พวกเขาจะจัดการได้ดีเอง
    แต่ทุกวันนี้กลับคาดหวังให้วิศวกรจูเนียร์ออกแบบระบบระดับ Twitter และท่องจำวิธีทำโจทย์ Leetcode
    เรื่องแบบนี้เมื่อก่อนถือว่าเป็นขั้นตอนที่ไร้ประโยชน์ และหวังว่า LLM จะช่วยลบวัฒนธรรมแบบนี้ไปได้

    • มีคนแซวกลับว่า “ถ้า LLM จะลบสิ่งนี้ออกไป งั้นรวมจูเนียร์ด้วยไหม?”
    • ทุกวันนี้การเฉพาะทางหนักขึ้นมาก เช่น ทำแต่ฟรอนต์เอนด์หรือแบ็กเอนด์เท่านั้น หลายคนทำแค่ React หรือแค่ Go

  • ฉันเองก็เริ่มต้นคล้าย ๆ กัน
    ตอนอยู่ประถมปีที่ 3 ฉันเห็นหนังสือ “Make Your Own Web Page! A Guide for Kids” ที่งานหนังสือของโรงเรียน แล้วขอให้แม่ซื้อให้
    ตอนนั้นฉันคิดว่าอินเทอร์เน็ตเหมือนเป็นของสำหรับองค์กรเท่านั้น แต่พอรู้ว่าตัวเองก็สร้างเว็บเพจได้ก็หลงใหลขึ้นมาทันที
    ตอนเรียน HTML ฉันรู้สึกเหมือนตัวเองเป็นแฮ็กเกอร์ และครูก็ตกใจมากจนถึงขั้นโทรหาพ่อแม่
    หลังจากนั้นก็เรียนเขียนโปรแกรมจาก “Sams Teach Yourself C in 24 Hours”, หนังสือ ActionScript สำหรับ Flash MX 2004 และหนังสือ C++
    ตอนนี้ทั้งหมดนั้นช่วยให้ฉันสร้างอาชีพที่ดีได้ และไม่นานมานี้ก็ไปหาหนังสือเล่มนั้นจาก eBay มาอ่านอีกครั้งพร้อมรอยยิ้ม

  • ฉันหลุดขำตรงที่พนักงานบริษัทโทรคมนาคมพูดกับคนดูแลเซ็ตท็อปบ็อกซ์ว่า “หุบปากไปเลย”
    ทั้งสถานการณ์เป็นฉากที่ทั้งเหลือเชื่อและตลกมาก ผู้คนมักหมกมุ่นกับเรื่องไร้สาระจนทำให้ตัวเองลำบาก

    • คนดูแลเซ็ตท็อปบ็อกซ์แค่พูดว่า “บนฮาร์ดแวร์จริงทำให้ลื่นได้ยาก” ก็น่าจะพอแล้ว
      แต่กลับทำให้ตัวเองดูเหมือนคนโง่ไปเอง ถึงอย่างนั้นก็ยังเป็นเรื่องที่สนุกมาก

  • เห็นด้วยกับเรื่องที่บอกว่าตัวติดตั้งที่เขียนด้วย Python มักตั้งสมมติฐานเรื่องสภาพแวดล้อมผิด จนต้องคอยแทรกแซงด้วยมือเสมอ
    ฉันเองก็เสียเวลาไปครึ่งวันกับการตั้งค่า environment สำหรับงาน SDR เหมือนกัน dependency hell ยังอยู่ไม่ไปไหน
    สุดท้ายมันก็ใช้งานได้ แต่ยุ่งเหยิงมากจริง ๆ

    • Python นี่เข้าขั้นหายนะในแง่การแพ็กเป็นไฟล์ executable
      ถ้าเป็นฝั่งเซิร์ฟเวอร์ที่ควบคุมสภาพแวดล้อมด้วยคอนเทนเนอร์ได้ก็ดีอยู่ แต่กรณีอื่นฉันไม่อยากแตะเลย
    • ที่ทำงานเก่าบางแห่งใช้เวลาตั้งค่าสภาพแวดล้อมพัฒนากันถึงสองวัน
      มีทั้งซอฟต์แวร์เชิงพาณิชย์รุ่นเก่าและโปรเจกต์ OSS ที่ถูกปล่อยทิ้งปนกันไปหมด แล้วทุก ๆ สองสามเดือนมันก็พังแบบสุ่มจนงานพัฒนาหยุดชะงัก
      สุดท้ายมีบริษัทหนึ่งเลือกใช้วิธีเปิด EC2 instance ที่อิง AMI แยกให้แต่ละนักพัฒนา แต่แม้แต่ CLI ที่ใช้จัดการสิ่งนั้นก็ยังพังบ่อยมาก
      เป็นยุคสมัยที่ “สนุก” จริง ๆ

  • ตอนนี้ฉันก็เข้าปีที่ 20 ของสายอาชีพแล้ว แต่เพราะทำแต่งานเว็บดีเวลอปเมนต์มา เลยรู้สึกว่าไม่ค่อยมีเกร็ดเล่าสนุก ๆอะไรกับเขา

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

  • ตรงประโยคที่ว่า “กระโดดไปยัง processor reset point” ทำให้นึกว่าไม่ใช่แค่ CPU แต่ทัศนคติในการเรียนรู้ของคนนั้นก็คงถูกรีเซ็ตไปด้วย

    • ฉันอยากรู้จริง ๆ ว่าเขาเจออะไรด้วยตัวเองบ้าง และหลังจากนั้นชีวิตเขาเป็นอย่างไรต่อ

  • ถ้าสนใจ DevOps ขอแนะนำ "Tales from the Machine Room" ของ Davide Bianchi

  • มีคนบอกว่าเมื่อก่อนซื้อโดเมน “susam.com” ไม่ได้ แต่ตอนนี้มีขายอยู่
    อาจซื้อได้ถูกกว่าราคาป้ายด้วยซ้ำ แน่นอนว่า .net ก็ไม่เลว แต่ถ้ามีความผูกพันทางใจก็น่าลองดู
    ขอบคุณที่มาแบ่งปันเรื่องราวดี ๆ

  • ประสบการณ์การทำงานในอุตสาหกรรมซอฟต์แวร์ก่อนยุค LLM เป็นสิ่งที่ต้องเจอด้วยตัวเองถึงจะเข้าใจ