- บทความเทคนิคสาธารณะสามารถออกแบบโดยยึด ข้อเท็จจริง·ประสบการณ์·คำถาม เป็นหลัก แทนการพยายามหลีกเลี่ยงคอมเมนต์ เพื่อเปลี่ยนปฏิกิริยาจากคนแปลกหน้าให้กลายเป็นข้อมูลที่นำไปเรียนรู้ได้
- หากพูดถึง ข้อเท็จจริงที่ตรวจสอบได้ เช่น วิธีใช้คอมพิวเตอร์หรือกรณีศึกษาการแก้ปัญหา มักจะได้คอมเมนต์เกี่ยวกับประสบการณ์คล้ายกัน การแนะนำเอกสารหรือแหล่งข้อมูล ข้อเท็จจริงที่ตกหล่น ข้อควรระวัง คำถาม และการชี้ข้อผิดพลาดบ่อยขึ้น
- แทนที่จะถามความเห็น หากขอ กรณีตัวอย่างและประสบการณ์ อย่างเจาะจง การประเมินว่า “UI จัดการ DNS บนเว็บแย่” ก็จะเปลี่ยนเป็นข้อมูลอย่าง “มันไม่รองรับเรคอร์ด
TLSA” - ช่วงไม่กี่ชั่วโมงหลังโพสต์ ควรรีบแก้ข้อผิดพลาดอย่างรวดเร็ว เขียนทางเลือกที่ได้พิจารณาไปแล้วไว้ล่วงหน้า และพยายามไม่ถูกดึงเข้าไปในประเด็นโต้เถียงซ้ำซาก
- ในพื้นที่อย่าง Twitter หรือ Mastodon ที่จัดการการติดตามและการบล็อกได้ ควรกำหนดขอบเขตของ พฤติกรรมที่ไม่ยอมรับ เพื่อให้เกิดบทสนทนาด้านเทคนิคที่ดีต่อสุขภาพ
วิธีเขียนให้คอมเมนต์มีประโยชน์
- ในการเขียนแบบสาธารณะ แทนที่จะหลีกเลี่ยงคอมเมนต์ทั้งหมด ให้ปรับ หัวข้อและวิธีตั้งคำถาม เพื่อให้คอมเมนต์ออกมาเป็นข้อมูลมากขึ้น
- แม้คอมเมนต์บนอินเทอร์เน็ตจะมีปฏิกิริยาหยาบคายอยู่บ้าง แต่ตลอดเวลาที่ผ่านมา ผู้เขียนก็ได้เรียนรู้อะไรมากมายจากคอมเมนต์ของคนแปลกหน้า
ให้ข้อเท็จจริงและประสบการณ์เป็นแกนหลัก
- ในบทความเทคนิค ผู้เขียนมักพูดถึง ข้อเท็จจริงเกี่ยวกับคอมพิวเตอร์ หรือประสบการณ์ที่ได้จากการใช้งานคอมพิวเตอร์
- หากเขียนแบบบทความ
tcpdumpที่พูดทั้งวิธีใช้และกรณีใช้งานในอดีต ทิศทางของคอมเมนต์มักจะค่อนข้างชัดเจนและเฉพาะเจาะจง- ประสบการณ์ใช้งานที่คล้ายกันหรือแตกต่างกัน
- การแนะนำเอกสารหรือแหล่งข้อมูลอื่น
- ข้อเท็จจริงที่เกี่ยวข้องแต่ไม่ได้อยู่ในบทความ
- ปัญหาที่อาจเกิดขึ้นหรือข้อควรระวัง
- คำถามทางเทคนิค
- การชี้ข้อผิดพลาดในบทความ
- คอมเมนต์ที่อิงข้อเท็จจริงมักจะรักษาบรรยากาศการสนทนาแบบปกติไว้ได้
- แน่นอนว่าก็มีปฏิกิริยาเชิงลบด้วย
- บางครั้งมีคนตอบอย่างหยาบคายเพราะบทความไม่ได้พูดถึงออปชันบางตัว
- เช่น ออปชัน
-nของtcpdumpมีประโยชน์เพราะปิดการทำ reverse DNS lookup ตามค่าเริ่มต้นและทำให้เห็น IP address ได้ - บางคนไวต่อความผิดพลาดมาก ผู้เขียนจึงรับมือด้วยการระบุว่า “ไม่แน่ใจ” ในส่วนที่ยังไม่มั่นใจ
เรื่องเล่าการแก้ปัญหาสร้างบริบท
- เรื่องราว เกี่ยวกับปัญหาที่แก้ได้มักกระตุ้นให้เกิดการพูดคุยที่ดี
- เหมือนบทความที่เล่าประสบการณ์ว่าจำเป็นต้องเข้าใจ TCP การแชร์กระบวนการแก้ปัญหาเฉพาะอย่างช่วยให้คอมเมนต์นำสิ่งที่เรียนรู้ไปวางในบริบทที่กว้างขึ้น
- ทำให้รู้ว่าปัญหาเดียวกันนี้พบได้บ่อยหรือไม่
- ทำให้รู้ว่ามีปัญหาอื่นใดที่มักเกิดร่วมกัน
- ทำให้รู้จักวิธีแก้อื่นที่ไม่ได้คิดถึง
- เหตุผลที่ผู้เขียนแก้บั๊กยาก ๆ ได้ ก็เพราะเคยอ่านบทความที่คนอื่นเขียนไว้ ดังนั้นเรื่องเล่าการแก้ปัญหาแบบนี้จึงอาจสำคัญต่อคนอื่นเช่นกัน
ใส่คำถามทางเทคนิคไว้ในบทความ
- ถ้าตั้ง คำถามทางเทคนิค ที่ยังไม่รู้คำตอบไว้ตรง ๆ ในบทความ หรือเขียนว่า “ไม่รู้เรื่อง X” จุดสนใจของคอมเมนต์จะถูกทำให้แคบลง
- ผู้อ่านจะเข้ามามีส่วนร่วมได้ง่าย โดยการตอบคำถามหรืออธิบายในส่วนที่ผู้เขียนยังไม่รู้
- การใส่คำถามลงไปทำให้มีโอกาสได้สิ่งที่มีคุณค่าจากคอมเมนต์จริงมากขึ้น
- คนชอบตอบคำถาม
- ผู้เขียนก็มีโอกาสได้คำตอบที่สงสัยอยู่
แก้ข้อผิดพลาดให้เร็ว
- เพราะมักเขียนในหัวข้อที่อยู่ตรงขอบเขตของความรู้ จึงเกิดข้อผิดพลาดในบทความได้บ่อย
- เมื่อมีคนชี้ข้อผิดพลาด ผู้เขียนจะใช้วิธีแก้ไขบทความทันที
- หลังเผยแพร่ ผู้เขียนจะอยู่ใกล้คอมพิวเตอร์สักสองสามชั่วโมงเพื่อรีบนำคำทักท้วงเรื่องข้อผิดพลาดมาแก้
- แม้จะมีวิธีบันทึกรายการแก้ไขแบบ
errataอย่างละเอียด แต่เพราะมีเวลาจำกัด จึงมักแก้ที่ตัวบทความโดยตรง
ขอกรณีตัวอย่างและประสบการณ์ แทนการถามความเห็น
- เมื่อมี ความเห็น หลากหลายเข้ามาใต้โพสต์บน Twitter หรือ Mastodon ถ้าถามต่อว่าทำไมจึงคิดแบบนั้น ก็อาจได้ประสบการณ์ที่เป็นรูปธรรมกลับมา
- ในบทความเรื่อง DNS มีคนบอกว่าชอบ zone file และไม่ชอบเว็บอินเทอร์เฟซสำหรับจัดการ DNS record พอถามเหตุผล ก็ได้คำตอบว่าเว็บอินเทอร์เฟซบางตัวไม่รองรับเรคอร์ด
TLSA - เมื่อเทียบกับความเห็นอย่าง “เว็บอินเทอร์เฟซจัดการ DNS แย่” ประสบการณ์แบบ “อยากใช้ DNS record type X แต่ใช้ไม่ได้” สร้างข้อมูลที่มีประโยชน์กว่า
- ในงานเขียนของตัวเอง เมื่อผู้เขียนแสดงความเห็น ก็พยายามอธิบาย ประสบการณ์การใช้งานคอมพิวเตอร์ ที่ทำให้เกิดความเห็นนั้นไปด้วย
ลดความเข้าใจผิดด้วยบริบทสั้น ๆ
- คนแปลกหน้าบนอินเทอร์เน็ตมีแนวโน้มจะตอบสนองแปลก ๆ มากขึ้น หากไม่รู้ว่าผู้เขียนเป็นใครและเขียนไปทำไม
- การใส่ บริบทของการเขียน สั้น ๆ ไว้ช่วงต้นบทความช่วยลดการคาดเดาที่ผิดพลาดได้
- บริบทว่าเริ่มใช้ Mac และลำบากเพราะต้องรันซอฟต์แวร์ที่รองรับเฉพาะ Linux
- บริบทว่าเริ่มดูแลเซิร์ฟเวอร์หลายเครื่องขึ้นและต้องคิดเรื่อง monitoring
- บริบทว่าต้องใช้สแกนเนอร์บน Linux เป็นครั้งแรกและกังวลว่าจะใช้เวลานานไหม
หลีกเลี่ยงข้อถกเถียงน่าเบื่อ
- ข้อถกเถียงด้านโปรแกรมมิงอย่าง “ควรเรียน
vimไหม” หรือ “functional programming ดีกว่า imperative programming หรือไม่” อาจให้ความรู้สึกน่าเบื่อได้ - หัวข้อที่ไม่สนใจหรือไม่มีอะไรน่าสนใจจะพูด มีแนวโน้มจะสร้างกระแสคอมเมนต์ที่ไม่ต้องการ จึงควรหลีกเลี่ยง
- แม้จะคาดเดาได้ไม่เสมอไป แต่หัวข้อ flamebait ที่เคยก่อข้อโต้เถียงซ้ำ ๆ ในอดีตก็ควรหลีกเลี่ยงเท่าที่ทำได้
- เช่น cryptocurrency, Tailwind, DNSSEC/DoH
- อย่างไรก็ตาม ถ้าสนใจหัวข้อนั้นจริง ๆ ก็ยังสามารถเขียนถึงได้
- แม้แต่หัวข้ออย่าง IPv6 และ IPv4 ที่มีประเด็นถกเถียงซ้ำ ๆ มากมาย หากนำเสนอในมุมอย่างเหตุผลที่เซิร์ฟเวอร์ควรรองรับ IPv6 ก็ยังอาจได้คอมเมนต์ที่น่าสนใจ
เขียนทางเลือกที่พิจารณาแล้วไว้ล่วงหน้า
- หากทางเลือกที่เคยพิจารณาแล้วแต่ไม่เลือก ถูกเสนอซ้ำในคอมเมนต์อีก การสนทนาอาจน่าเบื่อได้
- ผู้เขียนจึงใส่บันทึกสั้น ๆ เช่น “เหตุผลที่ไม่ทำ X คือ A, B, C” หรือ “ปกติจะทำ X แต่ในกรณีนี้…”
- ในบทความเกี่ยวกับ Nix ผู้เขียนระบุฟีเจอร์ที่เลือกไม่ใช้ เช่น
nix-shell,nix flakes,home managerเพื่อพยายามลดคอมเมนต์แนว “ควรใช้ flakes” - การเขียนถึงสิ่งที่ไม่ได้ทำ ยังมีประโยชน์กับผู้อ่านด้วย
- ผู้อ่านที่เพิ่งเริ่มรู้จัก Nix อาจได้ค้นพบ
nix flakes - ผู้อ่านอาจได้เรียนรู้ว่าแม้แต่ “best practice” ก็มีข้อยกเว้น
- ผู้อ่านที่เพิ่งเริ่มรู้จัก Nix อาจได้ค้นพบ
ตั้งขอบเขตในพื้นที่โซเชียล
- เมื่อผู้เขียนทักท้วงวลี “domain information groper” ใน man page ของ
digบน Mastodon บางรีพลายกลับเรียกร้องให้พิสูจน์ว่าผู้เขียนต้นฉบับมีเจตนาก้าวร้าวหรือพยายามอธิบายว่าไม่ใช่ปัญหา - จุดยืนคือวลีนั้นเกี่ยวข้องกับถ้อยคำที่คนทั่วไปเข้าใจกันอย่างแพร่หลายว่าอ้างถึงการล่วงละเมิดทางเพศ จึงไม่ควรอยู่ใน man page ของ
dig - ผู้เขียนบล็อกบางคนและโพสต์ข้อความสั้น ๆ ว่าไม่ต้องการได้รับปฏิกิริยาแบบนั้นอีก
- บนโซเชียลมีเดีย บางครั้งการตั้ง กฎ ว่าจะไม่ยอมรับพฤติกรรมแบบใดเป็นสิ่งสำคัญ
- เป้าหมายคือทำให้คนหยาบคายบางส่วนเลิกติดตามไป
- และทำให้คนที่เหลือมีพื้นที่พูดคุยเรื่องคอมพิวเตอร์กันอย่างมีสุขภาวะมากขึ้น
- วิธีนี้ทำได้เฉพาะในพื้นที่อย่าง Twitter หรือ Mastodon ที่พอจะจัดการรายชื่อผู้ติดตามได้บ้าง
- ในพื้นที่อย่าง HN, Reddit, Lobsters ผู้เขียนจะไม่พยายามทำแบบเดียวกัน
- ผู้ดูแล
digได้นำวลีที่เป็นปัญหาออกไปแล้วเมื่อหลายปีก่อน แต่ใน Mac OS ยังมีเวอร์ชันเก่ามากค้างอยู่เพราะเหตุผลด้านไลเซนส์
ไม่เถียง แต่เก็บเฉพาะสิ่งที่ได้ประโยชน์
- หากมีคนมาชวนทะเลาะหรือคอมเมนต์แบบเมินเฉย ผู้เขียนจะไม่ตอบ
- เพราะผู้เขียนไม่ชอบและไม่เก่งการเถียงบนอินเทอร์เน็ต จึงไม่ใช่การใช้เวลาที่คุ้มค่า
- หากมีคอมเมนต์เชิงลบที่ไม่คาดคิดจำนวนมาก ผู้เขียนจะดูว่ามีอะไรที่ยังดึงมาใช้ประโยชน์ได้หรือไม่
- ในบทความ Go DNS resolver ความยาว 80 บรรทัด มีบางคอมเมนต์ไม่พอใจที่บทความไม่ได้พูดถึงการ parse DNS packet
- ตอนแรกผู้เขียนคิดว่า DNS parsing เป็นเรื่องง่ายและชัดเจนอยู่แล้ว
- แต่ก็ได้ตระหนักว่าสำหรับคนที่ไม่เคยทำมาก่อน มันอาจไม่ได้ชัดเจนเลย
- คอมเมนต์เหล่านั้นเป็นแรงบันดาลใจบางส่วนให้กับ implement DNS in a weekend ซึ่งพูดถึงการ parsing มากขึ้น และท้ายที่สุดก็นำไปสู่คำอธิบาย DNS resolver ที่ดีกว่าเดิม
- แม้ผู้เขียนจะไม่ได้ไม่หวั่นไหวทางอารมณ์ต่อคำวิจารณ์เชิงลบในที่สาธารณะ แต่การพยายามวิเคราะห์คำวิจารณ์แล้วหยิบส่วนที่มีประโยชน์ออกมาช่วยได้
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
เป็นคำแนะนำที่ทำได้จริงและสมเหตุสมผลมากสำหรับคนที่เขียนบนอินเทอร์เน็ต และตรงกับประสบการณ์ของผมด้วย
แต่ก็น่าเศร้าที่วัฒนธรรมอินเทอร์เน็ตที่เราสร้างขึ้นทำให้คนมีความสามารถอย่าง Julia ต้องเซ็นเซอร์ตัวเองและจำกัดขอบเขตของงานเขียน
เหมือนท่อนที่ว่า “มีรายการแปลก ๆ อยู่ในหัวว่าอะไรบ้างที่ไม่ควรพูดถึง ถ้าไม่อยากเริ่มการถกเถียงครั้งที่ 50 ในหัวข้อเดิม” ในโลกออนไลน์ พฤติกรรมที่ในพื้นที่สังคมแบบอื่นคงยอมรับไม่ได้ กลับถูกยอมรับและบางครั้งยังได้รับรางวัลด้วย
HN, Slashdot, Twitter, Tumblr อาจมีรูปแบบต่างกัน แต่ปัญหาหลักดูเหมือนเหมือนกันทุกที่
บนอินเทอร์เน็ต ความคุ้นเคยส่วนตัว ความใกล้ชิดทางกายภาพ สีหน้าและน้ำเสียงหายไป และความกลัวต่อการตอบโต้จริง ๆ ก็แทบหายไปด้วย
จากประโยคถัดจากที่ยกมา ผมอ่านแล้วรู้สึกว่าเป็นหัวข้อที่ถูกพูดถึงมากเกินไปแล้ว ผู้คนมีความเห็นแรง ๆ กันอยู่ แต่ก็เป็นเรื่องที่ยากที่ใครจะเปลี่ยนความคิด เสนอมุมมองใหม่ หรือเรียนรู้อะไรได้
อย่างไรก็ตาม ผมคิดว่าหลายคนเซ็นเซอร์ตัวเองจริง ๆ กับเรื่องที่มีแนวโน้มจะก่อให้เกิดการถกเถียงด้วยอารมณ์ ภาพเหมารวม หรือ downvote เช่น ความเห็นที่อยู่นอกหรือบนขอบของทัศนะกระแสหลักของชุมชนใดชุมชนหนึ่ง
เช่น ผมเคยลองทำโปรเจกต์เล่น ๆ ด้วย Tailwind อยู่ไม่กี่ชิ้นและคิดว่ามันก็ดีทีเดียว แต่คนที่ทำงานเต็มเวลากับโปรเจกต์ Tailwind ขนาดใหญ่ในที่ทำงานอาจได้รับผลกระทบจากส่วนที่ผมมองข้ามว่าเล็กน้อยมากกว่ามาก และทุ่มเวลาและความหลงใหลให้ได้มากกว่า
ถ้าเจอสถานการณ์แบบนั้นซ้ำ ๆ ผมคงไม่ลาก Tailwind เข้าไปในบทสนทนาที่ไม่อยากให้เป็นเรื่อง Tailwind และก็คงไม่ได้รู้สึกว่ามันแย่อะไรมากนัก
บางหัวข้อจะถูกกลุ่มใหญ่ดันขึ้นหรือลงเสมอ ดังนั้นถ้าสามารถเก็บรางวัลได้อย่างมั่นคงด้วยคอมเมนต์เดิมทุกครั้งที่หัวข้อนั้นโผล่ขึ้นมา การทำซ้ำก็เป็นพฤติกรรมที่สมเหตุสมผล
ต่อให้รางวัลตรงนี้สุดท้ายเป็นแค่การปรับสมดุลโดพามีนของตัวเองก็ยังเหมือนเดิม
ในสังคมออฟไลน์ การทำเงินจากคอมเมนต์อาจยากกว่า แต่ก็ไม่ใช่ว่าไม่มีเลย เช่น ความนิยม หรือการเลือกตั้ง
กลยุทธ์การพูดว่า “ไม่แน่ใจ” เพื่อหลีกเลี่ยงการถกเถียงไร้ประโยชน์และดึงคำตอบที่เป็นประโยชน์ออกมานั้นยอดเยี่ยม แต่น่าเสียดายที่ไม่ใช่เรื่องง่ายสำหรับคนจำนวนมากในวงการซอฟต์แวร์
คนทำซอฟต์แวร์คุ้นเคยกับยุคที่ยังสามารถเชี่ยวชาญอะไรบางอย่างได้อย่างสมบูรณ์เหมือนในอดีต แต่ในตอนนี้ที่ความรู้และความซับซ้อนของโลกเพิ่มขึ้นเรื่อย ๆ แม้แต่บุคคลอัจฉริยะเหนือมนุษย์ที่มีมาตั้งแต่ปฐมกาลก็แทบตามไม่ทัน
ถ้ามองความเห็นคัดค้านไม่เป็นสัญญาณว่า “ฉันรู้น้อยกว่าที่คิด” ก็จะอันตราย และผมเคยเห็นหลายครั้งที่โปรเจกต์ซึ่งนำโดยคนฉลาดมาก ๆ ล้มเหลว เพราะไม่ฟังข้อมูลสำคัญจากคนที่อาจฉลาดน้อยกว่าแต่รู้เทคโนโลยีเฉพาะนั้นดีกว่า
ในความเป็นจริงมันใกล้เคียงกับแผนภูมิเรดาร์ของทักษะและประสบการณ์มากกว่า และยิ่งรู้สึกน่าขันเป็นพิเศษในอาชีพที่เต็มไปด้วยความรู้เฉพาะทางลึกลับ
การมีประสบการณ์มากและฉลาดเป็นสินทรัพย์ใหญ่ แต่ถ้ามีรุ่นพี่ที่ไม่ค่อยรู้จักไลบรารี X กับเด็กใหม่ที่ขุดคุ้ยแต่ไลบรารี X ก็ควรฟังคำแนะนำของเด็กใหม่คนนั้น
คนที่ฉลาดจริงรู้ว่าตัวเองรู้อะไรและไม่รู้อะไร ตรวจสอบความเข้าใจของตัวเองอยู่เสมอ และเมื่อพบว่าตัวเองผิดก็ยินดี เพราะแปลว่าได้เรียนรู้อะไรใหม่
ทุกคนคิดว่าต้องทำเหมือนรู้ทุกอย่างจึงจะได้รับความเชื่อใจหรือการยอมรับ แต่จริง ๆ แล้วถ้าอยู่กับความจริงใจ ความช่วยเหลือก็จะตามมาเอง
กฎของผมบน HN เป็นแบบนี้: ให้สมมติว่าคนที่ตอบไม่ได้อ่านบทความ และก็แค่อ่านคอมเมนต์ของผมแบบผ่าน ๆ ขณะกำลังเขียนคำตอบของตัวเองในหัว, เรื่องที่เป็นนามธรรมจะถูกเข้าใจผิด ดังนั้นให้เขียนอย่างเป็นรูปธรรมแต่กำกวม, ให้ถือว่าไม่มีความสัมพันธ์ที่สม่ำเสมอระหว่างคุณภาพคอมเมนต์กับปฏิกิริยาตอบรับ, เขียนคำตอบแล้วลบทิ้งโดยไม่ส่งก็ได้ และโดยมากนั่นคือทางเลือกที่ดีที่สุด, ถ้าไม่แน่ใจให้พับเธรดแล้วไปต่อ
ขอเสริมว่า ควรหลีกเลี่ยงการเถียงตอบโต้ยาว ๆ กับผู้ใช้คนเดียว เพราะโดยทั่วไปน่าเบื่อและไม่มีข้อสรุป, ถ้ามีใครหาเรื่องก็อย่าโดดขึ้นไปเล่นด้วย, สำหรับคอมเมนต์ที่ดูเป็นลบให้เผื่อความเป็นไปได้ไว้มาก ๆ ว่าเราอาจเข้าใจผิด และคำชมสามารถทำให้วันของคนคนหนึ่งดีขึ้นได้ ดังนั้นอย่าขี้เหนียวกับมัน
พอขอให้เพื่อนร่วมงานช่วยตรวจ เขาก็บอกว่า “มีวิธีเดียวที่จะปรับปรุงมันได้” แล้วกดปุ่มลบทันที
ถ้าจำเป็นต้องมีรายการแบบนี้ ผมคิดว่าทิศทางที่สร้างสรรค์กว่ามักเป็นการลดอัตตาเพื่อสร้างความยืดหยุ่นต่อวาทกรรมออนไลน์
แล้วเราจะรับสิ่งต่าง ๆ ได้ตามที่มันเป็นมากขึ้น และได้สัมผัสมุมมองที่หลากหลายกว่าเดิม
HN ไม่ได้พิเศษ และผมเองก็ไม่ได้พิเศษ คนแปลกหน้าไม่มีหน้าที่ต้องสละเวลามาประดิษฐ์คำตอบอย่างใส่ใจให้ผม และถ้าคาดหวังหรือเรียกร้องสิ่งนั้น โดยมากก็จะจบลงด้วยความผิดหวัง
ผมจะกลับไปดูเฉพาะเมื่อยินดีจะมีส่วนร่วมถ้ามีคำตอบมา
คอมเมนต์ที่มีความขัดแย้งแม้เพียงเล็กน้อยมักจะมีคำตอบจากคนที่ไม่ได้พยายามเข้าใจว่าผมกำลังพูดอะไร และแม้ผมจะโพสต์ข้อมูลหนึ่งชุดพร้อมลิงก์ ก็จะมีใครบางคนโกรธเพราะไม่ชอบข้อมูลนั้น
เธรดคอมเมนต์ อย่างมากก็แค่เกี่ยวพันกับหัวข้อเดียวกันแบบหลวม ๆ เท่านั้น
งานเขียนของ Julia มี พลังของคนดี ต่างจากบล็อกบางส่วนที่พยายามทำตัวน่ารักแบบฝืน ๆ และดูเหมือนว่าเธอได้รับสิ่งดี ๆ กลับมาเท่ากับที่เธอส่งออกไป
ชัดเจนว่าเธอเป็นนักเขียนที่ชำนาญและรู้วิธีคุมโทน
น้ำเสียงที่ผู้คนบนอินเทอร์เน็ตมักตั้งสมมติฐานไว้เป็นค่าเริ่มต้นนั้นกระด้างกว่า และนั่นเป็นสาเหตุใหญ่ของปัญหาที่ไม่จำเป็น
ในทางกลับกัน การประชดนิด ๆ หรือความดิบแบบ Torvalds สมัยก่อนก็ไม่ได้แย่ แต่โทนแบบนั้นจะดึงดูดฝูงชนที่เสียงดังกว่าเข้ามา
ไม่ใช่ทุกคนจำเป็นต้องเลียนแบบวิธีสนทนาแบบนั้น
ถึงอย่างนั้น น้ำเสียงของผมก็ยังรู้สึกใกล้กับ โทนบรรยายสอน มากกว่าที่อยากให้เป็นอยู่เสมอ
คำแนะนำแน่นมาก
ในฐานะคนที่เคยเจอเรื่องคล้ายกัน ขอเสริมว่า บทสนทนาออนไลน์ทั้งหมดเป็นสิ่งที่เลือกได้ ดังนั้นไม่จำเป็นต้องแลกเปลี่ยนกับใครอย่างไม่สนุกให้จบ และคนโง่ก็ปล่อยอ่านแล้วไม่ตอบได้
เราไม่สามารถโน้มน้าวทุกคนได้ บางคนก็ตั้งใจจะค้านอย่างเดียว และหลายการถกเถียงมีเจตนาร้าย ดังนั้นอย่าพยายามเปลี่ยนการยั่วยุให้เป็นการอภิปรายจะดีกว่า
คุณไม่ได้ติดหนี้อะไรผู้อ่านด้วย พวกเขาไม่ได้จ่ายเงิน
โดยรวมเป็นคำแนะนำที่ดี และการให้ ประสบการณ์มาก่อนความคิดเห็น รู้สึกสดใหม่สำหรับผม
“การดักกันไว้ก่อน” ไม่ค่อยถูกใจ เพราะทำให้งานเขียนน่าเบื่อได้ และ Julia เป็นนักเขียนชำนาญจึงทำได้ลื่นไหล แต่ผมทำไม่ค่อยได้
“ไม่ถกเถียง” นั้นดี แต่ผมมักพลาดบ่อย
เคล็ดลับที่ใช้ได้กับผมคือเตือนตัวเองว่าตอนนี้ผมกำลังกำลังฝึกสอนใครบางคนฟรี ๆ อยู่
ผมก็ไม่ค่อยเก่งเรื่องวิเคราะห์คอมเมนต์เชิงลบด้วย เลยอาจต้องใช้เทคนิคแนวการบำบัดแบบความคิดและพฤติกรรมสักอย่าง ปกติจะรีบเช็กว่า “ผมผิดหรือเปล่า?” แล้วถ้าผิดก็แก้ได้ ถือเป็นผลลัพธ์ที่ดี แต่ถ้าผมถูกแล้วถูกเข้าใจผิด ผมจะโมโห
ไม่รู้ว่าทำไม แต่ การถูกทั้งที่ถูกเข้าใจผิด น่าหงุดหงิดกว่าการผิดมาก
ถ้าผิด ผมจะคิดว่า “อ่า แย่แล้ว” พร้อมเกิดปฏิกิริยาโดพามีนจากการค้นพบ แต่ถ้าผมถูกแล้วอีกฝ่ายปฏิเสธที่จะเข้าใจ ผมจะคอยจิกเรื่องนั้นต่อไปเรื่อย ๆ
นี่คือแรงจูงใจหลักในการบล็อกบน Twitter และในอุดมคติ คนที่มักเข้าใจผมผิดก็ควรบล็อกผมด้วย เพื่อที่ผมจะได้ไม่เข้าไปเกี่ยวข้อง
ปฏิกิริยาต่อ “gross terminology” ในหน้าแมนนวลของ dig อาจเป็นความเข้าใจผิดและการสื่อสารล้มเหลวจริง ๆ หรือบางทีอาจเป็นความต่างระหว่างอังกฤษแบบสหราชอาณาจักรกับอังกฤษแบบอเมริกัน
“to grope around for something” หมายถึงคลำหาอะไรบางอย่าง และไม่ใช่สำนวนทางเพศเลย โดยปกติสิ่งที่คลำหาก็มักเป็นสิ่งไม่มีชีวิตอย่างสวิตช์ไฟ
ผมก็ไม่คิดว่าการใช้นั้นมาจากอุปมาเกี่ยวกับการล่วงละเมิดทางเพศ
คำหนึ่งคำมีได้หลายความหมายและอาจถูกใช้ในแบบหยาบคายได้ แต่ก็ยังใช้ได้อย่างชอบธรรมและเป็นธรรมชาติอยู่
“I coloured in a picture” ก็ไม่ได้ชวนขยะแขยง และ “garden hoe” ก็น่าจะโอเคไม่ใช่หรือ
ตัวอย่าง: https://www.dictionary.com/browse/groper
โดยเฉพาะผู้หญิง ซึ่งเป็นเป้าหมายที่พบบ่อยของการคลำแตะต้องทางเพศ อาจตระหนักถึงความหมายนั้นมากกว่า ดังนั้นแม้จะไม่ใช่สิ่งที่ผมนึกถึงเป็นอย่างแรก ผมก็เห็นว่าสมเหตุสมผลที่ผู้หญิงจะรับรู้แบบนั้น
อย่างที่ Julia พูด เจตนาเดิมไม่ได้สำคัญนัก และถ้างานเขียนของผมเผลอสร้างปัญหาให้ผู้อ่านบางส่วน ผมก็จะเปลี่ยน
เพราะเป้าหมายของผมคือสื่อสารใจความ
เวลาผมเห็นคนปกป้องภาษาที่ทำให้กลุ่มที่ถูกกีดกันในอดีตรู้สึกไม่สบายใจอย่างแข็งกร้าว ผมก็สงสัยว่าทำไมถึงต่อต้านการเปลี่ยนแปลงเล็ก ๆ น้อย ๆ ขนาดนั้น
อีกอย่าง ผู้ดูแล dig ก็เปลี่ยนไปแล้วตั้งแต่ปี 2017 แปลว่าพวกเขาคงไม่ได้ติดใจอะไรมากนัก
แต่ผมไม่ค่อยแน่ใจว่าในยุค 80 เป็นแบบนั้นด้วยหรือเปล่า
ผมกดลิงก์ Mastodon เพื่อดู “ผู้ชายที่เรียกร้องให้พิสูจน์” แล้วภายหลังจึงรู้ว่าคำตอบที่เป็นปัญหาถูกลบไปแล้ว ดังนั้นคำตอบสามอันที่ผมเห็นจริง ๆ ไม่เกี่ยวข้อง
คำตอบที่ผมเห็นโดยรวมสนับสนุน สองคนบอกว่าไม่เคยคิดถึงความหมายเรื่องการล่วงละเมิดทางเพศมาก่อน และแม้จะไม่รู้ว่านั่นเป็นเจตนาหรือไม่ แต่ก็เห็นด้วยอย่างยิ่งว่าควรลบออก อีกคนประหลาดใจที่มีการตีความแบบนั้นและถามหาบริบทเพิ่มเติม
หลังจากนั้น OP ตอบกลับจำนวนมากในเชิงเผชิญหน้าอย่างมาก โดยสันนิษฐานว่าทุกกรณีมีเจตนาร้าย ซึ่ง Julia เป็นนักเขียนเทคนิคที่ยอดเยี่ยมและผมจะอ่านต่อไป แต่ภาพครั้งนี้ดูไม่ดีนัก
การขอเปลี่ยนหน้าแมนนวลนั้นสมเหตุสมผลอย่างยิ่ง แต่ไม่จำเป็นต้องโจมตีตัวบุคคล
ผู้ชายบางคนที่ยกประเด็นเรื่องสำนวนนั้นระบุชัดเจนว่าเห็นด้วยอย่างเต็มที่กับการเอา “groping” ออก แต่ ณ จุดนั้นผู้เขียนคงไม่สามารถเห็นคำอธิบายนั้นแล้ว
ผมสนับสนุนเต็มที่ที่แต่ละคนจะตั้งขอบเขตและเลือกบล็อกพฤติกรรมคุกคาม แต่ท่าทีแบบ “ฉันไม่เห็นด้วยกับสิ่งที่เธอพูด ดังนั้นจะบล็อกทันทีและไม่ให้โอกาสชี้แจง” ดูเหมือนอยู่ใจกลางของ ความพังของวาทกรรมออนไลน์
อย่างไรก็ตาม ผมก็เข้าใจตัวกระตุ้นที่ไวต่อเรื่องนี้ เพราะเคยเห็นผู้หญิงรอบตัวเจอการคุกคามออนไลน์มาแล้ว
ผมไม่รู้ว่าสมดุลที่ถูกต้องคืออะไร และคงเป็นเรื่องส่วนบุคคลกับบริบทอย่างมาก แต่ผมเริ่มเข้าร่วมบทสนทนาเฉพาะเมื่อเต็มใจรับมือกับหมวดหมู่คำตอบที่คาดเดาได้ ยกเว้นการคุกคามที่ชัดเจน
วิธีบล็อกเมื่อไม่เห็นด้วยดูเหมือนจะเพิ่มการแบ่งขั้วและส่งผลเสียในระยะยาว และแม้บางครั้งผมจะ “ถูก” ก็ตาม มันก็ดูจะยิ่งเสริมจุดบอดของผมได้ง่าย
ผมเหนื่อยกับคนที่เห็นประโยคซึ่งเขียนในแบบที่ต่างจากที่คาดแล้วหน้าซีด จากนั้นก็ทรมานใจเพราะกลัวว่าจะมีความหมายสองชั้น
เช่น “Smoking a fag” เป็นสำนวนอังกฤษแท้ ๆ แต่ชาวอเมริกันไร้วัฒนธรรมอาจทำท่าตกอกตกใจแล้วคลำหาปุ่ม downvote หรือปุ่มรายงาน
ถ้ากลัวก็ไม่ควรอ่านอะไรเลย
การอ่านนั้นน่ากลัวและอันตราย
ถ้าคุณใส่ใจคนที่ฟังคุณ เวลาพวกเขาบอกว่า “คำที่คุณใช้ส่งผลกระทบเชิงลบ” การพูดว่า “ขอโทษนะ ผมไม่อยากทำให้คุณรู้สึกแบบนั้น ผมจะเปลี่ยนคำนั้น” แล้วเดินหน้าต่อ เป็นเรื่องธรรมชาติมากและไม่ยากเลย
หรือจะเถียงเรื่องเจตนาทั้งวันว่าผมไม่ได้หมายความแบบนั้น พร้อมมองข้ามผลกระทบจริงโดยสิ้นเชิง และทิ้งให้อีกฝ่ายรู้สึกว่าคุณไม่สนใจความรู้สึกของพวกเขาก็ได้
โดยเฉพาะในความสัมพันธ์ส่วนตัว ผมแนะนำอย่างยิ่งให้โฟกัสที่ ผลกระทบ มากกว่าเจตนาเวลาขอโทษ
บทความนี้ดูเต็มไปด้วย ความประหม่าเรื่องตัวตนและความถูกต้องทางการเมือง มากเกินไป
ผู้เขียนเซ็นเซอร์ตัวเองในข้อเสนอเชิงนโยบายและข้อสังเกตทางสังคม/วัฒนธรรม ซึ่งโดยส่วนตัวแล้วผมมองว่าสิ่งเหล่านั้น โดยเฉพาะมุมมองแปลก ๆ ที่ก่อให้เกิดการเปลี่ยนแปลง เป็นเรื่องน่าสนใจทั้งในการเขียนและการอ่าน
การบล็อกเรื่อง dig ก็ค่อนข้างน่ารำคาญ และทำให้ผู้เขียนดูเหมือนคนที่ลั่นไกเร็วเกินไป
ผมยังเห็นด้วยว่าคอมเมนต์ที่วิพากษ์วิจารณ์แม้เพียงเล็กน้อยในเธรดนี้ถูกโหวตลงไปต่ำกว่า 0 กันหมด
คอมเมนต์ของผมก็เช่นกัน และใน HN เป็นเรื่องปกติที่คอมเมนต์เชิงวิจารณ์จะถูกมองข้ามจนไม่ได้ upvote แต่การกดทุกอย่างที่วิจารณ์แม้เพียงนิดให้ต่ำกว่า 0 นั้นถือว่าหาได้ยากแม้ตามมาตรฐาน HN
บทความเกี่ยวกับการเซ็นเซอร์ตัวเองดูเหมือนจะดึงดูดผู้อ่านที่ต้องการโลกใหม่แปลก ๆ แห่งความประหม่าเรื่องตัวตน ที่ทุกคนต้องพยักหน้าเห็นพ้องให้กันและกัน
นักเขียนที่ดีจะคำนึงเสมอว่าการเลือกใช้คำจะส่งผลต่อผู้อ่านอย่างไร
คุณกำลังบอกว่านั่นเป็นเรื่องแย่หรือ?
คุณแค่มีความสนใจต่างกันเท่านั้น
ประเด็นที่ว่าลั่นไกเร็วในตัวอย่าง dig นั่นแหละคือหัวใจสำคัญ
ผู้เขียนกำลังเตือนว่าเราควบคุมได้ว่าจะเห็นอะไร และควรใช้สิทธิ์ควบคุมนั้น
สำหรับคนส่วนใหญ่ มีบางหัวข้อที่ยากจะเข้าร่วมถกเถียงอย่างสร้างสรรค์ และนั่นก็ไม่เป็นไร
ผมคิดว่าควรเก็บพลังงานไว้กับหัวข้อเหล่านั้น แล้วไปเขียนต่อในหัวข้อที่ใช้พลังงานได้ดีจะดีกว่า
upvote มักถูกใช้แทนการเห็นด้วย ส่วน downvote ถูกใช้แทนการไม่เห็นด้วย
อาจมีแนวคิดอื่น ๆ ว่าการโหวตควรหมายถึงอะไร แต่โดยธรรมชาติของระบบโหวตแล้ว มันไหลไปทางนั้นได้ง่าย
คล้ายกับที่ผมอยากให้ผู้คนให้คะแนน 3/5 เป็นค่าเริ่มต้น แทนที่จะเป็น 5/5 แต่ในความเป็นจริงเหมือนจะมีแค่ IMDb เท่านั้นที่เป็นแบบนั้น
น่าอายที่เพิ่งมารู้วันนี้ว่า dig เป็นตัวย่อ และย่อมาจากอะไร
เครื่องมือบรรทัดคำสั่งแทบทั้งหมดที่ชื่อไม่ชัดเจนล้วนเป็นตัวย่อ เช่น grep, cd, pwd, dd, yacc
ผมมีบล็อกส่วนตัวที่เขียนเฉพาะหัวข้อเชิงวิชาชีพอย่างเคร่งครัด และมีอีกบล็อกที่ใช้นามปากกาไว้เขียนความคิดเห็นที่คนอื่นอาจไม่ชอบ
การมี ตัวตนเงา ทำให้มีพื้นที่ที่สามารถ “ผิด” ได้เมื่อจำเป็น