Claude Skills — новый подход, где LLM использует специальные файлы-инструкции для решения задач. Например, Anthropic предоставляет шаблон для создания гифок под Slack: в нём есть код для проверки размера файла, валидации и даже пример готового GIF. Это позволяет Клоду генерировать контент, который сразу проходит модерацию платформы.

Особенность в том, что система работает без предварительного обучения модели на конкретных данных. Вместо этого, все инструкции и валидаторы загружаются динамически, в момент решения задачи. Это экономит ресурсы и позволяет гибко адаптироваться к новым задачам без переобучения модели.

По сути, Claude Skills — это шаблон для создания инструментов, которые LLM может использовать "по требованию". Это открывает путь к генерации не только медиа, но и документов, баз данных и даже ПО через подобные шаблоны. Уже сейчас есть навыки для работы с Excel, Word и PowerPoint, что делает систему универсальным ассистентом для автоматизации рутинных задач.

• Существуетение, что MCP и "skills" — это просто переименование уже существующих концептов: MCP — это стандартизированный способ подключения внешних сервисов, а skills — это просто контекст под рукой.
• Участники обсуждения отмечают, что большинство MCP-серверов бесполезны и могут быть заменены простым вызовом CLI-утилит.
• Некоторые участники подчеркивают, что Skills и MCP решают разные задачи: MCP — это про интеграцию внешних сервисов, а Skills — про управление контекстом.
• Участники также обсуждают, что Skills могут быть более удобны для конечного пользователя, так как они не требуют сложной настройки и могут быть созданы просто как текстовый файл.

Основанная на блоковых элементах, а не на документах, архитектура Notion позволяет каждому элементу контента быть гибко перестраиваемым, вкладываемым и превращаемым в базы данных или другие структуры. Это превращает Notion из простого редактора в операционную систему для работы, где все интегрировано. В отличие от этого, Google Docs остается в рамках устаревшей модели "документ как файл", что ограничивает его возможности. Notion's модель данных делает его более универсальным и адаптируемым, позволяя ему масштабироваться как платформа, а не просто как инструмент.

• Дискуссия вращается вокруг идеи, что победит не тот, кто предложит больше функций, а тот, кто заложит правильную модель данных, и что именно она определяет судьбу продукта.
• Участники обмениваются примерами: Slack vs. HipChat, Notion vs. Airtable, Google Docs vs. Microsoft Office, и обсуждают, как именно модель данных влияет на возможности и ограничения продукта.
• Обсуждается, что модель данных определяет, как продукт может развиваться и какие фичи можно будет добавлять, и какие нет.
• Участники также обсуждают, что выбор модели данных влияет на то, как продукт может масштабироваться и как он может эволюционировать.
• Также поднимается вопрос, что важнее: модель данных или умение ее реализовать, и как эти два фактора взаимодействуют.

Электронная почта превосходит мессенджеры благодаря универсальности и контролю над данными. Все сообщения приходят в единый интерфейс, где их можно сортировать, архивировать и искать — в отличие от десятка разрозненных платформ вроде Slack или WhatsApp. Архив писем остаётся доступным десятилетиями, тогда как сервисы вроде ICQ или Google Hangouts исчезают, унося историю переписк. Локальное хранение в формате Mbox гарантирует долговечность и возможность обработки скриптами.

Функциональность клиентов вроде Thunderbird включает фильтры, отложенную отправку, тегирование и офлайн-работу, а открытые протоколы SMTP/IMAP дают свободу выбора программ. Электронная почта асинхронна, не отвлекает уведомлениями, защищает конфиденциальность и не содержит рекламы. Это продуктивная среда, где пользователь управляет данными, а не зависит от прихотей корпораций.

