เขียนโปรแกรมไม่ยาก ยากคือการจัดการกับ「คน」และ「ความซับซ้อน」 วิศวกรอาวุโสของ Google แบ่งปันประสบการณ์ 14 ปี ตั้งแต่ความคิดของผู้ใช้ไปจนถึงความร่วมมือในทีม กฎทอง 21 ข้อนี้จะช่วยให้คุณสร้างเส้นทางอาชีพที่ลึกซึ้งยิ่งขึ้น
(ข้อมูลเบื้องต้น: การแปลทันทีของ Google เปิดให้ทุกแบรนด์หูฟังอย่างเป็นทางการ: รองรับมากกว่า 70 ภาษา เริ่มต้นบนสมาร์ทโฟน Android ของเม็กซิโกและอินเดีย)
(ข้อมูลเสริม: Google เปิดตัว「Gemini 3」อย่างเป็นทางการ! ขึ้นสู่จุดสูงสุดของโมเดล AI ที่ฉลาดที่สุดในโลก จุดเด่นคืออะไร?)

สารบัญบทความ

• 1. วิศวกรชั้นนำหลงใหลในการแก้ปัญหาของผู้ใช้
• 2. การ「พิสูจน์ตัวเองถูกต้อง」ไม่มีค่าอะไร รวมเป้าหมายที่ถูกต้องร่วมกันคือสิ่งสำคัญ
• 3. เน้นการลงมือทำ ไปเลย! คุณสามารถแก้ไขหน้าเว็บที่แย่ได้ แต่ไม่สามารถแก้ไขหน้าว่างเปล่าได้
• 4. ความอาวุโสสะท้อนในความชัดเจน ความฉลาดสะท้อนในภาระ
• 5. 「ความแปลกใหม่」เป็นดอกเบี้ยสูงที่ยืมมาจากการซ่อมบำรุง การรับสมัคร และภาระด้านการรับรู้
• 6. โค้ดจะไม่ส่งเสียงให้คุณ ฟังคน
• 7. โค้ดที่ดีที่สุดคือบรรทัดที่คุณไม่เคยเขียน
• 8. เมื่อขนาดใหญ่พอ แม้แต่บั๊กของคุณก็มีผู้ใช้
• 9. ทีม「ช้า」ส่วนใหญ่เป็น「ทีมที่失焦」
• 10. โฟกัสในสิ่งที่คุณควบคุม ละเว้นสิ่งที่คุณควบคุมไม่ได้
• 11. การนามธรรมไม่ได้กำจัดความซับซ้อน เพียงแต่ย้ายมันไป
• 12. การเขียนบังคับให้ชัดเจน การสอนเป็นวิธีเรียนรู้ที่เร็วที่สุด
• 13. ทำให้งานอื่นเป็นไปได้เป็นสิ่งไม่มีค่า แต่ก็เป็นสิ่งที่มองไม่เห็น
• 14. ถ้าคุณชนะทุกการโต้เถียง คุณอาจกำลังสะสมแรงต้านที่เงียบงัน
• 15. เมื่อดัชนีกลายเป็นเป้าหมาย มันก็ไม่ใช่ดัชนีที่ดีอีกต่อไป
• 16. การยอมรับว่า「ฉันไม่รู้」สร้างความปลอดภัยมากกว่าการทำเป็นรู้
• 17. บริบทของคุณยาวนานกว่าทุกงานที่คุณเคยทำ
• 18. การเพิ่มประสิทธิภาพส่วนใหญ่มาจาก「การเอางานออก」ไม่ใช่「อัลกอริทึมฉลาด」
• 19. กระบวนการมีอยู่เพื่อ ลดความไม่แน่นอน ไม่ใช่เพื่อสร้างเอกสาร
• 20. ในที่สุด เวลา จะมีค่ามากกว่าทองคำ โปรดดำเนินการตามนั้น
• 21. ไม่มีทางลัด แต่มีผลทบเชิงทบต้น

• ความคิดสุดท้าย

Addy Osmani ผู้อำนวยการด้าน AI ของ Google Cloud เป็นวิศวกรซอฟต์แวร์และนักคิดที่มีประสบการณ์ เขาเคยเป็นหัวหน้าประสบการณ์นักพัฒนาบน Chrome เกือบ 14 ปี เขามีส่วนร่วมในโครงการ DevTools, Lighthouse และ Core Web Vitals ปัจจุบัน เขารับผิดชอบประสานงานระหว่างทีม Google DeepMind, วิศวกรรม ผลิตภัณฑ์ และความสัมพันธ์กับนักพัฒนา

