ต้นทุนของการสลับบริบท: ตัวเลขไหนยังเชื่อถือได้ และวิธีนับต้นทุนของคุณเอง

แทบทุกบทความว่าด้วยต้นทุนของการสลับบริบทอ้างตัวเลขเดียวกัน: 23 นาที 15 วินาทีกว่าจะกลับมาทำงานต่อได้หลังถูกขัดจังหวะ มันแม่นยำถึงระดับวินาที มาจากนักวิจัย UC Irvine ที่มีชื่อเสียง และหน้าเว็บส่วนใหญ่ที่อ้างมันตีความผิด

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

ขอหมายเหตุเรื่องศัพท์หนึ่งข้อ เพราะ "context switch" มีความหมายอีกอย่างในระบบปฏิบัติการ: ในบริบทนั้น มันคือเคอร์เนลบันทึกสถานะของโปรเซสหนึ่งไว้ เพื่อให้โปรเซสอื่นทำงานต่อได้ บทความนี้พูดเรื่องคน — การย้ายความสนใจของคุณจากงานหนึ่งไปอีกงานก่อนที่งานแรกจะเสร็จ นักจิตวิทยาศึกษาเวอร์ชันในห้องแล็บในชื่อ task switching (การสลับงาน)

คำตอบสั้น ๆ: งานวิจัยวัดต้นทุนไว้สามอย่างต่างกัน ในห้องแล็บ การสลับหนึ่งครั้งทำให้การตอบสนองถัดไปของคุณช้าลงเสี้ยววินาที — ราว 200 มิลลิวินาทีในตัวอย่างทั่วไป — และการเตรียมตัวล่วงหน้าช่วยลดต้นทุนนั้นได้แต่ไม่ทำให้หายไป งานที่คุณทิ้งไว้ไม่เสร็จจะทิ้ง attention residue (ความสนใจที่ค้างอยู่) ซึ่งกดประสิทธิภาพในงานถัดไป และในออฟฟิศจริง งานที่ถูกขัดจังหวะแล้วกลับมาทำต่อในวันเดียวกันจะรอราว 25 นาทีก่อน — เวลารอนั้น ไม่ใช่เวลาที่ใช้เรียกสมาธิคืน คือที่มาของ "23 นาที" เจ้าดัง

ต้นทุนของการสลับงานในห้องแล็บ

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

การสาธิตคลาสสิกคือ Rogers และ Monsell (1995): ผู้เข้าร่วมสลับตามตารางเวลาคงที่ระหว่างการตัดสินตัวเลข (คู่หรือคี่) กับตัวอักษร (สระหรือพยัญชนะ) เวลาเตรียมตัวถึง 0.6 วินาทีช่วยลดต้นทุนได้ เกินกว่านั้นมันไม่ช่วยอะไรอีก และแม้มีเวลาเตรียมตัว 1.2 วินาที "ต้นทุนเวลาปฏิกิริยา (RT) ขนาดใหญ่ยังคงค้างอยู่ที่ระดับ asymptotic"

Rubinstein, Meyer และ Evans (2001) ใช้งานที่ยากกว่า — จัดเรียงรูปทรงและคิดเลขภายใต้กฎที่เปลี่ยนไปมา — ในการทดลองสี่ครั้ง แต่ละครั้งมีนักศึกษาระดับปริญญาตรี 12 ถึง 36 คน การทำสลับมีต้นทุน 614 ถึง 1,096 มิลลิวินาทีต่อการตอบสนองหนึ่งครั้ง เทียบกับการทำงานเดียวซ้ำ ๆ: มากขึ้นเมื่อกฎซับซ้อน น้อยลงเมื่อมีสัญญาณบอกว่าอะไรจะมาถัดไป