• Email предпочтительнее для асинхронного, вдумчивого общения с архивом и поиском, но не подходит для динамичных групповых дискуссий.
• Мессенджеры (Slack, Teams) популярны из-за удобства мгновенного общения, но страдают от отсутствия структуры и проблем с архивом.
• Проблемы email включают спам, сложные ветки обсуждений, ненадежную доставку и устаревшие клиенты.
• Предлагаются гибридные решения: улучшенные интерфейсы email, интеграция с мессенджерами или использование форумов.
• Важен выбор инструмента по ситуации: email для официальной переписки, чат — для оперативных вопросов.

Jules — это ИИ-агент для автоматизации разработки, который теперь предлагает API для интеграции в рабочие процессы. С его помощью можно автоматизировать создание задач, исправление багов и внедрение фич через инструменты вроде Slack, Linear или Jira, а также встраивать в CI/CD-пайплайны GitHub Actions. Например, можно отправить запрос на создание сессии через cURL, указав промпт и контекст репозитория.

Кроме API, в обновлениях появилась поддержка командной строки, веб-серфинг, тестирование веб-приложений с визуализацией результатов, работа с обратной связью из PR, загрузка изображений и увеличение размера VM до 20 ГБ. Агент стал быстрее и надёжнее, добавлена критика кода, интерактивное планирование и поддержка Bun.

• Перенос инфраструктуры на Railway и использование Jules для самостоятельного создания PR клиентом для мелких правок
• Критика Jules как продукта Google: фрагментация предложений, опасения по поводу закрытости и возможного прекращения поддержки
• Обсуждение различий между Jules, Claude Code, Copilot и другими агентами, их интеграций и безопасности
• Сравнение моделей использования: асинхронные агенты vs. интерактивные инструменты в IDE, вопросы доверия и ROI
• Критика антропоморфных названий продуктов и размышления о целесообразности разработки в личное время

Некоторые версии Electron на macOS вызывают системные лаги, особенно на Tahoe. Проблема решена в версиях 36.9.2, 37.6.0, 38.2.0, 39.0.0 и выше. Для обнаружения уязвимых приложений используется скрипт, который сканирует установленные программы и проверяет версии Electron Framework.

Временное решение — установка переменной окружения CHROME_HEADLESS=1 при запуске системы, что отключает тени окон Electron, устраняя лаги, но ухудшая визуальный вид. Среди популярных приложений с проблемными версиями: Visual Studio Code (37.3.1), Slack (38.1.2), DaVinci Resolve (36.3.2) и другие.

• Обсуждаются способы выявления Electron-приложений на Mac с устаревшими версиями фреймворка, вызывающими лаги системы, включая скрипты и инструменты для анализа.
• Участники отмечают, что многие популярные приложения (VS Code, Slack, Discord, Docker Desktop и др.) используют устаревшие версии Electron, что приводит к проблемам с производительностью после обновления macOS.
• Высказывается критика в адрес Apple за недостаточное тестирование ОС и в адрес Electron за отсутствие разделения рантайма и приложений, что затрудняет массовые обновления.
• Приводятся примеры конкретных приложений и их версий Electron, а также личный опыт удаления или отказа от обновления проблемного ПО.
• Обсуждаются технические детали бага Electron (проблема с перерисовкой тени) и тот факт, что команда Electron выпустила патч для предыдущих версий.

Автор предлагает отказаться от стандартной группировки Slack-каналов по темам (проекты, команды, соцактивности) в пользу сортировки по частоте чтения: «Читать сейчас», «Читать ежечасно», «Читать ежедневно» и «Читать когда угодно». Такой подход позволяет сразу фокусироваться на самых срочных сообщениях, снижая стресс и повышая продуктивность. Он ссылается на матрицу Эйзенхауэра, объясняя, как распределить каналы по важности и срочности.

Гибкость системы позволяет легко менять приоритеты каналов по мере изменения проектов или личной доступности. Автор отмечает, что тематическая группировка часто бессмысленна: например, канал офиса может требовать немедленного внимания (если там раздают кексы), а IT-поддержка — вообще не стоить времени. После месяца использования метода он достиг нуля непрочитанных сообщений и рекомендует попробовать этот подход.

