Даже в чатах можно общаться нормально, если писать длинные сообщения
Важное открытие последних месяцев — оказывается, общаться в слаке бывает просто невыносимо, а бывает чуть менее невыносимо.
Просто невыносимо — это когда по работе ты общаешься так же, как с друзьями договариваешься пойти пиво в пятницу вечером: перекидываешься короткими сообщениями, а компьютер (и телефон!) постоянно пиликает уведомлениями, и вообще происходит всё то же, что я описывал в старом посте про слак и продуктивность.
Чуть менее невыносимо — это когда ты общаешься так же, как в почте: развёрнутыми понятными письмами с драматургией и колл-ту-экшенами, только письма эти пишешь в чате, а не в почте. Возьмите на вооружение, если цените своё внимание, но попали в команду, которая использует слак вместо электронной почты.
Важное открытие последних месяцев — оказывается, общаться в слаке бывает просто невыносимо, а бывает чуть менее невыносимо.
Просто невыносимо — это когда по работе ты общаешься так же, как с друзьями договариваешься пойти пиво в пятницу вечером: перекидываешься короткими сообщениями, а компьютер (и телефон!) постоянно пиликает уведомлениями, и вообще происходит всё то же, что я описывал в старом посте про слак и продуктивность.
Чуть менее невыносимо — это когда ты общаешься так же, как в почте: развёрнутыми понятными письмами с драматургией и колл-ту-экшенами, только письма эти пишешь в чате, а не в почте. Возьмите на вооружение, если цените своё внимание, но попали в команду, которая использует слак вместо электронной почты.
Forwarded from запуск завтра
Мы с Федей ищем технического директора в igooods себе на замену.
igooods — это доставка продуктов из гипермаркетов. Сотни тысяч клиентов, тысячи заказов в день, миллиард оборота в месяц. 36 городов России. В партнерах — Метро, Лента, Призма, Вкусвилл, Ашан, Глобус, Карусель, Окей.
Техническая команда — 31 человек. Под капотом рельса и реакт, нативные мобильные приложения для iOS и Android.
Вы заберёте разработку, которая находится в процессе трансформации от небольшой уютной тусовки к машине по зарабатыванию денег. За последние полгода производство стало работать чётче, но до швейцарских часов ему пока далеко — много вещей делаются на ручном контроле. Вам предстоит выстроить QA, доукомплековать продуктовые команды, до конца перейти на сервисную архитектуру (цель — через полгода перестать писать код в монолит) и создать систему управления техдолгом.
Вторая задача — подчинить разработку бизнесу, работая бок о бок с CPO. Каждый джуниор-фронтендер должен знать, на какую метрику повлияет задача, которую он сейчас делает, а любая гипотеза про деньги должна проверяться не дольше трёх недель.
Мы с Федей запустили эти процессы, но чтобы завершить работу, нужно жить в Питере.
Команда прекрасная, но это не значит, что вам не придется много работать руками. Оно того стоит — вы выстроите первоклассную разработку в одном из крупнейших сервисов доставки продуктов в России.
Офис в Питере, помощь с переездом. Подчинение напрямую владельцу бизнеса; основной рабочий партнер — CPO Андрей Родин.
Пишите краткий рассказ о себе мне в личку или на s@samat.me.
igooods — это доставка продуктов из гипермаркетов. Сотни тысяч клиентов, тысячи заказов в день, миллиард оборота в месяц. 36 городов России. В партнерах — Метро, Лента, Призма, Вкусвилл, Ашан, Глобус, Карусель, Окей.
Техническая команда — 31 человек. Под капотом рельса и реакт, нативные мобильные приложения для iOS и Android.
Вы заберёте разработку, которая находится в процессе трансформации от небольшой уютной тусовки к машине по зарабатыванию денег. За последние полгода производство стало работать чётче, но до швейцарских часов ему пока далеко — много вещей делаются на ручном контроле. Вам предстоит выстроить QA, доукомплековать продуктовые команды, до конца перейти на сервисную архитектуру (цель — через полгода перестать писать код в монолит) и создать систему управления техдолгом.
Вторая задача — подчинить разработку бизнесу, работая бок о бок с CPO. Каждый джуниор-фронтендер должен знать, на какую метрику повлияет задача, которую он сейчас делает, а любая гипотеза про деньги должна проверяться не дольше трёх недель.
Мы с Федей запустили эти процессы, но чтобы завершить работу, нужно жить в Питере.
Команда прекрасная, но это не значит, что вам не придется много работать руками. Оно того стоит — вы выстроите первоклассную разработку в одном из крупнейших сервисов доставки продуктов в России.
Офис в Питере, помощь с переездом. Подчинение напрямую владельцу бизнеса; основной рабочий партнер — CPO Андрей Родин.
Пишите краткий рассказ о себе мне в личку или на s@samat.me.
А какую я добавил ценность?
Хороший менеджер задаёт этот вопрос во время каждой своей активности.
Какую ценность я добавил, когда сходил на встречу? Был ли полезен, принёс что-то новое или тупил в фейсбук?
Какую ценность я добавил, когда ответил на письмо? Легче ли стало совершить следующий шаг по проекту?
Какую ценность я добавил, когда поговорил с программистом? Стало ли ему понятнее, что и как делать на проекте?
Какую ценность я добавил за неделю руководства отделом? А за месяц?
Если нечего ответить, значит пора переставать заниматься деятельностью, которая не приносит ценности: отказаться от встреч с командой, которой ты не нужен, не слать пустые отписки на письма, не отвлекать программистов. Или просто отдохнуть.
Хороший менеджер задаёт этот вопрос во время каждой своей активности.
Какую ценность я добавил, когда сходил на встречу? Был ли полезен, принёс что-то новое или тупил в фейсбук?
Какую ценность я добавил, когда ответил на письмо? Легче ли стало совершить следующий шаг по проекту?
Какую ценность я добавил, когда поговорил с программистом? Стало ли ему понятнее, что и как делать на проекте?
Какую ценность я добавил за неделю руководства отделом? А за месяц?
Если нечего ответить, значит пора переставать заниматься деятельностью, которая не приносит ценности: отказаться от встреч с командой, которой ты не нужен, не слать пустые отписки на письма, не отвлекать программистов. Или просто отдохнуть.
#вопрос Реально ли стартануть в качестве начинающего программиста в 50 лет?
У меня, к сожалению, нет успешных историй на эту тему, но мне кажется, что вполне реально. Всё, что нужно, чтобы стать программистом, лежит на поверхности: интерпретатор ставится за 5 минут на любой компьютер, а книги по-прежнему продаются в интернет-магазинах.
Я не вижу ни одного препятствия, чтобы выполнить 5 из 6 пунктов из моего списка как вкатить в программирование. Предположу, что проблема будет только с шестым пунктом — найти команду с высокой инженерной культурой: эйджизм, сексизм и кучу других -измов никто не отменял.
Единственный вариант, который я вижу, — повысить свою ценность до устройства на работу. Попробуйте сделать такое крутое портфолио, которое только можете, — много наконтрибьютьте в опенсорс или напишите какой-нибудь большой сложный проект, больше чем стандартный todo-mvc. Это тяжёлый путь: пойти джуном в нормальную компанию гораздо легче. Зато этот путь зависит целиком от вашего желания, а не от предрассудков окружающих.
Надеюсь, у вас всё получится!
У меня, к сожалению, нет успешных историй на эту тему, но мне кажется, что вполне реально. Всё, что нужно, чтобы стать программистом, лежит на поверхности: интерпретатор ставится за 5 минут на любой компьютер, а книги по-прежнему продаются в интернет-магазинах.
Я не вижу ни одного препятствия, чтобы выполнить 5 из 6 пунктов из моего списка как вкатить в программирование. Предположу, что проблема будет только с шестым пунктом — найти команду с высокой инженерной культурой: эйджизм, сексизм и кучу других -измов никто не отменял.
Единственный вариант, который я вижу, — повысить свою ценность до устройства на работу. Попробуйте сделать такое крутое портфолио, которое только можете, — много наконтрибьютьте в опенсорс или напишите какой-нибудь большой сложный проект, больше чем стандартный todo-mvc. Это тяжёлый путь: пойти джуном в нормальную компанию гораздо легче. Зато этот путь зависит целиком от вашего желания, а не от предрассудков окружающих.
Надеюсь, у вас всё получится!
Цель встречи
Отличный способ сэкономить время на любой встрече — это писать её цель. Типа «я сейчас иду к заказчику, чтобы договориться об изменении вот этих требований: раз, два, три». Или «я выступаю перед командой, чтобы донести вот эти, эти и эти мысли». Или «Я созваниваюсь 1:1, чтобы узнать, насколько мой сотрудник чувствует себя счастливым в рамках текущего проекта».
Цель — это не агенда: скорее это внутренняя задача, не достигнув которой со встречи лучше не уходить.
Такая внутренняя цель здорово сокращает время: имея перед глазами конкретную задачу, вы будете меньше отклоняться от повестки. А ещё, чётко сформулировав цель, иногда понимаешь, что встречу лучше не проводить или проводить в другом формате. К примеру, понимаешь, что вместо того, чтобы посадить двух человек в одну комнату, занимаешься челночной дипломатией, договариваясь с каждым в отдельности, или созываешь встречу на тему, на которую лучше написать письмо.
Дополнение от Марьяны Онысько: «А еще, когда ты прописываешь цель встречи, то становится понятно, нужна ли она вообще. Иногда вопрос решается просто парой сообщений в чате»
Отличный способ сэкономить время на любой встрече — это писать её цель. Типа «я сейчас иду к заказчику, чтобы договориться об изменении вот этих требований: раз, два, три». Или «я выступаю перед командой, чтобы донести вот эти, эти и эти мысли». Или «Я созваниваюсь 1:1, чтобы узнать, насколько мой сотрудник чувствует себя счастливым в рамках текущего проекта».
Цель — это не агенда: скорее это внутренняя задача, не достигнув которой со встречи лучше не уходить.
Такая внутренняя цель здорово сокращает время: имея перед глазами конкретную задачу, вы будете меньше отклоняться от повестки. А ещё, чётко сформулировав цель, иногда понимаешь, что встречу лучше не проводить или проводить в другом формате. К примеру, понимаешь, что вместо того, чтобы посадить двух человек в одну комнату, занимаешься челночной дипломатией, договариваясь с каждым в отдельности, или созываешь встречу на тему, на которую лучше написать письмо.
Дополнение от Марьяны Онысько: «А еще, когда ты прописываешь цель встречи, то становится понятно, нужна ли она вообще. Иногда вопрос решается просто парой сообщений в чате»
#вакансия
Продакт и проджект в igooods
Мы ищем двух менеджеров:
— Продакт на поиск и сервис рекомендаций
— Проджект в команду ритейла
Работа в офисе в Питере. Денег — норм, офис отличный, коллектив — огонь, остальные подробности — по ссылкам.
Продакт и проджект в igooods
Мы ищем двух менеджеров:
— Продакт на поиск и сервис рекомендаций
— Проджект в команду ритейла
Работа в офисе в Питере. Денег — норм, офис отличный, коллектив — огонь, остальные подробности — по ссылкам.
FEDOR BORSHEV
#вакансия Продакт и проджект в igooods Мы ищем двух менеджеров: — Продакт на поиск и сервис рекомендаций — Проджект в команду ритейла Работа в офисе в Питере. Денег — норм, офис отличный, коллектив — огонь, остальные подробности — по ссылкам.
Упс, ссылка на продакта неправильная, правильная — http://bit.ly/igooods-product-fix
igooods on Notion
Продакт-менеджер в Поиск | Notion
Кто нам нужен
Эволюция парольных менеджеров
Моим первым менеджером паролей был KeePassX. Гиковская штуковина — пароли хранятся в локальном файле, файл можно синхронизировать чем угодно, к примеру Dropbox или ownCloud, если вы параноик.
Потом было два года Dashlane — красивого монстра со встроенным VPN и мониторингом дарквеба. К сожалению, за красотой скрывалась очень кривая реализация: автозаполнение (главная функция парольного менеджера) иногда просто переставало работать. Больше всего меня бесил театр безопасности, когда меня просили ввести цифры с картинки, чтобы «авторизовать» браузер. При этом, если цифры не вводить, всё продолжало работать.
В какой-то момент я настолько начал страдать от Dashlane, что всерьёз рассматривал переход на Bitwarden — кто не знает, это такая система хранения паролей для собственного сервера.
В итоге после очередной перезагрузки из-за зависшего менеджера паролей я перешёл на 1Password: менее красивый, но надёжный как топор. Автозаполнение работает везде, кроме сайта Тинькофф, синхронизируется моментально, не зависало вообще ни разу. Уже третий год на нём, очень советую.
Моим первым менеджером паролей был KeePassX. Гиковская штуковина — пароли хранятся в локальном файле, файл можно синхронизировать чем угодно, к примеру Dropbox или ownCloud, если вы параноик.
Потом было два года Dashlane — красивого монстра со встроенным VPN и мониторингом дарквеба. К сожалению, за красотой скрывалась очень кривая реализация: автозаполнение (главная функция парольного менеджера) иногда просто переставало работать. Больше всего меня бесил театр безопасности, когда меня просили ввести цифры с картинки, чтобы «авторизовать» браузер. При этом, если цифры не вводить, всё продолжало работать.
В какой-то момент я настолько начал страдать от Dashlane, что всерьёз рассматривал переход на Bitwarden — кто не знает, это такая система хранения паролей для собственного сервера.
В итоге после очередной перезагрузки из-за зависшего менеджера паролей я перешёл на 1Password: менее красивый, но надёжный как топор. Автозаполнение работает везде, кроме сайта Тинькофф, синхронизируется моментально, не зависало вообще ни разу. Уже третий год на нём, очень советую.
#вопрос Стоит ли менять работу, если уже порядком поднадоело, но есть новые проекты и в целом хоть какой‑то прогресс ощутим?
В бюро вышел мой новый совет — рассказываю про FOMO при смене места работы.
В бюро вышел мой новый совет — рассказываю про FOMO при смене места работы.
Самат сделал классный обзор инструментов для рисования диаграмм и рассказал, как мы применяем их в разработке igooods.
Накидаете в комментах своих инструментов?
Накидаете в комментах своих инструментов?
vc.ru
С помощью диаграмм можно объяснить что угодно. Тем более для этого есть классные инструменты — Сервисы на vc.ru
Язык коммуникации, о котором все забывают.
#вопрос Я руководитель web-разработки и собираюсь перейти в другую компанию, где будет другая команда и другие проекты. Как можно смягчить и сделать этот переход наиболее комфортным с точки зрения стресса?
Кажется, самый большой источник фрустрации для руководителя, который приходит в новую команду, — это сама команда. Люди ставят не те статусы в жире, пишут код по airbnb вместо standard, беспокоятся о непривычных проблемах, а по пятницам пьют стауты вместо IPA. Самое главное — не начать судорожно это всё менять.
Вот представьте сами — команда привыкла к трёхнедельным спринтам, а вы такой на белом коне, вооружившись словами вроде «декомпозиция», меняете спринты на недельные. И уже потом выясняете, что спринты такие длинные потому, что команда пилит только большие задачи, а на срочные и мелкие есть отдельная линия саппорта, которая вообще работает по канбану.
Или ещё хуже — команда работает по трёхнедельным спринтам, а вы привыкли к недельным, но менять боитесь (как бы чего не вышло) и страдаете.
Первый шаг в новой команде — это привыкнуть: не пытаться что-то поменять в первую же неделю, а понять и с уважением принять текущий процесс и привычки. То есть сначала научиться играть по их правилам, а потом уже внедрять свои. Если у вас нет аллергии к русскому селф-хелпу, почитайте на эту тему 45 татуировок менеджера — там есть целая глава про это.
Кажется, самый большой источник фрустрации для руководителя, который приходит в новую команду, — это сама команда. Люди ставят не те статусы в жире, пишут код по airbnb вместо standard, беспокоятся о непривычных проблемах, а по пятницам пьют стауты вместо IPA. Самое главное — не начать судорожно это всё менять.
Вот представьте сами — команда привыкла к трёхнедельным спринтам, а вы такой на белом коне, вооружившись словами вроде «декомпозиция», меняете спринты на недельные. И уже потом выясняете, что спринты такие длинные потому, что команда пилит только большие задачи, а на срочные и мелкие есть отдельная линия саппорта, которая вообще работает по канбану.
Или ещё хуже — команда работает по трёхнедельным спринтам, а вы привыкли к недельным, но менять боитесь (как бы чего не вышло) и страдаете.
Первый шаг в новой команде — это привыкнуть: не пытаться что-то поменять в первую же неделю, а понять и с уважением принять текущий процесс и привычки. То есть сначала научиться играть по их правилам, а потом уже внедрять свои. Если у вас нет аллергии к русскому селф-хелпу, почитайте на эту тему 45 татуировок менеджера — там есть целая глава про это.
Обойти сбоку
Когда мы запускали UIG, я потратил 4 часа на одну простую задачу — закрыть демосайт на Basic-авторизацию. Дело в том, что у нас внутри уже был свой механизм авторизации на JWT, и фронтенд слал эти самые JWT прямо в HTTP-хедере Authorization. Basic-авторизация точно так же использует этот хедер, посылая там логин и пароль, которые вы вводите в стандартное окно. Получился конфликт: фронтенд хочет послать один заголовок Authorization, а браузер — другой. Вылезла куча проблем — то сайт отваливался на мобилках, то бекенд отвечал 403 при SSR.
Я попробовал кучу разных вариантов, от установки nginx (которого изначально в архитектуре не было) и до того, что написал прослойку для express, которая вырезала хедер Authorization так, чтобы его видел только стоящий выше traefik. В итоге, потратив 4 часа, я предпочёл объяснить заказчику, что сайт мы, скорее всего, закрыть не сможем — так и забили, висели с открытой демкой.
А потом пришёл Самат и за 5 минут прямо на встрече предложил сделать дополнительную авторизацию не Basic, а просто на куках: всех дел на 15 минут.
В этой ситуации я повёл себя как плохой программист: увидел проблему (два хедера Authorization) и пошёл её решать, размахивая всеми инструментами, которые только знаю. Самат повёл себя как менеджер: не владея горой инструментов, он просто обошёл проблему сбоку.
Когда в следующий раз код, который вы пилите, покажется вам сложным или решения вашей проблемы не будет на первой странице гугля, подумайте — а то ли вы вообще делаете? Может, можно обойти сбоку? Поступаете ли вы как плохой программист или как хороший менеджер?
Когда мы запускали UIG, я потратил 4 часа на одну простую задачу — закрыть демосайт на Basic-авторизацию. Дело в том, что у нас внутри уже был свой механизм авторизации на JWT, и фронтенд слал эти самые JWT прямо в HTTP-хедере Authorization. Basic-авторизация точно так же использует этот хедер, посылая там логин и пароль, которые вы вводите в стандартное окно. Получился конфликт: фронтенд хочет послать один заголовок Authorization, а браузер — другой. Вылезла куча проблем — то сайт отваливался на мобилках, то бекенд отвечал 403 при SSR.
Я попробовал кучу разных вариантов, от установки nginx (которого изначально в архитектуре не было) и до того, что написал прослойку для express, которая вырезала хедер Authorization так, чтобы его видел только стоящий выше traefik. В итоге, потратив 4 часа, я предпочёл объяснить заказчику, что сайт мы, скорее всего, закрыть не сможем — так и забили, висели с открытой демкой.
А потом пришёл Самат и за 5 минут прямо на встрече предложил сделать дополнительную авторизацию не Basic, а просто на куках: всех дел на 15 минут.
В этой ситуации я повёл себя как плохой программист: увидел проблему (два хедера Authorization) и пошёл её решать, размахивая всеми инструментами, которые только знаю. Самат повёл себя как менеджер: не владея горой инструментов, он просто обошёл проблему сбоку.
Когда в следующий раз код, который вы пилите, покажется вам сложным или решения вашей проблемы не будет на первой странице гугля, подумайте — а то ли вы вообще делаете? Может, можно обойти сбоку? Поступаете ли вы как плохой программист или как хороший менеджер?
Запись стрима в прошлый понедельник
У меня наконец дошли руки добавить тайм-кодов, так что ловите запись.
Вот, что было интересного:
02:53 Как работаешь с техдолгом в команде?
08:50 Как планировать спринты, чтобы всё успевать?
11:01 Как выращивать людей в команде?
14:31 Что делать с легаси? Пример igooods
20:45 Как разработчику увеличить свой доход в 10 раз?
26:42 Получилось ли с Саматом заработать кучу денег?
27:04 Когда лучше брать джунов,
31:19 Как архитектурно правильно начинать новый проект?
37:24 Как следишь за производительностью программистов в команде?
40:41 Как видишь перспективы развития no-code?
45:54 Как понять, что у проекта исчерпывающая документация?
47:23 Где искать мотивацию работать, когда начинаешь ненавидеть проект?
51:44 Нет хобби кроме работы
52:24 Что значит взять на себя ответственность? Как и чем отвечать за неудачу?
57:46 Что будет с фронтендом и бекендом через 20–30 лет?
59:52 Куда лучше пойти джуну — на галеру или в стартап?
01:02:22 Переквалифицироваться в программисты после 40, миф или реальность?
01:05:36 Как тимлиду правильно устроить процесс делегирования задач, чтобы самому всё не контролировать?
01:08:45 Как развиваться project-менеджеру? Будет ли профессия актуальна в будущем?
01:10:29 Как продакту понять, о чём говорят разработчики?
01:12:16 Как думаешь, схлопнется ли скоро пузырь AI и ML?
01:14:30 Как совмещать семью и работу?
01:15:54 Как лучше учиться фундаментальным знаниям? Посоветуешь доступные гуманитарию книги и курсы?
01:18:18 Как найти и распознать техлида, способного лидить бек, фронт и тест-активности?
01:21:45 Важна ли декомпозиция задач, или это вмешательство в художественный процесс разработки?
01:25:19 Куда и как развиваться синьёру (в техническом плане)?
01:26:45 Инвестириуешь? Через какого брокера? В кого?
01:28:10 Что делать, если понимаешь, что коллеги технически не растут?
01:30:29 Как ты повышаешь у разработчиков ответственность за задачи?
01:32:39 В чём тебе стоило бы улучшить свои навыки? Какие области роста видишь у себя?
01:36:27 Как онбордить новых разработчиков, если документации и сервисов с интеграциями очень много?
01:37:20 Резко упало качество и скорость разработки, выросла сложность задач. Что делать?
01:39:08 Девопс в команде. Дань хайпу или есть польза?
01:41:20 Какие технические знания не устареют через 10 лет?
01:42:14 Есть ли жизнь без скрама и спринтов?
01:43:21 Как проджект-менеджеру перейти во фронтенд? Может сначала в QA?
01:44:11 Как ты вёл два беклога, для бизнеса в трелло, а для команды — в гитхабе?
01:46:53 Что такое высокая инженерная культура и как её распознать?
01:49:52 Как выбираешь на чём сфокусировать команду в устаревающем проекте на саппорте?
01:50:34 Как приучал себя к регулярным повторяющимся активностям, таким как блог или телеграм?
01:51:41 Можно ли долго вести проект без код-ревью? Как уменьшить временные затраты на этот этап?
01:53:44 О чём писать в блоге разработчика?
Честно говоря, я крайне не доволен стримом — пересматривая запись я понимаю, что мог бы ответить гораздо полнее и интереснее. Ну, ничего страшного — теперь я знаю, как готовиться, поэтому через пару недель устроим ещё один.
Ну и спасибо всем, кто пришёл!
У меня наконец дошли руки добавить тайм-кодов, так что ловите запись.
Вот, что было интересного:
02:53 Как работаешь с техдолгом в команде?
08:50 Как планировать спринты, чтобы всё успевать?
11:01 Как выращивать людей в команде?
14:31 Что делать с легаси? Пример igooods
20:45 Как разработчику увеличить свой доход в 10 раз?
26:42 Получилось ли с Саматом заработать кучу денег?
27:04 Когда лучше брать джунов,
31:19 Как архитектурно правильно начинать новый проект?
37:24 Как следишь за производительностью программистов в команде?
40:41 Как видишь перспективы развития no-code?
45:54 Как понять, что у проекта исчерпывающая документация?
47:23 Где искать мотивацию работать, когда начинаешь ненавидеть проект?
51:44 Нет хобби кроме работы
52:24 Что значит взять на себя ответственность? Как и чем отвечать за неудачу?
57:46 Что будет с фронтендом и бекендом через 20–30 лет?
59:52 Куда лучше пойти джуну — на галеру или в стартап?
01:02:22 Переквалифицироваться в программисты после 40, миф или реальность?
01:05:36 Как тимлиду правильно устроить процесс делегирования задач, чтобы самому всё не контролировать?
01:08:45 Как развиваться project-менеджеру? Будет ли профессия актуальна в будущем?
01:10:29 Как продакту понять, о чём говорят разработчики?
01:12:16 Как думаешь, схлопнется ли скоро пузырь AI и ML?
01:14:30 Как совмещать семью и работу?
01:15:54 Как лучше учиться фундаментальным знаниям? Посоветуешь доступные гуманитарию книги и курсы?
01:18:18 Как найти и распознать техлида, способного лидить бек, фронт и тест-активности?
01:21:45 Важна ли декомпозиция задач, или это вмешательство в художественный процесс разработки?
01:25:19 Куда и как развиваться синьёру (в техническом плане)?
01:26:45 Инвестириуешь? Через какого брокера? В кого?
01:28:10 Что делать, если понимаешь, что коллеги технически не растут?
01:30:29 Как ты повышаешь у разработчиков ответственность за задачи?
01:32:39 В чём тебе стоило бы улучшить свои навыки? Какие области роста видишь у себя?
01:36:27 Как онбордить новых разработчиков, если документации и сервисов с интеграциями очень много?
01:37:20 Резко упало качество и скорость разработки, выросла сложность задач. Что делать?
01:39:08 Девопс в команде. Дань хайпу или есть польза?
01:41:20 Какие технические знания не устареют через 10 лет?
01:42:14 Есть ли жизнь без скрама и спринтов?
01:43:21 Как проджект-менеджеру перейти во фронтенд? Может сначала в QA?
01:44:11 Как ты вёл два беклога, для бизнеса в трелло, а для команды — в гитхабе?
01:46:53 Что такое высокая инженерная культура и как её распознать?
01:49:52 Как выбираешь на чём сфокусировать команду в устаревающем проекте на саппорте?
01:50:34 Как приучал себя к регулярным повторяющимся активностям, таким как блог или телеграм?
01:51:41 Можно ли долго вести проект без код-ревью? Как уменьшить временные затраты на этот этап?
01:53:44 О чём писать в блоге разработчика?
Честно говоря, я крайне не доволен стримом — пересматривая запись я понимаю, что мог бы ответить гораздо полнее и интереснее. Ну, ничего страшного — теперь я знаю, как готовиться, поэтому через пару недель устроим ещё один.
Ну и спасибо всем, кто пришёл!
YouTube
Fedor Borshev Live — Стрим без темы #1
Общаемся на свободные темы.
02:53 Как работаешь с техдолгом в команде?
08:50 Как планировать спринты, чтобы всё успевать?
11:01 Как выращивать людей в команде?
14:31 Что делать с легаси? Пример igooods
20:45 Как разработчику увеличить свой доход в 10 раз?…
02:53 Как работаешь с техдолгом в команде?
08:50 Как планировать спринты, чтобы всё успевать?
11:01 Как выращивать людей в команде?
14:31 Что делать с легаси? Пример igooods
20:45 Как разработчику увеличить свой доход в 10 раз?…
Форма vs. содержание: Netflix vs. Кинопаб
Первым онлайн-кинотеатром, которым я воспользовался, был Кинопаб. Круто же — можно сразу смотреть любой фильм, хочешь — на английском, хочешь — хоть с китайскими субтитрами. Даже если фильм ещё не вышел — пожалуйста: смотри экранку. Примерно через пару месяцев я перешёл с Кинопаба на Netflix. Казалось бы, это полная противоположность: фильмов в русском Нетфликсе гораздо меньше, чем в тех же ivi или okko. Но Netflix определённо подошёл мне больше.
Дело в том, что все пять раз, когда я за эти два месяца хотел посмотреть фильм, я наталкивался на какие-то проблемы: то приложение не включается, потому что заблокировали ДНС, то фильм запускается два минуты и затем постоянно прерывается (или вообще начинает играть заново), чтобы оплатить, нужно пройти 10 шагов, которые потом приходится повторять каждый месяц. Вместо трейлера мне почему-то показывают сам фильм, а вместо фильма — наоборот, трейлер. В рекомендациях мне подсовывают какую-то фигню.
У Нетфликса всё наоборот — у тебя с самого начала спрашивают, что ты любишь, а затем устраивают бесшовный опыт: просто бесконечно показывают то, что интересно. Сначала я страдал, думал, как же так: а если я захочу посмотреть какой-то фильм, которого нет на Нетфликсе? А потом понял, что, когда я смотрю кино, моя обычная цель вообще не связана с его содержимым. Скорее я просто хочу провести время перед телевизором и переключить сознание. Так почему бы не довериться ребятам, которые собаку на этом съели?
Нетфликс делает классную форму при скудном содержании, а Кинопаб — ужасную форму при гигантском содержании. Разница между Нетфликсом и Кинопабом — как между Гитхабом (форма) и Гитлабом (богатое содержание, которое не работает). Или как между редактором кода (форма) и IDE (богатое содержание, которое тормозит).
Когда в следующий раз будете делать свой продукт, и неважно, будущий это единорог или API для коллег, подумайте, что важнее для вашего потребителя: форма или содержание?
Первым онлайн-кинотеатром, которым я воспользовался, был Кинопаб. Круто же — можно сразу смотреть любой фильм, хочешь — на английском, хочешь — хоть с китайскими субтитрами. Даже если фильм ещё не вышел — пожалуйста: смотри экранку. Примерно через пару месяцев я перешёл с Кинопаба на Netflix. Казалось бы, это полная противоположность: фильмов в русском Нетфликсе гораздо меньше, чем в тех же ivi или okko. Но Netflix определённо подошёл мне больше.
Дело в том, что все пять раз, когда я за эти два месяца хотел посмотреть фильм, я наталкивался на какие-то проблемы: то приложение не включается, потому что заблокировали ДНС, то фильм запускается два минуты и затем постоянно прерывается (или вообще начинает играть заново), чтобы оплатить, нужно пройти 10 шагов, которые потом приходится повторять каждый месяц. Вместо трейлера мне почему-то показывают сам фильм, а вместо фильма — наоборот, трейлер. В рекомендациях мне подсовывают какую-то фигню.
У Нетфликса всё наоборот — у тебя с самого начала спрашивают, что ты любишь, а затем устраивают бесшовный опыт: просто бесконечно показывают то, что интересно. Сначала я страдал, думал, как же так: а если я захочу посмотреть какой-то фильм, которого нет на Нетфликсе? А потом понял, что, когда я смотрю кино, моя обычная цель вообще не связана с его содержимым. Скорее я просто хочу провести время перед телевизором и переключить сознание. Так почему бы не довериться ребятам, которые собаку на этом съели?
Нетфликс делает классную форму при скудном содержании, а Кинопаб — ужасную форму при гигантском содержании. Разница между Нетфликсом и Кинопабом — как между Гитхабом (форма) и Гитлабом (богатое содержание, которое не работает). Или как между редактором кода (форма) и IDE (богатое содержание, которое тормозит).
Когда в следующий раз будете делать свой продукт, и неважно, будущий это единорог или API для коллег, подумайте, что важнее для вашего потребителя: форма или содержание?
#вопрос почему ты топишь против стейджинга?
Не совсем так — если вы, к примеру, пилите легаси-монолит на 300к строк без тестов, то без стейджинга и армии тестировщиков вы не обойдётесь. Я выступаю против стейджинга для маленькой команды.
Во-первых, поднять хороший стейджинг сложно: нужно делать CI/CD для каждой веточки, настроить Kubernetes, как-то обрезать тестовую базу данных, синхронизировать её с продом и делать ещё кучу работы.
Во-вторых, поддерживать стейджинг сложно: все эти мёрджи сначала в одну ветку, потом в другую, ой, а тут коммит потеряли, а там лишнее проскочило.
Но главный минус стейджинга для маленькой команды — это соблазн сделать релизный цикл. Когда вместо того, чтобы просто запушить решение в прод, нужно дождаться, пока задачу склеят с кучей других, всё это проверят на регрессии и затем зальют, хорошо, если с первого раза.
Когда твоя задача едет среди пачки других, ответственность за упавший прод размывается: если прод и упадёт, то это из-за релиза, а не из-за меня. И вообще — это тестировщик плохо потестировал, а не я запушил код без тестов.
Небольшим ребятам, если они хотят оставаться небольшими, нужно держаться как можно дальше от стейджинга, релизного цикла и ручного тестирования — только continuous deployment и горы юнит-тестов. Подробнее я рассказывал об этом в своём докладе на MoscowPython в январе.
Не совсем так — если вы, к примеру, пилите легаси-монолит на 300к строк без тестов, то без стейджинга и армии тестировщиков вы не обойдётесь. Я выступаю против стейджинга для маленькой команды.
Во-первых, поднять хороший стейджинг сложно: нужно делать CI/CD для каждой веточки, настроить Kubernetes, как-то обрезать тестовую базу данных, синхронизировать её с продом и делать ещё кучу работы.
Во-вторых, поддерживать стейджинг сложно: все эти мёрджи сначала в одну ветку, потом в другую, ой, а тут коммит потеряли, а там лишнее проскочило.
Но главный минус стейджинга для маленькой команды — это соблазн сделать релизный цикл. Когда вместо того, чтобы просто запушить решение в прод, нужно дождаться, пока задачу склеят с кучей других, всё это проверят на регрессии и затем зальют, хорошо, если с первого раза.
Когда твоя задача едет среди пачки других, ответственность за упавший прод размывается: если прод и упадёт, то это из-за релиза, а не из-за меня. И вообще — это тестировщик плохо потестировал, а не я запушил код без тестов.
Небольшим ребятам, если они хотят оставаться небольшими, нужно держаться как можно дальше от стейджинга, релизного цикла и ручного тестирования — только continuous deployment и горы юнит-тестов. Подробнее я рассказывал об этом в своём докладе на MoscowPython в январе.
Люди любят слабые решения
— Давайте возьмём этого кандидата? Ну и пусть он недотягивает, вдруг мы ещё месяц других не найдём.
— Давайте сделаем редизайн сайта — пофиг, что продаж нет.
— Давайте наймём ещё десяток программистов вместо одного продакта, который будет резать фичи.
— Давайте никому не скажем, что не успеваем запуститься в срок.
Обычно источник таких решений (не важно, принятых явно или нет) — достаточно банальный: у ответственного дома собака с ипотекой и вообще сегодня пятница. А зачем делать острые и конфликтные вещи, когда можно делать тихие и посредственные? Авось всё само потом рассосётся. И, бывает, рассасывается же.
Задача хорошего руководителя — предотвращать: не нанимать людей, склонных к слабым решениям, блокировать, отговаривать, увольнять. Пусть его все ненавидят, завтра CEO его уволит за конфликты, но сегодня команда хуйни делать не будет.
За это умение руководители и берут деньги.
— Давайте возьмём этого кандидата? Ну и пусть он недотягивает, вдруг мы ещё месяц других не найдём.
— Давайте сделаем редизайн сайта — пофиг, что продаж нет.
— Давайте наймём ещё десяток программистов вместо одного продакта, который будет резать фичи.
— Давайте никому не скажем, что не успеваем запуститься в срок.
Обычно источник таких решений (не важно, принятых явно или нет) — достаточно банальный: у ответственного дома собака с ипотекой и вообще сегодня пятница. А зачем делать острые и конфликтные вещи, когда можно делать тихие и посредственные? Авось всё само потом рассосётся. И, бывает, рассасывается же.
Задача хорошего руководителя — предотвращать: не нанимать людей, склонных к слабым решениям, блокировать, отговаривать, увольнять. Пусть его все ненавидят, завтра CEO его уволит за конфликты, но сегодня команда хуйни делать не будет.
За это умение руководители и берут деньги.
Обожаю раздавать советы, которым сам не следую!
Я закончил сдавать Артёму Горбунову новый бюрошный совет примерно за полтора часа до дедлайна. Забавно, но именно в этом совете я рассказал, что затянутая приёмка — это ответственность исполнителя, а не принимающего, и вообще когда просрал дедлайн в момент согласования, нельзя говорить «я всё сделал, это код-ревью\приёмка задержалась».
Я закончил сдавать Артёму Горбунову новый бюрошный совет примерно за полтора часа до дедлайна. Забавно, но именно в этом совете я рассказал, что затянутая приёмка — это ответственность исполнителя, а не принимающего, и вообще когда просрал дедлайн в момент согласования, нельзя говорить «я всё сделал, это код-ревью\приёмка задержалась».
#вопрос как ты борешься с прокрастинацией?
Самое плохое, что можно сделать с прокрастинацией, — это героическим усилием воли её преодолеть. То есть можно всегда через силу заставить себя работать, но так ты ценой счастья и здоровья получаешь результат по одной конкретной задаче, но фундаментальная проблема никуда не девается.
Когда мне не хочется работать — я не работаю. Наоборот, я сажусь в тишине и внимательно прислушиваюсь к внутренним сигналам — что именно вызывает нежелание работать? Может, я не считаю эту задачу важной? Может быть, мне не нравится клиент или сумма денег? Может, мне пора пару дней отдохнуть?
Если внимательно послушать сигналы, которые вызывают прокрастинацию, можно услышать вообще что-нибудь неприятное — к примеру, то, что профессия, которую ты выбрал, больше не приносит тебе удовольствия. Или вообще что-нибудь экзистенциальное, о том, что жизнь проходит мимо и вообще кризис среднего возраста.
Если самостоятельно найти ответ не удаётся — помогут психотерапевты.
Задавайте любые вопросы на fedor@borshev.com.
Самое плохое, что можно сделать с прокрастинацией, — это героическим усилием воли её преодолеть. То есть можно всегда через силу заставить себя работать, но так ты ценой счастья и здоровья получаешь результат по одной конкретной задаче, но фундаментальная проблема никуда не девается.
Когда мне не хочется работать — я не работаю. Наоборот, я сажусь в тишине и внимательно прислушиваюсь к внутренним сигналам — что именно вызывает нежелание работать? Может, я не считаю эту задачу важной? Может быть, мне не нравится клиент или сумма денег? Может, мне пора пару дней отдохнуть?
Если внимательно послушать сигналы, которые вызывают прокрастинацию, можно услышать вообще что-нибудь неприятное — к примеру, то, что профессия, которую ты выбрал, больше не приносит тебе удовольствия. Или вообще что-нибудь экзистенциальное, о том, что жизнь проходит мимо и вообще кризис среднего возраста.
Если самостоятельно найти ответ не удаётся — помогут психотерапевты.
Задавайте любые вопросы на fedor@borshev.com.
#вакансии в наши с Саматом проекты
— Node.js разработчик в w1d1, part-time удалённо
— React native разработчик в w1d1
— Продакт-менеджеры в igooods: в доставку, в блок работы с франчайзи, в поиск
— Проджект-менеджер
— Senior Ruby Developer
Контакты принимающих решение — там же, по ссылкам.
— Node.js разработчик в w1d1, part-time удалённо
— React native разработчик в w1d1
— Продакт-менеджеры в igooods: в доставку, в блок работы с франчайзи, в поиск
— Проджект-менеджер
— Senior Ruby Developer
Контакты принимающих решение — там же, по ссылкам.
Приходи с решением, а не с проблемой
Люблю, когда в трекере у задачи появляются ответы, а не вопросы: «Федя, я тут сделал не по макету, потому что бек пока не готов, переделаем после запуска» или «У нас была очень сложная вьюха в авторизации и я ее переписал».
Задача не ждёт, пока я проверю почту, а количество дефектов от таких самостоятельных решений, внезапно вовсе не растет.
Задать вопрос и просидеть до конца спринта в ожидании ответа — самый лёгкий способ соблюсти первый закон Паркинсона.
Не бойтесь принимать решения — в здоровом коллективе ошибки ценят больше, чем безделие.
Люблю, когда в трекере у задачи появляются ответы, а не вопросы: «Федя, я тут сделал не по макету, потому что бек пока не готов, переделаем после запуска» или «У нас была очень сложная вьюха в авторизации и я ее переписал».
Задача не ждёт, пока я проверю почту, а количество дефектов от таких самостоятельных решений, внезапно вовсе не растет.
Задать вопрос и просидеть до конца спринта в ожидании ответа — самый лёгкий способ соблюсти первый закон Паркинсона.
Не бойтесь принимать решения — в здоровом коллективе ошибки ценят больше, чем безделие.