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

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

Вместе с увеличенным заработком приходят возможности. Вот уже вместо списка покупок в «Ашане» вы заказываете доставку готовой еды, а освободившиеся 3 часа вкладываете в новый проект, который принесёт ещё больше денег.

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

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

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

Представьте, если первоклассник принёс учителю решение, что 2 x 2 = 3, а учитель в ответ выражает просто мягкое неодобрение, но не говорит, что правильно будет 4? Математика никогда не откроется ребёнку как точная наука, скорее ощущение будет «ну, я что-то делаю, что-то, наверное, получается».

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

Важно — именно «ты сделал говно», а не «ты — мудак». Критиковать можно только работу, но не личность.

40 минут говорили о будущем Django, про асинхронщину в питоне и о том, стоит ли учить ей джунов:

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

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

Во-вторых, это трата времени людей. Я говорю не об автоматических e2e-тестах на регресс, а о банальных интеграционных тестах. Какой смысл ждать по 4 часа ответа от кожаного мешка, когда можно за час написать робота, который проверит этот кусок работы? Причём робот сделает это не только сейчас, но и потом — в CI, при регрессионном тестировании, всегда.

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

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

Но есть одно место, где я жёстко включаю Ильяхова — это заголовки задач в трекере. Насколько вы бы захотели работать в команде, которая целый день занимается какой-нибудь «необходимостью реализовать новый механизм построения отчётности» и, чтобы не произносить это дерьмо в слух, называет задачи по номерам (типа «Как там задача 1238?»). Я — не хотел бы.

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

• Из заголовка чётко понятно, что нужно сделать. Не «доработать логику корзины», а «Сделать, чтобы при удалении последнего товара корзина очищалась».
• Никакой воды: смело рубить всякие «необходимо реализовать» и «отсутствие возможности».
• В заголовке есть понятные для всей команды ключевые слова. Если задача про вкладку Логистика, то так и писать «логистика», а не «интерфейс менеджера до доставке».
• Если задача мало декомпозирована («привести в порядок учёт зарплаты») то заголовок должен описывать следующий понятный шаг, к примеру «Понять, почему заказ 100500 не пробросился в 1с» или «сделать кнопку «не согласен с расчётом».

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