คิดตรรกะ แบบนักกลยุทธ์

ตรรกะ ฟังดูเหมือนอะไรที่แห้งแล้งใช่มั้ย เหมือนนักวิทยาศาสตร์แว่นหนาเตอะที่เขียนสูตรบนกระดานดำ ไม่ก็ คิดถึงคณิตศาสตร์กับห้องเรียนที่เงียบกริบรึเปล่า?

แต่เดี๋ยวก่อน! ถ้าคุณรู้จักตรรกะในแบบที่มือวางอันดับหนึ่งด้านกลยุทธ์ใช้กัน มันจะกลายเป็นเครื่องมือวิเศษในการวิเคราะห์ข้อมูล เล่าเรื่อง และโน้มน้าวคนอย่างมืออาชีพ!

เรามารู้จัก 3 ประเภทของตรรกะ ที่แยกความคิดแบบ นักวิเคราะห์หัวแหลม ออกจาก นักเล่าเรื่องเจ้าเสน่ห์ กันดีกว่า

1. Deductive Logic (ตรรกะนิรนัย)

จากทั่วไป → สู่เฉพาะ

คิดแบบนักสืบโคนันหรือเชอร์ล็อก โฮล์มส์! ตรรกะแบบนี้เริ่มจากความจริงที่กว้าง แล้วไล่เรียงลงมาสู่ข้อสรุปเฉพาะอย่างชัดเจน

ความเจ๋ง: ให้ “ความแน่นอน” เพราะถ้าเหตุผลทั้งหมดถูกต้อง ข้อสรุปก็ถูกชัวร์!

ตัวอย่าง:

• สินค้าของเราราคาแพง

• สินค้าแพงดึงดูดลูกค้าที่มีรายได้สูง

• ดังนั้น สินค้าของเราน่าจะเหมาะกับกลุ่มลูกค้ารายได้สูง

2. Inductive Logic (ตรรกะอุปนัย)

จากเฉพาะ → สู่ทั่วไป

แนวคิดแบบนักทดลอง หรือพวกที่ชอบดูเทรนด์แล้วเอามาโยงภาพรวม! เริ่มจากสิ่งเล็กๆ หลายอย่าง แล้วค่อยๆ มองเห็นภาพใหญ่

ความเจ๋ง: ใช้ “ความน่าจะเป็น” ช่วยวิเคราะห์ เหมาะกับการวางแผนเชิงกลยุทธ์

ตัวอย่าง:

• 3 แคมเปญล่าสุดที่เรามีฟีดแบคเร็ว ผลตอบรับดี

• แสดงว่าฟีดแบคเร็วมีผลดีต่อผลลัพธ์

• สรุป: ฟีดแบคเร็ว น่าจะ ทำให้ผลลัพธ์ดีขึ้น

3. Abductive Logic (ตรรกะอภินิรนัย)

จากข้อมูลกระจัดกระจาย → สู่การเดาอย่างมีเหตุผล

นี่คือวิธีคิดแบบนักสืบสายอาร์ต หรือผู้บริหารที่ต้องตัดสินใจไวในภาวะที่ไม่แน่ชัด มองข้อมูลต่างๆ แล้ว “เชื่อมโยง” หาข้อสรุปที่น่าจะใช่ที่สุด

ความเจ๋ง: ใช้ “สัญชาตญาณเชิงตรรกะ” — ดีไซน์การคาดเดาให้มีน้ำหนัก

ตัวอย่าง:

• ยอดขาย Q3 ดรอป

• มีคู่แข่งเปิดตัวช่วงนั้นพอดี

• สรุป: คู่แข่งเปิดตัว น่าจะ ทำให้ยอดเราตก

แล้วแบบไหนดีกว่ากัน?

จริง ๆ แล้ว ทั้ง 3 แบบ ดีหมด ถ้าใช้ให้ถูกบริบท!

• ถ้าอยากให้ข้อสรุปแม่นยำไร้ข้อกังขา → ไป Deductive

• ถ้าอยากวิเคราะห์เทรนด์หรือพฤติกรรมในอนาคต → ลอง Inductive

• ถ้าอยู่ในสถานการณ์ไม่ชัดเจนแต่ต้องตัดสินใจเลย → ต้องใช้ Abductive

สรุปง่าย ๆ:

• Deductive: เป๊ะ! มั่นใจได้

• Inductive: วัดใจจากข้อมูล

• Abductive: เชื่อมโยง สังเคราะห์ ฉับไว!

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

อีก 10 ปี AI จะแทนที่หมอได้จริงหรือ?

ใน 10 ปีข้างหน้า เราจะยังต้องไปหาหมออยู่ไหม หรือเราจะพิมพ์คำถามใส่แอป AI แล้วได้คำตอบรักษาโรคทันที?

คำถามที่ดังขึ้น เมื่อคนดังอย่าง Bill Gates เคยทำนายว่า “ภายใน 10 ปี AI จะให้คำแนะนำทางการแพทย์ได้ในระดับผู้เชี่ยวชาญ และจะเปลี่ยนวิธีที่เราพบหมอไปตลอดกาล”

เขาใช้คำว่า “free intelligence” — ความฉลาดที่แพร่หลายโดยไม่ต้องเสียเงิน

ประจวบกับ ผมไปพบ VC ท่านนึง เป็นการนัดพบปะกันโดยการเตรียมงานของ อุทยานวิทยาศาสตร์ภาคเหนือ นั้นก็เป็นคำถามเดียวกัน คุณคิดว่า solution telemedicine ของคุณ จะยังต้องการอีกเหรอ ในเมื่ออีก 10 ปี ก็ไม่ต้องการหมอสักเท่าไหร่แล้ว

มันเป็นเรื่องง่ายขนาดนั้นเลย ที่อยู่ ๆ AI มาแทนแพทย์ หรือ ในความเป็นจริงอาจยากกว่านั้น—เพราะการ “แทนที่” หมอ ไม่ได้มีแค่เรื่องความรู้ แต่รวมถึง การตัดสินใจที่ซับซ้อน, การสื่อสารกับคนไข้, และความเข้าใจความรู้สึกมนุษย์ ซึ่งเป็นสิ่งที่ AI ยังทำไม่ได้ 100%

ก่อนจะไปจุดนั้น เรามาดูจุดนี้กันว่า AI ทำอะไรแล้วบ้าง

AI เก่งอะไรแล้วบ้าง?

1. การวิเคราะห์ข้อมูลขนาดใหญ่
   AI อ่านภาพเอกซเรย์หรือ MRI ได้เร็ว และบางครั้งแม่นยำกว่ารังสีแพทย์ในงานวิจัย แต่ยังต้องมีหมอตรวจสอบซ้ำ เพื่อกันความผิดพลาดจากบริบทเฉพาะคนไข้

2. ช่วยงานเอกสารและการจดบันทึก
   ระบบ AI บันทึกข้อมูลคนไข้หรือช่วยสรุปเวชระเบียน ทำให้หมอมีเวลามากขึ้นสำหรับการดูแลคนไข้จริง ๆ

3. คาดการณ์ความเสี่ยง
   AI สามารถประเมินความเสี่ยงโรคเรื้อรัง เช่น เบาหวาน หรือหัวใจ ได้จากข้อมูลสุขภาพและพฤติกรรม

แต่ AI ยังขาดอะไร?

• ความเข้าใจมนุษย์ (Empathy): เวลาหมอบอกผลตรวจหรือข่าวร้าย สิ่งที่คนไข้ต้องการคือ “คนที่ฟังและเข้าใจ” ไม่ใช่เสียงหุ่นยนต์ ซึ่งแน่นอนว่า ตอนนี้คนก็เริ่มจะคุยกับ AI บ้าง แต่ต้องอาศัยความเชื่อใจและข้อมูลกันอีก

• การตัดสินใจในสถานการณ์ซับซ้อน: ห้องฉุกเฉินคือสนามทดสอบที่ AI ยังไม่พร้อม เพราะต้องตัดสินใจในเสี้ยววินาที โดยมีข้อมูลไม่ครบ เป็น เพราะ ER อาศัยข้อมูล ดังนั้น การประมวลผลจะมีปัญหา

• ความรับผิดชอบและกฎหมาย: ถ้า AI วินิจฉัยผิด ใครรับผิดชอบ? หมอ? บริษัท AI? หรือไม่มีใครเลย?

มาดูข้อมูลจากแหล่งต่าง ๆ กัน

สำรวจจากงานวิจัย & การสำรวจผู้เชี่ยวชาญ

1. การสำรวจนักวิจัย AI/Machine Learning

• ผลสำรวจปี 2017 โดย Grace และคณะ พบว่า AI มีความน่าจะเป็นสูง (50%) ที่จะสามารถทำงานเป็น ศัลยแพทย์ ได้ดีพอในปี 2053 arXiv

• การสำรวจในปี 2022–2024 ก็มีแนวโน้มคล้ายกัน: AI มีโอกาส 10% ที่จะความสามารถสูงกว่าคนในทุกงานภายในปี 2027 และ 50% ภายในปี 2047 แต่การแทนที่คนทั้งหมดในงานต่าง ๆ คาดว่าจะเกิดในราวปี 2116 arXiv

2. สำรวจแพทย์เฉพาะด้านจิตเวช

• จากแพทย์จิตเวช 791 คนใน 22 ประเทศ มีเพียง 3.8% ที่เชื่อว่า AI จะให้การดูแลด้วยความเข้าใจ (empathetic care) ได้เต็มรูปแบบ

• แต่พอถามถึงงานเอกสารหรือช่วยวินิจฉัย กลับมองว่า AI มีศักยภาพแซงหน้ามนุษย์ได้ในบางด้าน arXiv

3. รายงานจาก AMA (สมาคมแพทย์อเมริกัน)

• AMA เสนอว่า AI จะเปลี่ยนทุกอย่างในวงการแพทย์โดยแพทย์ที่ใช้ AI จะมีความได้เปรียบกว่าแพทย์ที่ไม่ใช้

• แต่ก็มีความกังวลเรื่อง bias, ความเป็นส่วนตัว, ความรับผิดชอบ และ AI ที่ให้คำแนะนำผิดได้ American Medical Association

4. บทวิเคราะห์ในวารสารการแพทย์

• ความเปลี่ยนแปลงของการจ้างงานในวงการแพทย์อาจไม่เกิดขึ้นอย่างมีนัยสำคัญภายใน 20 ปีข้างหน้า เนื่องจากข้อจำกัดของข้อมูล, regulation และ technical challenges PMC

เรามาคาดการณ์ในแต่ละช่วงเวลากัน

5 ปีแรก (วันนี้–2030)

• AI จะ เป็นผู้ช่วยอัจฉริยะ ให้หมอ เช่น สรุปผลตรวจ, คัดกรองผู้ป่วย, วิเคราะห์ภาพถ่ายทางการแพทย์

• หมอที่ใช้ AI จะทำงานได้เร็วและแม่นยำกว่าเดิม

• ผู้ป่วยบางกลุ่มอาจใช้ AI chatbot ก่อนมาโรงพยาบาล เพื่อรับคำแนะนำเบื้องต้น

10 ปีข้างหน้า (2035)

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

• แต่หมอจะยังเป็นคน ตีความผล AI, วางแผนการรักษาซับซ้อน และให้กำลังใจคนไข้

• คลินิกบางแห่งอาจมี “หมอคู่ AI” — หมอคนเดียว แต่มีระบบ AI คอยเสริมเบื้องหลังทุกขั้นตอน

30 ปีข้างหน้า (2050)

• อาจมี AI ที่ทำผ่าตัดหรือดูแลโรคซับซ้อน แต่ภายใต้การกำกับของหมอ

• หมอในอนาคตอาจกลายเป็น “ผู้ควบคุมระบบ AI” มากกว่าทำทุกอย่างเอง

หมอจะหายไปไหม?

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

นั้นก็คือเหตุผลที่ AI ไม่ได้มาทดแทนแพทย์ได้ แต่ในอนาคต จะมีอะไรเปลี่ยนแปลงไปอีกเล่า ใครจะไปรู้

11 ตรรกะหลอก ให้ตกหลุมพลางทางความคิด

เรามักคิดว่าเราคิดถูก... แต่บางครั้ง สิ่งที่หลอกเรามากที่สุดคือ "ตรรกะที่ผิด" ซึ่งแฝงมาในรูปของเหตุผลดูดี มีน้ำหนัก และน่าเชื่อถือ

Carl Sagan นักวิทยาศาสตร์และนักดาราศาสตร์ผู้ยิ่งใหญ่ เคยรวบรวมสิ่งที่เขาเรียกว่า
"11 กับดักทางความคิด" หรือ "11 ตรรกะหลอก" ที่เราทุกคนควรระวังไว้ให้ดี:

1. โจมตีตัวบุคคลแทนการโต้แย้งประเด็น (Ad hominem)

2. เชื่อเพราะผู้พูดมีอำนาจหรือชื่อเสียง (Argument from authority)

3. ไม่มีหลักฐานว่าไม่จริง = ต้องเป็นจริง (Appeal to ignorance)

4. แก้ตัวแบบเลี่ยงบาลี หลบความขัดแย้ง (Special pleading)

5. ตั้งสมมุติฐานไว้ในคำถามที่ยังไม่ได้พิสูจน์ (Begging the question)

6. เลือกจำแต่สิ่งที่เข้าข้างตัวเอง ลืมสิ่งที่ขัดแย้ง (Observational selection)

7. ใช้ตัวอย่างหรือข้อมูลจำนวนน้อยเกินไปในการสรุป (Statistics of small numbers)

8. สับสนระหว่าง “สิ่งที่เกิดร่วมกัน” กับ “สาเหตุที่แท้จริง” (Correlation ≠ Causation)

9. คิดแบบสุดโต่ง เห็นแค่ “ขาว” หรือ “ดำ” ไม่มีทางสายกลาง (False dichotomy)

10. บิดเบือนมุมมองของอีกฝ่ายให้ดูแย่ แล้วโจมตี (Straw man)

