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

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

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

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

Ещё в студии я познакомился с простым правилом управления любым проектом: если прошло 50% времени, проверь — выполнена ли половина работы.

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

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

Кстати, вопрос про 50% можно задавать самому себе и без помощи менеджера — хватит даже самой простой системы напоминалок

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

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

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

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

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

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

Их на самом деле всего три: ничего не делать, стать синьором или податься в управление.

Ничего не делать

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

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

Синьор

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

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

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

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

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

Тимлид\Менеджер

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

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

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

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

А там уже до CTO недалеко.

Итого

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

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

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

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

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

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

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