งานทบทวนปี 2003 ของ Monsell เพิ่มต้นทุนการผสมงาน: เมื่อการสลับอาจเกิดขึ้นได้ คนจะช้าลงแม้ในรอบที่งานซ้ำเดิม การสลับจึงเก็บภาษีทั้งบล็อก ต้นทุนตกค้างยังปรากฏแม้มีเวลาเตรียมตัวห้าวินาทีขึ้นไป แต่นี่คืองานง่าย ๆ ภายใต้เงื่อนไขอุดมคติ — ไม่เหมือนการ review โค้ดที่ถูกขัดจังหวะด้วยเธรด Slack เลย สองสายงานวิจัยถัดไปเข้าใกล้ความจริงมากกว่า

Attention residue: ส่วนของใจที่ยังติดอยู่กับงานเก่า

Attention residue คือความคิดที่ค้างอยู่กับงาน A หลังคุณย้ายไปงาน B แล้ว Sophie Leroy แสดงให้เห็นว่ามันกดประสิทธิภาพในงาน B มากที่สุดเมื่องาน A ถูกทิ้งไว้ไม่เสร็จ

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

งานวิจัยวัด residue ทันทีหลังการสลับ จึงไม่ได้ให้ระยะเวลาเป็นนาที หน้าเว็บที่โทษว่า residue ทำให้การเรียกสมาธิคืนกินเวลากว่า 20 นาที กำลังเชื่อมผลวิจัยสองเรื่องที่ไม่เกี่ยวกันเข้าด้วยกัน และนี่คือนักศึกษากับงานสั้น ๆ ในห้องแล็บ

Leroy และ Glomb (2018) มองไปที่งานตัวที่มาขัดจังหวะ คนที่คาดว่าจะต้องกลับไปทำงานที่ถูกขัดจังหวะภายใต้แรงกดดันเรื่องเวลาจะโฟกัสกับงานที่มาขัดจังหวะได้ยาก วิธีแก้ที่ได้ผลตลอดสี่การศึกษา: ก่อนสลับ จดไว้ว่าคุณอยู่ตรงไหนและจะทำอะไรต่อ พวกเขาเรียกมันว่า ready-to-resume plan (แผนพร้อมกลับมาทำต่อ) และมันช่วยลด residue พร้อมปกป้องประสิทธิภาพในงานที่มาขัดจังหวะ

ต้นทุนของการถูกขัดจังหวะในที่ทำงาน

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

Mark, González และ Harris (2005) ติดตามผู้จัดการ นักวิเคราะห์ และนักพัฒนา 24 คน คนละราวสามวัน — รวมเวลาสังเกตกว่า 700 ชั่วโมง — และเก็บข้อมูล "working spheres" คำที่พวกเขาใช้เรียกหน่วยงานระดับโปรเจกต์ 57% ของสเฟียร์เหล่านี้ถูกขัดจังหวะ งานที่ถูกขัดจังหวะแล้วกลับมาทำต่อในวันเดียวกันรอเฉลี่ย 25 นาที 26 วินาที (ส่วนเบี่ยงเบนมาตรฐาน 54 นาที 48 วินาที) โดยมีสเฟียร์อื่นคั่นกลางเฉลี่ย 2.26 สเฟียร์

ในห้องแล็บ Mark, Gudith และ Klocke (2008) ให้คน 48 คนตอบอีเมลงานขณะที่ "หัวหน้า" มาขัดจังหวะทุก ๆ ราวสองนาที รอบที่ถูกขัดจังหวะเสร็จเร็วกว่ารอบที่เงียบสงบ โดยไม่ต่างกันในแง่ข้อผิดพลาดหรือความสุภาพ — คนเขียนอีเมลสั้นลง ราคาที่ต้องจ่ายอยู่ในแบบสอบถาม: ความเครียด ความหงุดหงิด ปริมาณงาน ความพยายาม และแรงกดดันเรื่องเวลามากขึ้น "หลังทำงานแบบถูกขัดจังหวะเพียง 20 นาที"

