Не экономить на инфраструктуре

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

Вроде бы для меня всегда было очевидно, что нельзя экономить на эксплуатации — в ГдеМатериале я всегда покупал для программистов самое лучше — Гитхаб и Circle CI вместо Гитлаба и Жиры, gemfury вместо костыльных собственных реестров (github package тогда ещё не было), pusher.com вместо настройки вебсокетов и т. д.

Однако на себе, а особенно на своём бизнесе (ведь может не получиться же!), я привык экономить. Вместо прекрасной чатры для поддержки я настраивал какие-то мутные гугл-группы. Вместо удобного хостинга на Digital Ocean я долго думал, как безопасно разместить файлы курсов в том же бакете, где я храню свои бекапы. Хорошо хоть не додумался сам собирать сайт вместо тильды или писать парсер выписок из банка вместо выделения специальной карты для учёта расходов.

В итоге из-за тысячи рублей в месяц я потратил кучу ресурсов, которую мог бы обратить в пользу: к примеру, подготовить дополнительные 10 минут к вебинару, написать 5–6 интересных постов в канал или просто хорошо отдохнуть.

Не делайте так: лучше побольше заработать, чем поменьше потратить.

Жизнь без будильников

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

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

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

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

Парадоксальным образом мне удаётся проснуться на все встречи, которые я назначаю с утра. Мне в этом помогают большие запасы времени — если встреча назначена на 11:00, значит, ложиться надо в 22:00, чтобы к 09:00 успеть проснуться и выполнить все утренние ритуалы.

Кстати, если интересуетесь сном, посмотрите простую ссылку fixsleep.link, там прекрасный Никита Колмогоров собрал 17 советов, которые быстро чинят сон.

#вакансии

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

Посмотрите вы тоже:
— Разработчик React Native, devops и ведущий бекендер (Pyhton) в Т—Ж
— Фронтендер в Allure
— Фронтендер в Tripment
— Kotlin-бекендер в Первый Цупис
— Фронтендер в Motional (self-driving, Сингапур)

#вопрос А как ты понимаешь, кому именно нужно хвастаться на ретро? Что делать, если не хватает технических знаний, чтобы понять, кто и что сделал хорошего?

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

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

P. S. Вот сервис, который мы написали в ГМ, чтобы каждому участнику команды ежедневно на почту скидывался список закрытых задач. Приспособить его под дайджест закрытых пулл-реквестов — плёвое дело.

Не ходить в базу руками

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

Вот пара примеров из курса «Стать Тимлидом».

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

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

«Ты сделал говно»

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

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

Представьте, если первоклассник принёс учителю решение, что 2 x 2 = 3, а учитель в ответ выражает просто мягкое неодобрение, но не говорит, что правильно будет 4? Математика никогда не откроется ребёнку как точная наука, скорее ощущение будет «ну, я что-то делаю, что-то, наверное, получается».

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

Важно — именно «ты сделал говно», а не «ты — мудак». Критиковать можно только работу, но не личность.

Го в комменты, я создал

Разработчик отказывается делать фичу

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

А как вы (менеджеры и программисты) строите диалог в таких ситуациях?

​Закоментированный код

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

С тех пор появился git с его stash и текстовые редакторы с многоуровневой отменой, но люди продолжают комментить код и даже выкладывать его в репу. Кроме того, что такой приём вызывает немедленное желание пожевать Мамбу и послушать Децла, есть ещё и объективные проблемы.
— Растёт когнитивная нагрузка на чтение такого кода: если закомментировать два экрана кода, но оставить одну строку посередине — хрен вы её когда-нибудь найдёте.
— Удалённые строки в статистике превращаются в изменённые.
— Сбивается авторство. Вместо «Коля удалил код Серёжи» в истории будет что-то вроде «Коля удалил код Феди, который до этого поменял код Серёжи».

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

Если пишете на питоне и не хотите, чтобы в вашей команде коммитили закомментированный код, поставьте себе flake8-eradicate. Если юзаете что-нибудь подобное для JS/TS, напишите в комменты, пожалуйста.

Напиши пост

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

Не знаю, выложат ли ребята запись в паблик (скорее всего нет), но пока она доступна у меня на патреоне.

​Недавно был в гостях у MoscowPython — долго говорили про асинхронщину (спойлер: большинству проектов она не нужна), про то, как объяснять её джунам (спойлер: не нужно), про будущее джанги и вообще.

Годовая подписка — обман

Почти всегда, когда производители софта предлагают купить месячную подписку на софт, нам предлагают сэкономить 20%, оплатив сразу на год. Почти всегда это пустая трата денег.

Во-первых, ваши 20% экономии тут же превращаются в 10%, когда вы понимаете, что деньги можно было отдать не разработчику, а на год положить в любой доступный инвестиционный инструмент (историческая доходность по ETF Тинькова, один пай которого стоит 5 ₽, — 14% годовых).

Во-вторых, годовая подписка — это обязательство целый год использовать эту программу. Представьте, что вы фанат шифрованных заметок, закрытых под пароль. Выбираете визуально красивый заметочник, который так умеет делать, скажем, мой любимый Bear, за 1000 рублей в год. И тут проходит полгода, и нативный заметочник в Маке внезапно начинает поддерживать закрытие заметок под пароль. Вы на него переходите — зачем ещё одна программа на компьютере?

