- เมื่อทำระบบอัตโนมัติเล็กๆ น้อยๆ ซ้ำไปเรื่อยๆ วันหนึ่งก็จะถึง จุดวิกฤตทางการรับรู้ ที่ทำให้เครื่องมือและระบบทุกอย่างดูเป็น สิ่งที่ต้องแก้ไข
- ยิ่งทักษะทางเทคนิคสะสมมากขึ้น ก็ยิ่งไม่ใช่แค่รับรู้ปัญหา แต่ยังแบกรับ น้ำหนักทางอารมณ์ที่รู้สึกราวกับเป็นความรับผิดชอบ
- ความอยากแก้ไข ไม่ได้เป็นเพียงการเพิ่มประสิทธิภาพการทำงานเท่านั้น แต่บางครั้งยังกลายเป็น เครื่องมือควบคุมอารมณ์ และบางทีก็นำไปสู่ผลลัพธ์ที่ทำให้ ติดอยู่ในระบบที่ตัวเองสร้างขึ้น
- ระบบย่อมพังตามกาลเวลา และ ภาพลวงของการแก้ปัญหาได้อย่างสมบูรณ์นั้นไม่มีอยู่จริง
- ท้ายที่สุดแล้ว ทักษะที่จำเป็นจริงๆ ไม่ใช่ความสามารถในการแก้ทุกอย่าง แต่คือ ความผ่อนคลายทางใจที่ทนอยู่ได้แม้ไม่ต้องแก้อะไรบางอย่าง
จุดเริ่มต้นจากระบบอัตโนมัติเล็กๆ น้อยๆ
- เริ่มจาก งานเพิ่มประสิทธิภาพเล็กๆ เช่น สคริปต์ Python สำหรับเปลี่ยนชื่อไฟล์ หรือการย่อคำสั่ง
git - พอได้ลงมือแก้ความไม่สะดวกในระบบด้วยตัวเอง ก็จะเริ่มรู้สึกว่า ทุกสิ่งบนโลกดูเหมือนเป็นเป้าหมายที่ควรปรับปรุงได้
- เมื่อถึงจุดหนึ่ง มันจะเปลี่ยนจาก “ทำได้” ไปเป็น แรงกดดันทางศีลธรรม แบบ “ต้องทำ”
น้ำหนักของทักษะทางเทคนิค
- ก่อนจะเขียนโปรแกรม เราอาจปล่อยผ่านซอฟต์แวร์ที่ใช้งานไม่สะดวกได้ แต่ตอนนี้ ปัญหาต่างๆ มองเห็นได้อย่างชัดเจน
- โค้ดที่หละหลวมหรือการตั้งค่าแบบ hardcoded ที่นักพัฒนาคนอื่นทำไว้ กลับ ให้ความรู้สึกราวกับเป็นคำตำหนิ
- เกิดการเปลี่ยนมุมมองที่ทำให้ระบบและซอฟต์แวร์ทุกอย่างดูเป็น รายการ TODO ที่ต้องแก้ไข
ชีวิตที่ต้องรีแฟกเตอร์อย่างต่อเนื่อง
- ทุกครั้งมักคิดว่า “อันนี้ฉันทำให้ดีกว่านี้ได้” จน จมอยู่กับการพัฒนาเครื่องมือของตัวเอง
- ไดเรกทอรีโค้ดที่ไม่เป็นระเบียบ ความพยายามและการล้มเลิกนับไม่ถ้วน การออกแบบโครงสร้างใหม่ไม่รู้จบ ล้วนกลายเป็น แรงงานที่ผูกมัดตัวเอง ได้
- เหมือนคำเปรียบของ Kafka เรื่อง “สร้างกรงแล้วรอนกมา” เราอาจจมอยู่กับการสร้างเครื่องมือโดยไร้เป้าหมายก็ได้
ซอฟต์แวร์ย่อมเสื่อมสภาพ
- แม้แต่สคริปต์ที่เคยดูสมบูรณ์แบบก็อาจ ไร้ประโยชน์ไปในวันหนึ่งเพราะการเปลี่ยนแปลงจากภายนอก
- เช่น การเปลี่ยนเลย์เอาต์เว็บไซต์ การเปลี่ยนเวอร์ชันแพ็กเกจ หรือข้อผิดพลาดจาก dependency
- เมื่อเกิดปัญหา ก็ไม่ได้รู้สึกแค่ไม่สะดวก แต่ยังรู้สึก ผิด
- สุดท้ายจึงต้องเผชิญกับ ความจริงที่ว่าระบบต้องการการดูแลอย่างต่อเนื่อง
ภาพลวงของระบบอัตโนมัติ
- เรามักมี ความหวังลวงๆ ว่า “ตั้งค่าแค่ครั้งเดียวแล้วจะไม่ต้องไปยุ่งอีก”
- เราอาจมองการเขียนโปรแกรมเป็นชัยชนะของการแก้ปัญหา แต่จริงๆ แล้วมันเป็นเพียง สงครามที่ไม่มีวันจบ
- ไม่มีสิ่งที่เรียกว่าความเสร็จสมบูรณ์ มีเพียง การขุดสนามเพลาะที่ถูกน้ำท่วมอยู่เสมอ เท่านั้น
เมื่อการเขียนโค้ดกลายเป็นเครื่องมือควบคุมอารมณ์
- การสร้างเครื่องมือในบางครั้งคือ ปฏิกิริยาทางจิตใจที่พยายามควบคุมความวุ่นวายในชีวิต
- ยิ่งระบบซับซ้อนเท่าไร กลับยิ่งทำให้เรารู้สึกว่าตัวเองเป็นระเบียบมากขึ้น
- เพื่อหลีกหนีชีวิตที่ซับซ้อน เราจึง ลองทำแอปใหม่หรือรีแฟกเตอร์ เพื่อ ปลอบใจตัวเอง
ภาวะหมดไฟที่มาโดยไม่ทันตั้งตัว
- ภาวะหมดไฟไม่ได้เกิดจากการทำงานหนักอย่างเดียว แต่เกิดจาก ความรับผิดชอบที่มากเกินไป
- การตำหนิตัวเองว่า “ในเมื่อฉันแก้ได้ แล้วทำไมถึงไม่แก้?” ยิ่งเพิ่มความเครียด
- ความรับผิดชอบทางเทคนิคที่ไม่สิ้นสุดกลายเป็น ภาระที่บ่อนทำลายตัวเอง
เรียนรู้ทักษะของการปล่อยวาง
- ไม่จำเป็นต้องแก้ทุกปัญหา
- บางครั้ง การรู้ว่าไม่จำเป็นต้องแก้ ก็เป็นการควบคุมที่ยิ่งใหญ่กว่า
- การยอมรับข้อบกพร่องและใช้งานมันต่อไป ก็อาจเป็น ทางเลือกที่มีสติ ได้เช่นกัน
ทักษะที่แท้จริงคือความชัดเจนทางอารมณ์
- สำคัญกว่าทักษะในการแก้ คือ ทักษะทางใจที่อยู่ได้โดยไม่ต้องแก้
- ความสามารถในการแยกแยะว่าควรหยุดเมื่อไร และโปรเจกต์ไหนเป็นเพียง การปลอบใจตัวเอง
- เราจำเป็นต้องหลุดพ้นจากความยึดติดที่จะซ่อมทุกอย่าง และ หาท่าทีที่สบายใจกับความไม่สมบูรณ์แบบ
ท้ายที่สุดแล้ว ทักษะที่ยากที่สุดในโปรแกรมมิ่งคือ
"การเรียนรู้ที่จะปล่อยให้สิ่งที่พังอยู่แบบนั้น"
21 ความคิดเห็น
ทุกสิ่งมีเป้าหมาย หากบรรลุเป้าหมายแล้วก็ไม่จำเป็นต้องแก้ต่อ แต่ถ้ายังไม่บรรลุเป้าหมาย ก็ต้องแก้ไข
จุดเริ่มต้นคงเป็นการทำความเข้าใจเป้าหมายของโปรเจกต์ให้ชัดเจน
พอคุณตระหนักได้ว่า ในโลกนี้ยังมีบริษัทที่มีมูลค่าระดับหลายแสนล้านวอน เพียงแค่ทำหน้าที่รวบรวมและจัดระเบียบ API สุดเละเทะของพวกธนาคารและผู้ให้บริการชำระเงินต่าง ๆ ก็จะสบายใจขึ้นครับ 555
Ku x..
ถ้าคุณเห็นว่าระบบที่สร้างด้วย VB 6.0 และ COM + OLE + ActiveX ยังทำงานได้ดีอยู่ก็ถึงกับผงะและเกิดความอยากเขียนมันขึ้นมาใหม่ คุณคือคนที่จะต้องทุกข์ทรมาน
ท้ายที่สุดแล้ว ทักษะที่ยากที่สุดในการเขียนโปรแกรมคือ
การเรียนรู้ที่จะ "ปล่อยสิ่งที่พังไว้แบบนั้น"
เห็นด้วยเลยครับ/ค่ะ ผม/ฉันเป็นคนประเภทชอบเริ่มอะไรใหม่ ๆ เลยต้องเหนื่อยอยู่เสมอ...
ระบบอัตโนมัติที่โปรแกรมเมอร์คนหนึ่งปะติดปะต่อขึ้นมาแบบลวก ๆ แน่นอนว่าย่อมพังได้อยู่แล้ว
เนื้อหาดี
เบิร์นเอาต์แบบ Dotdem
: พออุตส่าห์ทำระบบงานอัตโนมัติอย่างยากลำบาก คนที่ได้ประโยชน์กลับเป็นเพื่อนร่วมงานข้าง ๆ แต่ตัวเองกลับถูกส่งไปทำงานอัตโนมัติของงานอื่นต่อ;
ผมเป็นหนึ่งในพวกชอบอู้งานที่พองานซึ่งใช้เวลา 15 นาทีไปทำให้เป็นอัตโนมัติ กลับใช้เวลาถึง 2 วัน
ความรู้สึกรับผิดชอบที่มากเกินไปเหมือนเป็นโรคประจำอาชีพของโปรแกรมเมอร์ เลยต้องแก้ด้วยระบบครับ
ให้ทีม Quality Assurance มา assure นั่นแหละ
QA สามารถช่วยยับยั้งความรู้สึกรับผิดชอบที่มากเกินไปของนักพัฒนาได้งั้นเหรอครับ? ผมยังไม่ค่อยเข้าใจเท่าไรครับ
เมื่อมีการไล่บี้หาความผิดจากนักพัฒนาแล้วบอกว่า “คุณเขียนโค้ดผิดเอง” สะสมมากขึ้น
นักพัฒนาก็จะถูกความรับผิดชอบกดดันจนหลีกเลี่ยงการลองสิ่งใหม่ ๆ
สุดท้ายก็จะเขียนแต่โค้ดที่ปลอดภัยซึ่งไม่มีความก้าวหน้าเท่านั้น
ความหมายของการที่ QA ต้อง Assure ก็คือแบบนั้นแหละ
ถ้าจะเขียนโค้ดเชิงพัฒนา ย่อมต้องแบกรับความเสี่ยงในระดับหนึ่ง
และสิ่งที่ QA ควรเป็นก็คือผู้ที่ตรวจสอบและรับผิดชอบในส่วนนั้น
อ่านบทความนี้แบบนั้นได้ด้วยเหรอครับ? ถ้าจะให้ผมตีความ ผมคิดว่าบทความนี้เป็นบทความที่วิจารณ์เรื่อง yak shaving มากกว่านะ
อย่างที่คุณ roxie พูดไว้ เรื่องในเนื้อหาหลักก็คือเรื่องเกี่ยวกับ yak shaving จริง ๆ แต่
พอเทียบกับประสบการณ์ส่วนตัวของผมแล้ว มันเลยกลายเป็นเรื่องที่ค่อนข้างคนละทิศคนละทางกับเนื้อหาหลักไปหน่อยครับ
อาจอธิบายได้ด้วยปรากฏการณ์ NIH (not invented here) เช่นกันหรือเปล่า? ผมคิดว่าเราไม่ควรลืมว่าการบำรุงรักษาก็คือต้นทุนคงที่ และในต้นทุนนั้นก็รวมถึงความพยายามของคนด้วย
ถ้าจะทำสิ่งนี้ไปได้นาน ๆ ดูเหมือนว่าเราก็คงต้องฝึกวางน้ำหนักของความรับผิดชอบและอารมณ์ลงบ้างเป็นครั้งคราว
ก่อนจะตกเข้าไปในวงจรของการชดเชยทางใจจากความรับผิดชอบที่มากเกินไป
ตัวผมเองก็ยังจัดการส่วนนี้ได้ไม่ค่อยดีเหมือนกัน 555... เป็นเนื้อหาที่ดีนะครับ
ผมคิดว่านี่เป็นประเด็นที่ดีนะครับ ความรับผิดชอบนั้นตามความหมายตรงตัวคือการรู้สึกว่าตัวเองต้องรับผิดชอบ ดังนั้นโดยตัวมันเองจึงไม่ได้เรียกร้องสิ่งตอบแทน แต่เมื่อเวลาผ่านไป ร่างกายและจิตใจก็ค่อยๆ อ่อนล้า ขณะที่ความรับผิดชอบไม่ได้หายไปง่ายๆ และเพื่อเติมช่องว่างนั้น เราก็ดูเหมือนจะเริ่มคาดหวังสิ่งตอบแทนขึ้นมาเอง (ทั้งที่จริงๆ ไม่ควรโยงสองอย่างนี้เข้าด้วยกัน) โดยที่เจ้าตัวอาจไม่ทันรู้ตัว
ก็นะ จุดประนีประนอมที่ยังพอเข้าท่ากว่า "ปล่อยของที่พังไว้แบบนั้น" ก็คงเป็น "อย่าไปแตะมันจนกว่ามันจะพัง" :)
ความเห็นจาก Hacker News
มีคำคมหนึ่งที่ได้เรียนรู้ตอนเล่นละคร ซึ่งอธิบายว่ากระบวนการของศิลปะคือทำให้สิ่งที่ยากกลายเป็นนิสัย ทำให้สิ่งที่เป็นนิสัยกลายเป็นเรื่องง่าย และทำให้สิ่งที่ง่ายงดงาม
เสนอความเห็นส่วนตัวเกี่ยวกับปัญหา UI
ระบายถึงความยากลำบากของโปรเจกต์ส่วนตัว
แสดงความเคารพต่อวิศวกรซอฟต์แวร์
วิจารณ์แนวคิดสมบูรณ์แบบนิยม
แบ่งปันข้อคิดส่วนตัว
กล่าวว่าครอบครัวและลูก ๆ ช่วยให้รับมือกับความสมบูรณ์แบบนิยมได้
การเขียนซอฟต์แวร์ด้วยตนเองสนุกกว่าและให้ทางแก้ที่เรียบง่ายกว่า
อ้างว่าวัฒนธรรมที่หมกมุ่นกับของใหม่คือรากของปัญหา
นักจิตวิทยาแบ่งคนออกเป็นคนที่ต้องการสิ่งที่ดีที่สุดเสมอกับคนที่มองหาสิ่งที่ดีพอ
ดูเหมือนว่าประโยคที่เหมาะสมกว่าจะเป็น "การรู้จักปล่อยวางสิ่งที่ไม่สำคัญ" มากกว่า "การปล่อยให้สิ่งที่พังอยู่แบบนั้น"
สิ่งที่ต้องแก้จริง ๆ ก็ต้องแก้อยู่แล้ว
เห็นด้วยครับ/ค่ะ ผม/ฉันคิดว่าเราต้องรู้ให้ชัดว่าตัวเองกำลังตกแต่งสวนให้สวยขึ้นอยู่ หรือกำลังทำงานที่สำคัญจริง ๆ แล้วจึงค่อยปล่อยวาง