จงประดิษฐ์ล้อขึ้นมาใหม่ - Reinvent the Wheel
(endler.dev)- คำแนะนำว่า "อย่าประดิษฐ์ล้อขึ้นมาใหม่" อาจส่งผลด้านลบด้วยการกดทับความคิดสร้างสรรค์และความใฝ่รู้
- การสร้างล้อแบบใหม่ หรือก็คือ การสร้างเครื่องมือหรือเทคโนโลยีเดิมขึ้นมาใหม่ ทำให้เกิดความเข้าใจเชิงลึกและการเรียนรู้
- แม้แต่ องค์ประกอบพื้นฐาน ที่ดูเรียบง่ายหรือคุ้นเคย แท้จริงแล้วก็มีความซับซ้อนและมี trade-off หลากหลาย
- การลองประดิษฐ์ล้อในแบบของตนเองช่วยเสริมความสามารถด้าน การเติบโต การแก้ปัญหา และการทดลอง
- เน้นความจำเป็นของการเลือกอย่างสมดุลระหว่าง การใช้ผลงานที่มีอยู่เดิมกับการสร้างขึ้นใหม่ ตามเป้าหมาย
Reinvent the Wheel
- คำพูดว่า "อย่าประดิษฐ์ล้อขึ้นมาใหม่" แม้มีเจตนาดี แต่เป็นคำแนะนำที่มาจากคนอยู่สองกลุ่ม
- คนที่เคยลองสร้างล้อด้วยตัวเองและได้สัมผัสความยากของมัน
- คนที่ไม่เคยลอง แต่ทำตามคำแนะนำเดิมอย่างไม่ตั้งคำถาม
- เมื่อคำแนะนำลักษณะนี้ถูกพูดซ้ำ ๆ ก็จะสร้างบรรยากาศที่ทำให้ความอยากรู้อยากเห็นและจิตวิญญาณแห่งการสำรวจหดตัวลง
- ย้ำว่า หากทุกคนทำตามคำแนะนำนี้ทั้งหมด เราอาจไม่มีความสะดวกสบายและความก้าวหน้าสมัยใหม่มากมายในทุกวันนี้
- ในความเป็นจริง ล้อเองก็ถูกสร้างขึ้นใหม่และพัฒนาต่อมาหลายครั้งหลังการประดิษฐ์ครั้งแรก
หมายเหตุ: ในที่นี้ 'ล้อ' สามารถแทนด้วยเครื่องมือ โปรโตคอล บริการ เทคโนโลยี หรือสิ่งประดิษฐ์อื่นใดก็ได้
การประดิษฐ์ล้อด้วยตัวเองก็คือการเรียนรู้
"สิ่งที่ฉันสร้างเองไม่ได้ ฉันยังไม่อาจบอกได้ว่าเข้าใจมัน"
— Richard Feynman
- หากต้องการ เข้าใจบางสิ่งอย่างลึกซึ้งจริง ๆ จำเป็นต้องมีประสบการณ์ลงมือสร้างมันเอง แม้จะเป็นเวอร์ชันเล็ก ๆ ก็ตาม
- ต่อให้ผลลัพธ์ไม่สมบูรณ์ หรือสุดท้ายจะไม่ได้ใช้งาน กระบวนการลงมือสร้างนั้นเองก็สำคัญ
- แนวคิดหลายอย่างในวิทยาการคอมพิวเตอร์—เช่น โปรโตคอล การเข้ารหัส เว็บเซิร์ฟเวอร์—อาจดูยาก แต่จริง ๆ แล้วใครก็ลองทำได้
- เมื่อมีผู้คนได้ลองสร้างด้วยตัวเองมากขึ้น ก็จะมีโอกาสเข้าใจ โครงสร้างและแก่นแท้ของเทคโนโลยีที่มีอยู่ มากขึ้น
ทุกสิ่งคือกระบวนการสำรวจที่ไม่มีวันสิ้นสุด (Rabbit Hole)
- องค์ประกอบพื้นฐานที่เรามองว่าเป็นเรื่องธรรมดา—เช่น สตริง หรือพาธของไฟล์—แท้จริงแล้วซับซ้อนมาก
- การลองสร้างไลบรารีสตริงหรือพาธของตัวเองเป็นโอกาสสำคัญในการเรียนรู้
- ผ่านกระบวนการนี้ เราจะตระหนักถึงข้อเท็จจริงอย่างเช่น
- แม้แต่สิ่งในชีวิตประจำวันก็มี ความซับซ้อนที่แทบไร้ขอบเขต
- การสร้าง สิ่งที่มีประโยชน์ต่อผู้อื่น เป็นโอกาสให้เราได้เรียนรู้ความถ่อมตน
- ทุก abstraction ล้วนเป็นสิ่งที่มนุษย์สร้างขึ้น ไม่สมบูรณ์แบบ และอาจมี trade-off อีกรูปแบบหนึ่งได้เสมอ
- ระหว่างการลงมือทำ เราต้องเผชิญกับทางเลือกและปัญหามากมาย เช่น ความถูกต้อง ความเรียบง่าย ประสิทธิภาพ การขยายตัว และการพกพาข้ามระบบ
- วิธีแก้ปัญหาที่เราสร้างเองอาจยอดเยี่ยมในบางด้าน แต่ไม่ได้เหมาะกับผู้ใช้หรือสถานการณ์ทั้งหมด
- โซลูชันที่มีอยู่เดิมเองก็มีข้อจำกัด และอาจไม่เหมาะกับปัญหาของเรา
- ประสบการณ์ของการขุดลึกกับปัญหาเดียวจนสุดทางคือส่วนหนึ่งของการเติบโตเป็นวิศวกร
- หากเอาแต่ย้ายไปมาระหว่างโปรเจกต์บ่อย ๆ ก็จะไม่ได้การเรียนรู้ที่มีความหมาย
เหตุผลที่ควรประดิษฐ์ล้อขึ้นมาใหม่
- ต้องการสร้างล้อที่ดีกว่าเดิม (ซึ่งคำว่า ‘ดีกว่า’ มีความหมายได้หลายแบบ)
- มีเป้าหมายเพื่อเรียนรู้ว่าล้อถูกสร้างขึ้นมาอย่างไร
- เพื่อ สอนหลักการของล้อให้ผู้อื่น ในเชิงการศึกษา
- การสำรวจกระบวนการประดิษฐ์ล้อช่วยให้เกิดความเข้าใจใหม่ ๆ
- พัฒนาความสามารถในการ ซ่อมแซมหรือปรับปรุง ได้ด้วยตนเองเมื่อมันพัง
- ทำให้ได้เรียนรู้เครื่องมือและทักษะหลากหลายที่จำเป็นต่อการสร้างล้อ
- เข้าใจบทบาทของล้อในฐานะส่วนหนึ่งของระบบที่ซับซ้อนกว่า (เช่น รถยนต์)
- เพื่อพยายามสร้างล้อที่พิเศษมากสำหรับความต้องการเฉพาะ (เช่น รถเข็นวีลแชร์ สเกตบอร์ด หรือล้อปั้นเครื่องปั้นดินเผา)
- ล้อที่เราสร้างอาจกลับถูกนำไปใช้ในงานอีกแบบหนึ่งได้ดีกว่าเป้าหมายเดิมโดยสิ้นเชิง
- ในโลกนี้ แนวคิดใหม่ที่ไม่ยึดติดกรอบเดิม อาจมีบทบาทสำคัญอย่างมาก
Reuse vs Reinvent
- เราไม่ควรมองข้ามผลงานของผู้อื่น แต่ควรศึกษางานของพวกเขาและนำมาใช้อย่างเหมาะสม
- ควรระวังไม่ทิ้งของเดิมแล้วสร้างใหม่เพียงเพราะ ความไม่ไว้วางใจหรือความไม่รู้
- แต่หากไม่เคยลงมือสร้างหรือทดลองเอง ก็ยากที่จะเข้าใจ แก่นสำคัญและการพัฒนา ของสาขานั้นอย่างแท้จริง
- ในวิศวกรรมซอฟต์แวร์ การทดลองเล็ก ๆ และการทำต้นแบบทำได้ง่ายและรวดเร็ว จึงมีประสิทธิภาพต่อการแก้ปัญหาส่วนบุคคล
- แนะนำให้ เริ่มจากเล็ก ๆ ทำให้เรียบง่าย และค่อย ๆ วนปรับปรุง
- ดังนั้นคำแนะนำสุดท้ายของฉันคือ
- หากต้องการ insight ให้ลองสร้างขึ้นใหม่ด้วยตัวเอง
- หากต้องการ impact ให้ใช้โซลูชันที่ผ่านการพิสูจน์แล้วซ้ำอีกครั้ง
"Reinvent for insight. Reuse for impact."
"สร้างขึ้นใหม่เพื่อให้เกิดความเข้าใจลึกซึ้ง และนำของเดิมมาใช้ซ้ำเพื่อสร้างผลกระทบ"
8 ความคิดเห็น
พอจะทำล้อสี่เหลี่ยมให้กลายเป็นล้อกลม ก็ทำให้นึกถึงคำพูดของเจ้านายที่บอกว่าอย่าไปประดิษฐ์ล้อขึ้นมาใหม่ ยังมีผีเฝ้าคำว่า "อย่าประดิษฐ์ล้อใหม่" อยู่รอบตัวอีกเยอะเลย
ผมมองว่า เช่นเดียวกับที่คำว่า "วัวหายแล้วค่อยล้อมคอก" ไม่ได้หมายความว่าไม่ต้องเตรียมพร้อมสำหรับอนาคต
คำว่า "อย่าประดิษฐ์ล้อขึ้นมาใหม่" ก็ไม่ได้หมายความว่าไม่ควรลงทุนเวลาเพื่อให้ได้มาซึ่งความเข้าใจลึกซึ้ง
หากตัดคำพูดเหล่านี้ออกจากบริบทที่มันถูกพูดขึ้นมา ความหมายที่แท้จริงก็จะบิดเบือนไป
นี่เป็นประสบการณ์ล่าสุดของผมเอง แต่เมื่อไม่นานมานี้ผมได้สร้างวงล้อที่พิเศษมากของตัวเองขึ้นมาอันหนึ่ง
การบิลด์แอปบน Nuxt ที่มี 1000 หน้าเคยใช้เวลา 7 นาที
แต่หลังจากยอมละทิ้งระบบอัตโนมัติบางอย่างแล้วเขียนขึ้นใหม่ ผลลัพธ์คือบิลด์ได้สำเร็จใน 20 วินาที
การตัดสินใจว่าเราควรสร้างอะไรขึ้นมาใหม่เองถึงตรงไหน และควรพึ่งพา dependency ภายนอกถึงตรงไหนนั้นเป็นเรื่องยาก
ไม่ว่าในกรณีไหน การเลือก dependency นั้นเพราะอยากประหยัดเวลาที่ต้องลงมือทำสิ่งนี้เอง กับการที่หากไม่มี dependency นั้นแล้วจะไม่สามารถสร้างบริการได้จนต้องถูกผูกติดกับมัน เป็นคนละเรื่องกันโดยสิ้นเชิง
อาจทำแบบนั้นไม่ได้กับโค้ดทุกส่วนเสมอไป (อย่างระบบปฏิบัติการ เป็นต้น) แต่การพยายามขยับไปทางอย่างแรกให้มากที่สุดเท่าที่ทำได้ ก็น่าจะช่วยให้เข้าใจระบบได้ดีขึ้น
สุภาษิตมันมีความหมายแฝงอยู่ แต่เดี๋ยวนี้คนที่ตีความกันแค่ตามตัวอักษรมีมากขึ้น
ถ้ากระแสคำพูดแบบนั้นมาอีก เดี๋ยวห้องประชุมก็เละเทะกันอีกแบบไม่มีใครรู้สึกอะไร
พวกสาย paperwork จะคึกคักกันใหญ่ แล้วก็ทำความล้มเหลวแบบเดิมซ้ำอีกทุกปี
ความคิดเห็นจาก Hacker News
ฉันเคยมีประสบการณ์สร้างล้อขึ้นมาใหม่ด้วยตัวเองในบางสาขา ไม่ได้ตั้งใจจะทำแบบนั้นตั้งแต่แรก แต่เพราะคิดว่าเทคโนโลยีที่มีอยู่นั้นผิดทาง ฉันมักเข้าหาปัญหาที่คนทั่วไปบอกว่าเป็นไปไม่ได้ด้วยวิธีแบ่งแยกแล้วพิชิต โชคดีด้วยและดื้อพอตัว สุดท้ายเลยทำสำเร็จ ล้อของฉันมีประสิทธิภาพเหนือกว่ามากในสาขานั้น พอลองทำการทดลอง ก็ทำให้สิ่งที่เดิมคิดว่าเป็นไปไม่ได้กลายเป็นเรื่องที่ทำได้ง่ายมาก เมื่อเวลาผ่านไป คนอื่นในสาขานั้นก็เริ่มใช้ล้อของฉันเช่นกัน ตอนแรกทุกคนจะงง ๆ แต่พอเรียนรู้แล้วก็ไม่กลับไปแบบเดิมอีก ฉันได้รับบั๊กรีพอร์ตและคำขอฟีเจอร์จาก use case และ workflow แปลก ๆ ทั่วโลก ได้คุยเชิงเทคนิคแบบลึก ๆ กับคนเก่งที่ปกติไม่มีทางได้เจอกันตรง ๆ ได้เห็นคนอื่นทำสิ่งที่ไม่มีใครคาดคิดได้ด้วยล้อที่ฉันสร้าง ได้ค้นพบเรื่องใหม่ ๆ จนทำให้นอนไม่หลับด้วยความตื่นเต้น และยังสนุกกับการเห็นเพื่อนร่วมงานสมองค้างเมื่ออธิบายความสามารถของล้อฉันให้ฟังด้วย ไม่ต้องกลัวการสร้างล้อขึ้นมาใหม่หรอก ไม่มีใครรู้ว่ามันจะกลิ้งไปสู่เส้นทางบ้าคลั่งแบบไหน
นอกจากเหตุผลเรื่องทำล้อเดิมให้ดีขึ้นแล้ว ผมคิดว่ายังมีอีกเหตุผลสำคัญที่ตกหล่นไป คือเราสามารถสร้างล้อที่พอดีกับตัวเราเป๊ะ ๆ และใช้มันในสภาพนั้นต่อไปได้ ผมเห็นคนพูดว่า “อย่าสร้างล้อซ้ำ” แล้วพยายามยัดล้อรถยนต์ใส่จักรยานอยู่บ่อย ๆ ถ้าสร้างทุกส่วนของระบบให้เข้ากันได้ดีด้วยตัวเอง เราอาจได้ประโยชน์มากกว่าที่คิด
หนึ่งในเหตุผลสำคัญของการสร้างล้อขึ้นมาใหม่ คือเพื่อหลีกเลี่ยงความซับซ้อนที่ถูกเพิ่มเข้ามาโดยไม่จำเป็นจาก dependency ที่ไร้ประโยชน์
เห็นด้วยสุด ๆ ที่ไลบรารียอดนิยมมักแก้ปัญหาได้หลายสถานการณ์ แต่เพราะแบบนั้นเอง หลายครั้งจึงมีโค้ดที่ไม่จำเป็นติดมาด้วยเต็มไปหมด ประเด็นสำคัญคือ ถ้าฉันสามารถสร้างฟังก์ชันที่ต้องการได้ในเวลาไม่นาน การทำเองจะดีกว่าทั้งในแง่การใช้งานและการลด dependency ให้น้อยที่สุด ยกเว้นอย่างเดียวคือไลบรารีเข้ารหัส อันนั้นไม่แนะนำให้ทำเองเด็ดขาด
นี่คือเหตุผลใหญ่ที่สุดที่ฉันสร้างล้อขึ้นมาใหม่ dependency มักพาฟีเจอร์ที่เราไม่ต้องการติดมาด้วย ฉันต้องการแค่ความสามารถระดับขี่ไปซูเปอร์แถวบ้านเท่านั้น และส่วนตัวฉันไม่เชื่อโค้ดที่ไม่โปร่งใส ต่อให้ใช้ dependency มันก็ควรเป็นสิ่งที่ฉันใช้เวลาสักวันเดียวก็ทำเองได้ และตรวจสอบได้ ฉันจะไม่ใช้ไบนารีที่ดูซอร์สโค้ดไม่ได้ เว้นแต่จะซื้อด้วยเงิน ถ้าฟรีก็ต้องเปิดเผยซอร์สโค้ดเสมอ
ฉันทำไลบรารี task runner ที่อิงกับ DAG (กราฟมีทิศทางแบบไม่มีวัฏจักร) ขึ้นมาเอง และทำให้ task อยู่ในคิวได้ เพราะอยากรันเดโมบนเว็บเบราว์เซอร์จึงทำแบ็กเอนด์ IndexedDB สำหรับ Electron app ก็ทำ SQLite และสำหรับสภาพแวดล้อมเซิร์ฟเวอร์หลายผู้ใช้ก็ทำแบ็กเอนด์ Postgres แยกไว้ต่างหาก แล้วยังเพิ่ม limiter สำหรับจำกัดความเร็วด้วย นอกจากนั้นก็ต้องทำล้ออีกหลายอันเอง ทั้งเรื่องการประมวลผลกราฟและการจัดการ task ถ้าจะทำแบบไม่มี dependency เลย งานมีเยอะจริง ๆ แต่ฉันก็แยก branch ไว้สำหรับสร้างและตรวจสอบสคีมาอินพุต/เอาต์พุตของ task ด้วย TypeBox สุดท้ายแล้วอาจมี dependency อีกตัวเข้ามาอยู่ในแกนหลักก็ได้
อีกเหตุผลหนึ่งคือ มันช่วยฝึกความสามารถในการประดิษฐ์หรือวิจัยสิ่งใหม่ ๆ ผ่านการลงมือฝึก ปัญหาที่มีคนแก้ไปแล้วก็ยังใช้ฝึกได้ดีพอ
บางครั้งก็สร้างล้อขึ้นมาใหม่เพื่อหลีกเลี่ยงความซับซ้อนอย่าง abstraction หรือ modularization ที่ไม่จำเป็น
เป็นบทความที่ชวนคิดต่อได้ดี ผมเองก็มีประสบการณ์คล้ายกัน โดยสร้างไลบรารีแมชชีนเลิร์นนิงสไตล์ PyTorch (ml-by-hand) ขึ้นมาตั้งแต่ศูนย์โดยใช้แค่ Python กับ NumPy เริ่มจาก autograd engine ขนาดเล็ก แล้วค่อย ๆ ลงมือทำ layer, optimizer, dataloader และส่วนอื่น ๆ เองทีละขั้น ผมเริ่มเพราะอยากเรียนรู้หลักการพื้นฐานล้วน ๆ ด้วยไลบรารีที่ทำเองนี้ ผมลองสร้างตามตั้งแต่ convolutional neural network แบบคลาสสิก (cnn example) ไปจนถึง GPT-2 แบบง่าย (gpt2 example) มันทำให้ผมเข้าใจมากขึ้นมากว่าแมชชีนเลิร์นนิงทำงานภายในอย่างไรโดยไม่มี abstraction ของ PyTorch หรือ TensorFlow เท่ากับว่าผมไม่เพียงสร้างล้อขึ้นมาใหม่ แต่ยังสร้างรถทั้งคันขึ้นมาเองจากล้อนั้นด้วย
ขอต่อจากคำพูดที่ว่า คนที่มักพูดว่า “อย่าสร้างล้อขึ้นมาใหม่” มีอยู่สองประเภท ที่จริงผมคิดว่ายังมีประเภทที่สามซึ่งพบได้บ่อยกว่ามาก คือคนที่รู้ดีถึงความลำบากของการสร้างล้อซ้ำ เคยผ่านกระบวนการนั้นมาแล้ว และตัดสินว่าไม่คุ้มเลยที่จะทำเอง ไม่ว่าจะด้วยเหตุผลด้านการเรียนรู้หรืออะไรก็ตาม
การสร้างล้อขึ้นมาใหม่คือวิธีเรียนรู้ที่ดีที่สุด แต่ผมคิดว่ามันจริงเฉพาะในบริบทของการเรียนรู้เท่านั้น ผมเองก็ชอบขุดลึกกับอะไรสักอย่าง แต่ในบริษัทก็มักมีเส้นตายและข้อจำกัดอื่น ๆ ที่ทำให้สำรวจได้ไม่เต็มที่ ถ้าจะเอาล้อที่สร้างขึ้นไปใช้กับงานจริง มันต้องดีกว่าของเดิมอย่างชัดเจนถึงจะคุ้มใช้
99% ของคนที่สร้างล้อขึ้นมาใหม่ในที่ทำงาน แทบไม่รู้ด้วยซ้ำว่าล้อเดิมถูกสร้างอย่างไร หรือทำไมมันถึงมีโครงสร้างประนีประนอมแบบนั้น
การลงมือสร้างเองไม่ได้เป็นวิธีเรียนรู้ที่ดีที่สุดเสมอไป เพราะใช้ทั้งเวลาและต้นทุนสูง ถ้ามีเอกสารที่ดีและสภาพแวดล้อมทดลองที่เหมาะสม ก็เรียนรู้ได้เพียงพอ ความชัดเจนในการถ่ายทอดความรู้เองก็เป็นโจทย์อีกแบบหนึ่ง ไม่จำเป็นต้องสร้างทั้งระบบขึ้นมาใหม่จากพื้นเสมอไป
ตอนนี้กำลังทดลองทำระบบรัฐบาลขึ้นมาใหม่ในระดับโลกอยู่ แน่นอนว่าไม่ใช่รัฐบาลจริง เช่น ua.gov-ai.co, ua.ai-gov.co, ng.gov-ai.co, ng.ai-gov.co เป็นต้น ตอนนี้ CBER กับ DDP คืบหน้ามากที่สุด และทำไปถึง 422 หน่วยงานแล้ว อยากทำให้เสร็จก่อน Juneteenth การสร้างพื้นฐานขึ้นมาใหม่แบบนี้ช่วยให้เข้าใจหลักการระดับรากฐานมากขึ้น ผมรู้อยู่แล้วว่ามันคงไม่ก่อผลลัพธ์ที่ใช้งานจริงอะไร แต่ก็มีประโยชน์ในการจัดระเบียบความคิดใหม่ทุกครั้งที่แก่นสารสำคัญเปลี่ยนไป ผมมองว่าการทดลองสร้างล้อขึ้นมาใหม่มีความหมายเสมอ
ถ้าคุณทำงานในสตาร์ตอัป ผมคิดว่าควรเมินคำแนะนำแบบนี้ให้มากที่สุดเท่าที่จะทำได้ (ยกเว้นกรณีที่ล้อใหม่ที่กำลังสร้างเป็นแกนหลักด้านประสิทธิภาพของบริการ) ไม่อย่างนั้นมีโอกาสสูงที่จะเผาทรัพยากรอันจำกัดจนธุรกิจจบก่อนจะเริ่มเสียอีก
ถึงอย่างนั้น สำหรับสตาร์ตอัป ผมก็คิดว่าสำคัญที่จะต้องทำงานกับคนที่เคยสร้างล้อด้วยตัวเองมาก่อน หรือพูดอีกแบบคือคนที่สร้างล้อเป็นจริง ๆ อย่างน้อยควรมีประสบการณ์จากโอเพนซอร์สหรือโปรเจกต์ส่วนตัว
คำแนะนำแบบนี้น่าจะไม่ได้พูดในเชิงอาชีพ แต่หมายถึงการทดลองสร้างล้อเพื่อการเรียนรู้ส่วนตัวมากกว่า
นึกถึงคำคมที่เพื่อนเคยพูดไว้ “เหตุผลที่เราสร้างล้อขึ้นมาใหม่ ไม่ใช่เพราะเราต้องการล้อเพิ่ม แต่เพราะเราต้องการนักประดิษฐ์เพิ่ม” ฉันเคยมีประสบการณ์หลายครั้งที่การลงมือสร้างเองเพื่อเรียนรู้แนวคิดใหม่ ทำให้ทั้งหัวและใจรู้สึกมั่นคงขึ้น พอได้เจอคำพูดของไฟน์แมนที่ว่า “สิ่งที่ฉันสร้างไม่ได้ แปลว่าฉันยังไม่เข้าใจมัน” ความเชื่อแบบนี้ก็ยิ่งแข็งแรงขึ้น ทุกครั้งที่สร้างล้อขึ้นมาใหม่ ฉันจะมีสัญชาตญาณต่อแนวคิดแรกเริ่มนั้นชัดขึ้น และยังได้เรียนรู้เรื่องที่ไม่เคยรู้มาก่อนด้วย
ผมมองว่าบรรยากาศที่ต่อต้านความซ้ำซ้อนมากเกินไปคือปัญหาของยุคเรา ทุกคนค่อย ๆ เหมือนกันไปหมด กินอาหารแบบเดียวกัน ทำงานคล้ายกัน และเคลื่อนไหวตามความต้องการที่คล้ายกัน ถ้าผลักแนวคิดอย่าง ‘ห้ามสร้างล้อซ้ำ’ ไปจนสุดทาง สุดท้ายเป้าหมายอาจกลายเป็นการเป็นคนที่ไม่รู้อะไรเลยและคอยตอบสนองความต้องการเฉพาะของคนรวยไม่กี่คนเท่านั้น เป็นชีวิตที่ไม่เรียนรู้การทำอาหาร ไม่เรียนรู้การเกษตร แม้แต่ความรักก็ไม่เรียนรู้
บริษัทเป็นสถานที่สำหรับมาเรียนรู้หรือ? หรือเป็นสถานที่ที่นำวงล้อที่คนอื่นสร้างไว้แล้วมาสร้างคุณค่าใหม่?
การสร้างเป็นแค่จุดเริ่มต้น และถ้าให้บริการไปสักราว 10 ปี ระหว่างทางก็คงมีเรื่องสารพัดเกิดขึ้น ซึ่งถ้าจะยืนหยัดอยู่ตรงนั้นได้ก็คงต้องมีพื้นฐาน... ต้องเรียนรู้ครับ