(อันนี้อยากแชร์ เพราะจริงๆ ผมว่า Software engineer หลายคนมากที่อึดอัดหรือโมโหกับสิ่งที่เกิดขึ้นในฟิลด์เราหลายๆ เรื่อง เลยมักจะยกว่างานฟิลด์อื่นเขาละเอียดกว่าดีกว่า ซึ่งหลายๆ ครั้งมันเวอร์เกินจริงไปเยอะ หลายๆ คนฝันว่าโลกจริงจะมีงาน Engineer ที่ Very predictable ซึ่งมัน ไม่ใช่ เดี๋ยวผมเสริมความเห็นส่วนตัวทีหลัง)
มันมีคนนึงที่เขาไปทำการสำรวจว่า Traditional Engineering กับ Software Engineering ต่างกันยังไงผ่านการสัมภาษณ์คนที่ย้ายสายงานมาจาก Engineering field อื่นๆ มาทำซอฟต์แวร์
สรุปสั้นๆ คือ Software engineer มักจะ Romanticized งานของ Engineer ทั่วไปเยอะเกินไปมากครับ
ส่วนที่ Software Engineer ควรจะเรียนรู้และพัฒนาจากงาน Engineer สายอื่นได้มีครับ แต่ไม่เยอะเท่าที่หลายๆ คนมองหรือเคลม โดยเฉพาะที่ชาว Software Engineer มองครับ คนที่ย้ายสายจาก Engineer อื่นมาชื่นชม Software Engineering field หลายเรื่องเลยทีเดียว
ลองอ่าน Blog นี้ดู เป็นตอนที่สองของ บทความ The crossover project
https://www.hillelwayne.com/post/we-are-not-special/
อันนึงที่เป็นตัวอย่างง่ายๆ ในบทความเลยคือ ในสายอื่นเวลาเขาคำนวนเขามักจะใช้ Excel share กัน ดังนั้นไม่ต้องพูดถึงเรื่อง Rigourous ในการทำ Version control and change control เราทำได้ดีกว่าเขาหลายเท่า
(คหสต. นี่อาจจะเป็นส่วนนึงทำให้เราสามารถ Change ได้บ่อยกว่าสายอื่นหรือเปล่านะ เลยทำให้ Perception ว่าคนอื่นเขามี Process ชัดเจนมากเลยนะในการแก้อะไรซักอย่าง อาจจะเพราะ Tracking system เขาไม่ดีเท่าไหร่)
หรืออีกอันนึง
One time Carl’s team had to install a screw conveyor in an oil rig, then discovered it was just a couple inches too tall for the room. They couldn’t shrink the equipment, and they couldn’t raise the ceiling, since there were another four floors above it. The team’s solution? Cut a hole in the ceiling, put the equipment in, then put a box around the hole on the next floor so that nobody trips over it. Now that change is permanently part of the rig’s structure, something that has to be accommodated in every future change forever. And that leads to another difference: software engineers can undo their kludges. Trad engineers cannot.
--------------------------------
"Software is More Unpredictable”
*Laughter* -Dawn, Matt, Steve, Mike, Mat, Another Matt
จากที่ผมอ่านบทความนี้มานาน ผมพอสรุปได้ว่าจริงๆ ทุกงาน Engineering มันจะมีส่วนที่เละเทะกับส่วนที่ Rigorous หมดครับ อย่างแบบไอ้ที่ Carl เขาต้องตัดหลุมเพื่อทำ Shortcut ในการสำรวจ ก็คือมันส่วนที่คนในฟิลด์รู้อยู่แล้วว่ามันไม่ได้กระทบ Fundamental จนน่าเกลียด พวกนี้ก็จะเละๆ หน่อย
หรือคนที่ทำ Electrical engineering ก็มีการทำแบบ Spike บนเซอร์กิตเล็กๆ อย่าง Trial and error เพื่อออกแบบ Prototype ก่อน แล้วค่อยมาคำนวนเรื่องสเกล แต่ไอ้เวลาทำ Trial and Error ตอน Prototype เงี้ย บางคนก็ทำเละพอๆ กับที่เราทำเขียนโค้ดลองรันแล้วดูว่าเป็นยังไงนั่นแหละ แล้วมันค่อยมา Rigourous ตอน Prove ว่าสเกลต้นทุนสเกลสิ่งนี้ได้
ถ้ากลับมาฟิลด์ Software Engineering ก็มีส่วนที่ Rigourous มากๆ เหมือนกัน มากจนเรา Take for grant ไปแล้ว อย่างเช่น
- ไม่มีใครบ้าคุยกันบน Network outside of TCP/IP Protocol แล้วซึ่งอันนี้ Proof หนักมาก
- Hashing & Crytographic ก็พิสูจน์กันมาหนักแล้วก็ยังมีการเจาะกันต่อไป จนเราได้ Library สำเร็จรูปที่ใช้ได้ด้วยโค้ดสองสามบรรทัด จริงๆ ภายใต้นั้นมันมี Math ที่ Rigourous มาก
- Hardware driver ที่ใช้คุยกันตั้งแต่ 32-bit, 64-bit ไปจนถึง Apple อันใหม่ นี่ก็ Rigourous มากๆ
สิ่งที่เราโชคดีกว่าคนอื่นคือพอเราทำอะไรที่ Rigourous เสร็จพิสูจน์เสร็จ มันออกมาเป็นสูตรสำเร็จรูปที่ใช้ได้เลย เราสามารถทำ Abstraction ทิ้งได้ ทำให้ในฐานะคนทำงานเราไม่ต้องคิดซ้ำไปซ้ำมาเรื่องเดิมมาก เราเลยได้โฟกัสในส่วนที่ "เละเทะ" ของงาน Engineering ได้เยอะครับ