#вакансия

Продакт и проджект в igooods

Мы ищем двух менеджеров:

— Продакт на поиск и сервис рекомендаций
— Проджект в команду ритейла

Работа в офисе в Питере. Денег — норм, офис отличный, коллектив — огонь, остальные подробности — по ссылкам.

Упс, ссылка на продакта неправильная, правильная — http://bit.ly/igooods-product-fix

Эволюция парольных менеджеров

Моим первым менеджером паролей был KeePassX. Гиковская штуковина — пароли хранятся в локальном файле, файл можно синхронизировать чем угодно, к примеру Dropbox или ownCloud, если вы параноик.

Потом было два года Dashlane — красивого монстра со встроенным VPN и мониторингом дарквеба. К сожалению, за красотой скрывалась очень кривая реализация: автозаполнение (главная функция парольного менеджера) иногда просто переставало работать. Больше всего меня бесил театр безопасности, когда меня просили ввести цифры с картинки, чтобы «авторизовать» браузер. При этом, если цифры не вводить, всё продолжало работать.

В какой-то момент я настолько начал страдать от Dashlane, что всерьёз рассматривал переход на Bitwarden — кто не знает, это такая система хранения паролей для собственного сервера.

В итоге после очередной перезагрузки из-за зависшего менеджера паролей я перешёл на 1Password: менее красивый, но надёжный как топор. Автозаполнение работает везде, кроме сайта Тинькофф, синхронизируется моментально, не зависало вообще ни разу. Уже третий год на нём, очень советую.

#вопрос Стоит ли менять работу, если уже порядком поднадоело, но есть новые проекты и в целом хоть какой‑то прогресс ощутим?

В бюро вышел мой новый совет — рассказываю про FOMO при смене места работы.

​Самат сделал классный обзор инструментов для рисования диаграмм и рассказал, как мы применяем их в разработке igooods.

Накидаете в комментах своих инструментов?

Рассказал в подкасте у Самата, как я два раза стал программистом,  почему не закончил среднее образование, насколько полезно в реальной жизни программирование, которому учат в универе, и вообще как войти в айти.

Слушайте в Apple, Google, Castbox, Яндекс, Spotify, Overcast, ютуб и в веб-версии.

#вопрос Я руководитель web-разработки и собираюсь перейти в другую компанию, где будет другая команда и другие проекты. Как можно смягчить и сделать этот переход наиболее комфортным с точки зрения стресса?

Кажется, самый большой источник фрустрации для руководителя, который приходит в новую команду, — это сама команда. Люди ставят не те статусы в жире, пишут код по airbnb вместо standard, беспокоятся о непривычных проблемах, а по пятницам пьют стауты вместо IPA. Самое главное — не начать судорожно это всё менять.

Вот представьте сами — команда привыкла к трёхнедельным спринтам, а вы такой на белом коне, вооружившись словами вроде «декомпозиция», меняете спринты на недельные. И уже потом выясняете, что спринты такие длинные потому, что команда пилит только большие задачи, а на срочные и мелкие есть отдельная линия саппорта, которая вообще работает по канбану.

Или ещё хуже — команда работает по трёхнедельным спринтам, а вы привыкли к недельным, но менять боитесь (как бы чего не вышло) и страдаете.

Первый шаг в новой команде — это привыкнуть: не пытаться что-то поменять в первую же неделю, а понять и с уважением принять текущий процесс и привычки. То есть сначала научиться играть по их правилам, а потом уже внедрять свои. Если у вас нет аллергии к русскому селф-хелпу, почитайте на эту тему 45 татуировок менеджера — там есть целая глава про это.

Обойти сбоку

Когда мы запускали 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 О чём писать в блоге разработчика?

Честно говоря, я крайне не доволен стримом — пересматривая запись я понимаю, что мог бы ответить гораздо полнее и интереснее. Ну, ничего страшного — теперь я знаю, как готовиться, поэтому через пару недель устроим ещё один.


Ну и спасибо всем, кто пришёл!

Форма vs. содержание: Netflix vs. Кинопаб

Первым онлайн-кинотеатром, которым я воспользовался, был Кинопаб. Круто же — можно сразу смотреть любой фильм, хочешь — на английском, хочешь — хоть с китайскими субтитрами. Даже если фильм ещё не вышел — пожалуйста: смотри экранку. Примерно через пару месяцев я перешёл с Кинопаба на Netflix. Казалось бы, это полная противоположность: фильмов в русском Нетфликсе гораздо меньше, чем в тех же ivi или okko. Но Netflix определённо подошёл мне больше.

