Fast - พลังของซอฟต์แวร์ที่รวดเร็ว

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

---

อุตสาหกรรมซอฟต์แวร์ที่ไม่ค่อยเรียกร้องความเร็ว

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

ข้อจำกัดของซอฟต์แวร์ที่ช้า

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

ผลลัพธ์ของซอฟต์แวร์ที่รวดเร็ว

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

ความเร็ว ความเรียบง่าย และสมาธิ

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

ความพยายามที่ซ่อนอยู่เบื้องหลังการทำให้เร็ว

• การสร้างซอฟต์แวร์ที่รวดเร็วต้องอาศัย การเพิ่มประสิทธิภาพฝั่งแบ็กเอนด์ที่ซับซ้อน
• ที่ Cash App มีความพยายามจะ เพิ่มเฉพาะขั้นตอนที่จำเป็นจริง ๆ ในเส้นทางการใช้งานของผู้ใช้ โดยจัดการความซับซ้อนไว้ภายในระบบ
• Instagram เริ่ม อัปโหลดทันทีพร้อมกับที่ผู้ใช้พิมพ์คำบรรยายภาพ ทำให้รู้สึกว่าอัปโหลดเสร็จในทันที
• ความเร็วไม่ใช่เพียงความสำเร็จทางเทคนิค แต่เป็น ผลลัพธ์ของการจัดลำดับความสำคัญและสมาธิที่แน่วแน่

ความเร็วคือความสนุกและแรงจูงใจ

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

สัมพัทธ์ของความเร็ว

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

แหล่งอ้างอิง

• มีบทความด้านล่างนี้ที่เป็นแหล่งข้อมูลเพิ่มเติมที่มีประโยชน์เกี่ยวกับความเร็ว
  • Patrick Collison: https://patrickcollison.com/fast
  • Charlie Marsh: https://notes.crmarsh.com/python-tooling-could-be-much-much-faster
  • Paul Graham: https://www.paulgraham.com/growth.html

[GN⁺]

ความคิดเห็นใน Hacker News

• รู้สึกขอบคุณมากที่ YCom รักษาอินเทอร์เฟซของ HN ให้เร็วและใช้งานได้ดีมาโดยตลอด เคยมีประสบการณ์กับ Slashdot ที่อ้างว่าเป็น "modern UI" แล้วเปลี่ยนอินเทอร์เฟซใหม่หมด กลายเป็นมีพื้นที่ว่างมหาศาลและโครงสร้างที่กวาดตาอ่านได้ยาก เลยเลิกใช้ทันที ทั้งที่เมื่อก่อนเป็นเว็บที่อ่านทุกวัน
  • ความหนาแน่นของข้อมูลและการหาสิ่งที่ต้องการให้เจอได้เร็ว เป็นแนวคิดที่ตรงข้ามกับ "engagement" อย่างสิ้นเชิง ปกติหลายเว็บจงใจทำให้ซับซ้อนเพื่อดันตัวเลขเวลาที่ผู้ใช้อยู่บนเว็บ แล้วเอาไปขายกับผู้ลงโฆษณา หน้าเว็บถูกทำให้โหลดช้าโดยตั้งใจเพื่อให้กดพลาดและชักจูงให้เกิด "conversion" ความจริงคือโลกนี้การหลอกคนทำเงินได้มากกว่าการยึดผู้ใช้เป็นศูนย์กลาง
  • HN เป็นเว็บที่เปิดไว้เพื่อตรวจว่าอินเทอร์เน็ตยังต่อได้อยู่ไหม ท่ามกลางเว็บที่ bloated ไปหมด มันเป็นสิ่งที่โดดเด่นจริง ๆ
  • UI ของ HN เองก็ยังควรปรับปรุง โดยเฉพาะบนมือถือ เช่น คอนทราสต์ต่ำ ปุ่มเล็กเกินไปจนกดลำบาก ไม่มี dark mode เป็นต้น ผมมีเวอร์ชันที่คิดว่าเป็น UI ในอุดมคติ ทำด้วย Elm แบบ client-side ล้วน ใช้ HN firebase API อยู่ที่ https://seville.protostome.com/
  • ผมไม่คิดว่า Slashdot พังเพราะ UI คุณค่าที่แท้จริงอยู่ที่คอมเมนต์จากเหล่า SME คุณภาพสูงในยุคแรก ๆ หลังเว็บถูกขายต่อ ก็ดูเหมือนเริ่มถดถอยจากผู้ใช้คุณภาพต่ำ การดูแลที่แย่ และการไหลออกของคนเก่ง ยังแปลกใจอยู่เลยที่เว็บยังไม่ปิด
  • orange site (HN) ยังไม่รองรับแท็ก Markdown สำหรับลิงก์อยู่ดี