เมื่อวันที่ 3 เขาได้เผยแพร่บทความเชิงลึกเกี่ยวกับประสบการณ์ในที่ทำงานบนบล็อกส่วนตัวของเขา รวมประสบการณ์การทำงานและความเป็นมืออาชีพใน Google เป็นบทสรุป 21 ข้อเกี่ยวกับการสื่อสาร การเลือกเทคโนโลยี และการวางแผนอาชีพ ซึ่งทางทีมแปลได้รวบรวมไว้ดังนี้:

---

เมื่อประมาณ 14 ปีก่อน ตอนที่ผมเข้าร่วม Google ผมคิดว่างานนี้คือการเขียนโค้ดที่สมบูรณ์แบบ ผมเข้าใจแค่บางส่วน ยิ่งอยู่ไปนาน ผมก็ยิ่งตระหนักว่านักพัฒนาที่เก่งที่สุดไม่ได้เขียนโค้ดดีที่สุดเสมอไป แต่เป็นคนที่เรียนรู้「การควบคุมทุกอย่างนอกเหนือจากโค้ด」: รวมถึงความสัมพันธ์ระหว่างบุคคล การเมืองในที่ทำงาน การสร้างความเห็นร่วม และความไม่แน่นอน

ประสบการณ์เหล่านี้เป็นสิ่งที่ผมหวังว่าจะเข้าใจได้เร็วขึ้น บางอย่างช่วยให้ผมประหยัดความล้มเหลวเป็นเดือน บางอย่างใช้เวลาหลายปีถึงจะเข้าใจอย่างแท้จริง สิ่งเหล่านี้ไม่เกี่ยวกับเทคโนโลยีเฉพาะทาง: เทคโนโลยีเปลี่ยนแปลงเร็วเกินไป จึงไม่สำคัญ สิ่งเหล่านี้เกี่ยวกับกฎเกณฑ์ที่ซ้ำ ๆ ในโปรเจกต์และทีมต่าง ๆ

ผมแบ่งปันสิ่งเหล่านี้เพราะผมได้รับประโยชน์จากวิศวกรที่เต็มใจช่วยเหลือผู้อื่น นี่คือการตอบแทนเล็ก ๆ ของผม

1. วิศวกรชั้นนำหลงใหลในการแก้ปัญหาของผู้ใช้

การหลงใหลในเทคโนโลยีและการค้นหาแอปพลิเคชันเป็นสิ่งล่อใจมาก ผมเคยทำ ทุกคนก็เคยทำ แต่วิศวกรที่สร้างคุณค่ามากที่สุดคือคนที่「ย้อนกลับไปทำงาน」: พวกเขาหลงใหลในการเข้าใจปัญหาของผู้ใช้ลึกซึ้ง และปล่อยให้โซลูชันเกิดขึ้นจากความเข้าใจนั้นเอง

ความหลงใหลในผู้ใช้หมายถึงการใช้เวลาในการศึกษาตั๋วบริการลูกค้า พูดคุยกับผู้ใช้ สังเกตปัญหาการใช้งานของพวกเขา ถาม「ทำไม」ซ้ำ ๆ จนเข้าใจแก่นแท้ วิศวกรที่เข้าใจปัญหาจริงมักพบว่า โซลูชันที่ดูหรูหรามักง่ายกว่าที่คิดไว้มาก วิศวกรที่เริ่มจากโซลูชัน มักจะเพิ่มความซับซ้อนโดยไม่จำเป็นเพื่อให้สมเหตุสมผลกับแนวคิดของตนเอง

2. 「พิสูจน์ตัวเองถูกต้อง」ไม่มีค่าอะไร รวมเป้าหมายที่ถูกต้องร่วมกันคือสิ่งสำคัญ

คุณอาจชนะการโต้เถียงทางเทคนิคทุกครั้ง แต่แพ้โปรเจกต์ทั้งหมด ผมเคยเห็นวิศวกรฉลาดที่อยากเป็นคนฉลาดที่สุดในห้อง จนสะสมความไม่พอใจเงียบ ๆ ค่าใช้จ่ายนี้จะแสดงออกในภายหลังเป็น「ปัญหาการดำเนินงานลึกลับ」หรือ「แรงต้านที่ไม่เข้าใจ」

