2 คะแนน โดย GN⁺ 2023-12-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

สัมภาษณ์แม่ของผมผู้เป็นโปรแกรมเมอร์ COBOL บนเมนเฟรม

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

ปี 1991

  • แม่เริ่มการฝึกอบรมภายในที่ Nordbanken (ปัจจุบันคือ Nordea)
  • เธอทำแบบทดสอบหลายอย่างและผ่านทั้งการทดสอบ IQ การทดสอบทางจิตวิทยา และการทดสอบการทำงานหลายอย่างพร้อมกัน
  • เธอเริ่มต้นในฐานะโปรแกรมเมอร์ IBM mainframe COBOL และ 25 ปีต่อมาก็ยังทำงานตำแหน่งเดิมในธนาคารเดิม

COBOL

  • COBOL ไม่ใช่ภาษาการเขียนโปรแกรมเท่ ๆ อย่าง Haskell เชิงฟังก์ชันหรือ Golang ที่เด่นเรื่อง concurrency
  • COBOL เป็นภาษาสั่งงานแบบ imperative และ procedural และรองรับเชิงวัตถุตั้งแต่ปี 2002
  • ในบริบทของการเขียนโปรแกรมบนเมนเฟรม แทบไม่มีใครที่รู้ COBOL

ฐานข้อมูล

  • ฐานข้อมูลหลักชื่อว่า IMS ซึ่งเป็นฐานข้อมูลแบบลำดับชั้นที่ IBM สร้างขึ้นสำหรับโครงการ Apollo
  • กำลังพยายามย้ายไป DB2 แต่เป็นงานที่จะใช้เวลาหลายปี
  • ปัจจุบันฐานข้อมูล DB2 เก็บข้อมูลอยู่ราว 10TB

แบตช์

  • ประมาณ 80% ของระบบประกอบด้วยงานแบตช์
  • งานแบตช์จะรันตามเวลาหรือช่วงเวลาที่กำหนด เพื่อประมวลผลข้อมูลหรือส่งข้อมูลไปยังธนาคาร/หน่วยงานอื่น

ปัญหาที่ธนาคารกำลังเผชิญ

  • ธนาคารที่ใช้เมนเฟรมมีปัญหามากมายที่ต้องจัดการ
  • โปรแกรมเมอร์กำลังมีอายุมากขึ้น และพนักงานใหม่ต้องใช้เวลา 2-3 ปีกว่าจะทำงานได้อย่างอิสระ
  • มีโปรแกรมอายุหลายสิบปีจำนวนมาก และไม่มีใครรู้ว่ามันทำอะไร

คำส่งท้าย

  • น่าสนใจมากว่าในอีกไม่กี่ปีข้างหน้า Nordea และธนาคารอื่น ๆ จะนำเทคโนโลยีใหม่อะไรมาใช้

Q & A

  • ทำไมถึงเลือกทำงานด้าน IBM mainframe COBOL programming? เพราะอยากทำงานกับคอมพิวเตอร์
  • เรื่องที่แย่ที่สุดระหว่างวันคืออะไร? เพื่อนร่วมงานลืมใส่จุดในโมดูลระบบสำคัญ ทำให้ธนาคารล่มนาน 16 ชั่วโมง
  • อนาคตของธนาคารจะเป็นอย่างไร? พวกเขาตระหนักว่าจำเป็นต้องแทนที่เมนเฟรมด้วยสิ่งที่ทันสมัยกว่า
  • ในฐานะโปรแกรมเมอร์ผู้หญิงในยุค 90 ต้องเผชิญความท้าทายอะไรบ้าง? ไม่มีปัญหา
  • การทำงานกับโค้ดเบสเดิมมานานกว่า 20 ปีน่าเบื่อไหม? การสร้างระบบใหม่สนุกเสมอ
  • การเขียนโค้ดให้ธนาคารน่ากลัวไหม? น่ากลัวมาก แต่สภาพแวดล้อมการทดสอบแข็งแรงดี จึงมักเป็นไปอย่างราบรื่น
  • เคยทำพลาดครั้งใหญ่กับระบบธนาคารไหม? ในปี 1997 เธอเคยทำผิดพลาดจนทำให้สามารถถอนเงินจากบัญชีออมเพื่อการเกษียณได้อย่างผิดกฎหมาย
  • สภาพแวดล้อมการทำงานเป็นอย่างไร? จากโต๊ะทำงานส่วนตัวเปลี่ยนเป็นพื้นที่เปิด ซึ่งเธอไม่ชอบมาก