11. ใช้คำพูดกำกวม คลุมเครือ เพื่อเบี่ยงเบนหรือบิดความหมาย (Weasel words)

หลายข้อในนี้ สอดคล้องกับสิ่งที่พระพุทธเจ้าทรงสอนไว้เช่นกัน — อย่าด่วนเชื่อสิ่งใดด้วยอคติ ไม่ว่าจะเป็นเพราะ "เขาเป็นใคร" หรือ "เรารู้สึกชอบ"

จะเชื่ออะไร…จงตรึกตรองให้ดี
จะคิดอะไร…จงรู้ทันความคิดของตัวเอง

พลังแห่งปัจจุบัน - และ การเฝ้าดูความคิด

อจ. พบคนไข้ซึมเศร้ามาก ทั้งที่ไม่ใช่จิตแพทย์ ตอนแรกคิดว่า เฮ้อ เพราะเป็นกฎของแรงดึงดูด แต่ถามหมอคนอื่น ๆ ก็บอกเหมือนกัน

เหมือนว่า โรคซึมเศร้า เป็นโรคติดต่อ หรือ เป็นโรคของสังคมที่ป่วย แน่นอนว่า มันยังไม่สามารถจับเหตุได้ ว่าทำไมสังคมของเราถึงป่วยยกใหญ่ ราวกับว่ามันฝังอยู่ในทุกซอกมุม บ้างโทษเศรษฐกิจ บ้างโทษเลี้ยงดู บ้าง social media หรือไม่ก็นู่น PM 2.5

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

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

The Power of Now ที่เขียน โดย Eckhart Tolle มีคำที่สรุปด้วยประโยคเพียงหนึ่งว่า:

“The moment you realize you are not present, you are present.”

“เมื่อคุณรู้ตัวว่าคุณไม่ได้อยู่กับปัจจุบัน นั่นแหละคือคุณอยู่กับปัจจุบันแล้ว”

ใจความสำคัญ:

คุณไม่ใช่ความคิดของคุณ เมื่อเรามักหลงอยู่ในความคิด: วางแผน อดีต อนาคต ความกังวล การตำหนิตัวเอง เราคิดออกไปไกล คิดว่า นั่นคือทางที่ดี แต่ปัจจุบัน เรากลับลืม

สิ่งที่จะทำให้ดึงความคิดกลับมาได้ นั่นคือ Witnessing Presence หรือ พลังแห่งการเฝ้าดู

Tolle เรียกสิ่งนี้ว่า “พลังของผู้เฝ้าดู” หรือ witnessing presence — ความรู้สึกตัวที่ไม่ตัดสิน น่าสนใจไหม

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

การฝึกสังเกตความคิด ความเครียด ความโกรธ โดยไม่กลืนไปกับมัน คือการฝึกอยู่กับ “ตอนนี้” เหมือนกัน เมื่อเฝ้าดู จะไม่ตัดสิน และจะสงบดี

หลายคนคิดว่า การเฝ้าดูและอยู่กับปัจจุบันคือการ ภาวนา

นั่นอาจไม่ใช่เสมอไป

การฝึกอยู่กับปัจจุบัน ไม่ใช่เฉกเช่นเดียวกับการ “นิ่งสงบ”

บางครั้งมันคือการต่อสู้กับความคิดภายในตัวเอง

มันไม่สมบูรณ์แบบ แต่มันจริง และเปลี่ยนชีวิตได้

อย่าสร้างตัวตนจากความคิดหรืออารมณ์

“คุณไม่ใช่ความวิตกกังวลของคุณ”

“คุณไม่ใช่อดีตของคุณ”

“คุณไม่ใช่เสียงในหัวคุณ”

ความสงบไม่ได้มาจากการคิดดีขึ้น แต่จากการ "ไม่เป็น" ความคิดนั้น

ระหว่าง ความคิด และ การตื่นรู้ มี ทางเลือก และมี อิสรภาพ

ประโยคทองคำจาก Eckhart Tolle:

“Always say ‘yes’ to the present moment. What could be more futile, more insane, than to create inner resistance to what already is?”

“จงพูดว่า ‘ใช่’ กับปัจจุบันเสมอ มีอะไรจะไร้สาระไปกว่าการต่อต้านสิ่งที่มัน ‘เป็น’ ไปแล้ว?”

ตอนนี้เป็นตอนเช้า หลาย ๆ คนก็ต้องตื่นไปทำงาน บทความเรียบ ๆ ง่าย ๆ สั้น ๆ อาจเปลี่ยนวิธีคิดของเราได้

- อจ สุรัตน์

จงทำให้เรียบง่ายในความซับซ้อน

ภาพการ์ตูนที่เต็มไปด้วยสิ่งประดิษฐ์เครื่องจักรทำงานไปตามขั้นตอน เพื่อไปจบกับการช่วยทำสิ่งง่าย ๆ อย่างกินข้าว ถอดเสื้อผ้า ผลิกหน้าหนังสือ

มันคือการ์ตูน “Rube Goldberg Machine เครื่องจักรของ รูบ โกลด์เบิร์ก” ซึ่งเป็นสิ่งประดิษฐ์ล้อเลียนที่ใช้กลไกซับซ้อนเป็นสิบขั้นตอน เพียงเพื่อทำสิ่งง่าย ๆ ดูแล้วก็เออ มันคิดได้นะ บางคนก็คิดว่า จะทำให้มันยากทำไม ทำให้มันง่ายก็จบเรื่องแล้ว ในใจก็บางทีก็สนุกกับ process

ไม่รู้ว่า นักวาดการ์ตูนตั้งใจเสียดสีสังคมหรือเปล่า แต่เราก็เห็นโลกแห่งความเป็นจริง โลกขององค์กรสมัยใหม่ที่เต็มไปด้วยโครงสร้าง ระบบ และขั้นตอนที่สลับซับซ้อน (ซึ่งบางที มันเพื่อมาตอบสนองสิ่งง่ายๆ อะนะ) การใช้ทรัพยากรมหาศาล กระบวนการชื่อแปลก ๆ เพื่อบรรลุเป้าหมายธรรมดา กลายเป็นเรื่องปกติไปเสียแล้ว เพราะองค์กรใหญ่ที่ซับซ้อนเลยต้องใช้ระบบที่ซับซ้อนหรือเปล่า เอาความซับซ้อนมาแก้ปัญหาอันซับซ้อน เหมือนพิษแก้พิษในหนังจีน หรือ เอาจริง ๆ เป็นแค่ความสุขของกระบวนการคิด

บางครั้ง ความซับซ้อนมันก็หลีกเลี่ยงไม่ได้ แต่บางครั้งมันเป็นกับดัก—เป็นการสร้างภาพของความจริงจัง ตามมาด้วยภาพมโนงง ๆ กับผลลัพย์ที่อยากได้ อยากถามนะ ทำไมไม่ทำให้มันง่ายวะ มันทำไม่ได้ หรือเราเสพติดกระบวนการ

Steve Jobs กล่าวว่า

“ความเรียบง่ายนั้นยากกว่า เพราะต้องคิดอย่างละเอียดกว่าจึงจะทำให้มันเรียบง่ายได้”

มนต์เสน่ห์แห่งความซับซ้อน

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

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

รายงานจาก Harvard Business Review ปี 2016 ระบุว่า ในช่วง 50 ปีที่ผ่านมา องค์กรทั่วโลกมีความซับซ้อนเพิ่มขึ้นเกือบ 7 เท่า — แต่ประสิทธิภาพแทบไม่เปลี่ยน

“องค์กรที่เติบโตมักจะหลงติดกับการรักษาระบบเดิม มากกว่าการปรับให้เรียบง่ายและมีประสิทธิภาพ”

งานวิจัยใน Annals of Internal Medicine พบว่า
แพทย์ใช้เวลาหนึ่งชั่วโมงกับคนไข้ แต่ต้องใช้เวลาเกือบสองชั่วโมงกับระบบเอกสารในคอมพิวเตอร์ เมื่อมาตรฐานทำให้ตกมาตรฐาน มันคือตัวอย่างความจริง ตัวหนังสือ เอกสารมากขึ้น เวลามองหน้าคนไข้น้อยลง

สิ่งที่ควรช่วยให้เรียบง่าย กลายเป็น กลไกซับซ้อนแบบรูบ โกลด์เบิร์ก ที่กินพลัง

จริง ๆ มันก็มีเหตุผลว่า ทำไมองค์กรถึงติดกับดักความซับซ้อน

1. ความกลัวที่จะพลาดหรือล้มเหลว
   ระบบที่ซับซ้อนมักถูกสร้างขึ้นเพื่อ “กันความผิด” มากกว่าการทำให้ดี

2. โครงสร้างองค์กรแบบไซโล (Silo)
   แผนกต่าง ๆ ต่างออกแบบระบบเพื่อประโยชน์ของตนเอง ไม่ได้คิดถึงภาพรวม

3. วัดผลด้วยกิจกรรม ไม่ใช่ผลลัพธ์
   การมี KPI จำนวนมาก ทำให้เน้นว่า “ทำอะไรไปแล้วบ้าง” มากกว่า “ได้ผลลัพธ์หรือไม่” มันเหมือน to do list เพื่อเรียกความสบายใจ และ public white board ที่เขียนโชว์ว่า ฉันทำตามระบบแล้วนะ

4. ระบบเดิมที่สั่งสมจนยุ่งเหยิง
   องค์กรมักจะเพิ่มระบบใหม่โดยไม่ล้างของเก่า กลายเป็นการซ้อนทับโดยไม่รู้ตัว เรียกว่า ขาดแม่บ้านที่คอยทำความสะอาดระบบ

ความซับซ้อน แน่นอนว่า ผลดีมันก็มี แต่ผลเสียก็มีตามมาเช่นกัน

ราคาที่ความซับซ้อนต้องจ่าย

• ช้า: ใช้เวลาตัดสินใจนานขึ้น โดยเฉพาะในสถานการณ์วิกฤต

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

• ขัดขวางนวัตกรรม: ไอเดียใหม่ ๆ มักจะถูกฆ่าตายด้วยกระบวนการ

• สร้างภาพลวงตาของการทำงาน: พนักงานทำตามระบบแค่ “ให้ผ่าน” ไม่ได้สร้างคุณค่า

พลังของความเรียบง่ายอย่างตั้งใจ

Jeff Bezos ผู้ก่อตั้ง Amazon เคยตั้งกฎว่า "ทีมหนึ่งต้องเลี้ยงได้ด้วยพิซซ่าสองถาด" เพื่อให้การสื่อสารคล่องตัวและไม่ต้องผ่านระบบเยิ่นเย้อ
Toyota เองก็ใช้หลักการ “Lean” โดยให้พนักงานหยุดสายการผลิตได้ทันทีเมื่อพบปัญหา — ความเรียบง่ายนี้คือกุญแจของความยืดหยุ่น

ความเรียบง่ายที่แท้จริงคือการเข้าใจความซับซ้อน และเลือกสิ่งที่จำเป็นเท่านั้น

เอาหละ ในเมื่อโลกถูกสร้างมาแบบนี้ เรามารู้แนวทางสร้างวัฒนธรรมแห่งความเรียบง่าย (แต่ไม่เสี่ยง) กันดีไหม

1. เริ่มจากผลลัพธ์: มองย้อนกลับจากเป้าหมาย เพื่อหาทางที่ตรงและเร็วที่สุด

2. ลดขั้นตอนตัดสินใจ: ให้อำนาจคนหน้างานมากขึ้น

3. ล้างระบบซ้ำซ้อน: ทบทวนกระบวนการอย่างสม่ำเสมอ

4. ทดสอบจริง: ลองทำภารกิจด้วยตัวเอง หรือให้คนนอกลอง แล้วฟังเสียงสะท้อน

5. ให้รางวัลกับความเรียบง่าย: ยกย่องคนที่ทำให้สิ่งต่าง ๆ ง่ายลง

6. สร้างระบบที่ลดความซับซ้อนลงได้ เช่น ใช้ เทคโนโลยีช่วย automate

เรากำลังสร้างโบสถ์ หรือ เขาวงกต?

ในยุคที่เทคโนโลยีสามารถทำให้ทุกอย่างเร็วขึ้น ทำไมหลายองค์กรยังต้องประชุม 5 รอบ เพื่อซื้อไวท์บอร์ดแผ่นเดียว? หรือมีแดชบอร์ด 10 ตัวเพื่อตัดสินใจเรื่องเล็ก ๆ?

เรากำลังแก้ปัญหาจริง ๆ — หรือแค่สร้างเครื่องจักรเพื่อให้รู้สึกว่าเรากำลังทำงาน? ลองถามตัวเอง

นอนไม่หลับ สมองจะสะสมขยะ

ตื่นมาสมองมันล้า หากล้านาน ๆ ก็สมองเสื่อม เพราะมีสารพิษสะสมมากเกินไป มันเหมือนขยะ ที่ล้วนทำลายสมอง

ระบบไกลม์ฟาติก (Glymphatic System) คือระบบ “ล้างสมอง” ขณะนอนหลับ ทำหน้าที่กำจัดของเสียออกจากสมอง โดยเฉพาะในช่วง หลับลึก (slow-wave sleep) ซึ่งเป็นช่วงที่ของเหลวในสมองไหลเวียนดีที่สุด และช่วยทำความสะอาดสมองเหมือนระบบแม่บ้านจอมขยัน

เรามารู้สารสำคัญที่ระบบไกลม์ฟาติกช่วยล้างออกจากสมองขณะนอนหลับ:
1. เบต้า-อะไมลอยด์ (β-amyloid)
โปรตีนที่เมื่อสะสมมากเกินไปจะจับตัวเป็นคราบในสมอง (amyloid plaques)
เกี่ยวข้องกับโรคอัลไซเมอร์
ระบบไกลม์ฟาติกจะช่วยล้างออกในช่วงที่นอนหลับ โดยเฉพาะช่วงหลับลึก

