Как дела в iGooods

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

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

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

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

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

——

Когда я работал в ГдеМатериале, я рассказывал о своих делах с большим отставанием — сначала добивался результата, а потом говорил, как я это сделал. Если не получалось — просто не рассказывал. Теперь всё по-другому, я пишу здесь почти в реальном времени. «Почти», получается, потому что я всё-таки иногда ещё и работаю :-)

Кажется, из-за этого лага я выгляжу как Винстон Вулф из Pulp Fiction — как будто мы с Саматом пришли и решаем проблемы по чеклисту: «вот разбрызганные мозги, вот старые ковры, вот губка — оттираем, накрываем». На самом деле нет — лично я на прошлой неделе обосрался с двумя проектами в iGooods, нифига не сделал для запуска нового вебинара, потерял полдня потому, что почитал новости, и абсолютно не доволен результатами по большой внутренней задаче, о которой пока рано рассказывать.

Такие публичные отчёты нужны мне, чтобы быть в порядке: перечитал, что сделал, и кажется что не всё так плохо. Рекомендую такую практику всем — просто садитесь и раз в неделю рассказывайте, как у вас дела. Можно близким, можно каналу в телеграме, или Apple Notes или Day One, если почему-то не хотите публиковать.

Чеклисты

Обожаю чеклисты — с ними можно делать много дел, совершенно не подключая головы. Работать по чеклистам — это как писать код с тестами — не нужно всё время проверять, правильно ты делаешь свою работу или нет. У меня есть чеклисты на все случаи жизни:

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

Самое главное моё открытие в чеклистах — их можно дописывать. Скажем, чеклист о том, как начинать живой стрим, появился ещё до первого стрима и состоял из двух пунктов — «выставить свет» и «закрыть дверь». После того, как у меня во время стрима вылезло окно с почтой — там появился пункт «закрыть лишние программы». Когда я обнаружил, что не все VPN тянут нормальный битрейт — появился пункт «проверить вещание». Теперь там чуть больше 10 пунктов, каждый из которых экономит мне силы, позволяя не думать там, где можно не думать.

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

​Переносим разработку в облако

Недавно я посчитал, сколько будет стоить макбук, на котором комфортно писать код, и офигел: получилось где-то 250 тысяч. Такую сумму отдавать жалко, особенно учитывая, что за $40 в месяц на digitalocean можно арендовать дроплет, который всё равно окажется мощнее и быстрее.

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

В эту субботу будем разбираться, как можно целиком перенести разработку на удалённую машину. Поскольку это будет стрим, а я так ни разу не делал — результата не обещаю.

Суббота 14:00, приходите.

Как публичная активность влияет на работу CTO?

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

​Начинаем стрим через 15 минут

Поговорим об облачной разработке — расскажу про состояние Visual Studio Code Online и покажу, как я поднимаю удалённые машины через ansible.

https://www.youtube.com/watch?v=Y0JraNE8ZRI

Почему я открыто делюсь исходным кодом (и +2 открытых проекта на Django)

Разработчики, которые приходят на мои проекты, часто удивляются, почему я с такой лёгкостью открываю свои наработки — добавляю в репозитории в гитхабе, даю доступ на сервера и передаю документацию. Ведь обычно все прячут исходный код за семью печатями — не делятся доступами, присылают странные zip-архивы без папки .git и т.д. Я где-то даже видел команду, которая обфусцировала код, прежде чем выложить на гитхаб.

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

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

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

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

На прошлой неделе я открыл два важных проекта на Django:
— education-backend: это активный коммерческий проект — бекенд, которым я пользуюсь чтобы брать деньги вебинары.
— f213/django — мой стартер проектов на django с батарейками: pytest, 12-факторностью, кучей линтеров и ещё много чем.

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

Я надеюсь, что мои исходники послужат кому-то примером того, что можно писать коммерческий код для удовольствия.

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

​Выбросьте свой гитлаб

Осторожно — дальше ничем не обоснованное личное мнение

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

Наверное такие команды выбрали гитлаб потому, что сделали табличку, в которой сравнили его с гитхабом по количеству фич, и увидели, что у гитлаба их больше и они бесплатнее. К сожалению, такие таблички не показывают, что большинство фич гитлаба недоделаны и не дотягивают до конкурентов:
— CI поощряет писать шелл-скрипты, как в двухтысячных. Хотите собирать в докере — пилите свой образ с бойлерплейтом вроде apt-get --no-install-recommends install git
— Бесплатный облачный CI не работает — ваш проект просто висит в очереди и не билдится.
— Реестр контейнеров глючит, разрывает соединение и вообще не работает.

UI гитлаба не годится никуда: примеру на странице пулл-реквеста кнопка «закрыть и забить» в два раза больше, чем кнопка «смёрджить», а список коммитов запрятан в отдельную вкладку.

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

Если вы цените время своих коллег — мигрируйте на гитхаб прямо сейчас, это бесплатно.

#вакансия #работамечты

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

