Linear, GitHub, Slack: 200 Notifikasi – Bagaimana Jika 5?
Notifikasi Linear, GitHub, dan Slack membanjiri tim engineering Anda? Analisis mengapa arsitekturnya bermasalah – dan 5 sinyal yang benar-benar penting.
By Ellis Keane · 2026-03-13
Masalahnya bukan karena Anda menerima terlalu banyak notifikasi. Masalahnya adalah Anda menerima jumlah yang tepat – dari tiga alat berbeda, tentang peristiwa yang sama, pada saat yang sama.
Setiap webhook dipicu dengan benar. Setiap integrasi menghadirkan persis apa yang dijanjikannya. GitHub memberi tahu Anda tentang PR. Linear memberi tahu Anda tentang isu yang ditutup oleh PR. Slack memberi tahu Anda karena seseorang, pada suatu waktu (mungkin Anda, tiga bulan lalu, dalam gelombang optimisme yang salah arah tentang "visibilitas"), menghubungkan bot ke saluran proyek. Tiga alat, tiga notifikasi, satu peristiwa, dan semuanya bekerja persis seperti yang dirancang. Engineeringnya sempurna. Pengalamannya menyedihkan.
Notifikasi Linear, GitHub, dan Slack Anda tidak membanjiri karena ada yang rusak. Mereka membanjiri karena tidak ada yang rusak. Setiap alat dengan setia menjalankan kontrak notifikasinya tanpa kesadaran bahwa alat lain ada. Tidak ada bus acara bersama. Tidak ada lapisan deduplikasi. Tidak ada konsep di mana pun dalam tumpukan bahwa "manusia ini sudah mengetahui hal ini." Anda tidak menderita karena konfigurasi yang salah. Anda menderita karena titik akhir logis dari menghubungkan enam alat ke dalam alur kerja yang sama dan membiarkan masing-masing berteriak secara independen ke dalam kekosongan.
"Sistem notifikasi tidak gagal. Sistem ini begitu berhasil sehingga mengubur Anda." – Chris Calo
Kemajuan.
Anatomi satu merge – autopsi duplikasi
Mari saya pandu Anda melalui satu peristiwa – satu merge PR – dan lacak apa yang terjadi di lapisan notifikasi. Bukan karena itu tidak biasa, tetapi karena itu sangat biasa dan menyedihkan.
Seorang rekan tim melakukan merge PR di GitHub. Berikut kaskadenya:
- GitHub menembakkan webhook ke kotak masuk notifikasi Anda. Anda menulis ulasan pada PR ini, jadi Anda berlangganan. Itu adalah notifikasi pertama.
- Integrasi GitHub Linear mendeteksi isu yang tertaut dan secara otomatis mengubah statusnya dari "Sedang Berjalan" menjadi "Selesai." Linear menghasilkan notifikasi untuk semua orang yang memantau isu tersebut – termasuk Anda, karena Anda berada di tim yang sama. Itu adalah notifikasi kedua.
- Bot Slack (yang Anda hubungkan dalam gelombang optimisme yang saya sebutkan) memposting ringkasan merge ke #frontend. Jika seseorang bereaksi terhadap pesan itu dengan emoji atau komentar, Slack menghasilkan notifikasi utas. Itu adalah notifikasi ketiga, berpotensi keempat.
- CI berjalan pada commit merge. GitHub menembakkan webhook lain. Jika CI berhasil, Anda mungkin tidak peduli, tetapi Anda tetap mendapatkan notifikasi karena model langganan GitHub bersifat biner – Anda memantau atau tidak. Itu adalah notifikasi kelima.
Lima notifikasi. Satu peristiwa. Dan Anda ada di panggilan tempat merge dibahas, jadi Anda sudah mengetahuinya sebelum salah satu dari mereka tiba.
Kalikan ini dengan setiap PR, setiap transisi isu, dan setiap jalannya CI untuk tim enam orang, dan Anda melihat 30 hingga 40 peristiwa duplikat per orang per hari sebelum menghitung sinyal yang benar-benar baru. Sistem notifikasi tidak gagal. Sistem ini begitu berhasil sehingga mengubur Anda.
Mengapa membisukan hanyalah tambalan di atas pendarahan
Saran standarnya adalah membisukan secara agresif. Matikan notifikasi email GitHub. Atur Slack agar hanya memberi tahu pada penyebutan langsung. Berhenti mengikuti semua isu Linear kecuali yang ditugaskan kepada Anda. Ini adalah ekuivalen notifikasi dari mengobati pergelangan tangan yang patah dengan melepas jam tangan Anda – secara teknis Anda telah mengurangi kompleksitas terkait pergelangan tangan, tetapi Anda juga kehilangan kemampuan untuk mengetahui waktu.
Saya mencoba pendekatan membisukan (tentu saja – kita semua melakukannya, itu adalah hal pertama yang semua orang coba, tepat sebelum hal kedua yang semua orang coba, yaitu rantai Zapier yang entah bagaimana memperburuknya). Saya agresif: menonaktifkan email GitHub sepenuhnya, membisukan setiap saluran Slack yang bukan saluran kerja tim saya, berhenti mengikuti semua hal di Linear kecuali isu saya sendiri. Ketenangan selama sekitar tiga hari.
Kemudian saya melewatkan dua ulasan PR yang memblokir karena diskusi terjadi di saluran yang telah saya bisukan. Para engineer yang membutuhkan ulasan saya akhirnya mengirim DM kepada saya – yang hanyalah notifikasi dengan langkah ekstra dan sentuhan energi pasif-agresif "hei, apa kamu melihat pesanku?". Seminggu kemudian, keputusan desain mendarat di utas komentar Figma yang sepenuhnya mengubah komponen yang sedang saya bangun setengahnya, dan saya tidak mengetahuinya sampai PR saya ditolak. Yang menyenangkan.
Masalah mendasar dengan membisukan adalah bahwa itu menerapkan aturan statis pada konteks yang dinamis. Pengaturan notifikasi Anda dari Selasa lalu tidak tahu tentang bug mendesak yang muncul pagi ini. Dan semakin agresif Anda membisukan, semakin lebar celah dalam kesadaran Anda – celah yang diisi rekan tim dengan DM "hanya memastikan Anda melihat...". Yang, jika Anda menghitung skor, berarti membisukan secara agresif tidak mengurangi notifikasi Anda. Ini hanya menggesernya dari bot (yang tidak menghakimi Anda) ke manusia (yang pasti melakukannya).
Lima sinyal yang benar-benar memerlukan interupsi
Setelah mencatat notifikasi selama beberapa minggu (dalam file teks biasa, karena saya persis tipe orang yang Anda harapkan menulis artikel tentang arsitektur notifikasi), sebuah pola muncul. Dari sekitar 200 ping harian, yang benar-benar memerlukan tindakan dalam satu jam jatuh ke dalam lima kategori:
- Seseorang diblokir oleh Anda. Permintaan ulasan PR pada kode yang Anda miliki, pertanyaan yang hanya bisa Anda jawab, keputusan yang menunggu masukan Anda. Ini adalah satu-satunya kategori di mana penundaan memiliki biaya yang berlipat – setiap jam Anda tidak merespons adalah satu jam orang lain tidak bisa bekerja.
- Sesuatu yang Anda deploy rusak. Kegagalan CI pada cabang Anda, lonjakan kesalahan setelah merge Anda, permintaan revert. Kategori "kode Anda sedang terbakar."
- Keputusan dibuat yang mempengaruhi pekerjaan Anda saat ini. Perubahan desain, pembaruan kontrak API, pergeseran prioritas dari sisi produk. Ini jarang tetapi mahal untuk dilewatkan (lihat: PR saya yang ditolak, di atas).
- Tenggat waktu bergeser. Cakupan sprint berubah, demo dimajukan, dependensi meleset. Peristiwa yang mengubah kalender.
- Seseorang membutuhkan bantuan dan Anda adalah orang yang tepat. Bukan setiap @channel. Bukan setiap @here. Yang spesifik di mana keahlian Anda benar-benar relevan – dan bahkan kemudian, hanya jika tidak ada orang lain yang bisa menjawab.
Semua hal lainnya – transisi status, pesan bot otomatis, reaksi emoji "terdengar bagus", CI yang berhasil di cabang yang tidak Anda pantau – adalah informasi yang mungkin berguna pada akhirnya tetapi tidak perlu menginterupsi fungsi yang sedang Anda tulis. Kompleks industri notifikasi telah meyakinkan kita bahwa semua ini layak mendapat urgensi yang sama. Mereka tidak.
Dari 200 notifikasi harian, sekitar lima kategori benar-benar memerlukan interupsi dari apa yang Anda lakukan. Sisanya adalah informasi yang mungkin berguna pada akhirnya – tetapi alat memperlakukan semuanya dengan urgensi yang sama, yang berarti tidak ada yang benar-benar urgen.
Kerangka triase untuk yang dikhianati secara arsitektural
Berikut adalah kerangka yang dapat Anda mulai gunakan hari ini – tidak perlu alat, hanya disiplin dan sekitar 20 menit pengaturan. Ini tidak akan memperbaiki masalah arsitektural (tidak ada yang kurang dari lapisan deduplikasi yang dapat melakukan itu), tetapi ini akan menghentikan pendarahan sementara Anda mengevaluasi solusi jangka panjang.
Sapuan dua kali sehari: Alih-alih memeriksa notifikasi terus-menerus, kelompokkan menjadi dua sapuan – sekali pertengahan pagi, sekali pertengahan sore. Selama setiap sapuan, pindai notifikasi GitHub Anda, kotak masuk Linear, dan pesan Slack yang belum dibaca, dan urutkan masing-masing ke dalam satu dari tiga ember:
| Ember | Aturan | Tindakan | |-------|--------|----------| | Bertindak sekarang | Seseorang diblokir, sesuatu rusak, atau keputusan memerlukan Anda | Tangani segera | | Kelompokkan | Penting tapi tidak mendesak dari sisi waktu | Tambahkan ke daftar "balas nanti", tangani di akhir hari | | Arsipkan | Obrolan bot, pembaruan status, utas yang diselesaikan, duplikat | Tandai sudah dibaca, lanjutkan |
Tetapkan default tingkat saluran di Slack: Untuk setiap saluran, putuskan: apakah ini saluran "bertindak sekarang" (saluran kerja tim Anda, saluran insiden) atau saluran "kelompokkan" (pengumuman umum, pembaruan lintas tim)? Bisukan saluran kelompok dan hanya periksa selama sapuan Anda. Ya, ini secara teknis adalah membisukan, yang baru saja saya ejek selama dua paragraf – perbedaannya adalah Anda masih memeriksanya sesuai jadwal daripada berpura-pura mereka tidak ada.
Gunakan filter notifikasi GitHub: Tandai github.com/notifications?query=reason:review-requested – URL tersebut hanya menampilkan ulasan PR yang secara eksplisit ditugaskan kepada Anda, menghilangkan kebisingan langganan/CI sepenuhnya. Untuk email, GitHub menyertakan header alasan (review_requested, mention, subscribed, ci_activity) yang dapat Anda filter: arsipkan otomatis "subscribed" dan "ci_activity" dan Anda tidak akan kehilangan apa pun yang benar-benar Anda butuhkan. Fakta bahwa GitHub mengubur metadata berguna ini di header email daripada mengeksposnya di UI notifikasi memberi tahu Anda segalanya tentang seberapa banyak pemikiran yang masuk ke sisi konsumsi sistem ini.
Pendekatan ini tidak akan menangkap sinyal kontekstual (ingat komentar Figma yang menenggelamkan PR saya? Sapuan dua kali sehari juga tidak akan menangkapnya). Tapi ini akan memotong kebisingan sebesar 60 hingga 70 persen, yang cukup untuk menghentikan alt-tab kompulsif saat Anda mengevaluasi apakah masalahnya memerlukan solusi nyata.
Apa yang sebenarnya perlu dilakukan lapisan deduplikasi
Di sinilah ini menjadi menarik secara arsitektural – dan di mana saya berhenti memikirkan ini sebagai masalah pengaturan notifikasi dan mulai memikirkannya sebagai masalah klasifikasi.
Pendekatan naif adalah pencocokan kata kunci dan deteksi penyebutan. Jika nama Anda muncul, tampilkan. Jika itu adalah permintaan ulasan yang ditugaskan kepada Anda, tampilkan. Ini menangkap kasus yang jelas tetapi sepenuhnya melewatkan yang kontekstual – keputusan desain dalam utas di mana tidak ada yang @menyebut Anda karena mereka tidak menyadari Anda sedang membangun komponen yang terpengaruh. (Yang satu itu akan menghantui saya untuk sementara waktu.)
Yang sebenarnya Anda butuhkan adalah grafik hubungan: tugas mana yang milik Anda, PR mana yang terkait dengan isu mana, utas Slack mana yang tentang fitur mana, orang mana yang cenderung membutuhkan masukan Anda tentang topik apa. Ketika sinyal baru tiba – pesan Slack, peristiwa GitHub, transisi Linear – Anda mengklasifikasikannya terhadap grafik tersebut. Bukan "apakah ini menyebutkan nama Chris?" tetapi "apakah ini mempengaruhi sesuatu yang sedang dikerjakan Chris, yang sedang ditunggu Chris, atau yang menjadi tanggung jawab Chris?"
Klasifikasi perlu dipecah menjadi sesuatu seperti ini:
| Klasifikasi | Artinya | Tindakan | |-------------|---------|----------| | Mendesak | Anda memblokir seseorang, atau ada yang rusak | Tampilkan segera | | Penting | Mempengaruhi pekerjaan Anda saat ini, tapi tidak kritis dari sisi waktu | Kelompokkan dalam ringkasan harian | | Informatif | Baik untuk diketahui, tidak perlu tindakan | Tersedia jika Anda mencarinya | | Kebisingan | Duplikat, obrolan bot, utas yang diselesaikan | Difilter sepenuhnya |
Bagian sulitnya adalah kepercayaan klasifikasi tidak bersifat biner. Pesan Slack di saluran yang tidak pernah Anda kunjungi mungkin masih mendesak jika merujuk pada isu yang ditugaskan kepada Anda. Notifikasi GitHub tentang repositori yang belum Anda sentuh selama berbulan-bulan mungkin penting jika seseorang baru saja membuka kembali bug yang Anda pikir sudah diperbaiki. Anda membutuhkan dua lapisan yang bekerja secara harmonis: lapisan normalisasi peristiwa yang melakukan hash setiap webhook masuk terhadap kunci komposit – repositori, ID isu, aktor, jenis peristiwa – dan memeriksanya terhadap jendela dedup ber-TTL (pada dasarnya jendela geser dari sidik jari peristiwa terkini), dan di belakangnya, grafik hubungan langsung yang memetakan kepemilikan tugas, tautan PR, peserta utas, dan pola aktivitas terkini. Pada dasarnya Anda membangun model baca dari seluruh status kerja tim, diperbarui hampir secara real-time, dan mengkuerinya di setiap sinyal yang masuk. Lapisan dedup menangkap duplikat yang jelas. Grafik menjawab pertanyaan yang lebih sulit: "apakah ini relevan secara khusus untuk Anda, sekarang?"
Loop klasifikasi inti menangani kasus yang jelas dengan baik, dan itu saja sudah mengurangi kebisingan secara substansial – tetapi sinyal yang benar-benar ambigu (di mana Anda tidak cukup yakin untuk menekan tetapi juga tidak cukup yakin untuk menampilkan) masih merupakan masalah terbuka. Kami bereksperimen dengan mengelompokkan mereka ke dalam ringkasan "mungkin", tapi saya tidak akan berpura-pura kami sudah menyelesaikannya.
Apa yang berubah ketika banjir berhenti
Yang tidak saya perkirakan – saya benar-benar berpikir manfaatnya hanya "ping lebih sedikit" – adalah betapa profundnya hubungan Anda dengan alat berubah ketika mereka berhenti berteriak kepada Anda.
Ketika setiap notifikasi mungkin penting, Anda mengembangkan kecemasan ringan tentang jumlah yang belum dibaca. Bilah sisi Slack dengan nama salurannya yang tebal. Lonceng GitHub. Kotak masuk Linear. Anda memeriksa secara kompulsif, bukan karena Anda mengharapkan sesuatu yang mendesak, tetapi karena biaya melewatkan sesuatu terasa lebih tinggi dari biaya memeriksa 50 hal yang ternyata adalah kebisingan. Saya dulu alt-tab ke Slack di antara menulis tanda tangan fungsi dan isinya. Bukan keputusan sadar – hanya refleks, seperti Anda memeriksa spion saat lampu merah.
Interupsi diri preemptif mungkin lebih buruk dari notifikasi itu sendiri, karena Anda memecah konsentrasi Anda sendiri sebelum ping pun tiba. Anda hidup dalam kondisi perhatian sebagian yang permanen, dan Anda merasakannya dalam kode yang Anda tulis – ulasan yang lebih dangkal, pilihan arsitektural yang lebih aman, jalur dengan hambatan minimum alih-alih pendekatan yang sebenarnya tepat, karena Anda tidak percaya bahwa Anda akan mendapat 45 menit tanpa gangguan untuk memikirkannya.
Ketika banjir berhenti – ketika Anda percaya bahwa sinyal penting akan menemukan Anda dan kebisingan tidak akan – refleks itu memudar. Tidak segera, karena kebiasaan lama sulit dihilangkan. Tapi dalam beberapa minggu Anda menyadari bahwa Anda menghabiskan waktu lebih lama di editor Anda tanpa alt-tab kompulsif. Anda mulai menyelesaikan pikiran. Anda menulis kode yang lebih baik, bukan karena Anda tiba-tiba menjadi lebih cerdas, tetapi karena Anda berhenti secara sukarela untuk 30 peralihan konteks per jam atas nama sistem notifikasi yang tidak pernah meminta Anda melakukannya.
Berhenti tenggelam dalam notifikasi. Sugarbug mengklasifikasikan setiap sinyal dari Linear, GitHub, dan Slack berdasarkan relevansi – dan hanya menampilkan apa yang benar-benar membutuhkan Anda.
Q: Apakah Sugarbug mengurangi notifikasi yang berlebihan dari Linear, GitHub, dan Slack? A: Ya. Sugarbug terhubung ke Linear, GitHub, dan Slack melalui API dan mengklasifikasikan setiap sinyal berdasarkan urgensi dan relevansi. Alih-alih meneruskan setiap notifikasi, Sugarbug hanya menampilkan yang memerlukan perhatian Anda – biasanya mengurangi ratusan ping harian menjadi segelintir yang benar-benar membutuhkan Anda.
Q: Bisakah Sugarbug memprioritaskan notifikasi PR GitHub berdasarkan apa yang sedang saya kerjakan? A: Sugarbug membangun grafik pengetahuan dari tugas, PR, dan percakapan Anda. Sugarbug mengetahui PR mana yang terkait dengan pekerjaan Anda saat ini dan menampilkan permintaan ulasan, konflik merge, dan kegagalan CI untuk PR tersebut terlebih dahulu – sambil diam-diam mengarsipkan sisanya.
Q: Apa perbedaan Sugarbug dengan pengaturan notifikasi bawaan Slack? A: Pengaturan Slack memungkinkan Anda membisukan saluran atau menetapkan kata kunci, tetapi tidak dapat memahami konteks lintas alat. Sugarbug membaca Linear, GitHub, dan Slack secara bersamaan, sehingga mengetahui bahwa utas Slack tentang PR yang Anda tulis bersifat mendesak meskipun berada di saluran yang telah Anda bisukan.
Q: Apa biaya nyata dari kelebihan notifikasi bagi tim engineering? A: Penelitian Gloria Mark di UC Irvine menyarankan bahwa dibutuhkan sekitar 23 menit untuk mendapatkan kembali fokus mendalam setelah gangguan. Di luar ping itu sendiri, perilaku pemeriksaan kompulsif yang mereka ciptakan memecah konsentrasi berkelanjutan yang dibutuhkan oleh pekerjaan engineering yang kompleks.
Jika notifikasi tim engineering Anda telah melewati batas dari "tetap terinformasi" menjadi "tetap cemas," itu mungkin merupakan tanda bahwa arsitekturnya perlu diperbaiki, bukan preferensi notifikasi Anda.