2. โปรตีนเทา (Tau protein)
โปรตีนที่ถ้าสะสมผิดปกติจะทำให้เซลล์สมองเสื่อม
พบมากในโรคทางสมอง เช่น อัลไซเมอร์
การนอนหลับช่วยกำจัดโปรตีนเทาที่เกินความจำเป็น

3. แลคเตท (Lactate)
ของเสียจากกระบวนการเผาผลาญพลังงานในสมอง
ระดับแลคเตทลดลงชัดเจนขณะนอนหลับ แสดงว่าถูกกำจัดออก

4. สารอนุมูลอิสระ และของเสียจากปฏิกิริยาออกซิเดชัน (ROS)
เกิดจากการทำงานของสมองและความเครียด
การสะสมอาจทำลายเซลล์ประสาท
ระบบไกลม์ฟาติกช่วยล้างออก ลดความเสี่ยงการอักเสบและเสื่อมของสมอง

5. ของเสียจากการสลายของสารสื่อประสาท
เช่น กลูตาเมต และโดปามีน
การขจัดของเสียเหล่านี้ช่วยรักษาสมดุลของสมอง

เราหลับ สมองไม่หลับ มันเปิด “ช่องทางลับ” ให้ของเหลวในสมองไหลผ่านอย่างรวดเร็ว เพื่อกำจัด โปรตีนพิษ สารตกค้าง และของเสียต่าง ๆ แม่บ้านจอมขยันนี่เยี่ยมจริง ๆ แต่หาก นอนมากไป ก็ไม่ดีนะ แม่บ้านก็ล้างเสร็จไปแล้ว สมองเราต้องตื่นมาทำงาน นอนให้อยู่ในช่วง 7-9 ชั่วโมง

- อจ สุรัตน์

10 พนักงานแบบนี้ กดปุ่มเอาออกไป

พนักงานแบบนี้ กดปุ่มเอาออก หนีให้ไกล

1. Deadwood

• เคยมีประโยชน์ แต่หมดไฟ

• ไม่ทำงาน ไม่พัฒนา และไม่ยอมไปไหน

“Consumes space, not value.”

⸻

2. Corrupt Intellectual

• ฉลาด มีความรู้ แต่ไร้จริยธรรม

• ใช้ความคิดเพื่อผลประโยชน์ส่วนตัว ทำลายระบบ

“Knows the rules — and twists them for gain.”

3. Diligent Fool

• ขยันเต็มที่ แต่คิดไม่เป็น

• ทำผิดซ้ำซาก สร้างภาระโดยไม่รู้ตัว

“Efficiently wrong, persistently harmful.”

4. Toxic High Performer

• ผลงานดี แต่ทำลายคนรอบตัว

• พฤติกรรมเห็นแก่ตัว ทำให้คนเก่งลาออก

“Keeps clients but kills culture.”

⸻

5. Insecure Saboteur

• กลัวคนอื่นเก่งกว่า คอยบ่อนทำลายเพื่อนร่วมงาน

• ปิดโอกาสคนอื่นเพื่อรักษาตำแหน่งตัวเอง

“They don’t grow — and won’t let others grow either.”

⸻

6. Chronic Victim / Passive-Aggressive

• ไม่เคยรับผิดชอบอะไร โทษแต่ระบบและคนอื่น

• ปิดกั้นการเปลี่ยนแปลง ใช้ความเงียบเป็นอาวุธ

“Yes on the outside, no on the inside.”

⸻

7. Ghost Employee

• อยู่ในระบบ แต่ไม่มีตัวตนจริง ไม่ทำงานจริง

• บางครั้งเป็น “เด็กเส้น” หรือคนที่ไม่มีใครกล้าแตะ

“They drain salary and oxygen — but never show results.”

⸻

8. Credit Stealer

• ชอบเอาผลงานคนอื่นไปเสนอแทนตัวเอง

• ทำลายความไว้วางใจในทีม

“Where there’s success, they appear. Where there’s failure, they vanish.

9. Chameleon Opportunist

ฉลาด ปรับตัวเก่ง แต่ไร้หลักการ พร้อมเปลี่ยนข้างตามอำนาจหรือผลประโยชน์

• ต่อหน้าผู้บริหาร: ปรับลุคเป็นมืออาชีพ

• ลับหลัง: บิดเบือนข้อมูล สร้างเกมการเมือง

• ไม่ยึดถือเป้าหมายองค์กร แต่เน้น “อยู่รอด” และ “ไต่เต้า”

“They play every side — except the side of integrity.”

⸻

10. Innovation Killer (หรือ Bureaucratic Blocker)

คนที่ต่อต้านการเปลี่ยนแปลงทุกอย่าง ด้วยเหตุผลว่า “เราทำแบบนี้มาตลอด”

• ปิดกั้นไอเดียใหม่ แม้จะดี

• มักอ้างระเบียบ ระบบ หรือความเสี่ยง เพื่อเลี่ยงความลำบาก

• ทำลายวัฒนธรรมแห่งการเรียนรู้ (learning culture)

“Not because they hate innovation — but because they fear losing control

การคำนวน ความสามารถด้านนวัตกรรม Innovation Capacity Level-MED CMU

สิ่งที่เราทำอยู่นี่เรียกนวัตกรรมไหม หากใช่ มันเป็นนวัตกรรมที่มีขีดความสามารถไหมนะ?

แน่นอนว่า การวัดความสามารถนวัตกรรม มีหลายวิธี การจำแนก อาจจะเป็น ระดับของนวัตกรรม โดยเฉพาะนวัตกรรมทางเทคโนโลยีที่มักจะใช้ ความโดดเด่นหรือเฉพาะตัว ในการวัด ที่แบ่งเป็น incremental, architectural, disruptive , radical innovation

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

ทาง ศูนย์นวัตกรรมด้านสุขภาพ คณะแพทยศาสตร์ (MedCHIC) ได้พัฒนา การวัดความสามารถด้านนวัตกรรม (Innovation Capacity Level, ICL) ขึ้นมา เพื่อวัดความสามารถด้านนวัตกรรมให้รอบด้านและตอบโจทย์องค์กรขึ้น

คำนิยามระดับความสามารถด้านนวัตกรรม (Innovation Capacity Level - ICL, หรือ MedCHIC ICL)
กรอบการประเมินนี้แบ่งระดับความสามารถด้านนวัตกรรมออกเป็น 4 ชั้น โดยใช้คะแนนรวมจาก 3 มิติ คือ ความแปลกใหม่ (Novelty), ผลกระทบทางธุรกิจ (Business Impact) และ ศักยภาพการขยายผล (Scalability) แต่ละมิติให้คะแนน 1–5 (รวมกันได้ 3–15 คะแนน) แล้วจัดอยู่ในหนึ่งใน 4 ชั้น ดังนี้:

🧪 Innovation Capacity Level (ICL)
ระดับความสามารถด้านนวัตกรรม

1️⃣ ความใหม่ (Novelty)
🔹 คำถาม: นวัตกรรมนี้ใช้เทคโนโลยีหรือวิธีการใหม่เมื่อเทียบกับโซลูชันที่มีอยู่หรือไม่?

-- กรุณาเลือก / Please select -- 1: Not Novel or Low Novelty - ไม่มีเทคโนโลยีหรือวิธีการใหม่ เพียงแค่ปรับปรุงกระบวนการเดิมเล็กน้อย 2: Existing Technology with Improved Efficiency - ใช้เทคโนโลยีเดิมหรือแนวทางเดิม แต่ช่วยเพิ่มประสิทธิภาพ 3: First Adoption in the Organization - นำเทคโนโลยี กระบวนการ หรือบริการที่เป็นที่รู้จักอยู่แล้วมาใช้ในองค์กรเป็นครั้งแรก 4: New technology but not breakthrough - ใช้เทคโนโลยีใหม่ แต่ไม่ได้เป็นการเปลี่ยนแปลงครั้งใหญ่หรือปฏิวัติวงการ 5: Radical New Innovation - เป็นแนวคิดใหม่ทั้งหมด หรือเทคโนโลยีที่ไม่เคยมีมาก่อนในตลาด

2️⃣ ผลกระทบทางธุรกิจ (Business Impact)
🔹 คำถาม: นวัตกรรมนี้ช่วยลดต้นทุน เพิ่มประสิทธิภาพ หรือสร้างโอกาสทางรายได้ได้มากเพียงใด?

-- กรุณาเลือก / Please select -- 1: Minimal or No Business Impact - นวัตกรรมยังไม่มีผลลัพธ์ที่ชัดเจนในเชิงธุรกิจ อาจเป็นเพียงการทดลองหรือแนวคิดเบื้องต้น 2: Localized Efficiency Gains - ลดเวลา ลดขั้นตอน หรือเพิ่มความสะดวกให้ผู้ใช้งาน/ทีมงานบางกลุ่ม แต่ยังไม่มีผลต่อโครงสร้างรายได้หรือต้นทุนขององค์กร 3: Organizational Efficiency Improvement - มีผลต่อหลายหน่วยงาน เช่น ลดต้นทุนการดำเนินงานหรือเวลาได้ชัดเจน หรือช่วยให้ลูกค้ารับบริการได้เร็วขึ้น แต่ยังไม่เกิดรายได้โดยตรง 4: Tangible Economic Outcomes - นวัตกรรมช่วยสร้างรายได้ใหม่ หรือช่วยลดต้นทุนในระดับที่ส่งผลต่อภาพรวมขององค์กร เช่น ค่ารักษาพยาบาลต่อหน่วยลดลง, มีลูกค้าจ่ายเงินจริง 5: Industry-Transforming Innovation - เป็นนวัตกรรมที่สามารถเปลี่ยนโมเดลรายได้ หรือทำให้เกิดการเปลี่ยนแปลงสำคัญในธุรกิจ เช่น กลายเป็นแหล่งรายได้ใหม่, แพลตฟอร์มที่ดึงผู้ใช้ในระยะยาว, ลดค่าใช้จ่ายโครงสร้างอย่างถาวร

3️⃣ ความสามารถในการขยายผล (Scalability)
🔹 คำถาม: นวัตกรรมนี้สามารถนำไปใช้ได้ง่ายและขยายขอบเขตไปสู่องค์กรหรืออุตสาหกรรมอื่น ๆ ได้หรือไม่?

-- กรุณาเลือก / Please select -- 1: Limited Scalability - Small Teams Only - ขยายได้น้อย ใช้ได้เฉพาะในกลุ่มผู้ใช้หรือทีมงานเล็ก ๆ ไม่มีศักยภาพในการขยาย 2: Limited Scalability - Department-Level - ขยายได้จำกัด ใช้ได้ในแผนกเดียว ยังไม่สามารถขยายไปทั้งองค์กรได้ 3: Moderate Scalability - Organization-Wide - ขยายได้ปานกลาง สามารถขยายใช้ได้ทั่วทั้งองค์กร 4: High Scalability - Cross-Industry - ขยายได้สูง สามารถขยายไปยังองค์กรหรืออุตสาหกรรมอื่น ๆ ได้ โดยมีโครงสร้างในการรองรับการเติบโต โดยอาจมีการปรับเปลี่ยนเล็กน้อย 5: Highly Scalability - Global Reach - ขยายตัวได้สูงมาก สามารถขยายไปสู่หลายอุตสาหกรรมหรือทั่วโลกได้โดยไม่มีข้อจำกัด รองรับการใช้งานที่หลากหลาย 🚀 คำนวณคะแนน / Calculate Score

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

อย่าวางรถไฟร้างไว้กลางทุ่ง : เรื่องเล่าของ Product Market Fit

รถไฟกลางป่ากับบทเรียนของตลาดที่พร้อมแล้ว

ในพิพิธภัณฑ์แห่งหนึ่งของ North Carolina มีรถไฟของเล่นธรรมดา ๆ วิ่งวนรอบพื้นที่เล็ก ๆ ไม่มีจุดขายพิเศษ แต่กลับสร้างรายได้เกือบ $250,000 ต่อปี ขณะที่ต้นทุนลงทุนสูงถึง $400,000+ จุดพลิกของความสำเร็จไม่ได้อยู่ที่คุณภาพของรถไฟ แต่คือ "ตำแหน่งที่ตั้ง" ที่มีเด็กและครอบครัวแวะเวียนเข้ามาทุกวัน

“It’s not the product that sells. It’s the presence of people who are ready to buy.”
— Aeron, Tech Entrepreneur

การมีผลิตภัณฑ์ที่ดีแต่ไม่มีใครเห็น เปรียบเสมือนนักเตะที่ฟิตแค่ไหนแต่ไม่มีโอกาสลงสนาม ก็ยิงประตูไม่ได้อยู่ดี

Product-Market Fit ไม่ได้แปลว่า Product ดี แต่แปลว่า Market “พร้อมจะซื้อ”

หลายคนเข้าใจว่า Product-Market Fit หมายถึงการทำสินค้าที่ดีที่สุดเท่าที่จะเป็นไปได้ แต่ความจริงคือมันหมายถึงการ "เอาสินค้าที่ใช่ ไปเสนอในเวลาที่ใช่ ต่อหน้าคนที่พร้อมจะจ่าย"

“Don’t find customers for your products, find products for your customers.”
— Seth Godin

นี่คือกับดักของสตาร์ทอัพหลายเจ้า ที่คิดว่า Product ดีต้องขายได้ โดยลืมไปว่า “ตลาด” คือสิ่งที่ต้องมาก่อน ไม่ใช่สิ่งที่จะตามมาในภายหลัง

กรณีศึกษา: Quibi — แพลตฟอร์มที่เจ๊งเร็วที่สุดในประวัติศาสตร์

Quibi ลงทุนกว่า $1.75 พันล้านดอลลาร์ เพื่อสร้างแพลตฟอร์มวิดีโอสั้นที่ดูผ่านมือถือเท่านั้น แต่ล้มเหลวภายใน 6 เดือนทำไม? เพราะแม้จะมีคอนเทนต์คุณภาพสูงและทีมงานระดับโลก แต่ ไม่มีตลาดที่ต้องการดูวิดีโอแนวนี้ในบริบทที่ Quibi ตั้งใจ นี่คือรถไฟกลางทุ่งร้างอีกหนึ่งขบวน