ทักษะไม่ได้อยู่ที่「ถูกต้อง」เสมอไป แต่คือการมีส่วนร่วมในสนทนาเพื่อให้เข้าใจปัญหา สร้างพื้นที่ให้ผู้อื่น และตั้งคำถามต่อความแน่นอนของตนเอง ความเชื่อมั่นในตัวเองที่แข็งแกร่ง ควรเปิดใจ — นี่ไม่ใช่เพราะคุณขาดความเชื่อมั่น แต่เพราะการตัดสินใจในสภาพไม่แน่นอน ไม่ควรผูกติดกับความภาคภูมิใจของคุณ

3. เน้นการลงมือทำ ไปเลย! คุณสามารถแก้ไขหน้าเว็บที่แย่ได้ แต่ไม่สามารถแก้ไขหน้าว่างเปล่าได้

การแสวงหาความสมบูรณ์แบบจะทำให้เกิดอัมพาต ผมเคยเห็นวิศวกรใช้เวลาหลายสัปดาห์ในการถกเถียงโครงสร้างที่ไม่เคยสร้างขึ้นจริง โซลูชันที่สมบูรณ์แบบมักไม่เกิดจากการคิดอย่างบริสุทธิ์ แต่เกิดจากการปะทะกับความเป็นจริง AI สามารถช่วยได้หลายด้าน

ทำก่อน แล้วค่อยปรับปรุงให้ดีขึ้น นำต้นแบบที่น่าเกลียดไปให้ผู้ใช้ดู เขียนร่างเอกสารออกแบบที่ยุ่งเหยิง ปล่อย MVP ที่คุณรู้สึกอายเล็กน้อย เรียนรู้จากความคิดเห็นจริงในหนึ่งสัปดาห์ มากกว่าการถกเถียงเชิงทฤษฎีเป็นเดือน แรงผลักดันนำไปสู่ความชัดเจน การวิเคราะห์ทำให้หยุดชะงักจะไม่สำเร็จ

4. ความอาวุโสสะท้อนในความชัดเจน ความฉลาดสะท้อนในภาระ

การเขียนโค้ด「ฉลาด」เป็นสิ่งที่แทบทุกวิศวกรทำได้ ซึ่งให้ความรู้สึกเป็นการพิสูจน์ความสามารถ แต่ซอฟต์แวร์วิศวกรรมคือ「เวลา」บวกกับ「ปฏิกิริยาของนักพัฒนาคนอื่น ๆ」 ในสภาพแวดล้อมนี้ ความชัดเจนไม่ใช่สไตล์ แต่เป็นการลดความเสี่ยงในการดำเนินงาน

โค้ดของคุณคือบันทึกกลยุทธ์สำหรับคนแปลกหน้าที่อาจซ่อมแซมตอนเที่ยงคืน การปรับปรุงความเข้าใจของพวกเขา ไม่ใช่ความงามของคุณ ผมชื่นชมวิศวกรอาวุโสที่เลือกใช้「ความฉลาด」เพื่อแลกกับ「ความชัดเจน」เสมอ

5. 「ความแปลกใหม่」เป็นดอกเบี้ยสูงที่ยืมมาจากการซ่อมบำรุง การรับสมัคร และภาระด้านการรับรู้

มองทางเลือกทางเทคนิคของคุณเป็น「เหรียญนวัตกรรม」ของบริษัทที่มีงบจำกัด ทุกครั้งที่คุณใช้เทคโนโลยีที่ไม่เป็นมาตรฐาน คุณใช้เหรียญหนึ่ง คุณไม่สามารถจ่ายได้มาก จุดสำคัญไม่ใช่「อย่าริเริ่มนวัตกรรมตลอดเวลา」 แต่คือ「ริเริ่มนวัตกรรมเฉพาะเมื่อได้รับผลตอบแทนที่เป็นเอกลักษณ์」

