พิมพ์โค้ดด้วยตัวเอง

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

---

ทำไมต้องพิมพ์โค้ดด้วยตัวเอง

• คอร์ส “Learn X the hard way” ของ Zed Shaw แนะนำว่าอย่าคัดลอกและวางตัวอย่าง แต่ให้พิมพ์เอง และช่วงหลังยิ่งแนะนำหนักขึ้นว่าเมื่อฝึกเสร็จแล้วให้ลบออก แล้วสร้างใหม่จากความจำ
• ปรากฏการณ์ที่การสร้างเนื้อหาด้วยตัวเองทำให้เข้าใจดีกว่าการเสพแบบรับอย่างเดียว ถูกเรียกว่า generation effect ในจิตวิทยาการรู้คิด
• ดังคำพูดของ Richard Feynman ที่ว่า “What I cannot create, I do not understand” การฝึกรื้อสร้างโค้ดขึ้นใหม่จากความจำจึงเป็นการทดสอบทั้งความเข้าใจและความจำพร้อมกัน
• ในยุคของ agent coding นี่ไม่ได้หมายความว่าไม่ควรใช้เครื่องมือพัฒนา แต่หมายความว่าบางครั้งก็ควรฝึกความสามารถในการเขียนโค้ดระดับตัวอักษรโดยไม่มีความสะดวกจากเครื่องมือ
• การฝึกลักษณะนี้มุ่งไปที่การทำให้คุณสามารถ “freecoding” ได้ โดยรักษารายละเอียดของการเขียนโปรแกรมอย่างไวยากรณ์ ชนิดข้อมูล และชื่อไว้ในหัว

Freecoding และความรู้รายละเอียดในหัว

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

• ไวยากรณ์และโครงสร้าง

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

• ชนิดข้อมูลและสคีมา

  • ต้องคุ้นเคยและสบายใจกับ type system และ data model
  • หากยังอยู่ในระดับที่ต้องเปิดดูตาราง คอลัมน์ ความสัมพันธ์ และโครงสร้างชนิดข้อมูลของโปรเจกต์อยู่ทุกครั้ง ก็จะออกแบบในระดับระบบได้ยาก

• ชื่อ

  • ต้องนึกชื่อฟังก์ชัน เมธอด คลาส import ไฟล์ และแพ็กเกจได้อย่างถูกต้อง
  • เมื่อโปรเจกต์และ dependencies เปลี่ยน ความรู้นี้ก็ต้องอัปเดตตามไปด้วย
  • หากคุณพิมพ์โค้ดที่นึกไว้ในหัวออกมาไม่ได้ด้วยความแม่นยำในระดับหนึ่ง ก็ใกล้เคียงกับการเข้าใจผิดว่าตัวเองเข้าใจ มากกว่าจะเข้าใจอย่างชัดเจนจริง ๆ
  • ภาษาอังกฤษไม่ใช่ภาษาที่แม่นยำเท่าโค้ด และประเด็นนี้ก็เชื่อมโยงกับบทความ A sufficiently detailed spec is code ที่ชี้ว่าสเปกที่ละเอียดพอ สุดท้ายก็เข้าใกล้ความเป็นโค้ด

ไวยากรณ์ทำให้การคิดระดับสูงเป็นไปได้