• รู้สึกว่า workflow ที่เอา LLM เข้ามาใช้ หลายครั้งในความเป็นจริงกลับช้าลง ฟังก์ชัน "refactor" ใน IDE เสร็จใน 1 วินาที แต่ถ้าโยนให้ AI assistant จะใช้ 30 วินาที และถ้าเป็นแบบ "agent" จะกินเวลา 15 นาที ตัวอย่างเช่น เคยให้ agent เขียนโค้ด HTTP endpoint ตอนแรกคิดว่า "งานหนึ่งวันเสร็จใน 10 นาที" แต่พอกลับมาดู พบว่าลอจิกพันกันไปหมด และการจัดการ error ก็ครึ่ง ๆ กลาง ๆ สุดท้ายเลยต้องเขียนใหม่เองราว 5 ชั่วโมง พร้อมทำเทสต์ให้ดีกว่ามาตรฐานที่ตั้งไว้ และการจัดการ error ก็ออกมาดีกว่าที่มันทำเองด้วย มีงานวิจัยเกี่ยวกับเรื่องนี้เหมือนกัน https://www.reddit.com/r/programming/comments/1lxh8ip/study_finds_that_ai_tools_make_experienced/
  • เคยเขียนเรื่องนี้ไว้หลายรอบแล้ว ผมคิดว่า LLM ที่ไล่ล่าคะแนน benchmark นั้นไปคนละทิศกับความเป็นเครื่องมือเขียนโปรแกรม จากประสบการณ์ของผม มันมีโอกาสผิดค่อนข้างสูง เลยต้องตรวจผลลัพธ์ตลอด ทำให้เสียเวลาคุยโต้ตอบกับ LLM นานขึ้น และคำตอบก็มาช้า จนบ่อยครั้งรู้สึกว่าถ้าทำเองด้วยมือจะเสร็จเร็วกว่า สิ่งที่ผมอยากได้คือ agent ที่คะแนน benchmark แค่ราว 60% ก็พอ แต่ตอบกลับได้ภายใน 1 วินาที
  • สิ่งเดียวที่ LLM ช่วยให้งานผมเร็วขึ้นจริง ๆ คือในบทบาทคล้าย find/replace ขั้นสูงของโค้ด เช่น prompt ให้มันเปลี่ยน "ลอจิกที่เกี่ยวกับ XXX" หลายจุดในโค้ดไปเป็นอีกแบบหนึ่ง มันตอบได้ค่อนข้างดี ช่วยลดงานที่ต้องไล่หาแล้วแก้ทีละจุดเยอะมาก แต่กับโค้ดที่ใหญ่มาก ๆ ยังไม่เคยลอง
  • น่าจะขึ้นอยู่กับสถานการณ์ ถ้าเป็น refactor แล้ว IDE หรือ language server รองรับ มันเร็วกว่าเยอะ แต่กรณีอื่น LLM ก็ช่วยได้ เช่น เมื่อวานผมทำลอจิก normalize URL แบบ MVP ซึ่งมีเคสตรวจสอบเยอะเพราะข้อมูลลูกค้ามี URL หลายรูปแบบ ผมเอาเคสลูกค้าที่เจอบ่อยที่สุดใส่ Claude แล้วขอให้ช่วยสร้าง "minimal spanning test cases" มันให้ผลใน 5~10 วินาที จากนั้นใช้ฟีเจอร์ Opus agent ใน Zed สร้างไฟล์เทสต์ แล้วค่อยตรวจเคส เก็บส่วนที่ไม่จำเป็นออก และปรับลอจิกให้ดีขึ้น วิธีนี้เร็วกว่านั่งทำเองทั้งหมดมาก
  • ได้ยินบ่อยทั้งออนไลน์และออฟไลน์ว่างานระดับ senior เร็วขึ้น 40~60% แต่ก็ยังไม่ใช่ระดับที่ฝากชีวิตไว้กับ AI agent แล้วอู้งานได้ทุกอย่าง
