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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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