Цель сообщения

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

Цели бывает три:
— Задать вопрос: «Федя, у нас тут A и B. Не понимаем C. Подскажешь?»
— Согласовать: «Федя, у нас тут D и E. Хотим сделать F. Норм?»
— Попросить: «Федя, нам надо G. Без тебя не можем. Сделаешь?».

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

#вопрос Ты топишь за 12 факторов. А как ты поддерживаешь второй фактор — зависимости, к примеру imagemagick? Оборачиваешь окружение в докер? А на локальной тачке?

Для прода мы используем либо Docker, либо билдпаки от Heroku, которые точно так же явно показывают зависимости.

С локальными зависимостями сложнее. Если мы разворачиваем бекенд на машине фронтендера, то там, используем тот же dockerfile, что и на проде. Если бекенд нужно развернуть на машине бекендера — я рекомендую работать на bare metal, а в докере держать только инфраструктуру, вроде PostgreSQL или RabbitMQ.

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

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

Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me

Вы приняты: второй поток

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

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

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

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

Ну а если собираетесь — стартуем 4 ноября. До 26 октября действует промокод 2Y1ET со скидкой 10%.

P.S. У нас есть 20 мест для тех, кто находится рядом с боевыми действиями, но имеет силы учиться. Напишите нам, если вас это касается.

Вообще в курсе много материалов не о том, как сделать, а о том, почему не стоит этого делать. В первом уроке рассказываем почему переезд может быть плохой идеей, или вот Дима записал видео почему не стоит работать в фангах — https://www.youtube.com/watch?v=RRFSLEFBV6Q

Лайкните, пожалуйста

Обещал рассказать про эксперимент с четырёхдневкой. TLDR — мы продолжаем работать 4 дня в неделю на всех проектах.

К сожалению, в нашей деятельности довольно сложно посчитать производительность и эффективность, поэтому мы ориентируемся на ощущения и опросы. По ощущениям, производительность команды не снизилась. По опросам, часть ребят продолжает работать 5 дней — хоть далеко и не в каждую пятницу. Доля работающих по пятницам колеблется от 30% до 50%, в зависимости от напряжённости на проектах. Судя по коммуникации в бейскемпе, чаще всего по пятницам работают менеджеры.

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

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

#вопрос что почитать, чтобы лучше разобраться в Django?

Этот вопрос мне задали в пятницу на PiterPy и я слегка потерялся, поэтому попробую ответить здесь.

Потерялся я потому, что сам я по Django не читал ничего, кроме официальной документации и пары десятков статей на специфичные темы вроде edge-кейсов в поведении ORM. Честно говоря, я не думаю что по Django можно написать хорошую книгу. Достаточно материала наберётся только, если описывать её целиком, включая древние и бесполезные части вроде системы шаблонов, форм, подсистемы сайтов или стокового тестирования на базе TestCase.

Если описывать только актуальные части, нужные для создания API — ORM, DRF, работу с HTTP, админку, актуальные батарейки— материала наберется на 3–4 лонгрида максимум. Поэтому книг никто и не пишет.

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

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

Это был традиционный вопрос по понедельникам. Хоть вопрос и задали на конференции, чтобы не ждать следующей лучше напишите мне на fborshev@pm.me

Один из клиентов недавно спросил у нас с Саматом, не боимся ли мы публиковать имена программистов в анонсах проектов — вдруг увидят и схантят. Бояться такого довольно странно — если следовать этой логике, надо запрещать им пользоваться ещё и Линкедином, ездить на конференции и вести блоги.

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

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

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

Стартуем в пятницу, а сегодня в 19:30 MSK на канале у Димы отвечаем на вопросы о курсе и поиске работы за рубежом. Записи не будет, напоминать тоже не буду — ставьте напоминалку на ютубе, если интересно.

Записаться →

Почему важно вести дневник

Я веду дневник уже почти 4 года. За это время я сделал около 1000 записей, загрузив в них почти 10 ГБ фото и видео. Считаю, что дневник — самая лучшая инвестиция в осознанность, даже полезнее чем покупка курса HeadSpace. Помимо общей осознанности или улучшения качества жизни, дневник даёт и измеримую пользу.

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

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

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

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

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