Business ≠ Product | Business = Learning System

“The real product of a startup is not the product—it’s the learning.”
— Eric Ries, The Lean Startup

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

อย่าสร้างรถไฟกลางทุ่งร้าง

เพราะคุณอาจกำลังทำเหมือนคนที่เห็นรถไฟขายดีในพิพิธภัณฑ์ แล้วทุ่มเงินซื้อรถไฟมาสร้างเอง แต่ลืมว่า...

• พิพิธภัณฑ์คือระบบนิเวศ ที่มี traffic

• เด็กคือกลุ่มเป้าหมายที่อยู่แล้ว

• รถไฟคือการเก็บเงินจากโอกาสที่มีอยู่แล้ว

เปรียบเสมือนธุรกิจที่มีชุมชนก่อน มีคนดู มีความสัมพันธ์ และ สินค้า เป็นเพียง “ช่องทางการเก็บรายได้” จากความเชื่อมั่นที่สร้างมา

Start with Market, Not Just Product

ดังนั้น ก่อนคิดจะสร้างอะไร ให้ถามคำถามสำคัญว่า:

• ใครจะใช้สิ่งนี้ในวันนี้เลย?

• เขามีปัญหานั้นจริงไหม?

• เขาอยากจ่ายเพื่อแก้ปัญหานั้นไหม?

อย่าลืมว่า Innovation ที่ไม่มีคนรอใช้ = ความว่างเปล่า

ข้อคิดจาก Steve Blank: “Get out of the building”

“No business plan survives first contact with customers.”
— Steve Blank

ไม่มีแผนธุรกิจใดที่รอดจากลูกค้าคนแรก ถ้าอยากสร้างสิ่งที่ตลาดต้องการจริง ๆ คุณต้องออกจากห้องประชุม ไปพบคนที่คุณหวังจะขายของให้ และฟังให้มากกว่าพูด

บทส่งท้าย: ถามตัวเองก่อนจะลงทุนใน “รถไฟของตัวเอง”

คุณแน่ใจหรือยังว่า ตลาดกำลังรอรถไฟแบบคุณ?

เพราะบางที สิ่งที่ทำให้เขาขายได้ ไม่ใช่ของดี
แต่คือ คนที่อยู่ตรงนั้น… พร้อมจะซื้ออยู่แล้ว

10 บทเรียนธุรกิจนวัตกรรมจาก Mad Unicorn – จากศูนย์สู่ยูนิคอร์นด้วยสองมือและหัวใจ

คุณไม่จำเป็นต้องมีต้นทุนสูงเพื่อเริ่มธุรกิจนวัตกรรม — แต่คุณต้องมีกึ๋นพอที่จะเปลี่ยนศูนย์ให้กลายเป็นระบบ และเจ็บพอที่จะเรียนรู้ก่อนจะรุ่ง

ซีรีส์ไทยสุดมัน Mad Unicorn (สงครามส่งด่วน) ไม่ใช่แค่ความบันเทิง แต่มันคือบทเรียนชีวิตเข้มข้นจากโลกของธุรกิจจริง ผ่านสายตาของ "สันติ" จากเด็กดอยในลำปาง สู่ผู้ก่อตั้ง Thunder Express บริษัทขนส่งที่กลายเป็นยูนิคอร์นไทย

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

1. เริ่มจากศูนย์ ไม่ใช่ข้อเสีย — ถ้ามันทำให้คุณมองเห็นทุกจุดด้วยตาเปล่า

สันติไม่มีอะไรเลย แต่เพราะไม่มี เขาเลยเห็นชัดว่าอะไรคือปัญหาที่คนมีมองไม่เห็น ใช้ในนวัตกรรม: เข้าใจ Pain Point ของผู้ใช้อย่างลึกซึ้ง โดยไม่ติดกับดักของวิธีคิดเดิม

2. ของที่คุณมีอยู่ อาจไม่หรู — แต่ถ้ารู้จักใช้ มันคือแต้มต่อ

สันติเคยคิดว่าภาษาจีนกลางที่แม่สอนคือเรื่องธรรมดา จนมันเปิดประตูการเงิน การเมือง และการต่อรองทั้งหมด ใช้ในนวัตกรรม: สร้าง USP จากสิ่งที่คู่แข่งมองข้าม เช่น soft skill, culture, connection ภูมิภาค

3. คนที่ทำให้เราพังที่สุด — สอนเรามากที่สุด

เจ้าสัวคนินทำให้เขาล้ม แต่ก็บอกบทเรียนสำคัญเรื่อง first mover ใช้ในนวัตกรรม: เรียนรู้จากคู่แข่งโดยไม่ต้องล้มเอง ถอดบทเรียนจากทั้งความสำเร็จและความล้มเหลวของคนอื่น

4. ความเจ็บอาจแค้นได้ — แต่ต้องแปรให้เป็นกลยุทธ์ ไม่ใช่กับดัก

Thunder Express เกือบพังเพราะตัดราคาด้วยอารมณ์ ไม่ใช่ข้อมูล ใช้ในนวัตกรรม: จงกล้าตัดสินใจ แต่ต้องใช้ข้อมูล ไม่ใช่ความแค้น

5. ทีมที่ดีไม่ใช่ทีมที่เก่งเหมือนกัน — แต่คือทีมที่กล้าคิดไม่เหมือนกันแล้วรวมพลังได้

เสี่ยวหยูเป็น CFO, รุ่ยเจี๋เป็นโปรแกรมเมอร์ สันติเป็นนักวิสัยทัศน์ — คนละทางแต่ใจเดียวกัน ใช้ในนวัตกรรม: รู้จุดอ่อนตัวเอง แล้วเติมเต็มด้วยคนที่กล้าเถียงคุณ

6. เร็วอย่างมีเข็มทิศ ดีกว่าแรงแบบไม่มีเบรก

การขยายสาขาเร็วเกินไปคือบทเรียนความวุ่นวายของ Thunder Express ใช้ในนวัตกรรม: อย่า scale ถ้ายัง validate ไม่ครบ จง iterate ให้พอใจก่อน

7. คำดูถูกคือฟีดแบ็คใน disguise

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

8. ยูนิคอร์นไม่ใช่จุดหมาย — แต่มันคือผลพลอยได้จากระบบที่ใช้ได้จริง

สันติไม่ได้ฝันถึงคำว่า “ยูนิคอร์น” เขาฝันถึงระบบขนส่งที่แม่สามารถจ่ายได้ ใช้ในนวัตกรรม: Focus ที่ value proposition มากกว่า valuation

9. ความกล้าไม่ใช่การไม่กลัว — แต่มันคือการลงมือแม้จะกลัว

สันติกลัวล้มอีกครั้ง แต่เขาก็เดิมพันกับดีล MY ด้วยข้อมูลครบทุกด้าน ใช้ในนวัตกรรม: อย่ารอให้พร้อม 100% เพราะนวัตกรรมไม่มีวันพร้อมจริง

10. เป้าหมายของคุณต้องใหญ่พอ — จนความเหนื่อยทุกวันนี้กลายเป็นแค่ราคาที่คุ้ม

สันติเริ่มจากอยากเอาชนะ แต่จบลงที่การสร้างคุณค่าให้ผู้คนทั้งประเทศ ใช้ในนวัตกรรม: หากเป้าหมายของคุณไม่ใหญ่พอจะเปลี่ยนโลกเล็กๆ สักใบ คุณจะเลิกกลางทางแน่นอน

ธุรกิจนวัตกรรมไม่ใช่สนามของคนเก่ง แต่คือสนามของคนที่กล้าเปลี่ยนความเจ็บ ความเชื่อ และความล้มเหลว — ให้กลายเป็นกลยุทธ์ที่คนอื่นไม่กล้าลอง

แรงบันดาลใจจาก Mad Unicorn ซีรีส์ที่มากกว่าละคร แต่มันคือ Case Study ที่เดินได้ครับ

MedChickathon: พรมแดนใหม่ของการเรียนรู้ผ่านนวัตกรรมในระบบสุขภาพ

ยากไหม จะแก้ปัญหาอะไรสักอย่าง

หลาย ๆ คนบอกว่า ไม่ยากหรอก แต่หาก เปลี่ยนคำถามใหม่ว่า

ยากไหม หากจะแก้ปัญหาที่ มีข้อจำกัดต่าง ๆ มีความซับซ้อนและการแก้ไขด้วยวิธีปัจจุบันยังไงก็ไม่ได้สักที

ยากสิ ทำไมจะไม่ยาก เพราะหากไม่ยาก มันก็คงมีคนไข้ไปแล้ว

และนี่คือที่มาของ Hack หรือ การเจาะช่องโหว่ของปัญหา แล้วแก้ด้วยวิธีที่แก้ชุดความคิดด้วยใหม่ ๆ และหาก การคิดหาวิธีแก้ปัญหาใหม่ๆ ด้วยการระดมสมองในเวลาที่จำกัด แบบ ไม่หยุดไม่หย่อนอย่างรวดเร็ว นี่คือที่มาของ “Hackathon” และ Hackathon ที่เกี่ยวกับการแก้ปัญหาเรื่องอะไร ก็เป็นของปัญหานั้น เช่น แก้ปัญหาสุขภาพ ก็เป็น Health Hackathon ยังไงหละ และสำหรับ ศูนย์นวัตกรรมสุขภาพคณะแพทย์ มช. หรือที่เรียกว่า MEDCHIC เลยเรียก Health Hackathon นี้ว่า MEDCHICATHON ชื่อมัน cool ใช่ไหมหละ ดู energetic พร้อมในการแก้ปัญหาด้วยไอเดีย ใหม่ๆ กัน

มารู้จักประวัติย่นย่อของ Hackathon ก่อน

คำว่า "hackathon" มาจากการรวมคำว่า "hack" และ "marathon" โดยมีจุดเริ่มต้นในช่วงปลายทศวรรษ 1990 ซึ่งเป็นยุคแห่งนวัตกรรมที่รวดเร็วในอุตสาหกรรมซอฟต์แวร์ Hackathon ครั้งแรกที่ได้รับการยอมรับอย่างกว้างขวางจัดโดย OpenBSD ในปี 1999 ที่นักพัฒนาได้รวมตัวกันเพื่อทำงานอย่างเข้มข้นด้านซอฟต์แวร์เข้ารหัสข้อมูล ไม่นานหลังจากนั้น บริษัทเทคโนโลยีอย่าง Sun Microsystems และ Yahoo ก็ได้นำรูปแบบนี้ไปใช้ เพื่อกระตุ้นให้ทีมงานทำงานร่วมกันภายใต้เวลาที่จำกัดในการสร้างโซลูชันใหม่ ๆ

รูปแบบ hackathon ได้ขยายจากแวดวงเทคโนโลยีไปสู่ภาคส่วนอื่น ๆ อย่างรวดเร็ว ในช่วงปี 2010 เป็นต้นมา hackathon ได้รับการปรับใช้ในภาคสุขภาพ การศึกษา และภาคพลเมือง โดยเฉพาะ hackathon ด้านสุขภาพซึ่งได้รับความนิยมในสถาบันการแพทย์ชั้นนำอย่าง MIT Hacking Medicine ซึ่งเน้นการทำงานร่วมกันแบบสหสาขาในการแก้ปัญหาจริงในระบบสุขภาพ

จากเครื่องมือในการแข่งขันด้านการเขียนโปรแกรม Hackathon ได้กลายมาเป็นเครื่องมือด้านการเรียนรู้เชิงกลยุทธ์ การเปลี่ยนแปลงวัฒนธรรม และการสร้างผลกระทบทางสังคม

เหตุผลเบื้องหลัง MedChickathon

ตั้งแต่ปี 2521 ในช่วงที่มีการพัฒนาย่านนวัตกรรมทางการแพทย์สวนดอก กิจกรรมที่กระตุ้นไอเดีย เพิ่มการสร้างทีม และปลุกความมีชีวิตชีวาด้วยบรรยากาศเร้าใจจึงเกิดขึ้น ในคราวนั้น SMID Health Hackathon ได้จัดขึ้นเป็นครั้งแรก การจัดครั้งแรก เป็นการจัด Online Hackathon เนื่องจากติดสถานการณ์การระบาดของเชื้อไวรัส โควิด ใน Theme “In the Age of Digitalization” จากนั้นในปีต่อมา ได้มีการเปลี่ยน ชชื่อเป็น MedCHIC Health Hackathon โดยเราจัดกันที่ ห้องประชุมโรงแรม Kantary Hill กับงาน 36 ชั่วโมง โดยในปีต่อมา ได้จัดใน Theme “Transforming Healthcare Service”

จากนั้น ครั้งที่ 3 ใน Theme “Accelerating Health Impact” และ ครั้งที่ 5 ใน Theme “InnoHealth JumpStart”

First Health Hackathon 2021

Second Health Hackathon 2022

3rd Hackathon 2023

4th Health Hackathon 2024

ในปี 2525 ได้มีการปรับชื่อ จาก MedChic Health Hackathon เป็น MedChickathon ให้จดจำได้ง่ายขึ้น โดยปีนี้ มาใน Theme “The First Pulse for Health Impact” โดยปีนี้ เน้นการทำ Hackathon โดยนำโจทย์จากงาน service , research หรือ education ที่อยู่ในมหาวิทยาลัย และผู้ที่เกี่ยวข้อง เพื่อนำไปใช้ในโรงพยาบาลต่อได้

จากไอเดียสู่การเปลี่ยนแปลง: การหว่านเมล็ดแห่งอนาคต

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

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

MedChickathon คือมากกว่า hackathon—มันคือระบบนิเวศของการเรียนรู้ ค่านิยม และต้นแบบของอนาคตที่เราต้องการเห็นในระบบสุขภาพ

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

Teach your younger self - จงสอนเจ้าเมื่อเยาว์วัย