Дело в том, что все пять раз, когда я за эти два месяца хотел посмотреть фильм, я наталкивался на какие-то проблемы: то приложение не включается, потому что заблокировали ДНС, то фильм запускается два минуты и затем постоянно прерывается (или вообще начинает играть заново), чтобы оплатить, нужно пройти 10 шагов, которые потом приходится повторять каждый месяц. Вместо трейлера мне почему-то показывают сам фильм, а вместо фильма — наоборот, трейлер. В рекомендациях мне подсовывают какую-то фигню.

У Нетфликса всё наоборот — у тебя с самого начала спрашивают, что ты любишь, а затем устраивают бесшовный опыт: просто бесконечно показывают то, что интересно. Сначала я страдал, думал, как же так: а если я захочу посмотреть какой-то фильм, которого нет на Нетфликсе? А потом понял, что, когда я смотрю кино, моя обычная цель вообще не связана с его содержимым. Скорее я просто хочу провести время перед телевизором и переключить сознание. Так почему бы не довериться ребятам, которые собаку на этом съели?

Нетфликс делает классную форму при скудном содержании, а Кинопаб — ужасную форму при гигантском содержании. Разница между Нетфликсом и Кинопабом — как между Гитхабом (форма) и Гитлабом (богатое содержание, которое не работает). Или как между редактором кода (форма) и IDE (богатое содержание, которое тормозит).

Когда в следующий раз будете делать свой продукт, и неважно, будущий это единорог или API для коллег, подумайте, что важнее для вашего потребителя: форма или содержание?

#вопрос почему ты топишь против стейджинга?

Не совсем так — если вы, к примеру, пилите легаси-монолит на 300к строк без тестов, то без стейджинга и армии тестировщиков вы не обойдётесь. Я выступаю против стейджинга для маленькой команды.

Во-первых, поднять хороший стейджинг сложно: нужно делать CI/CD для каждой веточки, настроить Kubernetes, как-то обрезать тестовую базу данных, синхронизировать её с продом и делать ещё кучу работы.

Во-вторых, поддерживать стейджинг сложно: все эти мёрджи сначала в одну ветку, потом в другую, ой, а тут коммит потеряли, а там лишнее проскочило.

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

Когда твоя задача едет среди пачки других, ответственность за упавший прод размывается: если прод и упадёт, то это из-за релиза, а не из-за меня. И вообще — это тестировщик плохо потестировал, а не я запушил код без тестов.

Небольшим ребятам, если они хотят оставаться небольшими, нужно держаться как можно дальше от стейджинга, релизного цикла и ручного тестирования — только continuous deployment и горы юнит-тестов. Подробнее я рассказывал об этом в своём докладе на MoscowPython в январе.

Люди любят слабые решения

— Давайте возьмём этого кандидата? Ну и пусть он недотягивает, вдруг мы ещё месяц других не найдём.
— Давайте сделаем редизайн сайта — пофиг, что продаж нет.
— Давайте наймём ещё десяток программистов вместо одного продакта, который будет резать фичи.
— Давайте никому не скажем, что не успеваем запуститься в срок.

Обычно источник таких решений (не важно, принятых явно или нет) — достаточно банальный: у ответственного дома собака с ипотекой и вообще сегодня пятница. А зачем делать острые и конфликтные вещи, когда можно делать тихие и посредственные? Авось всё само потом рассосётся. И, бывает, рассасывается же.

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

За это умение руководители и берут деньги.

Обожаю раздавать советы, которым сам не следую!

Я закончил сдавать Артёму Горбунову новый бюрошный совет примерно за полтора часа до дедлайна. Забавно, но именно в этом совете я рассказал, что затянутая приёмка — это ответственность исполнителя, а не принимающего, и вообще когда просрал дедлайн в момент согласования, нельзя говорить «я всё сделал, это код-ревью\приёмка задержалась».

#вопрос как ты борешься с прокрастинацией?

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

Когда мне не хочется работать — я не работаю. Наоборот, я сажусь в тишине и внимательно прислушиваюсь к внутренним сигналам — что именно вызывает нежелание работать? Может, я не считаю эту задачу важной? Может быть, мне не нравится клиент или сумма денег? Может, мне пора пару дней отдохнуть?

