Запись чата. Спасибо всем, кто дослушал до конца!

#вопрос Как создать маленький бизнес или как придти к предпринимательству, если ты бэкенд-разработчик?

Не чувствую ценности в своём мнении, потому что в жизни начал не так много бизнесов. Но попробую ответить, раз спросили.

Думаю, что свой бизнес бекенд разработчикам стоит начинать так же, как фронтендерам, девопсам, реставраторам, сантехникам, водителям грузовиков и маркетологам — нужно выбрать нишу и начать что-то в ней делать. Ниша может быть какой угодно: уверен, что можно стать CEO стартапа, если взять идею из последнего набора Y Combinator и отнести её к отечественным венчурным капиталистам. Или наоборот — открыть магазинчик обуви или шаурмячную, начитавшись какого-нибудь Т—Ж. Вероятно, вам так же помогут книги вроде «стартапа за 100$».

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

Ну и удачи вам :-)

Positive review против Negative review

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

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

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

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

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

​Огорóды

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

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

Теперь анализаторы логов заменила Гугль-аналитика, сисадминов заменил докер, и появилось отдельное слово для обозначения невиртуальных серверов — bare metal. Однако я до сих пор встречаю компании, которые ставят себе «анализаторы логов» — корпоративный гитлаб вместо гитхаба, локальные версии дженкинса вместо серкла, свои хостинги, почтовые сервисы, трекеры задач и пр.

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

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

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

Вы же покупаете помидоры и огурцы во Вкусвилле, а не выращиваете на своём огородике. Что мешает делать так же с софтом?

Новости «Профессионального роста»

У нас отличные новости — на ланчтаймах «Профессионального роста» мы определились с четвёртым спикером — это будет Самат. И добавили пятого спикера — это будет Антон Давыдов.

Самат расскажет о своём пути от сисадмина до владельца собственного бизнеса, Сергей Головин из CSSSR расскажет как растить тимлидов, Антон — о своём опыте роста в хакеры, Борис Окунский расскажет, как вырос из бармена до CTO, а Иван Смирнов расскажет о менторстве.

Обучение начинается 10 августа и состоит из 4-х уроков с домашкой, двух q&a-сессий со мной и Васей и 5 ланчтаймов со спикерами, приходите.

Как проект будет выглядеть через два года?

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

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

Пример — если в 2017 году сделать прод на docker-compose.yml (тогда действительно это рекомендовали), то в 2019 году вы себя возненавидите, потому что для любого изменения придётся править тонну скриптов, которые вы тогда написали. А вот если вы прямо сейчас, в 2021 году, соберёте деплой на Ansible — будет не так и уж и стыдно в в 2023: ansible развивается, потому что многим проектам больше ничего и не надо. Он, конечно, будет старьём, но работать вы с ним точно сможете, потому что Ansible — инструмент достаточно высокоуровневый.

Для фронтенда, увы, мысленный эксперимент не поможет — там за пару лет любая технология поменяется три раза.

Чем больше линтеров, тем лучше

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

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

Помимо базовых линтеров, которые проверяют форматирование, типа правильных запятых и кавычек, я использую высокоуровневые линтеры — измеряю когнитивную сложность методов, использую плагин к pytest, который проверяет, что все задекларированные фикстуры используются в тестах. Есть и более высокоуровневые — к примеру, на фронте у нас запрещено использовать название переменной this.$axios, чтобы программисты понимали, что на бекенд надо ходить через отдельные сервисы.

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

«Профессиональный рост: меня и команды» стартуем завтра

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

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

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

Пока Notion, привет Basecamp

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

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

Куда добавлять документацию с описанием, как у нас работает деплой, — в папку «Devops», которая лежит внутри папки, которая лежит внутри «Документы», или сразу в корень? Но ведь у нас в «Документах» лежат и бухгалтерские акты, и тот старый ADR, где мы решали, что не будем затягивать TypeScript в vue2. А как назвать новый документ — «Devops»? Но тогда в поиске по слову «devops» будет вылезать вакансия девопса, которую мы писали для клиента, и скопированная переписка, где я объяснял другому клиенту разницу между девопсами-людьми и девопсом-культурой.

Ну а 10 разных документов с названием «задачи» для разных клиентов и два неймспейса на каждого клиента: ClientName и ClientName private — это отдельный бонус.

Через год такой работы мы поняли, что ноушен в плане средства коммуникации не лучше, чем слак — туда просто написать, но потом невозможно найти. В итоге мы убежали на прекрасный Basecamp. Notion по сравнению с Basecamp — как webpack по сравнению с parcel: в первом случае у тебя сложнейший конструктор, а во втором — за тебя подумали разработчики, и теперь всё просто работает: тут и группировка по проектам, и жёсткая структура проекта, в которой ничего нельзя поменять, и крутейшие ежедневные отчёты о том, что нового произошло в компании. Notion оставили в качестве замены Google Docs — описываем там документы, ведём процессы по выплате зарплаты и другие мелочи.