จังหวะเวลาเปลี่ยนต้นทุนได้ Iqbal และ Bailey (2008) กักการแจ้งเตือนไว้จนถึงจุดพักตามธรรมชาติของงาน กับผู้เข้าร่วม 16 คนที่เขียนโปรแกรมหรือแก้ไขไดอะแกรม วิธีนั้นลดความหงุดหงิดและเวลาปฏิกิริยาเทียบกับการแจ้งเตือนทันที โดยหน่วงเฉลี่ยไม่ถึง 90 วินาที แต่มันไม่ได้ทำให้การกลับมาทำต่อเร็วขึ้น ผมสร้าง Timex แอปติดตามเวลาบน Mac และงานวิจัยชิ้นนี้คือเหตุผลที่การเตือนของ Energy จะรอจังหวะสลับแอปหรือช่วงหยุดนิ่งสักนาทีหนึ่ง

สถิติ context switching เจ้าดัง เมื่อตรวจบัญชีแล้ว

ตัวเลขห้าตัวที่โผล่บ่อยที่สุด ย้อนรอยกลับไปยังจุดเริ่มต้น:

คำอ้างที่ถูก 인용บ่อย	ที่มาจริง ๆ	สิ่งที่วัด	คำตัดสิน
"ต้องใช้เวลา 23 นาที 15 วินาทีเพื่อเรียกสมาธิคืนหลังถูกขัดจังหวะ"	Gloria Mark ในบทสัมภาษณ์ Gallup ปี 2006 เกี่ยวกับคน 36 คนที่เธอติดตาม ส่วนงานวิจัยปี 2005 ของเธอที่มี 24 คน รายงานไว้ที่ 25 นาที 26 วินาที	เวลาที่พนักงานออฟฟิศซึ่งถูกสังเกตใช้กลับไปยังโปรเจกต์ที่ถูกขัดจังหวะในวันเดียวกัน หลังแวะไปราวสองโปรเจกต์อื่น	ตัวเลขจริง ความหมายผิด มันคือการอ้อมไประหว่างโปรเจกต์ ไม่ใช่เวลาที่ใช้เรียกสมาธิคืน ค่าเฉลี่ย 25 นาทีในงานวิจัยมีส่วนเบี่ยงเบนมาตรฐาน 54 นาที มากกว่าค่าเฉลี่ยกว่าสองเท่า ส่วนบทสัมภาษณ์ไม่ได้ให้ค่านี้ไว้เลย
"การสลับงานกินเวลาทำงานที่มีประสิทธิภาพของคุณถึง 40%"	หน้าเว็บ APA จากปี 2006	ไม่มีการวัดอะไรที่ใหญ่ขนาดนั้น หน้านั้นรายงานคำพูดของ David Meyer ("มากถึง 40 เปอร์เซ็นต์") และบอกว่าการสลับหนึ่งครั้งอาจมีต้นทุน "แค่ไม่กี่ส่วนสิบของวินาที"	ยืดเกินจริง เป็นคำพูดแบบเพดานบน ไม่ใช่ผลการวิจัย
"พนักงานสลับไปมาระหว่างแอปวันละ 1,200 ครั้ง เสียเวลาสัปดาห์ละ 4 ชั่วโมง"	Murty, Dadlani และ Das, HBR 2022	พนักงาน 137 คน ส่วนใหญ่ทำงานสาย mid-/back-office (การเงิน, HR, ซัพพลายเชน…) ในบริษัท Fortune 500 สามแห่ง นานสูงสุดห้าสัปดาห์ การสลับแต่ละครั้งใช้เวลาตั้งหลัก "สองวินาทีกว่า ๆ"	เชื่อถือได้ สำหรับกลุ่มนั้น ผู้เขียนสองในสามคนทำงานที่ Soroco ซึ่งเป็นผู้สร้างซอฟต์แวร์ที่ใช้วัด ตัวเลขสี่ชั่วโมงคือราวสองวินาทีคูณการสลับวันละ 1,200 ครั้ง บวกรวมตลอดสัปดาห์ — ไม่ใช่สมาธิที่เสียไป
"โปรเจกต์หรืองานที่เพิ่มมาแต่ละชิ้นกินเวลาของคุณ 20%"	ตารางในหนังสือปี 1992 ของ Gerald Weinberg เรื่อง Quality Software Management หน้า 284 ตามที่ Chris Gagné อ้างถึง	การสลับระหว่างโปรเจกต์ที่ทำพร้อมกัน ผมไม่เจองานวิจัยหรือชุดข้อมูลใด ๆ รองรับตารางนั้น	ค่าประมาณที่ยังไม่ได้รับการยืนยัน พูดเรื่องโปรเจกต์ ไม่ใช่การสลับแอป
"การถูกขัดจังหวะห้าวินาทีทำให้ข้อผิดพลาดของคุณเพิ่มเป็นสามเท่า"	Altmann, Trafton และ Hambrick (2014)	นักศึกษาปริญญาตรี 300 คนทำตามลำดับขั้นตอนคงที่: การขัดจังหวะ 4.4 วินาทีทำให้ข้อผิดพลาดเรื่องลำดับเพิ่มสามเท่า แบบ 2.8 วินาทีเพิ่มสองเท่า ข้อผิดพลาดประเภทอื่นไม่เปลี่ยน	เชื่อถือได้ ในขอบเขตแคบ ๆ มันพูดเรื่องการลืมว่าทำถึงไหนในขั้นตอนแบบทีละขั้น