ทุกอย่างควรตั้งไว้ที่「น่าเบื่อ」เพราะความน่าเบื่อหมายถึงโมเดลความล้มเหลวที่รู้จักกันดี 「เครื่องมือที่เหมาะสมที่สุดสำหรับงานนี้」มักเป็น「เครื่องมือที่ทำงานได้ดีที่สุดในหลายงาน」 — เพราะการบริหารสวนสัตว์เทคโนโลยีจะกลายเป็นภาระที่แท้จริง

6. โค้ดจะไม่ส่งเสียงให้คุณ ฟังคน

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

ในองค์กรขนาดใหญ่ การตัดสินใจเกิดขึ้นในที่ประชุมที่คุณไม่ได้รับเชิญ โดยคนที่มีเวลาเพียงห้านาทีจัดการสิบสองความสำคัญ ถ้าเมื่อคุณไม่อยู่ ไม่มีใครพูดถึงผลกระทบของคุณ นั่นแปลว่าผลกระทบของคุณเป็นเรื่องไร้ความหมาย มันไม่ใช่แค่การขายตัวเอง แต่คือการทำให้สายโซ่คุณค่าเห็นได้ชัดสำหรับทุกคน (รวมถึงตัวคุณเอง)

7. โค้ดที่ดีที่สุดคือบรรทัดที่คุณไม่เคยเขียน

วัฒนธรรมวิศวกรรมฉลองความสร้างสรรค์ ไม่มีใครเลื่อนตำแหน่งเพราะลบโค้ด ถึงแม้การลบจะเป็นวิธีที่ดีกว่าการเพิ่มเพื่อปรับปรุงระบบ โค้ดทุกบรรทัดที่คุณไม่ได้เขียน คือโค้ดที่คุณไม่ต้องดีบัก ดูแล หรืออธิบายตลอดไป

ก่อนสร้าง ให้ถามตัวเองอย่างละเอียด:「ถ้าเราไม่ทำอะไรเลย จะเกิดอะไรขึ้น?」บางครั้งคำตอบคือ「ไม่มีอะไรเสียหาย」 นั่นคือทางออกของคุณ ปัญหาไม่ได้อยู่ที่วิศวกรไม่เก่งในการเขียนโค้ดหรือใช้ AI เขียน แต่เพราะเราทำเก่งเกินไป จนลืมถามว่า「ควรเขียนไหม」

8. เมื่อขนาดใหญ่พอ แม้แต่บั๊กของคุณก็มีผู้ใช้

เมื่อผู้ใช้มากพอ การกระทำใด ๆ ที่สามารถสังเกตได้จะกลายเป็นความขึ้นอยู่—ไม่ว่าจะเป็นสิ่งที่คุณสัญญาไว้ (กฎฮาเล็ม) มีใครกำลังดึงข้อมูล API ของคุณ อัตโนมัติฟีเจอร์แปลก ๆ ของคุณ แคชบั๊กของคุณ

นี่คือความเข้าใจระดับอาชีพ: คุณไม่สามารถมองข้ามงานความเข้ากันได้เป็น「การบำรุงรักษา」 แต่ต้องมองเป็น「ผลิตภัณฑ์เอง」 การออกแบบการเลิกใช้งาน ควรเป็นกระบวนการย้ายข้อมูลที่มีเวลา เครื่องมือ และความเข้าใจผู้อื่นเป็นส่วนประกอบ ส่วนใหญ่ของ「การออกแบบ API」จริง ๆ แล้วคือ「การเลิกใช้งาน API」

9. ทีม「ช้า」ส่วนใหญ่เป็น「ทีมที่失焦」

เมื่อโปรเจกต์หยุดชะงัก สัญชาตญาณคือโทษความสามารถในการดำเนินการ: ขาดคน เลือกเทคโนโลยีผิด ปกติแล้วนี่ไม่ใช่ปัญหาหลัก ในบริษัทใหญ่ ทีมคือหน่วยความขนานกัน แต่ต้นทุนการประสานงานเพิ่มเป็นเลขยกกำลังตามจำนวนทีม ส่วนใหญ่「ช้า」เป็นเพราะความไม่เข้าใจตรงกัน—คนสร้างสิ่งผิด หรือสร้างสิ่งที่ถูกในวิธีที่ไม่เข้ากัน วิศวกรอาวุโสมักใช้เวลามากขึ้นในการชี้แจงทิศทาง อินเทอร์เฟซ และลำดับความสำคัญ เพราะนั่นคือจุดอ่อนที่แท้จริง

