নোটিফিকেশন ওভারলোড: Linear, GitHub এবং Slack
Linear, GitHub, এবং Slack নোটিফিকেশন কি তোমার ইঞ্জিনিয়ারিং টিমকে নাজেহাল করছে? কেন আর্কিটেকচার ভেঙে পড়ে তার বিশ্লেষণ – এবং যে ৫টি সিগন্যাল আসলেই কাজের।
By Chris Calo · 2026-03-13
সমস্যাটা এটা নয় যে তুমি অনেক বেশি নোটিফিকেশন পাচ্ছো। সমস্যা হলো তুমি ঠিক যতগুলো পাওয়ার কথা ততগুলোই পাচ্ছো – তিনটি ভিন্ন টুল থেকে, একই ইভেন্ট নিয়ে, একেবারে একই সময়ে।
প্রতিটি ওয়েবহুক ঠিকঠাক ফায়ার করছে। প্রতিটি ইন্টিগ্রেশন ঠিক যা দেওয়ার কথা ছিল সেটাই দিচ্ছে। GitHub তোমাকে PR নিয়ে জানাচ্ছে। Linear জানাচ্ছে সেই ইস্যুটি নিয়ে যা ওই PR ক্লোজ করছে। Slack জানাচ্ছে কারণ কেউ একজন, কোনো একসময় (সম্ভবত তুমি নিজেই, তিন মাস আগে, "ভিজিবিলিটি" বাড়ানোর এক অদ্ভুত আশাবাদ থেকে), প্রজেক্ট চ্যানেলে একটি বট কানেক্ট করেছিলে। তিনটি টুল, তিনটি নোটিফিকেশন, একটি ইভেন্ট, এবং সবগুলোই ডিজাইনমতো ঠিকঠাক কাজ করছে। ইঞ্জিনিয়ারিং একেবারে নিখুঁত। অভিজ্ঞতাটা রীতিমতো যন্ত্রণাদায়ক।
তোমার Linear, GitHub, এবং Slack নোটিফিকেশনগুলো মাত্রাতিরিক্ত হওয়ার কারণ এই নয় যে কোনো কিছু ভেঙে গেছে। এগুলো মাত্রাতিরিক্ত কারণ কোনো কিছুই ভাঙেনি। প্রতিটি টুল অত্যন্ত বিশ্বস্ততার সাথে নিজস্ব নোটিফিকেশন কন্ট্রাক্ট পালন করছে, আর তাদের কোনো ধারণাই নেই যে অন্য টুলগুলোর অস্তিত্ব আছে। এখানে কোনো শেয়ারড ইভেন্ট বাস নেই। কোনো ডিডুপ্লিকেশন লেয়ার নেই। পুরো স্ট্যাকের কোথাও "এই মানুষটা এটা আগেই জানে" এমন কোনো ধারণাই নেই। তুমি কোনো মিসকনফিগারেশনের শিকার নও। তুমি আসলে একই ওয়ার্কফ্লো-তে ছয়টি টুল জুড়ে দেওয়ার যৌক্তিক পরিণতির শিকার, যেখানে প্রতিটি টুল স্বাধীনভাবে শূন্যতায় চিৎকার করে যাচ্ছে।
"নোটিফিকেশন সিস্টেম ফেইল করছে না। এটি এত সফলভাবেই কাজ করছে যে তোমাকে একেবারে চাপা দিয়ে দিচ্ছে।" – Chris Calo
উন্নতি!
একটি সিঙ্গেল মার্জের অ্যানাটমি – ডুপ্লিকেশনের ময়নাতদন্ত
চলো তোমাকে একটা ইভেন্টের ভেতর দিয়ে নিয়ে যাই – একটি সাধারণ PR মার্জ – এবং দেখি নোটিফিকেশন লেয়ারে আসলে কী ঘটে। এটা বলছি না কারণ ব্যাপারটা অস্বাভাবিক, বরং এটা ভয়ংকরভাবে সাধারণ।
একজন টিমমেট GitHub-এ একটি PR মার্জ করলো। এরপর যা ঘটে:
- GitHub তোমার নোটিফিকেশন ইনবক্সে একটি ওয়েবহুক ফায়ার করলো। তুমি এই PR-এ একটি রিভিউ লিখেছিলে, তাই তুমি সাবস্ক্রাইবড। এটা হলো নোটিফিকেশন এক।
- Linear-এর GitHub ইন্টিগ্রেশন লিংক করা ইস্যুটি ডিটেক্ট করে এবং এর স্ট্যাটাস "In Progress" থেকে "Done"-এ অটো-ট্রানজিশন করে। যারা এই ইস্যুটি দেখছে তাদের সবার জন্য Linear একটি নোটিফিকেশন জেনারেট করে – যার মধ্যে তুমিও আছো, কারণ তোমরা একই টিমে। এটা হলো নোটিফিকেশন দুই।
- Slack বট (যেটা তুমি সেই আশাবাদের বশবর্তী হয়ে কানেক্ট করেছিলে) #frontend চ্যানেলে একটি মার্জ সামারি পোস্ট করে। যদি কেউ সেই মেসেজে কোনো ইমোজি বা কমেন্ট দিয়ে রিঅ্যাক্ট করে, Slack একটি থ্রেড নোটিফিকেশন জেনারেট করে। সেটা নোটিফিকেশন তিন, ক্ষেত্রবিশেষে চার।
- মার্জ কমিটের ওপর CI রান করে। GitHub আরেকটি ওয়েবহুক ফায়ার করে। CI যদি পাস করে, তোমার হয়তো কিছু যায় আসে না, কিন্তু তুমি নোটিফিকেশনটা পাচ্ছো কারণ GitHub-এর সাবস্ক্রিপশন মডেলটা বাইনারি – তুমি হয় দেখছো, না হয় দেখছো না। এটা হলো নোটিফিকেশন পাঁচ।
পাঁচটি নোটিফিকেশন। একটি ইভেন্ট। আর তুমি সেই কলেই ছিলে যেখানে মার্জ নিয়ে আলোচনা হয়েছিল, তাই নোটিফিকেশনগুলো আসার আগেই তুমি ব্যাপারটা জানতে।
ছয় জনের একটি টিমের জন্য প্রতিটি PR, প্রতিটি ইস্যু ট্রানজিশন, এবং প্রতিটি CI রানের সাথে একে গুণ করে দেখো – তুমি দেখতে পাবে সত্যিকারের নতুন সিগন্যাল গোনার আগেই প্রতিদিন মাথাপিছু ৩০ থেকে ৪০টি ডুপ্লিকেট ইভেন্ট জমা হচ্ছে। নোটিফিকেশন সিস্টেম ফেইল করছে না। এটি এত সফলভাবেই কাজ করছে যে তোমাকে একেবারে চাপা দিয়ে দিচ্ছে।
মিউট করা কেন রক্তক্ষরণে ব্যান্ডেজ বাঁধার মতো
সাধারণত পরামর্শ দেওয়া হয় খুব অ্যাগ্রেসিভভাবে মিউট করতে। GitHub-এর ইমেইল নোটিফিকেশন বন্ধ করে দাও। Slack-এ শুধু ডিরেক্ট মেনশন এলে যেন নোটিফাই করে তা সেট করো। Linear-এ শুধু তোমাকে অ্যাসাইন করা ইস্যুগুলো ছাড়া বাকি সবকিছু আনফলো করো। নোটিফিকেশনের দুনিয়ায় এটা অনেকটা কবজির হাড় ভাঙার পর ঘড়ি খুলে ফেলার মতো – টেকনিক্যালি তুমি কবজি-সম্পর্কিত জটিলতা কমিয়েছো ঠিকই, কিন্তু তুমি এখন আর সময় দেখার ক্ষমতাও রাখো না।
আমি এই মিউটিং অ্যাপ্রোচ ট্রাই করেছি (অবশ্যই করেছি – আমরা সবাই করি, সবাই প্রথমেই এটা ট্রাই করে, আর দ্বিতীয় যে জিনিসটা সবাই ট্রাই করে তা হলো একটা Zapier চেইন বানানো, যা পরিস্থিতিকে কোনোভাবে আরও খারাপ করে তোলে)। আমি খুবই অ্যাগ্রেসিভ ছিলাম: GitHub ইমেইল পুরোপুরি বন্ধ, আমার টিমের ওয়ার্কিং চ্যানেল ছাড়া Slack-এর সব চ্যানেল মিউট, নিজের ইস্যু ছাড়া Linear-এর সব আনফলো। প্রায় তিন দিনের জন্য স্বর্গীয় শান্তি।
তারপর আমি দুটি ব্লকিং PR রিভিউ মিস করলাম কারণ আলোচনাগুলো এমন সব চ্যানেলে হচ্ছিল যেগুলো আমি মিউট করে রেখেছিলাম। যে ইঞ্জিনিয়ারদের আমার রিভিউ দরকার ছিল তারা শেষমেশ আমাকে DM করলো – যেটা আসলে বাড়তি ঝামেলাসহ একটা নোটিফিকেশন আর তার সাথে "হেই, তুমি কি আমার মেসেজটা দেখেছিলে?" টাইপের একটু প্যাসিভ-অ্যাগ্রেসিভ ভাইব। এক সপ্তাহ পর, একটা Figma কমেন্ট থ্রেডে এমন একটা ডিজাইন ডিসিশন নেওয়া হলো যেটা আমি অর্ধেক বানানো কম্পোনেন্টটা পুরোপুরি বদলে দিলো, আর আমি সেটা জানতেই পারলাম না যতক্ষণ না আমার PR রিজেক্ট হলো। বেশ মজার অভিজ্ঞতা।
মিউট করার মূল সমস্যা হলো এটি ডায়নামিক কনটেক্সটের ওপর স্ট্যাটিক রুল অ্যাপ্লাই করে। তোমার গত মঙ্গলবারের নোটিফিকেশন সেটিংস আজ সকালে আসা জরুরি বাগটি সম্পর্কে কিছু জানে না। আর তুমি যত অ্যাগ্রেসিভভাবে মিউট করবে, তোমার সচেতনতায় গ্যাপগুলো তত বড় হতে থাকবে – যে গ্যাপগুলো টিমমেটরা "জাস্ট চেক করছি তুমি দেখেছিলে কি না..." টাইপ DM দিয়ে পূরণ করে। তুমি যদি হিসেব রাখো, অ্যাগ্রেসিভ মিউটিং আসলে তোমার নোটিফিকেশন কমায় না। এটি শুধু নোটিফিকেশনগুলোকে বট (যারা তোমাকে জাজ করে না) থেকে মানুষের (যারা নিশ্চিতভাবেই করে) দিকে সরিয়ে দেয়।
যে ৫টি সিগন্যাল আসলেই ইন্টারাপশনের দাবি রাখে
কয়েক সপ্তাহ ধরে নোটিফিকেশন লগ করার পর (একটি প্লেইন টেক্সট ফাইলে, কারণ নোটিফিকেশন আর্কিটেকচার নিয়ে আর্টিকেল লেখে এমন একজন মানুষের কাছ থেকে তুমি ঠিক এটাই আশা করবে), একটা প্যাটার্ন সামনে এলো। প্রতিদিনের প্রায় ২০০টি পিং-এর মধ্যে, যেগুলোতে আসলেই এক ঘণ্টার মধ্যে অ্যাকশন নেওয়ার প্রয়োজন ছিল, সেগুলো পাঁচটি ক্যাটাগরিতে পড়ে:
- কেউ তোমার কারণে ব্লক হয়ে আছে। তোমার নিজের কোডের ওপর একটি PR রিভিউ রিকোয়েস্ট, এমন প্রশ্ন যার উত্তর শুধু তুমিই দিতে পারো, বা তোমার মতামতের অপেক্ষায় থাকা কোনো সিদ্ধান্ত। এটিই একমাত্র ক্যাটাগরি যেখানে দেরি করার চক্রবৃদ্ধি ক্ষতি আছে – তুমি যত ঘণ্টা রেসপন্স করবে না, ঠিক তত ঘণ্টা অন্য কেউ কাজ করতে পারবে না।
- তোমার ডেপ্লয় করা কোনো কিছু ভেঙে গেছে। তোমার ব্রাঞ্চে CI ফেইলিওর, তোমার মার্জের পর এরর বেড়ে যাওয়া, একটি রিভার্ট রিকোয়েস্ট। "তোমার কোডে আগুন লেগেছে" ক্যাটাগরি।
- এমন কোনো সিদ্ধান্ত নেওয়া হয়েছে যা তোমার বর্তমান কাজকে প্রভাবিত করে। একটি ডিজাইন চেঞ্জ, একটি API কন্ট্রাক্ট আপডেট, বা প্রোডাক্টের দিক থেকে প্রায়োরিটি শিফট। এগুলো বিরল কিন্তু মিস করলে চড়া মূল্য দিতে হয় (ওপরে আমার রিজেক্ট হওয়া PR-এর কথা মনে আছে?)।
- ডেডলাইন পরিবর্তন হয়েছে। স্প্রিন্টের স্কোপ চেঞ্জ হয়েছে, কোনো ডেমোর সময় এগিয়ে এসেছে, কোনো ডিপেনডেন্সি পিছিয়ে গেছে। ক্যালেন্ডার বদলে দেওয়ার মতো ইভেন্ট।
- কারো সাহায্য দরকার এবং তুমিই সঠিক মানুষ। সব @channel নয়। সব @here নয়। ঠিক সেগুলো যেখানে তোমার দক্ষতা আসলেই প্রাসঙ্গিক – এবং তা-ও শুধু তখনই যদি অন্য কেউ উত্তর দিতে না পারে।
এর বাইরের সবকিছু – স্ট্যাটাস ট্রানজিশন, অটোমেটেড বট মেসেজ, "sounds good" ইমোজি রিঅ্যাকশন, তুমি ফলো করছো না এমন ব্রাঞ্চের CI পাস – হলো এমন তথ্য যা হয়তো একসময় কাজে আসতে পারে কিন্তু তুমি যে ফাংশনটি লিখছো তাতে ব্যাঘাত ঘটানোর কোনো প্রয়োজন এগুলোর নেই। নোটিফিকেশন ইন্ডাস্ট্রিয়াল কমপ্লেক্স আমাদের বুঝিয়েছে যে এগুলোর সবগুলোরই সমান গুরুত্ব পাওয়া উচিত। কিন্তু আসলে তা নয়।
প্রতিদিনের ২০০টি নোটিফিকেশনের মধ্যে, মোটামুটি পাঁচটি ক্যাটাগরি আসলেই তোমার কাজ থামানোর দাবি রাখে। বাকিগুলো এমন তথ্য যা হয়তো কোনো একসময় কাজে লাগতে পারে – কিন্তু টুলগুলো সবকিছুকেই সমান জরুরি হিসেবে ট্রিট করে, যার মানে দাঁড়ায় কোনো কিছুই আসলে জরুরি নয়।
আর্কিটেকচারালভাবে প্রতারিতদের জন্য একটি ট্রায়াজ ফ্রেমওয়ার্ক
এখানে এমন একটি ফ্রেমওয়ার্ক দেওয়া হলো যা তুমি আজ থেকেই ব্যবহার শুরু করতে পারো – কোনো টুলের দরকার নেই, শুধু ডিসিপ্লিন এবং সেটআপের জন্য প্রায় ২০ মিনিট। এটি আর্কিটেকচারাল সমস্যার সমাধান করবে না (একটি ডিডুপ্লিকেশন লেয়ার ছাড়া সেটা সম্ভবও না), কিন্তু দীর্ঘমেয়াদী সমাধানের কথা ভাবার সময় এটি অন্তত রক্তক্ষরণ বন্ধ করবে।
দিনে দুইবারের সুইপ: অনবরত নোটিফিকেশন চেক করার বদলে, সেগুলোকে দুটি সুইপে ভাগ করে নাও – একবার সকাল মাঝামাঝি, আরেকবার বিকেল মাঝামাঝি। প্রতিটি সুইপের সময়, তোমার GitHub নোটিফিকেশন, Linear ইনবক্স, এবং Slack-এর আনরিড মেসেজ স্ক্যান করো এবং তিনটি বাকেটে সাজাও:
| বাকেট | নিয়ম | অ্যাকশন | |--------|------|--------| | এখনই করো | কেউ ব্লক হয়ে আছে, কিছু ভেঙে গেছে, অথবা কোনো সিদ্ধান্তে তোমাকে এখনই দরকার | সাথে সাথে হ্যান্ডেল করো | | ব্যাচ | গুরুত্বপূর্ণ কিন্তু সময়ের তাড়া নেই | "পরে রেসপন্স করবো" লিস্টে দাও, দিনশেষে হ্যান্ডেল করো | | আর্কাইভ | বটের চ্যাটার, স্ট্যাটাস আপডেট, সলভ হয়ে যাওয়া থ্রেড, ডুপ্লিকেট | রিড মার্ক করো, নিজের কাজে মন দাও |
Slack-এ চ্যানেল-লেভেল ডিফল্ট সেট করো: প্রতিটি চ্যানেলের জন্য ঠিক করো: এটি কি "এখনই করো" চ্যানেল (তোমার টিমের ওয়ার্কিং চ্যানেল, ইনসিডেন্ট চ্যানেল) নাকি "ব্যাচ" চ্যানেল (জেনারেল অ্যানাউন্সমেন্ট, ক্রস-টিম আপডেট)? ব্যাচ চ্যানেলগুলো মিউট করো এবং শুধু সুইপের সময় চেক করো। হ্যাঁ, টেকনিক্যালি এটিও মিউট করা, যাকে আমি মাত্র কয়েক প্যারা আগেই ব্যঙ্গ করেছি – তবে পার্থক্য হলো তুমি এগুলোকে পুরোপুরি ইগনোর না করে একটি নির্দিষ্ট শিডিউলে চেক করছো।
GitHub-এর নোটিফিকেশন ফিল্টার ব্যবহার করো: বুকমার্ক করে রাখো github.com/notifications?query=reason:review-requested – ওই URL শুধু সেই PR রিভিউগুলো দেখায় যেগুলো সরাসরি তোমাকে অ্যাসাইন করা হয়েছে, সাবস্ক্রাইবড/CI নয়েজ একেবারে বাদ দিয়ে। ইমেইলের ক্ষেত্রে, GitHub একটি রিজন হেডার (review_requested, mention, subscribed, ci_activity) ইনক্লুড করে যা দিয়ে ফিল্টার করা যায়: "subscribed" এবং "ci_activity" অটো-আর্কাইভ করে দাও, তাহলে দরকারি কিছুই হারাবে না। GitHub যে এই দরকারি মেটাডেটা নোটিফিকেশন UI-তে না দেখিয়ে ইমেইল হেডারে লুকিয়ে রাখে, তা থেকেই বোঝা যায় এই সিস্টেমগুলোর কনজাম্পশন সাইডে কতটা কম চিন্তা করা হয়েছে।
এই অ্যাপ্রোচ কনটেক্সচুয়াল সিগন্যাল ধরতে পারবে না (সেই Figma কমেন্টের কথা মনে আছে যা আমার PR ডুবিয়েছিল? দিনে দুইবারের সুইপও সেটা ধরতে পারতো না)। কিন্তু এটি নয়েজ ৬০ থেকে ৭০ শতাংশ কমিয়ে দেবে, যা compulsive alt-tab থামানোর জন্য যথেষ্ট, যতক্ষণ না তুমি ঠিক করছো সমস্যাটির একটি আসল সমাধান দরকার কি না।
একটি ডিডুপ্লিকেশন লেয়ারের আসলে কী করা দরকার
এখান থেকেই আর্কিটেকচারালি বিষয়টি মজার হয়ে ওঠে – আর ঠিক এখানেই আমি এটিকে নোটিফিকেশন সেটিংসের সমস্যা না ভেবে একটি ক্লাসিফিকেশন সমস্যা হিসেবে ভাবতে শুরু করি।
সবচেয়ে সাধারণ অ্যাপ্রোচ হলো কিওয়ার্ড ম্যাচিং এবং মেনশন ডিটেকশন। তোমার নাম থাকলে সামনে আনো। তোমাকে অ্যাসাইন করা রিভিউ রিকোয়েস্ট হলে সামনে আনো। এটি সাধারণ কেসগুলো ধরতে পারলেও কনটেক্সচুয়াল ব্যাপারগুলো পুরোপুরি মিস করে – যেমন এমন থ্রেডে ডিজাইন ডিসিশন যেখানে কেউ তোমাকে @-মেনশন করেনি কারণ তারা বুঝতেই পারেনি তুমি ওই কম্পোনেন্টটি বানাচ্ছো। (এই ব্যাপারটা আমাকে বেশ কিছুদিন ভোগাবে।)
তোমার আসলে যেটা দরকার তা হলো সম্পর্কের একটি গ্রাফ: কোন টাস্কগুলো তোমার, কোন PR কোন ইস্যুর সাথে জড়িত, কোন Slack থ্রেড কোন ফিচার নিয়ে, কোন টপিকে সাধারণত তোমার মতামত প্রয়োজন হয়। নতুন সিগন্যাল এলে – Slack মেসেজ, GitHub ইভেন্ট, Linear ট্রানজিশন – সেটিকে ওই গ্রাফের সাপেক্ষে ক্লাসিফাই করতে হবে। "এটি কি Chris-কে মেনশন করছে?" সেটা না দেখে বরং "এটি কি এমন কিছুকে প্রভাবিত করছে যা নিয়ে Chris এই মুহূর্তে কাজ করছে, অপেক্ষায় আছে বা যার জন্য সে দায়ী?"
ক্লাসিফিকেশনটিকে এমন কিছু ভাগে ভাগ করতে হবে:
| ক্লাসিফিকেশন | এর মানে কী | অ্যাকশন | |---------------|---------------|--------| | জরুরি | কেউ তোমার জন্য আটকে আছে, অথবা কিছু ভেঙে গেছে | সাথে সাথে সামনে আনো | | গুরুত্বপূর্ণ | তোমার বর্তমান কাজকে প্রভাবিত করে, কিন্তু সময়ের দিক থেকে ক্রিটিক্যাল নয় | ডেইলি ডাইজেস্ট হিসেবে ব্যাচ করো | | তথ্যমূলক | জেনে রাখা ভালো, অ্যাকশনের দরকার নেই | তুমি খুঁজলে যেন পাওয়া যায় | | নয়েজ | ডুপ্লিকেট, বটের চ্যাটার, সলভ হওয়া থ্রেড | পুরোপুরি ফিল্টার করে বাদ দাও |
কঠিন ব্যাপারটা হলো ক্লাসিফিকেশন কনফিডেন্স বাইনারি হয় না। তুমি কখনো ভিজিট করো না এমন চ্যানেলের Slack মেসেজও জরুরি হতে পারে যদি সেটি তোমাকে অ্যাসাইন করা ইস্যুর রেফারেন্স দেয়। মাসের পর মাস না ছোঁয়া রেপোর GitHub নোটিফিকেশনও গুরুত্বপূর্ণ হতে পারে যদি কেউ এমন বাগ রি-ওপেন করে যা তুমি ফিক্সড ভেবেছিলে। তাই দুটি লেয়ার একসাথে কাজ করা দরকার: একটি ইভেন্ট নরমালাইজেশন লেয়ার যা প্রতিটি ইনকামিং ওয়েবহুককে কম্পোজিট কী দিয়ে হ্যাশ করে – রেপো, ইস্যু আইডি, অ্যাক্টর, ইভেন্ট টাইপ – এবং TTL-যুক্ত ডিডুপ উইন্ডোর (রিসেন্ট ইভেন্ট ফিঙ্গারপ্রিন্টের স্লাইডিং উইন্ডো) সাথে চেক করে। এর পেছনে থাকবে লাইভ রিলেশনশিপ গ্রাফ, যা টাস্ক ওনারশিপ, PR লিংকেজ, থ্রেড পার্টিসিপেন্ট, এবং রিসেন্ট অ্যাক্টিভিটি প্যাটার্ন ম্যাপ করবে। তুমি মূলত পুরো টিমের ওয়ার্কিং স্টেটের একটি রিড মডেল তৈরি করছো, যা প্রায় রিয়েল-টাইমে আপডেট হয় এবং প্রতিটি ইনবাউন্ড সিগন্যালে কোয়েরি করা হয়। ডিডুপ লেয়ার স্পষ্ট ডুপ্লিকেটগুলো ধরে। গ্রাফটি কঠিন প্রশ্নের উত্তর দেয়: "এটি কি এই মুহূর্তে, নির্দিষ্টভাবে তোমার জন্য প্রাসঙ্গিক?"
কোর ক্লাসিফিকেশন লুপ পরিষ্কার কেসগুলো ভালোভাবে হ্যান্ডেল করে, এবং শুধু এটুকুতেই নয়েজ অনেকাংশে কমে – কিন্তু সত্যিকারের অস্পষ্ট সিগন্যালগুলো (যেখানে বাদ দেওয়ার জন্য যথেষ্ট কনফিডেন্ট নও আবার সামনে আনার জন্যও যথেষ্ট কনফিডেন্ট নও) এখনো একটি ওপেন সমস্যা। আমরা এগুলোকে একটি "হয়তো" ডাইজেস্টে ব্যাচ করার এক্সপেরিমেন্ট করছি, কিন্তু আমি এমন ভান করবো না যে আমরা এর নিখুঁত সমাধান বের করে ফেলেছি।
ফায়ারহোজ বন্ধ হলে কী বদলায়
যেটা আমি আশা করিনি – আমি সত্যিই ভেবেছিলাম সুবিধা হবে শুধু "কম পিং" – তা হলো তোমার টুলগুলো চিৎকার থামালে এদের সাথে তোমার সম্পর্কটা কতটা গভীরভাবে বদলে যায়।
যখন প্রতিটি নোটিফিকেশনই গুরুত্বপূর্ণ হতে পারে, আনরিড কাউন্ট নিয়ে একটা ধীর মাত্রার উদ্বেগ তৈরি হয়। বোল্ড চ্যানেল নামসহ Slack সাইডবার। GitHub-এর বেল আইকন। Linear ইনবক্স। তুমি বাধ্য হয়ে বারবার চেক করো, জরুরি কিছু আশা করে না, বরং কিছু মিস করার ভয়টা ৫০টা নয়েজ চেক করার কষ্টের চেয়ে বেশি মনে হয় বলে। আমি ফাংশন সিগনেচার আর বডি লেখার মাঝখানে Slack-এ alt-tab করতাম। সচেতন সিদ্ধান্ত ছিল না – শুধুই একটা রিফ্লেক্স, ট্রাফিক সিগন্যালে আয়না দেখার মতো।
এই preemptive self-interruption অনেক সময় নোটিফিকেশনের চেয়েও খারাপ, কারণ পিং আসার আগেই তুমি নিজের মনোযোগ ভাঙছো। তুমি permanent partial attention-এ থাকো, আর কোডে সেটা দেখা যায় – অগভীর রিভিউ, অতিরিক্ত নিরাপদ আর্কিটেকচারাল পছন্দ, যেটা আসলে সঠিক সেই অ্যাপ্রোচের বদলে সবচেয়ে কম ঝামেলার পথ বেছে নেওয়া, কারণ তোমার বিশ্বাসটাই থাকে না যে ব্যাঘাত ছাড়া একটানা ৪৫ মিনিট চিন্তা করার সুযোগ পাবে।
ফায়ারহোজ বন্ধ হলে – যখন তুমি বিশ্বাস করতে পারো গুরুত্বপূর্ণ সিগন্যাল তোমাকে খুঁজে নেবে আর নয়েজ আসবে না – সেই রিফ্লেক্স ধীরে ধীরে ম্লান হতে থাকে। সাথে সাথে না, পুরোনো অভ্যাস শক্ত। কিন্তু কয়েক সপ্তাহের মধ্যে দেখবে এডিটরে অনেক বড় uninterrupted stretch পাচ্ছো, compulsive alt-tab ছাড়া। চিন্তা শেষ করতে পারছো। ভালো কোড লিখছো, হঠাৎ স্মার্ট হয়ে যাওয়ার কারণে না, বরং নোটিফিকেশন সিস্টেমের হয়ে ঘণ্টায় ৩০টা কনটেক্সট সুইচিং স্বেচ্ছায় নেওয়া বন্ধ করেছো বলে।
cutting through inbox and channel noise notification fatigue the Slack notification strategy for busy teams নোটিফিকেশনের সাগরে ডুবে থেকো না। Sugarbug প্রাসঙ্গিকতার ভিত্তিতে Linear, GitHub এবং Slack থেকে আসা প্রতিটি সিগন্যালকে ক্লাসিফাই করে – এবং শুধু সেগুলোই সামনে আনে যেগুলোতে সত্যিই তোমাকে দরকার।
প্র: Sugarbug কি Linear, GitHub, এবং Slack-এর অতিরিক্ত নোটিফিকেশন কমাতে পারে? উ: হ্যাঁ। Sugarbug API-এর মাধ্যমে Linear, GitHub, এবং Slack-এর সাথে কানেক্ট করে এবং প্রতিটি সিগন্যালকে তার জরুরিতা ও প্রাসঙ্গিকতার ভিত্তিতে ক্লাসিফাই করে। সব নোটিফিকেশন ফরওয়ার্ড করার বদলে, এটি শুধু সেগুলোই সামনে আনে যেগুলোতে সত্যিই তোমার মনোযোগ দরকার – সাধারণত শত শত দৈনিক পিং কমে গিয়ে হাতে গোনা কয়েকটায় দাঁড়ায়।
প্র: আমি এখন যা কাজ করছি, তার ভিত্তিতে Sugarbug কি GitHub PR নোটিফিকেশন প্রায়োরিটাইজ করতে পারে? উ: Sugarbug তোমার টাস্ক, PR এবং কনভার্সেশনের একটি নলেজ গ্রাফ তৈরি করে। কোন PR তোমার বর্তমান কাজের সাথে সম্পর্কিত সেটা বুঝে আগে রিভিউ রিকোয়েস্ট, মার্জ কনফ্লিক্ট এবং CI ফেইলিওর সামনে আনে – আর বাকিগুলো নীরবে সরিয়ে রাখে।
প্র: Slack-এর বিল্ট-ইন নোটিফিকেশন সেটিংস থেকে Sugarbug আলাদা কীভাবে? উ: Slack-এর সেটিংস দিয়ে তুমি চ্যানেল মিউট করতে বা কিওয়ার্ড সেট করতে পারো, কিন্তু সেগুলো বিভিন্ন টুলের মধ্যে কনটেক্সট বুঝতে পারে না। Sugarbug একসাথে Linear, GitHub, এবং Slack-এর ডেটা পড়ে, তাই এটি জানে যে তোমার লেখা একটি PR সম্পর্কিত Slack থ্রেডটি জরুরি, এমনকি সেটি যদি তোমার মিউট করা কোনো চ্যানেলেও থাকে।
প্র: ইঞ্জিনিয়ারিং টিমের জন্য নোটিফিকেশন ওভারলোডের আসল খরচটা কী? উ: UC Irvine-এ Gloria Mark-এর গবেষণা বলছে যে, একবার কাজে ব্যাঘাত ঘটলে আবার গভীর মনোযোগ ফিরিয়ে আনতে প্রায় ২৩ মিনিট সময় লাগে। শুধু পিংগুলোর বাইরেও, বারবার নোটিফিকেশন চেক করার এই অভ্যাসটি জটিল ইঞ্জিনিয়ারিং কাজের জন্য প্রয়োজনীয় দীর্ঘস্থায়ী মনোযোগকে ভেঙে দেয়।
যদি তোমার ইঞ্জিনিয়ারিং টিমের নোটিফিকেশনগুলো "আপডেট রাখা" থেকে "উদ্বিগ্ন রাখা"-র দিকে চলে যায়, তাহলে সেটা সম্ভবত তোমার নোটিফিকেশন প্রেফারেন্স নয়, বরং আর্কিটেকচার ফিক্স করার সিগন্যাল।