สิ่งที่ผมได้เรียนรู้ตลอด 45 ปีในอุตสาหกรรมซอฟต์แวร์
(bti360.com)บทเรียนที่วิศวกรผู้ทำงานมาตลอด 45 ปี ตั้งแต่บัตรเจาะรูจนถึงคลาวด์ ทิ้งไว้ก่อนเกษียณ
1. ระวังคำสาปของความรู้
- เมื่อคุณรู้อะไรบางอย่างแล้ว คุณแทบจะจินตนาการไม่ออกเลยว่าการไม่รู้นั้นเป็นอย่างไร
- นี่คือสาเหตุของความเข้าใจผิดและความไร้ประสิทธิภาพจำนวนมาก
- คนฉลาดที่คุ้นเคยกับเรื่องซับซ้อนมักมีแนวโน้มเป็นแบบนี้มากกว่า
- หากไม่ระวังคำสาปของความรู้ ทั้งโค้ดและการสื่อสารก็จะกลายเป็นสิ่งที่เข้าใจยาก
- พยายามทำความเข้าใจผู้ฟัง และนึกย้อนว่าตอนที่เราเริ่มเรียนรู้ครั้งแรกนั้นเป็นอย่างไร
2. โฟกัสที่พื้นฐาน
เทคโนโลยีเปลี่ยนแปลงอยู่ตลอด แต่พื้นฐานของการพัฒนาซอฟต์แวร์อยู่เหนือกระแสเหล่านี้
พื้นฐานหกข้อที่ใช้ได้ยาวนาน
→ การทำงานเป็นทีม : ทีมที่ยอดเยี่ยมสร้างซอฟต์แวร์ที่ยอดเยี่ยม อย่ามองว่าการทำงานเป็นทีมเป็นเรื่องที่มีอยู่แล้วโดยธรรมชาติ
→ ความไว้วางใจ : ทีมเคลื่อนที่ด้วยความเร็วของความไว้วางใจ จงเป็นคนที่น่าเชื่อถือและคนอื่นอยากร่วมงานด้วย
→ การสื่อสาร : สื่อสารอย่างซื่อสัตย์และเชิงรุก ระวังคำสาปของความรู้
→ การแสวงหาฉันทามติ : ใช้เวลาร่วมกันทั้งทีม ค้นหาทางออกที่ดีที่สุดผ่านการอภิปรายและความเห็นต่าง
→ การทำ test automation : โค้ดที่ผ่านการทดสอบอย่างดีทำให้ทีมเดินหน้าได้อย่างรวดเร็วและมั่นใจ
→ โค้ดและการออกแบบที่สะอาด เข้าใจง่าย และสำรวจได้ง่าย : มองว่าวิศวกรคนถัดไปที่จะรับช่วงต่อโค้ดของคุณคือลูกค้า เขียนโค้ดที่ผู้สืบทอดสามารถอ่านและบำรุงรักษาได้โดยไม่มีปัญหา
3. ความเรียบง่าย
- การต่อสู้กับความซับซ้อนเป็นเรื่องที่ไม่มีวันจบ
- ทางแก้ควรเรียบง่ายที่สุดเท่าที่จะเป็นไปได้
- จงสมมติว่าคนถัดไปที่ต้องมาดูแลโค้ดของผมอาจไม่ได้ฉลาดเท่าผม
- ถ้าทำได้ด้วยเทคโนโลยีน้อยกว่า ก็จงทำแบบนั้น
"สำหรับนักออกแบบ ความสมบูรณ์แบบไม่ใช่ตอนที่ไม่มีอะไรให้เพิ่มอีก แต่คือตอนที่ไม่มีอะไรให้เอาออกอีก" - แซงเต็กซูเปรี
4. ทำความเข้าใจก่อน
- หนึ่งใน 7 อุปนิสัยของสตีเฟน โควีย์ คือ "จงพยายามเข้าใจก่อน แล้วจึงพยายามให้คนอื่นเข้าใจ"
→ คำพูดนี้ช่วยให้ผมเป็นผู้ฟังและเพื่อนร่วมทีมที่ดีขึ้นมากกว่าคำแนะนำอื่นใด - หากคุณต้องการมีอิทธิพลต่อผู้อื่นและร่วมมือกันอย่างมีประสิทธิภาพ คุณต้องเข้าใจพวกเขาก่อน
- ก่อนจะบอกความคิดของตัวเอง จงตั้งใจฟังเพื่อเข้าใจความรู้สึก ไอเดีย และมุมมองของพวกเขาอย่างแท้จริง
5. ระวัง Lock-in
- จะมีเครื่องมือเพิ่มผลิตภาพรุ่นถัดไปที่อ้างว่าจะปฏิวัติวิธีสร้างซอฟต์แวร์อยู่เสมอ
→ CASE, COTS, ERP, Ruby เป็นต้น - พวกเขามักอ้างว่าหากรับเอาปรัชญาการพัฒนาของตนไปใช้ทั้งหมด จะช่วยประหยัดต้นทุนและเวลาได้ แต่ค่าใช้จ่ายล่วงหน้าหรือข้อจำกัดที่ตามมามักไม่ชัดเจน
- Lock-in เคยเกิดขึ้นกับผู้ขายซอฟต์แวร์เป็นหลัก แต่ทุกวันนี้เกิดกับ framework ต่างๆ ด้วย
- Lock-in ทำให้การเปลี่ยนแปลงมีต้นทุนสูงมาก
- จงเลือกอย่างรอบคอบ ของใหม่ไม่ได้ดีกว่าเสมอไป
6. ซื่อสัตย์ และยอมรับเมื่อบทบาทนั้นไม่เหมาะกับคุณ
- ในช่วงใดช่วงหนึ่งของอาชีพ คุณอาจได้รับบทบาทที่ไม่เหมาะกับตัวเอง
- ความไม่เหมาะสมไม่ได้เป็นข้อบกพร่องของนิสัย แต่เป็นปัญหาที่ไม่ควรมองข้าม
- ทางออกของภาวะกลืนไม่เข้าคายไม่ออกนี้อาจมีได้มากกว่าหนึ่งทาง
→ คุณเปลี่ยนแปลงตัวเอง หรือ
→ บทบาทนั้นเปลี่ยนแปลง - สิ่งสำคัญคือการมีความรู้จักตนเองว่า "กำลังเกิดอะไรขึ้น และต้องทำอย่างไรจึงจะก้าวผ่านจากตรงนี้ไปได้"
7 ความคิดเห็น
ก่อนหน้านี้ก็มีคำแนะนำดี ๆ โพสต์ขึ้นมาเยอะแล้วนะครับ แต่ถ้าจะขอเพิ่มอีกสักชิ้น ผมอยากแนบบทความนี้ไว้ต่อท้ายครับ
https://th.news.hada.io/topic?id=2060
แน่นอนว่าบทความนี้ก็ดีมาก ๆ เช่นกัน แต่บทความด้านบนดูเหมือนจะเป็นคำแนะนำที่ชวนให้ย้อนกลับมาทบทวนได้ในมุมที่ครอบคลุมกว่าหน่อย (ไม่จำกัดอยู่แค่ซอฟต์แวร์) ถ้ารวบรวมอะไรแบบนี้ไว้แล้วหยิบกลับมาอ่านได้ทุกครั้งที่ต้องการก็คงดีมาก..
ว้าว~ เป็นคำพูดที่เต็มไปด้วยมุมมองลึกซึ้งเกี่ยวกับเทคโนโลยีและผู้คนเลยนะครับ/ค่ะ ยอดเยี่ยมมาก~!
ทำให้นึกถึงคำพูดของรุ่นพี่ที่ว่า สุดท้ายแล้วงานก็เป็นสิ่งที่คนทำ ไม่ใช่คอมพิวเตอร์
ขอบคุณสำหรับบทความดีๆ ครับ
ในฐานะมือใหม่ จะจดจำคำแนะนำนี้ไว้ครับ!
ขอบคุณที่แชร์บทความดี ๆ ครับ มีหลายประเด็นที่ต้องค่อย ๆ อ่านและนำไปขบคิดต่อเลยครับ
ว้าว เนื้อหาดีมากเลย... ขอบคุณครับ
ขอบคุณสำหรับบทความดี ๆ มากครับ!!