ภาพลวงตาแห่งผลิตภาพ

 (frantic.im)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Bob วิศวกรระดับตำนานของ Facebook เปิดตัว Facebook Groups ได้โดยไม่ต้องมีสภาพแวดล้อมพัฒนาที่ซับซ้อน และทำผลงานได้ต่อเนื่องในแฮกกาธอน
  • เขาใช้เพียง Sublime Text แบบพื้นฐานและล็อก printf โดยสภาพแวดล้อมนั้นมีการเน้นไวยากรณ์ที่ไม่แม่นยำ และไม่มีทั้ง live reloading กับ debugger
  • ขณะที่นักพัฒนารอบตัวมองว่า ชุดเครื่องมือที่ซับซ้อน เช่น Vim syntax highlighting และ snippets, tmux, mosh, คีย์ลัด hphpd, และ Git aliases คือหัวใจของผลิตภาพ
  • การชนะในแฮกกาธอนของ Bob ได้แรงหนุนจาก เซนส์ด้านผลิตภัณฑ์และสัญชาตญาณ หรือความสามารถในการตัดสินใจว่าจะสร้างอะไร มากกว่าการตั้งค่า editor
  • วิธีทำงานแบบใหม่อาจสร้างความเปลี่ยนแปลงได้ แต่ผลลัพธ์ที่แท้จริงท้ายที่สุดมาจาก การแก้ปัญหาที่ถูกต้อง

ความต่างระหว่างเครื่องมือที่ซับซ้อนกับผลงานจริง

  • Bob เป็นทั้งวิศวกรสายผลิตผลงานของ Facebook ผู้เปิดตัว Facebook Groups และบุคคลระดับตำนานที่ส่งมอบผลงานได้ต่อเนื่องในแฮกกาธอน
  • เพื่อนร่วมงานคนหนึ่งที่หมกมุ่นกับเรื่องผลิตภาพในเวลานั้น ใช้ Vim syntax highlighting และ snippets ที่ทำขึ้นเองสำหรับ Hack ซึ่งเป็นภาษาถิ่นของ PHP ที่ Facebook ใช้
    • เขารัน tmux บน mosh และยังตั้งค่าคีย์ลัด hphpd แบบกำหนดเองกับ Git aliases ไว้อีกด้วย
  • วิธีทำงานของ Bob กลับเรียบง่ายมากเมื่อเทียบกัน
    • เขาใช้ Sublime Text โดยไม่ตั้งค่าเพิ่มเติม ทำให้สีของโค้ดเกือบครึ่งหนึ่งแสดงผิด
    • แทนที่จะใช้ live reloading หรือ debugger เขาใส่ printf ลงในโค้ดแล้วรอให้ล็อกแสดงออกมา
  • ในแฮกกาธอนวันนั้น Bob เป็นผู้ชนะ และจำกันได้ว่าสิ่งที่เขาทำคือฟีเจอร์รองรับโพสต์ซื้อขายใน Facebook Groups
    • ฟีเจอร์นี้ต่อมาพัฒนาเป็น Facebook Marketplace

