‘Can’t be fucked’: สาเหตุของหนี้ทางเทคนิคที่ถูกประเมินต่ำเกินไป
(jesseduffield.com)- ความสามารถในการพัฒนาไม่ได้ถูกกำหนดด้วยความรู้เพียงอย่างเดียว และแม้จะรู้ว่าต้องทำอะไร หากผัดวันประกันพรุ่งเรื่องการทดสอบ การรีแฟกเตอร์ และการเขียนกรณีทำซ้ำเพราะ ขาดแรงจูงใจ หนี้ทางเทคนิคก็จะสะสมขึ้น
- นักพัฒนาที่ยอดเยี่ยมจะสืบสวนและแก้ flaky test เปลี่ยนบั๊กที่พบให้เป็น ticket หรือแก้ทันที และถ้าฟีเจอร์ใหม่ไม่เข้ากับโค้ดเดิมก็จะ รีแฟกเตอร์ ก่อน
- คำคมอย่าง “premature optimisation”, “duplication is better than the wrong abstraction”, “Keep It Simple, Stupid” มีประโยชน์เมื่อใช้รับมือกับข้อจำกัดจริง แต่ก็อาจถูกใช้เป็นคำพูดที่ซ่อนความหมายว่าแค่ ไม่อยากทำ ได้เช่นกัน
- ใน Lazygit มีการสร้างระบบทดสอบ end-to-end ตลอดหลายเดือนและเห็นผลลัพธ์ชัดเจน แต่ใน Lazydocker กลับไม่ได้เพิ่มการทดสอบแบบเดียวกัน และยังผัดเรื่องการขอ minimal reproduction repository กับการรีแฟกเตอร์ God Struct ออกไป
- แม้จะไม่มีพลังพอจะเขียนโค้ดให้สมบูรณ์แบบ การเปิดเผยอย่างตรงไปตรงมาว่าส่วนไหนยังขาดอยู่ จะช่วยให้ตัดสินได้ง่ายขึ้นทั้งเรื่องมาตรฐานการบำรุงรักษาและลำดับความสำคัญของงานถัดไป
การขาดแรงจูงใจที่สร้างหนี้ทางเทคนิค
- “Can’t Be Fucked” เป็นสแลงแบบออสเตรเลียที่หมายถึงภาวะที่ไม่อยากทำอะไรบางอย่าง หรือไม่มีทั้ง พลังและแรงจูงใจ จะทำมัน
- เคยคิดว่าถ้าเรียนรู้ความรู้ด้านการพัฒนาให้มากขึ้นก็จะกลายเป็นโปรแกรมเมอร์ที่ดีขึ้น แต่ในความเป็นจริง นักพัฒนาที่น่าเคารพคือคนที่ไม่ได้มีแค่ความรู้ แต่ยังมี ความสม่ำเสมอและความขยัน ด้วย
- นักพัฒนาที่ดีรู้ว่าการจัดการปัญหาให้ถูกต้องตั้งแต่ตอนที่ปัญหายังเล็ก จะช่วยประหยัดเวลาในระยะยาว และลงมือทำตามนั้น
- ถ้ามี flaky test ก็จะตรวจสอบและแก้ไข
- ถ้าพบบั๊กในการใช้งานจริง ก็จะสร้าง ticket หรือแก้ทันที
- ถ้าฟีเจอร์ใหม่ไม่เข้ากับโค้ดเดิม ก็จะรีแฟกเตอร์ก่อนแทนที่จะยัดมันเข้าไปฝืน ๆ
- ถ้าจำเป็น ก็จะไล่ลงไปจนถึงชั้นล่างของสแตกเพื่อหาสาเหตุ
- นักพัฒนาแบบนี้ก็ยังแยกแยะได้ว่าเมื่อไร “good enough” คือคำตอบที่ถูกต้อง เมื่อไรควรลดขอบเขตงาน และเมื่อไรควรเรียนรู้โดเมนให้มากขึ้นก่อนค่อยเปลี่ยนสถาปัตยกรรม
- ปัญหาคือไม่ว่าการตัดสินใจเหล่านั้นจะเป็นอย่างไร ในบางจังหวะ การขาดแรงจูงใจ กลับกลายเป็นข้อจำกัดที่แรงกว่าข้อจำกัดภายนอกของโปรเจกต์เสียอีก
ซื่อตรงโดยไม่ซ่อนตัวหลังคำคม
- ระบบทดสอบ end-to-end ของ Lazygit ถูกสร้างแบบพาร์ตไทม์นานหลายเดือน หลังจากนั้นมันช่วยกัน regression ได้มาก และผู้เขียนก็มั่นใจว่าถ้ามาเพิ่มเอาตอนนี้คงยากกว่ามาก
- ถึงอย่างนั้น เหตุผลที่ยังไม่เพิ่ม end-to-end test ให้ Lazydocker ก็ง่าย ๆ แค่ว่า CBF
- หลังจากเปิด issue ในโอเพนซอร์ส repository อื่น ก็ถูกขอให้ทำ Git repository สำหรับ minimal reproduction แต่จนถึงตอนนี้ก็ยังไม่ได้ทำ และการรีแฟกเตอร์ครั้งใหญ่ที่เริ่มไว้มากกว่าหนึ่งปีก่อนก็ยังไม่เสร็จ ทำให้โค้ดยังมี God Struct อยู่มาก
- ไม่ได้สรุปชัดว่าเป็น burnout, การขาด growth mindset หรือเป็นเรื่องของนิสัยส่วนตัว
- การรู้ถึงความเจ็บปวดระยะยาวของหนี้ทางเทคนิคอาจกลายเป็นแรงผลักให้หลีกเลี่ยงมันได้ แต่ การรู้ กับการลงมือทำสิ่งที่ถูกต้องจริง ๆ นั้นไม่เหมือนกัน
- คำพูดอย่าง “ถ้ามี test เยอะเกินไป ภาระในการบำรุงรักษาก็จะเพิ่มขึ้น”, “จะดูผลกระทบจากฟีเจอร์อื่นก่อนแล้วค่อยรีแฟกเตอร์”, “premature optimisation”, “cut scope aggressively” อาจใช้เพื่อการตัดสินใจที่ดีได้ แต่ก็ใช้เป็นข้ออ้างได้เช่นกัน
- ถ้ายอมรับว่าบางส่วนของโค้ดหรือ pull request ยังไม่ดีพอเพราะความขี้เกียจ ผู้รีวิวก็จะตัดสินได้ตรง ๆ เองว่าข้อบกพร่องนั้นยังอยู่ในเกณฑ์รับได้ หรือควรเอาเวลาไปใช้กับงานถัดไปจะดีกว่า
- เมื่อเข้าสู่ภาวะ CBF แทนที่จะท้อใจ ควรซื่อตรงกับมัน และถ้าคุณเร่งเครื่องที่ระดับ 100% มานานเกินไป ก็อาจถึงเวลาต้อง พักร้อน แล้ว
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ส่วนใหญ่ของ CBF อธิบายได้ด้วยค่าตอบแทนและแรงจูงใจเพียงอย่างเดียว
ตอนที่ผมเข้าบริษัทนี้ใหม่ ๆ ยังเต็มไปด้วยพลัง แก้บิลด์ที่พัง ทำให้เทสต์ที่ถูกปล่อยทิ้งไว้ผ่าน รีแฟกเตอร์ pipeline การ deploy และตามหาสาเหตุรากของบั๊กแล้วแก้ไข
แต่พอเวลาผ่านไป คนอื่นไม่ได้เอาอย่างผม กลับกลายเป็นว่า “เดี๋ยวคนนั้นก็แก้ให้เอง” และผมก็ได้รู้ว่าถ้าทำงานจิปาถะ ก็จะมีแต่งานจิปาถะมากขึ้นกลับมา
ในทางกลับกัน คนที่ทำแบบแฮ็ก ๆ ลวก ๆ กลับห่อผลลัพธ์ออกมาให้ดูดีแล้วได้เลื่อนตำแหน่งก่อน และพอปัญหาไปปะทุในฝั่ง operations เขาก็ย้ายไปโปรเจกต์อื่นแล้ว
รุ่นน้องที่ผมช่วยอยู่สัปดาห์ละหลายชั่วโมงได้เงินมากกว่าผม เพราะถูกจ้างเข้ามาแบบเร่งด่วนในปี 2022 ส่วนผมได้รับการประเมินว่า “เกินความคาดหวัง” ในปี 2023 แต่ไม่ได้ขึ้นเงินเดือนเพราะบอกว่าเป็นช่วงเวลาที่ยากลำบาก
สุดท้ายแล้ว ในฐานะคนทำงานกินเงินเดือน ถ้าความพยายามไม่ได้รับผลตอบแทน หรือกลับกลายเป็นโทษ ก็ไม่แปลกที่แรงจูงใจจะหายไป
ออกไปหา জায়গาที่เหมาะกับตัวเองและผู้คนของตัวเองเถอะ
เมื่อได้รับการยอมรับ ต้นทุนของแรงจูงใจจะลดลงมาก และคนเราชอบรางวัล
ที่คนเล่นเกมกันเป็นพัน ๆ ชั่วโมงก็เพราะต้นทุนของแรงจูงใจต่ำมาก
ไม่ได้หมายความว่าควรทำที่ทำงานให้เป็นเกม แต่ถ้าเราปกป้องตัวเองก็จะดูจุกจิก เพื่อนร่วมงานจึงควรยอมรับกันและกัน
หนี้ทางเทคนิคก็มี อัตราดอกเบี้ย ต่างกัน และฝีมืออยู่ที่การปล่อยหนี้ 0% ไว้ แล้วไปชำระหนี้ดอกเบี้ยสูงก่อน
ตอนปูพื้นตู้เก็บของในห้องใต้ดิน วัสดุไม่พอเลยปูด้านหลังให้เสร็จสมบูรณ์ไม่ได้ หน้าตาอาจดูไม่สวย แต่ก็ถูกกล่องบังอยู่ตลอด และต่อให้อยู่ไปหลายสิบปีก็ไม่มีผลกระทบ นี่คือหนี้ทางเทคนิค 0%
ในทางกลับกัน ถ้ารางระบายน้ำอุดตัน เวลาผ่านไปค่าใช้จ่ายจะเพิ่มขึ้นจากน้ำรั่วเข้าห้องใต้ดินหรือรางระบายน้ำหลุด นั่นคือหนี้ที่มีดอกเบี้ย ขั้นบันไดหน้าบ้านที่พังจนสะดุดล้มอยู่เรื่อย ๆ ก็เป็นหนี้ดอกเบี้ยสูงที่ควรรีบแก้
ในงานวิศวกรรม ปัญหาสถาปัตยกรรมที่ทำให้การพัฒนาฟีเจอร์ทั้งหมดช้าลงอาจเป็นหนี้ดอกเบี้ยสูง ขณะที่โค้ดรก ๆ หรือ TODO ในไฟล์ที่แทบไม่แตะ อาจเป็นหนี้ดอกเบี้ยต่ำจริง ๆ
วิศวกรมักพลาดงานที่สำคัญกว่าเพราะไปแก้หนี้ 0% ในด้านหนึ่ง และอีกด้านก็พูดว่า “ผลิตภัณฑ์/ผู้นำไม่สนับสนุนการแก้หนี้ทางเทคนิค” แต่บ่อยครั้งก็อธิบายต้นทุนจริงและอัตราดอกเบี้ยให้ดีไม่ได้
ตั้งแต่บนลงล่าง ทุกคนสนใจแต่ของใหม่และแวววาว ไม่สนใจงานดูแลของที่มีอยู่
ต่อให้โน้มน้าวได้ว่ามันสำคัญ ผู้บริหารก็แค่เห็นด้วยว่างานนั้นจำเป็น แต่ ไม่มีผลเชิงบวกใด ๆ ต่อการประเมินผลงาน ถ้าผิดพลาดขึ้นมา ผมก็เป็นคนรับงานที่มีแต่โดนตำหนิ
ถ้า codebase รกและไม่สม่ำเสมอ ต่อให้เป็นไฟล์ที่ซ่อนอยู่ นักพัฒนาก็จะมีใจน้อยลงที่จะทำฟีเจอร์ใหม่ให้สอดคล้องและมีคุณภาพ
มันจะกลายเป็นว่า “ยังไงก็ต้องเขียนโมดูลนี้ใหม่ทั้งก้อนอยู่แล้ว งั้นแปะ ๆ ไว้ตรงนี้ก่อน แล้วค่อยจัดระเบียบทีหลัง”
https://en.wikipedia.org/wiki/Broken_windows_theory
เป็นการขยายคำว่า technical debt อย่างเป็นธรรมชาติ และสื่อสารแก่นของเรื่องได้กระชับ จนอยากเอาไปใช้ในบริษัทด้วย
ดังนั้นการโทษว่า “นักพัฒนาอธิบายต้นทุนจริงไม่ได้” จึงเป็นข้ออ้างที่ค่อนข้างง่าย
ถ้ามีปัญหาที่ลูกค้ามองเห็น ก็มีโอกาสได้รับการแก้ไข แต่ถ้าเป็นแค่ปัญหาภายใน โอกาสจะต่ำกว่ามาก
เวลาจะใช้คำอย่าง “หนี้ทางเทคนิค 0%” อย่างจริงจัง ก็ควรย้อนกลับมาดูว่าจับแนวคิดผิดไปหรือเปล่า
หนี้ต้องชำระคืนหรือจ่ายดอกเบี้ย แต่ถ้าไม่มีสิ่งเหล่านั้น ก็ไม่ใช่หนี้
คราวหน้าคงจะบอกว่าฟีเจอร์ที่ยังไม่ได้ implement ก็เป็นหนี้ทางเทคนิค 0% ด้วยหรือเปล่า
ผมไม่ใช่แฟน Steve Jobs แต่ชอบคำพูดของเขาเกี่ยวกับ จิตวิญญาณของช่างฝีมือ และท่าทีที่ใส่ใจรายละเอียดเสมอ
“ถ้าคุณเป็นช่างไม้ที่กำลังทำตู้ลิ้นชักสวย ๆ คุณจะไม่ใช้ไม้อัดทำด้านหลังเพียงเพราะมันหันเข้ากำแพงและไม่มีใครเห็น คุณรู้ว่ามันอยู่ตรงนั้น ดังนั้นคุณจะใช้ไม้สวย ๆ กับด้านหลังด้วย เพื่อให้นอนหลับได้อย่างสบายในตอนกลางคืน ความงามและคุณภาพต้องไปจนสุดทาง”
ผมมองว่าวงการซอฟต์แวร์โดยรวมกำลังทุกข์หนักจากท่าทีแบบ “ทำให้ตรงข้อกำหนดทางเทคนิคได้แบบเฉียด ๆ แล้ว งานของฉันก็จบ”
https://www.goodreads.com/quotes/445621-when-you-re-a-carpen...
มีเรื่องเล่ามากมายว่าเขาปฏิเสธไม่ให้เปิดตัวฮาร์ดแวร์และซอฟต์แวร์ที่ไม่ถึงมาตรฐาน และไล่คนที่ทำให้ได้ตามสเปกที่ถูกต้องไม่ได้ออก
ในทางกลับกัน คนส่วนใหญ่ทำงานภายใต้ผู้นำที่ตรงกันข้ามโดยสิ้นเชิง คือ “ทำให้เสร็จให้เร็วที่สุดเพื่อขายให้มากขึ้น และทำแค่เท่าที่จำเป็นให้ผ่านการทดสอบคุณภาพไปได้ก็พอ”
ช่างไม้จริง ๆ ต้องใช้งานได้จริงและคุ้มต้นทุนเพื่อแข่งขันในตลาด
ถ้าใช้ไม้แพง ๆ หรือใช้เวลาไปกับจุดที่ไม่มีใครเห็น ปริมาณงานที่ทำได้จะลดลง และต้นทุนของลูกค้าจะสูงขึ้นโดยไม่จำเป็น
สำหรับช่างฝีมือ เวลาและเงินก็มีจำกัดเช่นกัน และเวลาที่ใช้ไปกับงานที่มองไม่เห็นก็คือเวลาที่ไม่ได้ใช้กับงานที่เห็นชัดกว่า
ในตลาดที่ช่างไม้ฝีมือเท่ากันผลิตได้มากกว่าในต้นทุนต่ำกว่า ช่างไม้แบบนั้นย่อมถูกเบียดออกไป
ผมคิดว่าปัญหาซอฟต์แวร์เป็นเรื่อง แรงจูงใจ มากกว่าทัศนคติ ผมชอบทำงานดี ๆ และใช้ซอฟต์แวร์ที่ดี แต่เวลาในแต่ละวันมีจำกัด และผมก็ไม่ได้ถึงขั้นยอมสละเวลาส่วนตัวเพื่อผลประโยชน์ทางธุรกิจที่ผมไม่ได้รับประโยชน์เอง
แถมถ้าเริ่มรีแฟกเตอร์ ก็พอคาดเดาได้อย่างมีเหตุผลว่าวันใดวันหนึ่งจะมีฟีเจอร์จำเป็นที่ต้องทำให้เสร็จภายในวันนี้โผล่ขึ้นมา
แม้ผู้บริหารจะเห็นด้วยกับการจัดการหนี้เทคนิค สุดท้ายมันก็แก้ไม่ได้อยู่ดี เว้นแต่จะพองประมาณการเวลาให้มากขึ้น แล้วใช้เวลาที่ได้รับมอบหมายไปรีแฟกเตอร์แทนงานที่ถูกจัดให้
ในหนังสือเล่มหนึ่ง ตัวละครช่างตีเหล็กซ่อมชิ้นส่วนรถม้าแล้วพูดว่า “จงทำให้ดีที่สุดเท่าที่ทำได้เสมอ”
เมื่อมีคนบอกว่า “แต่นั่นเป็นชิ้นส่วนที่อยู่ข้างล่าง ไม่มีใครเห็นหรอก” เขาตอบว่า “แต่ฉันรู้ว่ามันอยู่ตรงนั้น ถ้าฉันไม่ทำให้ดีเท่าที่ฉันทำได้ ฉันจะอายทุกครั้งที่รถม้าคันนั้นผ่านไป และฉันจะเห็นรถม้าคันนั้นทุกวัน”
https://news.ycombinator.com/item?id=28086786
ถ้าคุณเขียนเทสต์หน่วย/เทสต์อินทิเกรชัน/เทสต์ end-to-end อย่างเหมาะสม และเมื่อเห็นโค้ดยุ่งเหยิงก็รีแฟกเตอร์แทนที่จะวางทับลงไปอีกชั้น ผลงานบนกระดาษของคุณจะดูต่ำกว่าเพื่อนร่วมงานที่คอย “ปิด” ticket ไปเรื่อย ๆ
โดยเฉพาะในองค์กร “Agile เต็มรูปแบบ” ที่ไม่คำนึงถึงการรีแฟกเตอร์หรือการจัดระเบียบคุณภาพโค้ดเลย
Apple อย่างน้อยก็เคยเป็นข้อยกเว้นอยู่ช่วงหนึ่ง ราคาสินค้าสูง ลูกค้าจึงคาดหวังคุณภาพ บริษัทมีอัตรากำไรที่ทำให้สิ่งนั้นเป็นไปได้ และเหนืออื่นใดคือมี Steve Jobs ที่มีสายตาต่อประสบการณ์ใช้งาน
อีกสุดขั้วหนึ่งก็มีกรณีอย่าง Juicero ที่สร้างเครื่องบีบซองน้ำผลไม้ด้วยวิศวกรรมระดับอากาศยาน
ตลอดช่วงส่วนใหญ่ของอาชีพ ผมจัดการหนี้เทคนิคเองเมื่อเห็นโอกาส แม้ไม่มีใครสั่ง เพราะมีความผูกพันและความรู้สึกเป็นเจ้าของ
ตอนนี้อยู่ในที่ทำงานที่ใช้ Jira ทำ ไมโครแมนเนจเมนต์ และไม่มีอิสระ ผมจึงไม่ทำอะไรนอกจากสิ่งที่จำเป็นจริง ๆ
เมื่อก่อนความพยายามโดยสมัครใจเป็นแกนหลักของอาชีพ แต่ตอนนี้การเปลี่ยนแปลงใด ๆ มีต้นทุนด้านการจัดการโปรเจกต์ทั้งเชิงราชการและเชิงสังคมสูงเกินไป จนไม่คุ้มที่จะทำ
ผมไม่สนใจว่าผลิตภัณฑ์จะไปได้ดีในระยะยาวหรือบริษัทจะสำเร็จไหม แค่ทำ ticket ไปเรื่อย ๆ จนกว่าจะหางานถัดไปได้
แต่ถ้าทำในแนวทาง “รีแฟกเตอร์ไปเลย ไม่ต้องขออนุญาต” ก็จะโดนดุว่าทำ PR ที่ไม่เป็นไปตามแพตเทิร์นเดิมของ repository
กลายเป็นว่า “ก็ดีนะ แต่ต้องคุยกับทั้งทีมก่อน”
ดังนั้นหนี้เทคนิคจึงโตต่อไป การ merge PR หนึ่งใช้เวลาหลายเดือน และเทสต์ก็ไม่เสถียรจนเหมือนตู้สล็อตคาสิโนที่ต้องกดปุ่มรีสตาร์ตไปเรื่อย ๆ จนกว่าจะ build ผ่าน Agile นี่ช่างยอดเยี่ยมจริง ๆ
จากประสบการณ์ของผม การ ลงมือเชิงรุก ในที่ทำงานที่ขยับตัวแบบตอบสนองอย่างเดียวไม่เคยได้รับรางวัลเลย
พอพบปัญหา ปัญหานั้นจะกลายเป็นปัญหาของผมทันที และถ้ามันระเบิดขึ้นมาอีกทีภายหลัง ก็จะกลายเป็นว่าผมเป็นคนทำพัง
PM และฝ่ายบริหารมักเดินด้วยสมมติฐานเชิงลบอยู่เสมอ จึงไม่คุ้มเลย
โดยเฉพาะบางคนคิดว่าตัวเองมีเส้นทางอันรู้แจ้งไปสู่โค้ดที่ดี แต่ในความจริงมักแค่เลือกทางที่ง่ายกว่าการอ่านและทำความเข้าใจโค้ดเดิม
มีความเข้าใจผิดอยู่บ้างในคอมเมนต์ที่นี่
สำหรับโปรแกรมเมอร์แต่ละคน แรงจูงใจ ความพยายาม พลังงาน หรือพลังใจ จะเรียกอะไรก็ตาม ล้วนเป็น ทรัพยากรที่มีจำกัด และนี่เป็นเรื่องปกติอย่างยิ่ง
จุดแข็งขององค์กรคือทำงานได้มากกว่าโปรแกรมเมอร์คนเดียว แต่ในกระบวนการนำองค์ประกอบหลายอย่างมาต่อกัน มันจะเกิดช่องว่าง และงานก็หลุดรอดไปตามช่องนั้น
คนที่ได้รับเงินเดือนเพื่อดูแลองค์กร ไม่ใช่งานเทคนิค เช่น COO, HR, ผู้จัดการผลิตภัณฑ์ ควรสร้างกระบวนการมาจัดการช่องว่างเหล่านั้น
แต่บริษัทจำนวนมากขึ้นเรื่อย ๆ กลับผลักงานนี้ไปให้วิศวกรและนักออกแบบรายบุคคล เพราะวัดด้วยกำไรขาดทุนหรือ OKR ได้ยาก
บริษัทก็เจ็บปวด วิศวกรก็หมดไฟ มันมีขีดจำกัดในการคอยตามเก็บ ticket และงานเล็ก ๆ ที่หลุดตามช่องว่างเหล่านี้โดยไม่มีค่าตอบแทนเพิ่มเติม
บรรยากาศเชิงลบตรงนี้แรงมากก็จริง แต่ผมดีใจที่บทความนี้อธิบายความรู้สึกในชีวิตประจำวันของผมได้ตรงเป๊ะ
เวลาผมเห็น test coverage ที่ยอดเยี่ยมกับการ refactor อย่างมีหลักการในโปรเจกต์โอเพนซอร์ส บางวันผมก็เข้าสู่โหมด “ทำให้ถูกต้อง” และทำของดี ๆ ออกมาได้เยอะ
แล้วพอวันหนึ่งพลังนั้นหายไป ผมก็กลายเป็น CBF เหมือนผู้เขียน ข้ามการทดสอบ แปะโค้ดลงในตำแหน่งที่รู้ว่าไม่ดี และปูทางที่ตัวผมในอนาคตคงไม่ขอบคุณ
ผมเห็นมันเกิดขึ้นแบบเรียลไทม์ แต่ก็ไม่มีพลังหรือแรงจูงใจจะกลับไปสู่โหมด “ทำให้ถูกต้อง” ที่มีแรงบันดาลใจอีก
เรื่องนี้เกิดขึ้นแม้กระทั่งกับซอฟต์แวร์ที่ผมสร้างและขายเองทั้งหมด
พอเห็นว่าผู้เขียนคือคนที่สร้าง Lazygit ก็ประทับใจ และผมชอบ lazygit มากจริง ๆ ในหัวผม เขาอยู่ในหมวดผู้ดูแลโอเพนซอร์สที่ทำทุกอย่างได้ถูกต้องเสมอ
ดูเหมือนว่าเราทั้งคู่จะมีประสบการณ์คล้ายกันเรื่องแรงจูงใจ
ดีใจที่คุณชอบ lazygit และหวังว่าจะรักษาความประทับใจที่ดีนี้ไว้ได้ต่อไป
การตัดสินใจส่วนใหญ่จริง ๆ แล้วเป็นเรื่อง ไร้สำนึก
ภาวะ “ทำไม่ไหวจริง ๆ” หมายความว่าวงจรบางอย่างในสมองตัดสินว่างานอย่างการ refactor หรือการทดสอบไม่คุ้มค่าพอให้ทำ
วงจรนั้นอาจถูกก็ได้ เพราะถ้ามองอย่างเป็นกลางและภาพรวม หลายครั้งผลตอบแทนเทียบกับความพยายามก็ไม่มากพอจริง ๆ
เช่น ถ้าคุณใช้เวลาสองเดือนสร้าง end-to-end test แล้วหลังจากนั้นหกเดือนมันช่วยประหยัดเวลาในการ debug และอื่น ๆ ได้สามสัปดาห์ ตัวเลขก็ไม่คุ้ม
มีสุดโต่งสองแบบที่พบบ่อย ฝั่งหนึ่งคือธุรกิจบังคับให้วิศวกรรับภาระหนี้เทคนิคที่เป็นการแลกเปลี่ยนที่แย่มากจริง ๆ อีกฝั่งหนึ่งคือวิศวกรใช้เวลากับการจัดโครงสร้างในอุดมคติและชุดทดสอบขนาดใหญ่ที่ท้ายที่สุดจะไม่ได้รับผลตอบแทน
ส่วนหนึ่งก็เพราะบางคนกังวลว่าจะมีคนเจอโครงสร้างโค้ดที่ดีกว่าหรือการทดสอบเพิ่มเติม แล้วนำมาตัดสินตัวเอง
ถ้าผมรู้สึกว่ากำลังปล่อยของที่ต่ำกว่ามาตรฐานของตัวเอง แม้มาตรฐานนั้นจะสูงกว่าความจำเป็นจริง ขวัญกำลังใจและแรงจูงใจ ก็เสียหายหนัก
ผมมองว่าปัญหาใหญ่ที่สุดของหนี้เทคนิคกลับอยู่ที่การทำลายขวัญกำลังใจนี่แหละ
ใน Lazygit ผมใช้เวลาหลายเดือนสร้างระบบ end-to-end test ไว้บางส่วน และทุกวันผมยังคิดถึง regression ที่ระบบนั้นช่วยกันไว้ รวมถึงถ้าต้องมาเพิ่มตอนนี้จะยากขึ้นแค่ไหน
ผมรู้ชัดว่ามันคุ้มค่า แต่เหตุผลที่ไม่ได้เพิ่ม end-to-end test ให้ Lazydocker ก็เพราะแค่ CBF นั่นเอง
end-to-end test ถ้าไม่มีเครื่องมือที่ดีพอ จะน่ารำคาญระดับนรกและเป็นงานมหาศาล เราต้องมีเฟรมเวิร์กพื้นฐานที่เสียบเข้าไปได้ง่ายกว่านี้
ถ้าโชคดี คนคนนั้นอาจยังมีเวลาเหลือไปดู integration test ด้วย
ผมคิดว่ามุมมองที่สังคมและโลกนี้มองว่าผู้คนขี้เกียจนั้น ส่วนใหญ่ไร้สาระมาก
ทำงานสัปดาห์ละ 40 ชั่วโมงไปหลายสิบปี แล้วค่อยได้พักหลังเกิดใหม่ แบบนี้ยังจะมาพูดเรื่องความขี้เกียจกันอีกหรือ
พลังงานทางใจถูกดูดไปสร้างความมั่งคั่งให้คนอื่น และพอแก่เกินกว่าจะทำอะไรได้ ก็ถูกทิ้ง
ทุกสัปดาห์มีฟีเจอร์ที่ควรเสร็จตั้งแต่เมื่อวานโผล่มาอีก ผมไม่รู้ว่า จะให้แก้หนี้เทคนิคตอนไหน จะให้ทำในเวลาว่างเหรอ? ตั้งแต่แรกผมยังไม่รู้เลยว่าทำไมต้องมีชีวิตอยู่ต่อไปด้วยซ้ำ
ในโปรเจกต์ที่โตเต็มที่ของทีมเล็ก ๆ ticket ที่เหลือทั้งหมดคือบั๊กยาก ๆ ที่ไม่มีใครอยากทำ
ต่อให้ลงทุนไปหลายวัน สิ่งที่แสดงให้เห็นได้ก็มีแค่ตัดรายการข้อสงสัยออกไปไม่กี่ข้อ และเป็นบั๊กประเภทที่ถ้าตัดผิดก็กลับมาอีกในสัปดาห์ถัดไป
ทุกวันต้องทุ่มพลังงานทางใจทั้งหมดลงกับ ticket แบบนั้น และพอพึ่งกาแฟหรือสารกระตุ้นจนแก้บั๊กได้ ก็ submit โค้ด ปิด ticket แล้วไป ticket ถัดไปทันที
ไม่มีการพักจริง ๆ มีแค่ช่วงต้นของ ticket ถัดไป ที่ยังไม่มีใครคาดหวังผลลัพธ์ทันที จึงได้พักสมองสั้น ๆ
แต่ผ่านไปไม่กี่วัน ผู้คนก็เริ่มถามว่าที่ผ่านมาทำอะไรอยู่ ถามว่าติดปัญหาไหม ทั้งที่จริง ๆ แทบยังไม่ได้เริ่มด้วยซ้ำ แล้วก็ต้องแต่งคำโกหกเล็ก ๆ เพื่ออธิบายว่าทำไมถึงล่าช้า
ช่วงที่ต้องพักที่สุด กลับเป็นช่วงที่ตามหลังที่สุดและคนอื่นเริ่มสังเกตแล้ว การลาพักร้อนจึงไม่รู้สึกเหมือนเป็นตัวเลือกเลย
ตอนนี้ผมทำงานให้องค์กรไม่แสวงกำไรด้านวิศวกรรม สัปดาห์ละ 20–30 ชั่วโมง บางทีก็น้อยกว่านั้น เงินตึงมือ แต่การทำงานมากกว่านี้เป็นไปไม่ได้จริง ๆ
ผมมีเวลานิดหน่อยสำหรับ side project กับปั่นจักรยาน และไม่ทำงานวันสุดสัปดาห์เด็ดขาด วันอังคารก็ไม่ทำ ยกเว้นกรณีพิเศษ
ผมรักงานปัจจุบันมากจริง ๆ และมันเป็นงานในฝัน แต่ก็ไม่คุ้มที่จะทำจนตัวเองตาย ชีวิตมีครั้งเดียว และผมจะใช้ชีวิตด้วยความรักอย่างแท้จริง
วันนี้ผมเพิ่งจบงาน 1 เดือนที่แทบจะเขียน firmware ของอุปกรณ์บริษัทใหม่เกือบทั้งหมด ทั้งที่ตอนแรกถูกประเมินเป็นงาน 1 สัปดาห์เพื่อแก้บั๊กเล็ก ๆ ในบางส่วนของโมดูลสื่อสาร
โชคดีที่มี PM และเพื่อนร่วมงานที่ใจเย็น พวกเขายอมรับว่าตอนนี้เราสามารถแก้บั๊ก legacy อายุ 8 ปีในโค้ดนั้นได้จริง ๆ แล้ว
ยังเหลือการทดสอบ edge case และการแก้เพิ่มเติม แต่ remote code update ทำงานแล้ว จึงส่งอุปกรณ์ออกได้
คำว่า “โกหก” ตรงนี้ใกล้เคียงกับคำแนะนำเชิงพฤติกรรม เดิมทีผมเริ่มคอมเมนต์ด้วยคำว่า “โกหกเถอะ” แต่มีการเข้าใจผิด
และเพื่อบอกเพื่อนร่วมงานว่าการมีเวลาคิดถึงนัยที่กว้างกว่าของงานนั้นเป็นเรื่องสำคัญ
รวมถึงเพื่อเติมความคิดของตัวเองให้กับชุมชนแบบนี้ กินช็อกโกแลต พาสุนัขไปเดินเล่นถ้าทำได้ และฟังบรรยายของ Alan Watts บน YouTube
ในฐานะคนที่พยายามทำให้ถูกต้อง ผมมองว่าสิ่งสำคัญของหนี้เทคนิคคือ การติดตาม
ปัญหาที่เห็น ใช้เวลาไม่กี่นาทีก็สร้างเป็นงานหนึ่งรายการได้ และงานนั้นก็กลายเป็นหนี้เทคนิค
leadership มีหน้าที่จัดลำดับความสำคัญของหนี้เทคนิค และค่อย ๆ ลดมันลงอย่างต่อเนื่องในปริมาณหนึ่ง
บางครั้งการตัดสินใจว่าจะไม่ทำบางอย่าง ก็เป็นการลดหนี้เทคนิคเหมือนกัน และนั่นก็โอเคอย่างสมบูรณ์
จุดประสงค์ของกระบวนการบันทึก ตรวจสอบ และจัดการ คือให้โอกาสมอง “ปัญหาที่ยังไม่ใช่ตอนนี้” เป็นครั้งที่สอง
สัญชาตญาณแรกอาจผิด และจริง ๆ แล้วไม่จำเป็นต้องมี X ก็ได้ หรือในทางกลับกัน มันอาจถูกด้วยเหตุผลที่ตอนนั้นยังนึกไม่ถึง
เหนือสิ่งอื่นใด งานบางส่วนที่บอกว่า “ตอนนี้ทำไม่ได้” นั้นสำคัญจริง ๆ ถ้าไม่สละเวลาไปดู ก็จะหาเรื่องเหล่านั้นไม่เจอ