• แม้ IDE หรือ coding agent จะช่วยจัดไวยากรณ์ให้ได้ ความสามารถในการจัดการไวยากรณ์ด้วยตัวเองก็ยังสำคัญ
• หากคุณยังลำบากกับการจับคู่วงเล็บ ก็อาจทำให้เกิดคำถามได้ว่าคุณเชื่อมโยงข้อสมมติและข้อสรุปเชิงตรรกะของคนอื่นได้อย่างคล่องแคล่วจริงหรือไม่
• ท่าทีที่มองข้ามรายละเอียดอาจเชื่อมไปสู่ภาวะอ่านออกเขียนได้เชิงหน้าที่บกพร่อง ซึ่งสื่อสารกันด้วยบรรยากาศมากกว่าจะพิจารณาความหมายของคำอย่างชัดเจน
• ตัวอย่างพรอมป์ต์ LLM หลายอันดูเผิน ๆ เหมือนใช้ได้ แต่เมื่ออ่านละเอียดจะพบว่ามีคำสั่งที่ขัดกันเองอยู่พร้อมกัน
  • “อย่าเสนอเครื่องมือภายนอกหรือทางเลือกอื่นที่ไม่อยู่ใน skill ที่ระบุไว้ข้างต้น”
  • “หากงานต้องการความสามารถที่เกินกว่า skill ที่มีอยู่ ให้บอกเช่นนั้น”
• ความสามารถในการจัดการไวยากรณ์ การสะกด และโครงสร้างเล็ก ๆ อย่างแม่นยำ ไม่ได้แยกขาดจากความสามารถในการเข้าใจภาพใหญ่ให้ถูกต้อง
• ไวยากรณ์ไม่ใช่รายละเอียดที่ขวางการคิดระดับสูง แต่เป็นเครื่องมือทางความคิดที่บีบอัดและเปิดทางให้การคิดระดับสูงเกิดขึ้นได้
• สัญลักษณ์ชนิดข้อมูลอาจแม่นยำและกระชับกว่าคำอธิบายภาษาธรรมชาติ

  x คืออาร์เรย์ของอ็อบเจ็กต์ โดยแต่ละอ็อบเจ็กต์มีพร็อพเพอร์ตี domain แบบจำเป็นที่เก็บสตริง และพร็อพเพอร์ตี port แบบเลือกได้ที่เก็บตัวเลข
  

  x : { domain: string, port?: number }[]
  

ชนิดข้อมูลและสคีมาคือเบาะแสหลักของการออกแบบระบบ

• Fred Brooks กล่าวไว้ใน The Mythical Man-Month ว่า ถ้าให้ดูตาราง ส่วนใหญ่แล้วโครงสร้างก็จะชัดเจนได้แม้ไม่มี flowchart
• หากใช้ฐานข้อมูล คุณควรรู้จักตาราง ชื่อคอลัมน์ และความสัมพันธ์ของโปรเจกต์อย่างทะลุปรุโปร่ง
• แทนที่จะคอยเปิดดูข้อมูลนี้แบบหลวม ๆ เมื่อต้องใช้ การทำความเข้าใจล่วงหน้าและเก็บไว้ในหัวจะช่วยให้ทำการออกแบบระดับระบบได้อย่างมีประสิทธิภาพ
• หากไม่พยายามในส่วนนี้ สคีมาฐานข้อมูลก็มักจะสะท้อนความคิดที่สับสน กลายเป็นโครงสร้างไม่ทำ normalization ที่เต็มไปด้วยข้อมูลซ้ำหรือคล้ายกันได้ง่าย
• ประสบการณ์กับภาษาชนิดข้อมูลเข้มอย่าง Rust หรือ Haskell แสดงให้เห็นข้อดีของ mental model ที่แข็งแรงต่อชนิดข้อมูลได้ชัดเจน
• การฝึกสร้าง “mental type checker” หรือ “mental borrow checker” ที่แม่นยำ ก็ช่วยได้แม้เวลาคุณใช้ภาษาที่มีชนิดข้อมูลอ่อนกว่า
• หากไม่ใช้กล้ามเนื้อการให้เหตุผลเชิงนามธรรมนี้ ก็มีโอกาสพลาดพื้นฐานของ data modeling อย่าง make invalid states unrepresentable
• หากไม่เข้าใจว่าชนิดข้อมูลต่าง ๆ ประกบกันอย่างไร ก็จะลงเอยด้วยการโปรย as any ไปทั่วโค้ด TypeScript
• หากยังทนความไม่สบายของการคิดเรื่องชนิดข้อมูลในเส้นทางปกติไม่ได้ เส้นทางผิดปกติอย่างการดีบัก type error ก็ยิ่งทนได้ยากกว่า
• นี่ไม่ได้หมายความว่า Haskeller หรือ Rustacean จะเขียนโค้ดดีกว่าเสมอไป แต่หากเงื่อนไขอื่นเท่ากัน ความคล่องกับชนิดข้อมูลย่อมช่วยได้