สองแถวในตารางเป็นจริงตามความหมายที่คนทั่วไปเข้าใจพร้อมกันไม่ได้ ถ้าการสลับแอปทุกครั้งมีต้นทุน 23 นาที 15 วินาที การสลับวันละ 1,200 ครั้งของ HBR จะต้องใช้เวลาวันละ 465 ชั่วโมง อ่านต้นทางแล้วความขัดแย้งก็หายไป: อันหนึ่งคือการตั้งหลักสองวินาทีหลังสลับหน้าต่าง อีกอันคือการอ้อม 25 นาทีก่อนที่คนจะกลับมาหยิบโปรเจกต์ที่ถูกขัดจังหวะขึ้นทำต่อ

วิธีวัดการสลับบริบทของคุณเอง

นับการสลับแอปต่อชั่วโมงของคุณจากบันทึกของวัน มันคือส่วนเดียวของต้นทุนที่คุณสังเกตได้ตรง ๆ ส่วน residue และการกลับมาทำต่อคุณทำได้แค่อนุมาน

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

จากวันที่ถูกบันทึกไว้ Timex สุ่มเก็บแอปที่อยู่หน้าสุดทุก ๆ หนึ่งวินาทีลงไฟล์ SQLite ในเครื่องหนึ่งไฟล์ หนึ่งแถวต่อหนึ่งเซกเมนต์ที่ติดตาม: bundleId ของแอป ชื่อหน้าต่าง URL เวลาเริ่ม เวลาจบ และระยะเวลา เปิดไฟล์นั้นใน SQLite viewer ที่ใช้ฟรี ซึ่งทำงานในเบราว์เซอร์โดยไม่ต้องสมัคร ใช้ไฟล์ ZIP ที่ส่งออกจาก Settings หรือไฟล์ใน ~/Library/Application Support/io.muvon.timex/ แล้ววาง query ทีละคำสั่ง

จำนวนการสลับแอปต่อชั่วโมงนาฬิกาของหนึ่งวัน (เปลี่ยนวันที่ได้):

WITH seq AS (
  SELECT startAt,
         bundleId <> LAG(bundleId) OVER w
           AND (julianday(startAt) - julianday(LAG(endAt) OVER w)) * 86400 < 120
           AS switched
  FROM activity
  WHERE date(startAt, 'localtime') = '2026-10-08'
  WINDOW w AS (ORDER BY startAt)
)
SELECT strftime('%H', startAt, 'localtime') AS hour,
       COUNT(*) FILTER (WHERE switched) AS app_switches
FROM seq
GROUP BY hour
ORDER BY hour;

จำนวนการสลับต่อชั่วโมงที่ติดตาม หนึ่งแถวต่อวัน นับจากวันที่เริ่มต้น:

WITH seq AS (
  SELECT date(startAt, 'localtime') AS day,
         duration,
         bundleId <> LAG(bundleId) OVER w
           AND (julianday(startAt) - julianday(LAG(endAt) OVER w)) * 86400 < 120
           AS switched
  FROM activity
  WHERE date(startAt, 'localtime') >= '2026-10-01'
  WINDOW w AS (PARTITION BY date(startAt, 'localtime') ORDER BY startAt)
)
SELECT day,
       COUNT(*) FILTER (WHERE switched) AS app_switches,
       ROUND(SUM(duration) / 3600.0, 1) AS tracked_hours,
       ROUND(COUNT(*) FILTER (WHERE switched) * 3600.0 / SUM(duration), 1) AS switches_per_hour
FROM seq
GROUP BY day
ORDER BY day;

กฎสามข้อที่ทำให้การนับซื่อตรง:

• การสลับคือแถวที่ bundleId ต่างจากแถวก่อนหน้า — ไม่ใช่แค่แถวใหม่ใด ๆ เพราะการเปลี่ยนชื่อหน้าต่างภายในแอปเดียวก็อาจเริ่มแถวใหม่ได้เช่นกัน
• ช่องว่างต้องต่ำกว่า 120 วินาที Timex ปิดเซกเมนต์หลังไม่มีอินพุตคีย์บอร์ดหรือเมาส์ 120 วินาที (เสียงที่กำลังเล่นหรือไมค์ที่เปิดอยู่ในแอปหน้าสุดจะทำให้เซกเมนต์เปิดต่อ) ช่องว่างที่ยาวกว่านั้นแปลว่าคุณลุกหายไป และการกลับมาใช้แอปคนละตัวหลังมื้อเที่ยงไม่ถือเป็นการสลับ
• Timex เก็บเวลาเป็น UTC ทุกวันและทุกชั่วโมงจึงต้องผ่าน modifier 'localtime' ของ SQLite เพื่อให้ตรงกับนาฬิกาของคุณ

ผมทดสอบทั้งสองคำสั่งก่อนเผยแพร่ บนฐานข้อมูล 14 แถวที่เก็บเป็น UTC และอ่านในเขตเวลา UTC+7: การสลับที่รู้คำตอบอยู่ 8 ครั้ง บวกกับแถวแอปเดียวกันสองแถว ช่องว่างลุกหายไป 15 นาที ช่องว่างสองชั่วโมง แถวจากวันก่อนหน้าตามเวลาท้องถิ่น และแถวที่เป็นวันก่อนหน้าใน UTC แต่เป็นวันที่ query ในเวลาท้องถิ่น ทั้งสอง query คืนผลออกมา 8 การสลับพอดี แบ่งเป็น 4, 2 และ 2 ในชั่วโมงท้องถิ่น 9, 10 และ 11 นาฬิกา — ทั้งใน sqlite3 ของ Python และใน sql.js บิลด์ WebAssembly ที่ตัว viewer ใช้

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

อะไรช่วยลดต้นทุนของการสลับบริบท

สลับให้น้อยลง สลับที่ขอบตามธรรมชาติ และจดโน้ตก่อนวางมือ แต่ละข้อมีงานวิจัยรองรับชัดเจน

