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

На прошлых курсах мы слали письма через postmark: верстали вручную каждый шаблон и рассылали. Сейчас так сделать нельзя
- письма сложные, да и хочется сохранить возможность подписаться на курс уже после запуска. Так что решили сделать на базе mailchimp.

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

Стрим будет эту субботу, 9 января, в 14:00
- https://youtu.be/95zJaqwn1L8.

не писать логи в файлы В «12 факторах» написано: «логи
- это поток событий». Сейчас объясню чуть проще.

Если джуниору поставить задачу записывать какие-то события в лог, скорее всего, его код будет выглядеть как-то так:

with open('logs/events.log') as fp: fp.writeln('Event has happened')

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

1. Никто не будет знать, пока не прочитает код, что logs/events.log
- это артефакт, который надо хранить. Если запустить ваше приложение внутри докер-контейнера, то все ваши логи будут жить не больше, чем время жизни контейнера с приложением.
2. Приложение нельзя будет нормально запустить в нескольких экземплярах. Если у вас работают 5 копий (5 контейнеров или 5 серверов), то никто и никогда не скажет, на каком именно сервере лежит logs/events.log, придётся отсматривать все
5.
3. Файлы с логами нужно ротировать, чтобы не заканчивалось место. А если вы пишете по 100 событий в секунду
- ротировать быстро.

Все эти проблемы решают централизованные системы логгинга
- graphana loki, papertrail или даже datadog. Когда вы их подключаете, ваше приложение пишет логи не в файл, а через сокет на центральный сервер. Архивация и ротация у вас теперь на одной машине. А самое главное
- поиск: любое средство хранения логов даёт вам поиск, который работает гораздо удобнее, чем grep.

Курс «Самому не проще» в подарок

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

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

До нового года так же действует промо-код на скидку 15%
- DELEJAN, потом скидок не будет.

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

https://youtu.be/fzaZz5mH1yA

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

Чтобы не наращивать конфликт, достаточно просто говорить. Тупое правило: если видишь в сообщении от коллеги хоть небольшой намек на эмоции
- немедленно прекращай общение и назначай встречу. Если сам написал эмоциональное сообщение
- стирай скорее.

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

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

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

Плато продуктивности

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

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

Работа с некачественным кодом сильно выматывает
- вместо фокуса на цели приходится разбираться, о чем же думал «тот парень» (и тот, кто его подгонял). В таком режиме волна продуктивности превращается в болото: ∿∿
-\____. Хочется уволиться и пойти работать машинистом метро.

Нормальная загрузка программиста похожа на плато:
-
-
-
-
-
-. На плато нет всплесков вроде срочных задач и эмоциональных подъёмов. Но нет и болота с унылым разгребанием долгов. Программист на большом проекте
- это марафонец.

00 выступаю на митапе tver.io, сделаю обзор инструментов, которые нужны программистам, чтобы получать от работы настоящее удовольствие. Приходите
- https://www.youtube.com/watch?v=m9ZnwjOubls

Я не понял

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что делать, чтобы вас не заменили роботом

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

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

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

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

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

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

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

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

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

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

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

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

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