คริสติน ไอแซค ซีอีโอและผู้ร่วมก่อตั้ง Strudel – สัมภาษณ์ซีรีส์

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

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

คุณเคยดำรงตำแหน่งผู้นำในองค์กรต่างๆ เช่น LinkedIn, Udemy และ Disney ก่อนที่จะก่อตั้ง Strudel ในปี 2025 ประสบการณ์จากบทบาทเหล่านั้นได้ทำให้คุณตระหนักถึงความจำเป็นของแพลตฟอร์ม “การออกแบบวิศวกรรมขับเคลื่อนด้วย AI” ใหม่ๆ อย่างไร และมันช่วยกำหนดรูปแบบการก่อตั้ง Strudel ได้อย่างไร?

ทุกๆ องค์กรที่ผมทำงานด้วยมีปัญหาเดียวกัน ใน Disney มีผลกระทบอย่างมาก – หากแพลตฟอร์มสตรีมมิ่งหยุดชะงักในช่วงการเปิดตัวครั้งสำคัญ มันไม่ใช่แค่ผลกระทบทางการเงิน แต่เป็นช่วงเวลาที่สำคัญของแบรนด์ ใน LinkedIn มีการเติบโตอย่างไม่หยุดยั้ง มีบริการหลายพันบริการที่สร้างเสียงรบกวน และแม้แต่ทีมที่ดีที่สุดก็ยังต้องดิ้นรนเพื่อตามทัน ใน Udemy ผมเห็นทีมที่มีคนจำนวนน้อยทำสิ่งที่น่าเหลือเชื่อด้วยเครื่องมือที่จำกัด

สิ่งที่เชื่อมโยงทั้งสามและประสบการณ์ของผู้ร่วมก่อตั้ง Shai Rubin และ Brian Kaufman ในการนำทีมวิศวกรรมคือว่าผู้วิศวกรใช้เวลามากขึ้นในการสร้างบริบทมากกว่าการแก้ปัญหาเอง เมื่อมีคนถูกเรียกในเวลา 2 นาฬิกา พวกเขาต้องค้นหาในเธรด, แดชบอร์ด, ตั๋ว Jira, บันทึกการวางจำหน่าย – เพียงเพื่อเข้าใจว่าอะไรเปลี่ยนแปลงและเมื่อไหร่ พวกเขากำลังเล่นเป็นนักสืบก่อนที่จะเริ่มทำงานจริงๆ นั่นคือการสูญเสียศักยภาพของผู้มีพรสวรรค์อย่างมาก

ผมคิดเสมอว่า ต้องมีวิธีที่ฉลาดกว่านี้ในการนำเสนอสิ่งที่สำคัญจริงๆ เมื่อถึงเวลาที่เหมาะสม นั่นคือเมล็ดพันธุ์ของ Strudel

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

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

หมวดหมู่แรกคือความไว้วางใจของลูกค้า ค่าปรับ SLA เป็นโครงสร้างทางกฎหมาย – ไม่ได้ครอบคลุมลูกค้าที่เปลี่ยนไปใช้คนอื่นอย่างเงียบๆ หรือลูกค้าองค์กรที่เห็นหน้าสถานะของคุณในเวลาที่ไม่เหมาะสมและเลือกคู่แข่งแทน นั้นเป็นความเสียหายที่ช้า ลับๆ และถาวรในรูปแบบที่การชำระเงินคืนไม่สามารถเทียบได้

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

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

วิศวกรมักถูกดึงออกจากการสร้างคุณสมบัติใหม่เพื่อตอบสนองต่อเหตุการณ์ในการผลิต การต่อสู้กับไฟอย่างต่อเนื่องนี้ส่งผลกระทบต่อนวัตกรรมผลิตภัณฑ์และแผนพัฒนาระยะยาวอย่างไร?

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

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

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

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

เครื่องมือติดตามแบบดั้งเดิมเป็นหลักๆ เป็นระบบเตือนภัย มันบอกคุณได้ว่ามีบางสิ่งเกิดขึ้น – การเพิ่มขึ้นของความหน่วง, อัตราความผิดพลาดที่เพิ่มขึ้น, พ็อดที่ล่ม แต่มันไม่สามารถให้เหตุผลข้ามโดเมนได้

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

การเชื่อมโยงข้ามโดเมนนี้คือสิ่งที่ AI ทำให้เกิดขึ้นได้ เราสามารถรักษาตั๋ว Zendesk, การ.commit GitHub, การสืบค้น Datadog (DDOG ) และหลักฐาน CloudWatch เป็นส่วนหนึ่งของเรื่องราวที่รวมกันแทนที่จะเป็นจุดข้อมูลที่แยกจากกัน AI นำเสนอไม่เพียงแต่สิ่งที่เสียหาย แต่ยังรวมถึงสาเหตุและที่มา – และมันพื้นฐานมาจากหลักฐานที่วิศวกรสามารถตรวจสอบและดำเนินการได้จริง เราไม่ได้ขอให้ทีมวางใจในกล่องดำ เราให้สมมติฐานที่มีเหตุผลและความเริ่มต้นที่รวดเร็ว

คุณอธิบาย Strudel ว่าเป็นการนำเสนอ “การออกแบบวิศวกรรม” คอนเซปต์นี้หมายถึงอะไรในทางปฏิบัติ และมันแตกต่างจากแพลตฟอร์มการตรวจสอบหรือ AIOps แบบดั้งเดิมอย่างไร?

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

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

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

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

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

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

การหยุดชะงักหลายครั้งมาจากบั๊กเล็กๆ หรือการเปลี่ยนแปลงการกำหนดค่าที่หลุดจากการทดสอบ AI ระบุรูปแบบที่ซับซ้อนในโค้ด, หลักฐาน หรือสัญญาณโครงสร้างได้อย่างไรเพื่อป้องกันเหตุการณ์สำคัญ?

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

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

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

บริษัทต่างๆ มักลงทุนอย่างมากในการตรวจจับ แต่ยังคงดิ้นรนในการลดเวลาในการแก้ไขปัญหา อุปสรรคที่ใหญ่ที่สุดที่ป้องกันไม่ให้องค์กรปิดช่องว่างระหว่างการตรวจจับและการแก้ปัญหาอย่างแท้จริงคืออะไร?

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

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

การประกอบบริบทนี้คือปัญหาอุดตัน ไม่ใช่ว่าวิศวกรและทีมสนับสนุนไม่รู้วิธีแก้ปัญหา – แต่พวกเขาใช้เวลา 30-60 นาทีแรกของทุกเหตุการณ์ในการพยายามเข้าใจว่าพวกเขาเห็นอะไรอยู่ นั่นคือที่ที่ Strudel อยู่ ทั้งสมมติฐานของเราคือว่าหากคุณสามารถมอบรูปภาพที่สอดคล้องกันและอ้างอิงจากหลักฐานให้กับวิศวกร – ณ เวลาที่พวกเขา cần – คุณจะบีบอัดช่องว่างนั้นอย่างมาก การทำงานแก้ไขยังคงเป็นของพวกเขา เราแค่พาให้ถึงเส้นเริ่มต้นได้เร็วขึ้น

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

สิ่งที่ผมรู้สึกอย่างแรงที่สุดในเรื่องนี้คือ สิ่งนี้: มนุษย์ควรตรวจสอบโค้ดที่เข้าไปในผลิตเสมอ

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

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

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

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

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

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

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

ขอขอบคุณสำหรับการสัมภาษณ์ที่ยอดเยี่ยม ผู้อ่านสามารถเรียนรู้เพิ่มเติมได้ที่ Strudel