В общении с плохими программистами (а ещё строителями, водителями и сантехниками) часто проскакивает тон «нерешаемая задача»:

— Давай сделаем, чтобы по нажатию на кнопку уходило письмо клиенту? Не получится, мы в этот момент ещё не авторизованы на бекенде :(

— Давай передавать данные о телефонных заказах в Гугль-аналитику? Это невозможно — мы для таких заказов не знаем ID аналитики :(

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

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

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

Будьте решателями проблем, а не создавателями.

Один из ботов, которых мы активно используем в Гитхабе ГдеМатериала — stale. Задача бота очень простая — приходить в каждый пулл-реквест, в котором ничего не происходит.

Вот к примеру сделал я ПР, который немного улучшает кодовую базу. Хотел показать коллегам-разработчикам, и забыл — так пулл-реквест и остался висеть. Бизнес-стейкхолдера у задачи нет, поэтому никто, кроме меня, про неё не напомнит. Или пришёл бизнес с задачей, мы её начали делать, задали пару вопросов — а нам никто не отвечает.

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

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

Наш бот не совсем политкорректный — ведь незавершённая работа это так плохо:

Наверное, где-то в мире есть ребята, у которых гипотезы не выстреливают с вероятностью 80% или даже 75%. Но у нас с вами это не так. Фича, которую вы пилите прямо сейчас, улетит у трубу с вероятностью 90%. Пользователи не заметят новую кнопку, робот не сработает, потому что годится только для 0,1% заказов, а письмо, которое вы верстали неделю, никто не откроет.

Повторите про себя пару раз, и как только вы осознаете — вам сразу станет легче жить. Вы перестанете подходить к новым фичам с завышенными ожиданиями (вот сделаем и заживём!). Вы перестанете проектировать раздутое говно — зачем, если вы выкинете это с вероятностью 90%?

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

Помните мой совет со входом через Инстаграм? Зная о том, что этот вход не будет никому нужен с вероятностью 90%, вы сделаете интеграцию не с инстаграмом, а с auth0, чтобы в будущем сразу проверить 10 других способов входа, 1 из которых окажется рабочим.

Просто всегда помните, что ваша гениальная идея с вероятностью 90% — говно.

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

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

За процесс, наоборот, спрашивать легко: опоздал программист на работу на 5 минут — значит виноват. Тупанул во вконтосик в рабочее время — значит плохо работает.

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

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

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

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

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

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