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

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

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

А может и не заметят. Если от коллеги плохо пахнет (простите) то есть вероятность что никакой личный пример не заставит его соблюдать правила гигиены.

Есть #вопрос про ИТ? Задавай в @fedor_borshev

​​В mtrl.ai мы ищем ведущего питониста. Вы будете работать над нашим бекофисом — это сложное бизнес-приложение, которое позволяет нам взаимодействовать с неорганизованными строительными рынками, как с настоящими складами.

Вам придется работать с асинхронным предсказанием наличия, системой принятия решений о выборе поставщика\менеджера, API для сайта, телефонии, маркетинга и еще кучей всего. Код без легаси, самые старые участки написаны в начале 2017 года.

Кол пишем на Django2/DRF и python 3.6. БД — Postgres и Redis, планирование задач на Celery/RabbitMQ, поиск на elasticsearch. Переиcпользуемый код опенсорсим или выносим в микросервисы. Пишем юнит- и интеграционные тесты на pytest, на самом большом проекте сейчас ~4500 тестов.

Работаем удаленно, недельными спринтами, таски ставим в issues гитхаба. Сейчас в команде, включая меня, трое питонистов — вы будете четвертым.

Если порекомендуете друга, который пройдет испытательный срок — получите 30к.
 
По всем вопросам — @fedor_borshev.

#работамечты

​​Понятный код

Долго думал над тем, как можно было бы одним словом охарактеризовать хороший код. Недавно дошел: ПОНЯТНЫЙ.

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

Может ли хороший код быть непонятным? Нет. Может ли понятный код быть плохим? Вряд ли.

Вопрос: Я программист, хочу стать тимлидом и руководить людьми, что почитать?

Тимлиду нужно прокачивать то же, что и менеджеру — общение с людьми, ответственность, планирование проектов и управление командой.

Прокачку софтскиллов стоит начать с классики вроде Стивена Кови и Джима Кэмпа. Обе книги — сложный и качественный селф-хелп, почти без воды.

Для хардскиллов рекомендую Голдрадта — Цель (все три части) и Критическую цепь.

Если прочитали основы, поизучайте список книг в моем блоге.

#вопрос

​​Первый закон Паркинсона

В 50-х годах прошлого века умный дядька по фамилии Паркинсон, историк по профессии, вывел немного шутливый, но верный и правдивый закон — работа занимает все отведенное на нее время.

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

Если у вас в спринте три мелкие задачи, то вы будете делать их две недели.

Наоборот тоже работает — если до конца недели нужно сделать 20 задач (и вам отрежут руку, если не сделаете), то вы найдете способ все успеть — пофлексите, упростите код, напишете говно, наконец.

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

​​Сервисы: Periscope

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

У нас в mtrl.ai уже давно внедрен Periscope — помимо привычной функциональности, вроде построения графиков и сборки красивых дешбордов, он сильно упрощает построение запросов — там есть упрощенные джоины (SELECT order.id, order.date, customer.name from [order+customer]), джоины из разных БД, кастомные вьюхи и еще много всего, упрощающего жизнь и аналитикам и программистам.

Periscope — дорогой инструмент (цены начинаются от 500$ в месяц), наверное есть и подешевле. Но простота настройки и фичи, которые позволяют аналитикам не ковыряться в дебрях SQL, кажется стоят еще дороже.

​​Процесс vs результат

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

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

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

Самый хороший способ — прямо сейчас найти у себя на работе проект с жестким дедлайном и взять на себя ответственность за его завершение. После второго проеба вы научитесь вести правильный внутренний диалог с собой: «Действительно ли то, что я делаю необходимо для результата?»; «Что из того, что я запланировал можно НЕ делать?».

Если проектов нет на работе — сделайте свой. Только поставьте жесткий дедлайн с осязаемым результатом. Хорошая личная задача — «завести блог». Напишете себе бекенд на гошечке? Возьмете модный генератор статичных сайтов? Или все-таки медиум?

Слово «Аджайл» заездили давно и наглухо. Даже Сбербанк уже работает по аджайлу. Тем не менее, я до сих пор встречаю ребят, которые не понимают, что такое «гибкость» в процессе разработки ПО.

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

​​Ребята из Zeit.co (они же now.sh) выкатили классную фичу — деплой докер-образа в одну команду.

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

