Фёдор Борщёв

Вебинар о профессиональном росте

В эту субботу в 14:00 я провожу большой вебинар о профессиональном росте. Расскажу, как планировать свой рост: как найти время на развитие, где практиковаться, как руководить коллегами, доводить дела до завершения и в чём разница между профессиональным и служебным ростом.

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

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

Почитайте программу

Рабочее и личное время

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

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

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

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

AirPods в один клик

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

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

Оказывается, этот процесс можно сократить до одного клика и пары секунд — есть специальные программы, которые сделали именно для того, чтобы моментально подключать AirPods к компьютеру. Я пользуюсь бесплатным workflow для Alfred, который так и называется AirPods Connector. Если у вас вдруг нет Alfred — не беда, заплатите 400 рублей за ToothFairy, которая делает то же самое, или просто скачайте бесплатный AirBar.

Я ничего не понял

Каждому из нас периодически падают плохо проработанные, непонятные и невежливые письма: «Коллеги нужна выгрузка платежей генеральный требует ASAP». Если вы сами пишете такие письма — почитайте Ильяхова. А в этой заметке я расскажу про заклинание, которое от таких писем помогает.

Заклинание называется «я ничего не понял». Если вам написали неопрятное письмо, даже не озаботившись тем, чтобы из него было понятно, чем можно помочь — просто пишите в ответ «я ничего не понял».

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

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

Бирюзовое доверие

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

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

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

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