• Пользователи обсуждают методы организации каналов в Slack по приоритетам (например, группы для инцидентов, команд, проектов) для управления вниманием.
• Высказывается недовольство ограниченностью настроек уведомлений: отсутствие батчинга, промежуточных вариантов между "полностью отключить" и "уведомлять обо всём".
• Предлагаются альтернативные подходы: использование вкладки "Unreads", сортировка каналов в боковой панели, отключение уведомлений и выборочная проверка.
• Некоторые пользователи сравнивают Slack с электронной почтой и другими инструментами (Teams, Zoom Chat), отмечая их преимущества для асинхронного общения.
• Обсуждается проблема информационного шума: большинство сообщений не требуют срочного внимания, что приводит к потере времени.

Большинство пользователей применяют лишь около 20% функций приложения, но у каждого — свой уникальный набор. Например, один копирует таблицы из Excel в Word, другой строит сводные таблицы, а третий вообще использует его для учёта расходов. Когда софт обрастает новыми возможностями, они часто мешают тем, кому важна конкретная узкая функциональность, — это создаёт пространство для нишевых продуктов.

Такие сервисы, как Kagi или Figma, успешно занимают эти лакуны, фокусируясь на идеальном решении задач определённой аудитории вместо погони за универсальностью. Стратегия Win — не пытаться угодить всем, а позволить пользователям через расширения и кастомизацию самим формировать свой идеальный 20%, как это делают VS Code или Slack. Ключ в гибкости, а не в нагромождении функций.

• Пользователи обычно используют лишь небольшую часть функционала приложения (около 20%), но у разных пользователей это разные 20%, что требует поддержки всего функционала.
• В корпоративном сегменте отсутствие даже редко используемых, но критичных для конкретного клиента функций (гигиенических фич) может привести к срыву сделки.
• Сложность удаления неиспользуемых функций обусловлена тем, что каждая функция может быть критически важна для узкой группы пользователей, и их удаление приведет к потере этих пользователей.
• Для борьбы с раздуванием функционала предлагаются различные стратегии: фокусировка на конкретной аудитории, модульность, соблюдение философии Unix (один инструмент — одна задача), сбор метрик использования.
• Разработчикам сложно предсказать, как именно будет использоваться продукт, поэтому важно сохранять гибкость и возможность кастомизации, особенно для технически подкованных пользователей.

Приложения на Electron вызывают серьёзные задержки в работе всей системы на macOS 26. Пользователи сообщают о замедлении интерфейса, лагах при вводе текста и проблемах с отзывчивостью даже при минимальной нагрузке. Это связано с тем, что фреймворк использует общие ресурсы системы неэффективно, особенно в многозадачных сценариях.

Проблема проявляется при одновременной работе нескольких Electron-приложений, таких как Slack, Discord или VS Code. Система начинает проседать по производительности, что негативно сказывается на пользовательском опыте. Разработчики Electron признают проблему и изучают её, но пока не предложили конкретного решения.

• Проблема с производительностью в macOS 26 вызвана использованием приложениями (включая Electron) приватных API Apple, что приводит к утечкам ресурсов и лагам.
• Некоторые пользователи не сталкиваются с проблемами, возможно, из-за высокой производительности железа (например, чипов M4), которое маскирует недочеты.
• Обсуждается, кто виноват: разработчики приложений за использование приватных методов или Apple за отсутствие регрессионного тестирования и обратной совместимости.
• Для части приложений (Chrome/Chromium) уже выпущен фикс, а также известны временные решения через терминал.
• Спектр мнений варьируется от критики Electron до защиты его как кросс-платформенного решения с хорошим DX.

Slack, будучи Electron-приложением, использует библиотеки с лицензией MIT, что требует включения соответствующего файла лицензии в дистрибутив. Однако в некоторых версиях Slack этот файл отсутствует, что нарушает условия лицензирования и может вызвать юридические вопросы. Это подчёркивает важность соблюдения лицензионных соглашений даже в крупных коммерческих продуктах.

Пользователи Mastodon сталкиваются с необходимостью включения JavaScript для работы веб-приложения, что может быть неудобно для тех, кто предпочитает отключать скрипты из соображений безопасности или производительности. В качестве альтернативы предлагается использовать нативные приложения, доступные для различных платформ, что улучшает опыт и обеспечивает большую гибкость.

• Участники обсуждают чрезмерную сложность и раздутость лицензий и условий Slack, а также его зависимость от множества сторонних библиотек.
• Высказывается критика в адрес современного ПО за расточительное использование ресурсов в сравнении с программным обеспечением прошлого.
• Поднимается тема необходимости владения программным обеспечением, а не его аренды (подписки), и возможности самоличного хостинга.
• Предлагаются альтернативы Slack для командного чата, такие как Zulip и Campfire, с возможностью самостоятельного хостинга.
• Обсуждаются причины популярности Slack в корпоративной среде, главные из которых — готовые решения и техническая поддержка для бизнеса.

Slack вымогает у нас дополнительные $195 тыс. в год

Открытое письмо

Hack Club — некоммерческая организация, которая уже почти 11 лет использует Slack для обучения подростков программированию. Мы не были нахлебниками: несколько лет назад, когда Slack перевёл нас с бесплатного тарифа на платный за $5 тыс. в год, мы с радостью согласились.

Однако два дня назад Slack сообщил, что если мы не согласимся доплатить $50 тыс. на этой неделе и затем $200 тыс. ежегодно, наш рабочий пространство будет отключено, а вся история сообщений — удалена.

Можно было бы сказать, что Slack вправе в любой момент отменить льготные условия. Но, на мой взгляд, уведомление за полгода — это минимум при таком резком повышении. По сути, Salesforce (компания с капитализацией $230 млрд) вынуждает небольшую подростковую некоммерческую организацию в срочном порядке найти огромную сумму, иначе мы рискуем потерять все каналы связи. Это абсурд.

Последствия

Крайне сжатые сроки оказались катастрофическими для наших программ. Десятки сотрудников и волонтёров вынуждены срочно обновлять системы, перестраивать интеграции и переносить годы накопленных знаний. Стоимость вынужденной миграции колоссальна.

В любом случае, мы переходим на Mattermost. Этот опыт показал, что контроль над своими данными крайне важен. Если вы — небольшой бизнес, советую тоже задуматься о переходе.

---

Этот пост был написан в спешке — ситуация стала шоком! Если нужны дополнительные детали, напишите мне.

• Slack резко увеличил плату для некоммерческой организации Hack Club в 40 раз с коротким сроком уведомления, угрожая удалить данные.
• Сообщество осудило действия Slack как неэтичные, сравнив их с тактикой вымогательства и указав на риск для других неплатежеспособных клиентов.
• В ответ на негативную реакцию Slack публично извинился и восстановил прежние условия, назвав это ошибкой.
• Hack Club, несмотря на извинения, начал миграцию на альтернативную платформу (Mattermost) из-за потери доверия и желания контролировать данные.
• Обсуждение перешло к рекомендациям по переходу на открытые решения (Zulip, Matrix) и критике бизнес-модели SaaS, ведущей к зависимости от вендора.

• Кит Питт — австралийский разработчик, отец троих детей, бывший фокусник. Считает себя не предпринимателем, а изобретателем: «ценность идеи = кто-то заплатил за неё».

• Buildkite родился как побочный проект: Кит писал e-mail-API и понадобился собственный CI. Вечерами довёл прототип до продукта, подключил PIN Payments (первый в AU простой REST-эквайринг) и выложил на $5/30/100.

• Первый «чужой» клиент из Европы (Moneybird) показал: продукт внешне нужен. Когда знакомая компания сама докинулась до $500/мес, Кит поверил, что выживет.

• Первые годы — вечера и выходные, пока жена училась; днём — работа в Envato. Рост шёл медленно, но MRR удваивался каждые 6 мес.

• 2016 — деньги кончились, зарплаты не хватало. Кит вернулся к инвесторам, поднял раунд и стал CEO полный ставка. Пришлось учиться управлять, нанимать и строить распределенную команду.

• Голос продукта выработали через публичный блог: честные посты о проблемах и фичах привели трафик и доверие разработчиков.

• Сегодня Buildkite — глобальный CI/CD с клиентами вроде Shopify и Slack; офисы в Мельбурне и SF. Кит ушёл с поста CEO, но остался техническим лидером и продолжает «изобретать».

• Buildkite хвалят за гибридную архитектуру (SaaS + свои агенты), декларативные пайплайны и приятный UI.
• Малые компании уходят: цены взлетели, фокус сместился на крупные enterprise.
• Меньшие стартапы успешно использовали Buildkite + дешёвые серверы (Hetzner) и Knapsack Pro для параллельных тестов.
• Основатель признался, что привлёк $28 млн раунда, «чтобы купить дом» — вызвал улыбку.
• Некоторые разработчики считают ИИ-ассистентов вредными для глубокого понимания задачи: «поверхностный флирт» вместо погружения.

Atlassian приобретает The Browser Company
Сегодня мы объявили о покупке The Browser Company — создателей браузеров Dia и Arc.

Цель
Создать первый AI-браузер для командной работы, объединив любовь TBC к инновациям и опыт Atlassian в управлении командами.

Проблема
Современные браузеры заточены под потребление, а не работу: куча вкладок, потерянные вкладки, отсутствие контекста задач.

Решение
Arc уже умеет группировать вкладки, а Dia добавляет AI-агента, который:

• собирает контекст из Jira, Confluence, Slack;
• автоматически открывает нужные страницы;
• помогает быстрее принимать решения.

Что дальше

• Arc и Dia продолжат работать как сейчас.
• Постепенно появится глубокая интеграция с Atlassian-продуктами.
• Команды объединятся, чтобы масштабировать идею «браузера для работы».

Мы верим, что совместно сделаем работу более продуктивной и приятной.

• Arc был признан инновационным браузером для продвинутых пользователей, но рост остановился и команда переключилась на новый проект Dia с ИИ, вызвав шквал критики.
• Пользователи считают отказ от Arc ошибкой: продукт нравился, но монетизировать его оказалось сложно.
• Покупка Atlassian за $610 млн наличными выглядит странно: стратегического перекрытия продуктов нет, выручки у TBC не было.
• Многие опасаются, что Arc «умрёт» под крылом Atlassian, и уже переходят на Zen или Firefox.
• Общий вывод: это похоже на дорогой acqui-hire или ставку на «AI-агентов» в корпоративной экосистеме Atlassian.

• YouTube
  О платформе | Пресс-центр | Авторские права | Контакты | Авторам | Реклама | Разработчикам
  Условия | Конфиденциальность | Безопасность | Как работает YouTube | Тест новых функций | NFL Sunday Ticket
  © 2025 Google LLC

• IRC стал «точкой входа» в Linux, программирование и даже в профессии: кто-то научился CAD, кто-то писал скрипты для mIRC, а кто-то защищался от WinNuke.
• Люди знаходили друзей, жён и стипендии; 9/11 многие узнавали первым именно в чатах, а не по ТВ.
• Это была первая глобальная «соцсеть» без рекламы и алгоритмов: decentralized, эфемерные каналы, netsplits и «ghost»-бансеры, которые до сих пор держат связь.
• Сегодня IRC живёт в нишах: Libera.Chat, секретные +s-каналы, IRCCloud и пара приваток, куда новичков не зовут, чтобы «не убить атмосферу».
• Основная жалоба: Discord/Slack тяжёлые и коммерческие, IRCv3 с историей идёт медленно, а «золотой век» ушёл вместе с 56k-модемами и телефонными счетами.