ต้องจำชื่อให้ได้จึงจะนำกลับมาใช้ซ้ำได้

• ควรนึกชื่อฟังก์ชัน เมธอด คลาส import แพ็กเกจ และไฟล์ที่ใช้บ่อยในโปรเจกต์หรือ dependencies ได้อย่างง่ายดาย
• นี่เป็นรูปแบบเฉพาะของหลักการที่กว้างกว่าว่า คุณต้องคุ้นเคยกับสิ่งที่มีอยู่แล้ว หรือ prior art
• เหตุผลที่หลายคนพึ่ง coding agent ก็เพราะไม่รู้จัก prior art ที่นำกลับมาใช้ซ้ำได้ซึ่งทำสิ่งที่ต้องการอยู่แล้ว ผลคือปล่อยให้เอเจนต์ประดิษฐ์ล้อขึ้นมาใหม่
• หากไม่รู้ว่ามี SaaS boilerplate projects อยู่ ก็ง่ายที่จะคิดว่าเอเจนต์จำเป็นต้อง scaffold ทุกอย่างขึ้นมาจากศูนย์
• สำหรับจุดประสงค์นี้ การโคลนโปรเจกต์โอเพนซอร์สที่ผ่านการพิสูจน์แล้วและสร้างมาเพื่อสิ่งนี้โดยตรง มักเร็วกว่า ถูกกว่า และเชื่อถือได้กว่าการขอให้เอเจนต์ทำงานเดียวกัน
• เมื่อมีคนคาดการณ์ว่า LLM จะสามารถสร้างทั้งเบราว์เซอร์ได้ภายในไม่กี่ปี ก็สามารถโต้แย้งได้ว่าเพียง fork Chromium ก็ทำได้ตั้งแต่วันนี้แล้ว และยังแก้ไขกับบำรุงรักษาได้ง่ายกว่า
• การจำชื่อยังสำคัญต่อการนำโค้ดกลับมาใช้ซ้ำภายในโปรเจกต์เดียวกันหรือในบริษัทเดียวกันด้วย
• หากไม่รู้ว่าต้องหาอะไร คุณก็ไม่อาจต่อยอดบนงานของเพื่อนร่วมทีมได้

การตรวจทานผลลัพธ์จากเอเจนต์ต้องอาศัยความเข้าใจของมนุษย์

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

  describe("abort detection logic", () => {
    it("detects aborted stopReason in messages", () => {
      const messages = [
        { role: "assistant", stopReason: "aborted", content: [] },
      ];
      const isAborted = messages.some((m: any) => m.stopReason === "aborted");
      expect(isAborted).toBe(true);
    });
  
    it("detects abort in error string", () => {
      const error = "The operation was aborted";
      const isAborted = error.includes("abort");
      expect(isAborted).toBe(true);
    });
  
    it("does not false-positive on normal errors", () => {
      const error = "Network timeout";
      const isAborted = error.includes("abort");
      expect(isAborted).toBe(false);
    });
  
    it("does not false-positive on normal stop reasons", () => {
      const messages = [
        { role: "assistant", stopReason: "stop", content: [] },
      ];
      const isAborted = messages.some((m: any) => m.stopReason === "aborted");
      expect(isAborted).toBe(false);
    });
  });
  

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

ความอึดและความชำนาญแยกจากกันไม่ได้