Если бы вы платили помесячно, вы бы потратили 600 рублей. А за год вы заплатили 1000 — получается, либо вы потеряете 400 рублей, либо останетесь на Bear. Через 4 месяца вы наверняка забудете отказаться от подписки и оплатите ещё 1000 за будущий год.

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

У меня есть только одна программа, за которую я плачу годами, — это дневник Day One. Для меня это программа больше про вечность, чем про фичи: мне приятно осознавать, что мои личные переживания и важные моменты из жизни уходят в облако, в котором пролежат, возможно, и после моей смерти. Наверное, если бы за Day One можно было платить десятилетиями, я бы и на этом сэкономил 20%. А вот за всё остальное я плачу помесячно, что и вам советую.

​12 факторов: не хранить пароли в коде

п. 3 в «12 факторах» говорит — храните конфигурацию в переменных окружения. По-русски это значит «не храните пароли в коде». Сейчас объясню.

Вот представьте, что вы выкладываете на прод приложение, которое хранит своё состояние в постгресе, и единственное место, куда оно умеет за ним ходить, — это localhost с логином root и паролем secret. Проблема усугубляется тем, что все популярные веб-фреймворки по дефолту предлагают хранить пароли именно в коде — settings.py в джанго или secrets.yml в рельсе. Джуны действительно так делают. А это плохо:

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

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

Так что храните все пароли в переменных окружения. К примеру, если используете джанго, можете взять django-environ, который строит нормальный мостик между переменными окружения и settings.py.

#вопрос Что думаешь о чудесном мире будущего, где всё будет serverless? Уже сейчас пишутся приложения со похожими стеками — CloudFront + S3 для фронта и Lambda + ApiGateway + куча обвеса вокруг (SNS, SQS, CloudWatch Rules, etc). Не думаешь ли ты, что это некий геймченджер и в перспективе 5 лет туда уедет очень много всего, от стартапов до энтерпрайза?

Конечно, думаю — любой стек стремится уменьшать количество бойлерплейта. Посмотрите, как продвинулся вперёд фронтенд за последние 10 лет. Вместо jquery появились react/vue/svelte/whatsoever, где мы оперируем уже не DOM, а реактивными компонентами, которые могут быть чем угодно — HTML, функциями или вообще смесью из компонентов высшего порядка.

С другой стороны, ретрокод умирает достаточно медленно — на jquery до сих пор пишут плагины для вордпресса, до сих пор есть такие странные профессии, как «битрикс-разработчик» или «админ FreeBSD». И эти профессии востребованы: есть много бизнесов, которые построили давно и которые до сих пор приносят людям деньги.

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

Подробнее см. мой предыдущий пост Что делать, чтобы вас не заменили роботом

Задавйте свои вопросы на fedor@borshev.comfedor@borshev.com

Пост благодарности

Мы проверили последнюю домашку, ответили на последний комментарий, разослали последнее письмо — так что курс «Стать Тимлидом» можно считать завершённым.

Перечитывая материалы, я кайфую. Если бы я получил эти 5 уроков хотя бы лет 10 назад, моя профессиональная жизнь сложилась бы совсем по-другому. Это даёт надежду, что материалы окажутся полезными и для слушателей курса.

Спасибо всем, кто читал лонгриды, слушал спикеров, задавал вопросы на q&a. Отдельное спасибо за тёплые отзывы.

Спасибо Марьяне и Саше, мы с вами, определённо, — неплохая команда.

И до следующего потока всем!

Меньше тратить → больше зарабатывать

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

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

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

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

Умение говорить «Нет»

Людей вокруг всегда больше, чем у тебя есть внимания. Дел вокруг больше, чем есть времени. Пет-проектов больше, чем ты можешь сделать.

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

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

Самому не проще

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

Делегирование и постановка задач — больная тема. Ещё 10 лет назад всех уже тошнило от S.M.A.R.T. и условных «семи правил успешного делегирования». Мне, к примеру, хотелось, чтобы кто-нибудь рассказал, почему я так стесняюсь ставить коллегам задачи, и как сделать, чтобы команда делала порученную работу быстрее, чем я своими руками. Но везде были советы от копирайтеров, из серии «делегируйте полномочия вместе с ответственностью».

Даже банальная фраза «дай им обосраться», когда-то брошенная одним из наставников, помогла мне больше, чем все книги по управлению людьми.

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

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

3 письма, 1 q&a-сессия, старт 12 января. Стоит 6500 рублей. До конца этого года скидка 15% по промо-коду DELEJAN.

Я не понял

Есть такой странный баг в мозгах у многих программистов — нам стыдно говорить «я не понял». Эксплуатируется просто — достаточно уверенным тоном сказать какую угодно чушь, а потом спросить «ну как, понятно?». Типа менеджер говорит «Добавляем тут if, там ставим кнопку и всё начинает работать. Ну как, понятно?». Большинство неопытных программистов, которых я когда-либо видел, не задумываясь отвечают «да», хотя на самом деле понятия не имеют, о какой кнопке идёт речь и что именно входит в понятие «всё».

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

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

Посмотрите на себя — может, у вас тоже есть вредная привычка не признаваться, что вы что-то не поняли?