#вопрос Подскажи пожалуйста, всегда ли вам хватало возможностей Django для ваших кейсов? Были ли моменты когда было желание переписать на чём то пошустрее? Есть ли какие-то кейсы когда ты бы не взял Django как основу для веб-проекта (помимо микросервисов и жестких ограничений по latency)?

Нам Django всегда хватало. Правда у нас много аутсорсной специфики: команды с высокими требованиями к времени ответа обычно реализуют проекты in-house с помощью собственных дорогих специалистов. В аутсорсе мы практически не работаем с нагрузкой, которую нельзя закешировать.

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

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

Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me

Управляющие воздействия

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

Плохая команда не едет вперёд без дейликов. Несамостоятельный сотрудник не выполняет задачи без десятка комментариев от меня. Плохо настроенный проект буксует без ежедневных встреч всех участников.

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

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

Модель юзера — только для authn/authz

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

Проблема любой модели юзера в любом таком фреймворке — она своим существованием буквально просит неопытного программиста писать в себя код. Пишешь метод получения заказа? Как же клёво будет сделать request.user.get\_orders(). Делаешь почтовые уведомления? request.user.send\_email(). Хочешь отдать в API накопительную скидку? request.user\_get\_discount().

В итоге получается божественный объект, который буквально умеет всё, находится в центре любой схемы данных и не помещается в одной голове, чтобы его отрефакторить. Особенно грустно становится, когда в системе есть несколько видов юзеров — скажем потребители и контент-менеджеры. Первый действительно часто нужно делать .get\_orders(), то у других больше востребованы методы для работы с пермишенами и аудитлогом. И все они лежат в одном месте, путаясь друг с другом!

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

Так что настоятельно рекомендую, если работаете с MVC-фреймворкаии — не используйте модель юзера ни для чего кроме аунтификации и авторизации: запутаетесь.

#вопрос Не возникало ли желания разработать свой инструмент для отрисовки фронта? Я имею ввиду backend driven ui. Возможно что-то используешь из существующего, расскажи пожалуйста об этом. И как в целом рассматриваешь такой подход? И поделись пожалуйста мнением о собственной разработке подобных решений, стоит ли игра свеч?

Начну со второго вопроса. Желание делать собственные инструменты у меня пропало лет 10–12 назад, когда я понял, что попытки конкурировать с сообществом не приносят ни денег, ни счастья. Чтобы делать собственные фреймворки, нужно быть очень хорошим инженером, уметь разговаривать с людьми и разбираться в продуктоводстве. Разговаривая с опенсорсерами уровня Никиты Соболева я понимаю, что мне с моим ремесленническим подходом до этого очень далеко.

Про backend driven ui я уже где-то писал. Даже если отбросить крайности вроде приснопамятного GWT или попыток делать динамические формы на Django, делать фронт силами бекендеров довольно невыгодно с точки зрения бизнеса. Во-первых, на рынке труда гораздо больше неуниверсальных специалистов, то есть проще нанять отдельно бекендера и отдельно фронтендера, чем фуллстека. Во-вторых, все инструменты генерации фронта на бекенде, которые я видел, — довольно маргинальные. Как не конфигури тулзы вроде django-webpack, DX там будет ужасным — ни горячей перезагрузки, ни zero-configuration, даже разворачивать всё это на одной тачке крайне больно. Получается довольно обидно — настраиваешь неделю кучу всякой фигни, с трудом ищешь людей, которые с ней будут работать, а на соседнем проекте набирают npm init vue и получают всё то же самое, но сто раз проще.

Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me

Надёжность

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

Когда два сотрудника назначают встречу на 16:00 — я уверен, что в 16:01 встреча уже будет идти. Когда любой сотрудник компании пишет письмо любому другому сотруднику (мне в том числе), он уверен, что письмо не потеряется.

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

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

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

Сейчас проводим эксперимент — объявляем чёрнопятничную распродажу: в течение 24 и 25 ноября даём скидку 25% на самостоятельный тариф любого нашего курса по промокоду BlackFriday. Хотим использовать пятницу, чтобы дать возможность познакомиться со школой тем, кто сомневается и видит недостаточно ценности в курсах. Или подарить друзьям.

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

Выбрать курс →

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

#вопрос Как нанимать сотрудника на незнакомый стек? К примеру, если мне нужно нанять react-разработчика, то я знаю какие вопросы задать, т.к. я сам пишу на реакте. Но как быть, если в команду нужен специалист по machine learning и ни у кого нет опыта в этом направлении?

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

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

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

Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me

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

— У вас нет перерывов между встречами. Значит после 2–3 таких встреч остальные становятся бесполезны — вы будете банально тупить на них.
— Вы не защищаете свой календарь. Вряд ли вы сами поставили себе встречу, которая пересекается с другой: скорее всего вас позвали, а вы не смогли отказать.
— У вас принято задерживаться на встречах. Это значит, что встречи скорее всего проходят без повестки или в неудачном составе.

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

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

#вопрос Я всю жизнь промышленно пишу бэкенд, периодически ненадолго заглядывая во фронтенд по мере надобности (есть минимальный опыт с React, Svelte). Сейчас выбираю стек технологий для личного проекта. Нужен будет API для приложений и для фронта; фронт— админка и простой сайт для пользователей.

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

Сам склоняюсь к Django+React (хотя душа просит Svelte). Если можешь, расскажи, какие технологии сейчас позволяют программисту сделать сайт, как будто он чуть-чуть дизайнер. (Я слышал слово «tailwind».

———

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

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

У tailwind есть своё место — на нём удобно собирать админки и простые CRUD-интерфейсы. Если интерфейсы становятся сложными и в команде появляется дизайнер — становится тесновато. В контексте роста проекта у инструментов вроде tailwind довольно узкое окно: когда зерокода уже мало, а для полноценной разработки пока рановато. Как пример — мы делаем на нём новую версию школьной LMS: старая упёрлась в техдолг, дизайнера и UI-кита в команде нет, вот мы и взяли готовое.

Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me

Умение рассказывать истории

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

На работе люди рассказывают истории всегда — на собеседованиях, когда объясняют новую концепцию на встрече, когда онбордят новичков и ставят задачи — у всего этого есть нарратив, который один человек рассказывает другому. Нарратив может быть минимальным: с началом, серединой и концом. Бывает посложнее — к примерукруг Хармона (того самого, из Рика и Морти) с неясным зовом, поиском, перепетиями и победой в конце.

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

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

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

Писать мало кода — это софтскилл

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

С одной стороны ребят можно понять — хочется больше практиковаться в новых технологиях: когда пришёл на проект, где всё уже работает, самый хороший способ изучить его технологии— воспроизвести с нуля на соседнем проекте. Да и индустрия давит — парочка хайповых технологий в резюме привлечёт больше сорсеров, чем умение решать задачи за день вместо недели или за 300 строк вместо 30 000.

Если планируете развиваться в кого-то кроме синьёра, годами не вылезающего из своего, постепенно превращающегося в легаси, проекта, такой оверижиниринг для вас — стратегическая ошибка. Смотрите сами, технологии — это хард-скиллы. Сегодня RabbitMQ, завтра BunnyPQ или RussMessageOchered: всё это учится за 1–2 недели при желании. А вот умение писать мало кода — это целый сложный софт-скилл: тут и в бизнес-задаче надо разобраться, и изобретать уметь, и заказчику продать свои изобретения. За пару недель не освоишь.

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

Есть минутка

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

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

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

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

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

Так что мы сделали 3 письма, которые радикально улучшат коммуникацию — вокруг вас, если вы обычный программист или во всей команде, если вы менеджер\тимлид.

Смотреть программу →

Стартуем 1 февраля, до 26 декабря — скидка 10% по промокоду NOSYNCNEEDED

Возник #вопрос по поводу твоего поста Кто отвечает, чтобы ПР оказался на проде.

Вроде смысл понятен: дать понять представление о границах ответственности разработчика и definition of done. Но как это работает на практике не очень ясно: разработчик контролирует процесс QA и деплоя и людей, которые за них отвечают? Сам тестирует или деплоит? Что насчет интеграции фронтенд кода с бэкэндом? Продолжается ли ответственность до того, чтобы код правильно работал на проде? Работает ли это по другому сейчас, когда у вас аутсорс разработка?

———

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

Теперь отвечу на остальные вопросы.

> разработчик контролирует процесс QA и деплоя и людей, которые за них отвечают?

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

> Что насчет интеграции фронтенд кода с бэкэндом?

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

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

> Продолжается ли ответственность до того, чтобы код правильно работал на проде?

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

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

Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me

P.S. Если вы питонист и хотите работать в зрелой команде — мы открыли набор.