วันหนึ่ง ลูกศิษย์ บอกว่า อจ สอนเขียนบทความ ให้ความรู้คนอื่น ให้หน่อย

"จงสอน สิ่งที่ เราอยากรู้เมื่อเรายังเด็กกว่านี้ ไม่มีความรู้อะไร ช่วยเหลือให้เราดีขึ้น"

Teach younger you. สอนคนอื่น เหมือนสอนตัวเองที่ยังเยาว์วัย ไร้เดียงสา

แค่นี้

- อจ สุรัตน์

10 ช่วงเวลาปิ๊งแว๊บ คิดอะไรก็ได้หมด

เคยปิ๊งแว๊บ อยู่ ๆ ก็คิดอะไรออกไหม ?

มันจะมีช่วงเวลาที่เรา แบบ ปิ๊งแว้บ มีไอเดียหรือมีความคิดใหม่ ๆ ออกมาเหมือนกับหมีที่โผล่ออกมาจากพุ่มไม้ "surprise" ฉันพบแล้ว

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

ช่วงเวลานี้ เรียกว่า "Eureka" ภาษากรีกโบราณของ "ฉันพบแล้ว" ที่มีเรื่องเล่าของ นักคณิตศาสตร์ชาวกรีกชื่อว่า อาร์คีมีดีส (Archimedes)ที่คิดการคิดมวลของทองจากการทีมันทดแทนน้ำในอ่างจนล้นออกมา

เอาหละ เรามารีวิวกันดีกว่า ว่า Eureka moment มีอะไรบ้าง แล้ว มันเกิดจากอะไร ทำไมถึงปิ๊งแว๊บ
10 "Eureka Moments": ช่วงเวลาแห่งการปิ๊งไอเดียใหม่ ๆ
---
1. ตอนอาบน้ำ
- คลาสสิกของแท้ เพราะสมองผ่อนคลาย ไม่มีสิ่งรบกวนจากหน้าจอหรือความเร่งรีบ
- คลื่นสมองเปลี่ยนเป็น “alpha wave” ซึ่งเอื้อต่อความคิดสร้างสรรค์
---
2. ตอนกำลังจะหลับ (หรือหลังตื่นใหม่ ๆ)
- ช่วง “Hypnagogia” และ “Hypnopompia” คือช่วงครึ่งหลับครึ่งตื่นที่สมองทำงานแบบ free-association
- หลายคนบอกว่าไอเดียดีที่สุดเกิดก่อนหลับ 5 นาที

3. ตอนวิ่ง หรือเดินเล่นคนเดียว
- การเคลื่อนไหวซ้ำ ๆ ทำให้สมองได้จัดระเบียบความคิดและเชื่อมโยงข้อมูลใหม่ ๆ
- Steve Jobs ชอบ “walking meetings” ก็ด้วยเหตุผลนี้
---
4. ตอนอยู่บนรถ หรือกำลังเดินทาง
- โดยเฉพาะการขับรถคนเดียว, นั่งเครื่องบิน, หรือรถไฟ—เวลาเหล่านี้คือ "liminal space" ที่เปิดโอกาสให้สมองลอยคิดนอกกรอบ
---
5. ตอนคุยเล่นกับคนที่ไม่ใช่สายเดียวกัน
- คนละวงการ = คนละชุดคำถาม
- ไอเดียใหม่มักเกิดจากการผสมข้ามขอบเขตความรู้ (cross-pollination)
---
6. ตอนที่สอนคนอื่น
- เวลาต้องอธิบายเรื่องหนึ่งให้คนอื่นเข้าใจ สมองจะพยายามจัดเรียงและเข้าใจลึกขึ้น จนอาจเห็น “วิธีใหม่” ที่ไม่เคยคิด
---
7. ตอนเล่นของเล่น หรือวาดรูปเล่น
- ไม่ต้องจริงจัง แต่ช่วยให้สมอง “หลุดกรอบ”
- เช่น การ doodle หรือเลโก้ ทำให้เกิด “associative thinking” ที่ดีต่อไอเดีย
---
8. ตอนโดนข้อจำกัดกดดัน
- ความคิดสร้างสรรค์พุ่งขึ้นเมื่อมี “ข้อจำกัด” เช่น ไม่มีงบ ไม่มีเวลา
- Necessity is the mother of invention.
---
9. ตอนฟังเพลง (โดยเฉพาะเพลงที่ไม่มีเนื้อร้อง)
- เพลงแนว ambient หรือ lo-fi hiphop สร้าง “flow state”
- สมองทำงานเหมือนฝันกลางวัน แต่นำไปสู่การเชื่อมโยงใหม่ ๆ
10. ตอนอยู่ท่ามกลางธรรมชาติ
- การอยู่ในป่า เดินบนดอย หรือแม้แต่นั่งดูต้นไม้ในสวน
- สมองจะปรับจาก “task mode” เป็น “default mode” ที่เหมาะกับการตกผลึกความคิด

ของพวกเราปิ๊งแว๊บ ตอนไหน ลองแชร์กันครับ

- อจ สุรัตน์​

เปลี่ยนการบ่นให้ฮีลใจ จากคำถาม “เมื่อเทียบกับอะไร?”

ในแต่ละวัน เราฟังคนอื่นบ่นมามากแค่ไหน บางคนบอกว่ามาก บางคนบอกว่า ชั้นสิ เป็นคนที่บ่นมากกว่า

มันได้ระบาย ความอัดอั้นตันใจ บ่นแล้วสมองโล่ง ว่างั้น

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

แต่การบ่นมันดีต่อใจจริงเหรอ?

ต้องบอกว่า มันเป็นความคิดที่ผิด

การบ่นที่บอกว่า คือการระบายนั้น จริง ๆ แล้ว มันคือดาบสองคม

“การบ่นเหมือนการระบาย แต่บ่อยครั้งมันยิ่งทำให้เราหงุดหงิดมากขึ้น” ดร.เบิร์นสตีน ผู้เชี่ยวชาญด้านสมอง กล่าว และมีงานวิจัยมากมายที่ยืนยันเรื่องนี้

งานวิจัยที่ตีพิมพ์ในวารสาร Cerebral Cortex แสดงให้เห็นว่า **การบ่นซ้ำ ๆ จะกระตุ้นและเสริมสร้างเส้นทางประสาทในสมองที่เกี่ยวข้องกับความคิดเชิงลบ นั่นหมายความว่า ยิ่งเราบ่นมากเท่าไร สมองก็จะยิ่ง "คุ้นชิน" กับรูปแบบความคิดแบบนั้นมากขึ้น เป็นเหมือนการ “ปูทาง” ให้สมองเลือกความคิดในแง่ร้ายได้ง่ายและบ่อยขึ้น

หลักการนี้คล้ายกับการฝึกกล้ามเนื้อ หากเราออกกำลังกายกล้ามเนื้อส่วนใดซ้ำ ๆ กล้ามเนื้อส่วนนั้นก็จะแข็งแรงขึ้น ในทางเดียวกัน **การใช้เส้นทางประสาทบางเส้นทางซ้ำ ๆ จะทำให้มันถูกเสริมสร้างและกลายเป็นอัตโนมัติ นี่คือสิ่งที่เรียกว่า Neuroplasticity หรือ ความสามารถในการเปลี่ยนแปลงของสมอง

การหมุนวนอยู่กับปัญหาเดิม ๆ  แบบไม่หาทางออกหรือไม่ยอมรับสิ่งที่ควบคุมไม่ได้ มันจะกลายเป็น "rumination" หรือ **การครุ่นคิดซ้ำ ๆ ที่เป็นอันตรายทางจิตใจ**

นักจิตวิทยาเรียกสิ่งนี้ว่า  “toxic venting”  คือการระบายที่ไม่ได้ทำให้ดีขึ้น แต่กลับตอกย้ำความรู้สึกแย่ เช่น

- ยิ่งพูดยิ่งโกรธ

- ยิ่งเล่า ยิ่งรู้สึกเป็นเหยื่อ

- ยิ่งแชร์ ยิ่งเสพติดการได้รับความเห็นใจ

แล้วเราจะทำอย่างไร ไม่ให้สมองเราพังจากการบ่น ?

ดร.เจฟฟรีย์ เบิร์นสตีน นักจิตวิทยาที่มีประสบการณ์กว่า 30 ปี เสนอวิธีแก้ไขง่าย ๆ แต่ทรงพลัง นั่นคือ การถามตัวเอง (หรือถามลูก) ว่า “เมื่อเทียบกับอะไร?”

น่าสนใจไหม คำถามสั้น ๆ แค่นี้ เปลี่ยนความคิดได้เหรอ

การถามว่า “เมื่อเทียบกับอะไร?” เป็นการกระตุ้นให้เกิด การมองใหม่ (Cognitive Reappraisal) ซึ่งเป็นเทคนิคทางจิตวิทยา ที่ถูกพิสูจน์แล้วว่าช่วยคุมอารมณ์ได้ เพราะเป็นการบอกว่า มันมีมุมมองเปรียบเทียบ เปิดใจให้กว้าง ความทุกข์เรา มันปะติ๋วนะ

ตัวอย่าง

เด็กชายที่บ่นเรื่องอาหารกลางวัน: เมื่อแม่ถามเขาว่า “เมื่อเทียบกับอะไร?” เด็กชายเริ่มคิด และตอบว่า “ก็มีเด็กบางคนที่ไม่มีอาหารกลางวันกินเลย” แม้เขาจะยังไม่ชอบแซนด์วิชไก่งวง แต่ความรู้สึกขอบคุณที่เกิดขึ้นช่วยลดความหงุดหงิดลงได้

เด็ก ๆ เรียนรู้ผ่านการสังเกตพฤติกรรมของผู้ใหญ่ ทฤษฎีการเรียนรู้ทางสังคม (Social Learning Theory)

“พฤติกรรมของมนุษย์ส่วนใหญ่เรียนรู้ได้จากการสังเกตและเลียนแบบ”

ดังนั้น หากผู้ใหญ่สามารถฝึกตั้งคำถาม “เมื่อเทียบกับอะไร?” แทนการบ่นให้เป็นนิสัย เด็ก ๆ ก็จะซึมซับวิธีคิดที่ยืดหยุ่นและสร้างสรรค์นี้เช่นกัน

ลองดูคำถามกับผู้ใหญ่กัน

ผู้ใหญ่ที่กำลังเผชิญกับความผิดหวังในอาชีพ ความสัมพันธ์ หรือแม้แต่ความวิตกเรื่องอายุ ก็สามารถใช้เครื่องมือนี้ได้เช่นกัน

เช่น ชายคนหนึ่งรู้สึกว่าตัวเองประสบความสำเร็จน้อยกว่าที่ควรจะเป็น เมื่อถามตัวเองว่า “เมื่อเทียบกับอะไร?” เขาพบว่ากำลังเปรียบเทียบกับเพื่อนที่เลือกเส้นทางชีวิตต่างออกไป ซึ่งไม่ได้ดีกว่าเสมอไป นั่นสิ ความสุขมันก็ไม่ได้วัดจากการที่สูญเสีย ณ.เวลานั้น

เห็นไหม คือ ก็ไม่ได้ ว่าหุบปากห้ามบ่นเลย แต่หากมันบ่น จนเป็นนิสัยขี้บ่น มันยิ่งแย่ต่อสมองและจิตใจ ของคนบ่นเอง

อจ สุรัตน์

Hackers and Painters บทความแปลจากปี 2003

นี่คือบทความแปล Hackers and Painters ของ Paul Graham

(บทความนี้ดัดแปลงมาจากการบรรยายพิเศษที่มหาวิทยาลัยฮาร์วาร์ด ซึ่งได้รวมเอาการพูดในงานที่มหาวิทยาลัยนอร์ทอีสเทิร์นก่อนหน้านี้เข้าไปด้วย)

โดยสามารถเข้าไปดูใน original lik ได้ที่ >> https://www.paulgraham.com/hp.html

เมื่อฉันเรียนจบปริญญาโทด้านวิทยาการคอมพิวเตอร์ ฉันได้ไปเรียนต่อในโรงเรียนศิลปะเพื่อศึกษาการวาดภาพ หลายคนดูประหลาดใจที่คนที่สนใจคอมพิวเตอร์จะสนใจการวาดภาพด้วย พวกเขาดูเหมือนจะคิดว่าการแฮ็กและการวาดภาพเป็นงานที่แตกต่างกันอย่างสิ้นเชิง — ว่าการแฮ็กนั้นเย็นชา แม่นยำ และมีระเบียบแบบแผน ขณะที่การวาดภาพเป็นการแสดงออกอย่างบ้าคลั่งของแรงกระตุ้นดิบ ๆ ภายใน

ทั้งสองภาพนี้ผิด การแฮ็กและการวาดภาพมีหลายอย่างที่เหมือนกัน อันที่จริง จากคนหลากหลายประเภทที่ฉันเคยรู้จัก แฮ็กเกอร์และจิตรกรเป็นกลุ่มที่คล้ายกันที่สุด

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

ฉันไม่เคยชอบคำว่า "วิทยาการคอมพิวเตอร์" เลย เหตุผลหลักที่ฉันไม่ชอบก็เพราะว่ามันไม่มีสิ่งที่เรียกว่าวิทยาการคอมพิวเตอร์อยู่จริง ๆ วิทยาการคอมพิวเตอร์เป็นเหมือนถุงรวมของหัวข้อต่าง ๆ ที่เกี่ยวข้องกันอย่างหลวม ๆ ซึ่งถูกโยนรวมกันด้วยอุบัติเหตุทางประวัติศาสตร์ เหมือนยูโกสลาเวีย

