Ну и чтобы два раза не вставать — я ищу фронтендера на свой проект. Обязательно знать vue.js и не бояться код-ревью, желательно знать Quasar Framework, иметь Android-телефон и писать тесты (если нет — научим). Работа проектная, занятость парт-тайм, оплата — по неделям.

Присылайте ссылку на гитхаб, пожелания об условиях работы и пару слов о себе на fedor@borshev.com с пометкой «Фронтендер-андроидер»

Что делать, если проебал дедлайн?

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

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

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

Ошибиться со сроком — не страшно. Страшно — ошибиться второй раз: тебе перестанут доверять.

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

Я неверно оценил свои силы → Я долго разбирался с новым плагином для Ангуляра
Изменились условия задачи → Я не учел, что потребуется переверстывать шапку
Я неверно понял задачу → Я не обсудил задачу с постановщиком

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

Самое главное правило сдачи работы

Самое главное правило сдачи любой творческой работы — никогда не оставляй заказчика одного. Не кидай ссылку на макеты, не отправляй демо-доступ, не высылай текст в Гугль-доке.

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

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

Не хочешь слить в трубу результаты работы — презентуй её лично.

Спасибо всем, кто пришёл вчера на AMA в Питере!

Вы задавали интересные и сложные вопросы, давали полезные дополнения. Получилось супер!

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

​Вопрос: какой софт используешь для Pomodoro? Синхронизируешь ли с календарём и другими приложениями?

Я использую Tomato One.

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

Есть вопрос? Напишите мне на fedor@borshev.comfedor@borshev.com

Я начал новый цикл советов — простым языком рассказываю, чем аккуратный объектно-ориентированный код отличается от неаккуратного.

В первом совете из цикла рассказал о зацеплении — показателе того, насколько один класс зависит от другого.

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

​Запись вебинара об удалённой работе

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

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

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

free-for.devfree-for.dev

Давно хотел вам посоветовать крутейший источник знаний об окружающем мире — free-for.dev. Это каталог сервисов, которые предоставляют бесплатные тарифы для программистов. Ценность этого каталога — не в халяве (хотя наверное это кому-то тоже важно), а в его таксономии. Просто читаете, какие сервисы существуют, и узнаёте много нового о современном контексте разработки.

К примеру именно из free-for.dev я когда-то давно узнал, что в мире существуют такой класс сервисов, как APM, или что можно просто скормить все логи в papertrail, а не поднимать свой ELK-стек.

Каждый раз, когда собираетесь притащить что-нибудь новое в свою инфраструктуру — посмотрите на free-for.dev, наверняка это уже есть в виде облачного сервиса за $10 в месяц.

#вакансия #работамечты #питер

Мы с Саматом ищем рубистов в iGooods. Вы придёте в самую сложную и интересную фазу проекта — мы забрали код от аутсорсеров, и теперь приводим его в порядок: покрываем тестами API, разбиваем лишние связи, строим нормальный CI/CD. Из последних достижений — выдернули user-facing фронтенд из монолита и запустили SPA на React/TSX, унесли тестовые стенды на DigitalOcean, внедрили Rails::Engine и прямо сейчас внедряем паттерн Repository, чтобы избавиться от толстых моделей.

Проект — автоматизация службы доставки из магазинов: задания для сборщиков товаров и курьеров, управление персоналом (сколько и куда выводить людей), интеграции с разными сервисами, начиная от разбора списка товаров от сотен офлайн-магазинов и заканчивая собственной системой аналитики на ClickHouse. По технологиям — Rails 4 (скоро поправим), DRY-стек, тесты пишем на RSpec. Код и CI на Гитлабе, задачи в Джире. Лежит всё на железках в Селектеле, но мы активно виртуализуемся и контейнеризуемся.

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

Работа из офиса на Технологическом институте, один день в неделю — дома. Зарплата — от 150k для мидлов и 250к+ для синьоров. Если вы — джуниор и покажете проект с тестами на гитхабе, возьмём вас на 80k и прокачаем до мидла.

За рекомендацию мидла, который пройдёт испытательный срок, бонус 80 000 рублей.

Вопросы и отклики пишите руководителю бекенда Жене Зубаирову @MindCufk.

Вопрос: почему ты работаешь стоя? Весь день вообще не садишься?

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

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

Другие вопросы — #вопрос. Задать свой — fedor@borshev.comfedor@borshev.com

Срочно в номер: завтра ваш сертификат letsencrypt может превратится в тыкву

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

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

Это ощутимо задело ГдеМатериал — половину сертификатов пришлось перевыписывать.

Почитайте почту и проверьте свои сервисы вот тут.

​От 0 до 150 000 строк кода не жертувя качеством

Ребята из MoscowPython выложили видео моего доклада о том, как мы в ГдеМатериале поддерживаем качество кода.

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

Несмотря на все проблемы, получилось круто, так что смотрите, но не смейтесь :-)

Второй совет про аккуратный код: связность

Вышел второй совет об аккуратном коде, где я простым языком рассказываю о принципе единой ответственности (S из SOLID).

Опять прошу от вас обратной связи — понятно ли это для людей, которые не сильно разбираются в программировании?

#вопрос: объектно-ориентированный стиль или функциональный?

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

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

Уверен, что я такой не один, поэтому жёстко приходить в команду с тем, что «мы теперь пишем только ООП» я бы не стал. Если бы я, как CTO, был уверен, что у нас вся команда хочет писать в функциональном стиле, функциональный стиль подходит ко всем нашим core-библиотекам, и мы сможем нанимать неограниченное количество новых людей, которые будут это поддерживать — я бы, наверное, согласился.

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

Коридорное тестирование

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

Есть ребята, которые под коридорным тестированием понимают «взять макеты и побегать с ними по коридору». То есть не тестируют прототипы, а просто показывают макеты разным людям и спрашивают «что думаешь?».

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

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

См. также «Одна задача — один ответственный»

Небольшое реалити-шоу про меня

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

Последний, 15-й эпизод в этом сезоне. Уходим на месяц каникул и вернемся со вторым сезоном, ещё интереснее первого. Спасибо замечательной команде — Андрею Борзенко, Юле Яковлевой, Павлу Цурикову, Павлу Боровкову и Полине Агарковой. Вы лучшие!

Спасибо вам большое, что слушаете! Пожалуйста, пишите в личку, что вы думаете о подкасте — даже (особенно) если вы не довольны и хотите что-то поменять.

Три абзаца

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

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

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

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

См. также Длинные ТЗ не работают