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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На таких страхах вырастают неуклюжие, плохо пахнущие классы с копипастой, которые постепенно превращаются в легаси.

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

Если вы задаетесь этим вопросом, значит вам — не нужен.

Проблема докера — в пороге вхождения. Уметь докер — это как уметь HTML: чтобы его применить, нужно учить еще вагон технологий: CSS, JS, и еще бекенд желательно. У докера этот вагон состоит минимум из swarm (а лучше k8s), чтобы запускать контейнеры, prometheus, чтобы их мониторить, и кучи самописных скриптов, чтобы все это деплоить.

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

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

Триггеры, когда действительно пора задуматься про докер:

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

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

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

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

Есть два режима жизнедеятельности — производство и потребление.

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

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

В увеличении производства в первую очередь заинтересованы вы сами. Чем больше вы делаете (или другие, с вашей помощью) — тем быстрее достигаете целей.

Человечество изобрело кучу инструментов для потребления — телефоны, торговые центры, push-уведомления, шаурма у метро.

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

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

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

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

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

Такое задание — как открытый вопрос. Поймет ли новенький наш стиль для названий тестов? Не испугается ли сложности? Дополнит ли документацию? Напишет ли переиспользуемый код? Не постесняется задавать вопросы? Выдержит ли дедлайн, который сам назовёт?

Если вдруг проект не получается отдать из-за НДА-шных причин — отдаю специально хранимый для этих целей pet project.

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

Самое главное правило — не обманывать себя при планировании и помнить, что планы без запаса не сбываются.

Свой запас я держу в буфере, который называется «можно проебать» — это прям такой лейбл в трекере. Лейбл ставится на задачи, которые мы будем делать только, если успеем закончить более важные.

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

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

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

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

Я говорю о простых случаях, которые может заметить кто угодно, банальном «нажимаю на кнопку — получаю ошибку». Непосредственных причин такой хуйни может быть много — CI упал, код не прошёл валидацию\тесты, программист забыл сделать git push.

А вот фундаментальная причина одна, и ее легко исправить — это непонимание definition of done. В случае бага все просто, сделанная работа — это когда баг не воспроизводится на продакшене. В сложных фичах нужно позадавать себе вопросы — что постановщик ожидал получить? Какой самый частый сценарий использования? В каком виде лучше показывать результат?

Самое лучшее средство от непонимания definition of done — всегда подкреплять свои слова доказательством. Пофиксил баг — приложи скриншот. Выкатил фичу — запиши видосик. Если не понимаешь, что скриншотить/записывать — иди за пониманием задачи к тимлиду или менеджеру.

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

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

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

О таких проблемах гораздо лучше узнавать от воображаемого коллеги, а не от реального.

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

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

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

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

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

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

Моя библиотека книг по тайм-менеджменту ограничена единственной Getting Things Done, поэтому я обрадовался, когда ребята из издательской студии Поле предложили написать рецензию на книгу Марка Форстера «Сделай это завтра», которая выходит у них в ноябре.

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

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

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

Конечно, книга не заменяет ГТД с его пустыми инбоксами, но хорошо дополняет. По предзаказу стоит 600 рублей.

Никогда не реагируйте на что-­то немедленно, если ситуация не является по­-настоящему неотложной или ваша работа не предполагает такой реакции.

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