ในอีกด้านหนึ่ง คุณมีคนที่จริง ๆ แล้วเป็นนักคณิตศาสตร์ แต่เรียกสิ่งที่พวกเขาทำว่า "วิทยาการคอมพิวเตอร์" เพื่อให้สามารถขอทุนจาก DARPA ได้
ตรงกลาง คุณมีคนที่ทำงานในลักษณะเหมือนการศึกษาประวัติศาสตร์ธรรมชาติของคอมพิวเตอร์ — เช่น การศึกษาพฤติกรรมของอัลกอริทึมที่ใช้ในการส่งข้อมูลผ่านเครือข่าย
และในอีกสุดขั้วหนึ่ง คุณมีแฮ็กเกอร์ ซึ่งพยายามเขียนซอฟต์แวร์ที่น่าสนใจ โดยที่คอมพิวเตอร์เป็นเพียงสื่อกลางในการแสดงออก เหมือนคอนกรีตสำหรับสถาปนิก หรือสีสำหรับจิตรกร เป็นเหมือนกับว่านักคณิตศาสตร์ นักฟิสิกส์ และสถาปนิกทั้งหมดต้องอยู่ในภาควิชาเดียวกัน

บางครั้ง สิ่งที่แฮ็กเกอร์ทำถูกเรียกว่า "วิศวกรรมซอฟต์แวร์" แต่ชื่อนี้ก็ทำให้เข้าใจผิดไม่แพ้กัน นักออกแบบซอฟต์แวร์ที่เก่ง ๆ ไม่ใช่วิศวกรมากไปกว่าสถาปนิก ความแตกต่างระหว่างสถาปนิกกับวิศวกรไม่ได้ชัดเจนเป็นเส้นตรง แต่ก็มีอยู่ เส้นแบ่งนั้นอยู่ระหว่าง "อะไร" และ "อย่างไร": สถาปนิกตัดสินใจว่าจะทำ "อะไร" และวิศวกรหาวิธีทำ "อย่างไร"

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

บางทีในอนาคต "วิทยาการคอมพิวเตอร์" อาจจะถูกแยกออกเป็นส่วน ๆ เหมือนอย่างที่ยูโกสลาเวียถูกแยกตัว นั่นอาจจะเป็นเรื่องดี โดยเฉพาะถ้าหากมันหมายถึงเอกราชให้กับบ้านเกิดของฉัน นั่นคือ การแฮ็ก

การรวมงานประเภทต่าง ๆ เหล่านี้เข้าด้วยกันในภาควิชาเดียวกันอาจจะสะดวกในเชิงบริหาร แต่ในเชิงสติปัญญาแล้วมันกลับสร้างความสับสน นั่นคืออีกเหตุผลหนึ่งที่ฉันไม่ชอบชื่อ "วิทยาการคอมพิวเตอร์" แม้จะโต้แย้งได้ว่าคนที่อยู่ตรงกลางกำลังทำสิ่งที่เหมือนวิทยาศาสตร์ทดลอง แต่คนที่อยู่สองขั้วตรงข้ามกัน — คือพวกแฮ็กเกอร์และนักคณิตศาสตร์ — นั้นไม่ได้ทำวิทยาศาสตร์จริง ๆ

นักคณิตศาสตร์ดูเหมือนจะไม่รู้สึกเดือดร้อนกับเรื่องนี้ พวกเขาทำงานพิสูจน์ทฤษฎีเหมือนนักคณิตศาสตร์คนอื่น ๆ ในภาควิชาคณิตศาสตร์ และคงเลิกใส่ใจไปนานแล้วว่าตึกที่พวกเขาทำงานมีป้ายว่า "วิทยาการคอมพิวเตอร์" อยู่ข้างนอก แต่สำหรับแฮ็กเกอร์ ชื่อนี้เป็นปัญหา เพราะถ้าสิ่งที่พวกเขาทำถูกเรียกว่า "วิทยาศาสตร์" มันทำให้พวกเขารู้สึกว่าต้องประพฤติตัวเหมือนนักวิทยาศาสตร์ ดังนั้นแทนที่จะทำในสิ่งที่พวกเขาอยากทำจริง ๆ นั่นคือ การออกแบบซอฟต์แวร์ที่สวยงาม แฮ็กเกอร์ในมหาวิทยาลัยและห้องทดลองวิจัยกลับรู้สึกว่าพวกเขาควรจะเขียน "งานวิจัย"

ในกรณีที่ดีที่สุด งานวิจัยเป็นแค่พิธีการ แฮ็กเกอร์เขียนซอฟต์แวร์เจ๋ง ๆ แล้วเขียนบทความเกี่ยวกับมัน และบทความนั้นก็กลายเป็นตัวแทนของความสำเร็จที่ซอฟต์แวร์นั้นเป็นตัวแทนอยู่ แต่บ่อยครั้ง ความไม่ลงรอยนี้ก่อให้เกิดปัญหา มันง่ายมากที่จะค่อย ๆ ลื่นไถลจากการสร้างสิ่งที่สวยงาม ไปสู่การสร้างสิ่งที่น่าเกลียดแต่เหมาะกับการเขียนบทความวิจัยมากกว่า

น่าเสียดายที่ สิ่งที่สวยงามมักจะไม่ใช่หัวข้อที่ดีสำหรับบทความวิจัย ข้อแรก งานวิจัยต้องเป็น "ของใหม่" — และทุกคนที่เคยเขียนวิทยานิพนธ์ปริญญาเอกจะรู้ดีว่า วิธีที่แน่นอนที่สุดในการแน่ใจว่าคุณกำลังสำรวจพื้นที่บริสุทธิ์คือการเลือกพื้นที่ที่ไม่มีใครอยากแตะ ข้อสอง งานวิจัยต้อง "มีเนื้อหาสาระมาก" — และระบบที่ยุ่งเหยิงนั้นมักจะให้หัวข้อที่อุดมสมบูรณ์กว่า เพราะคุณสามารถเขียนเกี่ยวกับอุปสรรคต่าง ๆ ที่คุณต้องเอาชนะได้ การเริ่มต้นด้วยสมมติฐานที่ผิดนั้นให้หัวข้อได้ดีที่สุด ตัวอย่างที่ดีของกฎข้อนี้คือ "ปัญญาประดิษฐ์" (AI) ถ้าคุณสมมติว่าความรู้สามารถแทนค่าด้วยรายชื่อของนิพจน์ตรรกะเชิงประพจน์ที่มีอาร์กิวเมนต์เป็นแนวคิดนามธรรม คุณก็จะมีบทความให้เขียนได้มากมาย เหมือนที่ริคกี้ ริคาร์โด เคยพูดว่า “ลูซี่ เธอมีเรื่องต้องอธิบายอีกเยอะเลยนะ”

วิธีการสร้างสิ่งที่สวยงามมักเกี่ยวข้องกับการปรับปรุงเล็กน้อยในสิ่งที่มีอยู่แล้ว หรือการผสมผสานแนวคิดที่มีอยู่ในแบบใหม่เล็กน้อย งานแบบนี้สื่อสารผ่านบทความวิจัยได้ยากมาก

แล้วทำไมมหาวิทยาลัยและห้องแล็บวิจัยยังคงประเมินแฮ็กเกอร์จากจำนวนงานตีพิมพ์ล่ะ? เพราะมันง่ายที่จะทำ เช่นเดียวกับที่ "ความถนัดทางการศึกษา" (scholastic aptitude) ถูกวัดด้วยการสอบมาตรฐานแบบง่าย ๆ หรือประสิทธิภาพของโปรแกรมเมอร์ถูกวัดด้วยจำนวนบรรทัดของโค้ด มันง่ายที่จะใช้การทดสอบที่ง่าย แม้ว่าจะไม่ได้แม่นยำนักก็ตาม

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

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

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

ยังมีสิ่งที่แย่กว่าการที่คนอื่นเข้าใจงานของคุณผิด นั่นคือ คุณเองเป็นฝ่ายเข้าใจงานของตัวเองผิด

สาขาที่เกี่ยวข้องกันคือสถานที่ที่คุณจะไปค้นหาไอเดียใหม่ ๆ ถ้าคุณพบว่าตัวเองอยู่ในภาควิชาวิทยาการคอมพิวเตอร์ จะมีความล่อตาล่อใจอย่างยิ่งที่จะเชื่อว่าการแฮ็กเป็นการประยุกต์ใช้ของสิ่งที่วิทยาการคอมพิวเตอร์ทฤษฎีกำลังทำหน้าที่เป็นทฤษฎี ฉันรู้สึกอึดอัดใจในใจลึก ๆ ตลอดช่วงที่เรียนบัณฑิตศึกษาว่าฉันน่าจะรู้ทฤษฎีมากกว่านี้ และรู้สึกผิดมากที่ลืมสิ่งที่เรียนไปภายในสามสัปดาห์หลังจากสอบไฟนอล

ตอนนี้ฉันเข้าใจแล้วว่าฉันเข้าใจผิด แฮ็กเกอร์จำเป็นต้องเข้าใจทฤษฎีการคำนวณ (theory of computation) พอ ๆ กับที่จิตรกรจำเป็นต้องเข้าใจเคมีของสี คุณจำเป็นต้องรู้วิธีคำนวณเวลาและพื้นที่ที่ซอฟต์แวร์จะใช้ และต้องรู้เรื่องความสมบูรณ์แบบของทัวริง (Turing completeness) คุณอาจต้องการจำอย่างน้อยแนวคิดของเครื่องสถานะ (state machine) เผื่อคุณต้องเขียนพาร์เซอร์หรือลิไบรารีสำหรับ regular expressions จริง ๆ แล้วจิตรกรจำเป็นต้องจำเรื่องเคมีของสีมากกว่านี้ด้วยซ้ำ

ฉันพบว่าที่มาของไอเดียที่ดีที่สุดไม่ได้มาจากสาขาอื่น ๆ ที่มีคำว่า "คอมพิวเตอร์" อยู่ในชื่อ แต่กลับมาจากสาขาอื่น ๆ ที่เต็มไปด้วย "ผู้สร้าง" (makers) การวาดภาพให้ไอเดียที่อุดมสมบูรณ์กว่าทฤษฎีการคำนวณเสียอีก

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

ฉันถูกสอนว่าการดีบัก (debugging) เป็นแค่ขั้นตอนสุดท้ายที่เอาไว้จับข้อผิดพลาดและการหลุดรอดต่าง ๆ แต่ตามวิธีที่ฉันทำ โปรแกรมมิ่งดูเหมือนจะ "ประกอบด้วย" การดีบักเลยทีเดียว

เป็นเวลานานที่ฉันรู้สึกผิดเกี่ยวกับเรื่องนี้ เหมือนกับตอนที่ฉันรู้สึกผิดที่ไม่จับดินสอตามที่โรงเรียนสอน ถ้าฉันมองไปที่ "ผู้สร้าง" คนอื่น ๆ อย่างจิตรกรหรือสถาปนิก ฉันคงจะรู้ว่ามีชื่อสำหรับสิ่งที่ฉันทำอยู่ — นั่นคือ "การสเก็ตช์" (sketching)

ดูเหมือนว่าการที่สอนฉันให้เขียนโปรแกรมในมหาวิทยาลัยนั้นผิดหมดเลย คุณควรคิดโปรแกรมไปพร้อม ๆ กับการเขียน เหมือนกับนักเขียนและจิตรกร และสถาปนิก

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

การมี static typing (การระบุประเภทข้อมูลอย่างเคร่งครัด) อาจจะเป็นไอเดียที่ดี หากผู้คนเขียนโปรแกรมแบบที่ฉันถูกสอนมาในมหาวิทยาลัย แต่ความจริงแล้ว ไม่มีแฮ็กเกอร์คนไหนที่ฉันรู้จักเขียนโปรแกรมแบบนั้นเลย เราต้องการภาษาโปรแกรมที่ให้เรา "ขีดเขียน เลอะเทอะ และลบแก้ไขได้ง่าย" ไม่ใช่ภาษาที่ต้องนั่งอย่างสง่างามด้วยถ้วยชาชั้นดีและสนทนากับ compiler ที่เปรียบเสมือนคุณป้าแก่เคร่งครัด

ขณะเราพูดถึง static typing การระบุว่าแฮ็กเกอร์คือ "ผู้สร้าง" (makers) จะช่วยให้เรารอดพ้นจากปัญหาอีกประการหนึ่งที่เกิดขึ้นในวงการวิทยาศาสตร์: นั่นคือ "ความอิจฉาคณิตศาสตร์" (math envy)

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

ในสาขาอย่างฟิสิกส์ นี่อาจจะไม่ก่อให้เกิดอันตรายมากนัก แต่ยิ่งคุณไกลจากวิทยาศาสตร์ธรรมชาติมากเท่าไร ปัญหานี้ก็ยิ่งรุนแรงขึ้นเท่านั้น

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

ถ้าแฮ็กเกอร์ระบุตัวเองว่าเป็น "ผู้สร้าง" เช่นเดียวกับนักเขียนและจิตรกร พวกเขาคงไม่รู้สึกถูกล่อลวงด้วย "ความอิจฉาคณิตศาสตร์" นี้ นักเขียนและจิตรกรไม่รู้สึกว่าตัวเองต้องแข่งขันกับนักคณิตศาสตร์เลย และฉันคิดว่าแฮ็กเกอร์เองก็ควรจะเป็นเช่นเดียวกัน

ถ้ามหาวิทยาลัยและห้องแล็บวิจัยขัดขวางไม่ให้แฮ็กเกอร์ทำงานในแบบที่พวกเขาอยากทำ บางทีสถานที่สำหรับแฮ็กเกอร์ก็คือในบริษัทต่าง ๆ

น่าเสียดายที่บริษัทส่วนใหญ่ก็ไม่ยอมให้แฮ็กเกอร์ทำในสิ่งที่พวกเขาอยากทำเหมือนกัน มหาวิทยาลัยและห้องแล็บวิจัยบังคับให้แฮ็กเกอร์เป็นนักวิทยาศาสตร์ และบริษัทต่าง ๆ ก็บังคับให้แฮ็กเกอร์เป็นวิศวกร

ฉันเพิ่งค้นพบเรื่องนี้เองไม่นานมานี้ ตอนที่ Yahoo! ซื้อบริษัท Viaweb ของเรา พวกเขาถามฉันว่าฉันอยากทำอะไร ฉันไม่เคยชอบงานด้านธุรกิจเท่าไรนัก เลยบอกว่าฉันอยาก "แฮ็ก" อย่างเดียว