10. โฟกัสในสิ่งที่คุณควบคุม ละเว้นสิ่งที่คุณควบคุมไม่ได้

ในบริษัทใหญ่ มีหลายปัจจัยที่คุณควบคุมไม่ได้—โครงสร้างองค์กร การตัดสินใจของผู้บริหาร สภาพตลาด การเปลี่ยนแปลงของผลิตภัณฑ์ การโฟกัสในสิ่งเหล่านี้จะทำให้เกิดความวิตกกังวลโดยเปล่าประโยชน์ นักพัฒนาที่มีความสามารถจะเน้นใน「วงอิทธิพล」ของตน

คุณไม่สามารถควบคุมการปรับโครงสร้างได้ แต่คุณสามารถควบคุมคุณภาพงาน การตอบสนองของคุณ และสิ่งที่คุณเรียนรู้ เมื่อเผชิญความไม่แน่นอน ให้แยกปัญหาและหาทางดำเนินการที่เป็นรูปธรรม นี่ไม่ใช่การยอมแพ้เชิงกลยุทธ์ แต่คือการโฟกัสอย่างชาญฉลาด การใช้พลังงานกับสิ่งที่ไม่สามารถเปลี่ยนแปลงได้คือการขโมยเวลาจากสิ่งที่คุณสามารถเปลี่ยนแปลงได้

11. การนามธรรมไม่ได้กำจัดความซับซ้อน เพียงแต่ย้ายมันไป

การนามธรรมแต่ละครั้งคือการพนัน—พนันว่าคุณไม่จำเป็นต้องเข้าใจพื้นฐาน บางครั้งคุณชนะ แต่ความล้มเหลวของนามธรรมมักจะรั่วไหล เมื่อมันล้มเหลว คุณต้องรู้ว่าพื้นฐานเกิดอะไรขึ้น วิศวกรอาวุโสมักเรียนรู้「พื้นฐาน」แม้ในสแต็กเทคโนโลยีที่สูงขึ้น นี่ไม่ใช่เพราะความคิดถึงอดีต แต่เป็นการเคารพในช่วงเวลาที่นามธรรมล้มเหลว ใช้เครื่องมือของคุณ แต่ต้องเข้าใจโมเดลความล้มเหลวของพื้นฐาน

12. การเขียนช่วยบังคับให้ชัดเจน การสอนเป็นวิธีเรียนรู้ที่เร็วที่สุด

การเขียนบังคับให้คุณคิด เมื่อผมอธิบายแนวคิดให้คนอื่นฟัง—ไม่ว่าจะเป็นในเอกสาร การบรรยาย การรีวิวโค้ด หรือแม้แต่คุยกับ AI—ผมจะพบว่าตนเองเข้าใจช่องว่าง

กระบวนการทำให้เนื้อหาเข้าใจง่ายสำหรับผู้อื่น ก็ทำให้มันเข้าใจง่ายขึ้นสำหรับตัวเองด้วย นี่ไม่ใช่แค่การแบ่งปันความรู้อย่างใจดี แต่เป็นเทคนิคการเรียนรู้แบบ「เห็นแก่ตัว」 ถ้าคุณคิดว่าคุณเข้าใจอะไรดีแล้ว ลองอธิบายง่าย ๆ มันซิ จุดที่คุณติดขัด คือจุดที่คุณเข้าใจไม่ลึกพอ การสอนคือการ「ดีบัก」โมเดลความคิดของคุณเอง

13. ทำให้งานอื่นเป็นไปได้เป็นสิ่งไม่มีค่า แต่ก็เป็นสิ่งที่มองไม่เห็น

「งานกาว (Glue work)」—เอกสาร การแนะนำเข้าใหม่ การประสานงานข้ามทีม การปรับปรุงกระบวนการ—สำคัญมาก แต่ถ้าคุณทำโดยไม่รู้ตัว มันจะเป็นอุปสรรคต่อการเติบโตทางเทคนิคและทำให้เหนื่อยล้า กับดักคือมองว่ามันเป็น「ความช่วยเหลือ」 แต่ควรมองเป็นการมีส่วนร่วมที่มีจิตสำนึก มีขอบเขต และมองเห็นได้ จำกัดเวลา ทำงานเป็นรอบ ๆ เปลี่ยนเป็นผลผลิต (เอกสาร เทมเพลต อัตโนมัติ)