ไม่ใช่จะทำอย่างไร แต่คือจะสร้างอะไร

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

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

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

 
GN⁺ 1 시간 전
ความคิดเห็นจาก Hacker News

  • การแบ่งคนเป็นสองขั้วระหว่าง ช่างฝีมือที่ทะนุถนอมเครื่องมือ กับคนที่หมกมุ่นกับเครื่องมือนั้นเป็นเรื่องผิด เครื่องมือที่ดีไม่ใช่ของเล่น แต่เป็นวิธีไปสู่เป้าหมาย และผมเองก็เคยใช้เวลาหลายวันทำเชลล์สคริปต์ ฟังก์ชัน Emacs เครื่องมือจัดวางหน้าต่าง ฯลฯ ให้เข้ากับเวิร์กโฟลว์ของตัวเอง
    ผลคือ syntax highlighting, การนำทางและวิเคราะห์โค้ด, การจัดวางหน้าจอ, การจัดการ Git ทำได้ด้วยการกดแป้นเพียงไม่กี่ครั้ง และสิ่งที่ทำลายสมาธิก็หายไป ควร ลงทุนกับสภาพแวดล้อมการทำงาน เช่น เก้าอี้ เชลล์พรอมป์ต์ editor แต่เมื่อสบายแล้วก็ลืมมันไป แล้วโฟกัสกับปัญหาจริงก็พอ
    อย่างไรก็ดี การปรับแต่งเครื่องมือไม่รู้จบอาจเป็นสัญญาณว่ากำลังหลีกเลี่ยงงานที่หนักและไม่น่าสนุก ซึ่งไม่ใช่ปัญหาง่าย ๆ ที่จะโยนความผิดให้ตัวเครื่องมือเอง

    • ถ้าได้งานใหม่แล้วได้รับเทคสแตกใหม่กับแล็ปท็อป Windows จะทำอย่างไร? ช่วงต้นอาชีพผมเรียนรู้วิธีทำงานให้มีประสิทธิภาพด้วยเครื่องมือพื้นฐานของสภาพแวดล้อมที่ได้รับมา และในความเป็นจริง โอกาสที่เราจะเลือกเครื่องมือเองได้มีน้อย เครื่องมือข้ามแพลตฟอร์มเองก็ไม่ค่อยสม่ำเสมอ ยกเว้นชุดผลิตภัณฑ์ของ JetBrains
    • ดูเหมือนความแตกต่างระหว่าง ซามูไรกับนินจา ซามูไรมองดาบเป็นส่วนขยายของจิตวิญญาณ แต่นินจาถ้าจำเป็นก็ใช้ดาบงัดของให้เปิดได้ ในเศรษฐกิจยุคนี้ มุมมองต่อเครื่องมือแบบซามูไรไม่ค่อยเข้ากัน
    • การใช้เครื่องมืออย่างสนุกเป็นเรื่องสำคัญ แม้ผลิตภาพจะไม่ได้เพิ่มขึ้น 10 เท่า แก่นสำคัญคือการจดจ่อกับงานและสนุกกับกระบวนการ
      โดยเฉพาะเครื่องมือในยุค LLM ทำให้ต้องสลับไปมาระหว่างเอเจนต์หลายตัวกับเทอร์มินัลอยู่ตลอด การ สลับบริบทบ่อย ๆ แบบนี้พรากความสนุกและสภาวะลื่นไหลไป จึงหวังว่าจะมีใครหาทางแก้ได้
    • ดูเหมือนมือใหม่จำนวนมากอยากได้รับการยอมรับและถูกมองอย่างจริงจัง จึงข้ามขั้นตอนที่จำเป็นไปบ่อย ๆ การดูเหมือนเป็นแบบนั้นกับการเป็นแบบนั้นจริง ๆ นั้นต่างกัน และระหว่างที่สะสมทักษะก็ยังต้องรับภาระเรื่องปากท้องด้วย
    • หลังจากเชี่ยวชาญเทคโนโลยีแล้ว เครื่องมือที่ดีในตัวมันเองก็กลายเป็นความสนุกอย่างมาก ในทางกลับกัน ผู้เชี่ยวชาญบางครั้งก็สามารถสร้างผลลัพธ์ที่ดีอย่างน่าทึ่งได้แม้ใช้เครื่องมือที่ไม่เหมาะนัก

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

    • ซอฟต์แวร์คือคำตอบของปัญหาที่ถูกทำให้เป็นรูปธรรม ดังนั้นก่อนอื่นต้องนิยามปัญหาที่จะแก้ โค้ดคือสแนปช็อตที่แสดงให้ทุกคน รวมถึงตัวเราในอนาคต เห็นระดับความเข้าใจปัญหาในปัจจุบัน รวมถึงความชัดเจนและความเหมาะสมของทางแก้
      การเขียนโค้ด ณ เวลาที่เหมาะสมคือการทำให้คำตอบที่เข้าใจแล้วเป็นรูปธรรม ใกล้เคียงกับงานพิมพ์มากกว่า
    • เมื่อก่อนผมหมกมุ่นกับการตั้งค่า แต่หลังจากใช้ AI ผมกำลังสร้างสิ่งเจ๋ง ๆ ที่เมื่อก่อนสร้างไม่ได้ ในทางกลับกัน ความเข้าใจต่อโค้ดฐานและทักษะเดิมก็ค่อย ๆ อ่อนลง และแม้จะทึ่งกับเทคนิคใหม่ ๆ แต่เหมือนไม่ได้เรียนรู้อย่างลึกซึ้ง
      ในแง่ที่ AI ช่วยลดกำแพงเริ่มต้นที่ต้องข้าม มันก็เป็นการปรับปรุงสภาพแวดล้อมอีกรูปแบบหนึ่งเหมือนกัน เมื่อก่อนตอนเดินทางทั่วยุโรปเพื่อเปลี่ยนจากบทบาท QA ไปเป็นนักพัฒนาและเรียน InterviewCake ผมก็เสียเวลาไปกับการปรับแต่ง editor มากกว่าการแก้โจทย์
      นี่อาจเป็น อาการของ ADHD ก็ได้ หลังเริ่มรักษาด้วยยาเมื่อเร็ว ๆ นี้ ผลิตภาพเปลี่ยนไปมาก และผมถึงกับน้ำตาไหลเมื่อคิดว่าได้เสียชีวิตไปครึ่งหนึ่งกับการทำให้การตั้งค่าสมบูรณ์แบบ แทนที่จะลงมือทำงานจริง
    • มีช่องว่างระหว่าง ผลิตภาพจริงกับความรู้สึกว่ามีผลิตภาพ การกดคีย์ใน Vim หรือ Emacs เพื่อเขียนโค้ดได้อย่างคล่องแคล่วทำให้รู้สึกเหมือนเป็นแฮกเกอร์ แต่ไม่ได้หมายความว่ามีผลิตภาพ ต่อให้สั่งการ AI agent หลายสิบตัวด้วยโทเคนมหาศาล ก็ไม่ได้รับประกันว่าผลลัพธ์จะทำงานได้หรือแก้ปัญหาได้
    • ไม่แน่ใจว่าสัดส่วนที่ควรใช้เวลา 90% ไปกับการคิดและอ่านนั้นแม่นยำหรือไม่ สำหรับนักพัฒนาแอป CRUD ธรรมดาส่วนใหญ่
    • การคิดกับการพิมพ์มักเกิดขึ้นพร้อมกัน หลายคนให้เหตุผลเกี่ยวกับปัญหาได้ง่ายขึ้นขณะเขียนและแก้โค้ด และนี่ก็เป็นเหตุผลว่าทำไมต่อให้อ่านโค้ดที่ LLM สร้างทั้งหมดแล้ว ความเข้าใจโค้ดก็ยังลดลงอย่างมากได้

  • มีบริษัทที่ได้รับเงินลงทุนจาก VC ซึ่งสร้างผลิตภัณฑ์ที่มีคนใช้จริงหรือยอมจ่ายเงินให้ไม่ได้ บริษัทเหล่านี้พยายามแสดงให้เห็นว่าตนยุ่งและมีผลิตภาพแค่ไหนเพื่อให้มูลค่าบริษัทดูสมเหตุสมผล และกระแส AI ก็อาจอยู่ในบริบทเดียวกัน เพราะโฟกัสแต่ผลิตภาพและวิธีการ มากกว่าว่าจะสร้างอะไร
    https://components.news/the-gamer-and-the-nihilist/ เปรียบเทียบ สตาร์ทอัพแนวสุญนิยม แบบนี้กับบริษัทพัฒนาเกมที่สร้างผลิตภัณฑ์ซึ่งผู้คนยอมจ่ายเงินและใช้งาน ในเศรษฐกิจที่แอปผลิตภาพคิดเป็นเกือบ 40% ของผลงานบน Product Hunt แรงงานบางส่วนก็ถูกทุ่มไปกับการทำให้ดูเหมือนกำลังสร้างอะไรบางอย่าง มากกว่าสร้างสิ่งนั้นจริง ๆ

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

  • ผมสร้างหรือใช้เครื่องมือผลิตภาพแค่พอไม่ให้ตามหลัง และมองว่ามากกว่านั้นเป็นกับดัก เมื่อก่อนจะทบทวนไตรมาสละครั้ง แต่หลัง AI ผมใช้สัปดาห์ละ 1–2 วันกับงานเมตาอย่างการปรับปรุงเครื่องมือ และคาดว่าจะลดลงเมื่อเครื่องมือที่เกี่ยวข้องเป็นมาตรฐานมากขึ้น
    ถ้าภาพลักษณ์ว่าเป็น ผู้เชี่ยวชาญด้านเครื่องมือ แข็งแรงขึ้น ไม่เพียงแต่จะพลาดงานที่มีคุณค่าจริง แต่ยังถูกประเมินว่าเป็นคนที่มีเคล็ดลับผลิตภาพลับ ๆ อีกด้วย หากความแตกต่างไม่ได้มากอย่างที่คาด การตัดสินใจอื่น ๆ ของเราก็อาจไม่ถูกเชื่อถือไปด้วย

  • ยิ่งใช้เวลาอยู่หน้าคอมพิวเตอร์น้อยลง ผมก็ยิ่งทำงานได้มากขึ้น และเมื่อผมลดมอนิเตอร์จาก 3 จอเหลือ 1 จอ ผลิตภาพก็เพิ่มขึ้นมาก ผมแก้ปัญหาส่วนใหญ่ได้ตอนหั่นผักหรือตัดหญ้า การนั่งอยู่หน้าเทคโนโลยีแวววาวไม่ได้ทำให้ตัดสินใจได้เร็วขึ้นหรือดีขึ้น
    เหตุผลที่ผมทำผลงานได้ดีกว่าทีมพัฒนาของลูกค้าก็เพราะผมไม่ใช่พนักงานประจำ จึงหยุดและคิดช้า ๆ ได้อย่างเพียงพอ ละครแห่งผลิตภาพ อย่างแรงกดดันให้สถานะใน Teams เป็นสีเขียวอยู่เสมอ ทำให้หลายองค์กรตัดสินใจโง่ ๆ

    • ตลอด 15 ปี ผมทำงานกับสองบริษัทที่มีสำนักงานอยู่บนหน้าผาใน La Jolla แคลิฟอร์เนีย มองเห็นทะเล ผมเดินไปตามหน้าผาและสวนสาธารณะพลางคิดเรื่องงาน และถ้าเป็นการหารือจริงจังที่ไม่ต้องใช้ไวต์บอร์ด ผมก็ชวนเพื่อนร่วมงานไปเดินด้วยกัน ควรกลับไปฟัง hammock talk ของ Rich Hickey อีกครั้ง
    • เห็นชื่อผู้ใช้แล้วสงสัยว่าเป็น Bob ที่ปรากฏในบทความหรือเปล่า

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

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

  • ในปี 2004 ทีมเล็ก ๆ ที่ส่วนใหญ่เป็นนักพัฒนาระดับจูเนียร์ได้รับการอบรม Java ที่ยอดเยี่ยมและเข้มข้น ก่อนการอบรม ทุกคนหมกมุ่นกับการตั้งค่า IntelliJ กับ Eclipse และถกเถียงกันอย่างดุเดือด แต่ผู้สอนกลับแนะนำอย่างน่าประหลาดใจให้ใช้แค่ เครื่องมือ JDK พื้นฐานกับ Notepad
    จุดประสงค์คือให้เรียนรู้ว่าเกิดอะไรขึ้นข้างใน และเขาบอกว่าผลิตภาพก็คงไม่ได้ต่างกันมากนัก

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

  • เรื่องนี้ไม่ใช่ผลิตภาพ แต่เป็น ความสนุกของการเล่นของเล่น