ความเห็นของ GN⁺

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

1 ความคิดเห็น

 
GN⁺ 2023-12-15
ความคิดเห็นบน Hacker News
  • โพสต์ต้นฉบับบน HN เมื่อปี 2016 คือ https://news.ycombinator.com/item?id=12096250
    ถ้ากำลังมองหาอะไรอ่านเพิ่มเติมในหัวข้อ “โลกของการเขียนโปรแกรมธนาคารเป็นคนละโลกกับสิ่งที่พวกเราส่วนใหญ่คุ้นเคยโดยสิ้นเชิง” An oral history of Bank Python ก็เป็นตัวเลือกที่ดี: https://calpaterson.com/bank-python.html
    เคยขึ้น HN มาก่อนด้วย: https://news.ycombinator.com/item?id=29104047

    • ไม่น่าเชื่อว่าเรื่องนั้นผ่านมา 7 ปีแล้ว ตอนนั้นตั้งใจจะสัมภาษณ์แม่เกี่ยวกับเรื่องที่ท่านเคยเขียนโปรแกรมเมนเฟรมด้วย Michigan Algorithm Decoder แต่สุดท้ายก็ไม่ได้ทำ
      https://news.ycombinator.com/item?id=12097032
  • ผู้คนมักคิดกันว่า “ถ้าเป็นโปรแกรมเมอร์เมนเฟรมวัย 20 ปี อายุจะมีมูลค่าสูงมาก จึงน่าจะได้เงินเดือนสูง” แต่ความจริงมักอยู่แค่ระดับเฉลี่ย หรือแม้แต่ต่ำกว่าค่าเฉลี่ยด้วยซ้ำ จึงเกิด ปัญหาท่อส่งคนเก่ง
    สิ่งที่มีคุณค่าจริง ๆ ไม่ใช่ทักษะอย่าง “รู้ COBOL” แต่เป็นความรู้ขององค์กรเกี่ยวกับ ตรรกะทางธุรกิจ มหาศาลที่สะสมอยู่ใน COBOL ต่างหาก นักพัฒนาทั่วไปก็เรียน COBOL ได้ แต่โปรแกรมเมอร์ COBOL ที่เกษียณแล้วกลับมาด้วยสัญญาปีละ 500,000 ดอลลาร์ ไม่ใช่เพราะ COBOL แต่เพราะความรู้เชิงสถาบันที่สั่งสมมา
    ถ้าธนาคารและสถาบันต่าง ๆ จ่ายเงินก้อนโตให้โปรแกรมเมอร์เมนเฟรมรุ่นใหม่จริง ๆ ปัญหาโครงสร้างประชากรแบบตอนนี้ก็คงไม่รุนแรงเท่านี้

    • ตอนเรียนบัณฑิตวิทยาลัยเคยเจอคนที่อยู่ในสถานการณ์แบบนั้น เขาทำงานธนาคาร แล้วถูกเลิกจ้างช่วงวิกฤตการเงิน และธนาคารก็พยายามย้ายระบบเดิมไปเป็นอะไรอย่าง Java
      พวกเขามองว่าโปรเจกต์ใกล้เสร็จแล้ว และเห็นว่าทีมเขียนใหม่คุ้นเคยกับ COBOL พอแล้ว ที่เหลือน่าจะทำต่อได้โดยไม่มีเขา แต่ในความเป็นจริง แม้จะเข้าใจ COBOL แล้ว ก็ยังต้องการ ความรู้เชิงสถาบัน ของเขาอย่างยิ่ง สุดท้ายเขากลับไปทำพาร์ตไทม์ด้วยเรตที่ปรึกษาสูงลิ่วจนกว่าการย้ายระบบจะเสร็จ ระหว่างนั้นก็เรียนบัณฑิตวิทยาลัยควบคู่ไปด้วยเพื่อเพิ่มความสามารถ
    • เคยดูแล ระบบแกนหลัก COBOL ในบริษัทประกันรายใหญ่ เห็นด้วยอย่างยิ่ง สิ่งที่บริษัทจ่ายเงินให้ไม่ใช่ความรู้ COBOL โดยตรง แต่เป็นคนที่รู้จุดแปลก ๆ และกับดักที่ไม่มีเอกสารอยู่ในโค้ด
      โปรแกรมเมอร์ที่พอใช้ได้ย่อมอ่านและไล่ตามโปรแกรม COBOL ได้ แต่จะไม่รู้ว่าทำไมงานส่งออกสำคัญระหว่างดึงข้อมูลสำหรับยื่นแบบ 10-K ถึงล่ม ที่แท้เป็นเพราะมีคนเคยคิดว่าจำนวนเรคอร์ดบางประเภทจะไม่มีทางเกิน 3000 แล้วฮาร์ดโค้ดให้เกิดข้อผิดพลาดทันทีเมื่อเกินค่านั้น
    • ตอนเริ่มทำงาน เคยทำงานเมนเฟรมสายธนาคาร/ประกัน สภาพแวดล้อมการทำงานค่อนข้างแย่ ตั้งแต่เรื่องเล็ก ๆ อย่างกฎการแต่งกาย ไปจนถึงเรื่องยากเข้าใจอย่างโค้ดเบสเลกาซีที่เก่าอย่างน่าสยดสยอง ถ้าเงินดีคงทนได้ แต่มันก็ไม่ได้ดี
      จริง ๆ แล้วได้ค่าตอบแทนน้อยกว่างานเก่ามาก ซึ่งเป็นงานติดตั้งโครงสร้างสายเคเบิลจริง ๆ คือวางไฟเบอร์ออปติกกับอีเทอร์เน็ตทองแดง และเหตุผลที่เลือกงานนี้ก็แค่เพราะในออฟฟิศมีแอร์เท่านั้นเอง ไม่ใช่งานที่อยากใช้เป็นเส้นทางอาชีพ
      ตอนทำงานเป็นผู้ดูแลระบบ Windows ระดับกลางที่คอยรับสายซัพพอร์ตลูกค้าให้ผู้ให้บริการคลาวด์ ผมได้เงินมากกว่าตอนเป็นเจ้าหน้าที่เมนเฟรมจูเนียร์ของธนาคาร/ประกันเกือบ 30% ทั้งที่เป็นทักษะหายากและอยู่ในอุตสาหกรรมมูลค่าสูง แต่งานเมนเฟรมกลับได้ค่าตอบแทนต่ำกว่ามาก และในบริษัทนั้นนักพัฒนาเมนเฟรมได้รับค่าตอบแทนต่ำที่สุดในบรรดานักพัฒนาทุกระดับประสบการณ์ คนเดียวที่ได้ค่าตอบแทนสมเหตุสมผลคือผู้รับเหมาอิสระที่เคยทำงานมา 30 ปีก่อนเกษียณ
    • ผมมีประสบการณ์ COBOL เคยทำบนเมนเฟรมด้วย และยังยินดีกลับไปทำอีก ตามมาตรฐานโปรแกรมเมอร์ COBOL ผมยังถือว่าอายุน้อย จึงอาจมีคนใช้ประโยชน์จากผมต่อได้อีก 20 ปี
      แต่ค่าจ้างของบทบาทแบบนั้นย่ำแย่เมื่อเทียบกับสิ่งที่หาได้จากเทคโนโลยีอื่น ๆ และชีวิตยุคใหม่ก็ผลักดันให้ต้องไล่ตามเงินเดือนที่สูงกว่าอย่างหนัก
    • มีกรณีแบบนั้นจริง ๆ ผมเคยทำงานที่ธนาคารข้ามชาติซึ่งมีสำนักงานใหญ่ในสหรัฐฯ ทีมสำนักงานใหญ่ทำโปรแกรมหรูหราเพื่อดึงบัณฑิตวิทยาการคอมพิวเตอร์จบใหม่เข้ามา
      โปรแกรมนี้เสนอค่าตลาดที่ “ยุติธรรม” สำหรับตำแหน่งเริ่มต้นในอุตสาหกรรม และให้ได้สัมผัส 2–3 ทีมหรือแผนกในปีแรก เมื่อจบโปรแกรม ถ้าบริษัทยังชอบคุณ ผู้สมัครก็เลือกทีมที่จะเข้าทำงานประจำได้ แต่ไม่มีการขึ้นเงินเดือน และ ณ จุดนั้น คนที่สร้างผลงานได้ไม่เร็วก็ถูกคัดออกไปแล้ว
      จากมุมมองบริษัท ผลลัพธ์ยอดเยี่ยมมาก พวกเขาได้โปรแกรมเมอร์รุ่นใหม่ที่ชำนาญ COBOL มากกว่าเพื่อนร่วมงานใหม่ ๆ ในราคา 60,000–70,000 ดอลลาร์ ต่อปี ขณะที่เพื่อนร่วมงานระดับซีเนียร์หรืออยู่มานานบางรายได้ 200,000–400,000 ดอลลาร์
  • คุณยายของผมเขียนโปรแกรมด้วยบัตรเจาะรู แต่ไม่รู้ว่าเป็นฮาร์ดแวร์อะไร และตอนนี้ก็สายเกินกว่าจะถามแล้ว พ่อของผมทำ Fortran และ COBOL เยอะมากบนเมนเฟรมโซเวียต และต่อมาก็ทำงาน Y2K มากมายในสหรัฐฯ
    ของที่เจ๋งที่สุดชิ้นหนึ่งคือกระดาษพิมพ์โปรแกรม Fortran ที่พ่อฉีกเป็นสามส่วนเพื่อห่อฟิล์มขนาดใหญ่ 64 มม. ของภาพภูเขาที่ท่านเคยถ่ายไว้ น่าจะออกมาจาก เมนเฟรม Minsk-32 โปรแกรมชื่อ MATR1 ทำงานเกี่ยวกับการจัดการเมทริกซ์ และในคอมเมนต์มีการกล่าวถึงภูมิประเทศ ตอนนี้ผมใส่กรอบแขวนไว้บนผนังใกล้โต๊ะทำงาน
    ผมเองก็เขียนโค้ดหลายภาษามาทั้งชีวิต และตอนนี้ลูกวัยรุ่นก็เริ่มสนใจการเขียนโค้ด โดยเรียน Java กับ Python ที่โรงเรียนมัธยม มุ่งสู่การเป็น โปรแกรมเมอร์รุ่นที่ 4

    • ฟังเหมือนไอเดียหนังที่โค้ดเบสเดียวกันถูกส่งต่อข้ามรุ่น ชื่อเรื่องว่า Legacy Code น่าจะเหมาะ
  • หากมองจากมุมเทคโนโลยีแล้ว คำกล่าวที่ว่านี่คือจุดสำคัญที่สุดของธนาคารเป็นเรื่องจริง เมื่อพิจารณาส่วนแบ่งตลาดของ Nordea ในสวีเดนและกลุ่มประเทศนอร์ดิกแล้ว ถ้าทีมนั้นหายไป เศรษฐกิจสวีเดน หรืออาจถึงขั้นเศรษฐกิจนอร์ดิกก็อาจสั่นคลอนได้ และน่าจะส่งผลต่อ EU ไม่น้อยด้วย
    หลังอ่านบทความนี้ ผมก็อดสงสัยมาตลอดว่า โปรแกรมเมอร์ COBOL ที่ทำให้ธนาคารแบบนี้เดินต่อไปได้ อาจเป็น bus factor ที่ถูกประเมินต่ำอย่างมหาศาลในหลายเขตเศรษฐกิจทั่วโลกหรือไม่ และยังสงสัยด้วยว่าแผนสำรองสำหรับสถานการณ์แบบนั้นคืออะไร
    [0] https://en.wikipedia.org/wiki/Nordea

    • เริ่มสงสัยด้วยว่าโปรแกรมเมอร์ APL จะอยู่ในสถานการณ์คล้ายกันไหม เท่าที่รู้มีองค์กรขนาดใหญ่จำนวนไม่น้อยที่ใช้ APL
    • แผนสำรองสำหรับสถานการณ์แบบนั้นอาจเป็นการหยุดทำงานอย่างฉาวโฉ่ไปหลายสัปดาห์ก็ได้: https://en.wikipedia.org/wiki/TSB_Bank_(United_Kingdom)#Migration_to_the_Sabadell_Proteo_banking_platform
      ผมคิดว่า การสูญเสียความรู้ภายในองค์กร น่าจะเป็นปัจจัยใหญ่ในหายนะครั้งนั้น
    • ในฐานะโปรแกรมเมอร์ที่เคยถูกรถบัสชน แถมยังเป็นรถบัสคันเดียวกับที่นั่งไป 5 ชั่วโมงจนถึงปลายทางในกรีซตะวันตกด้วย ขอบอกว่าความเสี่ยงที่จะถูกรถชนตายนั้นสูงกว่ามาก
      ยิ่งรวมยอดขาย SUV ที่เพิ่มขึ้น ซึ่งเป็นอันตรายต่อคนเดินถนนและคนปั่นจักรยานมากขึ้นเข้าไปด้วยแล้ว อาจน่าแปลกใจเสียด้วยซ้ำที่ธนาคารไม่ได้ล่มเพราะโปรแกรมเมอร์ตาย แต่ล่มเพราะบัญชีแย่ ๆ และการฉ้อโกง
  • ประโยคที่ว่า “เคยมีโต๊ะส่วนตัว แต่ตอนนี้ย้ายไปอยู่พื้นที่เปิดที่เลือกนั่งตรงไหนก็ได้ และฉันเกลียดมันมาก” นั้นประหลาดตรงที่ต่อให้ไม่เคยทำงานเมนเฟรมมาก่อนก็ยังรู้สึกโดนมาก

    • ผมก็ชอบ โต๊ะส่วนตัว มากกว่าเยอะ การที่คนเราจัดสภาพแวดล้อมให้เข้ากับรสนิยมและความชอบของตัวเองเป็นเรื่องธรรมชาติมาก แต่ไม่เข้าใจว่าทำไมนักออกแบบสำนักงานบางคนถึงไม่คำนึงถึงเรื่องนี้
    • สงสัยว่าสำนักงานส่วนใหญ่ก็เหมือนของเราหรือเปล่า คือเรียกว่า “ที่นั่งแบบยืดหยุ่น” แต่ในทางปฏิบัติทุกคนมีที่ของตัวเอง พอมาทำงานก็นั่งโต๊ะเดิมเสมอ และโดยมากก็เคารพกันในเรื่องนี้
      เก้าอี้ ตำแหน่งและความสว่างของจอ ความสูงของโต๊ะ ฯลฯ ถูกปรับให้เข้ากับตัวเองอยู่แล้ว แนวคิด hot desking เลยดูน่าขันไปเลย อยากให้ยอมแพ้อย่างเป็นทางการไปเลยดีกว่า
  • ตอนทำงานเป็น ที่ปรึกษาด้านการผสานระบบ ในภาคบริการการเงิน ต้องผสานกับระบบ core banking แบบนี้บ่อยมาก
    โดยทั่วไป หากเจรจาอินเทอร์เฟซใหม่ทั้งหมด แรงเสียดทานทั้งด้านเทคนิค ธุรกิจ และการปฏิบัติตามกฎระเบียบจะสูงจนโปรเจกต์เลื่อนไป 1–2 ปีหรือมากกว่านั้นได้ง่าย ๆ จึงพยายามนำจุดผสานเดิมจากโปรเจกต์ก่อนหน้ากลับมาใช้
    การผสานระบบมักเป็นการส่งเอกสารที่มีโครงสร้างภายในเวลาหนึ่งในช่วงเย็น เพื่อให้ประมวลผลแบบแบตช์ตอนกลางคืน เอกสารข้อมูลแบบอิงออฟเซ็ตจะมีพื้นที่ที่ยังไม่ได้จัดสรรไว้ตามการออกแบบ เพื่อรองรับการอัปเดตและการใช้งานในอนาคต และถ้าต้องการข้อมูลใหม่ ก็จะเจรจากันว่าจะใช้ไบต์ส่วนไหนได้
    ฝั่งดึงข้อมูลบางครั้งก็หา API ที่ “ทันสมัย” กว่านี้ แต่ไม่ควรคาดหวังอะไรละเอียดแบบ REST มากเกินไป มักต้องประชุมกับฝ่ายกฎระเบียบและการปฏิบัติตามข้อกำหนดบ่อย ๆ เพื่อหาทางเลี่ยงการพัฒนาใหม่ที่มีต้นทุนสูง
    ขอเสริมว่า หลายครั้งฝ่าย compliance กลับปฏิบัติจริงและมุ่งหาทางออกมากกว่าฝ่าย IT เสียอีก การโน้มน้าวทีมของเราว่าถ้อยคำในกฎไม่ได้จำเป็นต้องตีความตามตัวอักษรแบบเข้มงวดที่สุดเสมอไป มักยากกว่าการตกลงกับฝ่าย compliance ด้วยซ้ำ
    ถ้าลองนึกว่าชั้นการผสานแบบนี้สะสมผ่านโปรเจกต์นับร้อยมาตลอดหลายสิบปี ก็จะเริ่มเข้าใจเป็นครั้งแรกว่าทำไม การเปลี่ยนระบบ core ถึงยากขนาดนั้น

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

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

    • อยู่ในสถานการณ์คล้ายกัน แม่ของผมทำซอฟต์แวร์จำลองสำหรับ ระบบ AEGIS ซึ่งไม่ใช่เรื่องปกติสำหรับผู้หญิงผิวดำในทศวรรษ 1980
      ตอนอายุ 20 เธอเรียนจบปริญญาคณิตศาสตร์ภายใน 3 ปี และในทศวรรษ 1970 ก็เขียนโปรแกรมคอมพิวเตอร์ด้วยบัตรเจาะรู
      ตอนนี้เธอผูกเชือกรองเท้าเองให้เรียบร้อยสม่ำเสมอยังไม่ได้ อยากให้ทุกคนบันทึกความสำเร็จและเรื่องราวชีวิตของคนที่รักไว้ก่อนจะสายเกินไป
    • ถ้าเคยคิดถึงเรื่องแบบนี้ ขอแนะนำให้ลงมือทำเลย ถ้ากำลังคิดว่าจะเริ่มอย่างไร แนะนำ แอป StoryCorps
      ใช้ง่าย มีคำถามที่เตรียมไว้ให้มากมาย และสร้างคำถามเองก็ได้ อัดเสียงลงในโทรศัพท์ได้ทันที และถ้าต้องการก็อัปโหลดบทสัมภาษณ์ไปยังหอสมุดรัฐสภาสหรัฐฯ ได้ด้วย
      https://storycorps.org/participate/storycorps-app/
    • อาจเป็นทั้งสองอย่างก็ได้: https://en.wikipedia.org/wiki/Fractional_Orbital_Bombardment_System#Development_history_and_deployment
  • คุณยายอายุครบ 95 ปีในปีนี้ ทุกวันนี้ยังไปทำงานที่สถาบันวิจัยแห่งหนึ่งในอดีตกลุ่มโซเวียตทุกวัน เพื่อเขียนงานจำลองเชิงตัวเลขด้วย Fortran และ Maple
    เพื่อนร่วมงานยังคงไม่อยากให้ท่านเกษียณ และท่านเองก็เลื่อนการเกษียณออกไปทุกปี ผมภูมิใจมากกับความรู้ด้านการวิเคราะห์เชิงตัวเลขและคณิตศาสตร์อันยอดเยี่ยมของท่าน

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

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