• นี่เป็นเรื่องเล่าจากสมัยเป็นพนักงานใหม่ ที่ทำให้ผมได้ชื่อว่าเป็นวิศวกรซอฟต์แวร์ที่ทำงานเร็ว ตอนนั้นเป็นยุคที่ทั้งความรู้อัลกอริทึมและความสามารถในการอ่านผลลัพธ์จากคอมไพเลอร์สำคัญมาก และเป็นยุคที่ Carmak กับ Abrash กำลังกลายเป็นดาวเด่น ตอนอายุ 22 ผมได้เข้าประชุมกับลูกค้าบริษัทข้ามชาติรายใหญ่เป็นครั้งแรก แล้วถูกชี้ว่าผลิตภัณฑ์ของเราช้า VP ของบริษัทนั้นพูดตรง ๆ ว่า "เร็วขึ้น 1 วินาที เท่ากับเพิ่มกำไรประจำปีให้เรา 1 ล้านดอลลาร์" ผมช็อกมาก นั่นเป็นครั้งแรกที่เห็นการตีมูลค่าเป็นเงินกับเรื่องความเร็วแบบนี้ และมันกลายเป็นช่วงเวลาสำคัญในอาชีพที่ยังติดอยู่ในใจแม้ผ่านไป 20 ปีแล้ว แล้วก็มีวิศวกรอีกคนแซว VP ว่า "ถ้าลดเหลือ 0 วินาทีได้ ก็หาเงินได้ไม่จำกัดเลยไหม" ในห้องไม่มีใครหัวเราะ แต่ผมว่ามันตลกดี
  • จาก 1 วินาทีเหลือ 0 วินาที หรือจาก 2 วินาทีเหลือ 1 วินาที ก็เพิ่มทีละ 1 ล้านดอลลาร์ไม่ใช่เหรอ ทำไมตรรกะถึงกระโดดไปเป็นเงินไม่จำกัดได้ล่ะ
  • สุดท้ายก็อยากรู้ว่าได้ทำให้มันเร็วขึ้นจริงไหม
• ขอเขียนตอบเพราะเห็นด้วยกับประโยคแรกของบล็อกโพสต์ ผู้ใช้ไม่ได้มาบอกนักพัฒนาตรง ๆ ว่า "ช่วยทำให้เร็วหน่อย" แต่ถ้ามันไม่เร็ว พวกเขาก็ไม่เชื่อถืออยู่ดี ถ้า Rust ช้ากว่า Ruby ก็คงไม่มีใครสนใจ Rust ต้องพูดได้ว่า "เร็วกว่า C++" ถึงจะดึงความสนใจได้ บน HN เองก็เหมือนกัน แค่มีจุดขายว่า "เร็ว" ทุกคนก็พร้อมจะตื่นเต้น ถ้าเร็วขึ้นอีกนิดเดียวก็ได้ความสนใจทันที
  • นี่ใช้ได้แค่กับคนกลุ่มเล็ก ๆ ที่เป็นโปรแกรมเมอร์บน HN นักพัฒนาส่วนใหญ่หรือผู้ใช้ทั่วไปไม่ได้สนใจมากนักว่าช้าหรือไม่ ขอแค่ UI ใช้ง่ายก็พอ แม้แต่ data scientist มืออาชีพจำนวนมากก็ยังใช้ Github Desktop ที่ดูเรียบร้อย แทนเครื่องมือ command ที่เร็วจัด
  • ผมว่าข้อสรุปผิดนะ "ความเร็ว" เป็นจุดต่างที่ทรงพลังเมื่อคุณให้ชุดฟีเจอร์เดียวกันได้เร็วกว่า คนอาจแห่ไปหา "X ที่เร็วกว่า X" ก็จริง แต่ก็อาจย้ายไปหาอะไรที่ฟีเจอร์มากกว่า UX ดีกว่า ถูกกว่า หรือดีกว่าในด้านอื่นได้ และต่อให้ช้ากว่าก็ยังมีโอกาสถูกเลือก
  • สำหรับภาษาและ runtime ความเร็วสำคัญมาก แต่เวลาเลือก framework ปัจจัยอื่นอย่างฟีเจอร์หรือความเข้ากันได้สำคัญกว่า หลายคนก็ยังใช้ Electron ทั้งที่ช้า
  • ความจริงคือเราอยู่ในโลกที่แอปจำนวนมาก โดยเฉพาะเว็บแอป ช้ามากมหาศาล การกดอะไรสักอย่างแล้วต้องรอหลายวินาทีกว่าจะมีปฏิกิริยาเป็นเรื่องปกติ ดังนั้นแม้จะพูดว่า "ของเร็วดีที่สุด" แต่โลกจริงกลับตรงข้าม
  • ที่ผู้ใช้ HN ชอบคำว่า 'เร็ว' ก็เพราะเรารู้ว่าเทคโนโลยีส่วนใหญ่ที่ใช้อยู่ตอนนี้ช้าเกินไปมาก และโดยเนื้อแท้แล้วมันทำให้เร็วกว่านี้ได้