• Eustress คือความเครียดเชิงบวก และเมื่อคุณผลักดันตัวเองให้ทำสิ่งใหม่และยาก คุณจะสร้างความทนต่อความไม่สบายเล็ก ๆ และข้ามความไม่สบายที่ใหญ่กว่าได้
• หากคอยหลีกเลี่ยงความไม่สบายเสมอ ก็จะไหลลงสู่วงจรอุบาทว์ของความสิ้นหวังและความหงุดหงิดที่เพิ่มขึ้น
• เมื่อฝึกความแม่นยำ ความจำ และการคิดเชิงโครงสร้างในด้านหนึ่ง ความสามารถในอีกด้านก็มักดีขึ้นตามไปด้วย
• เช่นเดียวกับที่ LLM ทำการสรุปแบบทั่วไปจากข้อมูลฝึก มนุษย์ก็ทำให้เป็นนิสัยและถ่ายทอดความสามารถที่ฝึกในด้านหนึ่งไปยังอีกด้านหนึ่งได้
• โดยเนื้อแท้แล้ว การพัฒนาซอฟต์แวร์เกี่ยวข้องกับการออกจากพื้นที่สบายอย่างสม่ำเสมอ และอยู่ในบริบทเดียวกับบทความ Software engineers are not (and should not be) technicians

[GN⁺]

ความคิดเห็นจาก Lobste.rs

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

• ข้อความคอมมิตและเอกสาร ควรพิมพ์เอง
  โปรแกรมเมอร์มักไม่ชอบงานเขียนแบบนี้ เลยชอบคิดว่า “ให้ LLM เขียนให้ก็ได้” แต่ถ้าเขียนเอง คุณจะได้เผชิญหน้ากับประสบการณ์ผู้ใช้และการตัดสินใจด้าน implementation ในที่เดียวกัน เช่น “ถ้าจะทำ X ต้องส่ง -Y ... เดี๋ยวก่อน นี่คือทางที่ดีที่สุดหรือเปล่า?” “อันนี้ใช้ Y เพื่อแก้ X ... แต่จริง ๆ ใช้ Z ก็ได้ไม่ใช่เหรอ?” การทบทวนแบบนี้จะเกิดขึ้น

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

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

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

  • ไม่นานมานี้ฉันใช้ vibe coding ทำอะไรบางอย่างที่พอใช้งานได้แต่ไม่ค่อยดีนักออกมา แล้วโค้ดก็เละเทะมาก
    ฉันเลยถือโอกาสเขียนมันใหม่ด้วยมือ เพื่อเรียกสัญชาตญาณการเขียนโปรแกรมที่ขึ้นสนิมไปตลอด 8 เดือนที่ผ่านมาให้กลับมา ผลที่เขียนใหม่ออกมาฉันชอบมากกว่า และมันก็ทำงานได้ดีกว่าจริง ๆ LLM ยังมีประโยชน์สำหรับการอธิบายหรือช่วยแก้จุดที่ติดขัด แต่ความรู้สึกที่ว่าเราเข้าใจทั้ง codebase ด้วยตัวเองนั้นดีกว่ามาก
  • มันก็ขึ้นอยู่กับกรณี บางทีทาลิปสติกใหม่ให้หมู สุดท้ายมันก็ยังเป็น หมู อยู่ดี

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

  • ดูจะเป็นการตีความที่ถูกต้อง แต่ก็มีความเป็นไปได้สูงว่าคนเขียนพรอมป์ต์ตั้งใจให้ LLM ไม่ได้แค่พูดว่า “ขออภัย ต้องใช้ความสามารถอื่น แต่บอกไม่ได้” ทว่าให้บอก ว่าต้องใช้อะไร ด้วย แน่นอนว่าอาจตั้งใจตามตัวอักษรจริง ๆ ก็ได้
  • ฉันมองว่าคำตอบแบบ “ทำไม่ได้ด้วยความสามารถที่มีให้” ไม่สอดคล้องกับคำสั่งข้อที่สอง
    ประโยคที่สองอ่านได้ว่าไม่ได้สั่งให้โมเดลปฏิเสธหรือบอกเป็นนัยถึงการมีอยู่ของ external tool หรือทางเลือกอื่น แต่ให้ ยืนยันการมีอยู่ของมันอย่างสร้างสรรค์