Плюшки вроде автоотката в случае фейла, скейлинга и полного отсутствия серверов, жестких дисков, дистрибутивов убунты и apt-get прилагаются.

​​Сервисы: retool

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

Ребята из retool пошли еще дальше — они позволяют прямо мышкой собирать кастомные интерфейсы, которые будут ходить в API или напрямую в БД.

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

А вот доступ к API — это круто. В комплекте с работающей документацией (вроде apiary + dredd), это позволит не привлекая программистов на коленке собирать новые рабочие места.

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

Приходи с решением, а не с проблемой

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

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

Задать вопрос и просидеть до конца спринта в ожидании ответа — самый лёгкий способ соблюсти закон Паркинсона.

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

Post mortem

Большие ребята, которые работают с инженерами, после крупных аварий всегда пишут post mortem — начиная с гугля и амазона, и заканчивая более «консьюмерскими» сервисами вроде circle ci или гитхаба. Самый известный post mortem, который наверное читали все — эпичный проеб данных в гитлабе.

Обычно в таких документах на более или менее понятном языке объясняют причины произошедшей аварии и рассказывают про выводы и изменения в командных процессах.

Существует даже целая коллекция post mortem, можно читать прям с пивом и попкорном.

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

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

В mtrl.ai принято писать подробные письма о крупных ошибках. Вот к примеру про недавнюю проблему, которую спровоцировал я (ПДФ, чтобы картиночки сохранить).

​​В эту субботу закрывается старая версия CircleCI.comCircleCI.com

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

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

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

Цены у circle вполне демократичные — 50$ за контейнер. В комплекте — еще один бесплатный контейнер, который умеет собирать приватные проекты.

Письмо самому себе

Из ГТД я вынес для себя три вещи: ежедневные обзоры дел, пустой инбокс и письма самому себе.

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

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

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

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

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

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

Бот, кстати, бесплатный и открытый, так что если вы ГТД-шник — смело пользуйтесь: @selfmailbot.

​​Сервисы: dependabot

Важная часть гигиены кодовой базы — актуализация зависимостей. Устаревшие зависимости приводят к мелким незаметным проблемам, которые вместе съедают кучу времени — на 5 минут дольше разворачивается проект; появляются свой код, который дублирует то, что давным-давно есть в апстриме; код не работает на новой убунте и т.д.

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

Dependabot решает эту проблему методом брутфорса: он постоянно мониторит зависимости и делает пулл-реквест с новой версией сразу после выхода. Первое внедрение становится тяжелым — вам упадет 20–30 ПР, с которыми как-то нужно будет разобраться. Зато потом вы получаете гарантию, что ваши зависимости не застрянут в каменном веке — просто нажимайте на зеленую кнопку: у вас же наверняка хорошее покрытие, и вы не боитесь обновляться, правда?

Самый первый дедлайн

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

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

В этот период вас оценивают. Ваши будущие отношения будут построены не по тому, как вы вели себя на встрече, а по тому, как вы поведете себя в эту неделю.

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

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

Не проебывайте первый дедлайн. Договоритесь об ФФФ, срежте 90% работ, но решите задачу полезно для бизнеса. Даже маленький результат за спиной позволит управлять ситуацией, а не созерцать, как все катится под гору из-за недоверия.

Микроменеджмент ←———→ доверие

Для меня всегда слово «микроменеджмент» был антонимом слова «доверие».

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

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

А если вы занимаетесь микроменедментом, значит вы не доверяете коллегам. Насколько вообще имеет смысл работать с людьми, которым нельзя доверять?

Работа мечты: Сделать домашнюю работу

В последние несколько месяцев мы быстро растем и проводим много собеседований. Для меня это способ понаблюдать и поделать выводы о состоянии рынка труда программистов, вернее той его части, которую еще не съели крупные ребята типа Яндекса и Мейл.ру.

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

Начнем с самой важной части процесса — домашней работы. Хорошо проделанная домашняя работа гарантирует быструю встречу с CTO, а ее отсутствие — встречу с HR и тестовое задание до собеседования.

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

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

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

#работамечты

Вопрос: куда пойти работать начинающему веб-программисту: в студию или продуктовую команду?

У каждого из направлений свои плюсы.

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

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

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

Когда станете мидлом и выше — в какой-то момент сами придете к варианту с продуктовой командой.

Есть #вопрос? Присылай на @fedor_borshev