Не повторяйте нашу ошибку — не ведитесь на красивую упаковку.

P. S. Я по-прежнему считаю, что небольшим командам со средним уровнем сложности можно вообще не брать никаких инструментов, а вести всё в GitHub. Подробнее — см. мою старую статью на VC.

#вопрос Стоит ли использовать приватную почту вроде FastMail? Нужна ли она обычному пользователю?

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

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

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

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

Отвечая на изначальный вопрос — если вы сомневаетесь, нужна ли вам приватная почта, вероятно, она вам не нужна. Ну а если можете — почему бы и нет.

Каждый понедельник я отвечаю на один чётко поставленный вопрос. Задавайте на fedor@borshev.com

Вы неправильно выключаете уведомления

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

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

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

— Открываете настройки уведомлений (Settings → Notifications, если у вас iOS).
— Заходите в каждую программу и снимаете галочку с «Allow Notifications». Не делаете исключений — одинаково отключаете уведомления для телеграма, фейсбука, яндекс.такси, почты, встроенных СМС-сообщений. То есть вы отключаете уведомления не внутри приложения для определённых контактов, а для всего приложения разом.
— После того как вы отключили уведомления, формируете в телефоне VIP-список. Добавляете туда телефоны родных и PagerDuty (если к вам это применимо). Телефоны коллег не добавляете ни в коем случае.
— Объясняете родным, что, если от вас нужно что-то срочное, вам надо звонить. В интернет-магазинах переходите на доставку самовывозом — она не требует никакой срочной коммуникации.
— Если прошёл месяц, а коллеги или босс на работе всё ещё протестуют и говорят, что вы должны срочно отвечать на их сообщения — меняете работу: тишина в голове этого стоит.

Будь в курсе

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

— «Скажи, когда бизнес ждёт эту фичу?» — «Я не в курсе, узнаю».
— «Подскажи, что нам нужно включать в этот RSS-поток?» — «Я не в курсе, спрошу у бизнеса».
— «Чем я могу ещё помочь?» — «Я не в курсе, ребята, скажите, чем Федя ещё может помочь?»

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

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

Менеджеры, будьте в курсе, пожалуйста.

Две вакансии в мои проекты

1. Фронтендер в Школу Сильных Программистов. Проектная работа над opensource-проектом: личным кабинетом студента школы.
2. Руководитель контура к нам с Саматом. Надо писать хороший код на питоне и общаться с бизнесом. Фуллтайм.

В обоих проектах распределённые команды, у которых есть чему поучиться и нормальная удалёнка без стендапов и жиры. Если интересно — присылайте примеры кода и пару слов о себе на fedor@borshev.com.

#вопрос В продолжение темы почты: в каких случаях оправдано поднятие своего почтового сервера вроде iRedMail?

Скорее всего собственный сервер — это требование безопасности. А безопасность — штука относительная.

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

Или ставите вы сервер в супер-защищённую корпоративную сеть, но из-за согласований с безопасностью у вас не осталось время нормально выучить конфигу, и вы оставляете у себя Open Relay (это не выдумка, я такое видел).

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

Кстати, вопросы для понедельников мне можно задавать безопасно и анонимно на fborshev@pm.me.

Не критиковать стиль кодирования на ревью

Это вторая часть поста про линтеры

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

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

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

dependabot → renovate

Я давно пользуюсь dependabot, чтобы автоматически обновлять зависимости в репозиториях: все мои проекты покрыты тестами, и я могу не думать о совместимости. За всё время эта стратегия подвела меня всего один раз — как-то вышла новая версия django-axes, которая почему-то (уже не помню почему) оказалось несовместима с моим сетапом. Все остальные пакеты всегда обновлялись без проблем — и на беке, и на фронте.

К сожалению, после того, как GitHub купил dependabot, у него появился фатальный недостаток, который не могут починить уже год — теперь dependabot не может автоматически мёрджить ПР с обновлениями зависимостей. То есть мне приходится ручками заходить в каждый проект и нажимать там Merge, если пулл-реквест горит зелёным.

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

Уже пару месяцев часть моих opensource-проектов живёт на прекрасном renovate, который не только не заствляет меня думать о минорных зависимостях, но ещё и автоматически бампает версии языка в Dockerfile и даже в настройках CI. Горячо рекомендую.

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

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

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

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

Так что смотрите на команду, а не на компанию. И удачи на новом месте!

Каждый понедельник я отвечаю на один конкретно поставленный вопрос. Задавайте свои на fedor@borshev.com/

Критерий прохождения испытательного срока: вау-эффект

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

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

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

​Недавно меня позвал в гости Иван Самолов. Поговорили буквально обо всём, что меня волнует — о бизнесе с Саматом, о том, как (не) нанимать программистов, как системно вести подход к личному бренду и о том, откуда в телеграме в последний год взялось столько мусорных ИТ-каналов.

Отдельная важная часть — о Школе Сильных Программистов: я впервые публично сформулировал наши цели и подходы: