Не обслуживайте срочность
Недавно на Q&A «Есть минутки» мне задали вопрос — как вести асинхронную коммуникацию, когда кто-то нужен срочно — типа стенд упал, ветка не мёрджится или просто нужно срочно сделать задачу.
Конечно, когда что-то действительно нужно срочно — никакая асинхронная коммуникация не работает: надо писать, звонить и вообще разыскивать всяческими доступными способами. Однако меня смущает, что большинство людей воспринимают срочность как некую аксиому, типа «нам нужен чатик с девопсами, потому что они бывают нам срочно необходимы». Конечно, если системно не работать над происходящим в компании, все будут друг-другу срочно нужны.
Работа менеджера\тимлида состоит не в том, чтобы обслуживать срочность, создавая больше чатиков, а в том, чтобы её убивать: выделять время, чтобы сделать неломаемые стенды; внедрять gitflow, чтобы не было немёрджащихся веток; бить по рукам тем менеджерам, которые выдумывают срочность, потому что не доверяют людям. Такие причины устранить реально — у нас с Саматом в команде на 20 человек и несколько крупных проектов срочность бывает два раза в год при крупных релизах.
Не обслуживайте срочность — убивайте её.
Недавно на Q&A «Есть минутки» мне задали вопрос — как вести асинхронную коммуникацию, когда кто-то нужен срочно — типа стенд упал, ветка не мёрджится или просто нужно срочно сделать задачу.
Конечно, когда что-то действительно нужно срочно — никакая асинхронная коммуникация не работает: надо писать, звонить и вообще разыскивать всяческими доступными способами. Однако меня смущает, что большинство людей воспринимают срочность как некую аксиому, типа «нам нужен чатик с девопсами, потому что они бывают нам срочно необходимы». Конечно, если системно не работать над происходящим в компании, все будут друг-другу срочно нужны.
Работа менеджера\тимлида состоит не в том, чтобы обслуживать срочность, создавая больше чатиков, а в том, чтобы её убивать: выделять время, чтобы сделать неломаемые стенды; внедрять gitflow, чтобы не было немёрджащихся веток; бить по рукам тем менеджерам, которые выдумывают срочность, потому что не доверяют людям. Такие причины устранить реально — у нас с Саматом в команде на 20 человек и несколько крупных проектов срочность бывает два раза в год при крупных релизах.
Не обслуживайте срочность — убивайте её.
Точить пилу
Когда на собеседованиях говорят, что не писали тестов на предыдущей работе — я всегда спрашиваю, что помешало это сделать. Если отбросить радикальные варианты, когда программисты сами считают, что без тестов — быстрее, самый частый ответ — «нам не дают времени».
Я всегда в такие моменты представляю себе застройщика, который жалеет денег рабочим на каски и с умным лицом рассуждает, что это экономит ресурсы. Правда иногда строителям на голову падают кирпичи — но ничего страшного: теперь на территории есть специальная больница, где таких людей откачивают. Экономия же! К тому же пока никто не умер — есть пара инвалидов, но их пенсия ничтожна по сравнению с экономией на касках.
Таких застройщиков, к счастью не бывает. Так же, как не бывает глупых руководителей бизнеса. Если хорошо объяснить — согласится даже мерзкий капиталист-владелец аутсорса. В основном инженеры не могут объяснить потому, что до конца и сами не верят в эффективность автотестов — попробовали пару раз и не получилось: тесты падали, тормозили, или бесконечно жрали время на поддержку.
Именно таким людям я помогаю уже несколько лет — провожу стримы, где пишу по TDD, постоянно пишу о тестах в канале. К сожалению, это всё не работает, пока инженеры не разрешают себе «заточить пилу». Кажется, научить этому извне невозможно — можно дойти только самому.
Если вы пишете на питоне и уже научились — приходите на наш курс по тестированию с Никитой Соболевым: расскажем и покажем все актуальные способы наточить свою пилу и показать коллегам, как это делать. Кроме вебинара про базовые инструменты (который вы получите в записи) будет ещё три — о читаемости, о скорости/надёжности и о том, как всё это живёт в реальной жизни.
Стартуем сегодня в 18:00 MSK, ещё можно успеть. Есть рассрочка, а если хорошо побегать — можно даже успеть от юрлица.
Смотреть программу →
Когда на собеседованиях говорят, что не писали тестов на предыдущей работе — я всегда спрашиваю, что помешало это сделать. Если отбросить радикальные варианты, когда программисты сами считают, что без тестов — быстрее, самый частый ответ — «нам не дают времени».
Я всегда в такие моменты представляю себе застройщика, который жалеет денег рабочим на каски и с умным лицом рассуждает, что это экономит ресурсы. Правда иногда строителям на голову падают кирпичи — но ничего страшного: теперь на территории есть специальная больница, где таких людей откачивают. Экономия же! К тому же пока никто не умер — есть пара инвалидов, но их пенсия ничтожна по сравнению с экономией на касках.
Таких застройщиков, к счастью не бывает. Так же, как не бывает глупых руководителей бизнеса. Если хорошо объяснить — согласится даже мерзкий капиталист-владелец аутсорса. В основном инженеры не могут объяснить потому, что до конца и сами не верят в эффективность автотестов — попробовали пару раз и не получилось: тесты падали, тормозили, или бесконечно жрали время на поддержку.
Именно таким людям я помогаю уже несколько лет — провожу стримы, где пишу по TDD, постоянно пишу о тестах в канале. К сожалению, это всё не работает, пока инженеры не разрешают себе «заточить пилу». Кажется, научить этому извне невозможно — можно дойти только самому.
Если вы пишете на питоне и уже научились — приходите на наш курс по тестированию с Никитой Соболевым: расскажем и покажем все актуальные способы наточить свою пилу и показать коллегам, как это делать. Кроме вебинара про базовые инструменты (который вы получите в записи) будет ещё три — о читаемости, о скорости/надёжности и о том, как всё это живёт в реальной жизни.
Стартуем сегодня в 18:00 MSK, ещё можно успеть. Есть рассрочка, а если хорошо побегать — можно даже успеть от юрлица.
Смотреть программу →
Письмо самому себе
Из ГТД я вынес для себя три вещи: ежедневные обзоры дел, пустой инбокс и письма самому себе.
Первые две вещи настолько банальны, что на них не стоит останавливаться. А вот про письма в будущее расскажу подробнее.
Вы когда-нибудь задумывались, почему маленькое сообщение в телеграме заставляет людей отвлечься от интересной беседы или важной работы? Все дело в распространенной логической ошибке, которая называется привлекательность новизны. Грубо говоря, каждая последующая мысль пришедшая в голову, кажется более важной, чем предыдущая.
Если не сохранять внезапные мысли, то они будут улетать в бездонную пропасть. А если постоянно на них переключаться, то вы просто ничего не будете успевать — ведь рано или поздно вместо важной мысли вам придет голову идея проверить личные сообщения в фейсбуке, и вы проснетесь вечером в обнимку с котиками или очередной петицией против кровавого режима.
Чтобы не терять важное, я пишу письма самому себе. Как только в голову приходит любая мысль, которая не имеет отношения к тому, чем я занят сейчас, я ее записываю и отсылаю себе на почту. Мысль из головы сразу же уходит, и я возвращаюсь обратно к тому, что делал. Мысль не проебется — почту я проверяю периодически и полностью вычищаю ящик.
Раньше для для отсылки писем я пользовался программой на айфоне, которая так и называлась — Mail to Self. Однако со временем пришло понимание, что каждый клик понижает вероятность того, что мысль будет записана. Особенно Mail to Self страдала, когда хотелось отправить себе скриншот или фотографию.
Поэтому я пошел дальше и написал себе бота для телеграма — @selfmailbot. Бот делает простую штуку — все что я ему пишу, оказывается у меня на почте. Привычный интерфейс телеграма помогает лениться еще меньше и записывать вообще все, что приходит в голову.
Бот бесплатный и открытый, так что если вы ГТД-шник — смело пользуйтесь. Если хотите скинуться на хостинг бота и живёте не в России — у меня есть патреон.
Из ГТД я вынес для себя три вещи: ежедневные обзоры дел, пустой инбокс и письма самому себе.
Первые две вещи настолько банальны, что на них не стоит останавливаться. А вот про письма в будущее расскажу подробнее.
Вы когда-нибудь задумывались, почему маленькое сообщение в телеграме заставляет людей отвлечься от интересной беседы или важной работы? Все дело в распространенной логической ошибке, которая называется привлекательность новизны. Грубо говоря, каждая последующая мысль пришедшая в голову, кажется более важной, чем предыдущая.
Если не сохранять внезапные мысли, то они будут улетать в бездонную пропасть. А если постоянно на них переключаться, то вы просто ничего не будете успевать — ведь рано или поздно вместо важной мысли вам придет голову идея проверить личные сообщения в фейсбуке, и вы проснетесь вечером в обнимку с котиками или очередной петицией против кровавого режима.
Чтобы не терять важное, я пишу письма самому себе. Как только в голову приходит любая мысль, которая не имеет отношения к тому, чем я занят сейчас, я ее записываю и отсылаю себе на почту. Мысль из головы сразу же уходит, и я возвращаюсь обратно к тому, что делал. Мысль не проебется — почту я проверяю периодически и полностью вычищаю ящик.
Раньше для для отсылки писем я пользовался программой на айфоне, которая так и называлась — Mail to Self. Однако со временем пришло понимание, что каждый клик понижает вероятность того, что мысль будет записана. Особенно Mail to Self страдала, когда хотелось отправить себе скриншот или фотографию.
Поэтому я пошел дальше и написал себе бота для телеграма — @selfmailbot. Бот делает простую штуку — все что я ему пишу, оказывается у меня на почте. Привычный интерфейс телеграма помогает лениться еще меньше и записывать вообще все, что приходит в голову.
Бот бесплатный и открытый, так что если вы ГТД-шник — смело пользуйтесь. Если хотите скинуться на хостинг бота и живёте не в России — у меня есть патреон.
#вопрос начиная стартап, какую "техническую гигиену" стоит ввести? О чем стоит задуматься с самых первых дней?
Мне не хочется в очередной раз рассказывать про автотесты, линтеры, ci\cd и докер, поэтому я буду считать что это вопрос от фаундера, а не CTO.
Самое главное, что вы как фаундер можете сделать с первых дней — это научить свою разработку писать как можно меньше кода. Каждая фича, которую вы закодите руками программистов стоит денег и внимания. Даже если её никто не использует. Тестируйте гипотезы на nocode-решениях. Если всё-таки пилите фичи — прямо в задачах фиксируйте гипотезы, которые проверяете этими фичами и учите разработку совершать минимум телодвижений, нужных чтобы эту гипотезу проверить. Если гипотеза выстреливает — тогда уже пишите хороший код. Если нет — выпиливайте весь написанный код. Чем меньше тратите сил на поддержку — тем больше остаётся для новых фич, и тем меньше денег стоит вам разработка.
Если вдруг гипотезы — это не ваша история, и для запуска вашего стартапа нужно запилить кучу кода не меньше кинопоиска, тогда первая ваша задача — отсеять плохих программистов. К сожалению, собрав рандомную команду с рынка, вряд ли вы получите людей, способных самостоятельно организовать свою работу. Скорее всего они довольно сильно вас замедлят, нагородив сложности вроде микросервисов с кафкой, или настроив лишних процессов вроде ручного тестирования с релизными поездами.
Чтобы поймать замедление на самом раннем этапе — выстройте обязательный еженедельный контроль: когда команда по понедельникам строит понятный бизнесу план, а через неделю отчитывается по нему. Если на протяжением 2–3 недель больше 20% плана не выполняется — скорее всего у вас уже есть проблемы с качеством, и пора честно поговорить об этом с командой (кстати мы с Саматом это умеем, пишите).
Это был традиционный вопрос по понедельникам. Задайте свой на fborshev@pm.me
Мне не хочется в очередной раз рассказывать про автотесты, линтеры, ci\cd и докер, поэтому я буду считать что это вопрос от фаундера, а не CTO.
Самое главное, что вы как фаундер можете сделать с первых дней — это научить свою разработку писать как можно меньше кода. Каждая фича, которую вы закодите руками программистов стоит денег и внимания. Даже если её никто не использует. Тестируйте гипотезы на nocode-решениях. Если всё-таки пилите фичи — прямо в задачах фиксируйте гипотезы, которые проверяете этими фичами и учите разработку совершать минимум телодвижений, нужных чтобы эту гипотезу проверить. Если гипотеза выстреливает — тогда уже пишите хороший код. Если нет — выпиливайте весь написанный код. Чем меньше тратите сил на поддержку — тем больше остаётся для новых фич, и тем меньше денег стоит вам разработка.
Если вдруг гипотезы — это не ваша история, и для запуска вашего стартапа нужно запилить кучу кода не меньше кинопоиска, тогда первая ваша задача — отсеять плохих программистов. К сожалению, собрав рандомную команду с рынка, вряд ли вы получите людей, способных самостоятельно организовать свою работу. Скорее всего они довольно сильно вас замедлят, нагородив сложности вроде микросервисов с кафкой, или настроив лишних процессов вроде ручного тестирования с релизными поездами.
Чтобы поймать замедление на самом раннем этапе — выстройте обязательный еженедельный контроль: когда команда по понедельникам строит понятный бизнесу план, а через неделю отчитывается по нему. Если на протяжением 2–3 недель больше 20% плана не выполняется — скорее всего у вас уже есть проблемы с качеством, и пора честно поговорить об этом с командой (кстати мы с Саматом это умеем, пишите).
Это был традиционный вопрос по понедельникам. Задайте свой на fborshev@pm.me
Выбирать только лучшее
Мы в «Феде и Самате» заканчиваем переход с fastmail на gmail. Пока рефлексировал, подтвердил для себя старый принцип «не изъёбываться» — KISS работает не только в коде, но и в организации.
Раз уж мы столько вкладываемся в DX и в асинхронную коммуникацию без стендапов — почему бы не потратить силы ещё и на удобные инструменты? Fastmail, к примеру, не работает по IMAP без VPN и имеет довольно непривычный интерфейс после знакомого всем gmail. Разница как между Basecamp и YouTrack: второй вроде и функциональный, но об UX явно никто не думал, сервис делали программисты для программистов.
С ужасом представляю, как живётся пользователям адовых отечественных комбайнов вроде Битрикс24 (серьёзно, в нём ведут разработку!) или огородиков с корпоративным Postfix/dovecot и ужасными вебмордами. Сколько времени пользователи тратят на работу, а сколько — на борьбу с окружением и сисадминами.
Хочу, чтобы в моей компании не было даже минимальных барьеров к продуктивности, поэтому всегда буду выбирать самые лучшие сервисы, и не жалеть времени и денег на переход.
Мы в «Феде и Самате» заканчиваем переход с fastmail на gmail. Пока рефлексировал, подтвердил для себя старый принцип «не изъёбываться» — KISS работает не только в коде, но и в организации.
Раз уж мы столько вкладываемся в DX и в асинхронную коммуникацию без стендапов — почему бы не потратить силы ещё и на удобные инструменты? Fastmail, к примеру, не работает по IMAP без VPN и имеет довольно непривычный интерфейс после знакомого всем gmail. Разница как между Basecamp и YouTrack: второй вроде и функциональный, но об UX явно никто не думал, сервис делали программисты для программистов.
С ужасом представляю, как живётся пользователям адовых отечественных комбайнов вроде Битрикс24 (серьёзно, в нём ведут разработку!) или огородиков с корпоративным Postfix/dovecot и ужасными вебмордами. Сколько времени пользователи тратят на работу, а сколько — на борьбу с окружением и сисадминами.
Хочу, чтобы в моей компании не было даже минимальных барьеров к продуктивности, поэтому всегда буду выбирать самые лучшие сервисы, и не жалеть времени и денег на переход.
Это я или моё окружение?
Человек — существо социальное. Часто настолько социальное, что даже внутренний диалог происходит не с самим собой, а с социумом. Хороший пример — недвижимость: мы годами видим баннеры с счастливыми семьями и эмоциональными посылами вроде «построй своё место» или «получи московскую прописку» и привыкаем к ним настолько, что покупка квартиры превращается из обычного в общем-то финансового инструмента в самоцель. Отпадают рациональные вопросы вроде «а что будет на этом месте через 10 лет» или «не ухудшит ли эта ипотека качество моей жизни?» — мы просто хотим квартиру. А как родители обрадуются!
Важный скилл, который который приходит с возрастом — это умение честно разговаривать с собой о своих желаниях. Хочу ли я стать айтишником, или может всё-таки менее трендовым, зато подходящим дизайнером интерьеров? Хочу ли я переезжать в Казахстан, или просто следую за новостями? Выбираю мерседес потому, что это самое лучшее редложение на рынке, или потому что у соседа такой?
Этот софт-скилл здорово помогает и в работе программиста. Хочу ли я писать на nuxt потому, что считаю его качественным фреймворком с внятным будущим, или потому, что так принято? Хочу ли я разбираться в ChatGPT, или она просто на хайпе сейчас?
Сделав сложный выбор, всегда проверяйте — а сами ли вы сделали этот выбор? Или может общество подсказало?
Человек — существо социальное. Часто настолько социальное, что даже внутренний диалог происходит не с самим собой, а с социумом. Хороший пример — недвижимость: мы годами видим баннеры с счастливыми семьями и эмоциональными посылами вроде «построй своё место» или «получи московскую прописку» и привыкаем к ним настолько, что покупка квартиры превращается из обычного в общем-то финансового инструмента в самоцель. Отпадают рациональные вопросы вроде «а что будет на этом месте через 10 лет» или «не ухудшит ли эта ипотека качество моей жизни?» — мы просто хотим квартиру. А как родители обрадуются!
Важный скилл, который который приходит с возрастом — это умение честно разговаривать с собой о своих желаниях. Хочу ли я стать айтишником, или может всё-таки менее трендовым, зато подходящим дизайнером интерьеров? Хочу ли я переезжать в Казахстан, или просто следую за новостями? Выбираю мерседес потому, что это самое лучшее редложение на рынке, или потому что у соседа такой?
Этот софт-скилл здорово помогает и в работе программиста. Хочу ли я писать на nuxt потому, что считаю его качественным фреймворком с внятным будущим, или потому, что так принято? Хочу ли я разбираться в ChatGPT, или она просто на хайпе сейчас?
Сделав сложный выбор, всегда проверяйте — а сами ли вы сделали этот выбор? Или может общество подсказало?
#вопрос Приучаю себя читать и теряюсь из-за количества книг. Кажется, что интересных книг больше, чем я могу осилить. Расскажи, пожалуйста, как ты выбираешь книги? Какую информацию считаешь самой ценной? Как ты понимаешь, какая книга принесет больше пользы?
Круто, что вы спросили не «как читать больше книг», а «как выбирать книги». Я сам когда-то свалился в состояние, в котором гнался за количеством, а не за качеством — прочитал за два года около 100 книг, вёл даже публичный список прочитанного. Потом начал сбавлять темп потому, что постепенно переставал чувствовать пользу от чтения. Перелом случился в 2020 году, когда я ушёл в собственный бизнес, где важнее оказались базовые человеческие качества — умение много работать и не ссать в неопределённости: я практически перестал читать нон-фикшн, дойдя по 1–2 книг в год.
Сейчас, открывая книгу, я чётко формулирую ожидания, к примеру «я читаю эту книгу Адизеса, потому что хочу подумать о стратегии роста школы как организации» или «я читаю эту книгу по личной продуктивности, чтобы сделать ревизию своих рабочих привычек и добавить себе уверенности». Если я не чувствую, что ожидания выполняются за первые 100 страниц — книгу выкидываю: есть много гораздо более полезных способов потратить время.
Ещё в вашем случае я бы посоветовал привязывать знания из книг к плану роста: скорее всего ваша цель — не достигнуть количества прочитанных книг, а стать более сильным профессионалом, и гигантский беклог скорее в этом помешает, добавив чувство вины.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Круто, что вы спросили не «как читать больше книг», а «как выбирать книги». Я сам когда-то свалился в состояние, в котором гнался за количеством, а не за качеством — прочитал за два года около 100 книг, вёл даже публичный список прочитанного. Потом начал сбавлять темп потому, что постепенно переставал чувствовать пользу от чтения. Перелом случился в 2020 году, когда я ушёл в собственный бизнес, где важнее оказались базовые человеческие качества — умение много работать и не ссать в неопределённости: я практически перестал читать нон-фикшн, дойдя по 1–2 книг в год.
Сейчас, открывая книгу, я чётко формулирую ожидания, к примеру «я читаю эту книгу Адизеса, потому что хочу подумать о стратегии роста школы как организации» или «я читаю эту книгу по личной продуктивности, чтобы сделать ревизию своих рабочих привычек и добавить себе уверенности». Если я не чувствую, что ожидания выполняются за первые 100 страниц — книгу выкидываю: есть много гораздо более полезных способов потратить время.
Ещё в вашем случае я бы посоветовал привязывать знания из книг к плану роста: скорее всего ваша цель — не достигнуть количества прочитанных книг, а стать более сильным профессионалом, и гигантский беклог скорее в этом помешает, добавив чувство вины.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
А давайте поговорим?
Что-то давно мы с вами не разговаривали, надо исправляться. В эту пятницу в 18:00 MSK делаем с Марьяной двухчасовой стрим на ютубе. Можно будет задать любой вопрос — про управление проектами, образование, профессиональный рост, питон, школу или аутсорс.
Ссылку на стрим опубликуем прямо здесь в пятницу.
Что-то давно мы с вами не разговаривали, надо исправляться. В эту пятницу в 18:00 MSK делаем с Марьяной двухчасовой стрим на ютубе. Можно будет задать любой вопрос — про управление проектами, образование, профессиональный рост, питон, школу или аутсорс.
Ссылку на стрим опубликуем прямо здесь в пятницу.
Сервисы: cloudflare zero trust
Недавно открыл для себя гениальную вещь — cloudflare zero trust: замену рабочего VPN для 2023 года.
Обычно всякие внутренние админки прячут не только за логины\пароли, но и за фаерволы. В общем-то логично — если сольют пароль, фаервол — это ещё один рубеж безопаснсоти. Чтобы пройти через эти фаерволы, пользователи и программисты вынуждены ставить себе корпоративные VPN-клиенты вроде tunnelblick, все как один — кривые.
Zero Trust убирает необходимость в фаерволлах и VPN — вместо настроек IP-адресов и портов, мы начинаем думать на уровень выше: настраиваем доступы пользователей к приложениям. Подключиться к продовому постгресу, авторизовавшись через корпоративный гитхаб? Пожалуйста. Разрешить доступы в your-app/admin/ только для пользователей с почтой
В основе лежит простое требование — все сервисы, которые требуют ограничения доступа, отдавать через cloudflare, дальше всё происходит само. Нам это супер-удобно — уже почти год весь трафик отдаём наружу только через cloudflared. Заодно это даёт ещё и дубовый фаервол: поскольку трафик приходит в шифрованном туннеле, поэтому можно закрыть вообще все входящие порты, кроме 22.
Если прямо сейчас проектируете новую корпоративную сеть — горячо рекомендую заменить VPN на Zero Trust, до 50 живых пользователей система работает бесплатно. Правда лендос у них состоит из какого-то корпоративного буллшита — чтобы понять, что эта штука умеет, нужно региться и ковырять интерфейс, но оно того стоит.
Недавно открыл для себя гениальную вещь — cloudflare zero trust: замену рабочего VPN для 2023 года.
Обычно всякие внутренние админки прячут не только за логины\пароли, но и за фаерволы. В общем-то логично — если сольют пароль, фаервол — это ещё один рубеж безопаснсоти. Чтобы пройти через эти фаерволы, пользователи и программисты вынуждены ставить себе корпоративные VPN-клиенты вроде tunnelblick, все как один — кривые.
Zero Trust убирает необходимость в фаерволлах и VPN — вместо настроек IP-адресов и портов, мы начинаем думать на уровень выше: настраиваем доступы пользователей к приложениям. Подключиться к продовому постгресу, авторизовавшись через корпоративный гитхаб? Пожалуйста. Разрешить доступы в your-app/admin/ только для пользователей с почтой
@your-app.com? Пара кликов мышки.В основе лежит простое требование — все сервисы, которые требуют ограничения доступа, отдавать через cloudflare, дальше всё происходит само. Нам это супер-удобно — уже почти год весь трафик отдаём наружу только через cloudflared. Заодно это даёт ещё и дубовый фаервол: поскольку трафик приходит в шифрованном туннеле, поэтому можно закрыть вообще все входящие порты, кроме 22.
Если прямо сейчас проектируете новую корпоративную сеть — горячо рекомендую заменить VPN на Zero Trust, до 50 живых пользователей система работает бесплатно. Правда лендос у них состоит из какого-то корпоративного буллшита — чтобы понять, что эта штука умеет, нужно региться и ковырять интерфейс, но оно того стоит.
FEDOR BORSHEV
А давайте поговорим? Что-то давно мы с вами не разговаривали, надо исправляться. В эту пятницу в 18:00 MSK делаем с Марьяной двухчасовой стрим на ютубе. Можно будет задать любой вопрос — про управление проектами, образование, профессиональный рост, питон…
Начинаем! Го на ютуб — https://www.youtube.com/live/DNwt6GqPPRU?feature=share
YouTube
Стрим без темы #2
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
Срочный контент
Любое медиа существует для просмотров. Полная зависимость от трафика — это то, что объединяет Медузу и RT, ваш любимый канал с мемасами и редакцию Пивоварова, Википедию и сайты с гороскопами.
Весь контент всех медиа можно разделить на два вида — срочный и веченозелёный. Срочный контент — это новости, мемасы на злобу дня: в общем всё, что не будет иметь смысла через год-полтора. Вечнозелёный контент — это тексты\видео, польза которых не увядает со временем. Скорее всего любой медиасайт, который вы откроете, будет состоять из срочного контента, а большинство авторских блогов (как этот) — наоборот, вечнозелёные.
Срочный контент не несёт пользы — если не считать пользой (ложную) уверенность в том, что мы понимаем происходящее. Вечнозелёный контент, наоборот, более полезен — повышает кругозор, наводит на размышления. Срочный контент потреблять гораздо легче — если бы я писал пост не о том, как правильно потреблять медиа, о новом сенсационном заявлении американского президента, до этого места дочитало бы в два раза больше людей. Дело — в дофаминовой системе, если интересно, погуглите лекции Анны Обуховой.
Я почти всю жизнь обходился без срочного контента — просто не интересовался новостями. Это не было осознанным шагом — мне просто было не интересно. Ковид в 2020 году и война в 2022 довольно сильно поменяли мой формат потребления — начиная с обзоров политологов я к концу 2022 года скатился в чтение коммерсанта и даже периодически заходил на медузу. Осознав эту фигню, я осознанно взялся за формат потребления и наглухо заблокировал все медиа через /etc/hosts (тг-каналов, к счастью, у меня не было). Вот уже 4 месяца, как я не прочитал и не услышал ни одной единицы срочного контента.
Сознание прочистилось — появилось место для размышлений о будущем, осталось больше сил на личные проекты и игру на гитаре, я начал чаще писать в дневник. Думаю, это было лучшим решением как минимум за последние полгода.
Очень советую — заблокировать десяток сайтов и отписаться от кучки каналов вам почти ничего не стоит. Через пару недель пропадёт привычка хвататься за телефон, через месяц — почувствуете качественные изменения во внутреннем диалоге.
Любое медиа существует для просмотров. Полная зависимость от трафика — это то, что объединяет Медузу и RT, ваш любимый канал с мемасами и редакцию Пивоварова, Википедию и сайты с гороскопами.
Весь контент всех медиа можно разделить на два вида — срочный и веченозелёный. Срочный контент — это новости, мемасы на злобу дня: в общем всё, что не будет иметь смысла через год-полтора. Вечнозелёный контент — это тексты\видео, польза которых не увядает со временем. Скорее всего любой медиасайт, который вы откроете, будет состоять из срочного контента, а большинство авторских блогов (как этот) — наоборот, вечнозелёные.
Срочный контент не несёт пользы — если не считать пользой (ложную) уверенность в том, что мы понимаем происходящее. Вечнозелёный контент, наоборот, более полезен — повышает кругозор, наводит на размышления. Срочный контент потреблять гораздо легче — если бы я писал пост не о том, как правильно потреблять медиа, о новом сенсационном заявлении американского президента, до этого места дочитало бы в два раза больше людей. Дело — в дофаминовой системе, если интересно, погуглите лекции Анны Обуховой.
Я почти всю жизнь обходился без срочного контента — просто не интересовался новостями. Это не было осознанным шагом — мне просто было не интересно. Ковид в 2020 году и война в 2022 довольно сильно поменяли мой формат потребления — начиная с обзоров политологов я к концу 2022 года скатился в чтение коммерсанта и даже периодически заходил на медузу. Осознав эту фигню, я осознанно взялся за формат потребления и наглухо заблокировал все медиа через /etc/hosts (тг-каналов, к счастью, у меня не было). Вот уже 4 месяца, как я не прочитал и не услышал ни одной единицы срочного контента.
Сознание прочистилось — появилось место для размышлений о будущем, осталось больше сил на личные проекты и игру на гитаре, я начал чаще писать в дневник. Думаю, это было лучшим решением как минимум за последние полгода.
Очень советую — заблокировать десяток сайтов и отписаться от кучки каналов вам почти ничего не стоит. Через пару недель пропадёт привычка хвататься за телефон, через месяц — почувствуете качественные изменения во внутреннем диалоге.
Анализ систем и распил монолитов
Оглядываясь на прошлое лето, когда мы решили сделать продолжение «Асинхронной Архитектуры», я чувствую себя продюсером «Безумного Макса 4». И не потому, что у нас в качестве эксперта выступает Том Харди (уверен, Антон разбирается в архитектуре лучше), а потому, что мы делали этот курс почти год.
Причина простая — задумали слишком много: хотели так же, как «Стать Тимлидом», сделать курс «Стать Архитектором». Мы не учли, что этим двум профессиям нужно учить по-разному: тимлидам нужно дать практический фреймворк для развития и немного попинать, а вот архитекторам нужна ТЕОРИЯ в огромном количестве. Собственно, весь год мы и пробовали разные подходы, чтобы отжать и упаковать ТЕОРИЮ так, чтобы её можно было прочитать и не умереть.
В итоге остановились 5 уроках, в ~50 страниц A4, построенных на «кругах профессионализма» — каждый новый урок учит решать ту же задачу, что и предыдущий, но на новом уровне и для бизнеса с новым скейлом, с учётом предыдущих ошибок. Получается, как прогрессивный джипег: можно прочитать и половину курса, и уже стать сносным архитектором для не очень сложных систем. Чтобы мысли Антона легко воспринимались в тексте, мы позвали Тимура Зарудного: это первый раз, когда мы зовём пишущего редактора, до этого были только корректоры, а редактировали мы с Марьяной.
На курсе учимся стратегическому анализу бизнеса и DDD, рассматриваем несколько архитектурных стилей, учимся выбирать БД и способы коммуникаций, писать документацию. Самый главный урок, ради которого всё задумывалось — четвёртый: в нём мы даём пошаговые рекомендации по распилу монолитов на базе теории из первых уроков.
Стартуем 12 мая, 5 уроков, 4 круга профессионализма, Q&A, чатик с Антоном и десяток котов в каждом уроке. Если дойдёте до конца — получите достаточно знаний и инструментов, чтобы проектировать системы для большинства крупных работодателей.
До 26 апреля действует промокод
Смотреть программу →
Оглядываясь на прошлое лето, когда мы решили сделать продолжение «Асинхронной Архитектуры», я чувствую себя продюсером «Безумного Макса 4». И не потому, что у нас в качестве эксперта выступает Том Харди (уверен, Антон разбирается в архитектуре лучше), а потому, что мы делали этот курс почти год.
Причина простая — задумали слишком много: хотели так же, как «Стать Тимлидом», сделать курс «Стать Архитектором». Мы не учли, что этим двум профессиям нужно учить по-разному: тимлидам нужно дать практический фреймворк для развития и немного попинать, а вот архитекторам нужна ТЕОРИЯ в огромном количестве. Собственно, весь год мы и пробовали разные подходы, чтобы отжать и упаковать ТЕОРИЮ так, чтобы её можно было прочитать и не умереть.
В итоге остановились 5 уроках, в ~50 страниц A4, построенных на «кругах профессионализма» — каждый новый урок учит решать ту же задачу, что и предыдущий, но на новом уровне и для бизнеса с новым скейлом, с учётом предыдущих ошибок. Получается, как прогрессивный джипег: можно прочитать и половину курса, и уже стать сносным архитектором для не очень сложных систем. Чтобы мысли Антона легко воспринимались в тексте, мы позвали Тимура Зарудного: это первый раз, когда мы зовём пишущего редактора, до этого были только корректоры, а редактировали мы с Марьяной.
На курсе учимся стратегическому анализу бизнеса и DDD, рассматриваем несколько архитектурных стилей, учимся выбирать БД и способы коммуникаций, писать документацию. Самый главный урок, ради которого всё задумывалось — четвёртый: в нём мы даём пошаговые рекомендации по распилу монолитов на базе теории из первых уроков.
Стартуем 12 мая, 5 уроков, 4 круга профессионализма, Q&A, чатик с Антоном и десяток котов в каждом уроке. Если дойдёте до конца — получите достаточно знаний и инструментов, чтобы проектировать системы для большинства крупных работодателей.
До 26 апреля действует промокод
K1F3N на 10% скидки. C 1 мая — повышаем цены.Смотреть программу →
#вопрос вот бывает пишешь какому-нибудь занятому чуваку, типа CEO, а он не отвечает. Как тактично напомнить о себе?
Неответ — это тоже ответ. Поищете проблемы не в занятом чуваке, а в письме. Их не так уж и много — ваше письмо скорее всего или неинтересное, или сложное.
К примеру я не отвечаю на предложения купить рекламу в этом канале — мне это просто неинтересно. Занятый CEO наверняка не ответит вам на просьбу встретиться, если подумает, что вы захотите поговорить про технологии — для него это зона ответственности CTO.
Вторая причина — на ваше письмо ответить сложно. К примеру известный блогер вряд ли ответит на предложение прийти на очередную конференцию, если из этого предложения не будет понимать, какая там аудитория, и какие спикеры уже согласились. Занятый CEO большой компании вряд ли посмотрит ваше резюме на джуниорскую позицию — он скорее всего даже не знает, куда его форварднуть.
Так что если вам не отвечают — первым делом перечитайте письмо. Как можно сделать ваше предложение более интересным? Как можно сделать ответ на ваше письмо более простым? И только после этого — напоминайте.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Неответ — это тоже ответ. Поищете проблемы не в занятом чуваке, а в письме. Их не так уж и много — ваше письмо скорее всего или неинтересное, или сложное.
К примеру я не отвечаю на предложения купить рекламу в этом канале — мне это просто неинтересно. Занятый CEO наверняка не ответит вам на просьбу встретиться, если подумает, что вы захотите поговорить про технологии — для него это зона ответственности CTO.
Вторая причина — на ваше письмо ответить сложно. К примеру известный блогер вряд ли ответит на предложение прийти на очередную конференцию, если из этого предложения не будет понимать, какая там аудитория, и какие спикеры уже согласились. Занятый CEO большой компании вряд ли посмотрит ваше резюме на джуниорскую позицию — он скорее всего даже не знает, куда его форварднуть.
Так что если вам не отвечают — первым делом перечитайте письмо. Как можно сделать ваше предложение более интересным? Как можно сделать ответ на ваше письмо более простым? И только после этого — напоминайте.
Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me
Аргумент как продавать мониторинг
Недавно убеждал одну команду установить себе нормальный APM. Основной аргумент против был «у нас есть <отечественный сервис-пинговалка>, если что-то случится, он нам сообщит».
Нормальный мониторинг по сравнению с пинговалками (не важно, отечественными или нет) — это как превентивный медосмотр против сообщения «поздравляем, вы умерли».
Мониторинг показывает проблемы в приложении задолго до того, как они выстреливают: если у вас 20% пользователей получают 500 ошибку, то с пинговалкой вы об этом не узнаете, пока она не попадёт в эти 20%. Если у вас потихоньку растёт latency у базы, вы не узнаете об этом, пока пинговалка, вместе с нормальными пользователями, не начнёт отваливаться по таймауту. Datadog, к примеру, позволяет даже не настраивать никакие триггеры — просто запускаете в нём watchdog, и он сам напишет, если что-то не так.
В общем сбор данных — это про проактивность, а алёрты «сайт упал» — про реактивность. Если у вас на работе всё ещё настроены пинговалки вместо нормального мониторинга — обязательно поговорите с CTO об этом.
Недавно убеждал одну команду установить себе нормальный APM. Основной аргумент против был «у нас есть <отечественный сервис-пинговалка>, если что-то случится, он нам сообщит».
Нормальный мониторинг по сравнению с пинговалками (не важно, отечественными или нет) — это как превентивный медосмотр против сообщения «поздравляем, вы умерли».
Мониторинг показывает проблемы в приложении задолго до того, как они выстреливают: если у вас 20% пользователей получают 500 ошибку, то с пинговалкой вы об этом не узнаете, пока она не попадёт в эти 20%. Если у вас потихоньку растёт latency у базы, вы не узнаете об этом, пока пинговалка, вместе с нормальными пользователями, не начнёт отваливаться по таймауту. Datadog, к примеру, позволяет даже не настраивать никакие триггеры — просто запускаете в нём watchdog, и он сам напишет, если что-то не так.
В общем сбор данных — это про проактивность, а алёрты «сайт упал» — про реактивность. Если у вас на работе всё ещё настроены пинговалки вместо нормального мониторинга — обязательно поговорите с CTO об этом.
В этот четверг проводим с Антоном Давыдовым стрим про будущий курс «Анализ Систем».
Мы проводим такие встречи уже год, со времён первого потока «Вы приняты» с Димой Рожковым. Для студентов — это возможность сделать превью и убрать сомнения: поговорить о формате обучения и о содержимом курса. Для нас — выровняться со студентами: всё ли хорошо рассказали на лендинге? полностью ли покрывает программа запросы?
Если сомневаетесь, стоит ли покупать курс — приходите 4 мая в 19:00. Ссылку на трансляцию выложим сюда. Записи не будет.
Мы проводим такие встречи уже год, со времён первого потока «Вы приняты» с Димой Рожковым. Для студентов — это возможность сделать превью и убрать сомнения: поговорить о формате обучения и о содержимом курса. Для нас — выровняться со студентами: всё ли хорошо рассказали на лендинге? полностью ли покрывает программа запросы?
Если сомневаетесь, стоит ли покупать курс — приходите 4 мая в 19:00. Ссылку на трансляцию выложим сюда. Записи не будет.
Достоин ли я асинхронной коммуникации?
Все хотят работать асинхронно — не быть постоянно на связи с коллегами, отвечать когда удобно, а не когда спросили, иметь большие промежутки времени на творческую работу. Но не все этого достойны.
Вообще-то начать работать асинхронно можно в любой команде — если телега\слак установлены у вас на компьютере, значит вы всегда можете их выключить или хотя бы отключить уведомления. Вопрос в том, что будет происходить во время вашего отсутствия.
Попробуйте честно ответить для себя — а достойны ли вы асинхроннной работы? Не нужно ли вас пинать, чтобы вы делали задачи вовремя? Когда вы говорите «сделал» это означает «создал пул-ревест» или «код работает на проде и влияет на метрики»? Достаточно ли ваших знаний находятся в общем пространстве, или коллегам без вас ничего не понятно?
Если что-то из этого в беспорядке — будет тяжело даже отключить уведомления: вас всё равно найдут и заставят общаться. А если всё в порядке — скорее всего никто и не заметит вашего отсутствия. Серьёзно — я видел ребят, которые асинхронно работают в совершенно синхронных офисных командах просто потому, что свято соблюдают принцип «пацан сказал — пацан сделал».
Все хотят работать асинхронно — не быть постоянно на связи с коллегами, отвечать когда удобно, а не когда спросили, иметь большие промежутки времени на творческую работу. Но не все этого достойны.
Вообще-то начать работать асинхронно можно в любой команде — если телега\слак установлены у вас на компьютере, значит вы всегда можете их выключить или хотя бы отключить уведомления. Вопрос в том, что будет происходить во время вашего отсутствия.
Попробуйте честно ответить для себя — а достойны ли вы асинхроннной работы? Не нужно ли вас пинать, чтобы вы делали задачи вовремя? Когда вы говорите «сделал» это означает «создал пул-ревест» или «код работает на проде и влияет на метрики»? Достаточно ли ваших знаний находятся в общем пространстве, или коллегам без вас ничего не понятно?
Если что-то из этого в беспорядке — будет тяжело даже отключить уведомления: вас всё равно найдут и заставят общаться. А если всё в порядке — скорее всего никто и не заметит вашего отсутствия. Серьёзно — я видел ребят, которые асинхронно работают в совершенно синхронных офисных командах просто потому, что свято соблюдают принцип «пацан сказал — пацан сделал».
#вопрос Почему ты делаешь из vim IDE, хотя есть готовые IDE, в которые можно вставить vim?
Вообще я уже сейчас уже совсем мало пишу кода, но попробую ответить из полугодичной давности.
Во-первых, потому что могу. Несмотря на любовь к программированию и то, что я сам себе выбираю задачи — эта работа бывает для меня скучной, а значит выматывающей. Когда я беру в руки инструмент, в котором я сам сконфигурил все нюансы, то получаю гораздо больше удовольствия, а значит меньше скучаю и меньше трачу сил.
Во-вторых, мне очень важна скорость и энергоэффективность. Скорость — потому что я ненавижу системы с плохим дизайном, которые тратят моё время на свои проблемы. Проиндексировать проект или загрузить все плагины — это работа IDE, а не моя. Так почему я должен этого ждать?
С энергоэффективностью тоже всё просто — я люблю покодить в кафе. Возможно на M1 всё стало побыстрее, не знаю — ни разу не запускал на нём ничего тяжёлого.
В любом случае я не призываю никого использовать редакторы текста вместо IDE — у нас в fands, к примеру, больше половины сотрудников пользуются продуктами jetbrains. Главное, в обоих случаях, — не жалеть времени на настройку инструментов.
Это был традиционный ответ на вопрос по понедельникам. Задать свой — fborshev@pm.me
Вообще я уже сейчас уже совсем мало пишу кода, но попробую ответить из полугодичной давности.
Во-первых, потому что могу. Несмотря на любовь к программированию и то, что я сам себе выбираю задачи — эта работа бывает для меня скучной, а значит выматывающей. Когда я беру в руки инструмент, в котором я сам сконфигурил все нюансы, то получаю гораздо больше удовольствия, а значит меньше скучаю и меньше трачу сил.
Во-вторых, мне очень важна скорость и энергоэффективность. Скорость — потому что я ненавижу системы с плохим дизайном, которые тратят моё время на свои проблемы. Проиндексировать проект или загрузить все плагины — это работа IDE, а не моя. Так почему я должен этого ждать?
С энергоэффективностью тоже всё просто — я люблю покодить в кафе. Возможно на M1 всё стало побыстрее, не знаю — ни разу не запускал на нём ничего тяжёлого.
В любом случае я не призываю никого использовать редакторы текста вместо IDE — у нас в fands, к примеру, больше половины сотрудников пользуются продуктами jetbrains. Главное, в обоих случаях, — не жалеть времени на настройку инструментов.
Это был традиционный ответ на вопрос по понедельникам. Задать свой — fborshev@pm.me
Анализ систем: стартуем в пятницу!
12 мая, в эту пятницу, мы стартуем новый курс с Антоном Давыдовым — Анализ Систем.
Для меня курс — об осознанном проектировании систем. Каждый программист рано или поздно проектирует системы, но единицы делают это, понимая что происходит: большинство почему-то думает не от бизнеса, а от технологий, которые услышали на последней конференции.
На курсе учимся стратегическому анализу бизнеса и DDD, рассматриваем несколько архитектурных стилей, учимся выбирать БД и способы коммуникации, работать со стейкхолдерами и писать документацию. Самый главный урок, ради которого всё задумывалось — четвёртый: в нём мы даём пошаговые рекомендации по распилу монолитов на базе теории из первых уроков. Отдельная гордость Антона — несколько сотен ссылок на дополнительные материалы, если захотите углубиться в какую-то из тем. Хватит на год вперед.
Джунам курс не подойдёт. Мидлам подойдёт. Если есть, где применить полученные знания, или просто очень интересуетесь проектированиям — обязательно берите тарифы с обратной связью. Синьёрам, помидорам, принципалам и CTO пойдёт в любом случае.
Стартуем в пятницу,есть ещё одно VIP-место с личной обратной связью и консультацией.
Смотреть программу →
12 мая, в эту пятницу, мы стартуем новый курс с Антоном Давыдовым — Анализ Систем.
Для меня курс — об осознанном проектировании систем. Каждый программист рано или поздно проектирует системы, но единицы делают это, понимая что происходит: большинство почему-то думает не от бизнеса, а от технологий, которые услышали на последней конференции.
На курсе учимся стратегическому анализу бизнеса и DDD, рассматриваем несколько архитектурных стилей, учимся выбирать БД и способы коммуникации, работать со стейкхолдерами и писать документацию. Самый главный урок, ради которого всё задумывалось — четвёртый: в нём мы даём пошаговые рекомендации по распилу монолитов на базе теории из первых уроков. Отдельная гордость Антона — несколько сотен ссылок на дополнительные материалы, если захотите углубиться в какую-то из тем. Хватит на год вперед.
Джунам курс не подойдёт. Мидлам подойдёт. Если есть, где применить полученные знания, или просто очень интересуетесь проектированиям — обязательно берите тарифы с обратной связью. Синьёрам, помидорам, принципалам и CTO пойдёт в любом случае.
Стартуем в пятницу,
Смотреть программу →
Марьяна завела себе прикольную традицию — одной строкой рассказывать, как у неё в проектах идут дела, что нового\интересного случилось. Давайте попробуем это здесь?
— С Саматом доросли до двух ключевых клиентов и 20 человек в компании. За год мы выросли в два раза и не упали в качестве. Хоть и прощаемся сейчас с одним из клиентов — будем расти дальше.
— Запустили обучение на выстраданном курс «Анализ Систем». Материалами я доволен, хотя и недоволен количеством усилий, которое мы на них потратили: за год над текстами поработало 6 (!) человек, для нас это очень много.
— LMS: новая LMS в школе работает офигенно — у студентов нет вопросов, материалы рендерятся приятно глазам. Конечно огрехи есть, но они понятные, и их список — конечен.
— Недавно мы со своим хождением в приватное API ноушена стали попадать под капчу клаудфлера. Справились быстро, немного посомневались в идее юзать ноушен как бекенд для LMS, но решили что всё делаем правильно. Сейчас планируем ещё ряд продуктовых доработок.
— Сделал бухгалтерское открытие — оказывается в нашей стране электронный документооборот работает не только для юрлиц. Внедряем Контур.КЭДО, чтобы без бумаг обмениваться документами с сотрудниками. Горжусь что спрятал от команды ещё один бюрократический препон.
— С Саматом доросли до двух ключевых клиентов и 20 человек в компании. За год мы выросли в два раза и не упали в качестве. Хоть и прощаемся сейчас с одним из клиентов — будем расти дальше.
— Запустили обучение на выстраданном курс «Анализ Систем». Материалами я доволен, хотя и недоволен количеством усилий, которое мы на них потратили: за год над текстами поработало 6 (!) человек, для нас это очень много.
— LMS: новая LMS в школе работает офигенно — у студентов нет вопросов, материалы рендерятся приятно глазам. Конечно огрехи есть, но они понятные, и их список — конечен.
— Недавно мы со своим хождением в приватное API ноушена стали попадать под капчу клаудфлера. Справились быстро, немного посомневались в идее юзать ноушен как бекенд для LMS, но решили что всё делаем правильно. Сейчас планируем ещё ряд продуктовых доработок.
— Сделал бухгалтерское открытие — оказывается в нашей стране электронный документооборот работает не только для юрлиц. Внедряем Контур.КЭДО, чтобы без бумаг обмениваться документами с сотрудниками. Горжусь что спрятал от команды ещё один бюрократический препон.
Насколько вам интересно такое читать? Если интересно — вернусь с апдейтами через месяц
Anonymous Poll
61%
Интересно!
25%
Норм
14%
Неинтересно, не занимай место
Тимлидская папка
Тут в ребята собрали папку с 15 телеграм-каналами для тимлидов. Я там тоже есть — кайф! Почитав папку, немного улучшил кругозор — кажется теперь я больше знаю, о чём болит голова у русскоязычных тимлидов и сочувствующих.
По ссылке можно сразу подписаться на все. Если беситесь от красных кружочков — выделите 30 минут, почитайте все каналы и подпишитесь на те, в которых найдёте что-нибудь непривычное или непонятное. Привычные и понятные каналы точно добавлять не стоит — нафига вам красные кружочки с тем, что вы уже знаете? :-)
Тут в ребята собрали папку с 15 телеграм-каналами для тимлидов. Я там тоже есть — кайф! Почитав папку, немного улучшил кругозор — кажется теперь я больше знаю, о чём болит голова у русскоязычных тимлидов и сочувствующих.
По ссылке можно сразу подписаться на все. Если беситесь от красных кружочков — выделите 30 минут, почитайте все каналы и подпишитесь на те, в которых найдёте что-нибудь непривычное или непонятное. Привычные и понятные каналы точно добавлять не стоит — нафига вам красные кружочки с тем, что вы уже знаете? :-)