แต่เมื่อฉันไปถึง Yahoo! ฉันพบว่าความหมายของคำว่า "แฮ็ก" ในที่นั้นคือ "การเขียนโค้ดตามที่ถูกกำหนดมา" ไม่ใช่การออกแบบซอฟต์แวร์ที่สร้างสรรค์
ในสายตาของ Yahoo! โปรแกรมเมอร์ถูกมองว่าเป็นช่างเทคนิคที่แปล "วิสัยทัศน์" (ถ้าเรียกแบบนั้นได้) ของผู้จัดการผลิตภัณฑ์ออกมาเป็นโค้ด

นี่ดูเหมือนจะเป็นวิธีการทำงานมาตรฐานในบริษัทขนาดใหญ่ พวกเขาทำเช่นนี้เพราะมันช่วยลด "ส่วนเบี่ยงเบนมาตรฐาน" ของผลลัพธ์ กล่าวคือ พวกเขาพยายามทำให้ผลลัพธ์ออกมา "สม่ำเสมอ" มากที่สุดเท่าที่จะทำได้

มีแฮ็กเกอร์เพียงส่วนน้อยเท่านั้นที่สามารถออกแบบซอฟต์แวร์ได้อย่างแท้จริง และมันยากมากสำหรับผู้บริหารที่จะเลือกคนเหล่านี้ออกมาได้ถูกต้อง ดังนั้น แทนที่จะฝากอนาคตของซอฟต์แวร์ไว้ในมือของแฮ็กเกอร์อัจฉริยะคนหนึ่ง บริษัทใหญ่ ๆ จึงตั้งระบบให้ "การออกแบบ" เป็นงานของคณะกรรมการ และให้แฮ็กเกอร์เป็นเพียงผู้ดำเนินการ

✅ แล้วนี่ก็คือหนึ่งในเหตุผลที่สตาร์ทอัพถึงสามารถเอาชนะบริษัทใหญ่ได้:

บริษัทใหญ่ต้องการลดความเสี่ยงของหายนะ และเพื่อหลีกเลี่ยงมัน พวกเขาจึงลดทอนความสุดโต่งของผลลัพธ์ (damp oscillations) ลง — แต่การทำเช่นนั้นหมายความว่าพวกเขาเสียโอกาสที่จะได้ "ผลงานยิ่งใหญ่" ไปด้วย พวกเขาไม่สามารถสร้างผลงานที่ยอดเยี่ยมได้อีก เพราะต้องเล่นแบบปลอดภัย

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

ดังนั้น ถ้าคุณสามารถหาวิธีเปิดศึก "สงครามการออกแบบ" กับบริษัทใหญ่ ๆ ที่ระบบการออกแบบของพวกเขาถูกควบคุมโดยผู้จัดการผลิตภัณฑ์ได้ล่ะก็ พวกเขาจะไม่มีวันไล่ตามคุณทัน

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

ตัวอย่างเช่น การเขียนโปรแกรมเวิร์ดโปรเซสเซอร์ที่ดีกว่า Microsoft Word นั้นคงทำได้ง่ายมาก แต่ Microsoft ซึ่งซ่อนตัวอยู่หลังการผูกขาดของระบบปฏิบัติการของพวกเขา ก็คงไม่แม้แต่จะสังเกตเห็นว่าคุณมีอยู่ด้วยซ้ำ

ดังนั้น สถานที่ที่เหมาะสมสำหรับการต่อสู้ด้านการออกแบบ คือ "ตลาดใหม่" (new markets) ที่ยังไม่มีใครสร้างป้อมปราการขึ้นมาได้ ที่ซึ่งคุณสามารถชนะได้ด้วยการใช้วิธีการออกแบบที่กล้าหาญ และให้ "คนกลุ่มเดียวกัน" เป็นทั้งผู้ออกแบบและผู้เขียนซอฟต์แวร์

Microsoft เองก็ทำเช่นนี้ในช่วงเริ่มต้น เช่นเดียวกับ Apple และ Hewlett-Packard ฉันสงสัยว่าทุกสตาร์ทอัพที่ประสบความสำเร็จล้วนทำเช่นนี้

ดังนั้น วิธีหนึ่งในการสร้างซอฟต์แวร์ที่ยอดเยี่ยมคือการเริ่มต้นสตาร์ทอัพของตัวเอง แต่ก็มีปัญหาอยู่สองอย่างเกี่ยวกับเรื่องนี้

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

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

ถ้าคุณอยากทำเงิน คุณมักจะถูกบังคับให้ทำงานกับปัญหาที่หยาบกระด้างเกินกว่าที่ใครจะยอมแก้ฟรี ๆ

ผู้สร้าง (Makers) ทุกคนต่างเผชิญกับปัญหานี้ ราคาถูกกำหนดโดยอุปสงค์และอุปทาน และ "สิ่งที่สนุกในการทำ" นั้นมีอุปสงค์น้อยกว่าสิ่งที่แก้ปัญหาธรรมดาสามัญของผู้คนโดยตรง

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

✅ ดังนั้น ฉันคิดว่าคำตอบสำหรับปัญหานี้ในกรณีของซอฟต์แวร์ก็คือ แนวคิดที่เป็นที่รู้จักกันดีในหมู่ผู้สร้าง: "งานประจำ"(day job)

คำนี้มีต้นกำเนิดจากนักดนตรีที่เล่นดนตรีในเวลากลางคืน แต่มีงานประจำในตอนกลางวัน
พูดให้กว้างขึ้น มันหมายถึง คุณมีงานหนึ่งที่ทำเพื่อเงิน และอีกงานหนึ่งที่ทำด้วยใจรัก

เกือบทุกคนที่เป็นผู้สร้างต่างมีงานประจำในช่วงต้นของชีวิตอาชีพของพวกเขา
จิตรกรและนักเขียนก็มีงานประจำกันอย่างฉาวโฉ่

ถ้าคุณโชคดี คุณอาจจะได้งานที่เกี่ยวข้องกับงานที่คุณรัก นักดนตรีมักจะทำงานในร้านขายแผ่นเสียง เช่นเดียวกับแฮ็กเกอร์ที่ทำงานกับภาษาโปรแกรมหรือระบบปฏิบัติการที่ตัวเองชื่นชอบ อาจได้งานที่ใช้มันจริง ๆ

เมื่อฉันพูดว่าคำตอบคือให้แฮ็กเกอร์มีงานประจำ และทำงานซอฟต์แวร์ที่สวยงามในเวลาว่าง ฉันไม่ได้เสนอไอเดียใหม่อะไรเลย นี่คือแนวคิดของ โอเพ่นซอร์ส (open source) นั่นเอง

สิ่งที่ฉันพูดก็คือ โมเดลโอเพ่นซอร์สนั้น "อาจจะ" เป็นโมเดลที่ถูกต้อง เพราะมันได้รับการยืนยันอย่างอิสระแล้วจากผู้สร้างในสาขาอื่น ๆ มานานนับศตวรรษ

มันน่าประหลาดใจสำหรับฉันที่ยังมีนายจ้างที่ลังเลที่จะให้แฮ็กเกอร์ทำงานโอเพ่นซอร์ส ตอนที่ Viaweb เรารู้สึกลังเลที่จะจ้างใครก็ตามที่ "ไม่ได้" ทำงานโอเพ่นซอร์ส!

เวลาสัมภาษณ์โปรแกรมเมอร์ สิ่งที่เราสนใจที่สุดคือ พวกเขาเขียนซอฟต์แวร์อะไรในเวลาว่าง
คุณไม่สามารถทำอะไรได้ดีจริง ๆ ถ้าคุณไม่รักมัน และถ้าคุณรักการแฮ็ก คุณก็จะหลีกเลี่ยงไม่ได้ที่จะทำโปรเจกต์ของตัวเองในเวลาว่าง

เพราะแฮ็กเกอร์เป็นผู้สร้าง (makers) ไม่ใช่นักวิทยาศาสตร์ ที่ที่ควรมองหาเปรียบเทียบไม่ใช่วงการวิทยาศาสตร์ แต่ควรมองไปที่ผู้สร้างประเภทอื่น ๆ เช่น จิตรกร นักเขียน และสถาปนิก

แล้วการวาดภาพสามารถสอนอะไรเราเกี่ยวกับการแฮ็กได้บ้าง?

สิ่งหนึ่งที่เราสามารถเรียนรู้ (หรืออย่างน้อยก็ยืนยันได้) จากการวาดภาพ ก็คือ วิธีการเรียนรู้การแฮ็ก

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

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

ฉันคิดว่าผู้สร้างส่วนใหญ่ทำงานในลักษณะนี้ นักเขียนและสถาปนิกก็เช่นกัน

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

อีกวิธีหนึ่งที่ผู้สร้างเรียนรู้คือ จากตัวอย่าง

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

นักเขียนก็ทำเช่นนี้ เบนจามิน แฟรงคลิน (Benjamin Franklin) เรียนรู้การเขียนโดยสรุปประเด็นจากบทความของแอดดิสันและสตีล (Addison and Steele) แล้วพยายามสร้างมันขึ้นมาใหม่ในภายหลัง เรย์มอนด์ แชนด์เลอร์ (Raymond Chandler) ก็ทำแบบเดียวกันกับนวนิยายสืบสวนสอบสวน

แฮ็กเกอร์เองก็สามารถเรียนรู้การโปรแกรมได้ด้วยการดูโปรแกรมที่ดี — ไม่ใช่แค่ดูว่ามันทำงานอย่างไร แต่ดู "ซอร์สโค้ด" ด้วย

หนึ่งในประโยชน์ที่ไม่ค่อยมีใครพูดถึงของขบวนการโอเพ่นซอร์สก็คือ มันทำให้การเรียนรู้การโปรแกรมง่ายขึ้นมาก

ตอนที่ฉันเรียนรู้การโปรแกรม เราต้องพึ่งตัวอย่างในหนังสือเป็นหลัก ชิ้นงานโค้ดขนาดใหญ่อันเดียวที่เข้าถึงได้ในตอนนั้นคือ Unix ซึ่งถึงกระนั้นเองก็ยังไม่เป็นโอเพ่นซอร์สจริง ๆ ด้วยซ้ำ
คนส่วนใหญ่ที่อ่านซอร์สโค้ด Unix อ่านมันจากสำเนาถ่ายเอกสารของหนังสือ John Lions' Commentary on Unix ที่เขียนตั้งแต่ปี 1977 แต่ถูกห้ามตีพิมพ์อย่างเป็นทางการจนถึงปี 1996

อีกตัวอย่างหนึ่งที่เราสามารถเรียนรู้จากการวาดภาพคือ วิธีที่ภาพวาดถูกสร้างขึ้นอย่าง "ค่อยเป็นค่อยไป"

ภาพวาดมักจะเริ่มต้นจากร่างคร่าว ๆ แล้วค่อย ๆ เติมรายละเอียดเข้าไปเรื่อย ๆ แต่มันไม่ใช่แค่การเติมเต็มเฉย ๆ บางครั้งแผนเดิมก็ผิดพลาดได้

ถ้าคุณส่องดูภาพวาดด้วยรังสีเอกซ์ คุณจะเห็นได้ว่าในภาพวาดจำนวนมาก แขนขาหรือองค์ประกอบต่าง ๆ ถูกย้ายตำแหน่งหรือปรับแต่งภายหลัง

นี่แหละ คือบทเรียนสำคัญสำหรับการแฮ็ก:

คุณควรยอมรับตั้งแต่แรกว่าสเปกของโปรแกรมจะไม่มีวันสมบูรณ์แบบ และคุณควรเขียนโปรแกรมในลักษณะที่ยอมให้สเปก "เปลี่ยนไปกลางทาง" ได้ง่าย

(นี่คือข้อได้เปรียบของสตาร์ทอัพอีกข้อหนึ่ง — บริษัทใหญ่มักทำแบบนี้ไม่ได้เพราะโครงสร้างที่แข็งตัวเกินไป)

ทุกคนคงเคยได้ยินเรื่องอันตรายของ การ optimize โปรแกรมเร็วเกินไป (premature optimization) แล้ว
แต่ฉันคิดว่าเราควรกังวลเรื่อง การออกแบบเร็วเกินไป (premature design) พอ ๆ กัน — การตัดสินใจเร็วเกินไปว่าโปรแกรมควรทำอะไรและทำอย่างไร

เครื่องมือที่ดีสามารถช่วยหลีกเลี่ยงอันตรายนี้ได้
ภาษาโปรแกรมที่ดีควรเหมือนกับ "สีน้ำมัน" คือ ช่วยให้คุณเปลี่ยนใจได้ง่าย ๆ ระหว่างทาง

Dynamic typing ช่วยได้ในเรื่องนี้ เพราะคุณไม่ต้องผูกตัวเองเข้ากับโครงสร้างข้อมูลแบบแข็งทื่อแต่แรก แต่กุญแจสำคัญจริง ๆ คือ ทำให้ภาษาโปรแกรมมีความเป็นนามธรรมสูง (very abstract)

โปรแกรมที่เปลี่ยนแปลงได้ง่ายที่สุดคือโปรแกรมที่ "สั้นมาก"

ฟังดูเหมือนเป็นเรื่องย้อนแย้ง แต่ผลงานที่ยิ่งใหญ่ต้อง "ดีกว่าที่จำเป็น" (better than it has to be)

ตัวอย่างเช่น เมื่อเลโอนาร์โด ดาวินชี วาดภาพเหมือน Ginevra de' Benci ซึ่งอยู่ที่หอศิลป์แห่งชาติในวอชิงตัน ดี.ซี. เขาวาดพุ่มต้นจูนิเปอร์ไว้ข้างหลังศีรษะของเธอ และเขาลงรายละเอียดแต่ละใบไม้ด้วยความประณีตอย่างยิ่ง

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

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