• ในทางกลับกัน ถ้าอะไรบางอย่างเร็ว "เกินไป" คนก็อาจสงสัยว่ามันทำงานจริงหรือเปล่า มีกรณีของ TurboTax ที่การวิเคราะห์จริงใช้เวลาไม่ถึง 1 วินาที แต่พอทำหน้าจอโหลดปลอมขึ้นมา ผู้ใช้กลับเชื่อถือและชอบมากกว่า ถึงขั้นต้องทำให้มันดูช้าลงเพื่อให้คนมั่นใจว่า "ได้ตรวจจริงแล้วนะ"
• ความเร็วสำคัญในด้านต้นทุนด้วย ในคลาวด์ที่คิดเงินเป็นวินาที ถ้าไม่ optimize ทุกขั้นตอน ก็ยากจะให้บริการถอดเสียงระดับองค์กรในราคาถูกได้ ตัวอย่างเช่น อิมเมจที่ผมทำมีขนาดเล็กกว่าโอเพนซอร์สตัวถัดไปถึง 2.5 เท่า ซึ่งนำไปสู่ cold boot ที่เร็วขึ้น ต้นทุนต่ำลง และบริการที่ดีขึ้น https://speechischeap.com
  • S3 ช้าหรือเร็ว? จริง ๆ คือเป็นได้ทั้งสองแบบ ถ้ามองเป็น single request มันช้า แต่ถ้ายิงหลาย request แบบขนาน มันก็ให้ความรู้สึกว่าเร็ว สุดท้ายแล้ว 'ความเร็ว' บางครั้งคือเรื่องความอยู่รอด และบางครั้งก็เป็นเรื่องของสุนทรียะ
  • ผมทำตรงกันข้าม คือรันบริการบน consumer hardware เลย ทำให้ถูกกว่าคลาวด์มาก ไม่ต้องกังวลเรื่องขนาดอิมเมจด้วย (bare metal เร็วกว่า) ตอนนี้ให้บริการถอดเสียงฟรีระดับ 20,000 นาทีต่อนาทีอยู่ด้วยซ้ำ (ภายใต้ข้อจำกัด 5 วินาทีต่อ request) และกำลังพัฒนาทางเลือกแบบโอเพนซอร์สกับข้ามแพลตฟอร์มอยู่ https://geppetto.app https://github.com/Mozilla-Ocho/llamafile/tree/main/whisper.cpp https://github.com/cjpais/whisperfile https://handy.computer ถ้าสนใจปฏิวัติบริการถอดเสียงก็ติดต่อมาได้
  • ผมคาดหวังว่าเครื่องมืออย่าง PAPER จะมีขนาดติดตั้งทั้งหมดไม่เกิน 2MB อย่างน้อยบน Linux (รวม cache แล้วก็ยังไม่เกิน) pip อยู่ที่ 10~15MB, pipx ใหญ่กว่านั้น, uv อยู่ที่ 35MB ผมกำลังพยายามทำให้เล็กกว่านี้
  • เร็วไม่ได้แปลว่าเบาและมีประสิทธิภาพเสมอไป หลายครั้งก็แค่ยัดฮาร์ดแวร์ราคาแพงเข้าไปเยอะ ๆ เพื่อให้มันเร็ว
