Slack আর কোডের মধ্যে কনটেক্সট সুইচিং: ডিপ ওয়ার্কের ওপর লুকানো ট্যাক্স
Slack আর কোডের মধ্যে কনটেক্সট সুইচিং ডেভেলপারদের প্রতি সপ্তাহে ঘণ্টার পর ঘণ্টা ডিপ ওয়ার্ক খেয়ে ফেলে। কীভাবে এটা মাপবে, কমাবে, আর ফ্লো স্টেট হারানো বন্ধ করবে – এখানে আছে।
By Ellis Keane · 2026-03-13
আজ তুমি আসলে কত মিনিট ডিপ ওয়ার্ক করেছ? ডেস্কে বসে থাকার সময় না। IDE খোলা থাকার সময়ও না। একটাই সমস্যায় টানা, নিরবচ্ছিন্ন, গভীর ফোকাস। এটা যদি আত্মবিশ্বাসের সাথে বলতে পারো, তাহলে হয় তুমি একটু বাড়িয়ে বলছ, না হয় Slack আর কোডের মধ্যে কনটেক্সট সুইচিং-এর অভিজ্ঞতাই তোমার হয়নি – সেক্ষেত্রে সত্যি বলছি, তোমার উপায়টা আমাকে শেখাও।
আমি এটা জিজ্ঞেস করি কারণ বেশিরভাগ দিন আমি নিজেই আমার সংখ্যা জানি না। জানি, সকাল ৯টায় বসেছিলাম একটা database migration করতে। জানি, কখন যেন তাকিয়ে দেখি দুপুর ১টা। আর জানি, ওই ফাঁকে Slack খুলেছি হয়তো দুই ডজনবার – কারও দরকার ছিল বলে না, ওই ছোট লাল badge-এর টান এমন যে ছোটখাটো একটা চাঁদও লজ্জা পাবে। যে migration সকালেই শেষ হওয়ার কথা, সেটা গড়িয়ে বুধবার পর্যন্ত গেল।
২৩ মিনিটের মিথ (আর আসলে কী সত্য)
তুমি হয়তো এই পরিসংখ্যান দেখেছ: "একবার কনটেক্সট সুইচ করলে আবার ফোকাসে ফিরতে ২৩ মিনিট লাগে।" এটা এসেছে UC Irvine-এ Gloria Mark-এর গবেষণা থেকে, আর গবেষণাটা সত্যি হলেও সংখ্যাটা এত ভুলভাবে quote হয় যে এটা এখন মোটামুটি vibes-এ নেমে এসেছে। ২৩ মিনিট বলতে বোঝানো হয়েছে মূল কাজে ফেরার সময় – একই গভীরতার ফোকাসে ফেরার সময় না – আর এটা ব্যাপকভাবে knowledge workers-দের ওপর মাপা হয়েছিল, শুধু ডেভেলপারদের ওপর না।
ডেভেলপারদের ক্ষেত্রে আসল খরচ পুরোটা নির্ভর করে তুমি মাথায় কী ধরে রেখেছিলে তার ওপর। ধরো একটা subtle race condition debug করছ, আর বিশ মিনিট তাকিয়ে থেকে অবশেষে তিনটা interlocking state machine-এর mental model বানালে। সেটা হারালে আবার পুরো বিশ মিনিট। Config ফাইলে typo fix? কয়েক সেকেন্ড। মূল কথা নির্দিষ্ট সংখ্যা না। মূল কথা হলো, Slack আর কোডের মধ্যে কনটেক্সট সুইচিং-এর খরচ মুহূর্তে সম্পূর্ণ অদৃশ্য থাকে কিন্তু সপ্তাহ শেষে sprint velocity-তে একদম পরিষ্কার দেখা যায়।
Lokalise Tool Fatigue Report বলছে, মানুষ গড়ে দিনে ৩৩ বার অ্যাপ বদলায়, আর ১৭% মানুষ ১০০ বারেরও বেশি সুইচ করে। আমরা "productivity" সফটওয়্যারের এমন একটা ইকোসিস্টেম বানিয়েছি যেটার প্রধান measurable effect হলো productivity-ই ভাঙা। কোথাও না কোথাও, একজন product manager DAU সংখ্যা দেখে উদযাপন করছে, যেখানে ওই সংখ্যার বড় অংশই আসলে মানুষ কাজে ফিরতে পারবে কি না সেটা চেক করছে।
কেন Slack আর কোডের মধ্যে কনটেক্সট সুইচিং আলাদাভাবে বেশি ব্যয়বহুল
Slack-এর ব্যাপারে ন্যায্য থাকতে চাই। এটা সত্যিই ভালো টুল, আর আমি বলতে যাচ্ছি না engineering team-দের IRC-তে ফিরে যাওয়া উচিত (যদিও কিছু দিন মাথায় আসে)। কিন্তু Slack থেকে IDE-তে কনটেক্সট সুইচ, দুইটা browser tab-এর মধ্যে সুইচের চেয়ে গুণগতভাবে অনেক বেশি ব্যয়বহুল। কেন, সেটা বোঝার মতো।
Mental model-এর অমিল। যখন তুমি কোডে ডুব দাও, মাথায় থাকে একটা জটিল model – variable state, function call chain, সিস্টেমের overall shape, আর নির্দিষ্ট ক্রমে কোন change করতে হবে। Slack চলে একেবারে ভিন্ন cognitive mode-এ: social context, conversational threading, কে কী বলছে আর সেটা তোমার relevant কি না বোঝা। এই দুই mode-এর মধ্যে সুইচ করা tab toggle না। এটা দুই সম্পূর্ণ আলাদা ধরনের চিন্তার মধ্যে বারবার যাওয়া, আর তোমার brain-এ কোনোটারই "save state" বাটন নেই।
অনিশ্চয়তার ট্যাক্স। আসলে ফোকাস মারে কী জানো? interruption নিজে না, interruption হতে পারে এই সম্ভাবনা। Notification badge উঠলে তুমি জানো না সেটা জরুরি কি না, চেক না করে বোঝা যায় না। এই অনিশ্চয়তা working memory-তে unresolved প্রশ্ন হয়ে বসে থাকে, তুমি সুইচ resist করলেও attention কুটকুট করে খায়। আর দেখো, এটা resist করতে আমিও তেমন ভালো না – commit message লেখার মাঝপথে badge peripheral vision-এ পড়তেই নিজেকে Cmd-Tab করে Slack-এ যেতে দেখেছি। Commit message ছিল dead code remove নিয়ে। Slack notification ছিল কেউ একটা gif-এ gif react করেছে। দারুণ productive বিকেল।
Thread trap। তুমি Slack খুললে, notification দেখলে, thread-এ ঢুকলে, তিনটা message পড়লে, বুঝলে তোমার input লাগবে না, বের হলে, দেখলে আরেকটা channel-এ badge, সেটাও চেক করলে – তারপর দেখলে পাঁচ মিনিট উড়ে গেছে আর migration logic দূর স্মৃতি। Irony হলো, Slack-এর threading model noise কমানোর জন্য ডিজাইন করা হলেও "badge দেখলাম" থেকে "আমাকে কিছু করতে হবে না নিশ্চিত হলাম" পর্যন্ত click-এর সংখ্যা বাড়ায়। Thread-এর ভেতর thread। নিচে নামতে নামতে শেষ নেই।
Slack আর কোডের মধ্যে কনটেক্সট সুইচিং-এর খরচ Slack-এ কাটানো কয়েক সেকেন্ড না। আসল খরচ হলো সম্পূর্ণ ভিন্ন দুই ধরনের চিন্তার মধ্যে সুইচ করার cognitive overhead, যার সাথে যোগ হয় notification আদৌ interruption-এর যোগ্য ছিল কি না সেই অনিশ্চয়তা।
আসলে কী কাজ করে (আর কী করে না)
আমি প্রায় সব standard advice ট্রাই করেছি – ঠিকমতো ট্রাই, "ব্লগ পড়ে মাথা নাড়ানো" ট্রাই না। গত ছয় মাস নিজের interruption pattern দেখে যেখানে এসে দাঁড়িয়েছি, সেটা এখানে।
যা কাজ করে
- Scheduled Slack windows। Deep-work দিনে Slack দেখো সকাল ৯টা, দুপুর ১২টা, আর বিকেল ৩টায়, বাকি সময় app পুরো close রাখো (minimize না, close)। Switch count mid-twenties থেকে single digit-এ নামে। Focus day-তে dock icon পুরো hide করা absurd শোনায় কিন্তু কাজ দেয়।
- DND + keyword exception। Slack-এর Do Not Disturb mode এমনভাবে set করো যাতে নির্দিষ্ট term বা নির্দিষ্ট মানুষের message ঢুকে যায়। Noise চুপ, genuine urgency alert। Perfect না, কিন্তু binary-র চেয়ে ভালো।
- Outbound message batching। Scratchpad-এ Slack message লিখে batch করে পাঠাও। টিমের অন্যদের interruption কমে, আর "wait, আগেরটা ignore করো" follow-up কমে।
শুনতে ভালো লাগে কিন্তু বাস্তবে টেকে না
- "Notification বন্ধ করো।" Flow state দারুণ বাঁচায়। কিন্তু একই সাথে সেই thread মিস হয় যেখানে তোমার টিম সেই API contract বদলে দিচ্ছে যেটার বিরুদ্ধে তুমি implement করছ। Cure নিজেই নতুন disease বানায়।
- "Status busy দাও।" মানুষ status দেখে না। Status-এ বাস্তব তথ্য থাকে না কারণ সবাই সবসময় busy দাবি করে – অফিস সংস্করণ: "কেমন আছ?" / "ভালো।"
সিস্টেম-লেভেল ফিল্টারিং
Scheduled window পদ্ধতি কাজ করে, কিন্তু এটা discipline-ভিত্তিক সমাধান – আর discipline solution-এর shelf life থাকে। তিন সপ্তাহ মেইনটেইন করবে, জরুরি কিছু pattern ভেঙে দেবে, আর তুমি আবার badge নড়লেই Slack চেকে ফিরে যাবে। এই cycle আমি যথেষ্টবার দেখেছি বুঝতে যে fix হলো বেশি willpower না। Fix হলো ভালো filter।
সিস্টেম লেভেলে কনটেক্সট সুইচিং সমস্যার আসল সমাধান হবে এমন কিছু যেটা একসাথে বুঝবে তুমি কী কাজ করছ আর Slack-এ কী হচ্ছে, এবং পার্থক্য করতে পারবে "এই thread-এ একটা decision আছে যেটা তোমার লেখা কোডে সরাসরি প্রভাব ফেলবে" আর "কেউ #random-এ লাঞ্চের option নিয়ে তর্ক করছে।"
Sugarbug-এ আমরা ঠিক এটাই বানাচ্ছি। এটা Slack-এ connect হয় (আর GitHub, Linear, Figma সহ আরও কয়েকটি টুলে), প্রতিটা সিগন্যাল টাইপ অনুযায়ী classify করে – decision, blocker, question, status update, noise – এবং সেগুলোকে সংশ্লিষ্ট task আর মানুষের সাথে link করে। Slack না খুলেই দেখতে পাও কোন Slack activity তোমার current task-এর জন্য relevant। Badge না। Uncertainty tax না। পাঁচ মিনিট thread spelunking করে বুঝতে হওয়া না যে, না, ওই notification তোমাকে নিয়ে ছিল না।
গত সপ্তাহের একটা concrete example: আমি vector search migration-এ ডুবে ছিলাম, আর একজন teammate Slack thread-এ ঠিক করল সামনে কোন embedding model ব্যবহার করব। Filtering না থাকলে আমি হয় এটা পুরো miss করতাম (DND mode), না হয় ঘণ্টাখানেক পর thread scan করতে গিয়ে পেতাম। Sugarbug-এর classifier এটাকে "decision – তোমার current task-এর জন্য relevant" সিগন্যাল হিসেবে surface করল। এক নজর, আবার migration-এ ফেরত।
আমরা এটা এখনও perfect করতে পারিনি – classifier edge case মিস করে, আর filtered সিগন্যাল এমনভাবে present করার UX নিয়ে iterate করছি যাতে আরেকটা notification surface তৈরি না হয় (যেটা হবে দারুণভাবে ironic own goal)। কিন্তু imperfect filtering-ও "all notifications" আর "no notifications"-এর binary-র চেয়ে ভালো। ওই migration-এর দিনে আমার হিসেবে অন্তত বিশবার Slack-এ যাওয়া সম্পূর্ণ অপ্রয়োজনীয় ছিল – বিশটা context reload, যেগুলো decent filter থাকলে হতোই না।
Badge উঠলেই context tax দেওয়া বন্ধ করো। Sugarbug শুধু সেই Slack সিগন্যাল surface করে যেগুলো সত্যিই তোমার current work-এ প্রভাব ফেলে।
Q: Slack আর কোডের মধ্যে কনটেক্সট সুইচিং আসলে কতটা খরচ করে? A: UC Irvine-এ Gloria Mark-এর গবেষণা বলছে, বাধার পর মূল কাজে ফিরতে প্রায় ২৩ মিনিট লাগে, যদিও তুমি কী করছিলে তার complexity অনুযায়ী আসল খরচ অনেক ওঠানামা করে। ডেভেলপাররা যখন দিনে বহুবার Slack আর IDE-র মধ্যে সুইচ করে, সেটা মিলিয়ে প্রতি সপ্তাহে ঘণ্টার পর ঘণ্টা ডিপ ওয়ার্ক হারায় – আর কষ্ট করে বানানো mental model সাধারণত এই round trip-এ টিকে থাকে না।
Q: Sugarbug কি Slack আর কোডের মধ্যে কনটেক্সট সুইচিং কমাতে সাহায্য করে? A: হ্যাঁ। কিছু দরকার আছে কি না দেখতে Slack-এ সুইচ করার বদলে, Sugarbug মেসেজ টাইপ অনুযায়ী classify করে আর তোমার চলতি task-এর সাথে link করে। Decision, blocker, আর question-এর মতো relevant সিগন্যাল তোমার সামনে আসে, খুঁজতে যেতে হয় না। লক্ষ্য হলো "just in case" switch বাদ দেওয়া – যেগুলোতে Slack খুলে কিছু actionable পাও না, তারপর তিন মিনিট ধরে মনে করার চেষ্টা করো তুমি কী করছিলে।
Q: কনটেক্সট সুইচিং কমাতে Slack notification বন্ধ করে দেওয়া উচিত? A: Mute করলে flow state বাঁচে, কিন্তু সত্যিই জরুরি জিনিস মিস হয় – যেমন সেই thread যেখানে তোমার টিম সেই API বদলে দিচ্ছে যেটার বিরুদ্ধে তুমি implement করছ। ভালো পদ্ধতি হলো filtering: এখনই মনোযোগ দরকার এমন সিগন্যাল আর অপেক্ষা করতে পারা noise আলাদা করা। Scheduled Slack window এর ভালো manual version; Sugarbug হলো automated version।
Q: কনটেক্সট সুইচিং আর multitasking-এর পার্থক্য কী? A: Multitasking হলো একসাথে দুটো কাজ করার চেষ্টা (যেটায় মানুষ সত্যিই খারাপ)। কনটেক্সট সুইচিং হলো ধারাবাহিকভাবে এক কাজ থেকে আরেক কাজে যাওয়া – খরচটা হলো কোডের mental model আবার reload করার সময় আর cognitive energy। Complex system মাথায় ধরে কাজ করা ডেভেলপারের ক্ষেত্রে এই reload কয়েক সেকেন্ড থেকে আধাঘণ্টা পর্যন্ত যেতে পারে, কাজের depth-এর ওপর নির্ভর করে।
Q: Sugarbug কি ফিল্টার করতে পারে কোন Slack মেসেজে বাধা দেওয়া উচিত? A: Sugarbug টাইপ অনুযায়ী সিগন্যাল classify করে আর তোমার task-এর সাথে link করে। তাই Slack খুলে সব channel scan না করে সরাসরি দেখতে পাও কোন activity তোমার current work-এর জন্য relevant। Relevance scoring নিয়ে আমরা এখনও iterate করছি (perfect না), কিন্তু DND mode-এর all-or-nothing approach-এর চেয়ে এটা অর্থপূর্ণভাবে ভালো।
---
Slack থেকে IDE-তে round trip যদি তোমার deep-work hour শুকিয়ে দেয় – আর notification badge এড়াতে dock icon লুকানো যদি তোমার কাছে যুক্তিসংগত productivity strategy মনে হয় – এই tax কমানোর জন্যই আমরা Sugarbug বানিয়েছি। ওয়েটলিস্টে যোগ দাও।