เขาเหมือนกับไมเคิล จอร์แดนในวงการบาสเกตบอล — ไร้ความปรานีต่อตัวเอง (relentless)

✅ ทำไมความละเอียดที่ "ไม่มีใครเห็น" ถึงสำคัญ?

เพราะในที่สุด รายละเอียดที่ไม่สังเกตเห็นทีละนิด ๆ เหล่านั้นจะ รวมตัวกัน จนกลายเป็นสิ่งที่ "สัมผัสได้"

เมื่อคนเดินผ่านภาพเหมือนของ Ginevra de' Benci พวกเขามักจะหยุดทันทีที่เห็นภาพนี้ ทั้ง ๆ ที่ยังไม่ทันได้อ่านป้ายชื่อศิลปินด้วยซ้ำ

เสียงเล็ก ๆ นับพันเสียงที่คุณแทบไม่ได้ยิน กำลังร้องเพลงประสานกันอย่างสมบูรณ์แบบอยู่ในภาพนั้น

เช่นเดียวกันกับซอฟต์แวร์ที่ยิ่งใหญ่:

ซอฟต์แวร์ที่ดีจริง ๆ ต้องมีความทุ่มเทอย่างบ้าคลั่งต่อ "ความงามที่มองไม่เห็น"
ถ้าคุณมองเข้าไปในซอฟต์แวร์ที่ดี คุณจะพบว่าแม้แต่ส่วนที่ไม่มีใครเห็นก็ยังสวยงามอย่างประณีต

ฉันไม่ได้อ้างว่าฉันเขียนซอฟต์แวร์ที่ยิ่งใหญ่ แต่ฉันรู้ว่าตัวเองมีพฤติกรรมที่ ถ้าเป็นพฤติกรรมในชีวิตจริง ก็คงต้องถูกส่งไปพบจิตแพทย์

การเห็นโค้ดที่เยื้องผิด หรือใช้ชื่อตัวแปรที่น่าเกลียด ทำให้ฉันแทบคลั่ง

ถ้าแฮ็กเกอร์เป็นแค่ช่างเทคนิคที่แปลงสเปกเป็นโค้ด
เขาก็สามารถทำงานไล่ไปตามสเปกจากต้นทางถึงปลายทางได้ เหมือนกับคนที่ขุดคูน้ำ

แต่ถ้าแฮ็กเกอร์เป็น "ผู้สร้าง" ล่ะ?

เราจำเป็นต้องคำนึงถึง แรงบันดาลใจ ด้วย

✅ การทำงานของผู้สร้างมี "จังหวะ" (cycles):

• บางครั้งคุณรู้สึกตื่นเต้นกับโปรเจกต์ใหม่ และอยากทำงานวันละ 16 ชั่วโมง

• บางครั้งกลับไม่มีอะไรน่าสนใจเลย

เพื่อสร้างผลงานที่ดี คุณต้องเรียนรู้ที่จะทำงานให้สอดคล้องกับจังหวะเหล่านี้

มันเหมือนการขับรถเกียร์ธรรมดาขึ้นเนิน — บางครั้งคุณต้องถอนเท้าออกจากคลัตช์เพื่อไม่ให้รถดับ

การยอมผ่อนปรนบ้างจะช่วยป้องกันไม่ให้ความทะเยอทะยานของคุณหยุดชะงัก

ในทั้งการวาดภาพและการแฮ็ก คุณจะมีงานบางชิ้นที่ "ทะเยอทะยานอย่างน่ากลัว" และงานอื่น ๆ ที่ "น่าเบื่อแต่สบายใจ"

เคล็ดลับ: เก็บงานง่าย ๆ ไว้สำหรับช่วงเวลาที่คุณรู้สึกติดขัด!

ตัวอย่างหนึ่งในโลกของแฮ็กกิ้งก็คือการ เก็บบั๊กไว้แก้ทีหลัง

ฉันชอบการดีบัก: นั่นคือช่วงเวลาที่การแฮ็ก "ง่ายดาย" อย่างที่คนทั่วไปคิดว่ามันควรจะเป็น

• คุณมีปัญหาที่ถูกจำกัดอย่างสมบูรณ์

• คุณรู้ว่าคุณจะชนะในท้ายที่สุด

• มันเป็นงานที่ผ่อนคลาย เหมือนกับการทาสีผนังห้อง

• ตัวอย่างของการวาดภาพยังสามารถสอนเราเกี่ยวกับ การทำงานร่วมกัน ได้อีกด้วย

  งานศิลปะชิ้นเอกในอดีตหลายชิ้นเป็นผลงานของ "หลายมือ" แม้ว่าจะมีแค่ชื่อของศิลปินหลักแปะอยู่ข้าง ๆ งานในพิพิธภัณฑ์

  เลโอนาร์โดเองก็เป็นลูกศิษย์ในเวิร์กช็อปของ เวอร์รอกคีโอ (Verrocchio) และเขาเป็นคนวาด "หนึ่งในนางฟ้า" ในภาพ The Baptism of Christ
  การทำงานร่วมกันเช่นนี้เป็นเรื่องปกติในยุคนั้น ไม่ใช่ข้อยกเว้น

  ✅ แต่มีสิ่งหนึ่งที่สำคัญมาก:
  แม้ว่าจะมีการทำงานร่วมกัน แต่มักจะไม่มีใครไป "วาดทับ" งานของอีกคน

  • มักจะมีการแบ่งงานชัดเจน เช่น ศิลปินหลักวาดตัวละครหลัก และผู้ช่วยวาดฉากหลังหรือตัวประกอบ

  • แต่จะไม่มีการที่ "หลายคนแก้ไขชิ้นเดียวกัน" ไปมา

  ฉันคิดว่านี่เป็น โมเดลที่เหมาะสมที่สุดสำหรับการทำงานร่วมกันในการสร้างซอฟต์แวร์ ด้วยเช่นกัน:

  • อย่าให้โค้ดเดียวถูกแฮ็กโดยคนสามหรือสี่คนโดยไม่มีใครเป็นเจ้าของอย่างแท้จริง

  • เพราะถ้าไม่มีเจ้าของ มันจะกลายเป็นเหมือนห้องนั่งเล่นรวมที่ร้างเหงาและเต็มไปด้วยขยะ

  ✅ วิธีที่ถูกต้องในการทำงานร่วมกัน คือ:

  • แบ่งโปรเจกต์ออกเป็น โมดูลที่กำหนดชัดเจน

  • กำหนด เจ้าของ ให้แต่ละโมดูล

  • และออกแบบ อินเทอร์เฟซ ระหว่างโมดูลให้รัดกุมเหมือนกับที่เราออกแบบภาษาโปรแกรม

เช่นเดียวกับการวาดภาพ ซอฟต์แวร์ส่วนใหญ่ถูกสร้างขึ้นมาเพื่อ ผู้ชมที่เป็นมนุษย์ (ไม่ใช่แค่เครื่องจักร)

ดังนั้นแฮ็กเกอร์ — เหมือนกับจิตรกร — ต้องมี ความเห็นอกเห็นใจ (Empathy) เพื่อสร้างผลงานที่ยอดเยี่ยม

ตอนฉันยังเด็ก ฉันมักถูกสอนให้ "มองจากมุมมองของคนอื่น" ซึ่งในทางปฏิบัติก็มักหมายถึง "ทำตามที่คนอื่นอยากให้ทำ" มากกว่าทำในสิ่งที่ฉันอยากทำเอง

ซึ่งทำให้ฉัน เข้าใจผิด เกี่ยวกับ Empathy และตั้งใจที่จะไม่พัฒนามัน

แต่ฉันผิดอย่างแรง

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

การเข้าใจคนอื่นไม่ได้หมายความว่าคุณต้องเสียสละตนเองเสมอไป — ในบางสถานการณ์ เช่นในสงคราม — การเข้าใจศัตรูก็เพื่อจะได้โจมตีเขาได้ดียิ่งขึ้น

✅ สำหรับผู้สร้าง:

• การเข้าใจมุมมองของผู้ใช้ (users) คือทุกสิ่ง

• เพราะซอฟต์แวร์ที่ยอดเยี่ยมต้อง ทำสิ่งที่ผู้ใช้คาดหวัง แม้พวกเขาจะไม่รู้ตัวก็ตาม

• ผู้ใช้จะไม่อ่านคู่มือ คุณต้องทำให้ซอฟต์แวร์ทำงานได้อย่างที่พวกเขาคาดคิด

หนึ่งในตัวอย่างที่ดีที่สุดในเรื่องนี้คือ Macintosh รุ่นแรกในปี 1985
มันคือซอฟต์แวร์ที่ "แค่ใช้งานได้เลย" แบบที่แทบไม่ต้องอธิบาย

แม้ว่าจะมีข้อจำกัดเรื่องหน่วยความจำ แต่ทีมงานสามารถแก้ไขปัญหานั้นได้อย่างรวดเร็วในเวลาไม่กี่เดือน

Source code เองก็ควร "อธิบายตัวเองได้" ด้วย

ถ้ามีสิ่งหนึ่งที่ฉันอยากให้ผู้คนจำเกี่ยวกับการโปรแกรมได้ ก็คือประโยคหนึ่งจากหนังสือ Structure and Interpretation of Computer Programs:

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

คุณต้องมีความเห็นอกเห็นใจต่อ ผู้อ่านโค้ด ของคุณด้วย เพราะในที่สุดแล้ว คนที่ต้องกลับมาอ่านโค้ดก็คือตัวคุณเอง

✅ ตัวชี้วัดง่าย ๆ ว่าใครมี Empathy ดีหรือไม่:

• ดูพวกเขาอธิบายเรื่องเทคนิคให้คนที่ไม่ใช่สายเทคนิคฟัง

• คนที่ดีจะสามารถปรับภาษาให้เรียบง่ายได้

• คนที่ไม่ดีจะอธิบายด้วยศัพท์เทคนิคยาก ๆ รัว ๆ เช่น "High-level language", "Compiler", "Object code" จนผู้ฟังงงตาย

ซอฟต์แวร์ไม่เพียงแต่ต้อง "ทำงานได้" เท่านั้น
มันต้อง "อธิบายตัวเองได้" เช่นเดียวกับงานศิลปะที่ยอดเยี่ยม

และ Empathy คือ ความแตกต่างระหว่างแฮ็กเกอร์ที่เก่งธรรมดา กับแฮ็กเกอร์ที่ยอดเยี่ยมที่สุด

ดังนั้น ถ้าแฮ็กกิ้งทำงานเหมือนการวาดภาพและการเขียนหนังสือแล้ว... มันจะ "เท่" เท่ากันไหม?

ท้ายที่สุดแล้ว คุณมีชีวิตแค่ครั้งเดียว คุณน่าจะใช้มันไปกับการทำสิ่งที่ยิ่งใหญ่

น่าเสียดายที่คำถามนี้ตอบยาก เพราะในเรื่องของ "ศักดิ์ศรี" (prestige) นั้น มักจะมี ระยะเวลาหน่วง (time lag) ขนาดใหญ่มาก

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

ในยุคของมันเอง การวาดภาพไม่ได้ดูเท่ขนาดนี้หรอก

ทุกวันนี้เราถือว่าภาพวาดของเลโอนาร์โด, ไมเคิลแองเจโล หรือราฟาเอล เป็นงานอันสูงส่ง
แต่ในสมัยนั้น ผู้คนอาจมองว่าจิตรกรก็เป็นเพียงช่างฝีมือธรรมดา ๆ เท่านั้น

มันคงดูแปลกมากสำหรับคนร่วมสมัยที่เห็น เฟเดริโก ดา มอนเตเฟลโตร (Duke of Urbino) ในยุคนั้น — และคิดว่าอีก 500 ปีข้างหน้า เขาจะมีชื่อเสียงเพียงเพราะเขาเป็น "คนที่มีจมูกแปลก ๆ" ในภาพวาดของปีเอโร เดลลา ฟรานเชสกา

✅ ดังนั้น ถึงแม้การแฮ็กจะยังไม่ได้ดูเท่ในวันนี้
แต่เราควรจำไว้ว่าการวาดภาพเองก็ไม่ได้ดูเท่ในยุคทองของมันเช่นกัน

และนี่คือข้อสรุปสำคัญที่สุด:

"เรากำลังอยู่ในยุคทองของการแฮ็ก"

ในหลาย ๆ สาขา งานที่ยิ่งใหญ่ที่สุด มักเกิดขึ้น ในช่วงแรก ๆ ของการถือกำเนิดสาขานั้น

ตัวอย่างเช่น:

• ภาพวาดระหว่างปี 1430 ถึง 1500 ยังไม่เคยถูกทำให้เหนือกว่า

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

• อัลเบรชท์ ดือเรอร์ ยกระดับการแกะสลัก

• เจน ออสเตน ยกระดับนวนิยาย

ซ้ำแล้วซ้ำเล่า เราเห็นรูปแบบเดียวกัน:

• สื่อใหม่ ๆ ปรากฏขึ้นมา

• ในสองสามรุ่นแรก ผู้คนที่ตื่นเต้นที่สุดได้สำรวจขอบเขตของมันอย่างแทบหมดสิ้น

และการแฮ็กก็อยู่ในเฟสเดียวกันนี้ในตอนนี้

ดังนั้น...

ในสมัยของเลโอนาร์โด

• การวาดภาพอาจไม่ได้ดูน่าตื่นเต้นเท่ากับที่เราคิดในปัจจุบัน

• แต่สิ่งที่เขาทำได้เปลี่ยนแปลงประวัติศาสตร์

และในตอนนี้

• สิ่งที่เราทำในโลกของการแฮ็ก

• จะเป็นสิ่งที่ทำให้การแฮ็กกลายเป็นหนึ่งในรูปแบบศิลปะที่ยิ่งใหญ่ที่สุดในประวัติศาสตร์มนุษย์

ทั้งหมดนี้ขึ้นอยู่กับว่าเรา "จะทำอะไรได้มากแค่ไหนกับสื่อใหม่นี้"