• ทุกครั้งที่เห็นบทความบ่นเรื่องการโอนเงินผ่านธนาคารในสหรัฐฯ ผมต้องเตือนตัวเองว่า ในสหราชอาณาจักรหรือสวิตเซอร์แลนด์ การโอนเงินแทบจะเสร็จทันที ทำไมสหรัฐฯ ถึงช้านักก็ยังสงสัยอยู่
  • ธนาคารท้องถิ่นในสหรัฐฯ แทบไม่มีโปรแกรมเมอร์ของตัวเอง และพึ่งพา "core processor" กันเป็นหลัก ดังนั้นการอัปเกรดระบบจึงช้ามาก การนำ Faster ACH มาใช้ก็ใช้เวลาหลายปี และล็อบบี้ของธนาคารท้องถิ่นก็พยายามเลื่อนเพราะมองว่าเสียประโยชน์ มีบล็อกที่อธิบายเรื่องนี้ไว้ดีมาก แนะนำเลย https://www.bitsaboutmoney.com/archive/community-banking-and-fintech/
  • ACH ช้าเพราะการจัดรอบเวลาและการประมวลผลแบบ batch ตัวการโอนจริงอาจเสร็จทันที แต่โดยมากจะมารวมยอดไปเคลียร์ตอนเที่ยงคืน นี่จึงเป็นเหตุผลว่าทำไม Venmo หรือ Zelle ถึงดังในสหรัฐฯ ในสวิตเซอร์แลนด์เองการโอน IBAN ก็ช้าเหมือนกัน ส่วนการจ่ายเงินแบบเรียลไทม์นั้น TWINT ได้รับความนิยมมากกว่า (ใช้สแกน QR code) ส่วน BACS ของสหราชอาณาจักรก็ช้าด้วยเหตุผลคล้ายกัน
  • สหรัฐฯ มีระบบโอนเงินแบบเรียลไทม์อยู่จริง 2 ระบบคือ RTP และ FedNow โดยมีธนาคารที่เข้าร่วมเพิ่มขึ้นเรื่อย ๆ https://real-timepayments.com/Banks-Real-Time-Payments.html เมื่อก่อนก็สามารถจ่ายค่าธรรมเนียมเล็กน้อยเพื่อโอนทันทีผ่านเครือข่ายบัตรเครดิตได้ แต่บัตรเครดิตมีเรื่องการค้ำประกันและกฎการคืนเงินที่ต่างกัน และหากเกิดการฉ้อโกง ธนาคารก็เสียหายมากกว่า
  • เรื่องนี้กลับมีข้อดีต่อผู้บริโภคด้วย เช่น ถ้ามีการหักเงินอัตโนมัติจากบัญชีที่เงินไม่พอ ธนาคารจะส่งอีเมลแจ้งหลายครั้ง ถ้าเป็นแบบเรียลไทม์คงเกิดปัญหาทันที แต่ตอนนี้เรายังมีเวลารับแจ้งแล้วจัดการเอง จึงอาจหลีกเลี่ยงค่าปรับหรือค่าธรรมเนียมได้ เพราะมันไม่ใช่การโอนทันที ธนาคารจึงมีโอกาสเตือน และผมก็มีโอกาสรับมือ
  • patio11 เคยเขียนเรื่องนี้ไว้อย่างละเอียด https://www.bitsaboutmoney.com/archive/the-long-shadow-of-checks/