ให้มันเป็นเครื่องมือสร้างอิทธิพล แทนที่จะเป็นบุคลิกภาพ

14. ถ้าคุณชนะการโต้เถียงทุกครั้ง คุณอาจกำลังสะสมแรงต้านที่เงียบงัน

ผมเรียนรู้ที่จะสงสัยในความแน่นอนของตัวเอง เมื่อผม「ชนะ」ได้ง่ายเกินไป มักมีอะไรผิดปกติ คนหยุดโต้เถียงไม่ใช่เพราะถูกคุณชักจูง แต่เพราะพวกเขายอมแพ้—พวกเขาจะบอกความไม่เห็นด้วยในระหว่างการดำเนินการ ไม่ใช่ในที่ประชุม การเข้าใจมุมมองของผู้อื่นอย่างแท้จริง การรับฟังความคิดเห็น และบางครั้งก็เปลี่ยนใจเปิดเผยเป็นสิ่งสำคัญที่สุด

15. เมื่อดัชนีกลายเป็นเป้าหมาย มันก็ไม่ใช่ดัชนีที่ดีอีกต่อไป

ทุกดัชนีที่คุณแสดงต่อผู้บริหารสุดท้ายจะถูก「บิดเบือน」 นี่ไม่ใช่เพราะเจตนา แต่เป็นเพราะมนุษย์จะปรับปรุงสิ่งที่วัดได้ (กฎฮาเล็ม) ถ้าคุณติดตามจำนวนบรรทัดโค้ด คุณจะได้จำนวนบรรทัดมากขึ้น ถ้าติดตามความเร็ว คุณจะได้ประมาณการที่บานปลาย

วิธีการของวิศวกรอาวุโส: สำหรับแต่ละดัชนี ให้ขอข้อมูลสองชุด ชุดหนึ่งดูความเร็ว อีกชุดดูคุณภาพหรือความเสี่ยง ยึดมั่นใน「การวิเคราะห์แนวโน้ม」 แทนที่จะบูชาเกณฑ์เป้าหมาย เป้าหมายคือความเข้าใจเชิงลึก ไม่ใช่การเฝ้าระวัง

16. การยอมรับว่า「ฉันไม่รู้」สร้างความปลอดภัยมากกว่าการทำเป็นรู้

วิศวกรอาวุโสที่พูดว่า「ฉันไม่รู้」ไม่ได้แสดงจุดอ่อน แต่เป็นการสร้าง「อนุญาต」 เมื่อผู้นำยอมรับความไม่แน่นอน มันส่งสัญญาณว่า: ห้องนี้ปลอดภัยสำหรับผู้อื่น ผมเคยเห็นทีมที่ผู้นำไม่ยอมรับความสับสน ซึ่งสร้างความเสียหายอย่างมาก: ไม่มีใครถามคำถาม ไม่มีใครท้าทาย ครีเอทีฟอายุน้อยเงียบ เพราะคิดว่าตัวเองไม่เข้าใจ แสดงความอยากรู้อยากเห็น แล้วคุณจะได้ทีมที่เรียนรู้จริง

17. บริบทของคุณยาวนานกว่าทุกงานที่คุณเคยทำ

ในช่วงเริ่มต้นอาชีพ ผมมุ่งเน้นที่งานมากกว่าความสัมพันธ์ การย้อนดูเป็นความผิดพลาดที่ผมรู้สึกได้ในภายหลัง การลงทุนในความสัมพันธ์ (ทั้งในและนอกบริษัท) เป็นสิ่งที่ให้ผลตอบแทนมหาศาลในหลายสิบปี เขาเป็นคนแรกที่ได้ยินโอกาส สร้างสะพานได้เร็วขึ้น ได้รับคำแนะนำด้านตำแหน่ง และร่วมสร้างธุรกิจร่วมกับคนที่สร้างความไว้วางใจมานาน งานไม่ใช่ตลอดไป แต่ความสัมพันธ์คือ จงสร้างความสัมพันธ์ด้วยความอยากรู้อยากเห็นและความเอื้อเฟื้อ ไม่ใช่ด้วยการแลกเปลี่ยน

18. การเพิ่มประสิทธิภาพส่วนใหญ่มาจาก「การเอางานออก」ไม่ใช่「อัลกอริทึมฉลาด」