В декабре 2020-го я прикрутил IRC-сервер к газонокосилке. Почему? Сломавшийся мотор дал повод полезть в карбюратор, а друзья в Undernet начали шутить: «Привяжи к ней Raspberry Pi и свяжи с EFnet!». Шутка не умерла за пять дней, и я решился.

Что такое IRC
Текстовый чат 1988 года, до сих пор жив. В 90-х через Undernet я познакомился с программистами по всему миру и сам стал разработчиком.

Как подключиться
Сервер lawnmower.* работает на Pi, прикреплённой к косилке.
Адрес: lawnmower.undernet.org:6667
Канал: #lawn

• Пользователи восторженно обсуждают проект «газонокосилка с Raspberry Pi и IRC-сервером», признавая его абсурдность и притягательность.
• Некоторые мечтали увидеть именно IRC-сервер на роботе-косилке, а не просто прикол; ссылки на openmower.de и idlerpg.net подогрели фантазии.
• Всплыла ностальгия по раннему интернету и Undernet, где люди знакомились по всему миру.
• Участники спорят, можно ли запустить Doom или IRC-клиент на современных ARM-микроконтроллерах косилок; китайские бренды считаются лёгкой добычей для хакеров.
• Вопрос «А где хранится форель?» стал внутренней шуткой треда.
• IRC-2021 жив (libera.chat) и всё ещё считается лучшим инструментом группового чата, в отличие от «IRC-as-a-service» вроде Slack.

Notion — это универсальный инструмент для заметок, задач, баз знаний и совместной работы. Объединяет блоки текста, таблицы, календари, доски Kanban, базы данных и встраиваемые медиа в единое пространство. Поддерживает шаблоны, автоматизацию, API и интеграции (Slack, GitHub, Figma и др.). Работает в браузере, на macOS, Windows, iOS и Android. Бесплатный план для личного использования; платные тарифы для команд и расширенных функций.

• Участники спорят, почему диффузионные модели проигрывают авторегрессии: BarakWidawsky связывает это с меньшей способностью к запоминанию, а ckjellqv — с невозможностью KV-кеширования.
• Woadwarrior01 удивлён росту FLOPs при генерации длинных последовательностей (×16–4700) и отмечает нелинейную зависимость.
• Godelski критикует неясность терминов «in/out-of-distribution» без описания обучающих данных.
• Bicsi предлагает «закрыть» диффузионные модели, считая цепочку мыслей (CoT) быстрым и мощным заменителем; против выступают fancyfredbot и SalmoShalazar, призывая не отвергать подход преждевременно.

• Проблема: «пользователь ≠ покупатель». Нет универсального решения; всё зависит от того, у кого реальная власть — и это не всегда владелец кредитной карты.

• Критерий: кто имеет рычаги — власть, ограничения и стимулы — чтобы протолкнуть покупку. Именно он и «ценит» продукт по-настоящему (с учётом реальности: может ли он реально обменять ценность на деньги/внедрение).

• Малые/ранние компании: плоская структура, главный ограничитель — скорость. Девелопер имеет влияние: приносит инструменты, может начать с фри-плана, показать пользу, а потом компания «троянится» на платный тариф. ЦТО хочет ускорения time-to-market, поэтому прислушивается.

• Компании с жёсткой безопасностью: власть у руководства/безопасности. Пользователи не ставят софт сами; длинный цикл продаж, фокус — безопасность и результат, а не DX/UX. Пользовательского «хочу» недостаточно.

• Деньги ≠ решение. Важно не «кто пробует первым», а «кто может провести сделку с учётом ограничений». Если девелопер ценит выше, чем бюджетодержатель, чек на его оценку не подпишут. Иногда девы платят сами — их стимул: выглядеть сильнее и принести победу.

