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 ยังไม่เคยถูกทำให้เหนือกว่า

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

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

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

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

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

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

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

ดังนั้น...

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

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

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

และในตอนนี้

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

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

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