เมื่อระบบช้าลง สัญชาตญาณคือเพิ่ม: แคช การประมวลผลแบบขนาน อัลกอริทึมที่ฉลาดขึ้น บางครั้งก็ใช่ แต่ผมเคยเห็นการปรับปรุงประสิทธิภาพมากที่สุดจากคำถามว่า:「เราได้คำนวณสิ่งที่ไม่จำเป็นออกไปบ้างไหม?」 การลบงานที่ไม่จำเป็นเกือบเสมอมีผลมากกว่าการทำงานให้เสร็จเร็วขึ้น โค้ดที่เร็วที่สุดคือโค้ดที่ไม่เคยรัน

19. กระบวนการมีอยู่เพื่อ ลดความไม่แน่นอน ไม่ใช่เพื่อสร้างเอกสาร

กระบวนการที่ดีที่สุดคือทำให้การประสานงานง่ายขึ้น ต้นทุนความล้มเหลวต่ำที่สุด กระบวนการที่แย่ที่สุดคือ「ละครบงการแบบราชการ」—มันอยู่เพื่อหลีกเลี่ยงความรับผิดชอบเมื่อเกิดปัญหา ถ้าไม่สามารถอธิบายได้ว่ากระบวนการลดความเสี่ยงหรือเพิ่มความชัดเจนอย่างไร มันอาจเป็นภาระ ถ้าคนใช้เวลาทำเอกสารมากกว่าทำงาน นั่นคือปัญหาใหญ่

20. ในที่สุด เวลา จะมีค่ามากกว่าทองคำ โปรดดำเนินการตามนั้น

ในช่วงเริ่มต้นอาชีพ คุณใช้เวลาแลกเงิน ซึ่งไม่ผิด แต่ในจุดหนึ่ง วิธีการคำนวณจะเปลี่ยน คุณจะตระหนักว่าเวลาเป็นทรัพยากรที่ไม่สามารถทดแทนได้ ผมเคยเห็นวิศวกรอาวุโสมุ่งมั่นเพื่อเลื่อนตำแหน่งและปรับปรุงเงินเดือนเล็กน้อย จนเหนื่อยล้า บางคนได้ผล แต่ส่วนใหญ่ก็สงสัยว่านี่คุ้มค่ากับสิ่งที่เสียไปหรือไม่ คำตอบคือ「ไม่ควรทำงานหนักเกินไป」แต่คือ「รู้ว่ากำลังแลกอะไร และทำอย่างมีสติ」

21. ไม่มีทางลัด แต่มีผลทบเชิงทบต้น

ความรู้เชี่ยวชาญมาจากการฝึกฝนอย่างตั้งใจ—เลิกเกินขอบเขตความสามารถของคุณ คิดสะท้อน ทำซ้ำ ๆ เป็นปี ๆ ไม่มีเวอร์ชันย่อ แต่ความหวังคือ: เมื่อการเรียนรู้สร้างทางเลือกใหม่แทนที่จะเป็นแค่ความรู้เล็กน้อย มันจะสร้างผลทบเชิงทบต้น เขียนหนังสือ (เพื่อความชัดเจน) สร้างโมดูลที่ใช้ซ้ำได้ รวบรวมบทเรียนที่เจ็บปวดเป็นคู่มือ การมองอาชีพเป็น「ผลทบเชิงทบต้น」ไม่ใช่「ลอตเตอรี่」จะทำให้คุณไปได้ไกลกว่า

---

ความคิดสุดท้าย

21 ข้อนี้ฟังดูเยอะ แต่แก่นแท้จริง ๆ มีไม่กี่ข้อ: รักษาความอยากรู้อยากเห็น ถ่อมตัว และจดจำว่างานเกี่ยวกับ「คน」เสมอ—รวมถึงผู้ใช้ที่คุณสร้างผลิตภัณฑ์ให้ และเพื่อนร่วมงานที่ร่วมสร้างด้วย

อาชีพวิศวกรยาวนานพอที่จะให้คุณทำผิดพลาดได้มากมายแล้วประสบความสำเร็จ ผมชื่นชมวิศวกรที่ไม่ใช่คนที่ไม่เคยผิด แต่คือคนที่เรียนรู้จากความผิด พูดคุยแบ่งปัน และไม่ย่อท้อ

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