• คำพูดที่ว่า “คนที่อธิบายสิ่งต่าง ๆ ให้ชัดเจนในเชิงหน้าที่ไม่ได้ แทบไม่มีข้อยกเว้นว่าจะเขียนประโยคที่ถูกต้องตามการสะกดหรือไวยากรณ์ไม่ได้ด้วย” ฟังดูเป็นอคติที่ค่อนข้างรุนแรงต่อคนที่มี dyslexia หรือแค่คิดต่างออกไป
  แน่นอนว่าเขาคงไม่ได้จะอ้างกลับกันว่าคนที่สะกดหรือใช้ไวยากรณ์ไม่ถูกต้องย่อมไม่ชัดเจนในเชิงหน้าที่ทันที แต่ไม่ว่าแบบไหนก็เป็นถ้อยคำที่ไม่ค่อยเผื่อพื้นที่ให้คนอื่น
  ถ้าจะมองอย่างสร้างสรรค์กว่านั้น ลองนึกถึง node editor ระบบแบบ node-based มีปัญหาเยอะใน implementation ปัจจุบัน แต่ถ้าทำดี ๆ มันสามารถควบคุมวิธีเขียนโปรแกรมจนตัด syntax error บางอย่างทิ้งไปได้เลย เช่น ถ้า node หนึ่งรับสตริง คุณก็ส่งตัวเลขให้มันไม่ได้ ไม่ใช่เพราะไปบังคับข้อจำกัดตอน build หรือ runtime แต่เพราะตั้งแต่ต้นมันทำให้คุณ “พูด” ตัวเลขตรงนั้นไม่ได้อยู่แล้ว เรื่องอย่างช่วงลูปที่ผิด จำนวนอาร์กิวเมนต์ไม่ถูก หรือวงเล็บไม่สมดุล ก็ทำให้ผิดไม่ได้ในเชิงโครงสร้างได้เหมือนกัน
  การเขียนซอฟต์แวร์ด้วยเครื่องมือที่บังคับข้อจำกัดบางอย่างในเชิงโครงสร้าง ไม่ได้แปลว่าคุณไม่เข้าใจข้อจำกัดนั้น แค่มันช่วยให้ไม่ต้องกังวลว่าจะเผลอพิมพ์ผิดในข้อผิดพลาดประเภทนั้นเท่านั้นเอง การรู้สึกหงุดหงิดที่เครื่องมือไม่ช่วยจัดการรายละเอียดทาง syntax เช่น จำนวนวงเล็บปีกกาของฟังก์ชัน หรือการย่อหน้าของ logical block ก็ไม่ได้แปลว่าคุณไม่เข้าใจว่าทำไม syntax นั้นถึงต้องใส่ใจ
  ที่ยก node system มาเป็นตัวอย่างก็เพราะมันตัดองค์ประกอบแบบ “โยนทิ้งไว้แล้วลืม” หรือ vibe coding แบบปิดสมองของ LLM ออกไป แล้วแยกให้เห็นเฉพาะ ปัญหาเรื่อง syntax พอตัด LLM ออกไป ข้ออ้างที่โฟกัสเรื่อง syntax ก็อ่อนลงมาก
  ฉันเห็นด้วยกับส่วนที่เหลือของบทความ แต่คิดว่าการมองทักษะด้าน syntax เป็นตัวชี้วัดรากฐานของความเข้าใจโค้ดหรือความสามารถในการเขียนโค้ดที่ดีของใครสักคน เป็นทิศทางที่ผิดมาก

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