• บทความนี้น่าสนใจและโยนประเด็นให้คิดเยอะมาก เวลาที่ความเร็ว "รู้สึกได้" จริง ๆ สิ่งสำคัญไม่ใช่ throughput ดิบ แต่คือ "ความเร็วที่รับรู้ได้" เช่น UI responsiveness หรือ input delay ที่ทำให้ใช้งานสบาย นี่จึงเป็นเหตุผลว่าทำไมผมเริ่มชอบ Go มากกว่า Rust Go คอมไพล์เร็วพอจนแทบไม่รู้สึกว่าต้องวัดเวลา ในทางกลับกัน ถ้าบางอย่างช้า ต่อให้ throughput จริงจะสูงแค่ไหนผมก็ไม่ชอบอยู่ดี (เช่น Java startup)
  • ต่อให้เทียบ Go กับ Rust แค่เรื่องความเร็วคอมไพล์ก็สำคัญมากแล้ว Rust build มี dependency จุกจิกหลายอย่างจนโครงสร้างโปรเจกต์เริ่มคล้าย JavaScript ส่วน Go มี dependency น้อยกว่ามากเมื่อเทียบกัน ตรงนี้ผมชอบ
  • ที่นักพัฒนาถกกันแบบนี้ก็ดี แต่สิ่งที่สำคัญจริง ๆ คือ "สำหรับผู้ใช้แล้ว ภาษาไหนเร็วกว่า"
• ต่างจากคำพูดที่ว่า "ในซอฟต์แวร์แทบไม่ได้ยินคำขอให้ทำให้เร็ว" แทบทุกบริษัทที่ผมเคยทำงานให้ต่างให้ความสำคัญสูงสุดกับความเร็วในการตอบสนองของหน้าเว็บและ latency ไม่ว่าจะสตาร์ตอัปหรือองค์กรใหญ่ ความเร็วและ latency เป็นเป้าหมายสำคัญ และมักมีการพิจารณาเสมอว่าผลิตภัณฑ์เร็วแค่ไหน หน้าโหลดเร็วแค่ไหน และมีความหน่วงประหลาด ๆ หรือไม่
  • จากประสบการณ์ตรง บริษัทส่วนใหญ่ที่ผมเคยอยู่ (6 จาก 8 แห่ง) แทบไม่ให้เวลาเพื่อ optimize performance เลย ผมต้องแอบทำเองตลอด แม้แต่ที่ที่คอยวัด latency แล้วบอกว่าสำคัญ พอถึงเวลาจริงก็ยังโดนงานฟีเจอร์ใหม่เบียดตกไปอยู่ดี
  • หลายที่หมกมุ่นกับการทำให้ผลการค้นหาออกเร็วขึ้น แต่กลับไม่ค่อยใส่ใจกับเวลา render หน้า หรือขนาดข้อมูลที่ส่งลงไปให้ผู้ใช้
• นี่เป็นสิ่งที่เจอซ้ำ ๆ จากหลายที่ทำงาน คือคนส่วนใหญ่มักประเมินคุณค่าที่แท้จริงของความเร็วต่ำเกินไป เพราะคิดแค่ว่า "ทำ workflow เดิมให้เร็วขึ้น" ตัวอย่างเช่น หลายคนคิดว่าการเร่งการทดลองขนาดใหญ่ที่ปกติรันข้ามคืนไม่ได้ช่วยมาก แต่ถ้าคุณเร่งมันได้แบบก้าวกระโดด จนสามารถรันหลายรอบในตอนกลางวันได้เลย ผลลัพธ์คือผลิตภาพคนละระดับโดยสิ้นเชิง
  • ผู้คนประเมินต้นทุนของ context switching ต่ำเกินไปมาก หลายคนคิดว่าลดคำสั่งหนึ่งจาก 30 วินาทีเหลือ 3 วินาที ถ้าทำวันละ 10 ครั้งก็แค่ประหยัดได้ 5 นาที แต่ความจริงต้นทุนจากการสลับบริบทมันสูงกว่านั้นมาก
  • ทุกครั้งที่ CI pipeline กินเวลาหลายชั่วโมง ผมจะคิดเสมอว่าถ้ามันจบใน 20 นาที ผมคงแก้แม้แต่ warning เล็ก ๆ จาก lint ได้ทุกครั้งไปแล้ว