- วิศวกรที่ยอดเยี่ยม ไม่ใช่โปรแกรมเมอร์ที่เขียนโค้ดเก่งที่สุด แต่คือ คนที่เรียนรู้วิธีรับมือกับผู้คน การเมือง การประสานงาน และความคลุมเครือรอบโค้ดได้
- เนื้อหานี้เน้นที่ แพตเทิร์นที่เกิดซ้ำในโปรเจ็กต์และทีม มากกว่าตัวเทคโนโลยี ครอบคลุมตั้งแต่การแก้ปัญหาให้ผู้ใช้ การทำงานร่วมกันในทีม คุณภาพโค้ด ไปจนถึงการวางเส้นทางอาชีพ
- ชี้ให้เห็นว่า ความชัดเจนคือคุณสมบัติหลักของวิศวกรอาวุโส และความฉลาดแพรวพราวเป็นเพียงภาระส่วนเกิน พร้อมมุมมองย้อนแย้งว่าโค้ดที่ดีที่สุดคือโค้ดที่ไม่ต้องเขียน
- ในองค์กรขนาดใหญ่ ความไม่สอดคล้องกันคือสาเหตุหลักที่ทำให้ช้าลง และเมื่อเมตริกกลายเป็นเป้าหมาย มันก็จะถูกบิดเบือน เปิดให้เห็นกับดักของการบริหารองค์กร
- ในมุมมองระยะยาว เวลาเป็นทรัพยากรที่มีค่ากว่าเงิน และเครือข่ายความสัมพันธ์อยู่ยาวนานกว่างานแต่ละแห่ง จึงต้องออกแบบเส้นทางอาชีพอย่างตั้งใจ
1. วิศวกรที่เก่งที่สุดหมกมุ่นกับการแก้ปัญหาให้ผู้ใช้
- การหลงใหลในเทคโนโลยีก่อนแล้วค่อยหาที่ใช้เป็นสิ่งที่เย้ายวน แต่วิศวกรที่สร้างคุณค่าได้มากที่สุดจะ ทำงานย้อนกลับ — เข้าใจปัญหาของผู้ใช้อย่างลึกซึ้ง แล้วค่อยสกัดทางแก้ออกมา
- การยึดผู้ใช้เป็นศูนย์กลาง หมายถึงการยอมใช้เวลากับ support ticket การคุยกับผู้ใช้ การสังเกตความลำบากของพวกเขา และคอยถามว่า “ทำไม” จนกว่าจะไปถึงรากของปัญหา
- วิศวกรที่เข้าใจปัญหาอย่างแท้จริงมักพบว่า ทางออกที่สวยงามนั้นเรียบง่ายกว่าที่คาด
- วิศวกรที่เริ่มจากโซลูชันมัก สร้างความซับซ้อนขึ้นมาเพื่อหาเหตุผลรองรับมัน
2. การถูกนั้นง่าย แต่การไปให้ถึงคำตอบที่ถูกต้องร่วมกันคืองานจริง
- คุณอาจชนะทุกข้อถกเถียงทางเทคนิคแต่แพ้ทั้งโปรเจ็กต์ และมักเห็น วิศวกรเก่งมากที่เป็นคนฉลาดที่สุดในห้องเสมอ จนสะสมแรงต้านเงียบ ๆ
- ต้นทุนจะไปโผล่ทีหลังในรูปของ “ปัญหาการลงมือทำที่อธิบายไม่ได้” และ “แรงต้านแปลก ๆ”
- ทักษะสำคัญไม่ใช่การเป็นฝ่ายถูก แต่คือ เข้าร่วมการถกเถียงเพื่อจัดแนวความเข้าใจของปัญหา เปิดพื้นที่ให้ผู้อื่น และรักษาท่าทีสงสัยต่อความเชื่อมั่นของตัวเอง
- ความเห็นหนักแน่น แต่ยึดติดน้อย — ไม่ใช่เพราะขาดความมั่นใจ แต่เพราะการตัดสินใจภายใต้ความไม่แน่นอนไม่ควรถูกผูกกับอัตลักษณ์ของเรา
3. เปิดตัวโดยมีอคติไปทางการลงมือทำ หน้าเว็บที่แย่ยังแก้ได้ แต่หน้าเปล่าแก้ไม่ได้
- การไล่หาความสมบูรณ์แบบทำให้เป็นอัมพาต และมักเห็นวิศวกรเถียงกันหลายสัปดาห์เรื่องสถาปัตยกรรมในอุดมคติของสิ่งที่ยังไม่เคยสร้างขึ้นจริง
- โซลูชันที่สมบูรณ์แบบไม่ได้เกิดจากการคิดล้วน ๆ แต่เกิดจากการปะทะกับโลกจริง และ AI ก็ช่วยได้หลายทาง
- ทำก่อน ทำให้ถูก แล้วค่อยทำให้ดีขึ้น — เอาโปรโตไทป์หน้าตาไม่สวยไปให้ผู้ใช้ลอง เขียนร่าง design doc ที่ยังรก ๆ และปล่อย MVP ที่อาจน่าเขินนิดหน่อย
- เราเรียนรู้จาก ฟีดแบ็กจริงหนึ่งสัปดาห์ มากกว่าการถกเถียงเชิงทฤษฎีหนึ่งเดือน และแรงส่งสร้างความชัดเจน ส่วน analysis paralysis ไม่ได้สร้างอะไรเลย
4. ความชัดเจนคือสัญญาณของความเป็นซีเนียร์ ส่วนความฉลาดแพรวพราวคือภาระส่วนเกิน
- สัญชาตญาณที่จะเขียนโค้ดแบบแพรวพราวแทบเป็นเรื่องสากลของวิศวกร และ ให้ความรู้สึกเหมือนเป็นการพิสูจน์ความสามารถ
- วิศวกรรมซอฟต์แวร์เกิดขึ้นเมื่อ มีเวลาและมีโปรแกรมเมอร์คนอื่นเข้ามาเกี่ยวข้อง และในสภาพแวดล้อมนั้น ความชัดเจนไม่ใช่แค่รสนิยมด้านสไตล์ แต่คือ การลดความเสี่ยงเชิงปฏิบัติการ
- โค้ดคือ บันทึกเชิงกลยุทธ์สำหรับคนแปลกหน้าที่ต้องมาดูแลมันตอนตี 2 ระหว่างเหตุขัดข้อง ดังนั้นเราต้องปรับให้เหมาะกับ ความเข้าใจของพวกเขา ไม่ใช่เพื่อความหรูหราของโค้ด
- วิศวกรอาวุโสที่ได้รับความเคารพที่สุดคือคนที่เรียนรู้จะ แลกความแพรวพราวกับความชัดเจนทุกครั้ง
5. ความใหม่คือหนี้ที่ต้องจ่ายคืนด้วย incident การจ้างคน และภาระทางความคิด
- ให้มองการเลือกเทคโนโลยีเหมือนองค์กรมีงบ “innovation token” เพียงเล็กน้อย และทุกครั้งที่รับของที่นอกมาตรฐานมาใช้จริง คุณจะใช้โทเคนไปหนึ่งอัน — ซึ่งรับได้น้อยมาก
- ประเด็นไม่ใช่ “อย่าสร้างนวัตกรรมเลย” แต่คือ “สร้างนวัตกรรมเฉพาะจุดที่คุณได้รางวัลจากการแตกต่างจริง ๆ” ส่วนที่เหลือควรให้ความธรรมดาเป็นค่าเริ่มต้น
- เพราะ ความธรรมดามีรูปแบบความล้มเหลวที่เรารู้จักอยู่แล้ว
- “เครื่องมือที่ดีที่สุดสำหรับงานนี้” มักหมายถึง “เครื่องมือที่แย่น้อยที่สุดเมื่อมองข้ามหลายงาน” เพราะการดูแลสวนสัตว์ของเครื่องมือหลายชนิดคือภาษีจริง
6. โค้ดไม่ได้พูดแทนคุณ คนต่างหากที่พูดแทน
- ช่วงต้นอาชีพเคยเชื่อว่างานที่ดีจะพูดแทนตัวมันเองได้ แต่นั่นเป็นความเข้าใจผิด เพราะโค้ดก็แค่นั่งเงียบอยู่ใน repository
- ผู้จัดการอาจพูดถึงคุณหรือไม่พูดถึงคุณในการประชุม และเพื่อนร่วมงานอาจเสนอชื่อคุณเข้าร่วมโปรเจ็กต์หรือเสนอชื่อคนอื่น
- ในองค์กรใหญ่ การตัดสินใจมักเกิดโดย คนที่มีเวลา 5 นาทีและลำดับความสำคัญ 12 อย่าง จากการประชุมที่คุณไม่ได้รับเชิญ และจากสรุปที่คุณไม่ได้เป็นคนเขียน
- ถ้าไม่มีใครอธิบายผลกระทบของคุณได้ในห้องที่คุณไม่อยู่ ผลกระทบนั้นก็แทบจะเป็นเรื่องเลือกได้ นี่ไม่ใช่การขายตัวเอง แต่คือการทำให้ ห่วงโซ่คุณค่าอ่านเข้าใจได้สำหรับทุกคน รวมถึงตัวคุณเอง
7. โค้ดที่ดีที่สุดคือโค้ดที่ไม่จำเป็นต้องเขียน
- วัฒนธรรมวิศวกรรมมักฉลองการสร้าง แต่ การลบมักทำให้ระบบดีขึ้นมากกว่าการเพิ่ม ทั้งที่ไม่มีใครได้เลื่อนตำแหน่งจากการลบโค้ด
- ทุกบรรทัดของโค้ดที่ไม่ได้เขียนคือ บรรทัดที่ไม่ต้องดีบัก ไม่ต้องบำรุงรักษา และไม่ต้องอธิบาย
- ก่อนจะสร้างอะไร ควรถามให้สุดก่อนว่า “ถ้าเรา...ไม่ทำมันเลย จะเกิดอะไรขึ้น?” — บางครั้งคำตอบคือ “ไม่มีอะไรเสียหาย” และนั่นก็คือทางออก
- ปัญหาไม่ใช่วิศวกรเขียนโค้ดไม่ได้ หรือเขียนด้วย AI ไม่ได้ แต่คือ เขียนเก่งเกินไปจนลืมถามว่าจำเป็นต้องเขียนหรือเปล่า
8. เมื่อระบบใหญ่พอ แม้แต่บั๊กก็มีผู้ใช้ที่ยึดติดกับมัน
- ถ้าผู้ใช้มีมากพอ พฤติกรรมทุกอย่างที่สังเกตได้จะกลายเป็น dependency ไม่ว่าจะตั้งใจสัญญาไว้หรือไม่ — ใครบางคนกำลัง scrape API, ทำ automation กับพฤติกรรมเฉพาะทาง หรือ cache บั๊กเอาไว้
- สิ่งนี้นำไปสู่บทเรียนระดับอาชีพว่า คุณไม่อาจมองงานด้าน compatibility ว่าเป็น “งานดูแลรักษา” และมองฟีเจอร์ใหม่ว่าเป็น “งานจริง” ได้ เพราะ compatibility ก็คือผลิตภัณฑ์
- ต้อง ออกแบบการเลิกซัพพอร์ตให้เป็นการย้ายระบบ พร้อมเวลา เครื่องมือ และความเห็นอกเห็นใจ
- งาน “ออกแบบ API” ส่วนใหญ่มักเป็นเรื่องของ “การปลดระวาง API” จริง ๆ
9. ทีมที่ “ช้า” ส่วนใหญ่ แท้จริงแล้วคือทีมที่ยังไม่จัดแนวกัน
- เมื่อโปรเจ็กต์ล่าช้า สัญชาตญาณแรกคือโทษการ execution — คนทำงานไม่หนักพอ เทคโนโลยีผิด วิศวกรไม่พอ — แต่ส่วนใหญ่ไม่ใช่ปัญหาจริง
- ในบริษัทใหญ่ ทีมคือหน่วยของการทำงานพร้อมกัน แต่ยิ่งจำนวนทีมคูณขึ้น ต้นทุนการประสานงานก็เพิ่มแบบทวีคูณ
- ความช้าส่วนใหญ่จริง ๆ คือ ความล้มเหลวในการจัดแนว — สร้างของผิด หรือสร้างของที่ถูกแต่เข้ากันไม่ได้
- วิศวกรอาวุโสจึงใช้เวลากับ การทำให้ทิศทาง อินเทอร์เฟซ และลำดับความสำคัญชัดเจน มากกว่าการ “เขียนโค้ดให้เร็วขึ้น” เพราะคอขวดจริงอยู่ตรงนั้น
10. โฟกัสกับสิ่งที่ควบคุมได้ และมองข้ามสิ่งที่ควบคุมไม่ได้
- ในองค์กรใหญ่มีตัวแปรนับไม่ถ้วนที่อยู่นอกการควบคุม — การปรับองค์กร การตัดสินใจของผู้บริหาร การเปลี่ยนแปลงของตลาด การเปลี่ยนทิศทางของผลิตภัณฑ์ — ถ้าหมกมุ่นกับสิ่งเหล่านี้จะสร้าง ความกังวลที่ไร้อำนาจลงมือทำ
- วิศวกรที่ยังมีสติและทำงานได้ผลจะ โฟกัสที่วงอิทธิพลของตัวเอง — คุณคุมไม่ได้ว่าจะมี reorg หรือไม่ แต่คุมได้ว่างานของคุณมีคุณภาพแค่ไหน คุณตอบสนองอย่างไร และคุณได้เรียนรู้อะไร
- เมื่อเจอกับความไม่แน่นอน ควร หั่นปัญหาออกเป็นชิ้นเล็ก ๆ แล้วระบุการกระทำที่เป็นรูปธรรมซึ่งตัวเองทำได้
- นี่ไม่ใช่การยอมจำนนแบบเฉยเมย แต่คือ การโฟกัสเชิงกลยุทธ์ เพราะพลังงานที่ใช้กับสิ่งที่เปลี่ยนไม่ได้ ก็คือพลังงานที่ขโมยมาจากสิ่งที่เปลี่ยนได้
11. abstraction ไม่ได้ลบความซับซ้อน มันแค่ย้ายมันไปตอนที่คุณเป็น oncall
- abstraction ทุกชั้นคือ การเดิมพันว่าคุณจะไม่จำเป็นต้องเข้าใจสิ่งที่อยู่ข้างใต้ และบางครั้งก็ชนะเดิมพันนี้
- แต่สุดท้ายอะไรบางอย่างก็จะรั่วออกมาเสมอ และเมื่อมันรั่ว คุณต้องรู้ว่า ตัวเองยืนอยู่บนอะไร
- วิศวกรอาวุโสจึงยังคงเรียนรู้สิ่ง “ระดับล่าง” ต่อไปแม้ stack จะสูงขึ้น ไม่ใช่เพราะ nostalgia แต่เพราะเคารพช่วงเวลาที่ abstraction พัง และคุณต้องอยู่กับระบบเพียงลำพังตอนตี 3
- ใช้ stack ไปเถอะ แต่ต้องมีแบบจำลองการทำงานในหัวเกี่ยวกับ failure mode พื้นฐานของมันไว้ด้วย
12. การเขียนบังคับให้ชัดเจน วิธีเรียนรู้สิ่งใดให้ดีขึ้นที่เร็วที่สุดคือพยายามสอนมัน
- การเขียนบังคับให้ชัดเจน และเมื่อคุณพยายามอธิบายแนวคิดให้คนอื่นฟัง — ไม่ว่าจะผ่านเอกสาร การนำเสนอ คอมเมนต์ใน code review หรือแม้แต่คุยกับ AI — คุณจะเจอช่องโหว่ในความเข้าใจของตัวเอง
- การทำให้บางสิ่ง อ่านเข้าใจได้สำหรับคนอื่น ก็ทำให้มัน อ่านเข้าใจได้มากขึ้นสำหรับตัวคุณเอง
- นี่ไม่ได้หมายความว่าคุณจะเรียนการเป็นศัลยแพทย์ได้จากการสอนมัน แต่สมมติฐานนี้ เป็นจริงอย่างมากในโลกวิศวกรรมซอฟต์แวร์
- มันไม่ใช่แค่ความเอื้อเฟื้อในการแบ่งปันความรู้ แต่ยังเป็น hack เพื่อการเรียนรู้แบบเห็นแก่ตัว — ถ้าคิดว่าเข้าใจอะไรดีแล้ว ลองอธิบายมันแบบสั้น ๆ จุดที่คุณติดคือจุดที่ความเข้าใจยังตื้น
- การสอนคือการดีบัก mental model ของตัวเอง
13. งานที่ทำให้งานอื่นเกิดขึ้นได้มีค่า แต่แทบมองไม่เห็น
- งาน glue อย่างเอกสาร การ onboarding การประสานงานข้ามทีม และการปรับปรุงกระบวนการ เป็นสิ่งจำเป็น แต่ถ้าทำแบบ เผลอทำไปเรื่อย ๆ มันอาจทำให้เส้นทางเทคนิคหยุดนิ่งและนำไปสู่ burnout
- กับดักคือการทำมันแบบ “ช่วย ๆ กันไป” โดยไม่จัดการให้เป็น งานที่ตั้งใจทำ มีขอบเขต และมีผลกระทบที่มองเห็นได้
- ควร จำกัดเวลา หมุนเวียนหน้าที่ และแปลงมันเป็นผลลัพธ์ เช่น เอกสาร เทมเพลต หรือ automation และทำให้มัน อ่านออกว่าเป็นผลกระทบ ไม่ใช่ลักษณะนิสัยส่วนตัว
- สิ่งที่มีค่าแต่ไร้ตัวตน เป็น ส่วนผสมที่เสี่ยงต่ออาชีพ
14. ถ้าคุณชนะทุกข้อถกเถียง คุณอาจกำลังสะสมแรงต้านเงียบ ๆ อยู่
- ได้เรียนรู้ที่จะ สงสัยในความเชื่อมั่นของตัวเอง และเมื่อ “ชนะ” ได้ง่ายเกินไป มักแปลว่ามีบางอย่างผิดปกติ
- คนที่เลิกเถียงกับคุณไม่ใช่เพราะคุณโน้มน้าวเขาได้ แต่อาจเป็นเพราะ เขายอมแพ้ และจะไปแสดงความไม่เห็นด้วยในขั้นตอนลงมือทำแทนที่จะเป็นในห้องประชุม
- การจัดแนวกันอย่างแท้จริงใช้เวลานานกว่า — ต้องเข้าใจมุมมองอื่นจริง ๆ ผสานฟีดแบ็ก และบางครั้งต้องเปลี่ยนใจต่อหน้าคนอื่นอย่างเปิดเผย
- ความรู้สึกดีระยะสั้นจากการเป็นฝ่ายถูก มีค่าน้อยกว่าความจริงระยะยาวของการได้สร้างสิ่งต่าง ๆ ร่วมกับเพื่อนร่วมงานที่เต็มใจร่วมมือ มากนัก
15. เมื่อการวัดกลายเป็นเป้าหมาย มันก็หยุดเป็นการวัด
- เมตริกทุกตัวที่เปิดให้ผู้บริหารเห็น สุดท้ายจะถูกเล่นเกม ไม่ใช่เพราะเจตนาร้าย แต่เพราะ มนุษย์ย่อม optimize สิ่งที่ถูกวัด
- ถ้าคุณติดตามจำนวนบรรทัดโค้ด คุณก็จะได้บรรทัดเพิ่มขึ้น ถ้าติดตาม velocity คุณก็จะได้ estimate ที่พองขึ้น
- วิธีคิดแบบซีเนียร์คือ ตอบทุกคำขอเรื่องเมตริกเป็นคู่ — ตัวหนึ่งสำหรับความเร็ว อีกตัวสำหรับคุณภาพหรือความเสี่ยง — แล้วผลักดันให้ ตีความแนวโน้ม แทนการบูชาค่าขีดแบ่ง
- เป้าหมายคือ อินไซต์ ไม่ใช่การสอดส่อง
16. การยอมรับว่าไม่รู้ สร้างความปลอดภัยได้มากกว่าการทำเหมือนรู้
- วิศวกรอาวุโสที่พูดว่า “ผม/ฉันไม่รู้” ไม่ได้กำลังแสดงความอ่อนแอ แต่กำลัง สร้างพื้นที่อนุญาต
- เมื่อผู้นำยอมรับความไม่แน่นอน มันส่งสัญญาณว่าคนอื่นก็ทำแบบเดียวกันได้ ทางเลือกอีกแบบคือวัฒนธรรมที่ทุกคนแกล้งทำเป็นเข้าใจ และปัญหาถูกซ่อนไว้จนระเบิด
- มักเห็นทีมที่คนซีเนียร์ที่สุดไม่ยอมรับว่าตัวเองสับสน และเห็นผลเสียของมัน — ไม่มีใครถามคำถาม สมมติฐานไม่ถูกท้าทาย และวิศวกรจูเนียร์ก็เงียบเพราะคิดว่าคนอื่นเข้าใจกันหมดแล้ว
- ถ้าคุณเป็นแบบอย่างของความอยากรู้อยากเห็น คุณจะได้ทีมที่เรียนรู้อย่างแท้จริง
17. เครือข่ายความสัมพันธ์อยู่ได้นานกว่างานทุกแห่งที่คุณจะมี
- ช่วงต้นอาชีพเคยโฟกัสแต่งานและละเลยการสร้างเครือข่าย ย้อนกลับไปมองแล้วนั่นเป็นความผิดพลาด
- เพื่อนร่วมงานที่ลงทุนกับความสัมพันธ์ — ทั้งในและนอกบริษัท — ได้รับ ผลตอบแทนยาวนานหลายสิบปี
- พวกเขาได้ยินเรื่องโอกาสก่อน สร้างสะพานเชื่อมได้เร็วกว่า ได้รับการแนะนำเข้าสู่บทบาทต่าง ๆ และร่วมก่อตั้งกิจการกับคนที่สร้างความไว้ใจกันมานานหลายปี
- งานไม่คงอยู่ตลอดไป แต่เครือข่ายความสัมพันธ์อยู่นานกว่างานแต่ละแห่ง — ควรเข้าหามันด้วยความอยากรู้อยากเห็นและความเอื้อเฟื้อ ไม่ใช่ความเร่งรีบแบบ transactional
- เมื่อถึงเวลาต้องก้าวต่อไป บ่อยครั้ง ความสัมพันธ์คือสิ่งที่เปิดประตู
18. การเพิ่มประสิทธิภาพส่วนใหญ่มาจากการตัดงานทิ้ง ไม่ใช่การเพิ่มความฉลาด
- เมื่อระบบช้าลง สัญชาตญาณแรกคือการเพิ่มบางอย่างเข้าไป — ชั้น cache, การประมวลผลแบบขนาน, อัลกอริทึมที่ฉลาดขึ้น — บางครั้งก็ถูกต้อง แต่บ่อยครั้งเห็นผลลัพธ์ที่ดีกว่าจากคำถามว่า “มีอะไรที่เราไม่ต้องคำนวณได้บ้าง?”
- การลบงานที่ไม่จำเป็น แทบจะมีผลมากกว่าการทำให้งานที่จำเป็นเร็วขึ้น และโค้ดที่เร็วที่สุดคือโค้ดที่ไม่ถูกรัน
- ก่อนจะ optimize ควร ตั้งคำถามก่อนว่างานนั้นจำเป็นต้องมีอยู่หรือไม่
19. process มีไว้เพื่อลดความไม่แน่นอน ไม่ใช่เพื่อสร้างร่องรอยเอกสาร
- process ที่ดีที่สุดทำให้การประสานงานง่ายขึ้นและทำให้ความล้มเหลวมีต้นทุนถูกลง ส่วน process ที่แย่ที่สุดคือการแสดงละครแบบราชการ — ไม่ได้มีไว้เพื่อช่วย แต่มีไว้เพื่อโยนความผิดเมื่อเกิดปัญหา
- ถ้าคุณอธิบายไม่ได้ว่า process หนึ่งลดความเสี่ยงหรือเพิ่มความชัดเจนอย่างไร มันก็ น่าจะเป็นแค่ overhead
- ถ้าคนใช้เวลาไปกับ การบันทึกงานมากกว่าการทำงานจริง แสดงว่ามีบางอย่างผิดอย่างหนัก
20. สุดท้ายเวลา จะมีค่ามากกว่าเงิน และคุณควรใช้ชีวิตให้สอดคล้องกับความจริงนั้น
- ช่วงต้นอาชีพเรามักแลกเวลาเป็นเงิน ซึ่งก็ไม่ผิด แต่ถึงจุดหนึ่ง สมการจะกลับด้าน — คุณเริ่มตระหนักว่าเวลาเป็นทรัพยากรที่สร้างใหม่ไม่ได้
- มักเห็นวิศวกรอาวุโสไล่ล่าระดับการเลื่อนตำแหน่งถัดไป optimize ค่าตอบแทนเพิ่มอีกไม่กี่เปอร์เซ็นต์ จนหมดไฟ
- บางคนได้มันมา แต่ส่วนใหญ่ภายหลังกลับตั้งคำถามว่า สิ่งที่ยอมเสียไปนั้นคุ้มจริงหรือไม่
- คำตอบไม่ใช่ “อย่าทำงานหนัก” แต่คือ “รู้ว่าคุณกำลังแลกอะไร และแลกมันอย่างตั้งใจ”
21. ไม่มีทางลัด แต่มีพลังของดอกเบี้ยทบต้น
- ความเชี่ยวชาญเกิดจาก การฝึกฝนอย่างตั้งใจ — ผลักตัวเองให้เลยจากทักษะปัจจุบันไปเล็กน้อย สะท้อนคิด แล้วทำซ้ำ — เป็นเวลาหลายปี — ไม่มีเวอร์ชันย่อ
- ส่วนที่ให้ความหวังคือ การเรียนรู้ทบต้น เมื่อมันสร้างทางเลือกใหม่ ๆ ไม่ใช่แค่ชิ้นความรู้เล็ก ๆ เพิ่มเข้ามา
- จงเขียน — ไม่ใช่เพื่อ engagement แต่เพื่อ ความชัดเจน — สร้างองค์ประกอบตั้งต้นที่นำกลับมาใช้ซ้ำได้ และเก็บ scar tissue ให้กลายเป็น playbook
- วิศวกรที่มองอาชีพเหมือนดอกเบี้ยทบต้น มักไปได้ไกลกว่าวิศวกรที่มองมันเหมือนลอตเตอรี่
ความคิดส่งท้าย
- 21 บทเรียนอาจดูเยอะ แต่สุดท้ายก็ย้อนกลับไปที่แนวคิดหลักไม่กี่ข้อ: รักษาความอยากรู้อยากเห็น รักษาความถ่อมตน และจำไว้ว่างานล้วนเกี่ยวกับผู้คนเสมอ — ทั้งผู้ใช้ที่เราสร้างให้ และเพื่อนร่วมทีมที่เราสร้างไปด้วยกัน
- เส้นทางอาชีพสายวิศวกรรม ยาวพอที่จะทำผิดพลาดได้มากมายแล้วยังไปต่อได้ และวิศวกรที่น่าเคารพที่สุดไม่ใช่คนที่ทำถูกทุกอย่าง แต่คือ คนที่เรียนรู้จากสิ่งที่ผิด แบ่งปันสิ่งที่ค้นพบ และยังคงปรากฏตัวลงมือทำต่อไป
- หากคุณยังอยู่ช่วงต้นของเส้นทาง ขอให้รู้ว่าสิ่งเหล่านี้จะยิ่งมีความหมายมากขึ้นเมื่อเวลาผ่านไป และหากคุณเดินมาไกลแล้ว ก็หวังว่าบางข้อจะสะท้อนใจคุณได้
5 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ทำให้นึกถึงคำพูดที่ว่า “พอระบบมีขนาดใหญ่ขึ้น แม้แต่บั๊กก็มีผู้ใช้ของมันเอง”
ตอนที่งานแรกของฉันลดเวลาโหลดจาก 5 นาทีเหลือ 30 วินาที ลูกค้ากลับไม่พอใจกันมาก
เพราะเวลาที่เคยเปิดคอม ทิ้งไว้ แล้วไปดื่มกาแฟคุยเล่นกันหายไป
บทเรียนจากเรื่องนี้ไม่ใช่ว่าอย่าปรับปรุงอะไรเลย แต่คืออย่าลืมว่า ซอฟต์แวร์ดำรงอยู่ท่ามกลางนิสัยและปฏิสัมพันธ์ของผู้คนจริงๆ
งานของวิศวกรไม่ใช่แค่ปิด ticket แต่คือการแก้ปัญหาของผู้ใช้จริง
ยิ่งเพิ่มประสิทธิภาพมากเท่าไร พนักงานก็ยิ่งต้องใช้ แรงงานทางกาย มากขึ้น จนเกิดความไม่พอใจแทน
สุดท้ายฉันเลยกลายเป็นคนที่ “ทำระบบดีๆ พัง” ในสายตาคนอื่น
มีประโยคหนึ่งว่า “ถ้ามีผู้ใช้มากพอ พฤติกรรมทุกอย่างของระบบที่สังเกตได้ จะมีใครสักคนพึ่งพามันอยู่”
ทุกครั้งก็คิดว่า “คราวนี้คงแก้แล้วล่ะ” แต่พอไม่ถูกแก้อยู่ 10 ปี ธุรกิจก็เลยอยู่รอดมาได้เสียอย่างนั้น
ทั้งสามฝ่ายเข้าใจปัญหาไม่เหมือนกัน
ความหมายของโค้ดไม่ได้เปลี่ยนไปตามเจตนาหรือความคาดหวัง และมันทำงานได้ภายใต้ข้อจำกัดของโลกจริงเท่านั้น
บทความที่เกี่ยวข้อง: Laws of Software Evolution
แต่ไม่ใช่ทุกบริษัทจะคิดแบบนั้น
การทำความเข้าใจ ความคาดหวังตั้งแต่ตอนสัมภาษณ์งาน จึงสำคัญมาก
พอเห็นว่าเป็นบทความของ Addy Osmani ก็รู้สึกถึง ความหน้าไหว้หลังหลอก นิดหน่อย
เขาเคยลอกโค้ดของฉันมาก่อน แล้วภายหลังก็โพสต์ คำขอโทษ แต่ไม่ได้แชร์บนโซเชียลมีเดีย
ถ้าเป็นคำขอโทษจากใจจริง ก็ควรเปิดเผยให้คนติดตามของเขาเห็นด้วย
สามข้อแรกโดนใจฉันเป็นพิเศษ
ปัญหาคือหลักสูตรการศึกษามักสอนแต่ภาษาและเฟรมเวิร์ก แต่ไม่ได้สอนตัวปัญหาเอง
ฉันทามติเกิดจากการสั่งสมในกระบวนการสร้างสรรค์ และอำนาจควรถูกใช้ในยามวิกฤต
หลายครั้งคนเรากลัวความล้มเหลวจนมัวแต่ถกเถียงและเสียเวลาไปเปล่าๆ
ฉันเพิ่งรู้จักแนวคิดเรื่อง ‘innovation tokens’ ครั้งแรกจากบทความ Boring Technology
เป็นบทความที่ boringtechnology.club และจนถึงตอนนี้ก็ยังเป็นหนึ่งในบทความด้านสถาปัตยกรรมที่ฉันชอบที่สุด
ประโยคที่ว่า “abstraction ไม่ได้กำจัดความซับซ้อน แค่มัน ย้ายมันไปไว้ตอนที่คุณเป็น on-call” ทำให้นึกถึง Law of Leaky Abstractions ของ Joel Spolsky
ตลอด 15 ปีในสายงานผู้นำ ฉันดูแลระบบมูลค่าหลายพันล้านดอลลาร์ในบริษัทค้าปลีกรายใหญ่
แต่สุดท้ายสิ่งสำคัญจริงๆ คือ การเมืองและความสัมพันธ์ระหว่างคน
คนที่ฉลาดกว่าก็ยังไม่ได้เลื่อนขั้นเพราะเล่นการเมืองไม่เป็น
จนได้ข้อสรุปอันขมขื่นว่าต้องสอนลูกๆ ให้ “เรียนรู้เรื่องการเมืองและการประจบสอพลอ”
ฉันเห็นด้วยอย่างมากกับคำว่า “Clarity is seniority”
ความชัดเจนคือหัวใจของการบำรุงรักษาและการขยายระบบ
ฉันถึงกับเขียนหนังสือ Elements of Code เพื่อสอนเรื่องนี้
abstraction ไม่ใช่สิ่งเลวร้าย ปัญหาอยู่ที่ ความชัดเจนของเป้าหมาย
มันเหมือนวิศวกรโยธาที่สร้างสะพานอยู่ในโกดังโดยไม่เคยมองภูมิประเทศจริง
สิ่งที่ควรถูกตำหนิไม่ใช่ abstraction เอง แต่คือการไม่เข้าใจว่ากำลังพยายามจำลองอะไร
abstraction ที่ผิดพลาดจะยิ่งทำลายความชัดเจน และก่อให้เกิด ความซับซ้อนที่ไม่จำเป็น
ถ้าให้เลือก ฉันว่ามี abstraction ไม่พอยังดีกว่า
คุณค่าที่แท้จริงของลิสต์แบบนี้คือการ ลองเขียนด้วยตัวเอง
แค่อ่านอย่างเดียวเดี๋ยวก็ลืม และจะมีความหมายก็ต่อเมื่อย้อนมองอาชีพของตัวเองแล้วสรุปออกมา
บทความนี้ไม่ใช่ค่านิยมอย่างเป็นทางการของ Google แต่เป็น บทเรียนส่วนตัวที่ได้จากการทำงานที่ Google
ไม่ใช่สิ่งที่องค์กรสอน แต่เป็นสิ่งที่เจ้าตัวค่อยๆ เข้าใจด้วยตัวเองจากประสบการณ์
ประเด็นสำคัญคือ แม้แต่ในองค์กรใหญ่ก็ยังเป็นเรื่องที่ยากอยู่ดี
คำพูดที่ว่า “พอระบบมีขนาดใหญ่ขึ้น แม้แต่บั๊กก็มีผู้ใช้ของมันเอง” ก็คล้ายกับปรากฏการณ์ ossification (การแข็งตัวจนเปลี่ยนแปลงยาก)
มันใช้ได้ไม่ใช่แค่กับ network protocol แต่กับทุกระบบ
เหตุผลที่ HTTP/3 และ QUIC ถูกออกแบบให้ เข้ารหัส ก็เพื่อไม่ให้อุปกรณ์กลางทางตั้งสมมติฐานผิดๆ
API ก็เช่นกัน ไม่ควรเปิดเผยสถานะภายใน
ประโยค “Bias towards action” น่าประทับใจมาก
ไม่ว่าคำแนะนำจะดีแค่ไหน มันก็ช่วยอะไร หน้ากระดาษเปล่า ไม่ได้
คุณต้องลงมือทำอะไรสักอย่างก่อน ถึงจะได้ feedback กลับมา
ทันทีที่คุณพิมพ์ตัวอักษรตัวแรก ปัญหาที่ไม่คาดคิดก็จะเริ่มโผล่ออกมา
ยิ่งองค์กรใหญ่เท่าไร คอขวดที่มองไม่เห็น แบบนี้ก็ยิ่งเยอะ
“Ship fast” ไม่ได้แปลว่า “ปล่อยของแบบลวกๆ”
ฉันกลับคิดว่า minimum viable product ที่ทำออกมาอย่างดีจะดีกว่า
ช่องว่างระหว่างอุดมคติกับความจริงนั้นใหญ่มาก และผู้เขียนก็ประชดว่า “Kool Aid มันอร่อยดี”
ไม่อย่างนั้นจะถูกมองว่า “ทำงานส่งๆ” และถ้าเกิดปัญหาขึ้นมาก็จะกลายเป็น แพะรับบาป
เป็นบทความที่ดีมากครับ แนวคิดที่ว่าการเติบโตในสายอาชีพนั้นรวมถึงการเติบโตทางวุฒิภาวะของความเป็นคนด้วย เป็นโอกาสให้ได้ทบทวนอีกครั้ง อ่านอย่างเพลิดเพลินเลยครับ
ทุกคำล้วนถูกต้องจริงๆ
บทเรียนข้อ 1 สำคัญมากจริงๆ นะครับ
ช่วงนี้กำลังรู้สึกอย่างแรงเลย 555
มีเนื้อหาดี ๆ มากมายและมีประโยคที่เปี่ยมด้วยมุมมองลึกซึ้งหลายประโยคจนผม/ฉันต้องอุทานออกมา ยิ่งชอบมากขึ้นไปอีกที่มีการทำตัวหนาประโยคสำคัญไว้
"การเป็นฝ่ายถูกในความรู้สึกระยะสั้น มีค่าน้อยกว่าความเป็นจริงระยะยาวของการร่วมกันสร้างบางสิ่งกับเพื่อนร่วมงานที่พร้อมให้ความร่วมมืออย่างเต็มใจมาก"
"ต้องมีการโฟกัสเชิงกลยุทธ์ และพลังงานที่ใช้ไปกับสิ่งที่เปลี่ยนไม่ได้ ก็คือพลังงานที่ขโมยมาจากสิ่งที่เปลี่ยนได้"
ไม่ใช่แค่เรื่องงานเท่านั้น แต่ยังมีหลายส่วนที่นำไปปรับใช้กับชีวิตได้ดีด้วย ขอบคุณสำหรับบทความดี ๆ
"โค้ดคือบันทึกเชิงกลยุทธ์สำหรับคนแปลกหน้าที่จะต้องมาดูแลรักษามันตอนตี 2 ระหว่างเหตุขัดข้อง ดังนั้นมันจึงควรถูกเขียนให้เข้าใจได้มากที่สุด"
"แรงขับเคลื่อนสร้างความชัดเจน ส่วนอัมพาตจากการวิเคราะห์ไม่ได้สร้างอะไรขึ้นมาเลย"