На беке у нас REST и Django, на фронте пока нет ничего. По технологиям хотим vue.js, больше никаких ограничений нет.

Работа удалённая, команда отличная, заказчик американский, оплата в долларах.

Присылайте пару строк о себе и ссылку на гитхаб на fedor@borshev.com

PostgreSQL anonymizer

Нашёл классный экстеншн для постгреса — PostgreSQL anonymizer — он простым декларативным синтаксисом вырезает из базы всё, что связано с персольной информацией пользователей.

Им можно вырезать имена из ночных дампов или прямо из базы.

Если вы всё ещё не на auth0 и сами вынуждены работать с персональными данными — мастхев.

P.S. Осталось два дня до повышения цены на мой вебинар об автоматизации разработки. Приходите — поговорим ещё о десятке таких нужных инструментов и о том, как их внедрять

Вебинар об автоматизации разработки переносится на 30 мая

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

Новая дата — 30 мая, суббота, 14:00.

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

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

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

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

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

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

​Учим докер

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

9 мая в 14:00, приходите на стрим

Уровень ЗП зависит от ответственности

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

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

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

​Начинаем через 15 минут

Как и обещал, в прямом эфире будем докеризировать Django-приложение, разбирая каждый шаг — https://youtu.be/t8gZD0lwu2k

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

Чек-лист: на что смотреть, когда затягиваешь новую библиотеку

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

Кроме очевидного способа минимизировать проблемы от зависимостей (поменьше их притаскивать, кек), есть ещё простая гигиена, которая помогает упростить жизнь. Прежде чем набрать npm install или что там у вас, найдите репозиторий зависимости в Гитхабе и проверьте его:
— Не смотрите на количество лайков.
— Есть ли тесты? Понятно ли написаны?
— Посмотрите 5 минут на код. Удаётся ли понять, как он работает?
— Были ли значимые (не «version bump») коммиты в последние полгода?
— Подходит ли лицензия вашему проекту?
— Не смотрите на количество лайков.
— Растёт или падает количество скачиваний (можно найти в npm/pypi).
— Сколько висит неотвеченных пулл-реквестов?
— Какие issues обсуждают?
— Понятно ли написано ридми, много ли документации?

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

Есть что добавить в чек-лист? Напишите на fedor@borshev.com

Органы чувств

Вот упал у вас прод, вы заходите по ssh и видите, что Load Average больше, чем количество ядер, в 10 раз. Люди не могут воспользоваться сервисом, партнёры задают вопросы, а всё, что вы знаете, — это то, что нагрузка выше в 10 раз, чем номинальная. Вы начинаете искать по логам (медленно, сервер-то перегружен), запускать ps и strace и совершать другие шаманские действия. Чувствуете, что двигаетесь по тёмному лесу с закрытыми глазами, как бегуны из старого клипа Pendulum.

Думаю, в такой ситуации был каждый опытный бэкендер. Я — точно несколько раз.

Выход простой — сделайте себе нормальные органы чувств. Заведите мониторинг с дашбордами, которые покажут топ самых нагруженных эндпоинтов API (отдельно по запросам, отдельно — по затраченному машинному времени), состояние серверов и 4 золотых сигнала (время ответа, количество запросов, рейт ошибок и запас нагрузки). Через пару аварий дополните собственные сигналы: скажем, мы в iGooods, пока не разобрались с падающей сетевой картой на сервере с БД, вывели нагрузку на неё на все борды.

Подойдёт что угодно — datadog, newrelic, можете даже Графану с Прометеусом поставить: главное, чтобы у вас были глаза и уши.

Каждый понедельник я отвечаю на один конкретно поставленный вопрос с насущной проблемой.

Вот, что интересного было в последнее время:
— Стоит ли уходить из агентства в продуктовую разработку?
— Что делать, если разработчик начал фейлить из-за карантина
— Как найти удалённую работу на полставки
— ООП или ФП?
— Как оценить успешность или неуспешность фичи после релиза
— Почему ты работаешь стоя?

Чтобы получить публичный ответ на свой насущный вопрос, нужно написать мне на fedor@borshev.com, конфиденциальность гарантирую.

Говори только с тем, кто принимает решения

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

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

Договорённости, заключённые с такими людьми, скорее всего, не сработают — они же не управляют ситуацией: вроде вы и договорились, а потом приходит настоящий ЛПР и делает всё так, как считает нужным.

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

Письмо с зарплатой

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

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

Ловите шаблон:

- Ты выходишь к нам на испытательный срок с зарплатой ХХ рублей.
- Испытательный срок продлится до 2 месяцев.
- По окончании испытательного срока твоя зарплата составит YY рублей.
- Критерии окончания испытательного срока — такие-то. Или: критерии окончания испытательного срока мы с тобой обсудим ХХ июня.
- Деньги переводим тебе на ИП / ГПХ / в пенсионный фонд / что там у вас.
- 25 числа каждого полного месяца получаешь аванс, 8 — расчёт за прошлый месяц.