• Типичный путь (пример): дев регистрируется → пробует локально → получает «аха-момент» до PR (видит до/после, экономит время/QA, возможно авто) → пытается убедить лидершип → лидершип тестит, проверяет бюджет → одобрение → покупка → распространение в команде.

• Практика для аутрича и месседжинга:

  • Определите, кто реально продвигает покупку в вашем сегменте (скорость vs безопасность).
  • Для девов: быстрый «аха» в онбординге, self-serve, бесплатный слой, скрипты для локального пруфа, материалы «как продать менеджеру» (one-pager ROI, сравнение рисков, кейсы).
  • Для решал: безопасность, комплаенс, TCO, интеграции, контроль доступа, процессы закупки; готовые ответы на due diligence.
  • Создайте мост: внутриигровой триггер «пригласить лидершип/безопасность» с автогенерацией отчёта ценности/рисков.
  • Точечный аутрич: спрашивайте про реальный путь успешного принятия именно у ваших пользователей и под него выстраивайте GTM.

• Пользователи ≠ покупатели: продавец должен «продавать» самих пользователей, чтобы они стали внутренними чемпионами продукта.
• Агрессивные продажи (спам, игнор отказов, скрытая цена) вызывают «сарафанное радио наоборот» и блокировки доменов.
• В крупных компаниях реальные полномочия могут быть у линейного менеджера, а не CTO; нужно точно выявлять, кто принимает решение.
• Успешные продукты (Slack, Postman) демонстрируют «уже пользуются 96 % вашей команды» и экономят время на доказательства.
• Для B2B2C-моделей пользователь становится распределённым отделом продаж, а платформа берёт процент с транзакций.

Я работал удалённо ещё до моды. В первой большой компании нас было двое в Варшаве, остальные — в Осло. Менеджер сказал: «Команда тебя приняла». Парадокс? Нет: был IRC-канал, где мы не только кодили, но и болтали о «Стартреке» и котиках. Компания создала онлайн-«кухню», и люди здоровались, спрашивали «как дела?» — как в офисе.

Пандемия. Я в консалтинге, всё как всегда: рабочие и оффтоп-каналы в Matrix. Нам поручили клиента, который «внезапно» стал удалённым. Менеджер велел включать камеры «ради командного духа». Мы купили вебки и ржали в чате. У клиента не было оффтопа; люди знали друг друга только по рабочим ролям. Ревью превращались в разборки, потому что никто не играл вместе вечерами и не пил пиво по пятницам.

Офлайновые офисы это понимают: кухня, настольный теннис, диванчики. Признание, что 8 часов кодить нереально, и людям нужно дышать. Перенеси работу в онлайн — и вдруг это становится новостью.

Недавно пришёл в «remote-first» компанию без офиса. На собеседовании хвалил оффтоп, и мне ответили: «У нас куча каналов и рандомных кофе-ботов». А по факту — тишина. В #music сбросили ссылку на клип и разошлись. Коллега пояснил: «Релиз на носу, все боятся выглядеть бездельниками». Так уже несколько месяцев.

Сколько ни создавай каналов, без культуры «можно поболтать» они мертвы. В старых командах боссы постили мемы чаще всех — потому что их работа и есть быть в курсе настроений. Если начальство молчит, остальные тоже замолкают.

• Участники обсуждают, как «человеческий элемент» в работе (оффтоп-общение, дружба) повышает удовлетворённость, но может выродиться в клановость и изоляцию.
• Переход на удалёнку усилил страх слежки: в офисе кофе-пауза была приватной, в Slack всё может читаться HR/IT.
• Корпоративная культура часто подавляет неформальность: стартапам позволено шутить, крупным компаниям важно минимизировать конфликт.
• Некоторые считают, что коллеги не обязаны быть друзьями (особенно в Германии), другие подчёркивают пользу доверия и симпатии.
• Технические решения (DM, каналы без истории) могут частично заменить «водопроводные разговоры», но не решают проблему культуры.