Если внимательно послушать сигналы, которые вызывают прокрастинацию, можно услышать вообще что-нибудь неприятное — к примеру, то, что профессия, которую ты выбрал, больше не приносит тебе удовольствия. Или вообще что-нибудь экзистенциальное, о том, что жизнь проходит мимо и вообще кризис среднего возраста.

Если самостоятельно найти ответ не удаётся — помогут психотерапевты.

Задавайте любые вопросы на fedor@borshev.com.fedor@borshev.com.

#вакансии в наши с Саматом проекты

— Node.js разработчик в w1d1, part-time удалённо
— React native разработчик в w1d1
— Продакт-менеджеры в igooods: в доставку, в блок работы с франчайзи, в поиск
— Проджект-менеджер
— Senior Ruby Developer

Контакты принимающих решение — там же, по ссылкам.

Приходи с решением, а не с проблемой

Люблю, когда в трекере у задачи появляются ответы, а не вопросы: «Федя, я тут сделал не по макету, потому что бек пока не готов, переделаем после запуска» или «У нас была очень сложная вьюха в авторизации и я ее переписал».

Задача не ждёт, пока я проверю почту, а количество дефектов от таких самостоятельных решений, внезапно вовсе не растет.

Задать вопрос и просидеть до конца спринта в ожидании ответа — самый лёгкий способ соблюсти первый закон Паркинсона.

Не бойтесь принимать решения — в здоровом коллективе ошибки ценят больше, чем безделие.

Не давать обещаний сходу

Менеджеры всегда закладывают запас, чтобы программисты успели в срок. Если команда оценила проект в 5 дней, опытный менеджер заложит 2 недели: скорее всего, что-то пойдёт не так и этот запас пригодится.

Почему-то этой уловкой редко пользуются программисты. Я и сам раньше на это напарывался: видел интересную задачу на пару часов, думал: «Что я, пару часов на неделе не найду?» — и давал обещания. В итоге брал кучу лишних задач и не оставлял себе буфера — если двухчасовая задача превращалась в 4 часа или основной проект съедал времени больше запланированного, приходилось или каяться или перерабатывать.

Разница между менеджером и программистом в том, что менеджер обычно даёт свои обещания отложенно: сегодня принял задачу, завтра оценил, послезавтра вернулся с оценкой. А от программистов почему-то все требуют оценки сразу, а значит, в действие включаются все возможные когнитивные искажения вроде ошибки планирования или предвзятости относительно экономии времени.

Вывод простой — никогда не давать обещаний сразу, когда их просят. Вместо этого, когда к тебе пришёл кто-то с интересной задачей (даже если это ты сам), нужно положить эту задачу в бэклог и распланировать её выполнение так же, как планируешь остальные задачи — с запасом и в комфортное время.

Хорошее письмо

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

Если одного твоего письма достаточно, чтобы решить задачу, то оно хорошее.

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

Работать в такси

Раньше я жал деньги на такси — мне казалось странным платить по 500–800 рублей за то, что можно сделать почти бесплатно — добраться из точки А в точку Б. Мне казалось, что не важно, где проводить время в дороге — в метро или такси: всё равно я читаю, пишу или делаю ещё что-то полезное.

А потом я внимательно всё посчитал.

Мой самый частый маршрут на такси занимает в среднем 40 минут. На метро тот же маршрут составляет около часа, но не весь этот час я остаюсь «в себе» — в метро множество отвлекающих факторов: шум и тряска, странные соседи (кого только не встретишь в московском метро), ожидание поезда, переходы между станциями. Из изначального часа на концентрированную деятельность остаётся не больше 30 минут.

То есть эффективность использования времени в такси приближается к 100%, а в метро — около 50%. Кажется выбор очевиден.

Стрим: пишем код для нового курса

Мы с Марьяной Онысько (@product_love) готовим для вас новый офигенный курс. Это будет что-то радикально новое. Конкретнее анонсируем на следующей неделе, а пока хочу постримить процесс техннической подготовки.

Дело в том, что Марьяна, как настоящий продакт, потребовала у меня поддержку промо-кодов, чтобы можно было давать временные скидки. К сожалению, мой текущий бекенд этого не поддерживает, поэтому в это воскресенье в 14:00 будем писать код.

Будет, как обычно Python, Django и TDD. Думаю, меня хватит часа на 2–3, так что приходите — неизвестно, когда ещё в следующий раз повторю.