• รวมเรื่องจุกจิกเป็นชุด การสลับทุกครั้งมีต้นทุนคงที่ และการผสมงานทำให้ช้าลงแม้ในจังหวะที่คุณไม่ได้สลับ ตอบข้อความเป็นรอบ ๆ ไม่ใช่มากองไหนตอบกองนั้น งานวิจัยปี 2008 ของ Mark พบว่าการขัดจังหวะเรื่องเดียวกับที่ทำอยู่ไม่ได้มีต้นทุนถูกกว่าเรื่องอื่น ผลได้จึงอยู่ที่การสลับให้น้อยลง ไม่ใช่การจัดกลุ่มการขัดจังหวะที่ "เกี่ยวข้องกัน"
• ปกป้องบล็อกงาน และคาดไว้ว่าคุณจะขัดจังหวะตัวเอง ในงานวิจัยปี 2005 ของ Mark นักวิเคราะห์และนักพัฒนาขัดจังหวะตัวเองบ่อยพอ ๆ กับที่คนอื่นมาขัดจังหวะพวกเขา การปิดการแจ้งเตือนคุมได้ครึ่งหนึ่ง อีกครึ่งคือการจับให้ได้ตอนที่คุณอยากลุกไปเช็กอะไรบางอย่าง
• หยุดที่ขอบงานเมื่อทำได้ Leroy พบว่าการทำเสร็จช่วยลด residue และ Iqbal กับ Bailey พบว่าการขัดจังหวะที่จุดพักทำให้คนหงุดหงิดน้อยกว่า เขียนฟังก์ชัน ย่อหน้า หรือข้อความตอบกลับให้จบ แล้วค่อยสลับ
• เมื่อทำไม่เสร็จ ทิ้งโน้ตพร้อมกลับมาทำต่อไว้ วิธีแก้ของ Leroy และ Glomb ใช้เวลาราวหนึ่งนาที: คุณอยู่ตรงไหน จะทำอะไรต่อ พวกเขาวัดผลกับงานที่มาขัดจังหวะ แต่โน้ตควรช่วยขากลับด้วย — ผู้เข้าร่วมของ Rubinstein สลับได้เร็วขึ้นเมื่อมีสัญญาณบอกว่าอะไรจะมาถัดไป และโน้ตก็คือสัญญาณนั้น

ความล้าจากการสลับบริบทมีจริงไหม

มีจริงบางส่วน ความกดดันระยะสั้นมีหลักฐานโดยตรง: ผู้เข้าร่วมในงานวิจัยปี 2008 ของ Mark ให้คะแนนความเครียด ความหงุดหงิด และความพยายามของตัวเองสูงขึ้นหลังทำงานแบบถูกขัดจังหวะ 20 นาที เวอร์ชันระยะยาว — การสลับตลอดเวลาที่บดคุณจน burnout — ไม่ใช่สิ่งที่งานวิจัยเหล่านี้ทดสอบ และผู้เขียนก็บอกไว้เอง: "เราบอกไม่ได้ว่าคนเราจะปรับตัวได้เมื่อเวลาผ่านไป หรือค่าวัดเหล่านี้จะยิ่งเพิ่มขึ้นอย่างเดียว" บทความเรื่อง toggle ของ HBR บอกว่าการสลับถี่ ๆ ทำให้คอร์ติซอลสูงขึ้น แต่ไม่ได้อ้างอิงอะไรเลย จงถือว่าคำอ้างเรื่องความเสียหายถาวรยังไม่ได้รับการพิสูจน์

ข้อจำกัดอย่างซื่อสัตย์

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

query เหล่านี้นับการสลับแอป ไม่ใช่นับการสลับความสนใจ การนึกถึงบั๊กอยู่ระหว่างตอบอีเมลนั้นมองไม่เห็น เช่นเดียวกับการย้ายไปมาระหว่างแท็บในเบราว์เซอร์เดียวหรือไฟล์ในเอดิเตอร์เดียว — ทั้งหมดนั้นยังอยู่ภายใน bundleId เดียว Timex เห็นแค่ Mac ของคุณ โทรศัพท์ที่คุณหยิบขึ้นมากลางคันจึงไม่เคยโผล่ในข้อมูล และ Timex บันทึกการสลับ มันไม่ได้บล็อกการสลับ

ลองนับสักหนึ่งสัปดาห์

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

ช่วงทดลองของ Timex ครอบคลุมการติดตาม 100 ชั่วโมงโดยไม่ต้องใช้บัตรเครดิต บน macOS 15 ขึ้นไปพร้อม Apple Silicon ดาวน์โหลด Timex ทำงานตามปกติสักหนึ่งสัปดาห์ แล้วนับ

— DK